Multiobjective (MO) optimization is an emerging field which is increasingly being encountered in many fields globally. Various metaheuristic techniques such as differential evolution (DE), genetic algorithm (GA), gravitational search algorithm (GSA), and particle swarm optimization (PSO) have been used in conjunction with scalarization techniques such as weighted sum approach and the normal-boundary intersection (NBI) method to solve MO problems. Nevertheless, many challenges still arise especially when dealing with problems with multiple objectives . In addition, problems with extensive computational overhead emerge when dealing with hybrid algorithms. This paper discusses these issues by proposing an alternative framework that utilizes algorithmic concepts related to the problem structure for generating efficient and effective algorithms. This paper proposes a framework to generate new high-performance algorithms with minimal computational overhead for MO optimization. However, it is difficult in some instances to incorporate all the aspects of the problem into a single objective function. Thus, a good way to go about incorporating multiple aspects is by defining multiple objectives and including them into the problem formulation. A mathematical representation of a multiobjective (MO) problem is as follows:In recent times, many concerns have been raised when dealing with emerging technologies in industrial and engineering optimization which present themselves in a multiobjective (MO) setting –5. Some In MO optimization problems, determining the most efficient solution set can be a very daunting process. Many varieties of concepts (such as diversity and convergence) have been proposed in the past . These iThe only concept that can be used generally for the overall ranking of solution sets is the idea of “Pareto dominance” . The hypOver the past years, metaheuristic techniques have been applied with increasing frequency to industrial MO optimization problems. Some of the most effective metaheuristic techniques are the ones that spring from evolutionary and swarms approaches. One such evolutionary approach is the genetic algorithm (GA), introduced by Holland in the nineties . GAs belOne of the most popular swarm-based optimization approaches is the particle swarm optimization (PSO) algorithm. This optimization method was developed based on the movement and intelligence of swarms. PSO was developed by Kennedy and Eberhart  in 1995.In a nutshell, currently MO optimization is done with the aid of metaheuristic algorithms, scalarization techniques, and nondominated Pareto optimal solution tracing. Besides, metric analysis is also employed to gauge the quality of the solutions obtained by any given algorithm. This paper aims to propose a philosophical framework that uses the information from metric analysis to generate high-performance and computationally efficient algorithms that produce high-quality solutions for MO optimization problems.This paper is organized as follows: This section provides a review on various research works on the applications of MO optimization techniques ranging from general industrial applications and power systems to chemical processes. Over the past years, MO optimization has been introduced and applied into many real-world industrial scale problems. Some of these developments are presented in From previous research works presented in In the last ten to fifteen years, many industrial processes are seen from the MO optimization standpoint. In most cases, these processes are modelled with two or less objectives see –38). In . In 38])Subsequently many methods for Pareto frontier construction have been proposed in the past see , 9). How. How9]).Another issue is the philosophy of hybridization. Algorithm hybridization is a good approach to enhance the performance of any given algorithm see , 40). Ho. Ho40]).Over the past years, performance metrics have been used to gauge the quality of solution sets produced by algorithms for MO problems , 43. TheHence, performance metrics have been used extensively in gauging solution quality. However, is it possible to further improve or modify an algorithm based on the assessment results produced by the performance metrics on a particular solution set? Secondly, if such a modification is possible, how does one go about using this information produced by the performance metrics? Assuming the answer to the first question is yes, then to answer the second question the information produced by the performance metrics need to be identified and classified. For this classification, the Hierarchy Axiom is postulated. Nevertheless, to increase the strength of this axiom an attempt is made to construct it from the “No Free Lunch (NFL) Theorems ”.As observed in the NFL Theorems' , algoritTo keep things clear, let this “structure of the problem” be defined as “problem morphology.” Assuming that in MO scenarios, the problem morphology can be attained by analyzing the solution sets produced by a given algorithm. The results of this analysis can be obtained by the performance metrics. Thus, it can be stated that the results produced by performance metrics could be used to characterise and understand the problem morphology.It is crucial to note that the definition of problem morphology introduced here is not the same as problem characteristics. Problem characteristic in an optimization context usually means the degree nonlinearity, the degree of nonconvexity, number of constraints, number of variables, and so forth. for a given problem. This sort of problem characteristics is commonly determined by observations done on the optimization problem formulation. “Problem morphology” on the other hand is used in this work to define the information which is numerically attained (results from the performance metrics) for the solution set of a given MO optimization problem. Hence, this distinguishes the “problem characteristics” from “problem morphology.” Although we have now established some logical connection between the problem morphology and the results produced by the performance metric, one question remains. How do we classify and use the information of the problem morphology to improve our algorithms? To attempt to answer this question, we now develop a formal postulate of the Hierarchical Axiom. In this argument, let us limit the number of metrics to three; say the convergence, diversity metrics, and the HVI. It is understood that the HVI gives us the degree of dominance of the solution sets, which in other words is our ultimate goal. The convergence and diversity metrics produces results that may be considered secondary to our ultimate goal. Since the results produced by all these metrics are from the same solution set, hence they must be connected in some unknown mathematical sense. Hence, our ultimate goal (solution set dominance) is influenced by the diversity and convergence metrics in an unknown manner. This unknown relationship would vary from problem to problem. This is due to the fact that the problem morphology also varies depending on the problem. This work proposes that by analysing the problem morphology by using the Hierarchy Axiom as a stepping point, this unknown relationship may be known.The hierarchy of priorities such that the degree of diversity and convergence of the solution sets directly influence the degree of dominance (measured by the HVI) is postulated. A hierarchical diagram representing this assumption is shown in The summary of the ideas proposed thus far is that, performance metrics does not only measure the algorithm's performance, but due to the NFL theorems, they also measure the structure of the objective space. Thus, it can be said that performance metrics also describes the problem morphology of any given MO problem.Since algorithms and problems are connected as described by the NFL theorems, the method to measure the problem morphology  is done by analyzing the solution set produced by any particular algorithm when tackling an MO optimization problem. Therefore, by testing a solution sets produced by a series of algorithms on a given MO problem using performance metrics, the problem morphology may be ascertained. In this work, the problem morphology includes the degree of convergence and diversity of the solution sets that depict the approximate Pareto frontier. As in most MO problems, the primary or critical solution quality here is defined by the degree of dominance of each solution set , 45. TheIn the spirit of this philosophy, a framework of a solution method is proposed in this work to obtain the approximate Pareto frontier for MO problems. First, a given problem is solved by using a series of metaheuristic methods. The degree of diversity, convergence, and HVI values is measured for all the approximate Pareto frontiers using performance metrics. Under the “Hierarchical Axiom,” the degree of convergence and diversity influences the degree of dominance. Thus, the influence of the convergence and the diversity metric values with respect to the HVI values of the approximate Pareto frontiers is analyzed. Next, the algorithm with the highest HVI value is identified. This algorithm is then improved based on the analysis done on the degree of convergence and diversity and their influence on the degree of dominance.At this juncture, the concept of “surgery on algorithms” is further explained by employing an example. By obtaining the results that describe the problem morphology, the characteristic of the solution set  can be known. For instance, consider a scenario where a particular problem was tested with two algorithms, say Algorithms A and B. Algorithm A has produced a higher HVI value as compared to Algorithm B. In the sense of problem morphology, the solution set produced by Algorithm A is less diverse but more convergent compared to Algorithm B see .Hence, from the problem morphology standpoint, it can be stated that the degree of convergence influences the degree of dominance of the solution sets. This is due to the fact that Algorithm A is more dominant than B and has a higher degree of convergence. It is known from the Hierarchy Axiom that the problem morphology influences the degree of dominance. Therefore, it is possible to increase the degree of convergence of the solution sets hence directly affecting the degree dominance of those solutions by augmenting or modifying the algorithms. This kind of augmentation is defined in this work as “surgery on algorithms.” By performing surgery on Algorithm A, a new algorithm (say Algorithm C) would be generated that produces more convergent and more dominant solutions see .Since it has already been established from , the conIt should be noted that the surgery on algorithms procedure is proposed in conjunction with the complete framework of the analysis of problem morphology and its consequent arguments and axioms. As opposed to hybridization, surgery on algorithms merely removes, adds, or modifies components in the algorithm based on the problem morphology. Therefore, the complexity of the algorithm does not increase radically and hence maintains its computational efficiency to a certain degree. However, hybridization often merges two whole algorithms into one. By doing so the complexity of the algorithms undergoes radical increment and this affects the computational efficiency of hybrid algorithms. Besides, by hybridizing algorithms, there is no guarantee that the hybrid algorithm produced may outweigh the results of its predecessors in their original form. These are the problems that may be addressed by employing the philosophical framework proposed in this work.In this section, some definitions and axioms are presented in formalized mathematical forms. These forms are the foundation for the proposed framework put forth in this paper.Aj be a MO algorithm, and let M be a MO problem. The set yi is defined as a set of decision variables to the problem M. The algorithm, Aj, operates on the set yi and generates a set xij ∈ Pj such that xij is a set of optimal points that construct the Pareto frontier Pj:i ∈  denotes the number of optimal points and m is the maximal number of optimal points. The index j ∈  denotes the individual solution set produced by algorithm j(Aj) and n is the maximum number of algorithms applied.Let xij ∈ Pj to a positive-definite real-valued scalar, cj, dj ∈ ℜ+. Let ∑ be the convergence metric, and let δ be the diversity metric such thatj ∈  and for all i ∈ .The convergence and diversity metrics behave as an operator that maps the points in the solution sets, xij ∈ Pj, to a positive-definite real-valued scalar, domj ∈ ℜ+ where domj is the degree of dominance. This mapping is given as follows:The hypervolume indicator (HVI) denoted Hyp maps the points in the solution sets, Pj and Pj+1 be two solution sets. If and only if cj > cj+1, then the solution set Pj is more convergent than Pj+1. If and only if cj > cj+1, then the solution set Pj+1 is more convergent than Pj.Let Pj and Pj+1 be two solution sets. If and only if dj > dj+1, then the solution set Pj is more diverse than Pj+1. If and only if dj > dj+1, then the solution set Pj+1 is more diverse than Pj.Let Pj and Pj+1 be two solution sets. If and only if domj > domj+1, then the solution set Pj is more dominant than Pj+1. If and only if dj > dj+1, then the solution set Pj+1 is more dominant than Pj.Let M, let Pj be some solution sets produced by a mapping by Aj. Then, the values cj and dj influence the values domj and not vice versa.For any problem The problem morphology is then defined as follows.M, let Pj be some solution sets produced by a mapping by Aj. Then, the known values cj, dj, and domj ∈ ℜ+ and their possible relationships are described as the “problem morphology.”For any problem M, let Pj be some solution sets produced by a mapping by Aj. Then the mappings by the metric operators, ∑,  δ, and Hyp can be described as in the graph diagram in For any problem f and g, describe the relationship between the degree of diversity and convergence with respect to the degree of dominance. The following relationships between the relations and the operators may be obtained as follows:Thus, the unknown relations, M, the solution set Pj is produced numerically by some algorithm, Aj. Thus, the performance of an algorithm, Aj, varies depending on the problem M. Therefore, f and g themselves which describe the problem morphology vary from problem to problem and cannot be obtained analytically. By implication, the problem morphology itself can only be obtained numerically by executing some algorithm Aj on a problem, M, and getting some solution set Pj.For any given problem M, the solution set, Pj, is produced numerically by some algorithm, Aj. The solution set, Pj, produced by Aj has diversity and convergence values that can be computed using the ∑ and δ operators. There exist components η and ξ such that when incorporated into some algorithm, Aj, these components increase the diversity and convergence values of its solutions.For any MO optimization problem Aj, be applied to some problem, M. The ∑, δ, and Hyp operators are applied to obtain the problem morphology. From the problem morphology, the relations f and g are established and two scenarios arise.(1) The higher the value of cj, the higher the degree of dominance, domj.  For some problem, M, let the problem morphology be identified such that cj ∝ domj. Then let Aj : (yi ∈ M)→(xij ∈ Pj). Applying the operators ∑, δ, and Hyp, the values cj, dj, and domj ∈ ℜ+ are obtained. If and only if an algorithm, Aj ⊗ ξ : (yi ∈ M)→(xij+1 ∈ Pj+1), is applied and if and only if for each j ∈  and for all i ∈ , ∑:(xij+1 ∈ Pj+1)→(cj+1 ∈ ℜ+) and Hyp : (xij+1 ∈ Pj+1)→(domj+1 ∈ ℜ+) is obtained, then cj+1 > cj and domj+1 > domj. The process of incorporating ξ into Aj to develop the new algorithm Aj ⊗ ξ is defined as surgery on the algorithm Aj.(2) The higher the value of dj, the higher the degree of dominance, domj. Let M be some problem, and let the problem morphology be identified such that dj ∝ domj. Let Aj : (yi ∈ M)→(xij ∈ Pj). Applying the operators ∑, δ, and Hyp, the values cj, dj, and domj ∈ ℜ+ are obtained. If and only if an algorithm, Aj ⊗ η : (yi ∈ M)→(xij+1 ∈ Pj+1), is applied and if and only if for each j ∈  and for all i ∈ , δ : (xij+1 ∈ Pj+1)→(dj+1 ∈ ℜ+) and Hyp : (xij+1 ∈ Pj+1)→(domj+1 ∈ ℜ+) is obtained, then dj+1 > dj and domj+1 > domj. The process of incorporating η into Aj to develop the new algorithm Aj ⊗ η is defined as surgery on the algorithm Aj.Let an algorithm, η and ξ may be incorporated into the algorithm, Aj, to obtain solutions with higher degree of dominance, domj, as mentioned above.Therefore, if any of these scenarios arises, then the components Gardenia  [MO optimization of extraction process of bioactive compounds from r, 2010) ;MO optimization of bioethanol production during cold enzyme starch hydrolysis  ;MO optimization of synthesis gas production process  ;MO optimization of pretreatment strategy for bioethanol production from rice husk  .The ideas proposed in this work were implemented to four industrial applications. The four applications wereGardenia jasminoides Ellis (J.E.) fruit. Chemical products such as crocins, geniposide, and the phenolic compounds (bioactive) are widely used in the food industry as natural food colorants (dyes). The phenolic compounds in Gardenia J.E. also have high antioxidant capabilities which make this fruit valuable for medicinal uses. This MO optimization model was for the extraction process of bioactive compounds from the Gardenia J.E. with respect to the constraints. The MO optimization model was developed to maximize the yield of three bioactive compound: crocin (in mg/g dry powder), geniposide (in mg/g dry powder), and total phenolic compounds (in mg/g dry powder) with respect to process parameters which are the concentration of ethanol in %, the extraction temperature in °C and the extraction time in minutes.The MO problem presented in Deep and Katiyar, (2010)   by combined reforming. In combined reforming, two techniques which are Partial Oxidation of Methane Method  and Steam Reforming  are combined. The MO optimization model was developed based on responses from an experimental reactor setup. The normalized objective functions are the methane conversion in (%), carbon monoxide selectivity in (%), and hydrogen to carbon monoxide ratio as presented in Mohanty, 2006 [−1), and the reaction temperature (°C).As for Application III, the MO optimization of the noncatalytic combined reforming process was performed. A MO model was developed in Mohanty, 2006 , for thety, 2006 . These oFinally the optimization of the pretreatment strategy for ethanol production from rice husk was used as Application IV. The pretreatment technique optimized in the work of Banerjee et al., 2009 , is the For Applications I and II, the proposed framework was carried out and surgery was performed on the PSO and DE algorithms, respectively. This was done by embedding the Hopfield component that enhances the convergence capabilities of the PSO and DE algorithms. The new algorithms generated are the HoPSO and HoDE. These results of the new algorithms are then compared with the original algorithm. The results comprising of the HVI, convergence, and diversity values of the entire Pareto frontier obtained by the methods are shown in Tables The Pareto frontier constructed by the HoPSO and the HoDE algorithms in Applications I and II are shown in Figures As for Application III and IV, the proposed framework was also implemented and surgery was carried out on the PSO and DE algorithms, respectively. This was done by embedding the chaotic component that enhances the diversity capabilities of the PSO and DE algorithms. The new algorithms generated are the CPSO and CDE. The computational results comprising of the HVI, convergence and diversity values of the entire Pareto frontier obtained by these methods are shown in Tables The Pareto frontier constructed by the CPSO and the CDE algorithms in Applications III and IV are shown in Figures In Figures In this work, we have provided an overview of the prevalent methods applied in MO optimization. Besides, we have also discussed some current research issues faced in this area. Based on the ideas proposed, one of the ways forward in MO optimization is to develop a general framework/procedure to solve three-objective (or more) problems. Besides, proceeding in this line of thought, new directions are revealed for studies involving the effects of convergence/diversity of the solution set on the degree of Pareto dominance produced by any given MO algorithm. These insights pave a new path to our understanding of structures and constructions of objective spaces.By these studies, an alternative or an enhancement to the hybridization approach (the proposed idea of “surgery”) which produces algorithms which are computationally less intensive, robust, effective, and capable of generating high-quality solutions could be developed. Extensive analysis and comparative works of solutions produced by these algorithms with standard algorithms could be carried out. By these comparisons, the strengths and drawbacks of the proposed framework may be studied in more detail. Most importantly, despite solving MO problems efficiently, the views presented in this work also points to an angle of inquiry that would increase our understanding of the nature of MO problems.


