國
立
交
通
大
學
資訊科學與工程研究所
碩
士
論
文
為 DIY 使用者設計的家庭自動化平台
A Home Automation Platform for DIY User
研 究 生：熊家媛
指導教授：袁賢銘 教授
為 DIY 使用者設計的家庭自動化平台
A Home Automation Platform for DIY User研
究
生：熊家媛 Student：Chia-Yuan Hsiung
指導教授：袁賢銘 Advisor：Shyan-Ming Yuan
國 立 交 通 大 學
資 訊 科 學 與 工 程 研 究 所
碩 士 論 文
A ThesisSubmitted to Institute of Computer Science and Engineering College of Computer Science
National Chiao Tung University in partial Fulfillment of the Requirements
for the Degree of Master
in
Computer Science July 2009
Hsinchu, Taiwan, Republic of China
為 DIY 使用者設計的家庭自動化平台
研究生：熊家媛 指導教授：袁賢銘 國立交通大學資訊科學與工程研究所 摘要 「為 DIY 使用者設計的家庭自動化平台」，這是我所研究的主題。不同的電 子產品間往往有不同的廠商規格，彼此難以合作，但是本實驗室已完成的 MHAP(MOM-based Home Automation Platform)，則可以讓使用不同標準的產品間 順暢地溝通。根據這樣良好的基礎，我希望能發展一套服務訂做系統，幫助使用 者可以自由又快速的訂製想要的家庭或是辦公環境的自動化服務。透過建立一個 服務的庫藏，利用服務的仲介者(Service Matcher)在了解使用者所擁有的設備環 境後，自動產生適當的服務。並可以在設備環境有變化的時候，自動將服務變形 成為可以運行的模式。 本研究之成果為一個以家庭裝置環境設定導向的家庭自動化平台設計，稱之 為 MyHA(My Home Automation)。另透過問卷調查獲得受訪者對於家庭服務和智 慧型產品的看法，參考此結果設計一套可供 MyHA 使用者取用的家庭服務範本。 MyHA 中各種設定文件皆使用 XML 的格式，讓 MyHA 具有可攜性，並且讓使 用者間可以交流彼此對家庭服務的想法與設計，以期能進一步促進家庭自動化的 發展與普及。A Home Automation Platform for DIY User
Student：Chia-Yuan Hsiung Advisor：Shyan-Ming Yuan
Department of Computer Science National Chiao Tung University
Abstract
In this thesis I propose a home automation platform, which is design for Home Automation DIY users. As we all know, electronic devices produced by different manufacturers often operate under different specifications, as a result, it is difficult to make then work all together. Therefore, the DCSL has completed the MHAP (MOM-based Home Automation Platform), so that all the devices with different criteria would be able to communicate with one another seamlessly. Based on such a ideal foundation, I decided to develop a decision-making system, so that the users would be able to set up a desired home/office automation service efficiently.
In brief, after building up a treasury of services, a special service called the Service Matcher will be able to gather and analyze the information of the user's environment, and provide an ideal service automatically. Further more, the Service Matcher can transform the prior service into a new workable one. The main contribution of this research is design of a device-location oriented home automation platform, which is named as MyHA (My Home Automation.) Before I began to design this platform, I had survey a group of potential users about their opinions toward intelligent devices with my questionnaires. Besides, all the set-up documents of is written in XML format, so that MyHA is perfectly portable. The XML format also makes it possible for different users to exchange their opinion and idea of home automation, and ultimately contribute to the further development of smart homes.
Acknowledgements
The author is indebted to Dr. Shyan-Ming Yuan, his advisor, Mr. Chi-Huang Chiu, the candidates for Ph.D. of the Department of Computer Science, National Chiao-Tung University, Mr. Chun-Yuan Chen of Computer Science, National Chiao-Tung University, for their assistance and helpful comments in this research. The author especially thanks to Miss Ko-Chia, Chen for her assistance of the earlier drafts of the manuscript.
Table of Contents
摘要...i
Abstract... ii
Acknowledgements ... iii
Table of Contents ...iv
List of Figures... vii
List of Tables...ix
Chapter 1 Introduction...1
1.1 Motivation ...1
1.2 Objects and System Goals ...1
1.2.1 Device-Location Oriental Service Template ...2
1.2.2 Service Auto-Apply ...2
1.2.3 Service Auto-Recovery...3
1.3 Problems...3
1.4 Solution ...3
1.4.1 Device-Location Oriental Service Template ...3
1.4.2 Service Template Database...4
1.4.3 Service Matcher and Auto-Apply...4
Chapter 2 Background...5
2.1 Home Automation...5
2.2 HAMP ...5
2.3 XML Rule ...6
2.3.1 RuleML ...6
Chapter 3 Survey and System ...8
3.1 Survey ...8
3.3 MyHA System Scope ...12 3.3.1 Home Device ...13 3.3.2 Home User...13 3.3.3 Room ...14 3.3.4 Home Service...14 3.3.5 Virtual Device...16
3.3.6 The Service Creation Flow ...17
3.4 Location Information ...18
3.4.1 Floor Plans...18
3.5 Service Manager and Procedure Engine ...20
3.6 Home Service Templates ...21
3.7 Service Share Space ...21
3.8 System Parameters and System Service...21
Chapter 4 Descriptors...23
4.1 MyHA Descriptors Overview...23
4.2 Root Descriptor...23
4.3 Device Descriptor ...24
4.4 Room Model Descriptor...25
4.5 Home Service Template Descriptor...26
4.6 Event and Action Procedure Descriptor...28
Chapter 5 Home Services and Auto-Apply ...33
5.1 Home Service and Event/Action Procedure...33
5.2 Service Auto-Apply...37
5.2.1 Scenario...37
5.2.2 Service Matcher...39
5.2.3 Home Environment prerequisite ...40
5.2.4 The Criteria ...43
5.2.5 Compromise...44
5.3 Device Procedure checker...45
5.3.2 Logical Trap ...46 Chapter 6 Results ...47 6.1 Service Template ...47 6.1.1 Living Room ...47 6.1.2 Kitchen Work ...47 6.1.3 Home Secure...47 6.1.4 Home GIM...48 6.1.5 Long Vocation...48 6.1.6 Sweet Sleep ...48 6.1.7 Quick Morning ...48 6.1.8 Party Night ...49 6.1.9 Good Student ...49 6.1.10 Movie Time ...49 6.1.11 Dinnertime...49 6.1.12 House Keeping ...50 6.2 User Interface ...50 Chapter 7 Conclusion ...52 7.1 Contributions ...52
7.1.1 Cheep and quick solution for DIY user...52
7.1.2 Enhance Home Service Capability ...52
7.1.3 Service templates...53
7.2 Future Work...53
7.2.1 Device Function Management...53
7.2.2 User Behavior Learner...54
Bibliography ...55
List of Figures
Figure 3-1 MyHA on MHAP Architecture ... 11
Figure 3-2 MyHA System scope...12
Figure 3-3 Reliability requirement of Home Automation System...15
Figure 3-4 Reliability requirement of Home Automation System...17
Figure 3-5 A Example of floor plan in graphic view ...20
Figure 3-6 A Example of floor plan in tree structure ...20
Figure 4-1 The XML-based MyHA descriptors relationship map ...23
Figure 4-2 The XML-based MyHA descriptors relationship map ...24
Figure 4-3 An example of the device descriptor ...25
Figure 4-4 An example of the room model descriptor...26
Figure 4-5 An example of the home service template descriptor ...27
Figure 4-6 A draft of device’s event/action procedure...29
Figure 4-7 An example of the event procedure descriptor...29
Figure 4-8 An example of the event procedure descriptor for Sweet Dream service ..30
Figure 4-9 An example of the action procedure descriptor for Sweet Dream service .31 Figure 5-1 Service contains device procedure ...33
Figure 5-2 The process to provide a new service by filling up a form of procedure...34
Figure 5-3 Service and procedure - direct packet ...35
Figure 5-4 Service and procedure - double packet ...35
Figure 5-5 Procedures in side Service - direct packet...36
Figure 5-6 Procedure s in side Service – wrap by service ...37
Figure 5-7 The concept of Service Matcher...39
List of Tables
Table 3-1 The result of Intelligent home appliances purchase factors...9
Table 3-2 The result of the degree of interest in home services...10
Table 4-1 The time control tag description of event procedure ...32
Table 4-2 The time control tag description of action procedure ...32
Table 5-1 The role table of room in service ...41
Chapter 1 Introduction
1.1 Motivation
In the near future, there will be a lot cheep and smart home appliance in our home market. When customers need some new home appliance to replace their traditional stuffs, they can easily go into a shop store and bring some little digital controllable devices home. Surely they can online these new comers step by step follow instructions in the menu which comes along with the new comers and slowly try out all possible set up to let them cooperate with old smart guys, or we can provide some platform to make the whole process as easy as how customers pay for their new home servants.
Prior to my research, our lab has already established a platform called MHAP [1], which has made various kinds of electronic devices with different specifications able to communicate and work along with one another. Based on such a ideal foundation, I would like to build up a service-designing system, which can help its users to customize a desired home or office automation service. Briefly speaking, with a pre-built service library, the Service Matcher--which will be introduced thoroughly later in my thesis--will first detect what the devices in the specified environment are, and then it will automatically decide what the appropriate services are. Moreover, the Service Matcher will be able to detect the changes of the device environment and transform the service into a functional new service.
1.2 Objects and System Goals
DIY user, I was wondering what kind of home services that people would really want and how do people think about intelligent equipment and home automation.
Since most people do not have the experience of DIY their home automation, I turn to give thought to a similar case: personal computer DIY users. The reasons that end users choose to make their home automated by themselves may list like fallows: 1. Enjoy fun process. 2. Hold their home control power in their hands. 3. Save some money from manufactories and seller [2]. Not only the reasons looks similar to the why people DIY their personal computer and the drawback or so call “sweet burden” are also alike – have to figure out what the real needed and take the responsibility of maintains and repair. In fact, due to the bigger scale and multi equipment involved, the job is harder. As all other DIY user would faced, they have to take care over every trouble which sometimes pop up with no alarm, figure out where the error started, then correct it or cover it…It’s a nightmare to anyone who does not have a leisure life.
I want to design a system that can help normal people to enjoy their interesting, modern, easy and light financial burden smart home environment.
1.2.1 Device-Location Oriental Service Template
To release the end user’s burden from making up services gradually, a home system should provide user some templates that have deferent purpose and still are modifiable.
The template not only describes how service work and what device and environment it needs.
1.2.2 Service Auto-Apply
still have picked up services and decided what devices should work together for perform the job. A ideal system for DIY users give user a short cut to get what they want by ask some simple questions, like “if you want a light control service,” “how about a media control center?” or “Do you need whole package service for bedroom?” then select suitable services templates and turn them into real services.
1.2.3 Service Auto-Recovery
If some devices fail, the system will have the ability to fix the problem first without effecting the user’s daily life.
1.3 Problems
MHAP is a well-designed mom-based communication platform. Appliances of different protocols can communicate each other through the MHAP. It also implements an interface for users to make a rule-based service and it give home appliance a location-embedded identity. However, location information does not work more than as an identifier for service and users. The interface help users ordering a service, however, they still have to communicate appliances and start up the whole process by themselves.
1.4 Solution
Concern the problem that DIY users may face and the ability of MHAP, here are three ways to support the new system.
1.4.1 Device-Location Oriental Service Template
and rule description structure. By adjusting and adding some new attributes to descriptors to strengthen the influence of environmental factors in home service and improve the usability of home service.
1.4.2 Service Template Database
Provide a service template database to home system. These templates can give DIY users a foundation to start up a service and they are modifiable, user can change it into want they want. The database should be portable, and user can take it to where they go then rebuilt their home service by the templates.
1.4.3 Service Matcher and Auto-Apply
Provide a service matcher that recommend service template for DIY users. The service matcher evaluates the condition of both system and home environment, and proposes a list of service template. System then modified these services into user’s requirement and put them on service.
Chapter 2 Background
2.1 Home Automation
The original Home Automation (HA) means the device or appliance within the homes connects and collaborates with each other and links to services and systems outside the home to facilitate the human life. The HA system also known as smart home, which focus on localized technology augmented environments where people perform everyday life activities. This system contains internal network, intelligent rule and devices in the home network for convenient or some special purpose [3-6]. Devices with automation services and various appliances being controlled or providing state information.Besides, the change of a device’s state may also cause the change of another device’s state or trigger some action of another device in a HA environment[1].
Increasingly, HA system should dynamically reconfigure their services at run-time in response to changing conditions in the user actions, and in the surrounding physical environment. Self-configuration has been mainly applied to servers or networks systems. These systems are required to work without interruption, maintaining a certain quality of service. In order to do so, the system manages its resources for prioritizing certain services and maximizing the number of supported users. However, it is believable that HA can also take advantage of the self-configuring benefits [5-8].
In 2007, Chun-Yuan Chen proposes the MOM-based Home Automation Platform (MHAP), which accomplishes event-driven Home Automation in incompatible home networks. MHAP is independent of any home networking technology and integrates home networking technologies in home gateway. By involved Message Oriented Middleware (MOM) and Open Service Gateway Initiative (OSGi), MHAP provide reliable automatic operations, fault tolerant and reconfigurable Home Automation, which is also highly extensible. MHAP can team up appliances, other MHAP gateways and Internet services, for example, Web Services[1].
By constructed above HAMP, an application system can get rid off the trouble in physical level, such as device discovery, communicate with devices that belong to different protocols. We can ignore the device that bought by users are X10 [9], INSTEON [10], UPnP [11] or HAVi [12], and focus on solving users’ problems.
2.3 XML Rule
Rules in the Web have become a mainstream topic since inference rules were marked up for E-Commerce and were identified as a Design Issue of the Semantic Web, and since transformation rules were put to practice for document generation from a central XML repository (as used here). Rule-based systems are a relatively simple model that can be adapted to any number of problems. Even as in other systems it has its limitations, rule keeps playing an important role in AI shells for knowledge-based or expert systems and in Intelligent Agents[13, 14].
2.3.1 RuleML
The Rule Markup Initiative has taken steps towards defining a shared Rule Markup Language (RuleML), permitting both forward (bottom-up) and backward
(top-down) rules in XML for deduction, rewriting, and further inferential-transformational tasks. The initiative was launched in the Internet in the winter of 2000. Complementary efforts consist of the development of (Java-based) rule engines such as jDREW and Mandarax RuleML, as well as XSB-RDF RuleML. RuleML's earlier design evolved into DTDs-Schemas for positional-slotted RuleML sublanguages including Object-Oriented RuleML (OO RuleML). Efforts also went into defining MOF-RuleML: The Abstract Syntax of RuleML as a MOF Model.
The goal of the Rule Markup Initiative is to develop RuleML as the canonical Web language for rules using XML markup, formal semantics, and efficient implementations.
RuleML covers the entire rule spectrum, from derivation rules to transformation rules to reaction rules. RuleML can thus specify queries and inferences in Web ontologies, mappings between Web ontologies, and dynamic Web behaviors of workflows, services, and agents[15].
I design a new rule schema, which defines the devices event/action procedures in HA services, by referencing RuleML and the original rule design in HMAP. The further discussions are in the fallowing chapters.
Chapter 3 Survey and System
3.1 Survey
To understand and ensure the users' thoughts of environment and equipment for Home Automatic, we ran a questionnaire, which focus on people’s view on daily used smart equipment and automation environment, through internet and paper form in the fall of 2008. The survey comprised of three sets of questionnaires: concerning personal background, the use and perceptions of smart devices, and their opinion of possible Home Automation scenario.
This survey tried to ask people who would DIY their Home Automation in the future. Considering the case of personal computer DIY and the usual home decorating DIY, the most possible user should be the group who get used to the operating tools, target materials and feel interested with the topic. In our case, the tool is personal computer; the materials are the digital devices. So first, we focused on people who practiced computer operating, and then pondered that who might relish Home Automation. The DIY-able HA situation is coming but not now, the potential users are someone who are fond of new technology and going to have a controllable home area. Judging from these conditions, PTT Bulletin Board System, which is arguably the largest BBS in Taiwan, is a suitable platform to distribute questionary, due to its academic object and relatively young user groups [16-18].
The result is a collection of 136 people’s complete feedback. 71.32% of them were simply students and 22.49% got a full time or part time job, and most of them use computer, mobile phone, digital camera, PDA daily, and heavily (93.38%).
82.35% (112 people) interviewees dominate over a private room or house. The background data shows the participants in my survey are relatively young and quite practiced to operating digital and intelligent devices. The participants of this survey are the main users of smart equipment in the near future. The questionnaire is attached in the end of this report.
Take a look of the results, even they are highly computer users, only 40.44% people owns smart equipment, which dose not include computer, mobile phone, etc, and no mater they have these devices or not, 69.85% of them don’t use them frequently. The results may due to the occupation and economy status, they are students and would not pay a lot money on home equipments.
When the questions came to ”Without money issue, will you want to have some smart electronic daily necessities?”, 49.26% of them said “yes”, and the other half people(47.79%) want to take into account other factors. The other factors include functional integrity, interface, appearance, etc. shows in Table1-1:
Table 3-1 The result of Intelligent home appliances purchase factors
Q: Will the removal of price factors, the following factors will affect whether you decide to have smart electronic daily necessities?
Answer Count Percentage
Functional integrity 122 89.71% Interface 104 76.47% Appearance 84 61.76% Durability 94 69.12% Power Saving 66 48.53% Product specifications 28 20.59% Other 4 2.94%
Products’ appearance is count on device manufactures, and to the others, a Home Automation platform can do some fixing and supporting. HA platform can provide a universal controller service and give users a new interface. The platform can also
integrate devices’ functions, extend the life of devices, and saving power by controlling devices’ behavior. Software can solve most users’ concerns, this fact push us more forward on the way to design a HA platform for them.
Table 3-2 The result of the degree of interest in home services
Q: The following is a list of catalogs of different purposes of home automation services, please select the item you are interested in:
Answer Count Percentage
Living in Living Room 90 66.18%
Long Vacation 116 85.29% Home GYM 48 35.29% Quick Morning 96 70.59% Dinning Time 54 39.71% Good Student 74 54.41% Sweet Dream 120 88.24% Bath Time 87 63.97% Party Night 51 37.50% None 2 1.47%
The question in Table 3-2 tried to understand what kinds of HA services are more interesting to users. Services in this question are catalog by purposes and scenarios not the type of involved device. These titles accompany with short descriptions can give interviewees a larger space to imagine what these services can bring to them. The result shows the most popular two are Sweet Dream and Long Vacation. Therefore, the flowing discussion will use these two as examples.
Figure 3-1 MyHA on MHAP Architecture
In Chapter 2, I have introduced the original system architecture of HAMP. To achieve the system’s goal, I designed an application and named it “MyHA”, which is short form of “My Home Automation”. In figure3-1, you can see the modified architecture layer. MyHA lies in the application layer with its plus one—Service Template Database. Inside MyHA, there are the Service Matcher, Home Service Manager and an interface for end users to communicate with MyHA. The Service Matcher performs the most important function of MyHA, it connects the home environment and home service. Service Matcher also carries out the service Service Auto-Recovery by cooperates with the Device Management Service in MHAP Service Layer. The working detail of Service Matcher will be described in Chapter 4.
There is a little modification in MHAP Service Layer that the original Rule Engine has been changed to Procedure Engine. The reason for this change is the rules in MyHA or HHAP do not have the ability to conduct a new principle or results, they just point out what situation of devices’ states would course some services asking
O Oppeenn SSeerrvviiccee GGaatteewwaayy IInniittiiaattiivvee M MOOMM SSeerrvviiccee C Coonnffiigguurraattiioonn S Seerrvviicceess R Ruullee EEnnggiinnee MaMannaDDeagevgeviemiccemee enntt S Seerrvviiccee A Addaappttoorrss ExExtteennssiioonn S Seerrvviicceess A Addmmiinniissttrraattiioonn T Tooooll R Ruullee ccoonnffiigguurraattiioonn T Teerrmmiinnaall A Apppplliiaannccee M Moonniittoorr U Unniivveerrssaall C Coonnttrroolllleerr P PhhyyssiiccaallDDeevviiccee a annddNNeettwwoorrkk S Seerrvviiccee M Maannaaggeemmeenntt&& D Deeppllooyymmeenntt M MHHAAPPSSeerrvviiccee L Laayyeerr A Apppplliiccaattiioonn L Laayyeerr M MyyHHAA S Seerrvviiccee M Maattcchh M Maakkeerr H Hoommee S Seerrvviiccee M Maannaaggeerr M MyyHHAA U Usseerr I Inntteerrffaaccee S Seerrvviiccee T Teemmppllaattee D Daattaabbaassee P Prroocceedduurree E Ennggiinnee
some specific device to perform some actions. Thus, device event/action procedures became the real service behavior descriptors.
3.3 MyHA System Scope
Room Device User Service Service Service Service Service Service User Service
MHAP
Figure 3-2 MyHA System scope
Figure 3-2 is the top-view of MyHA and the environment. The base is MHAP and the white area is MyHA.
First of all, let’s see what entities are in this system, know what is performed in side this system and what should it to deal with. From the design view, we can define these entities as four categories: device, user, room and service.
In MyHA, users are service owner and more importantly, they are part of event creators. MyHA do not treat users as the central of the system as some other home automation system [19, 20], but the users’ home environment plays the significant role. This frame of reference can delight the system burden and simplify system structure, and still can fit DIY users’ requirements. As we abstract users as event
S Seerrvviiccee T Teemmppllaattee D Daattaabbaassee
M
M
y
y
H
H
A
A
Room Room Device Room Devicecreators, the system can be more flexible and users can exchange home service more easily[21-23].
3.3.1 Home Device
In MyHA system, a device is a household appliance, which routines household tasks, using electricity or some other energy input. Many home networking technologies[24] have developed such as UPnP, HAVi, X10, INSTEON, Jini[25] and LonWorks[26], they give appliances connection ability.
3.3.2 Home User
A home user is someone who is involved in the Home Automation System. They can be a power user who apply their requirements to the system and define how Service will work or just enjoy the services.
I classify Users according to their authority and duty into four types:
1. Chef Manager: A chef manager manages and defines the whole system. Besides of the service made up, he/she also can set up the devices, person data, room information and the connection to the out side system.
2. Power User: They are end-user but own some privilege to make up their user-demanded services.
3. Bon Vivant (Normal User): some one who needn’t worry about how the System works and just take the advantage from the Service. (A Bon Vivant can order some exist service in System.)
4. Guest: Sometimes a guest is our boss, sometimes we just don’t want he/she get too close to our daily live. By using some simple identifier devices e.g. a finger print identifier, system can prevent a guest from crush into our bedroom but he/she can also use warm water in washing room in a cold cold wintertime.
Except for the Guest users, all users need ID/PW.
3.3.3 Room
Room is an area unit, the devices or services will work in it.
In the original HAMP design, system uses the room information as part of message topic and Region division to offer a Reliable Fault Tolerant Home Automation. I want to give room a more individual character, make the room data or we say the location information more useful for user demanded service.
3.3.4 Home Service
In the original design of MHAP, the service describes the functions that device can provide. In my design , the new service descriptors are divided into two kinds：1. Basic service descriptor; 2. Home service descriptor.
Home service performs a particular job. The service is provided according to the home users’ demands or it is just an inner function using by the system and completed by a serial device works.
Grow Up Direct go New Born Stand-By Hold Retire Ready Repair On-Work Set up In System Dead
Figure 3-3 Reliability requirement of Home Automation System
A service will be given birth when an Appliance is plug on the system or a user want to create an on-demanded Service. At the first case, the Basic Service of that Appliance will be created by system automatically and immediately go through the Grow Up state to Ready .More over, by default setting, an On-Line Appliance its basic functions are also on-line, thus the Service is set to be on Stand-By state. When it comes to the second case, the Service will not change its state to Ready until the User completed the Set-up process
These states filled by gray are Mutual Services. A Mutual Service means that it has ability to work.
A Service at mutual state has fallowing attributes: 1. Application List
2. Event/Action procedure 3. User
Once a Service became a Ready Service, it will go to the Stand-by state or just be holding until the user call it up to Stand-by state. Even the Ready state looks like a
temporary state; only pass Ready state a service can start its career. A service on Hold state will not work, but it is still under system control, and Users and System can change and watch its content. If a user wants to change the setting of a service, or the system thinks a service need to be adjusted because of some devices or services in the system were changed and that may affect the Service working, the Service setting can be repaired and sent to Repair State. Once the repair is done, the Service goes to Ready state and moves to Stand-By or Hold state again.
A Service can retire when the System or users think it no longer usable. At this state, the System will not maintain the data of service. If users want some Services go back to working, those Services have to go Repair state first. Users can announce a Retire Service to be Dead state, and this service will be deleted form the System forever and ever.
3.3.5 Virtual Device
A Virtual Device is actually a Service. Two or more Appliances accomplish the Action part of this kind Service. Users can set a service, which is in mutual state, as a virtual device. A virtual device has a device descriptor as a real device.
When a service is in mutual state, users can define it as a virtual device and service will make a device descriptor for this virtual device。
One benefits of virtual device is that user can maintain this virtual device through universal device interface. Users can easily maintain their favorite Services. Further more, once a service became a virtual device, other services can operate it directly.
3.3.6 The Service Creation Flow
1. User proposes a Service demand. 2. Create the corresponding procedure. 3. Run down the Procedure Checker.
4. Subscribe the event( check out the correct express) 5. Mark up Time event.
6. Finish Service creation.
Make a Service 1
Submit rule express 2
Result 4
7 Subscribe Device Event 8 Subscribe Time Event Service Creation Success
9
5 Result
Rule Engine
User MOM Service Time Center
Send test rule. 3
Rule checker Service center
3.4 Location Information
3.4.1 Floor Plans
The Floor Plan provides system the information of devices’ location and, more importantly, describes room-device relation. Floor Plan is able to help the system to complete automatic information matching. By processing the location information provided by Floor Plan, we can set up the default service, which is mainly defined by the location of the room; it can also provide the grouping function. Besides, every time when a device or even an environment alteration occurred, we can use the prior Floor Plan as a base to maintain the consistence and continuity of the service. The further discussion is in Chapter 5.
A floor is simply a container. A floor contains all other kinds’ elements of environment. User can set a floor “above” or “under” other floors.
Room corresponding to the physical room in users’ home environment, is surrounding by walls or identified by how users use it, therefore, a large space, in the settings can be divided into several different rooms. This setting is set in accordance with the users’ habits, so to a big dining room, which includes oven and cookers, can be set as one room or a dining room and a kitchen is up to users’ free will. A room can own devices and other rooms. User’s can set a room “next to” another room.
There are some default room models in system. For example, bedroom, toilet, living room, bathroom, hallway, etc. The followings are some special room type:
1. Entrance
An entrance, which contains a door, a gate or nothing but simply an open space, can be view as a room or a special pace in this home system. Entrance can own
devices, like electrical gate, drape, door ring, etc. It is differ from an ordinary room by the ability to connecting two independent rooms. If we view an entrance as a room, then the “next to” attribute represent where we can get by it. Since a room definition can tell the meaning of an entrance, an entrance can be set as a room.
2. Window
Window is similar to an entrance, thus I set windows as type of room. 3. Stair
Stair can also own some device, and it is a room, too. However, when it said a stair “next to” floors, it meant thst the stair is ascending or descending to these floors.
4. Open space
It is a room without walls and specifies the undefined area of house. For example, there are no doors or walls in between doorway and living room, then user can defined this blur space as an open space.
5. Out space: It defined the space out of users’ domain and it’s surrounding users’ other rooms. Rooms “next to” out space, tell system that they are in the edge of users’ home environment. Moreover, it is still a kind of rooms.
If users do not have a lot sensors in their home environment [27], Floor Plan can also set for completing environment information [28], basically, if users did not set down a quality relations room map, it will not affect the implementation of the system, but some default service that from service template database may not be able to apply. Total empty floor planes will constraints the functions of service automatically apply. User can manage appliances by room. The device procedures of services can be grouped by room. Room group can apply the procedure template.
<Out space> <Floor1> <Living Room> <Dinning Room> <Bedroom> <Kitchen> <Toilet> <Bathroom> <Stair> <Floor2> <Hallway> <Window> <Window> <FloorG> <Stair> <Home>
Figure 3-5 A Example of floor plan in graphic view
<Floor2>
<Bathroom> <NextTo> <NextTo> <Hallway> <Stair><Floor1>
<FloorG>
<Entrance> <Garage> <Stair> <Dinning Room> <NextTo> <Out Space> <NextTo> <Bedroom> <Window> <Kitchen> <Living Room>
Figure 3-6 A Example of floor plan in tree structure
In the original version, Rule (procedure) Engine is the conductor for the device operation. One the miss part of the original MHAP is the Service management. Rule (procedure) engine charges the logical analyze and create logical command. However, it is Service Manager to provide the event problem and command words to Rule (procedure) Engine.
3.6 Home Service Templates
A service description with its procedure and uses dummy devices ID to represent unknown employee devices. In a service template, it allows no real device as action and event provider, but a real exist device spec. in the ID tag, using the device type code.
Users can create their own service templates, as home device manufactories and sales can provide service templates alone with their products.
3.7 Service Share Space
Build up service template database on internet. This database collections service templates witch provided by manufactories, home automation organizations, and home users.
3.8 System Parameters and System Service
Service Parameters are applicable system-wide parameters and give service some cognitive messages from users. For example, the cool / hot temperature, the wake up time, and the loud volume, etc.
keeps all required time event, include the time be notice and the name of the subscriber when the time comes up, it throws a time event with the subscriber data to MOM.
Some devices do not have timer themselves. By using a system service Timer, system approves time events of routine jobs. Timer maintains the system clock. It also keeps the time event from procedure.
Chapter 4
Descriptors
4.1 MyHA Descriptors Overview
MyHA uses the MHAP descriptors design as a foundation; descriptors provide profiles of the entities inside MyHA. The MHAP descriptors are the guideline of device abstract and protocol mapping. MyHA retained the original design of mapping descriptor and basic service descriptor, but added some additional and modified some descriptors.
MyHA promises users that they can carry their home service setup with them when they move or change their home environment. At the same time, MyHA want to encourage users to share their home automation set up with other MyHA users. For these reasons, all the descriptors in MyHA are made up in XML format.
Index to 0,1 1 n n Index to Device descriptor n 1 Service descriptor Mapping descriptor
Index to sub device n
1
Home Service descriptor
n n
Index to
Event Procedure descriptor
Action Procedure descriptor
n Index to n Index to Index to n Index to n
Figure 4-1 The XML-based MyHA descriptors relationship map
Describe the system environment. For each system, there is only one root. <?xml version="1.0" ?> <root> <specVersion> <major>1</major> <minor>0</minor> </specVersion>
<systemID></SystemI>// systemID = the fixed IP address <friendlyName> </friendlyName>
<userDescription></userDescription> <modelName>Home</modelName> <geoInformation>
<lat></ lat>// Lat = latitude <lon></ lon>// Lon = longitude </geoInformation>
</root >
Figure 4-2 The XML-based MyHA descriptors relationship map
4.3 Device Descriptor
In the original system, each MHAP device has a root device descriptor which indexes to the sub devices and services. Therefore, the device can be two or more types of standard device simultaneously through the hierarchical architecture. In my design, the new schema will keep this structure.
The part of Action Mapping is also keep as the original design. My improvement is focus on the service contraction and the enhancement of the procedure expression.
<serviceType>urn:schemas-UPnP-org:service:power:1</serviceType> <serviceId>urn:schemas-UPnP-org:serviceId:power:1</serviceId> <SCPDURL>/service/power/description.xml </SCPDURL> </basicService> </basicServiceList> </D i > <basicService> <basicServiceList> <geoInformation> </geoInformation> <availableArea> </availableArea> <coordinates><x></x><y></y> </coordinates></location> <room>0000</room><location> <userDescription>Timer</userDescription> <UDN>uuid:Smarthome2001X10</UDN> <serialNumber>9999999999</serialNumber> <modelName>Timer</modelName> <manufacturer>Smarthome</manufacturer> <friendlyName>Home Timer</friendlyName> <deviceType>urn:schemas-UPnP-org:device:Timer:1</deviceType> </specVersion> <minor>0</minor> <major>1</major> <specVersion> <Device type="sigle">
Figure 4-3 An example of the device descriptor
4.4 Room Model Descriptor
The room model descriptor gives end users a direction to contribute their own house
</RoomModels> </RoomModel> <DeviceList></DeviceList> <RoomDescp>臥房</RoomDescp> <RoomModelName>Bedroom</RoomModelName> <ChildOf>Room</ChildOf> <RoomModel> </RoomModel> <DeviceList></DeviceList> <RoomDescp>廁所</RoomDescp> <RoomModelName>Toilet</RoomModelName> <RoomModel> </RoomModel> <DeviceList></DeviceList> <RoomDescp>一般房間</RoomDescp> <RoomModelName>Room</RoomModelName> <ParentOf>Bedroom</ParentOf> <RoomModel> <DeviceList></DeviceList> </RoomModel> <RoomDescp>整個使用空間</RoomDescp> <RoomModelName>Home</RoomModelName> <RoomModel> <RoomModels>
Figure 4-4 An example of the room model descriptor
4.5 Home Service Template Descriptor
The service descriptor play the role as the original design-- it describes those simple actions a device can perform without other devices. Home service descriptor contains the service that ordered by user. It can be as simple as the basic action but the most important function of this descriptor is to keep enough information about the user demanded service to ensure the system can running these complicated service as user expect.
</serviceModel>
<geoInformation> //globle </geoInformation> </involved_rules> </actionRule> <actionDevices><actionDevice ruleDeviceCode="A">B</actionDevice></actionDevices> <ruleID>ar00002</ruleID>//turn A off <actionRule role="leading" > </eventRule>
<eventDevices> <eventDevice ruleDeviceCode="A">D</eventDevice> </eventDevices> <ruleID>er00009</ruleID>//if Time 23:00~6:00
<eventRule role="leading"> </eventRule>
<eventDevices> <eventDevice ruleDeviceCode="A">A</eventDevice> </eventDevices> <ruleID>er00010</ruleID>//if A off on off
<eventRule role="leading"> <involved_rules>
</actionDevices>
<device_ID role="supporting" score="3" correspondID="C" >1234567895</device_ID></device> <device type="single"><deviceModel>Television</deviceModel><room>R0</room>
<device_ID role="leading" score="10" correspondID="B" >1234567891</device_ID></device> <device type="single"><deviceModel>Light</deviceModel><room>R1</room>
<actionDevices> </eventDevices> </device>
<device_ID role="system" score="0" correspondID="D"> </device_ID> <deviceModel>Timer</deviceModel> <room>R2</room>
<device type="single">
<device_ID role="leading" score="10" correspondID="A" deviceType=""></device_ID></device> <deviceModel>Light</deviceModel> <room>R0</room>
<device type="single"> <eventDevices>
</availableArea> </room>
<room> <roomCorrespondID>R2</roomCorrespondID><roomModel role="none">Home</roomModel> </room>
<room><roomCorrespondID>R1</roomCorrespondID> <roomModel role="none">LivingRoom</roomModel> </room>
<room> <roomCorrespondID>R0</roomCorrespondID><roomModel role="main">Bedroom</roomModel> <availableArea> <serviceTag>0007</serviceTag> <userList/> <userDescription></userDescription> <friendlyName>Sweet Dream</friendlyName> <serviceModelID>sm0003</serviceModelID> <serviceModel>
Figure 4-5 An example of the home service template descriptor
HyMA classify home service by some service features, e.g. location, purpose, involved device, and uses these categories on service auto-apply .User can add these information by themselves.
I classified service by how they work and what function it controlled.
devices crack, system keep some u-be choices. User can indicate substitute for event or action devices, if the main devices went out of work, system pick up the double.
Furthermore, user can set substitute procedure for services, if the devices failure caused the involved procedure totally disability, service can apply the appointed one to fill the vacant position.
More over, in service descriptions we give each event a role to show how these devices affect the service.
4.6 Event and Action Procedure Descriptor
What is procedure? For end users, they order Service, however, the communications between Appliances are through the system core-union -Service Engine, therefore all the entities outside core-union they use service-view and inside the core-union use procedures to describe Service and control Service acting.
Procedure s are Hieratical and the condition judgment in procedure should be time sensitive. Some services may ask events to happen in order or some services do not care about the happening sequence. This kind property should be show in the service procedure.
Procedure is just a form, and the Service will fill it. A procedure consists of event and action part. To enhance the reusability and flexibility, I decide to manage and store event and action parts separately.
By observation my daily life, I simplified what the actions a normal people would do to their home devices into the set in upper one; then I switch the on/off into up/down, higher/lower… or some specific functions like recording and deleting…then we get several similar procedures sets in the lower one:
1. Turn A’s function A1’s Parameter AP1 up 2. Turn A’s function A1’s Parameter AP1 down
3. Turn A’s function A1’s Parameter AP1 up, then turn off B’s function B1’s Parameter BP1 down
4. Turn A’s function A1’s Parameter AP1 up, then turn off B’s function B1’s Parameter BP1 up
5. Turn A’s function A1’s Parameter AP1 down, then turn off B’s function B1’s Parameter BP1 down
6. Turn A’s function A1’s Parameter AP1 down, then turn off B’s function B1’s Parameter BP1 up
7. It’s the time, then …(1~6)
Figure 4-6 A draft of device’s event/action procedure
Here I show how the basic procedure 4 looks like:
<event>
<if type="and"> <timesing waitingTime="30">0</timesing> //the unit is second and 30 secs is the basic time zone <var> <targetID>A</targetID> <varName>Power</varName> <acceptList > <acceptValue type="Solic">true</acceptValue> </acceptList> </var> </if> </event>
</eventRule> </event> </if> </var> </acceptList> <acceptValue type="Solic">off</acceptValue> <acceptList > <varName>Power</varName> <targetID>A</targetID> <var> </var> </acceptList> <acceptValue type="Solic">true</acceptValue> <acceptList > <varName>Power</varName> <targetID>A</targetID> <var> </var> </acceptList> <acceptValue type="Solic">fail</acceptValue> <acceptList > <varName>Power</varName> <targetID>A</targetID>
<waitingTime>10</waitingTime>//the unit is second <var>
<timesing>1</timesing> <if type="and">
<event> //a rule has one event
<ruleCapture>IF some device off on off</ruleCapture> <rulegroupID>rg0001</rulegroupID>
<eventRule ID="er00010" NAME="IF_4">
</actionRule> </action> </reaction> <argumentValue>true</argumentValue> <argumentName>Lock</argumentName> <actionName>Lock</actionName> <BasicServiceName>Lock</BasicServiceName> <commandTarget>A</commandTarget> <reaction> <timesing>0</timesing> <action> <ruleCapture> A</ruleCapture>
<actionRule ID="ar00005" NAME="Gate_1"> </actionRule> </action> </reaction> <argumentValue>fall</argumentValue> <argumentName>setPower</argumentName> <actionName>Power</actionName> <BasicServiceName>Power</BasicServiceName> <commandTarget>A</commandTarget> <reaction> <timesing>0</timesing> <action> <ruleCapture>A off</ruleCapture>
<actionRule ID="ar00002" NAME="BasicControl_2">
Figure 4-9 An example of the action procedure descriptor for Sweet Dream service
This is a simple procedure has one event message and one action command. Each <var> is a query to a single device’s single and I use <and> to capsulate the single event, and if the service needs more than one event message, <and> can capsulate these events. Surly, <or> can work for its situation too.
When there are multi event message, here comes a new problem—the timing control. Event messages are sent by devices and cause by human operating and the
different sequences may mean different intentions. For example, turn down the light in toilet then open one in the hallway, can indicate a move from toilet to hallway; a reverse sequence can not cause by the same move. On the other hand, the order can mean nothing but the time slot may do. Quick open and shut down the same light can be a signal of starting some services, same behavior but happened in 5 minutes may just means you leaved and came back to the same place.
Table 4-1 The time control tag description of event procedure
Event
Tag Description
TIMESING= 0 The event does not care about the sequence and time range of
event.
TIMESING= 1 The fallowing Query responses have to be accepted in order;
otherwise the action will not be triggered.
TIMESING= 2 This event repeats in a time range.
WAITINGTIME if TIMESING= 1 How long the service can wait the
next event happened. The time unit is second.
if TIMESING= 2 The time range
TIMEORDER if TIMESING = 1 indicate the sequence of the event.
Table 4-2 The time control tag description of action procedure
Tag Description Action
TIMESING= 0 All the reactions occur at the same time and the order is not
strict.
Chapter 5 Home Services and
Auto-Apply
5.1 Home Service and Event/Action Procedure
In this chapter, I will explain the relationship of service and device procedure in the system.
We already know that device procedure is a guideline that tells us how things going, in tradition, device procedure describes the admit behavior of specific objects, it may under some circumstantial condition or not. In this home automation system, I try to separate the target object and the behavior into different parts. This graph shows the main idea:
Service
Name: Gate Way Control
User: Manger
Location: floor1……
Content: Rule( device1, device2) Procedure
Figure 5-1 Service contains device procedure
In this point of view, services are just like packages for procedure. Like all those productions we buy in the convenient stores, a package, here is the service, has to explain the name of this product, the inside compositions, and the notable situation, etc. Our service marks up information, such like its purposes, its target users, its suitable location, etc. In addition, the most important parts-- the involved procedure and those devices that the procedure hire.
The benefits gained from this layout including:
1. In home application, there are many cases that one service just performs a similar action under similar situation to some other services. The little differences between these services is where the location them occur or what devices perform the jobs.” When TV volume up, higher the door ring volume” is just the same kind operation as “When the sound system volume up then louder the phone ring tone” In fact, we can even separate event procedure and action procedure into different parts. This will discuss in next section.
2. Faster Service auto apply: In the very beginning of system setup, system already has some template procedure.
From the other point of view, the procedure is a form, a playbook for service, and a service is the one who knows which devices will play which position.
Name: Birthday: Address: Phone: Procedure Procedure
Name: Damon Coxon Birthday: 2/16/1969 Address: Longbrige House,4th
F,,Room L4 , University Way, London Phone: 801+137+954 Service Maker SERVICE Service Manager
Procedure is an empty form. When user or system wants a new service, the service maker fills up the space in rule. After service maker finished its work, service manager registers the content as a new service.
Figure 5-2 The process to provide a new service by filling up a form of procedure
To fill up the form of a procedure correctly, a service needs efficient number of vent devices and action devices.
Now, consider the service- procedure index question. Service performs a serious and complicate action for user. Sometimes, there is no casual relation between those
actions and we still want them team as a service. In this case, a service should contain more than one procedure.
In addition, here is a different consideration: we want some back up procedure, in case some bad thing happened to the involved procedure. As we do to the devices in procedure, service involved extra one or more procedures as the substitute. Therefore, the main procedure and substitutes have similar behavior.
A service can contain more than one procedure:
Service A
P 1
P3
Involved Rule: R1( device1, device2), R2(device3, device4)R3(device5, device6, device7)
Location: Living Room User: family
Name: TV Service
P2
Direct Packet
Figure 5-3 Service and procedure - direct packet
Alternatively, if I force every procedure to be wrapped by a service, the situation will be like this:
P3 P1 P2 Service C Service B Service D Service A
Sub Service: Service B, Service C, Service D
Location: Living Room User: family
Name: TV Service
Double Packet
Figure 5-4 Service and procedure - double packet
information on service in double packet case is smaller in the second one.
To identify Service, System uses service ID and users use service name, and friendly description that are made by end user. However, the service ID and that information defined by user cannot quickly tell system what is the purpose of a service.
The role tag in <serviceType> of such service is noted as “container”.
The double packet structure can surly make the service description much simpler and clearer than the naked one.
Assume that I let the first one alive. Here comes the further problem: Can procedure act other procedure or just other service?
The goal of the system is to be as flexible as possible to carry every thing that user desire to come true in an easy way. Procedure design is the key point to realize this.
The first adaptation is to allow procedure s hiring existing procedure and other controllable object in the system. Controllable objects including devices, location data, user data, service and procedure.
Plan A: A procedure directly nominates other procedures, that means all the stuffs involved in every procedures are packaged by the only one service,
Service A
P2 P3
Name: Home GYM Service
User: family
Location: Bedroom, Living Room… P 1
Involved Rule: R1( device1, device2), R2(device3, device4)R3(device5, device6, device7)
so all the materials contain in those stuffs have to be memo on the only one package, in the situation which is showed above, that would be service A to record all the devices used by R1, R2 and R3.
Plan B: A procedure cannot directly include procedure; procedure can only hire a service. Service A P2 P3 Service B Service C P1
Involved Rule: R1( device1, device2)
Location: Bedroom, Living Room User: family
Name: Home GYM Service
Figure 5-6 Procedure s in side Service – wrap by service
A service just keeps the information of devices for the procedure in the top level. To know the information of devices in the inner service, the system digs deeper to look up the inner service descriptions. Both ways are available. I think the second way is more consistent with the basic design of the whole architecture.
5.2 Service Auto-Apply
Assume the system already has a rich service model database, the situation of MyHA is just like a baseball scouts or a model agent. There are punch talent player, who suit the team needs perfectly and can the team give the player a satisfactory treatment? A matchmaker can do this puzzle for you!
5.2.1 Scenario
1. When you Move
You keep most home devices, and take them to your new house. At the same time, you throw some old equipments and some devices you just do not like or need them anymore. You also buy some new furniture and interesting toys. The layout of rooms in new house may different to before one, however, in general case, you may not change the composition of equipments in each rooms.
Thus, in your new bedroom, beside a bed, some closets, etc, you still have a nightstand, a sound system, wireless phone and a mosquito killer. Although, there is a little bit difference -- you got a brand new and powerful air conditioner, which can not only control air temperature, but also combine humidistat and ozone air cleaner, that replaces the traditional one in old house. At the same time, you still want to enjoy those comfortable services you have made when you lived in the old house; of course, plus some new fancy little trick. To have them from starting at the head is not a bad solution. It is fun. You can stew your brain and pop up some great idea than those old one you made in old house. However, moving is a hard job, adjust stuff to its right place is troubled and exhausted. Let MyHA carry your original idea to the new but still familiar environment.
2. When you buy a new toy
Tommy bought a new shower system this Friday afternoon. This new babe can make a babble bath and modulate spa pool, it with digital controller for water temperature and volume. Gina will be very happy about this surprise. After a crazy Friday night working in restaurant, she always says that she want a comfortable weekend spa with relaxing music and mild light effect. Tommy just set up the system when Gina came home. Can he finish the setting of the bath program ASAP to give Gina a surprise?
5.2.2 Service Matcher
Service Matcher is responsible for service auto-apply service. It is under the service manager. It picks out service templates for users and evaluates the capability of home environment, finally makes services and home devices work together. Service Matcher dose not just measure the services’ capability, but also evaluate User’s Home environment. That is the reason why the first step of Auto-apply process is called the Matching.
<ServiceTag Service Template <Device> Home Environment Service Matcher <Room>
Figure 5-7 The concept of Service Matcher
Matching Service survey the condition of both side, then give a possible services and devices list to users. What gave out alone the list are some suggestions. Service Matcher will throw out the information, which would help user to decide service is more workable and what devices should be lunched.
1. devices scanning
Based on the discovery service of MHAP, system can capture device movement. When a new device is inserted or an old device is removed, Service Matcher will
search for services that contain the same kind of devices.
2. choose Service
System owns a service template database. Users can select several service template modules from service share spaces and put them into their home service modules database. This service module base is the foundation of auto applies procedure.
Here I discuss how the home system finds out a propriety service for user from the home-service-module databases.
At the very beginning, users provide the big direction of service. Chose the wanted service module is the first picking. This occurs at the install procedure and any other time users want to change the setup of their home database. The second time that users release their desire to system is now--when the home auto applies getting star, users can (or not) claim some purposes of new services. E.g. House keeping, light control, etc. Base on these conditions, system stars the picking.
3. Pick up candidate service templates
By using some system recognizable tabs and user readable descriptions (<serviceType>, <friendlyName> and <userDescription>) that stored in service descriptions as searching key, Service Matcher combs out some service templates as users desired services from service template database. These service templates are candidates of services. System evaluates the candidates by what devices type they need and where they work.
5.2.3 Home Environment prerequisite
The evaluation starts from location requirement to devices.
1. Location prerequisite
A service may perform in one room or distribute in several rooms in different floor, and service can specified these rooms have to be a bedroom, living room or it
does not care.
For example, one a light opened in living room can express different thing from another light lighting in a bathroom, so it is necessarily needed to mark up service room type.
Furthermore, in some cases of multiple room services, the relationship among rooms is the key factor of service performance, which gives service a significant reason to note the room relationship prerequisite.
To note the relationship between rooms, first, service has to mark up the room, which the main action or main event take placed. Using the main room as a base, service can describe the relationship between main room and other rooms .Here is the room-relationship tag list:
Table 5-1 The role table of room in service
Role Description
<Main> The Room contains the main event or action device.
For each Service has only one main room.
<Next> This room is next to the main room.
<Belong> This room is contained by the main room.
<Up> This room is in the upper floor and right above the
main room.
<Down> This room is in the lower floor and right under the
main room.
<none> Service does not care the relationship between this
room and main room.
To make sure the services after applied are executable by home system, Service Matcher compares devices that already in the system and devices required by services.
Using those devices claimed by service template as searching key, searching through home environment. If no device fits the requirement, mark it as missing.
The perfect situation is all the devices fit the original presupposition. System already got every devices involved in the chosen service template, and all their types,
functionalities and locations satisfy the service’s requirements.
2. Device Restriction
If some devices, in the found device set, are disqualifying in some criteria, Service Matcher evaluates if this situation would damage the service performance. Here I list the points that devices may loose their scores:
1) Location
Two X10 lamps, one is in the living room, and the other one is in study hall. They are definitely with different purposes. Thus Service Matcher has to make sure
2) Type
3) Functionality:
A similar but worse situation, if there are some absent devices, it absolutely made a set lose score. Even though, it doesn’t mean this device set cannot work for user.
Now consider how Service Matcher evaluates found devices.
Even Service Matcher does want a perfect match, however, more frequently, it comes up some drawback and a restrict requirement would lead to nothing available. Therefore, when a device set is not perfect, Service Matcher will try to tolerate or fix it.
The main gate to decide if a service can be carry on is the importance of the problem devices. In every service description, Service Manager sticks a role tag and a weight attribute on each device, which involved in every service. A main actor is the most important device in a service. A main actor's responses or reactions will determine that whether a service is success or fall into failure.
A main event device is similar to main actor. If the event cannot send out from main event device, the service won’t be trigger. Here is the device role list:
Table 5-2 The role table of device in service
