An efficient architecture for the integration of sensor and actuator ...

Adv. Radio Sci., 9, 231–235, 2011 www.adv-radio-sci.net/9/231/2011/ doi:10.5194/ars-9-231-2011 © Author(s) 2011. CC Attribution 3.0 License.

Advances in Radio Science

An efficient architecture for the integration of sensor and actuator networks into the future internet J. Schneider, A. Klein, C. Mannweiler, and H. D. Schotten University of Kaiserslautern, Institute for Wireless Communication and Navigation, Paul-Ehrlich-Straße – Building 11, 67663 Kaiserslautern, Germany

Abstract. In the future, sensors will enable a large variety of new services in different domains. Important application areas are service adaptations in fixed and mobile environments, ambient assisted living, home automation, traffic management, as well as management of smart grids. All these applications will share a common property, the usage of networked sensors and actuators. To ensure an efficient deployment of such sensor-actuator networks, concepts and frameworks for managing and distributing sensor data as well as for triggering actuators need to be developed. In this paper, we present an architecture for integrating sensors and actuators into the future Internet. In our concept, all sensors and actuators are connected via gateways to the Internet, that will be used as comprehensive transport medium. Additionally, an entity is needed for registering all sensors and actuators, and managing sensor data requests. We decided to use a hierarchical structure, comparable to the Domain Name Service. This approach realizes a cost-efficient architecture disposing of “plug and play” capabilities and accounting for privacy issues.

1

Introduction

Today, most sensors are restricted to a local platform and cannot be accessed from external systems or applications. This drawback causes high redundancy in terms of hardware and hence high capital expenditures. In this paper, we present an architecture for integrating different sensors and actuators into the Internet. Our concept enables efficient management and access to sensors, actuators, and additional meta information via open and standardized interfaces, and provides means for ID and access management, while using the InterCorrespondence to: J. Schneider ([email protected])

net as comprehensive transport medium. Important requirements and objectives, that need to be addressed, are: – Privacy and Security – Manufacturer Independence – Dynamic System Adaptations – Scalability – Plug and Play Capability – Open and Standardized Interfaces – Low implementation Costs All these issues are related to the question: “How will such a concept be accepted by users?”. In order to gain the users’ confidence, the architecture must take care of all these aspects. The market acceptance is not only dependent on users’ confidence, moreover the system needs to be composed of mass market products to achieve low-priced products and increase the system’s attractiveness. Since our selected transport medium is the Internet, the users benefit from low installation costs and high reusability. Our proposed architecture is not limited to any special application. Moreover, we introduce an architecture which is able to deal with several application fields like home automation, ambient assisted living, home security, smart grid, etc. The paper is organized as follows: Sect. 2 briefly lists the state of the art. In Sect. 3, we present the system architecture and sensor integration. Finally, the paper concludes with a summary and an outlook on future work. 2

State of the art