Dear Colleagues,Rambam Maimonides Medical Journal (RMMJ) has now been published online at www.rmmj.org.il.We are delighted to announce that the fourth issue of the new peer-reviewed open-access journal RMMJ is freely accessible via the Internet for immediate worldwide, open access to the full text of articles and fulfills the terms of the Creative Commons attribution license under which everyone is free to copy, distribute, and display the work, free of charge, for non-commercial personal and educational purposes.This Journal, while sponsored by Rambam Medical Center, represents an international initiative with active participation of leading international figures in medicine, biomedical science, and the ethical and philosophical aspects of health care. RMMJ is guided by the highest standards of scientific quality and integrity, professional responsibility, and human compassion in accordance with the Rambam’s (Maimonides) scholarly and ethical legacy.The editorial policy of RMMJ focuses on a wide spectrum of clinically relevant biomedical research and other issues central to the provision of optimal health care, disease prevention, and environmental health and provides a vehicle for original articles on basic and translational research that bring discoveries from the bench to the bedside and from the bedside to the community.As you may have noticed in the previous issues, RMMJ will be published along with the original article author’s reply. This kind of extended “Letter to the Editor” will enable an appropriate and comprehensive public discourse regarding various issues.The present issue contains our regular sections “Nobel Laureate Perspective”, “The Maimonides (Rambam) Heritage”, and the “Rambam Grand Rounds”. The last-mentioned includes a special article of major current relevance on treatment of crush injuries caused by earthquakes. The “Rambam Forum” section deals with the current issue of the societal and religious considerations in the practice of organ donation. Two articles on major findings regarding diabetes are included in the “Horizons in Diabetes and Metabolism” section. Two new sections have been added, “Education, Practice and Organization of HealthCare in the 21st Century” and “Readers’ Opinions and Comments”, in which readers’ full-length articles that have been submitted as a response to an article previously published in Journal has had an outstanding exposure demonstrated by more than 11,000 new visits, and 59,000 articles downloaded, from 109 countries and territories. The Journal is a CrossRef member, and articles are indexed by Google Scholar and the Directory of Open Access Journals.During the nine months that have passed since the inauguration, the RMMJ. We would be grateful if you could also assist us by notifying your friends about the Journal. This can be easily done through our home website, by clicking the “Notify a Friend” button, or by sending us your friends’ email addresses through the “Contact Us” section.We call upon you to join us in this endeavor and cordially invite you to submit a paper to Journal will be assured.With your help, the scientific and clinical excellence of the Sincerely yours,Editor-in-ChiefOn behalf of the EditorsShraga Blazer, MD


