2.1 Smart Home and Home Automation
Smart homes and home automation are popular topics, referring to devices and appliances in the home environment that can be controlled automatically in an intelligent manner. Thus far, numerous studies have proposed system designs and even smart home products [1-4]. In smart home systems, devices and appliances are usually controlled to facilitate the duties of daily life. Home automation systems generally contain an internal network, as well as intelligent rules and devices in the home network for convenient or special purposes.
Devices and appliances can be controlled automatically by, or provide environmental information to, these home automation systems. In addition, changing the state of a device may also change the state of another device, or trigger actions in other devices within the smart home environment [6].
2.2 SOA and OSGi-Based Smart Home
Before defining a high level of logic for automation processes, the most crucial challenge is to facilitate the interconnectivity between different devices. Due to highly varied standards for home devices, such as X10 [20], INSTEON [21], UPnP [22], and Jini [23], communication between different devices is difficult to establish using dissimilar interfaces under various standards. For such heterogeneous network integration, the Service-Oriented Architecture (SOA) [14] design principle provides interoperability between various loosely coupled services. Open Services Gateway initiative (OSGi) [15] is one of the technologies that implement the SOA paradigm, and numerous researchers have implemented smart home
8
systems based on OSGi. Li et al. [24] designed a home network system, providing a Web interface for users to control appliances directly on the OSGi platform. Ishikawa et al. [25]
proposed SENCHA, a smart appliance integration middleware framework based on OSGi.
They indicated several limitations of OSGi in implementing smart home automation, such as the lack of multiple views of abstraction levels. In other words, the capability of multilevel abstraction of OSGi is not enough. Wu et al. [1] combined the OSGi platform with mobile agents [26] in their design, which involves multiple mobile agents responsible for different tasks, distributed among multiple OSGi platforms. Liao et al. [8] adopted the Message-Oriented Middleware (MOM) [27] paradigm for event handling in their context-aware smart home system. Rui et al. [9] presented a physical structure model and a multi-agent [28] based software architecture based on OSGi; this architecture encapsulated the device sensing as well as control operations into the AmI-Adaptor, and encapsulated the computation logic into the AmI-Box.
The primary problem of OSGi is that only bundles installed on the same OSGi container can inter-communicate. Therefore, technologies such as mobile agents in [1] must be designed to establish communication between different containers. Another problem of OSGi is that no standard process definition is provided. Hence, in the OSGi based systems, high level device control decisions are usually made by multi-agents and pre-defined by programmers. As a result, automation processes are fixed and not allowed to be configured by users. Although the system designed in [9] provides the capability of user configuration to AmI systems, the configuration level is at the AmI-Adaptor and AmI-Box levels, not at the process level; users must select and configure which AmI-Adaptor or AmI-Box to communicate.
9
2.3 Web Service, WSBPEL, and Web Service Based Home Automation
Web Service [16] is another technology that implements the concept of SOA, consisting of three main standards: Web Services Description Language (WSDL) [29], Simple Object Access Protocol (SOAP) [30], and Universal Description, Discovery and Integration (UDDI) [31]. Similar to OSGi, Web Service provides interoperability between different services;
therefore, it is also a candidate for smart home platforms. Uribarren et al. [32] proposed a middleware system based on Web Service for controlling devices with different protocols.
Unlike OSGi, a process execution standard, Web Services Business Process Execution Language (WSBPEL) [17], is designed to support process definition for executing Web Services. Because devices are usually provided by different manufacturers, the concept of device functionalities can be mapped to services provided by enterprises; and the concept of process execution using different devices can be mapped to cross-business process execution, including different enterprises. Anke et al. [33] revealed the drawback of OSGi: OSGi bundles are not directly accessible from clients outside of the OSGi container. To solve this problem, Anke et al. designed a system that exposes OSGi bundles using Web Service interfaces, and then executes these bundles using processes defined in WSBPEL. However, using both OSGi and Web Service involves a duplicate design, because both of them follow the SOA paradigm. Systems supporting WSBPEL process definition and execution can adopt device drivers directly implemented by Web Service, instead of by OSGi bundles, to reduce system overhead.
10
2.4 Semantic Web, Context-Aware Home, OWL-S, and Semantic Home Automation
Although WSBPEL is already a higher layer of both Web Service and OSGi, it is still difficult for users to write a WSBPEL document directly by themselves; many details of static binding, such as portTypes or URLs of services, must still be provided. To enable communication based on semantic ontology between different programs across the boundaries of different organizations, Semantic Web [34] technology is designed on the basis of Resource Description Framework (RDF) [35] and Web Ontology Language (OWL) [18]. In general, Semantic Web technology is usually used for context-aware home automation systems. Wang et al. [36] designed the CONON ontology for context reasoning in pervasive computing environments, including home environments. Moreover, several reasoning engines, such as OWL-QL [37], have been developed for understanding semantic meanings of OWL, and can be highly useful in semantic home systems. For example, if Light L is located in the living room, and the living room is located on the first floor, then the query “all the lights on the first floor” can identify Light L. Furthermore, OWL-S [19] extends the capability of OWL to describe the operations of Web Service and semantic process execution of these operations.
Mokhtar et al. [38] developed a QoS-aware dynamic service composition mechanism in ambient intelligence environments, using OWL-S for service description and process definition.
Although OWL-S is based on Semantic Web, it is still not abstract enough for users to express high-level concepts of processes, such as “I want to turn off all the lights on the second floor”.
Necessary semantic processes should still be defined explicitly by OWL-S. Given a dynamic home environment, for example, after installing a new light on the second floor, the OWL-S
11
process should be modified to meet the requirements of using that light. Ha et al. [10]
proposed an infrastructure for a ubiquitous home network service, adopting numerous technologies such as Web Service, WSBPEL, and OWL-S. Moreover, they designed a high level semantic process definition. Processes based on this definition are interpreted to WSBPEL processes dynamically according to the current home environment. However, the proposed semantic process definition language is too simplified, and not user-configurable.
Based on Semantic Web, situation-driven approaches [39-41] provide a higher level of semantic process automation abstraction. The concepts of situation, user goals, and broker goals are proposed so that Web Services can be controlled to fulfill brokers’ goals, which further fulfill user goals based on particular situations. Users or experts can control process actions by providing various situational parameters. In the smart home domain, the concept of situations can be mapped to the home environment, such as the lighting, current time, and status of appliances. Although users can control the processes by adjusting the situations, the process definitions, or the user goals, should also be pre-defined. In other words, users cannot create their own customized automation processes.
2.5 User-Configurable Smart Home
Rodden et al. [42] used the idea of Jigsaw to compose abstract processes for smart home automation. For example, a doorbell piece fitting a webcam piece, which then fits a mobile phone piece, implies that when the doorbell rings, the webcam takes a picture and sends this image to the user’s mobile phone. This is a compelling idea because it seems highly simple and user friendly. However, this simple representation causes many ambiguity problems. First, the item definitions are ambiguous; if ten lamps are in a house, there must be a manner to
12
distinguish them. Identifying each piece merely using the Jigsaw interface is difficult.
Determining how users can define and reconfigure their home automation systems in an understandable manner is crucial. In addition, several abstract concepts, such as “no one is home”, are not easily represented; all possible abstract concepts must be defined as pieces before using them. Second, the process definition is ambiguous; the manner in which operations should be executed is not defined. If every item is treated as the same type of piece, three pieces of webcams concatenated one-by-one is possible; however, the meaning of this process is not understandable. Finally, arguments of operations cannot be defined. For example, “turn on the air conditioner if the temperature is higher than 30 oC” cannot be defined because the number 30 cannot be assigned. Moreover, only one precondition piece is allowed to be defined in a process in this system. A trade-off exists between usability and unambiguity; a user interface design that is too simplified is not always understandable to users.
Drey et al. [43] proposed a taxonomy-driven approach to visually prototyping pervasive computing applications, including those of smart homes. This system allows users to create their own semantic automation processes, or rules, based on the sensor-controller-actuator development paradigm. Furthermore, they support the concept of “all” when defining rules using the symbol “*” after entity class names. However, the meaning of “*” differs between the sensor and actuator sides; using “*” on the sensor side implies “any one instance of this category”, but implies “all of the instances of this category” on the actuator side. The ambiguous design of “*” may confuse users when designing processes. Moreover, this system supports the concept of clock time only, and concepts of repeated time, such as every day or every weekend, are not supported.
13
2.6 Mobile Web content adaptation
Mobile content adaptation is a significant issue when browsing Web sites on mobile devices.
In general, Web pages are designed for PC users with large screens. Therefore, when users browse these Web pages on small-screen mobile devices, the display results are usually unsatisfactory. Many mobile content adaptation technologies were designed to solve this problem. The challenges of mobile content adaptation include different device profiles and user preferences. Moreover, since mobile devices do not usually have computation capabilities as powerful as those of PCs, only certain multimedia formats are supported for multimedia content.
In general, there are three categories of mobile content adaptation architecture: client-based application adaptation, client-server application adaptation, and proxy-based application adaptation. In client-based adaptation, client-side application performs content transcoding according to the profile of the mobile device. However, user preferences must be stored locally on devices, and the weak computing power of the mobile device may decrease efficiency. In server-side adaptation, the server generates or prepares different versions of content and decides what type of content should be delivered to clients according to their profiles. The problem is that server-side programs must be modified to support different types of clients; adapted content for mobile users is not available if the server does not support them.
In proxy-based adaptation, content is transcoded on the fly during delivery from server to client; this can solve the problems of client-side and server-side adaptation architectures.
However, in certain cases, such as SSL-encrypted communications, Web content can neither be modified nor adapted during transmission between clients and servers.
14
One client-based application adaptation technology is Opera’s Small-Screen RenderingTM in Opera’s mobile Web browser. This technology intelligently reformats Web pages to fit the width of screen on mobile devices, thereby eliminating the need for horizontal scrolling. Only the layout of page is changed; all the Web content remains. Another example of client-based application adaption is the Smart-Fit Rendering technology in ACCESS NetFront. Similar to Opera’s Small-Screen Rendering, Smart-Fit Rendering also renders Web pages to fit the narrow screen width of mobile devices.
The main difference between client-server application adaptation and proxy-based application adaptation is whether the content provider or third-party service provider is responsible for conducting the adaptation. Therefore, many adaptation systems can either be deployed server-side or proxy-side. Chen et al. proposed a mobile content adaptation system, which can be either a server-side or a proxy-side architecture. Their system separates a large page into several regions, and creates a minified image as an index page; if any region on the index page is selected, the user is redirected to another page that only displays the content of the selected region.
15