Today, related to sensors and sensor networks a lot of research work has been done in the field of energy management (Wang, 2006; Emmert and Staehle, 2007; Wang and

Published by Copernicus Publications on behalf of the URSI Landesausschuss in der Bundesrepublik Deutschland e.V.

232

2

J. Schneider et al.: An efficient architecture for the integration of sensor and actuator networks J. Schneider et al.: An Efficient Architecture for the Integration of Sensor and Actuator Networks into the Future Internet

Yang, 2007). In particular, wireless sensor networks have (Wang, 2006), (Emmert, 2007), (Wang, 2007). In particubecome a popular target for several energy management conlar, wireless sensor networks have become a popular target cepts. Although, our proposed concept has the potential to for several energy management concepts. Although, our proreduce energy consumption in wireless sensor networks, the posed concept has the potential to reduce energy consumpfocus of inour approach is on easily integrating different sention wireless sensor networks, the focus of our approach sorsisand actuators in the present and future Internet structure. on easily integrating different sensors and actuators in the Thepresent projectand C-Cast introduced a centralized future(C-Cast, Internet2010) structure. The project C-Cast (Ccontext management architecture. This architecture consistsarCast, 2010) introduced a centralized context management of Context Providers (e.g. wireless sensor networks), Conchitecture. This architecture consists of Context Providers text (e.g. Consumers (e.g. actuators for system adaptations) and(e.g. a wireless sensor networks), Context Consumers Context Broker. The Context Brokerand actsa Context as a central agent. actuators for system adaptations) Broker. The Therefore, Context toTherefore, send a registration Contextall Broker acts Providers as a centralhave agent. all Context to the Contexthave Broker witha their capabilities senProviders to send registration to the(available Context Broker sor values). this(available architecture doesvalues). not account for with theirHowever, capabilities sensor However, privacy issues. Zuniga and for Krishnamachari, this architecture does(Zuniga not account privacy issues. 2003) Zuniga proposed two2003) different solutions to integrate sensorstointo the (Zuniga, proposed two different solutions integrate sensorsIninto In the first approach, a direct conInternet. the the firstInternet. approach, a direct connection is used, is used, i.e. eachconnected sensor is to directly connected i.e. nection each sensor is directly the Internet and to canthe Internet and canIP be address. reached via address.approach, In the second be reached via its In its theIPsecond an approach, an indirect connection is used; this means a gateindirect connection is used; this means a gateway is responresponsible for providing an interface between sibleway for is providing an interface between the Internet and the eachInternet and each sensor. Especially for home automation, sensor. Especially for home automation, a special EIB/KNX a special EIB/KNX (KNX, 2010) busdifferent is used to connect with differ(KNX, 2010) bus is used to connect actuators ent actuators with each other. Communication is performed each other. Communication is performed via a serial bus and a serialis bus and each actuator is assigned a unique is adeachvia actuator assigned a unique address. Main drawback dress. Main drawback is the enclosed system communicathe enclosed system communication, since bus specification tion, since specification restricted and to KNX Associais restricted to bus KNX Associationis members license fees tion members and license fees are expensive. For managing are expensive. For managing sensor data, a distributed Consensor data, a distributed Context Service Architecture has text Service Architecture has been published in (Mannweiler, been published in (Mannweiler, 2010) and describes the de2010) and describes the design as well as the implementation sign as well as the implementation of a highly scalable soof a highly scalable solution for a context service registry lution for a context service registry in mobile environments. in mobile environments. This overcomes the bottleneck of This overcomes the bottleneck of centralized context mancentralized Additionally, this agementcontext systems.management Additionally,systems. this system has successfully system has successfully been tested with five small sensor been tested with five small sensor networks, each disposing networks, disposing of sensors. three to Our five designed individualarchitecture sensors. of threeeach to five individual Ouralso designed architecture also aims at context cooperating with such aims at cooperating with such service architeccontext architectures service delivery platforms. turesservice and service delivery and platforms. 3

System architecture and sensor integration 3 System Architecture and Sensor Integration

Sensor networks are an emerging research topic and have Sensor networks are an emerging research topic and have a wide range of potential applications. Hence, we present a wide range of potential applications. Hence, we present a comprehensive architecture to cover multiple application a comprehensive architecture to cover multiple application fields. Our introduced system is capable of supporting apfields. Our introduced system is capable of supporting applications andand services which useuse sensor data forfor controlling plications services which sensor data controlling actuators and system adaptations. Services are able to to access actuators and system adaptations. Services are able access sensor information of different SCPs via open and standardsensor information of different SCPs via open and standardizedized interfaces, thatthat alsoalso enable to integrate new sensors, interfaces, enable to integrate new sensors,ir-irrespective of manufacturer. Thus, the system is extensible respective of manufacturer. Thus, the system is extensibleinin a “Plug and&Play” Figure 1 illustrates the generic a ”Plug Play” manner. manner. Fig. 1 illustrates the generic system system structure. structure. Our system consists of the following functional components:

Fig.1.1.Generic Genericsystem Systemstructure. Structure Fig.

– Sensor Providers (SCP): These entities provide Our systemContext consists of the following functional composensor context information which is gathered by sensors nents: or sensor networks. – Sensor Context Providers (SCP): These entities provide – Gateway: The gateway implements the interface besensor context information which is gathered by sensors tween SCP(s) and the Internet. or sensor networks. – Sensor Address Server (SAS): All SCPs are registered at – Gateway: gateway implements interfaceSCP bethis entity The and the SAS will choose anthe appropriate tween SCP(s) and the Internet. on sensor data requests.

– –Sensor Address Server are (SAS): SCPs and are registered Service: These entities able All to request subscribe atfor thissensor entitydata. and the SAS will choose an Logical functions are usedappropriate for comSCP on these sensorvalues data requests. bining and exploiting them e.g. for system adaptations. All services need to be advertised to a node – Service: These entities are able to request and subscribe of the registry located in the Local Area Network or to for data. registry Logicalof functions for comthesensor distributed the Wide are Areaused Network, rebining these values and exploiting them e.g. for system spectively. adaptations. All services need to be advertised to a node the registry located the Local AreatoNetwork or to –ofActuators (AC): Theseinentities are used control externaldistributed devices likeregistry heaters,oflight, the the etc. Wide Area Network, respectively. To achieve a high reusability of deployed hardware, each SCP and AC requires a network connection a Local exterArea – Actuators (AC): These entities are used to control Network (LAN). data,etc. sensor context data as nal devices likeMultimedia heaters, light, well as other Internet services can use the same infrastrucToture. achieve a high reusability deployed Additionally, installation of costs for largehardware, buildings each will SCP and ACby requires a network connection to adata Local Area be reduced using wireless LAN. For sensor abstraction and (LAN). exchange, our conceptdata, applies a three layer data sensor Network Multimedia sensor context as context modelInternet as described in Table 1. the same infrastrucwell as other services can use sensor datainstallation (layer 0) iscosts directly by sensors ture.Raw Additionally, for gathered large buildings will provided without any data processing. Layer context beand reduced by using wireless LAN. For sensor data1 abstracdataand is derived from or more layers,a i.e. layer 0 and/or tion exchange, ourone concept applies three layer sensor layer 1.model The minimum requirement context as described in Table 1.for a SCP is to provide sensor contextdata data(layer of layer In the following Raw sensor 0) 0. is directly gathered subsection, by sensors more detailedwithout information on SCPs will be depicted. conand provided any data processing. Layer 1 In context trast, 2) use context i.e. datalayer from0layer 0, data is services derived (layer from one or sensor more layers, and/or 1 and 2 for their actual purpose. layer 1. The minimum requirement for a SCP is to provide sensor context data of layer 0. In the following subsection,

Adv. Radio Sci., 9, 231–235, 2011

www.adv-radio-sci.net/9/231/2011/

J. Schneider et al.: An efficient architecture for the integration of sensor and actuator networks 233 J. Schneider et al.: An Efficient Architecture for the Integration of Sensor and Actuator Networks into the Future Internet 3 Table 1. Three layer context model. Table 1. Three layer context model Context layer Context layer 0 0 1

1

2

2

DescriptionDescription sensor context Raw Raw sensor context data data without any processing without any processing Abstracted context Abstracted context data data withadditional additionalmeta metainformation information with Service-level abstraction Service-level abstraction

3.1 Provider (SCP) more Sensor detailedContext information on SCPs will be depicted. In contrast, services (layer 2) use sensor context data from layer 0, The Context Provider (SCP) can be seen as a sensor 1 andSensor 2 for their actual purpose. context source, since this entity is responsible for gathering 3.1 provisioning Sensor Context Provider (SCP) and raw sensor data. A SCP is not restricted to deliver only values of one sensor, rather most of these entities The provide Sensor Context Provider (SCP) can be seen as However, a sensor will a set of sensor values and parameters. context source, since this entity is responsible for gathering each SCP must be capable of supporting the respective bus andhardware provisioning raw sensor data. A SCP is not to or interface of its attached sensors andrestricted sensor netdeliver only values of one sensor, rather most of these entities works. For example, a sensor network can also be seen as provide a set of connected sensor values parameters. awill SCP and directly to and a gateway. For However, provisioneach SCP must be capable of supporting the respective bus ing of sensor data, we decided to use an indirect connection, or hardware interface of its attached sensors and sensor neti.e. a gateway is responsible for implementing an interface works. For a sensor cansolution also be provides seen as between theexample, Internet and each network SCP. This amore SCPflexibility, and directly connected to a gateway. For provisionsince sensor data processing is accomplished ingthe of gateway. sensor data, we decided to use an indirect connection, in i.e. a gateway is responsible for implementing an interface between the Internet and each SCP. This solution provides 3.2 Gateway more flexibility, since sensor data processing is accomplished in thegateway gateway. The implements an open interface for providing raw or abstracted sensor data to external services and applica3.2 Gateway tions via the Internet. By means of a standardized XMLderivative, different access rights, and security concepts, senThe gateway implements an open interface for providing raw sor data information can be reliably exchanged, taking prior abstracted sensor data to external services and applicavacy issues into account. Each gateway must provide the tions via the Internet. By means of a standardized XMLfollowing derivative,functionalities: different access rights, and security concepts, sensor– data information canattached be reliably exchanged, taking Registration of all sensor nodes with theirpricavacy pabilities issues into(available account. values, Each gateway must provide the accuracy, sensor location, following etc.) functionalities: – Registration of all attached sensor nodes with their ca– Detection of arrival and departure of sensors pabilities (available values, accuracy, sensor location, – etc.) Announcement and request of sensor values to the Sen-

sor Address node – Detection of Server arrival via andcorresponding departure of sensors Provision of sensor data (Context Layer 0) to the Sen–– Announcement and request of sensor values sor Address Server via corresponding node – Optional: sensor data processing to derive higher level context data (Context Layer 1) Layer 0) – Provision of sensor data (Context – Optional: sensor dataisprocessing to derive higher level A generic gateway model shown in 2. context data (Context 1) main functional blocks: The gateway can be splitLayer into three

– Data Acquisition Unit (DAU): This unit implements the hardware interface between sensors and gateway, and is responsible for acquiring raw sensor data from SCP(s). www.adv-radio-sci.net/9/231/2011/

Fig. model. Fig.2.2.Generic Genericgateway Gateway Model

A– generic gateway model shown in 2. complexity of this Data Processing Unitis(DPU): The Theunit gateway can be split into three main depends on the Context Layer. functional To provideblocks: layer 0 context, sensor data will only be formatted in an appli– Data Acquisition Unit (DAU): This unit implements the cable XML structure and delivered. In contrast, if layer hardware interface between sensors and gateway, and is 1 context can be requested, sensor context data will be responsible for acquiring raw sensor data from SCP(s). generated via combining and reasoning of current and previous sensor values. For this procedure, only – Data Processing Unit (DPU): The complexity ofsensor this data from the respective sensor network or SCP can be unit depends on the Context Layer. To provide layer Gateways cannot data from 0used. context, sensor data willrequest only besensor formatted in an other apgateways. that provide layerif 1 plicable XMLMoreover, structure gateways, and delivered. In contrast, context, can also provide their rawsensor sensorcontext data, used layer 1 context can be requested, datafor derivation of layer as layer 0 context.of curwill be generated via1 context, combining and reasoning rent and previous sensor values. For this procedure, – only Datasensor Delivery Unit the (DDU): The sensor DDU module data from respective network proor vides the interface between gateway and Internet, and SCP can be used. Gateways cannot request sensor data is responsible for registration SAS. Itthat implements from other gateways. Moreover,with gateways, provide a ”request/provide” as well as an asynchronous ”publayer 1 context, can also provide their raw sensor data, lish/subscribe” mode. control and sensor data used for derivation of layerBoth 1 context, as layer 0 context. have to pass this module. Moreover, it disposes of a – Data Delivery (DDU): The DDU module database withUnit all currently connected sensorsprovides and their the interface between gateway and Internet, and is remeta-information. Additionally, the DDU is responsisponsible for registration with SAS. It implements a ble for mapping and transferring a sensor data request “request/provide” as well as an asynchronous “pubto the according SCP and managing all sensor data sublish/subscribe” mode. Both control and sensor scriptions, taking access rights and privacy issuesdata into have to pass this module. Moreover, it disposes of a account. database with all currently connected sensors and their Additionally, 3.3 meta-information. Sensor Address Server (SAS) the DDU is responsible for mapping and transferring a sensor data request An important entity SCP is theand so-called Sensor Address to the according managing all sensor data Server sub(SAS). It is responsible for administrating a list of registered scriptions, taking access rights and privacy issues into gateways, and for coordinating and mediating sensor data account. requests. The SAS is implemented as a hierarchical, zone3.3 Sensor Address Server (SAS) oriented structure comparable to the Domain Name Service (DNS) (Mockapetris, 1987). It groups sensors and SCPs deAn important entity is the and so-called Sensor Address Server pending on their location allocates suitable sensor gate(SAS). It is responsible for administrating a list of registered ways to requests (e.g. by services). Fig. 3 shows the system gateways, and coordinating and mediating sensor datain structure of thefor SAS. A more detailed description is given requests. The SAS is implemented as a hierarchical, zone(Schneider, 2010). oriented structure comparable to the Domain Name Service At system start-up, each component in the network allocates a co-located SAS. Therefore, each client or gateway Adv. Radio Sci., 9, 231–235, 2011

234 J. Schneider et al.: An efficient architecture for the integration of sensor and actuator networks Architecture for for the the Integration Integration of of Sensor Sensor and and Actuator Actuator Networks Networksinto intothe theFuture FutureInternet Internet 4 J. Schneider et al.: An Efficient Architecture 4 J. Schneider et al.: An Efficient Architecture for the Integration of Sensor and Actuator Networks into the Future Internet

Fig.3.3.Structure StructureofofSensor SensorAddress AddressServer Server (SAS) Server(SAS). (SAS) Fig. Fig. 3. Structure of Sensor Address Server (SAS)

sends a(Mockapetris, ”getSAS” request to aItknown address. broadcast address. This (DNS) 1987). groupsbroadcast sensors and SCPsThis desends a ”getSAS” request to a known broadcast address. This address includes the current location of the client and a pathe client and a papending on their location and allocates suitable sensor gateaddress includes the current location of the client and a parameter ”mobile”, indicating whether the client is mobile or the client is mobile or ways to requests (e.g. by services). Figure 3 shows the sysrameter ”mobile”, indicating whether the client is mobile or not. In case of a mobile client, an appropriate SAS is choappropriate SAS is chotem structure of the SAS. A more detailed description is not. In of a tomobile client,position an appropriate SAS is sen with respect the current of To enof the the client. client. Tochoengiven in case (Schneider, 2010). sure an up-to-date allocation of the SAS, each mobile client sen with respect to the current position of the client. To enSAS, each mobile client At system start-up, each component in the network allohas to its announcement a certain interval. sure an up-to-date allocation of after the SAS, each mobile client certain time interval. cates a renew co-located SAS. Therefore, each clienttime or gateway With the allocation of a SAS to a client, sensor data can be has to renew its announcement after a certain time interval. sensor data can be sends a “getSAS” request to a known broadcast address. This announced to as well as requested from the SAS. This inWith the allocation of a SAS to a client, sensor data can be from the SAS. This inaddress includes the current location of the client and a pacludes sensor data andasmeta-information. announced to as well requested theEach SAS. This or inmeta-information. Each announcerameter “mobile”, indicating whetherfrom the client is announcemobile ment is valid for a certain time interval and has to be recludes sensor data and meta-information. Each announceinterval and has to be renot. In case of a mobile client, an appropriate SAS is chonewed. To ensure privacy issues, each SCP or gateway, rement is valid for a certain time interval and has to be reSCP or gateway, sen with respect to the current position of the client. To enspectively, choose between two different privacy modes. newed. To can ensure privacy issues, SCP gateway, redifferent privacy modes. sure an up-to-date allocation of theeach SAS, eachor mobile client In the ”private-mode”, advertised sensor information is respectively, can choose between two different privacy modes. sensor information is rehas to renew its announcement after a certain time interval. stricted to the zone-internal SAS.sensor Hence, sensor data can Hence, sensor data can In the ”private-mode”, advertised information is reWith the allocation of a SAS to a client, sensor data can be only be to requested inside the local (LAN). aa sub-network (LAN). If stricted theaszone-internal SAS. sub-network Hence, data If can announced to well as requested from thesensor SAS. This ingateway chooses the ”public-mode”, advertised sensor data advertised sensor data only be requested inside the local sub-network (LAN). If cludes sensor data and meta-information. Each announce-a is forwarded to antheappropriate SAS inadvertised the Internet. Hence, the Internet. gateway chooses ”public-mode”, ment is valid for a certain time interval and hassensor to Hence, be data resensor data and context, respectively, can be requested incan be requested inis forwarded to an appropriate SAS in the Internet. Hence, newed. To ensure privacy issues, each SCP or gateway, reside the sub-network as well as from the Internet (WAN). For Internet (WAN). For sensor data and context, respectively, can be requested inspectively, can choose between two different privacy modes. managing the dynamic IP addresses of the clients, aa mapper the clients, mapper side sub-network as advertised well as from the Internet (WAN). For In thethe“private-mode”, sensor information is reis used to assign the IP address to a fixed URL. Approprifixed URL. Approprimanaging the dynamic IP addresses of the clients, a mapper stricted to the zone-internal SAS. Hence, sensor data can management are e.g. DynDNS (dyndns, 2010), DynDNS (dyndns, 2010), isateused to assign services the IP address a fixed URL. Approprionly be requested inside the localtosub-network (LAN). If a 2myDNS (2mydns, 2010), no-IP (no-ip, 2010). A generic (no-ip, 2010). A generic ate management services are e.g. DynDNS (dyndns, 2010), gateway chooses the “public-mode”, advertised sensor data model of the system 2010), architecture is shown in 4. shown in 4. A Hence, (2mydns, no-IP generic is2myDNS forwarded to an appropriate SAS(no-ip, in the2010). Internet. model of the system architecture is shown in 4. sensor data and context, 3.4 (AC) 3.4 Actuators Actuators (AC) respectively, can be requested inside the sub-network as well as from the Internet (WAN). For 3.4 Actuators (AC) managing dynamic IP addresses of of thesmart clients, a mapper Actuators (ACs) execute commands control sysActuatorsthe (ACs) execute commands of smart control sysisActuators used to assign the IP address to a fixed URL. Appropritems, like alarm systems, for security or ambient assisted livtems, like alarm security or assistedsysliv(ACs)systems, execute for commands ofambient smart control ate management services are e.g. DynDNS (dyndns, 2010), ing, home automation, health care, etc. Each AC establishes ing, home automation, health care, etc. Each AC establishes tems, like alarm systems, for security or ambient assisted liv2myDNS 2010), no-IP 2010). A generic an for systems without bus/network caan interface interface for connecting connecting systems without bus/network caing, home(2mydns, automation, health care,(no-ip, etc. Each AC establishes model of the system architecture is shown in Fig. 4. pabilities. Fig. 5 shows a block diagram of an actuator inpabilities. Fig. 5 shows a block diagram of an actuator inan interface for connecting systems without bus/network cacluding examples for connected entities. cluding examples for connected entities. pabilities. Fig. 5 shows a block diagram of an actuator inActuators can execute Actuators can only only execute commands commands on request, request, where where cluding examples for connected entities. on two different classes of commands are possible: two different classes of commands are possible: Actuators can only execute commands on request, where two–– different classes of commands are possible: Action Actuator e.g. Action Command: Command: Actuator triggers triggers e.g. an an alarm. alarm.

– Action Command: Actuator triggers e.g. an alarm. Adv. Radio Sci., 9, 231–235, 2011

Fig. 4. Generic Model of the System Architecture Fig.4. 4.Generic Genericmodel Modelof ofthe thesystem Systemarchitecture. Architecture Fig. Fig. 4. Generic Model of the System Architecture

Fig. Fig. 5. 5. Actuator Actuator Block Block Diagram Diagram Fig. Fig.5.5.Actuator Actuatorblock Blockdiagram. Diagram

–– 3.4 –

Control Control Command: Command: Actuator Actuator receives receives aa control control comcommand from a service and replies with its current actuator mand from a service and replies with its current actuator Control Command: Actuator receives a control comActuators (AC) status message. status or an an error message. mand or from aerror service and replies with its current actuator status or an error message. Actuators (ACs) execute commands of smart control port sysAn triggers an An action action command command triggers an event eventon onthe theconnection connection port tems, like alarm systems, for security or ambient assisted livof actuator. Usually, these to of the actuator. Usually, these ports are connected to other other Anthe action command triggers anports eventare on connected the connection port ing, home automation, health care, etc. Each AC establishes entities like generator, roller blinds, etc. entities like alarm alarmUsually, generator, roller blinds, etc. of the actuator. these ports are connected to other an interface connecting systems withoutetc. bus/network caentities likefor alarm generator, roller blinds, pabilities. Figure 5 shows a block diagram of an actuator 3.5 Services 3.5 Services including examples for connected entities. 3.5 Services Services are the entities in With Services are can the controlling controlling entities inour ourarchitecture. architecture. With Actuators only execute commands on request, where the capability to request and subscribe for sensor data, as well the capability to request and subscribe for sensor data, as well Services are classes the controlling entitiesare in possible: our architecture. With two different of commands as to control actuators, they act as middleware. Logical funcas to control actuators, they act as middleware. Logical functhe capability to request and subscribe for sensor data, as well tions and will in tions such as as data datacombining combining andasreasoning reasoning willbe beapplied applied in as to such control actuators, they act middleware. Logical func– Action Command: Actuator triggers e.g. an alarm. these entities. As mentioned in section 2, Mannweiler (Manthese entities. As mentioned in section 2, Mannweiler (Mantions such as data combining and reasoning will be applied in nweiler, 2010) introduced aa design for aa distributed nweiler, 2010)As introduced design for 2, distributed service service these entities. mentioned in section Mannweiler (Manregistry. To extend this system to a distributed service arregistry. To extend this system to a distributed service arnweiler, 2010) introducedActuator a designreceives for a distributed – Control Command: a controlservice comchitecture, we include a privacy concept. Therefore, an adchitecture, we include a privacy concept. Therefore, an adregistry. extend this and system to with a distributed armandTo from a service replies its currentservice actuator ditional registry node isis the Area ditional registry nodemessage. added to toconcept. the Local Local Area Network Network chitecture, weaninclude a added privacy Therefore, an adstatus or error (LAN), registering services the (LAN), for registering alladded services inside the LAN. LAN. If aa serserditional for registry node all is to inside the Local Area If Network vice is marked as public, its registration gets forwarded to the vice is marked as public, its registration gets forwarded to the (LAN), for registering all services inside the LAN. If a serAn action command triggersnode, an event on the connection port public distributed registry located either in the same public distributed registry node, located either in the same vice is marked as public, its registration gets forwarded to the of thezone actuator. theseor are connected to other SAS as LAN’s SAS aalocated different SAS zone. SAS zone as the theUsually, LAN’s SAS orports different SASin zone. This public distributed registry node, either the This same entities like alarm generator, roller blinds, etc. concept allows the user to restrict services to the local subconcept allows the user to restrict services to the local SAS zone as the LAN’s SAS or a different SAS zone. subThis concept allows the user to restrict services to the local subwww.adv-radio-sci.net/9/231/2011/

J. Schneider et al.: An efficient architecture for the integration of sensor and actuator networks 3.5

Services

Services are the controlling entities in our architecture. With the capability to request and subscribe for sensor data, as well as to control actuators, they act as middleware. Logical functions such as data combining and reasoning will be applied in these entities. As mentioned in Sect. 2, Mannweiler (Mannweiler, 2010) introduced a design for a distributed service registry. To extend this system to a distributed service architecture, we include a privacy concept. Therefore, an additional registry node is added to the Local Area Network (LAN), for registering all services inside the LAN. If a service is marked as public, its registration gets forwarded to the public distributed registry node, located either in the same SAS zone as the LAN’s SAS or a different SAS zone. This concept allows the user to restrict services to the local subnetwork. If a user decides to make it public, the service registration is forwarded to the Wide Area Network’s (WAN) SAS. 4

Conclusions

This paper presented the design of a highly scalable and extensible solution for the integration of sensors and actuators into the future Internet, that overcomes the weakness of locally restricted sensor platforms or centralized sensor and actuator management architectures by means of open and standardized interfaces, and Sensor Address Servers. Further, privacy modes allow users to decide if their sensor data and/or services are available only for private or public use. In combination with security concepts, the proposed system architecture ensures reliable exchange of sensor data and metainformation for many important application areas, such as service adaptations in fixed and mobile environments, ambient assisted living, home automation, traffic management, as well as management of smart grids. Additionally, the partitioning into SCPs, gateways, services, and actuators allows for eased integration of new and rather low-cost components, since complex data processing and reasoning algorithms are shifted to service components. Thus, many components of the architecture, e.g. actuators and SCPs, can be constituted by mass market products. Furthermore, the use of the Internet as comprehensive transport medium ensures low installation costs, too. Therefore, these features will increase the attractiveness of the presented approach and hence the market acceptance. Future work will include three areas: First, implementation of a Sensor Address Server network and the introduced privacy concept. Second, combining of the SAS network and the Distributed Registry. Finally, large scale tests with a high number of sensors, actuators, and services with different privacy levels will be performed.

www.adv-radio-sci.net/9/231/2011/

235

Acknowledgements. This work has been supported by the Federal Ministry of Education and Research of the Federal Republic of Germany (Foerderkennzeichen 01 BK 0808, GLab; german-lab, 2010).The authors alone are responsible for the content of the paper.

References Wang, Q., Hempstead, M., and Yang, W.: A Realistic Power Consumption Model for Wireless Sensor Network Devices, SECON ’06 3th Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks, 2006. Emmert, B. and Staehle, D.: Impact of Energy Models on Energy Efficient Sensor Network Routing, University of W—rzburg, Institute of Computer Science, Technical Report No. 415, April 2007. Wang, Q. and Yang, W.: Energy Consumption Model for Power Management in Wireless Sensor Networks, SECON ’07 4th Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks, 2007. C-Cast Context Casting, http://www.ict-ccast.eu/, last access: March 2010. KNX Association, http://www.knx.org/, last access: Mai 2010. Z´uniga, M. and Krishnamachari, B.: Integrating Future Large-scale Wireless Sensor Networks with the Internet, USC Computer Science Technical Report CS 03-792, 2003. Mannweiler, C., Amann, B., Schneider, J., Klein, A., and Schotten, H. D.: A Distributed Context Service Architecture for Heterogeneous Radio Environments, ITG-Fachbericht der 15, ITG Fachtagung Mobilkommunikation, Osnabr¨uck, 2010. Schneider, J., Mannweiler, C., Klein, A., and Schotten, H. D.: Einbindung von Sensoren und Sensornetzwerken in das Future Internet, ITG-Fachbericht der 15. ITG Fachtagung Mobilkommunikation, Osnabr¨uck, 2010. Mockapetris, P.: Domain Names – Concepts and Facilities, IETF, RFC 1034, http://tools.ietf.org/rfc/rfc1034.txt, November 1987. Mockapetris, P.: Domain Names – Implementation and Specification, IETF, RFC 1035, http://tools.ietf.org/rfc/rfc1035.txt, November 1987. http://www.dyndns.com, last access: January 2010. http://www.2mydns.com, last access: January 2010. http://www.no-ip.com, last access: January 2010. http://www.german-lab.de, last access: January 2010.

Adv. Radio Sci., 9, 231–235, 2011