From our observation, numerous home appliances are easy to be operated, even by old people, but others are not. The difference between these operations is that several operations are quite common even over different appliances. For example, almost all appliances have power buttons to switch them on or off. It is quite easy to turn an appliance on by pressing the power button even it is a new kind of appliance that you never see it before. Another example is that it is easy to change the volume of TV by pressing the volume up and volume down buttons on the remote control. If you know how to change volume of TV, it is quite easy to learn how to change volume of an amplifier or any voice-related appliance providing volume up and volume down buttons. Many people, especially old people, feel frustrated if the operations of new devices are totally different with the old ones which they already familiar with. Computer is an example of device providing uncommon operations. Except the power on operation, nothing is similar to traditional controls of appliances; therefore many old people are afraid of using computers.
On the basis of our observation, we attempt to identify certain common operations between different appliances, or within the same category of appliance. We believe that common operations not only provide an understandable interface to users, but also provide a high level of abstraction of control. For example, a command “turn off all devices at the second floor”
can be created for power saving if all devices support the operation of “turn off”. However, not all devices are the same; several devices, such as multi-purpose washing machines, are valuable because they provide multiple, usually uncommon operations. Another issue is that operations which are not common may become common in the future; therefore, the definition of common operations must be extendable.
16
Furthermore, this thesis used the idea of common operations to design the definition of automation process. Since no common process definition exists for home automation until now, we attempt to identify the pattern of common requirements in smart home environment.
A trade-off also exists between simplicity and capability of process definition; if too many factors are included, the system may frustrate users, but if too little factors are included, some scenarios may not able to be expressed. Finally, the issues of semantic, unambiguous, and user-controllable process definition which are already discussed in Section 2 are also crucial to be addressed.
3.1 System Assumptions
On the basis of the scope of this thesis and the analysis of design issues, several assumptions for USHAS are defined as follows:
a. All the devices to be controlled have been deployed to users’ home environments. For example, lights have been connected to X.10 modules for USHAS to control.
b. Manufactures or third-party driver providers can provide device drivers which are implemented as Web Services and follow the driver standard of USHAS.
c. Operations are more understandable if they are common operations.
d. Automation processes are more understandable if semantic concepts are included.
e. Automation processes are more understandable if they are defined under a common process pattern.
3.2 System Overview
17
As discussed in Section 1 and 2, USHAS adopts the Web Service technology for exposing services provided by drivers, WSBPEL technology for execution level process definition, Semantic Web technology for knowledge base construction, and a semantic process definition language, SHPL, for semantic process definition. The conceptual stack of USHAS is shown in Fig. 3-1.
Figure 3-1. Conceptual stack of USHAS
Traditionally, devices can be controlled by two kinds of execution paradigms of smart home:
user-controlled execution and event-driven execution. In the proposed system, user-controlled device execution is easily achieved simply by invoking the services provided by device drivers; therefore, this thesis focused on event-driven execution. Layers of conceptual stack are introduced as follows:
18
a. Device Layer
Two categories of device are designed: sensor and actuator. Sensors collect environment information, and actuators enforce executions based on commands coming from users or automation systems. In USHAS, both sensor and actuator style devices are encapsulated by device drivers following the Web Service standard.
b. Notification Layer
Traditionally, some kinds of agent are designed for receiving sensing data generated by sensors. For example, images captured by cameras are analyzed, and then a face-detected event is generated if someone appears in front of the camera. USHAS adopts the Publish/Subscribe [44] paradigm for publishing events and notifying subscribers based on pre-defined topics, since that Pub/Sub systems are usually employed for event management [45-46].
c. Service Query Layer and Process Layer
Since USHAS follows the Web Service standard for service description, it adopts UDDI for service query. Also, USHAS uses the WSBPEL as the execution level process definition language, and a WSBPEL runtime for process execution.
d. Semantic Notification Layer
Some semantic events such as NoOneAtHomeEvent are defined in this layer. Except explicitly defined events, we found that the concept of semantic event handling is quite
19
similar to the concept of semantic process execution; semantic events can be mapped to pre-conditions of semantic process, and semantic event handling can be mapped to what must be executed in the body of semantic process. Therefore, the semantic notification layer not only handles explicitly defined events, but also includes pre-condition checking before semantic process execution.
e. Semantic Service Query and Semantic Process Layer
Although OWL-S is not abstract enough for semantic process definition, it is mature for describing and querying services of Web Services. Since USHAS uses OWL as the ontology for knowledge base construction, the OWL-S is adopted for semantic service query. Moreover, semantic process is defined in SHPL, which is described in the next section.
f. Management Layer
One of the main goals of USHAS is user-configurable semantic process design; therefore, a management layer for users to create semantic processes must be provided. Also, since home environment differs from user to user, there must be an interface provided for users to define the ontology of their home environments.
20