Many efforts today aim to energy saving, promoting the user’s awareness and virtuous behavior in a sustainability perspective. Our houses, appliances, energy meters and devices are becoming smarter and connected, domotics is increasing possibilities in house automation and control, and ambient intelligence and assisted living are bringing attention onto people’s needs from different viewpoints.Our assumption is that considering these aspects together allows for novel intriguing possibilities. To this end, in this paper we combine home energy management with domotics, coordination technologies, intelligent agents, ambient intelligence, ubiquitous technologies and gamification to devise novel scenarios, where energy monitoring and management is just the basic brick of a much wider and comprehensive home management system. The aim is to control home appliances well beyond energy consumption, combining home comfort, appliance scheduling, safety constraints, etc. with dynamically-changeable users’ preferences, goals and priorities. At the same time, usability and attractiveness are seen as key success factors: so, the intriguing technologies available in most houses and smart devices are exploited to make the system configuration and use simpler, entertaining and attractive for users. These aspects are also integrated with ubiquitous and pervasive technologies, geo-localization, social networks and communities to provide enhanced functionalities and support smarter application scenarios, hereby further strengthening technology acceptation and diffusion.Accordingly, we first analyse the system requirements and define a reference multi-layer architectural model – the Butlers architecture – that specifies seven layers of functionalities, correlating the requirements, the corresponding technologies and the consequent value-added for users in each layer. Then, we outline a set of notable scenarios of increasing functionalities and complexity, discuss the structure of the corresponding system patterns in terms of the proposed architecture, and make this concrete by presenting some comprehensive interaction examples as comic strip stories. Next, we discuss the implementation requirements and how they can be met with the available technologies, discuss a possible architecture, refine it in the concrete case of the TuCSoN coordination technology, present a subsystem prototype and discuss its properties in the Butlers perspective. In fact, several solutions exist that enable users to monitor their home energy consumption in real time – from low-cost, pass-through plugs that embed a meter to monitor a single appliance, to systems exploiting an inductive sensor in the mains line to monitor the whole house consumption via Wi-Fi Efergy , supportSome research platforms, like Powerpedia  or involves children (risk of fear or unexpected behaviour in the dark) or elderly people . To face these aspects, energy monitoring is a necessary brick, since no prevention can be made without awareness  that alThe second aspect is the forthcoming development of connected, and possibly smart, appliances, aimed at exchanging real-time information with the user and/or the “house” – and sometimes also outside, typically in the context of smart appliances and smart houses (see below): the purpose is to improve awareness and possibly allow feedback actions, including forms of remote appliance control Efergy  – for inThe third pillar consists of home control and automation systems, whose goal is to control home appliances in some way – not necessarily having energy saving as the main purpose: in fact, in most cases their goal is to enhance the human comfort, either automating some user actions , safety  or any other goal. In fact, if a suitable inferential engine is provided, this system could also anticipate or propose decisions based on the user’s current behaviour . Generally speaking, it should do so by coordinating and governing the home appliances according to the user’s dynamically-changeable goals – including energy saving as a special case. In this view, users should no longer be forced to specify details such as whether to turn off/on the washing machine rather than the air conditioner: they should just set the desired goal , and disregard the rest, letting the system take care of the details. At the same time, users should remain in touch with their butler in both directions – to be informed of any problem/situation and, conversely, to inform it if they change their mind/plans – via smartphones, social networks, etc.The envisioned system should thus be seen as an intelligent “home director”, a sort of Butlers architecture – an architecture for a pervasive home management system defined coherently with the above perspective. The architecture is intentionally devised to be general and technology-neutral so as to account for many possible systems – each with its own policies and objectives, based on the vendor’s trade-offs between cost, performance, reliability, robustness, etc. For this reason, special attention will be paid to the available technologies that could be used for the purpose.Accordingly, in this paper we present the Moreover, recognising that technology owes much of its success to people’s acceptance and enthusiastic adoption, and that the broad diffusion of a technology among consumers is strongly related to its ability in being perceived as “entertaining” and “pleasant” other than just useful and effective, we intentionally consider the gamification aspect as one further, essential requirement. This is why our scenarios include, for instance, humanized appliances with avatars and customizable personalities, which can be personalised from the style and language viewpoints and shared in social networks so as to involve users into a 360° experience; for the same reason, the system configuration and the user interaction can take advantage of the presence of 3D screens, gaming consoles, etc.Monitoring devices for house energy consumption are available from several vendors: typically, they exploit an inductive sensor in the mains line, and transmit data at the least to a remote metering unit via Wi-Fi, but possibly also to some Web-based service or mobile app like in Efergy . Some elIn the Energy@Home consortium  also considered energy balancing and control as an interesting application field, though possibly more from the energy provider’s viewpoint than the final consumer’s. In , including priorities to capture the user policies .In , we will discuss whether and to which extent they can be met with the available technologies.each appliance should be equipped with a consumption sensor;sensors should be able to communicate with some sort of central hub, and possibly also among themselves, via some kind of communication link; this requirement is independent from the actual technology and protocol selected for the purpose, which may be chosen in a wide variety of available technologies ;stigmergy  user both locally and remotely;the coordinator should support dynamically-modifiable, user-definable policies, inspectable and readable by any user in a clear human-understandable format, so that policies may be easily reviewed, integrated, and replaced at any time both locally and remotely; so, the coordinator architecture should not embed any hardwired technology nor any pre-installed “locked configurations”, in favour of a flexible, open configuration support; ;in addition, the coordinator should be able to inter-operate and cooperate with other users’ coordinators installed in other houses to exchange best practices, users policies and other relevant information – provided that an adequate security model is set up and the proper permissions are granted ;the coordinator could also be “intelligent” – that is, able to reason on the current situation  based on the user’s priorities, goals, but also on the current communication and coordination state  either directly or, more likely, via some ad hoc “proxies” – agents, in the MAS terminology and perspective.Given the central role of the coordinator, its requirements involve several aspects – from architectural and interoperability issues, to malleability and inspectability of policies, security, up to proper support to intelligence. More precisely:the configuration process should be simple, guided by a wizard if appropriate, and carefully designed so as not to be boring or annoyingly long; it should also take explicit advantage of any modern device  that users might possess;the local configuration process, in particular, should be able to exploit the Smart TVs, gaming consoles and personal computers available in the house, as well as other more pervasive devices like smartphone and tablet (via suitable apps or ad hoc Web sites), as well as via a voice menu system able to guide the user towards the desired configuration in a natural and familiar way; presence sensors could also be exploited to detect the user’s position in the house and activate the interaction device(s) available in that or the closest room;the remote configuration process, on the other hand, while exploiting the same smartphones & tablet apps and the Web sites cited above, could take advantage of other specific means, like shorts text messages , instant messaging systems, “twitter like” messages (with proper tags to be defined), as well as the user’s natural language thanks to the smartphones’ built-in text-to-speech/speech-to-text facility;the configuration language – intended as the set of commands usable to control the configuration process – should be linguistically expressive and efficient, that is, flexible enough to support a wide variety of different appliances and policies, enabling any useful command and situation to be expressed while retaining ease of use and overall simplicity; in addition, it should also be clearly uncoupled from the user’s natural language, both to easily support any users’ nationality – even simultaneously – and to preserve the underlying layer from changes in the users’ natural languages.The configuration process involves several aspects – namely, simplicity, proper exploitation of available devices, local vs. remote access, up to language aspects. More precisely:physically, it should support both local – exploiting available appliances such as Smart TVs (possibly 3D sets), wall screens, touch screens, gaming consoles, voice systems – and remote access – via text messages, short messages, voice messages, apps, wizards, Web sites, etc.;conceptually, it should make it easy and natural for the user to express high-level goals, desires and preferences , in addition to specific detailed commands  or command sequences (e.g. “do this before that”), promoting high-level specifications that delegate the coordinator for (most of) the practical scheduling: this is not only desirable from the user’s viewpoint, to free the user from having to plan detail aspects , but also to provide the coordinator with the necessary degrees of freedom;it should also enable the simultaneous specification of multiple goals – for instance, “try to do this, but at the same time save as much energy as you can”; or “do these things together, but don’t cause blackouts”, etc. – yet in a clear, easy-to-learn and understandable way – that is, no room for complex multi-dialog interfaces or that kind of multi-level menus that are often found in DVD recorders, video-cameras, and many other consumer electronics, that most people never use (if they know where they are..) because they are “too complex to understand”.In order to fulfil the above requirements and support the envisioned scenarios, the GUI should take several, integrated forms:the system (model and controller) counterpart of the GUI should support the expression of high-level goals, desires and preferences – rather/other than detailed commands and command sequences – from the linguistic viewpoint, including priorities among home appliances, user-defined constraints, etc.: accordingly, an expressive and easy-to-use language should be available, that is naturally usable from several different interface platforms – from text based messages to Twitter-like messages, touch screens, voice systems, up to posts on Facebook or similar social networks;dynamic system reconfigurations  should be supported at any time, and be possible through a variety of media, locally and remotely, both as a result of a user will or of an autonomous system decision;the specification of multiple simultaneous goals should be supported, in pair with a conflict detection and resolution mechanism that takes into account the user goals, policies, priorities, and constraints;geographic information must be properly handled and exploited – that is, grabbing the user location from either explicit position information or via indirect indications like posts about commercial activities, Foursquare check-ins, etc.; if possible, this information should also be stored in such a form that it can be easily and efficiently exploited as a base for behaviour detection, to infer the user’s behaviour (e.g. “he is coming home”) provided that an intelligent inferential engine – possibly an agent in a MAS perspective, or maybe the coordinator itself – is included in the architecture;optionally, an intelligent inferential engine – if present – could support advanced features such as anticipating the user’s desires, propose actions to achieve the user’s goals beyond the mere application of pre-compiled plans, help reducing conflicts, etc.; as mentioned above, this engine might conceptually take rather different forms at the architectural level, ranging from some ad hoc component  to a distributed system where intelligence is spread in the coordination architecture, up to the “extreme” case of the stigmergy approach.Although several functional requirements have already been mentioned indirectly, in terms of desired functionalities and system features, it is worth summarising them here to provide a complete view:gamification of the user experience, including the entertainment aspect under several forms, should be included. As discussed above, this choice aims to achieve several pervasive-oriented objectives:to broaden the social sensibility to the energy saving & management theme in general, and among the younger generations in particular, promoting the users’ interaction with the main social networks and communities;to promote the interaction with the community(-ies) of users, to exchange suggestions, best practices, etc.;to enhance people’s acceptance and voluntary technology adoption, by making the user experience more attracting, appealing and involving, ‘’humanizing” interactions.Last, but not certainly least, an adequate support to the today’s communities could be just the starting point of some new kind of “mixed” (human/appliance) social network, which could evolve in forms hard to guess today. In principle, appliance communities could grow up with different goals and forms:To this end, appliances could be “humanized” and equipped with a personality – which could be as complex and involving as many character traits as desired, possibly inspired to the user’s own personality – and “put in the arena” both to support multi-user gaming on some suitable platforms, and to play on social networks in a post-based, Facebook-like fashion. Note that participating to level 0: merely technical communities, aimed at exchanging practical information  with no expected human interaction : just a little more than a conventional communication protocol, no particular humanization required;level 1: mixed appliances/human communities, where humanized appliances – somehow similar to comic/cartoon strip characters – interact together, still with no particular autonomy or intelligence: this is where personalities, avatar and gamification could start to play a role;level 2: enhanced version of the above communities, with humanized appliances expressing also some form of autonomy or intelligent behaviour: personalities could then evolve “on their own”, beyond being just the pure projection of the home user/appliance manufacturer.In its turn, appliances humanisation could occur in very different, yet worth exploring, directions – which could take inspiration for their style and traits from comic, movie and cartoon characters, both in terms of icon, personality, and communication style. In particular, we could have ironic, verbose, or logic (“Vulcanian”-style) avatars, which communicate, interact and behave as the user perceives that appliance to be: for instance, a user could see his house inhabited by a verbose washing machine, as annoying as some never-stop-talking mother-in-law, and by an English gentleman-style refrigerator, while his best friend’s house could be very different, reflecting his personal view and style.Appliance personalities should be highly configurable in a wide variety of aspects – communication style, voice for voice synthesis systems (like today’s navigators), responsive style , mood, etc. – and virtually any desirable trait. Traits could also be moody, based on their expected “usage happiness”: for instance, an oven could very happy when expecting to be used to cook a pizza for a nice dinner with friends, and be sadder when unused for some time; and so on. Such aspects could also evolve over time to follow the user’s mood – which is actually what people already do every morning when posting their feelings and day life facts on Facebook, Google+, etc. – as well as their bigger life changes, like moving to a new house, or relevant success/failures in work or personal life which influence their life perception and happiness: for instance, the appliance personalities of the house of a single man/woman could change notably if he/she finds a partner and starts a new life, etc.shared among users in the social networks and in the user communities, becoming themselves a means to strengthen the communities, reinforce the entertainment effect (leading users to feel protagonist) as well as the users’ proactivity; as a side effect, humanized appliances embedding policies or preferences could become a way to promote and support policy/preferences sharing, with a multiplier effect on pervasivity. One further way to improve pervasivity and thrill/involve users could be to support on-line games and tournaments among humanized appliances, seen as users’ representatives, in specific (possibly energy-oriented) games – for instance, “who saved more energy today” – possibly aimed at showing off abilities – e.g. “today I rescheduled washing, oven and air conditioning eight times, to make my master happy”, etc. Clearly, in this perspective, imagination is the only limit: virtually any game and situation can be adapted to serve the purpose.As a next step, appliances personalities could be exported and The resulting multi-layer reference architecture is depicted in Figure information) is the enabling one: indeed, most of the systems reviewed in Sections Introduction and State of the art and related work operate at this level, allowing users to check their real-time energy consumption from a multitude of media (from displays to mobile apps), and promoting energy-saving behaviours via users’ awareness.The bottom layer (control) adds some form of remote appliance control: as discussed in the Sections Introduction and State of the art and related work, this is the typical goal of home automation and assisted living, but is also a pre-requisite for any active approach to home management that aims to go beyond the mere awareness of what’s going on in the house.The second layer (coordination) is rarely considered today, except for some research systems (see Section State of the art and related work); the same holds for the fourth layer (user), too, which is aimed at considering “who and where” the user is. Traces of features from the fifth layer (intelligence) can sometimes be found, albeit in limited forms like detecting and learning user interaction patterns; analogously, traces of features from the sixth layer  can be recognised in the social sharing features  provided by some systems. To the best of our knowledge, the top layer (gamification) is mostly unconsidered today in this application field.The upper layers, instead, are more independent from each other, and therefore more freely selectable. The third layer , as in some of the above-discussed cases.Moving from the state-of-the-art presented above, several scenarios, of increasing complexity and pervasivity, can be imagined, which correspond to different selections of layers, and possibly different selections of the features providing the value-added for users within each single layer.A + B + …) to indicate the required layers: more precisely, N represents the need for support of layer N, while N* indicates that only a partial support of the features inspired by level N is actually required.For the sake of concreteness, we discuss here some of the most intriguing possibilities, outlining a hierarchy of systems – from the basic informer up to the most comprehensive system. To express their architectures compactly, we use sum-like expressions  do this, to some extent. However, the scenario we first considered in the Introduction goes farther, assuming that users can control their appliances in a natural way – that is, communicating with the system easily, in their natural language, via voice recognition, short messages, maybe phrases in English, Italian, French, etc., in mobility and dynamically. This kind of system makes still use of layers 1 and 2, but invests on the communication aspect to improve pervasivity and provide further value-added for users. As a slight enhancement, communication might include tweets or posts on social networks, thus embracing layer 6, though without actually exploiting the social aspect in depth. As a further step, avatars could be added in the appliance control GUI , moving towards the direction of layer 7, albeit without stressing this aspect deeply. Possible systems architectures in this category therefore include 1 + 2, 1 + 2 + 6*, 1 + 2 + 7*, and 1 + 2 + 6* + 7*.The basic version of this kind of system makes use of layers 1 and 2, both to be informed and to control home appliances The second scenario adds coordination as a means to enable users to specify preferences and priorities, both statically and dynamically. This makes it possible to go beyond the mere “direct user control” of an appliance in favour of an approach where higher-level goals can be defined  that delegate the coordination infrastructure for the consequent detailed decisions. It should be noted that the expression “coordination infrastructure” does not necessarily refer to a complete coordination infrastructure: in principle, a central coordinator, with proper communication protocols, could do as well, albeit in a less scalable and maintainable way. However, adopting an effective coordination infrastructure makes it possible to enforce the specified policies, actually governing interaction and increasing the system robustness and security. Systems in this category include the same above, with a “+3” specification in their layer description.knowing the user – mainly his position, but also his age, gender, preferences, habits – and taking this information into account for deciding the activities’ coordination, so as to provide a more “user tailored” behaviour. The user location can be either obtained via geo-localisation of an enabled device, or grabbed from elsewhere – for instance, from the user’s check-ins on Foursquare or Google Places, though this choice implies some features from layer 6 – or simply obtained directly from the user, either asking or because the user provides his position proactively (even sending it by a low-level mechanism as a properly-formatted old-style SMSd). Personal user information such as age and gender can already be available if the user is known, or be grabbed as above for guests.In this scenario, the extra value-added comes from The likely effect of this information is to influence the priorities of tasks or the scheduling among appliances, favouring the ones that are most needed to meet the user comfort if he/she is coming home, and – conversely – perform the most annoying tasks when he or she is at work or at school. Examples range from controlling the home temperature to the preferred level when a given user is coming home, to warming the oven if the chef lady is coming home and likes to cook a cake or a pizza, scheduling the washing machine when nobody’s at home provided that there’s enough time for it before dinner time, etc. However, no specific intelligence – intended as the ability to reason and anticipate possible user wishes – is considered to be present at this stage: decisions are driven only by the rules embedded in the coordination layer during the configuration stage. Thus, systems in this category are substantially the same as above, with a “+4” layer in their architecture description., which can be now of a higher level than above, and include reasoning on the current system state, on the previous actions, and, if available, on the user position, identity, and behaviour. Consequently, systems in this category would particularly benefit from geo-localisation information provided by layer 4, although this is not indispensable to provide value-added for users. Examples of such intelligent decisions can range from comfort-oriented decisions , to the concretisation of abstract safety policies into specific actions , to deductions from the user’s current behaviour that can lead to proactively propose further actions , and so on.By adding intelligence as a fundamental feature, this scenario adds the ability to anticipate the user’s decisions and wishes, exploiting any available information, taken and re-elaborated from virtually any source. This puts greater emphasis onto the specification of the user’s goalsalter ego, to some extent), both to be informed of any problem/situation and, conversely, to inform it if of any change of mind, an adequate communication and interaction support is crucial. While the communication media and interaction forms outlined above for the basic remote controller can suffice, an enhanced communication/interaction support could greatly help to express and manipulate the user’s policies, preferences, desires, goals, etc. This is why intelligence could also cover the linguistic aspect, supporting higher-level concepts and metaphors: in fact, this is also essential to capture the configuration process at an adequate abstraction level, posing the base for its “gamified” support at layer 7.Since many advanced features depend on the user’s possibility of remaining constantly in touch with his/her butler , and 1 + 2 + 3 + 4 + 5 (better version), both with the possible further extension to layers 6 and/or 7.At layer 6, the key aspect is the integration with the social networks, in all the forms discussed above. Such integration can occur in both directions, that is, on the one hand users and appliances can participate in social activities, producing information, while on the other they can exploit communities to grab information – be it geographical information, user habits’ information, best practices, etc.per se, acting as a multiplier of the user engagement, other than as an extended source of information and user behaviour; yet, it is undeniably the major brick for building systems according to the gamification perspective, too.Any social network and community kind can potentially be considered in this context, from old-style forums to specific user communities, up to Facebook, Google+, Twitter, Foursquare, Google Places, etc. Adding the social dimension has a value users share their experience to advanced situations where humanized entities – maybe the single appliances, more likely the butler as the leader/representative of its community, possibly both – participate to their own communities and to traditional human communities, interacting with themselves and with the other users autonomously, within the boundaries of the pre-established security policies . Such system architectures have the same form as above, with a “+6” addition.The social contribution can range from basic situations  where Layer 7 considers the ability to entertain and make things nice as a fundamental aspect to involve people and to make complex tasks within their range. As discussed above, the main means to achieve these results are:user involvement, making him/her perceive to be part of the system by showing him/her that the system is perceiving him/her presence and possibly also that it knows his/her identity, habits, preferences: even a low cost sensor of presence used to activate the interaction devices in the room  can make the difference, because fun is based on engagement and on the feeling that your system is interacting precisely with you; another way could be using a custom (user-selected) voice in a text-to-speech interaction system; and so on.humanization of home appliances with highly-customizable avatars, whose personality, attitude traits, communication style, language, voice, etc. can be defined by the user (possibly starting from a set of pre-defined models to enable a one-minute quick start), so that they reflect his/her way of life, habits and mood;concretization of appliances and more abstract concepts  into physical, (possibly 3D) entities, to be manipulated very much like characters and objects in games on gaming consoles, possibly exploiting wearable movement sensors, so as to turn complex tasks  into physical experiences: if opportune, scores, classifications, awards, winners and similar accoutrements could also be included. This allows for a wide variety of systems, inspired to different gaming approaches and user engagement’s philosophies; the game metaphors and level could also be tailored to the user’s age, experience, role, permissions, etc., so as to provide each user with the kind of experience that is most suited for him/her – e.g. an intriguing game for a child or a young adult, or better a reassuring quiet location for the less experienced, possibly elderly people , and so on;sharing what’s happening in social networks, under a plurality of forms – from the user personally posting what he/she is doing with his/her house system, to humanized butlers interacting with the user’s wall/diary as if it were an old friend , to appliance communities sharing best practices and policies , to mixed appliance/human communities, up to humanized appliances as friends on Facebook, Google+, etc.System architectures in this category can vary from those providing a basic support, as in the remote controller scenario , to full-fledged systems involving all layers – the same above with a “+7” addition – where the gamification philosophy impacts nearly all the aspects of the system, from local interaction to remote interaction, system configuration, coordination control and reasoning rules, goals specification, experience sharing.In this Section we illustrate some possible “everyday interactions” with a comprehensive system like the one devised above in the form of comic strips.In this first example, described in Figures Once confirmed about Paolo’s conditions and desires, the butler orchestrates the house appliances accordingly, transforming Paolo’s goals – such as “silence” in the house because of the headache – into the consequent detailed decisions – such as switching off the washing machine to ensure silence, and activate the boiler to provide a hot tea.The second situation is similar to the above, but occurs in a different context. Ann is coming home normally, but decides to stop at a take-away pizza Figure : her butIn the gamification perspective, appliances are humanized with a proper avatar – possibly with a funny name, and feature a precise, user-defined personality , according to the legend shown in Figure Meanwhile, the butler keeps also an eye on Ann’s daughter, Jeannie Figure , noticinButlersBook, where butlers interact to exchange experiences and best practices. While closed communities (as discussed above) might be used, this community is intentionally open to users, so butlers are represented as avatars, feature a rather precise personality for the users’ fun (gamification), and behave according to their own style – see Figure Figure Despite the fun aspect, the community actively supports the sharing and exchange of butlers’ experiences and best practices, based on their willingness to share and learn, as expressed by their personality. Appliances communities (not shown) could also be considered. Of course, all such the community are accessible via different devices – from smartphones to tablets, Web, etc.As a reference multi-layer architecture, one of the main values of Butlers is its independency from any specific technology, which would otherwise limit its generality: in fact, as widely discussed above (Section Notable scenarios and system patterns), many different systems could be considered, each covering different layers and possibly realized with quite different technologies, depending on the designer’s goals and on the vendor’s market areas. On the other hand, concreteness is necessary to prove the feasibility of the Butlers’ approach, especially as concerns the integration of so many heterogeneous technologies from so many different areas.For this reason, in the following we conjugate these two needs by presenting one possible design of a Butlers system, yet delaying the commit to a specific model and technology as much as possible, so as to keep the conceptual and the practical aspects as separated as possible. To this end, we first analyse the available technologies needed for the Butlers layers from different areas, present a possible logical architecture of a Butlers system, then commit to a specific coordination model and infrastructure – the key choice that fixes the design and interaction metaphors, and therefore the basic ingredients of the system structure. Nevertheless, the Butlers system at this stage is still “general” in the meaning of Section Notable scenarios and system patterns, in that its features can still be scaled in a range – even if its overall design philosophy and “design language” is by now fixed by the key choice above. In the next step, we consider a subset of such a system, that is small enough to be implemented “by hand” without requiring a large team effort while retaining all the essential aspects of the full system. Finally, we present the actual implementation of such a system, discussing its intended application scenario, its agent-based architecture, and outline the resulting prototype.tuple centres – can be exploited to effectively provide the kind of flexible and extensible support needed by our architecture. The consequent TuCSoN-based implementation is discussed in Section TuCSoN for Butlers. Then, to be even more concrete, we take a small, but significant, sub-system and present its prototype implementation. Finally, we discuss the conceptual roadmap towards a real Butlers system: starting from the prototype, we discuss how, and to which extent, its limitations could be overcome with respect to all the relevant aspects – namely, home appliances, users categories, policies, configuration issues, and the butler itself.So, this Section is organised as follows. In Subsection Technologies we survey the main available technologies in the relevant fields, and evaluate whether – and to which extent – they can be used for our purposes. Then  we present the logical architecture of a possible Butlers system implementation, discussing the relationship between the properties of the architectural components and the features that the system can consequently be expected to provide. As a next step, we commit to a specific coordination technology and infrastructure (TuCSoN) as the technology of choice to concretise our Butlers logical architecture: we summarise its basics and discuss how its main metaphors – Our goal here is discussing to which extent the scenarios depicted in the previous Sections can be implemented with the available technologies, taking into account the requirements outlined in Section Requirements.As mentioned in the previous Sections, sensors for energy consumption measuring and monitoring are available from many vendors: so, it is reasonable to assume that each appliance can be equipped with proper sensors. The extra requirement that each appliance is provided with some kind of communication link is equally feasible, with a variety of protocols and system to choose from: since appliances are power-supplied, vendors could find it convenient to exploit technologies like Ethernet on PowerLine/Homeplug to make communication-enabled appliances with no extra wiring, but other cost-effective and widely available alternatives like Wi-Fi (or ZigBee) could be equally adopted – especially for battery-operated or gas-powered appliances.Wizard technologies have long been available on personal computers, so meeting requirement #1 in Section Requirements – which is also a GUI concern – is basically a matter of good design and proper implementation: of course, a smartphone-based or tablet-based version of this wizard should be tailored to the characteristics of such devices, like touch screens. Smart TV sets (requirement #2) could be treated analogously, but the 3D technologies that are becoming more and more common both on TVs and gaming consoles could be exploited to provide more involving, innovative configuration experiences: configuration could take place by inviting users to interact with 3D entities – maybe humanized animals or appliance avatars – instead of merely navigating through classic, tedious dialogs or on-screen display instruction. The wizard could also exploit the natural language, exploiting voice recognition and text-to-speech systems to talk to the user, making the system more accessible to visually-impaired or elderly people in the Assisted Living perspective. Presence sensors are also a low-cost, widely available technology, used typically in light switching and alarm systems: yet, nothing prevents it from being exploited in a novel scenario.Similar considerations hold for the remote configuration aspect (requirement #3), since the communication means considered in addition to the previous ones  are everyday, low-cost technologies.In short, all the technologies needed to face these issues are clearly available – often just in the smartphone in our pocket – so all is needed is to put everything together.The last requirement #4 is more technical, but the required knowledge and technology are also available: domain-specific languages are an established technology, so – more generally speaking – designing an expressive and efficient configuration language is well in our reach. Keeping it separate from the users’ natural language is merely a matter of good design, and presents no conceptual difficulties.Apart from the configuration-related aspects, the above technologies can be used for other aspects of the user interface (requirement #1), provided that a consistent view is given across the various interaction media. Because of the emphasis on high-level goals, desires and preferences (requirements #2 and #3), voice could well be the preferred mean over classical menus or on-screen dialogs that most users tend to find complex and unnatural: this is particularly relevant when the intended users include elderly people, children, and other non-expert categories – quite a common situation in a house, indeed.In addition, a “gamification-oriented” approach could also be explored – albeit with extra difficulties due to the higher abstraction level of these interactions with respect to the configuration above: in principle, goals and preferences could be concretised as items in a virtual (possibly 3D) world, so that their selection and specification becomes very much like an intriguing  game; the kind of the game could be system-specific, or even user-specific – for instance, preferring simple games for children, and more complex 3D worlds for younger adults. From the technology viewpoint, everything we need is already there: avatars are widely adopted in many contexts, from online forums to mode complex applications, gaming consoles (often with on-board Wi-Fi connectivity) are in many houses, and so are Smart TV and 3D TV sets, wearable movement sensors that enable natural yet advanced user interaction are also spreading around, etc. So, exploiting such technologies for our purposes is mainly a matter of integration – possibly a non-trivial issue from the industrial viewpoint, but hopefully not-so-critical from the conceptual viewpoint.per se, either – so, the related technology is there to be reused – but is used here in a novel application context. In particular, extending such humanisation/customisation to the communication and interaction aspects of appliances’ avatars, including physical aspects like voice, morphological details, etc. and possibly modelling their behaviour after the user’s mood, opens interesting perspectives in a social-aware scenario. Still, this does not require new technologies to be developed on purpose, but just to put together technologies available for different purposes in separate worlds.The technologies required to properly support the gamification approach are mostly the same discussed above for user interaction: so, their availability and presence in everyone’s house have already been discussed. Appliance communities – both in the form of merely technical and mixed appliance/human communities – constitute to some extent a novel idea, but the required technology is again well established – the novelty is in integrating this aspect in the new scenario. The avatar’s customisation in terms of style, traits, personality, communication style, etc. is not particularly original orchestration keyword. Depending on the context and on the adopted model, the responsibility of performing the coordination activities can be either on the entities to be coordinated , or on some ad hoc entity/-ies (the coordinator(s), whatever form they take and whatever protocols they use), or even on the coordination media, or a mix of these.Although coordination technologies are expectedly less common in consumer electronics, the topic of coordination has long been studied (Papadopoulos and Arbab subjective approach), where coordination is mostly up to the coordinables, emphasizes the entities’ autonomy and demands little or no requirements from the underlying communication system (and model): it can also be easily coded in virtually any language and platform, since coordination in this case is just one more task an entity must perform. However, the overall system correctness depends on the entities’ honest behaviour and willingness to cooperate, since there is no way to force the respect of any coordination law or protocol: so, the system robustness is weak, and security issues can arise. In the opposite scenario (referred to as the objective approach), entities do not interact directly, but through mediators – at least in the initial phase: then, direct communication might occur, for efficiency reasons – that control and govern interaction, enforcing the respect of the coordination laws: this is the basic difference between enabling and governing interaction , that are also embedded in today’s devices.Rather, grabbing such information indirectly, by analysing the user’s posts on Facebook, Foursquare and other social networks, requires a specific technology to be integrated. While similar technologies exist – for instance, to extract information from search engine’s queries: we all see “targeted” commercial ads being proposed right after a Google search, to say one – they are not necessarily tailored to geographical information or to the user’s position: what they do is trying to infer the user’s desires to propose vacations, services, goods, etc. Other, more geographical-oriented technologies do exist, however: some adopt a similar technique to propose restaurants, hotels and tourist services after a post on Foursquare or Google Places, while others infer the user’s position via his/her current IP address: so, the above requirement can conceptually be met by integrating such technologies in a new architecture, exploiting them in the new context.The intelligence aspects (requirements #4 and #5), despite their relevant role in the envisioned architecture, are less critical from the technological viewpoint at this stage, since decades of research in the AI, expert systems, machine learning and MAS fields have led to a strong knowledge in the area and to a wide range of models, languages, architectures, and technologies: so, designing and building a “suitable” inferential engine, with the required properties, is basically a matter of choosing the preferred approach and technology – where “preferred” can refer to many aspects , to be valued and weighted according to the designer’s viewpoint and vendor’s marketing goals.Following the previously-highlighted requirements and keeping an eye onto the available technologies, the logical architecture of a Butlers platform can be devised as in Figure whether the communication between the entities  and the infrastructure is one way or bi-directional, for all or just some of the entities (see layers 1 and 2 of the reference architecture); in a chain, this also affects the choice whether one single protocol is supposed to be adopted, or different heterogeneous protocols are to be supported – including the addition of new protocol support to an existing system;when, how and by whom these policies are to be configured – in particular, whether the configuration is supposed to be performed statically or also dynamically (at run time), and whether it is up to the system administrator only or should be available also to the final users, with which rights, by which means, and with which metaphors ;whether the infrastructure to be built is basically hardwired, or, conversely, requires configurable policies (see layer 3 of the reference architecture); in the latter case, the subsequent choices concern whether some form of intelligence is to be included in the system, for which purpose, in which parts and to which extent – from the simpler form of exploiting user information to higher-level tasks (layers 4 and 5 of the reference architecture)whether some form of social interaction has to be considered, in which forms and for which goals (layer 6 of the reference architecture)Different answers to these questions lead to different Butlers systems, with different features and capabilities, ranging basically over the whole set of possibilities discussed above – and beyond: any vendor can “carve” its system according to its needs and industrial aims.For the sake of concreteness, in the next Subsection we commit to a specific enabling technology – the TuCSoN model and infrastructure Figure  – and inTuCSoN , the Tunodes spread over the network  operating on such nodes. The system behaviour is governed by the coordination laws embedded in the tuple centres, which are designed so as to enforce the desired system behaviour. These laws are expressed in a declarative interaction programming language, ReSpecT, which is Turing-equivalent: so, any computable coordination law can in principle be expressed. The most recent ReSpecT version also supports time-aware specifications, as well as sensors and actuators. Tuple centres are inspectable at any time both by agents and humans (via the Inspector tool): in particular, the embedded laws can be changed at any time – provided that the proper access rights are granted – both statically and dynamically. Tuple centres can also cooperate together , promoting the conceptual and physical distribution of information and behaviour.A TuCSoN system is made of k Figure , bottom,role-based security model that requires agents to negotiate their roles and permissions both when entering the community and later, dynamically, on a “by need” basis: so, at any time, an agent interacts with the infrastructure via a sort-of “proxy gateway” called Agent Coordination Context  development methodology should be adopted. Among the several agent-oriented methodologies available in the literature it inherently supports interoperability of heterogeneous agents (requirement #2)its programmable coordination media (tuple centres) provide Turing-equivalent reasoning abilities tuple centres also provides dynamic, user-definable, inspectable policies, with the full inspectability of the communication and coordination state (requirement #8)tuple centres are accessible and configurable (requirement #3), both locally and remotely, at the infrastructure levelneither the model nor the infrastructure embed any hardwired technology or pre-installed (locked) configurationsit is designed so as to prevent bottlenecks (requirement #1).There are also some possible drawbacks, of course. The first worth mentioning is that accessibility and configurability at the infrastructure level are currently only within the range of expert users, that are sufficiently familiar with the TuCSoN inner structure and languages: however, as discussed in the Reference architecture, this could be faced by adding an extra architectural layer, aimed at filling the gap towards the non-expert user. Another drawback may concern performance: although TuCSoN has proven to be good enough in the applications where it has been used so far, more stressful situations should be tested. This aspect, however, is not crucial here, because our aim is just to present one of the possible implementations of the Butlers architecture with one of the possible available technologies, for feasibility and concreteness purposes – not to support TuCSoN as “the” suggested technology of choice: in principle, any other technology (or a mix of) with analogous features could be used, based on the designer’s requirements and key choices. enables both one way and bi-directional communication between the entities and the infrastructure; inherently supports heterogeneous protocols, since tuple centres can be programmed to bridge between different protocols and possibly among different agent perceptions; as a welcome side effect, new protocols can easily be added to an existing system, promoting incremental design, modularity, and the integration of new components into legacy systems; being based on the observable behaviour, intrinsically supports any kind of agents, independently of their technology, internal structure, etc.; results in a platform that is inherently distributed yet location-aware, thus providing designers with the power to balance distribution , and hereby performance, with locality awareness; being based on objective coordination, allows coordination laws to be enforced by the infrastructure, not just depend on well-behaving agents; gives rise to a platform that is completely configurable, where policies are expressed declaratively as ReSpecT programs, are not hardwired once and for all, are dynamically malleable and inspectable, and can be defined both statically and dynamically, both by any human or software agent with the proper access rights; allows users to change/integrate policies at different levels and by different means: while the developer and the expert users can operate directly in the ReSpecT language, end users can potentially be equipped with a higher-level interface providing a more abstract view over the policies, with adequate metaphors to express and manipulate them. Moreover, these views can coexist, both conceptually and practically, and other views can be added at a later time: so, for instance, a prototype system can have initially no higher-level policy manipulation features – the only way to manage policies being the direct tuple centre programming – but be extended later with some “add on” component that makes the higher level manipulation possible. more generally, allows the system to be extended at any time with little or no impact on the existing system, as long as the addition of new components, interaction protocols, agents, and coordination laws is “made transparent” by some suitably programmed tuple centre; inherently supports intelligence in the infrastructure: because ReSpecT is Turing-equivalent, potentially any (interaction-related) computation can be embedded, and any computable coordination law can be computed; at the same time, the chance to spread such intelligence among the system – in particular, to decide what to put onto agents and what onto the infrastructure – where and when needed provides the designer with the full power of tailoring the system according to his/her goals and needs; makes it easy to bridge the gap caused by any source of heterogeneity , thus also supporting the addition/replacement of entities to the system at later times;j above) between virtually any perception, protocol and entity, as well as decide how to split the required logic among agents and the infrastructure (as in point i above); supports potentially any kind of social interaction, since the designer can both bridge the gap  that is specifically thought to define a clear (but negotiable) external boundary, so as to protect both the infrastructure and the system built on its top from the external world.Exploiting the TuCSoN basic bricks, tuple centres and ACCs, the logical architecture shown in Figure Because of these features, the specific technologies for implementing the physical communication , for enabling communication at the logical level , for retrieving measures and issuing commands to remote-controllable appliances, for showing and manipulating information onto a variety of devices , and so on, need not be specified at this level: many of them could be used, possibly also together – it all depends on the vendor’s preferences and goals: the key aspect is that they do not influence the system design, since the infrastructure provides the technology to manage heterogeneity, filling the gaps. As a result, the architecture at this level still accounts for a wide set of systems, yet maintaining the generality of the reference architecture depicted in Figure $ORG, contains the specification of the organisation logical structure. Tuple centres embed the coordination laws required to handle the system, enforcing the desired properties and hereby implementing the “social intelligence”: this is further supported by the so-called linkability property of tuple centres, that is their ability to trigger reactions in other tuple centres, according to the local programming rules, as a consequence of a local event. Agents, on the other hand, embed the individual intelligence  of external entities.So, the Butlers logical architecture in Figure In this section we focus on a selected sub-system, that is small enough to be implemented as a prototype requiring neither a large team effort nor vendors’ involvement, yet retaining the key aspects of the full system.With respect to the full system, the following constraints and limitations apply:one single house is considered, with limited goals – referred only to lighting, air conditioning and heating;there is no intelligent Butler recognisable “as such”, like Archie in the comic strips above;user localisation is limited to the interior, and is simulated via GUI – that is, no real geo-localisation is actually present;social interaction facilities are not supported;gamification is not supported, either.The consequent architecture is synthesized in Figure user-defined maximum energy consumption threshold, to be monitored and enforced by the system;enforceable coordination laws that govern the interactions and enforce policies among all the involved entities;an extensible architecture based on loose coupling, where new devices, entities, and interaction protocols can be added seamlessly and incrementally:both comfort-oriented and energy management policies;both local (room-specific) and global (house) policies, applied to selected areas , with support for custom user preferences;a full-fledged role-based user model, with a configurable set of roles, and both static and dynamic separation of duties (SSD/DSD constraints).Figure parent (administrator), child, baby, cleaning lady, visitor and unknown. Parents have no restrictions – they can access all rooms and use all appliances; as administrators, they also define the house maximum energy consumption threshold, later enforced by the house management system. Children are not administrators, but apart from that have no fundamental restrictions – their only real limitation is the prohibition to access the private bathroom. Babies, instead, are forbidden to access the storage closet and the garage, too, and cannot use cooking or cutting appliances: moreover, they can access home entertainment appliances only during the weekends, until 8 pm, and with parental control. The cleaning lady can access all rooms and use all appliances, but only 8:30 am-6:30 pm Mon-Fri. Visitors have the same basic rights as babies, but can use appliances only in the presence of an adult living in the house : in this case, however, special exceptions may be needed – for instance, if the visitor is a repair man or a technician who needs to access a normally-forbidden room or use a normally-forbidden appliance to perform his work: it is then up to the administrator to define specific, ad hoc policies. Finally, the unknown role represents unrecognised people: since these should not be in the house, their presence is immediately reported to parents and children .There are 6 user roles: Environmental constraints apply to both rooms and appliances: for instance, the private bathroom is reserved to specific users at given times, but is available to others when the intended users are not at home; the TV is accessible to children in the evening and night (e.g. after 8 pm) only with parental control; and so on.User preferences are taken into account whenever possible, but only as far as the general house policies and the room policies allow. These policies, in their turn, may take external environment factors, such as light and temperature, into account. Proper meta-policies are also defined to mediate among possibly conflicting policies. For instance, some policies prescribe that:the room lights are switched on only if the room light sensor acknowledges;the room temperature is set at “approximately” the average of the temperatures desired by all the people currently in the house, where “approximately” means that the heating/air conditioning are switched on only if the desired temperature differs from the actual one for more than 3°C;in case of conflicts, the user that has been in the room for the longest time prevails.Every time a user enters a room, his/her preferences are taken into account, and the room condition is re-checked trying to meet the user’s expectations; of course, unknown people are not pandered to – room lights remain off, etc.To implement such a system as a TuCSoN multi-agent system, the SODA analysis and design process has been applied twice: first, to the RBAC engine in general; then, to the house management system in particular. While its details are outside the scope of this paper, the resulting MAS is shown in Figure Role Activation Agent  that the role is not active for the same user, 2) that it is associated to the requesting user, and 3) that the DSD constraints are respected.Analogously, the code below shows a small excerpt of tuple centre programming – a subset of the ReSpecT reactions of the RBAC_TC tuple centre  can view various kinds of information, manage users, roles and policies, and issue a command to simulate an action. The bottom dialogs enable the management of roles/permissions associations (left) and of roles/users associations (right): the latter also shows the corresponding rule expressed in the Prolog-like formalisation adopted.Figure Admittedly, the prototype presented in this section is a small subset of a whole Butlers system, with considerable limitations: so, it is worth discussing how far it is – both conceptually and practically – from a full Butlers system.Appliances in the prototype are totally simulated – we currently have no physical interface to any real appliance. Yet, the technology survey in Section Technologies showed that several technical solutions to monitor and remotely control appliances of any kind are available on the market. Therefore, integrating real appliances in the system is feasible – whatever communication protocol and interaction language they use – since the TuCSoN infrastructure fully supports heterogeneity from these viewpoints and can bridge the possible gaps. The required effort amounts to writing the proper “driver” software in terms of a) suitable tuple centre and ACC programming, and b) the appliance interface agent, whatever its implementation language and running platform are.Users, and user movement inside the house, are also simulated – there are no software interfaces to GPS and other localisation systems. Yet, geo-localisation technologies are embedded in smartphones, and other low-cost technologies such as movement sensors, touch sensors, fingertips sensors, etc. are available and could be used inside a building. External positions could also be grabbed from social networks like Foursquare, Facebook, Twitter, etc., provided that the necessary software is set up.So, while the integration requires the development of an adequate software layer in the form of a suitable proxy agent and corresponding TuCSoN programming, as above, it is clearly within reach. Since the burden of properly handling the heterogeneity of such sources can be left to the infrastructure, multiple different technologies could be used, even simultaneously, and integrated: suitably-programmed tuple centres could also provide a unified view of a user’s positions independently of the specific underlying technology exploited to get the location information at a given time – thus integrating information coming from GPS or Wi-Fi (inside and outside the house), house sensors (inside the house), social networks (mainly outside the house), etc.Policies in the prototype are currently limited to a few pre-defined fields , but others could be added by writing once again the necessary specifications in tuple centres/ACCs.Since policies are more likely to change at run time with respect to the appliance types or user localisation technologies above, which are more stable by nature, an administrator – or someone else with proper access rights – should be enabled to operate on tuple centres and ACCs, either directly or indirectly, also at run-time, so as to tune and configure the system dynamically. . Moreover, if selected end users, other than administrator, are to be enabled to add/change (some kinds of) policies, a higher-level user interface, with adequate metaphors, has to be designed to support them in this task, as it would be unrealistic, and dangerous, to let them operate directly on the infrastructure at the basic programming level.In the current basic prototype, the access to tuple centres and ACCs is generally done at the infrastructure level, and is therefore only within the reach of an expert user; at the same time, for the above reasons, an effort has been made to make a step towards a more user-friendly approach, as demonstrated by the dialog windows shown in Figure User-side configurability requires both proper metaphors and a suitable software support, aimed at making the configuration process understandable for various categories of end users, that are not – and should not need to be – computer experts. A variety of interaction systems could be considered, enabling configuration from different physical devices at different abstraction levels, possibly with a different level of detail on different devices and/or for different user categories: as an example, computer screens and smartphones could offer a complete UI with plenty of details that is mostly suited to expert users, while 3D TV screens and gaming consoles with movement detection could provide a very different, yet involving, user experience that turns the configuration process into something “physical” and “touchable” – a sort-of 3D game where items representing configuration aspects can be moved and composed in some kind of virtual world for non-expert users. Proper abstraction levels would be needed based on the user’s age, culture, etc.: for instance, a child wishing to configure the lighting or the music/media player in his/her room could be provided with metaphors like pets, toys, puppets, games, and other familiar objects from his/her everyday life, while his/her grandma’s and parents would likely need rather different abstractions; and so on.Although the current prototype does not include any of these features, the mediated interaction approach makes their addition an orthogonal aspect: as long as the proper specifications are eventually written in the proper tuple centres, the infrastructure itself does not care of how and where the specification themselves originated – be they written directly as ReSpecT code by an expert, or synthesized by a GUI like the ones in Figure The last crucial item which is totally missing from the current prototype is the (possibly humanized) Butler, like Archie and John in the comic strips. As long discussed above, this component is supposed to embed the higher-level intelligence, anticipating the user needs, possibly learning as time goes by, and possibly interacting with other butlers various ways to exchange experiences, best practices, etc.Conceptually, the prerequisite for these tasks is that the whole state of the system and of the interaction is reified, inspectable, and available to the Butler at any time, so that any kind of deduction can in principle be supported: TuCSoN satisfies this constraint, since all the relevant information is stored in tuple centres. Moreover, tuple centres can also be programmed so as to highlight the events, facts, and issues that are specifically relevant for the tasks to be performed, helping to build ad-hoc views that are tailored to the desired abstraction level. On the other side, the butler itself can be seen as a sort-of autonomous, intelligent agent embedding specific skills in selected areas : if the tasks to support is particularly complex, in principle it could also take the form of a society of cooperating agents. Technically, any AI model and system from the many available in the literature and AI research could be adopted: thanks to the mediated interaction approach, this is once more an orthogonal choice.per se, it could constitute another dimension worth investigating from the industrial viewpoint.Depending on the vendor’s target and marketing policies, butlers with increasing competence and abilities could be developed that include a different set of Butlers layers (as discussed in Section Notable scenarios and system patterns), supporting different “editions” of a Butlers systems. Proper standards could also be established for the butler’s interaction, so that butlers from different vendors may interchange and inter-operate. While this perspective is outside the scope of the Butlers architecture In this paper we put together house energy management with domotics, intelligent agents, ambient intelligence, ubiquitous technologies and gamification to depict novel scenarios where today’s pervasive technologies provide an innovative, comprehensive user experience enabling intriguing, advanced features. In the gamification perspective, we put special emphasis on the entertaining aspect and the social involving of new technologies to improve their acceptation and diffusion.As widely discussed above, there is an increasing industrial interest both on energy monitoring, controlling and saving systems, on the one hand, and on their integration with intelligent appliances  and on the practical side (e.g. how to properly integrate heterogeneous systems and technologies). Performance and robustness, in particular, will be key success factors. Of course, such aspects cannot be reliably evaluated on the current small prototype, not only because of its limited size and goals, but especially because the Butlers architecture accounts for many possible different systems, each with its own policies and objectives: so, vendors could make very different design and technical choices, with very different trade-offs between cost, performance, reliability, robustness, etc.It could also be worth highlighting that the Butlers architecture is not primarily aimed (only) at energy saving: it takes a much wider perspective – the comprehensive home management – where many other aspects are considered and integrated. So, while energy saving can be expected to be one of the most typical policies, a Butlers systems could well opt for  other goals and priorities – for instance, the maximum user’s comfort – which might potentially lead even to the opposite result – higher energy consumption at some times. These choices do not depend on the Butlers architecture: since the Butlers layers account for many possible different systems, each specific system reflects its vendor’s objectives, as well as the user’s preferences and desires. As a result, whether a given Butlers system leads to a gain in the environment, or helps in the sustainable living perspective, cannot be said in general: the potential is there, but its reification depends on the specific policies. The intriguing point, however, is that the widespread intelligence available in the most complete scenarios – namely, the Intelligent Butler, the Social Butler, and the Comprehensive Butler –, together with the knowledge of the user’s habits and his/her current position, allows for many potential optimisations in several directions, beyond the “pure” home management. For instance, the Butler could provide suggestions to the user in his/her everyday life, such as a home/work commute path that takes into account an extra intermediate stops at the supermarket  so as to save a further car trip, etc., thus promoting virtuous behaviour and overall contributing to a better living; and so on.For all these reasons, we believe that the perspectives discussed in this paper, despite the clear above-mentioned limits, are in the nature of things: technology is becoming more and more pervasive, awareness and intelligence in energy consumption, and more generally attention to the environment, are first-page issues everywhere. Our desire and expectation to control everything easily, remotely and from any kind of portable device at any time is also increasing, and so are our social presence online and our willingness to share where and with whom we are, and be possibly tracked for such purposes. So, eventually these aspects can be expected to merge – and home management, in all its many aspects and nuances, is too a killer application to miss it.aIn the USA and Canada, customers’ groups exist that claim possible health problems due to wireless interference from smart meters, claiming the right to switch back to analog meters. The debate is going on – see for instance  Conference, in Las Vegas (NV), 2010. See : the user sends a message with the bus stop number (e.g. 44) and line number (e.g. bus route 32) in a form like “44 32”, possibly adding the desired time (e.g. “44 32 1100” for 11 am), and gets the arrival time of the next two buses in response.