SmartProducts

Proactive Knowledge for Smart Products

SmartProducts
D.1.2.4: Final Concept for
Smart Products

WP 1 – Integrated Concepts for Smart Products
and Proactive Knowledge
Deliverable Lead: TUD
Contributing Partners:
OU, SAP, TUD, USFD, VTT

Delivery Date: 09.06.2011
Dissemination Level: Public
Version 1.0

Copyright  SmartProducts Consortium 2009-2012

SmartProducts

WP1 - Integrated Concepts for Smart Products and Proactive Knowledge

Deliverable

D.1.2.4: Final Concept for Smart Products

Deliverable Lead
Name

Organisation

e-mail

Daniel Schreiber

TUD

schreiber@tk.informatik.tu-darmstadt.de

Name

Organisation

e-mail

Daniel Schreiber

TUD

schreiber@tk.informatik.tu-darmstadt.de

Markus Miche

SAP

markus.miche@sap.com

Elena Vildjiounaite

VTT

elena.vildjiounaite@vtt.fi

Victoria Uren

USFD

v.uren@dcs.shef.ac.uk

Name

Organisation

e-mail

Andriy Nikolov

OU

a.nikolov@ac.open.uk

Contributors

Internal Reviewer

Disclaimer
The information in this document is provided "as is", and no guarantee or warranty is given
that the information is fit for any particular purpose. The above referenced consortium
members shall have no liability for damages of any kind including without limitation direct,
special, indirect, or consequential damages that may result from the use of these materials
subject to any liability which is mandatory due to applicable law. Copyright 2011 SAP, TUD,
USFD, VTT.

Smartproducts-d-1-2-4.doc
Copyright  SmartProducts Consortium 2009-2012

Dissemination Level: Public

Page 1

SmartProducts

WP1 - Integrated Concepts for Smart Products and Proactive Knowledge

Deliverable

D.1.2.4: Final Concept for Smart Products

Table of Contents
LIST OF FIGURES ................................................................................................................................................ 4
LIST OF TABLES .................................................................................................................................................. 5
EXECUTIVE SUMMARY .................................................................................................................................... 6
1

INTRODUCTION ........................................................................................................................................... 7
1.1

2

CHANGES COMPARED TO INITIAL VERSION ............................................................................................ 8

DEFINITIONS ............................................................................................................................................... 10
2.1

SMART PRODUCT.................................................................................................................................. 10
2.1.1
2.1.2

3

Characteristics of Smart Products ........................................................................................ 11
Problem Solving and Reasoning Capabilities of SmartProducts .......................................... 12

2.2
2.3

AMBIANCE ........................................................................................................................................... 13
CONTEXT.............................................................................................................................................. 14

2.4

2.3.1
Situation ................................................................................................................................ 16
USER .................................................................................................................................................... 16

CONCEPTS FOR SMARTPRODUCTS ..................................................................................................... 19
3.1

3.2

EMBEDDING IN AMBIANCES ................................................................................................................. 19
3.1.1
Description ............................................................................................................................ 19
3.1.2
3.1.3

Related Requirements ............................................................................................................ 20
Related Concepts ................................................................................................................... 20

3.1.4

Implementation ...................................................................................................................... 21

CONTEXT PROCESSING ......................................................................................................................... 23
3.2.1
Description ............................................................................................................................ 23
3.2.2
3.2.3

3.3

3.4

3.5

Related Requirements ............................................................................................................ 23
Related Concepts ................................................................................................................... 24

3.2.4
Implementation ...................................................................................................................... 25
DISTRIBUTED & SECURE STORAGE ...................................................................................................... 28
3.3.1

Description ............................................................................................................................ 28

3.3.2
3.3.3

Related Requirements ............................................................................................................ 29
Related Concepts ................................................................................................................... 31

3.3.4
Implementation ...................................................................................................................... 31
CONTEXT-ADAPTED & PERSONALIZED INTERACTION .......................................................................... 33
3.4.1
3.4.2

Description ............................................................................................................................ 33
Related Requirements ............................................................................................................ 34

3.4.3

Related Concepts ................................................................................................................... 35

3.4.4
Implementation ...................................................................................................................... 36
MULTI-DEVICE & MULTI-MODAL INTERACTION .................................................................................. 38
3.5.1

Description ............................................................................................................................ 38

Smartproducts-d-1-2-4.doc
Copyright  SmartProducts Consortium 2009-2012

Dissemination Level: Public

Page 2

SmartProducts

WP1 - Integrated Concepts for Smart Products and Proactive Knowledge

Deliverable

D.1.2.4: Final Concept for Smart Products

3.5.2

Related Requirements ............................................................................................................ 38

3.5.3
3.5.4

Related Concepts ................................................................................................................... 39
Implementation ...................................................................................................................... 39

4

CONCLUSION .............................................................................................................................................. 41

A

LIST OF ACRONYMS ................................................................................................................................. 42

B

OVERVIEW OF CONCEPT RELATIONSHIPS ...................................................................................... 43

REFERENCES ..................................................................................................................................................... 44

Smartproducts-d-1-2-4.doc
Copyright  SmartProducts Consortium 2009-2012

Dissemination Level: Public

Page 3

..... 18 Figure 4: Architecture for distributed context acquisition ............................ Arrows denote dependency............................................. ........................................... 28 Figure 6 Overview of concepts for proactive knowledge [D1................ Context Processing depends on functionality realized by Embedding in Ambiances ........................................................................................4: Final Concept for Smart Products List of Figures Figure 1: Overview on the Relationships between Concepts in [D1........g.3..... 8 Figure 2: Context is relevant and auxiliary information ............1...............2......SmartProducts WP1 ................ e...................................4]............................doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 4 ....... 16 Figure 3: Different users over the course of a smart products’ life-cycle ......................................................2] and smart products and their relationship...... 43 Smartproducts-d-1-2-4.........................Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.......... 26 Figure 5: Overview of the Distributed & Secure Storage .......2.........................

.. 25 Table 6: Requirements related to Secure and Distributed Storage .. 35 Table 10: Requirements for Multi-device & Multi-modal Interaction .. 31 Table 8: Requirements related to Context aware and Personalized Interaction ................. 20 Table 3: Relationship between Embedding in Ambiances and other concepts ............................Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D........................... 9 Table 2: Requirements Related to Embedding in Ambiances ........................... 39 Smartproducts-d-1-2-4.......................................2.............................. 35 Table 9: Relationship between Context-adapted & Personalized Interaction and other concepts ............................ 21 Table 4: Requirements related to the Context Processing ....1...........doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 5 .............................4: Final Concept for Smart Products List of Tables Table 1: Relationship of Final Concepts to Initial Concepts from [D1........2....SmartProducts WP1 .............................................................................. 24 Table 5: Relationship between Context Processing and other concepts ................................................. 39 Table 11: Relationship between Multi-device & Multi-modal Interaction and other concepts .....................1] ........................................................ 31 Table 7: Relationship between Distributed & Secure Storage and other concepts ............................

3. for deriving symbolic context information. It provides the means to store and retrieve non-volatile content to a dynamic network of smart products and back-end services.1. Context Processing is mainly realized by WP6 in the Context Manager component. It thereby contributes to the goal of achieving a natural product-to-human interaction. described in [D1.SmartProducts WP1 . Also. context (and situation). Embedding in Ambiances is mainly realized in the Communication Middleware component developed by WP6. this document contains definitions of the most important terms for understanding smart products: smart product. Context-adapted and Personalized Interaction deals with the adaptation and selection of user interface representation for interacting with the user.2]. which are implementations of the Embedding in Ambiances concept.4: Final Concept for Smart Products Executive Summary Successfully developing smart products requires addressing many ubiquitous computing challenges.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.2. Furthermore. The SmartProducts project realizes five concepts related to SmartProducts: Embedding in Ambiances. It uses the Communication Middleware and Web service bridge for its communication needs. Smartproducts-d-1-2-4. Distributed and Secure Storage is mainly realized by WP4 in the Ubiquitous Storage and Access Manager components. a part of Managing Proactive Knowledge [D1. Context Processing. for sharing context information. the Multi-device and Multi-modal interaction concept enables smart products to use interaction resources in an ambiance. It uses the Context processing capabilities of a smart product. These concepts are related among each other and to the concepts for Proactive Knowledge.2]. which choses the UI representation that bests fits the user or user group and context at hand. ambiance. It provides the functionality for sharing and using resources in an ambiance.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 6 . Context-adapted and Personalized Interaction and Multi-device and Multi-modal interaction. This deliverable summarises the overall approach of the SmartProducts project towards these challenges. The context information is processed by an automatic selection mechanism. Finally. It builds on the concept for embedding smart products in ambiances.3. it is used for distributing task information. which challenges we consider most important and the concepts we employ to address them in a software platform. it can make use of the reasoning capabilities of a smart product. Distributed and Secure Storage. and user. Furthermore. It uses the Communication Middleware to connect to these resources and provides rendering capabilities for the UI to the smart products platform.

Since terms like “smart product” potentially raise very different expectations in the reader. such as the support for procedural knowledge have even been integrated with the concepts for proactive knowledge.2. which challenges we consider most important and the concepts we employ to address them in a software platform.2] were considered too general.Implementation – summarises the chosen approach to the concept realisation referring where necessary to the relevant WP2-WP6 deliverables.3. this deliverable provides an overview of the relationships between the concepts. The presentation of the concepts was also changed compared to [D1. The concepts described in this deliverable are closely related to the concepts for proactive knowledge. The initial set of 16 concepts from [D1. the concept descriptions in both deliverables cross-reference each other. designing solutions and implementing trials. The remainder of this document is structured as follows.2]. Figure 1 shows a graphical overview of the relationship between the concepts described in this deliverable. Other concepts. Most important. Grasping the relationships between the concepts implemented in different technical work packages would be difficult by just reading the respective concept. . which are listed in [D1.2.1. We explain the concepts using the same structure as [D1.2]. since the requirements from [D1. we furthered our understanding of the problem space by investigating the three application scenarios. we provide definitions for key terms Smartproducts-d-1-2-4.3. There are two main reasons for this reduction in the number of concepts.3. (Secure and Distributed Storage and Context-adapted and Personalized Interaction) the more detailed requirements from the respective requirements documents of the technical work package are listed.2].Description .provides a synopsis of the concept.2]: . Thus.4: Final Concept for Smart Products 1 Introduction Successfully developing smart products requires addressing many ubiquitous computing challenges. and thus could be merged.Related concepts – lists related concepts including both the concepts from this deliverable and [D1.1. Some concepts proved to be just variants or facets of a more profound and powerful concept.2] and not in this deliverable.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 7 . and therefore they are described in [D1. .1.2. We focus on the implementation of the concepts in the technical work packages and the relation between the concepts.3.SmartProducts WP1 . This deliverable summarises the overall approach of the SmartProducts project towards these challenges.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. Thus. For two concepts.1].1] has been condensed into just 5 concepts in this deliverable. design and implementation deliverables of the individual technical work packages. .Related requirements – lists relevant requirements from the revised set reported in [D1.

SmartProducts WP1 .4].2.2.1].. In Section 3 the concepts and their relationships are described using the structure from above. the concepts in this deliverable have been revised from an earlier version [D1. Arrows denote dependency. e.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 8 .2.g. Table 1 summarizes the relationship between initial concepts and revised concepts.4: Final Concept for Smart Products used in the project in Section 2.1 Changes compared to Initial Version As explained above. Context Processing depends on functionality realized by Embedding in Ambiances. Section 4 concludes the deliverables. Concepts (initial) Concept (revised) Communication Middleware Scalable Hardware Platform Embedding in Ambiances Distributed Acquisition and Reasoning of higherlevel context Context.and Situation Awareness Sensing Capabilities Context Processing Distributed Storage Distributed & Secure Storage Smartproducts-d-1-2-4. Figure 1: Overview on the Relationships between Concepts in [D1.1. 1.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.

2.4: Final Concept for Smart Products Proactive Content Replication Decentralised Synchronisation Trust based collaborative defence Adaptation to Users and Situations Usable Security Interaction Paradigms Context-adapted & Personalized Interaction Multimodal Interaction Verbalizing Proactive Knowledge Multi-device & Multi-modal Interaction Usage and Maintenance of Procedural Knowledge Problem solving knowledge [D1.2.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.1.2] Smart Products Platform Architecture Used for implementation.1] Smartproducts-d-1-2-4.SmartProducts WP1 .3.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 9 . but not treated as a concept Table 1: Relationship of Final Concepts to Initial Concepts from [D1.

requires a considerable level of openness on the product's side. In the SmartProducts project. we put a focus on tangible smart products and not on exclusively virtual products.1 Smart Product In general. There are different reasons for adding “smartness” to products.e. repair and use. Simplicity is desirable during the entire life-cycle of the product. to support manufacturing. which are capable of running at least a minimal software platform themselves. There are three core requirements for these products: adaptation to situational contexts. such as software or services. communication infrastructures and IT services. In the latter case. This software can run directly on the device. “rich context representations. adaptation to actors that interact with products and adaptation to underlying business constraints. in particular.2. sophistication and diversity of product components (for example. or Smartproducts-d-1-2-4.4: Final Concept for Smart Products 2 Definitions 2. i. This adaptivity is enabled by three main technologies: sensing technologies which ensure sensing the global and the local context of a product (using global or local sensors respectively).SmartProducts WP1 .1. the connection to the physical device is maintained by technologies such as RFID. [Maass-2008] defines smart products as products that are adaptive to situations and users. As early as 2005. to be capable to predict errors and faults thus “removing unpleasant surprises from [the users'] lives". a “smart” item or object denotes a physical item that is somehow enhanced with software. representations about product capabilities and domain knowledge” in order “to infer how to learn from and adapt to users and situations".Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. such as sensors and smart labels (RFID tags). and rather focus on more powerful smart products. as well as the tendency of the suppliers and manufacturers to become increasingly independent of each other. In 2008. and the increased need for having products operate in open environments. equally important for smart products to tap into existing infrastructure. In the SmartProducts project we investigate how smartness can address two major trends with technical products: the increased need for simplicity for users in the face of products with complex functionality.. or in the infrastructure. They regard “smartness” as the product's capability to be pre-emptive. Allmendinger and Lombreglia investigate the notion of smartness in a product from a business perspective [Allmendinger-2005]. The increased number. Such smart products are capable to create their own infrastructure in a purely bottom-up way. The SmartProducts project aims to prove that these trends can now be addressed thanks to major developments in IT (since many facets of smartness are linked to research in this area) as well as advances in ubiquitous computing that provide “real world awareness” in these systems through the use of a variety of techniques. in the car industry). In the SmartProducts project.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 10 . however. we do not investigate this case. In practice it is.

they should be able to gather sensor information from other smart products to better understand the current situation..Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. Because the goal of the project is to provide an industry-applicable. while openness depends on improved product-to-product interaction.1. Even though every smart product has some built-in capabilities.g. consisting of a physical object and a software object. A key research problem is the integration of these knowledge intensive techniques with ubiquitous computing techniques. we take a special focus on workflows.1. and contain the necessary problem solving knowledge and reasoning capabilities for doing so (see Section 2. It is capable of self-organized embedding into different ambiances over the course of its life-cycle. such as planning-based approaches should co-exist with workflow-based knowledge.1 Characteristics of Smart Products The definition of the SmartProducts consortium stresses the ability of a smart product to engage in natural and purposeful interaction with a human user.SmartProducts WP1 .2). To improve product-to-human and product-to-product interaction. Simplicity can be achieved with improved product to user interaction.e.4: Final Concept for Smart Products wearable and embedded computers. In our view this can only be achieved if the smart product is able to take the initiative in the interaction with the user. large screens) to facilitate the interaction. it provides built-in resources and knowledge in the ambiance for other smart products to use (product-to-product interaction). semantic descriptions of product capabilities and AI planning for self-organization need to be adopted. 2. At the same time.2.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 11 . knowledge intensive techniques. i. such as storage. To do so.2). The SmartProduct project defines smart products as follows: A smart product is a hybrid entity. More flexible problem solving approaches. For example. which are a special case of procedural problem solving knowledge. to achieve simplicity even when interacting with complex products.1. the smart product must have an understanding of the task that needs to be accomplished. We define the resulting ensemble as ambiance (see Section 2. lifecycle-spanning methodology with tools and platforms to support the construction of smart products. which are built-in or provided by the ambiance. They should be able to use actuators on other smart products in order to automate tasks for the user and to use interaction capabilities in the environments (e. It uses resources. Smartproducts-d-1-2-4. it is clear that smart products need to inter-operate to overcome limitations of their individual capabilities. input or output capabilities and knowledge. Smart products must therefore be capable to use and provide resources in a smart products environment. with the goal of natural and purposeful product-to-human interaction. if it acts in a proactive way. such as reasoning for adaptation.

Domain knowledge. Thus. and how these goals can be realised through decomposition of tasks and inferences. progressing to the next step in a problem solving process or instantiating a new problem solving method to address a task. a knowledge model consists of three parts (knowledge categories). even though it could theoretically be avoided.and output-devices from desktop computers. . the user does not perceive the interaction with the smart product as an overhead at all. keyboard and screen.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 12 . but also incorporates more abstract information. such as voice recognition. each capturing a related group of knowledge structures: . user interaction may be appropriate in some circumstances. We provide a core ontology which includes definitions of high-level context-related concepts which can be extended with domain-specific entities.. a smart coffee machine could use a central touch screen located in the kitchen.2. 2.. such as the current location. Information from physical and virtual sensors can be used to adapt the application of problem solving knowledge to the environment of a product. Interaction with users has to be performed using different built-in interaction capabilities. user interaction cannot be avoided in all cases. but rather to enable better and more natural embedding of smart products in existing environments. Even though smart products should be able to apply their problem-solving knowledge autonomously.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. such as mouse. see Section 2.1. In conclusion. For example.2 Problem Solving and Reasoning Capabilities of SmartProducts According to the CommonKADS methodology [Schreiber-2000]. This is however not done to increase the efficiency of the interaction.SmartProducts WP1 . Multiple smart products can exchange sensor and task information to generate a distributed context-awareness. e. Smartproducts-d-1-2-4.3. which describes what goal(s) an application pursues. or using interaction capabilities provided by the ambiance.1. which describes the domain and information types.g.. to increase the intelligibility of smart products. the interaction with the user needs to be multi-modal and needs to span multiple devices. This ontology constitutes a part of the SmartProducts network of ontologies (see [D1. Smart products usually do not come with standard input. Very promising for enabling interaction with smart products is the use of mobile phones as terminal devices.Task knowledge.e. Context representation relies on a common format (in the form of RDF triples) and domain specific conventions that will be implemented in different smart products for interoperation.3. the projects notion of context-awareness does not refer only to physical information. Smart phones are easily portable and provide interesting interaction capabilities.2]). i.Inference knowledge. . This can be achieved in multiple ways.4: Final Concept for Smart Products We think that the most natural form of interaction is implicit interaction. or use voice interact enabled by a central microphone array. For details on context processing. which describes the basic inference steps constituting the building blocks of the reasoning process. such as currently pending tasks. e.g. Also.

the formal structure of knowledge is defined using ontologies expressed in standard Semantic Web languages (RDFS+OWL). We agree with the point of view expressed in [Russel-2002]. 2. Two types of knowledge components which contribute to reasoning capabilities are:  mechanisms for reasoning with formal knowledge.  problem-solving components.2. but includes also software services that interact with smart products. This adaptive/proactive knowledge block constitutes the reasoning capabilities of a smart product. the reasoning mechanisms implement standard semantics of these languages and. “an agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through effectors”. By embedding we mean that a smart product should be able to use resources and information available in the ambiance. these capabilities are realised by the reasoner component of the semantic data management infrastructure. are capable to process custom-defined rules which express domain-specific inferencing steps. Ambiance or (smart) environment are very general terms used with very (or sometimes slightly) different meanings. Thus. that an ambiance is synonymous to the term smart environment. however. such as a recipe database accessed from the kitchen over the internet. Problem-solving components [Motta-1999] make use of these generic formal reasoning mechanisms in order to reach specific goals and realise proactive behaviour of a product (e. One common approach is to define environment in combination with and by its relation to an agent [Russel-2002]. as well as to provide resources and information to other smart product in the ambiance.g.SmartProducts WP1 . In the context of the project. Note.2 Ambiance Smart products should be able to embed themselves into multiple ambiances over the course of their life-cycle. which are not located in the kitchen.. which is also used. which was restated in [Franklin-1997]: The concept of agent (and consequently that of environment and ambiance) Smartproducts-d-1-2-4.1.g.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.4: Final Concept for Smart Products In these terms. At the architecture level. Problem-solving methods specify how these goals can be reached through task-subtask decomposition and a sequence of atomic reasoning steps. in addition. Mechanisms for reasoning with formal knowledge implement generic inferencing procedures which are able to i) infer new knowledge from available passive knowledge and ii) trigger actions based on changes in the state of passive knowledge. the declarative or passive knowledge block of the product’s proactive knowledge corresponds to the domain knowledge category. determine which daily diet plan to suggest to the user). We use the term ambiance instead of the more common environment to emphasize that an ambiance is not restricted to a physical environment. and the adaptive/proactive knowledge block realises the task and inference knowledge categories. e. such as a kitchen.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 13 .

2. whether that is actually justified or not. non-smart product entities and which can be attributed with certain well-known properties. such as the time of the day. join and leave ambiances. With the implementation of zones in the communication middleware.e. we purposefully exclude any unknown influences.1.2. The entities in the ambiance may reflect real.4: Final Concept for Smart Products should be used as „tool for analyzing systems. a chair in the kitchen.SmartProducts WP1 . what is the boundary.g. ambiances are implicitly supported by the boundaries of the network communication. a new component needs to be introduced into the ambiance. An analogy from physics is the abstraction of a "closed system". Introducing a new source of influence is possible. i. who can code that knowledge into all parts of the system. not an absolute characterization that divides the world into“ environments and non-environments (cf. A smart product is thus a reactive agent (see [D1.3.2]).doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 14 . all components in an ambiance need to be connected to the same IP subnet or their IP address needs to be configured externally. however it needs to be made explicit. a kitchen stays the same ambiance no matter of the components that are contained in it at any point in time. enabling smart products to actively create. thereby adding another level of self-organization. By deciding to regard something as an ambiance. We propose the following definition for ambiance.e. either statically or dynamically. It is possible that components enter or leave the ambiance. how can we distinguish outside and inside. but they may also reflect virtual components.. e. which is used in the SmartProducts project: An ambiance is an identifiable container with a clear boundary that may contain smart products and other. That is why the container has an identity in its own right.. such as a recipe database accessed from the cloud. Per default. and is not identified by the contained components. [Russel-2002]). ambiances are supported in the SmartProducts platform. Entities inside the container can influence each other but they are not influenced by anything outside the container. For smart products systems this approach is not feasible. For example.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. we should be able to exactly specify what constitutes the identity of the ambiance. When we do so. If one designs a computing system in a top-down way. without human intervention. The well-known properties refer to abstract conditions. all aspects of the ambiance in which it will run are known to the designer. since they are specifically designed to be embedded into multiple and differing ambiances over the course of their life-cycle. The smart products in an ambiance have to autonomously construct a model of the ambiance in Smartproducts-d-1-2-4. The main purpose of the ambiance abstraction is that we assume all influencing factors inside the ambiance are known.3 Context Part of the perceived smartness of smart products comes from their ability to react to their ambiance. In the implementation of the SmartProducts platform.. physical components. i.

is not part of the context of a smart product. when researchers started to develop applications that incorporated the current location of users. As location-awareness is still regarded as a subset of context-awareness. the definition has the shortcoming of defining context by means of other ill-defined terms such as “situation” or ”relevance”. every application could be called context-aware. There are. For example.. etc.) and interfering physical or virtual properties (noise level.4: Final Concept for Smart Products order to use the resources provided and to adapt their actions accordingly.g. that do not regard location as auxiliary but rather as mandatory information. e. We define as follows: The context of a smart product comprises all aspects of the ambiance. but also from virtual sources. By then.g. which can come from physical sensors. place. task at hand. In our definition we focus on the original approach and thus refer to context as the intersection of „Relevant Information“ and „Auxiliary Information“ as visualized in Figure 2. e. This definition is in line with the definition used in the field of context-aware computing. such as characteristics of the user (her location. smart products announcing tasks in an ambiance. the most prominent context definition by [Dey-2001] (“Context is any information that can be used to characterize the situation of an entity. can be referred to as context.).. In our example. The term “context-aware computing” became popular in the mid-1990s. An entity is a person. etc. The model a smart product constructs for the ambiance is called its context. which can be detected and reacted upon by the smart product (relevant information). including the user and applications themselves”) solves this problem by limiting the context to all information that is relevant to the interaction between user and application.SmartProducts WP1 . Thus.1. or object that is considered relevant to the interaction between a user and an application. the latter lost its connotation of using auxiliary information. nearby resources. however. Smartproducts-d-1-2-4. the term context became more difficult to define. all information that can be processed by the application would be referred to as context (see “Relevant Information” in Figure 2). such as navigation systems. We do not consider the source of the information. Thus. user input. However.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. locationawareness was regarded as the most important subset of context-awareness and often used synonymously.2. Another problem that arises from Dey's definition is that even information that the application needs to fulfill its tasks. We only refer to those aspects of an ambiance as context that are not mandatory for the operation of a smart product (auxiliary information). such as location sensors. a growing number of applications. in our example the customer number and the number of people traveling.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 15 .

4 User The term “user” and “end-user” are not clearly defined in scientific literature. However.g. “a situation represents the semantic interpretation of context.SmartProducts WP1 .g.1. and is generally derived by fusing several pieces of contextual information in some way.. The term situation refers to a higher-level concept of a state representation. with potentially many different contexts being indicative of the same situation” [Dobson-2006]. however skilfully.3.2. There exist different notions in literature for referring to this higher-level context. for example: A user is • “a person or thing that uses something (stated or implied)” [Yourdictionary] • “a person who uses a computer or Internet service” [Wikipedia-user] • “someone who uses a program.4: Final Concept for Smart Products Figure 2: Context information is defined as relevant and auxiliary information 2. Dobson-2006] are the most common ones. Situational context [Gellersen-2002] and situation [Dey-2001.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.” [foldoc] An end-user is Smartproducts-d-1-2-4. it is useful to abstract from this lowlevel context information. e.1 Situation Especially for context information from physical sensors.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 16 . e. by inferring a meaningful label for the user’s activity from acceleration data. In the SmartProducts project. without getting into the internals of the program. 2. we define the term situation as follows: Situations are interpretations of context that can be used by a smart product to trigger actions in a problem solving process. there is a common understanding of the meaning of these terms.

support service workers) or just of the functionality provided by it without getting into the external of the platform. They have some technical expertise. there are three types of target users considered in this project.e.2. necessary if one considers the whole life-cycle of a smart product.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 17 . for example.e. but also of the software of the products. 2) Support service workers – persons who are responsible for maintaining the smart product. They are expected to have technical expertise in developing smart products. developed for the “usage” stage of the product lifecycle) and maintenance workshop workers who repair or replace products’ hardware (these persons act as end-users of the functionality. owners of smart vehicles or smart coffee machines (these persons act as end-users of the functionality. 3) Smart product end-users – ordinary people who use smart products in their everyday life or work with smart products. for example.1. Support service workers act as end-users of the SmartProducts platform and the supporting tools. they do not have to be as skilled as smart products developers. developed for the “maintenance” stage of the product lifecycle). Note that considering the developer as a user is uncommon. : 1) Smart product developer – persons who will design workflows for smart products and act as end-users of SmartProducts platform and supporting tools. Smartproducts-d-1-2-4.SmartProducts WP1 .4: Final Concept for Smart Products • • “the ultimate user for which something is intended” [Wordnet] “the end-user is a concept in software engineering. The difference between smart products end-users and support service workers is thus whether they are end-users of the smart products platform (i. such as workflow editor etc. for updating workflows when new aircraft assembly methodology is adopted. however. referring to an abstraction of the group of persons who will ultimately operate a piece of software (i. This can involve maintenance of the hardware.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. However. the expected user or target-user)” [Wikipedia-enduser] As the SmartProducts project aims at supporting humans during different stages of product life-cycle.

4: Final Concept for Smart Products The graph in Figure 3 illustrates in which step of the lifecycle which users need to be supported.1. Thereby we distinguish between smart products developers (end-users of the SmartProducts platform.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 18 . smart product developer smart product end-user Support Service Worker Support Service Worker Smart Products end-user Smart Products end-user Figure 3: Different users over the course of a smart products’ life-cycle To sum it up.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.2.SmartProducts WP1 . we define a user as follows: A user of a smart product is a person who uses the functionality and/ or the supporting tools of smart products. some technical skills required) and smart products end-users (end-users of the functionality provided by smart products. support service workers (end-users of the SmartProducts platform. Smartproducts-d-1-2-4. technically skilled). no technical skills required).

2] is given in Section 3. which have been detailed in [D6.1. e. the communication solution needs to support automatic node discovery. for exchanging task information and context information from sensors  Between smart products and interaction devices.  Between multiple smart products in an ambiance. smart products should not rely on this feature for their base functionality.4: Final Concept for Smart Products 3 Concepts for SmartProducts 3.. The communication middleware is embedded in the software of each smart product. Since Internet connectivity is not provided in every ambiance. and to use resources. certain requirements for the Communication Middleware can be identified. the former two cases demand that communication is enabled in an ad-hoc manner without relying on a central infrastructure service for managing the ambiance. e.1.SmartProducts WP1 .Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. such as screens or mobile phones.1 3. the smart product needs to be able to connect to these back-end systems as well.1. Therefore.. the Communication Middleware is used in different settings.2. e. an Internet gateway is needed. peer-to-peer routing.1]. The integration of smart products in an ambiance needs to be loose. Since smart products are hybrid entities and the computing resources of their physical part may be constrained.g. meaning they should provide resources to an ambiance and use resources in this ambiance provided by others (smart products or infrastructure). a screen built-into a smart fridge can be used as a shared screen in the kitchen). (Note that these terminal devices can be made available as parts of other smart products. If this is the case.1. to invoke functionality that cannot be run on the hardware of the smart product.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 19 ..g. An overview of the overall requirements for the Communication Middleware from [D1. Resources are shared in an ambiance using a Communication Middleware. since ambiances are Smartproducts-d-1-2-4.2. Thereby.g.1 Embedding in Ambiances Description Smart products are expected to embed themselves into ambiances. parts of the software may have to be moved into back-end systems. For the latter category. Within each of these categories. The communication between smart products and the gateway is comparable to the other cases. and peer-to-peer messaging.  Between smart products and back-end systems. Smart products developers can use this middleware to make product specific resources available (such as the coffee machines capability to brew coffee). The interaction models needed for communication in smart products systems are also diverse. allowing a smart product to contact the ERP system of a company.1. For example.

the Ubiquitous Storage components of each smart product in an ambiance communicate Smartproducts-d-1-2-4.SmartProducts WP1 .3 Smart products shall make context information and functionality (e. multiple interaction models are supported. Also. a smart product can utilize context information that is originally sensed by another smart product. Table 3 provides an overview of the relationships.g. Functionality of back-end services is most easily triggered from the smart product using remote method calls.1 Smart products shall be able to communicate with other smart products.COM. In the middleware developed in the SmartProducts project.COM. using an existing network infrastructure SP. Publish / subscribe communication addresses this. the Communication Middleware is needed to distribute information about pending tasks in the current ambiance.. often some kind of service discovery is needed to find and reserve suitable resources. 3. Related Concept Description Context Processing Context Processing relies on the Communication Middleware to distribute context information in an ambiance.COM..g. On the other hand. Thereby.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 20 .g. e. Table 2 show an overview of the requirements for the SmartProducts Communication Middleware.4: Final Concept for Smart Products constructed in an ad-hoc way. and thereby derive a better understanding of the current situation.1.3 Related Concepts Embedding in ambiances is a direct or indirect prerequisite for all other concepts described in this document.2. Thereby.5 Smart products shall discover other available smart products together with the functionality and proactive knowledge they provide.COM. brewing coffee) available to other smart products and the user over the network. for the communication with interaction devices. Requirement Description SP. central storage.2 Related Requirements Exiting approaches for communication middleware support only one (or a very limited number) of interaction models at the API level. web services and enterprise messaging SP.2 Smart products should be able to communicate with back-end systems (e. Distributed & Secure Storage The Distributed & Secure Storage is realized by distributing content in an ambiance via the Communication Middleware and to back-end storage via the Webservice bridge.1.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.1. SP. Table 2: Requirements Related to Embedding in Ambiances 3.

using the publish/subscribe communication feature of the Communication Middleware. interfaces for RPC calls can be specified in WSDL. for realizing the embedding of smart products into ambiances. brewing coffee) available to other smart products and the user over the network. like smart phones. and that capabilities will rise. Some believe that this phenomenon is slowing and that this may have a strong impact on the hardware/software technology business [Feldman-2009]. MundoCore has been released under MPL and is available for download from the SmartProducts website. MundoCore complies with established standards.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. we expect that smart products will Smartproducts-d-1-2-4.. Table 3: Relationship between Embedding in Ambiances and other concepts 3. An additional part of the communication middleware component developed by the SmartProducts project is a Web service bridge. The interaction resources are accessed via RPC performed with the Communication Middleware. To detect available interaction resources. Multi-device & Multimodal Interaction Multi-device & Multi-modal Interaction can use interaction resources provided by other smart products or dedicated interaction devices. From this. The International Technology Roadmap for Semiconductors is an assessment of the semiconductor industry's technology requirements and can provide insight on how the Semiconductor industry plans to move forward in the future [ITRS]. we assume that prices will fall.1. A critical factor of the communication middleware is its footprint. MundoCore is capable of working in peer-to-peer mode. since it is the minimal software component that needs to be deployed on the physical smart product. MundoCore provides programming abstractions to perform remote procedure calls (RPC). Problem Solving Knowledge Collaborative task solving based on problem-solving methods serves as a means of integrating the smart product’s capabilities into its ambiance. Moore’s law has provided dividends to hardware and software designers over the past 40 years [Larus-2009]. as well as simple channel and content based Publish/Subscribe communication. which allows for taping into existing web services and to provide web services from a smart product. e.1.4 Implementation The SmartProducts project builds on the MundoCore middleware [Aitenbichler-2007].SmartProducts WP1 . For the purposes of the SmartProducts project.g.2. the discovery mechanisms of the Communication Middleware is used.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 21 . other smart products in the same network are automatically discovered and routes to them are maintained.4: Final Concept for Smart Products with each other in a peer-to-peer fashion. in the ambiance.

MundoCore The task of the MundoCore communication middleware is to enable easy sharing of resources in smart product ambiances over computer networks. Web Service Bridge The web service bridge provides mappings of smart products code to REST style web services as client and server.2]. e. we assume that an IP stack is available on each smart product. The implementation and API is described in [D6.2.2]. Smartproducts-d-1-2-4. Communication Middleware .SmartProducts WP1 .g.3.3. Details about the implementation of the MundoCore communication middleware and documentation how it is used can be found in [D6.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.. [D6.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 22 .1.1] describes the initial version of the communication middleware.4: Final Concept for Smart Products become cheaper and better resourced and this will have an impact on their capabilities.345.

this processing can be done for each smart product individually.CTX. Gathering and processing information from physical sensors For physical context information. there may be product specific usages of context. The context processing framework of the SmartProducts platform builds on top of the communication middleware to provide a common context model for all smart products in an ambiance. often problematic to use in smart products.CTX.3 Smart products should be able to perform context-triggered actions Smartproducts-d-1-2-4.3.2.2] relevant for context processing. deriving situation information.. can be perceived by the software of the smart product. as defined in Section 2.g. 3. The SmartProducts platform provides a framework for integrating hardware sensors into smart products and analyzing the low-level data generated by them. such as the tasks shared in an ambiance. such as micro switches.2 Related Requirements Table 4 summarizes the requirements from [D1. Supporting good integration with sensor hardware and algorithms for processing their data is a very important aspect of context processing. Such distributed context processing is greatly supported by using a common framework on all smart products. adapting the torque settings of a wrench taking into account the wear and tear.g.2 Context Processing 3.2 Smart products should be able to monitor its context and react to developer specified situations (e. Information retrieved directly from physical sensors is. just utilizing information from built-in sensors.2. temperature sensors or RFID readers.. emit a warning when it is placed in a dangerous situation) SP. progressing to the next step in a workflow or starting a new problem solving process. however.1 Description Smart products must be able to process context information for various purposes. e.2. Furthermore. since it is instable and changes frequently.  virtual properties of the environment.1.SmartProducts WP1 . Constructing shared context models The usefulness of context information is increased.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 23 .1. such as.4: Final Concept for Smart Products 3.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. There are two basic ways in which a smart product can get context information:  physical properties can be sensed through sensors. Requirement Description SP. and come to a common representation of their current context. if multiple smart products share their context information.

The context processing infrastructure is thus the key integration point with the concepts for proactive knowledge [D1. SP.3 Related Concepts We use a fairly broad definition of context (see Section 2.2. in particular the ontologies for context information. described in [D1. SP. “experienced Personalized Interaction user”.3. Managing Proactive The Context Processing Widgets can tap into the reasoning Smartproducts-d-1-2-4. symbolic notion of context is also used for adapting the interaction with the user.2].CTX. such as “nightime”. so that Context Processing Widgets can be more easily reused.4 Smart products should be able to locate themselves w. Thereby. Related Concept Description Embedding in Ambiances Smart products in an ambiance exchange context information with each other using the Communication Middleware. Table 4: Requirements related to the Context Processing 3.CTX. It is the responsibility of the Context Processing Widgets (potentially in combination with the reasoning capabilities) to infer this symbolic information. Smart products should be able to simultaneously be part of multiple environments at the same time. where the client is asynchronously notified of certain context information via the publish / subscribe functionality of the middleware. the Context Manager. SP.3. Additionally. Table 5 shows an overview of the related concepts.r. etc. This higher-level.4: Final Concept for Smart Products (process step done.2] The context processing framework makes use of the domain models.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.CTX.2]. are needed by the UI Adapter.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 24 . Context-adapted & Symbolic situation information.3. using local or remote procedure calls. On the other hand.7 Smart products should be aware of their context perceived through sensors in the environment and sensors in the smart product itself. the Context Manager supports push-based interaction.SmartProducts WP1 . and the Context Processing Widgets running in it connect to the sensing hardware of smart products and the Communication Middleware.2) comprising task and situation context. their environments. something was collected by the user).t. Sensors deliver their information as RDF triples.1.5 Smart products should be able to identify their current environment and identify those smart products that also inhibit this environment.2. it is possible to use queries for current or recent context information. Modelling Smart Products Domain [D1.

3. information about pending tasks is published and consumed as context information. to specify when a step in a workflow can be assumed to be completed. Each smart product has a Context Manager component. where simple rule-based approaches do not suffice.4 Implementation The implementation of the context processing framework in the SmartProducts platform is shown in Figure 4.3. Problem solving knowledge [D1.1. Context Processing Widgets are responsible for detecting situations. When problem solving knowledge is applied. and reasoning can be performed in the widgets.3.SmartProducts WP1 . This data is interpreted by Context Processing Widgets inside the Context Manager. e. which takes the raw data gathered from sensors and exchanges context data with other smart products over the communication middleware. Table 5: Relationship between Context Processing and other concepts 3. enabling the developer to combine existing Context Processing Widgets that adhere to that representation.2] capabilities of the smart product to perform symbolic processing of context information.2. Inside the Context Manager context data is represented using an internal data structure optimized for efficiency. Smartproducts-d-1-2-4.4: Final Concept for Smart Products Knowledge [D1..2]).2. It can be converted into an ontological representation following the SmartProducts network of ontologies (see Modelling Smart Products Domain Domain [D1.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 25 .g.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.2] The problem solving knowledge may contain explicit pointers to certain situations.

supports the smart products developer in connecting to the sensor hardware and converting the resulting data into the Context Model representation. Smartproducts-d-1-2-4. An initial version has been delivered as [D6. e.g. raw data from a location sensor is processed by a Kalman Filter widget. Thereby.4. to smooth the values. For example. The SmartProducts platform Sensor/Actuator Integration Framework. Sensor/Actuator Integration Framework Gathering data from hardware sensors is normally tedious..doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 26 . e. described in [D6..2. the role of the Context Manager is to coordinate the way in which context data is processed by the different widgets. by comparing data from sensors to constant values.2]. This approach is similar to the Context Toolkit [Dey-2006].1.345.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.1]. using machine learning approaches to derive posture from the readings of accelerometer sensors. as the developer has to deal with the peculiarities of device-driver level programming.SmartProducts WP1 .g. other situations can only be inferred by using symbolic reasoning. The SmartProducts platform provides a framework for processing context information accompanied by a library of existing Context Processing Widgets for common tasks.4: Final Concept for Smart Products Communication Middleware MundoCore Sensor accelerometer RDF triples Situation Recognition Smoothing Activity Recognition Location Model Developer Context Manager Context Processing Widget Figure 4: Architecture for distributed context acquisition Situations can be derived following simple matching rule. Other situations require more complicated processing. Context Manager The Context Manager component hosts a graph of Context Processing Widgets. Yet.

Furthermore. The Context Manager connects to the Communication Middleware component.SmartProducts WP1 . This approach enables developers to reuse widgets in different smart products. The input and output of each widget should be RDF triples following the specification of the Context Model.2. Standard widgets provided by the platform comprise simple widgets for subscribing to context from the communication middleware. at which intervals.5. a rich set of widgets for location data is available. if the derived context information should be published. Details about the available widgets and their implementation are described in [D6. Context Processing Widgets The main work of context processing is done inside widgets. so that widgets can publish context information in the ambiance. by matching it to a location model. The convention is to use the URL of the context type in the Context Model ontology as a channel name.1.5. and widgets for simple arithmetical calculations and comparisons triggering certain situations.4: Final Concept for Smart Products The next step could be the combination of this numerical information into a symbolic location.2]. and if so. Details about the available widgets and their implementation are described in [D6. Smartproducts-d-1-2-4. and subscribe to context information.2].doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 27 .Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. It can be configured in each widget.

3 Distributed & Secure Storage This document contains an abstract of the concepts underlying the distributed and secure storage of proactive knowledge.2].1 Description Smart products require to store and access non-volatile content across their product life-cycle that needs to be highly available.2. such as files and knowledge sources. or media for user interaction. An overview of these concepts is depicted in Figure 5Fehler! Verweisquelle konnte nicht gefunden werden. The context processing Smartproducts-d-1-2-4. distributing. Distributed Storage Search Replication & Consistency Maintenance Security Administration Multi-Factor Authentication P2P Overlay Network Adapter Multi-Level Access Control Distributed Storage Framework Security Secure Distributed Storage Framework Figure 5: Overview of the Distributed & Secure Storage 3. The challenge addressed by the SmartProducts project is:  Develop a scalable storage infrastructure that supports traditional APIs. back-end systems and other smart products in the ambiance.SmartProducts WP1 . as well as for security and privacy of proactive knowledge are presented in the two final concept deliverables [D4.4: Final Concept for Smart Products 3. both for back-end business systems as well as for the smart products in an ambiance. like images illustrating car-part mounting procedures. however. Smart products are in general. durable. and maintaining proactive knowledge.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 28 . Traditionally. taking into account storage services provided by back-end systems. Examples for non-volatile content are models for domain knowledge.3] and [D4. such as for retrieving files (exact match queries or keyword search) and querying knowledge (SPARQL queries) but distributes content automatically to different places.2. such content is stored in a local file system.1. like recipe information in the smart consumer appliances use case. and accessible with low latency. database or triple store.3. not capable of storing all content required during their life-cycle on-board.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D..1. The distributed storage is optimized for larger objects. Detailed descriptions of the concepts for storing.

3 Smart products shall be able to maintain metadata incl.2.13 Smart products shall provide content version management functionality.1 Smart products shall be able to store content on-board (i. In the SmartProducts project.22 Smart products shall share part of their storage capacity in order to enable other smart products to store content off-board. since smart products may store sensible information.SD. or other authorized smart products.11 Smart products shall be able to execute read and write operations on related content independent of where this content is stored.e. SP.2 Smart products shall receive an unambiguous confirmation whether read/write operations have succeeded independent of where content is stored.21 Smart products shall be able to store content off-board either on related business systems or other smart products in their environment.SD. and query efficiency.WP4. with the Access Manager we provide a security mechanism that is capable of enforcing ABAC rules. SP. SP.SD.WP4.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 29 .17 Smart products shall provide a configurable consistency model that adapts Smartproducts-d-1-2-4.24 Smart products shall provide metrics for assessing suitability of other smart products for placing content off-board. SP. operation logs related to content stored on-board. SP. durability.SD. the data needs to be secured.WP4. and that can be used to classify content. SP. the information entrusted to the distributed storage is only accessed by the smart product that initially stored them.26 Smart products shall be able to maintain off-board content placement taking into account content properties.1. SP. locally on the smart product).Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.SD.SD.WP4.WP4.3. or query efficiency.14 Smart products shall provide replication functionality for enhancing content availability. we focus on the human aspects related to managing security policies instead of means for enforcing these policies.SD.23 Smart products shall provide pre-defined content classes that reflect content properties such as availability.SmartProducts WP1 . SP.SD.SD.SD.WP4.25 Smart products shall provide configurable content replacement policies to automatically determine content to be stored off-board.1] relevant for secure and distributed storage. This is important. Nevertheless. such as user preferences. SP.WP4.WP4. durability.2 Related Requirements Table 6 summarizes the requirements from [D4.WP4.SD. 3.4: Final Concept for Smart Products infrastructure is geared towards volatile data that needs to be propagated with low latency Furthermore.WP4. SP.WP4.SD.WP4. SP.SD. SP.. such as encryption. SP.1.WP4.

SD.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 30 . exact match queries). SP.SEC. SP..8 Smart products should be able to locate content based on related metadata (i. SP.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.27 Smart products shall enable applications to specify number of replicas depending on content properties and/or assigned content classes.SD.SEC..12 There shall exist authentication devices that provide user-related security services.SEC.SEC.g.WP4. SP.WP4.4: Final Concept for Smart Products content properties and approaches the related trade-offs (e. SP.4 There shall exist an identity management system. SP.WP4. SP.2 Smart products shall support fine-grained rights management mechanisms regarding the granularity of data. SP.SD. role (RBAC) or mission (MBAC) of an entity.9 Smart products should determine the trustworthiness of other smart products automatically by proactive information exchange. SP. SP. SP. between availability and consistency)..WP4.WP4.5 Smart products should be able to cooperatively check the behaviour of other entities for harmful activities.SEC.SEC.WP4.SD. SP.SD. SP.SmartProducts WP1 .SEC.29 Smart products shall be able to locate content based on their identifier (i.30 Smart products shall be able to locate content using complex queries.1. SP. Smartproducts-d-1-2-4. SP.WP4.WP4.28 Smart products shall provide a commitment protocol to enable smart products to agree on consistent object versions.2.WP4. smart products should react in a proper manner such as restricting the rights of the entities or entirely removing them from the network.1 Smart products shall support fine-grained rights management mechanisms based on the identity (IBAC). SP.WP4.3 Smart products shall support fine-grained rights management mechanisms regarding privacy policies.18 Smart products shall provide syntactic conflict management functionality in order to resolve conflicting versions of content in an automated way.SEC. keyword search based on controlled vocabulary).WP4. SP.SD.e.SD.WP4.7 If malicious entities are detected.8 The owner of a smart product shall be the highest authority to determine trustworthiness of other smart products.6 Smart products should maintain a history of earlier interactions which other products and users.WP4.WP4.SEC.WP4.WP4.SEC.e.19 Smart products should enable applications to integration applicationspecific semantic conflict management functionality in order to resolve conflicting versions of content in an automated way.WP4.

4 Implementation The implementation of the distributed and secure storage leverages existing work on distributed storage and peer-to-peer networks. Details about the Ubiquitous Storage component are described in [D4. it establishes a distributed storage system that employs the Communication Middleware to distribute content to different places.2. Existing approaches do not sufficiently consider the extreme heterogeneity of network nodes. SP.3.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 31 . which is found in networks of smart products and back-end systems.SEC.4: Final Concept for Smart Products SP. Table 7: Relationship between Distributed & Secure Storage and other concepts 3.WP4. Ubiquitous Storage The Ubiquitous Storage provides traditional APIs to the smart products developer. e. to specify when a step in a workflow can be assumed to be completed.3.2] The problem solving knowledge may contain explicit pointers to certain situations. Smartproducts-d-1-2-4.13 There shall exist authentication mechanisms for smart products in order to enable reliable identification. such as for retrieving files (exact match queries or keyword search) and querying knowledge (SPARQL queries).16 Smart products should enable applications to prohibit certain proactive knowledge from being distributed among other peers.14 Smart products shall detect unauthorized manipulations of proactive knowledge for ensuring its integrity.WP4.15 Smart products should detect and try to avoid Denial-of-Service (DoS) attacks in a collaborative manner.2].g.3.SEC. back-end systems and other smart products in the ambiance.1.SmartProducts WP1 . Underneath. SP. The final implementation is described in [D4. Table 6: Requirements related to Secure and Distributed Storage 3.SEC. One problem that needs to be addressed is identifying suitable metrics for selecting super-peers.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.WP4. Problem solving knowledge [D1.. Related Concept Description Embedding in Ambiances The stored content is distributed among storage resources embedded in an ambiance and back-end systems using the Communication Middleware. SP.3.SEC.3 Related Concepts Table 7 shows an overview of the relation between Distributed and Secure Storage and other concepts.WP4.3].3.

Smartproducts-d-1-2-4.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 32 .3.2.3.2].3. in particular different authorization mechanisms. The final implementation will be described in D4. Details about the Access Manager component.4: Final Concept for Smart Products Access Manager The Access Manager is queried by the Ubiquitous Storage to determine whether accesses to stored content are eligible.SmartProducts WP1 .1.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. are described in [D4.

This involves choosing the modality (speech.e. which are backed by results from experimental studies. Smartproducts-d-1-2-4.3. however.. we address the following problems related to the challenge of natural interaction with proactive smart products:  Selecting a UI variant that is most suitable for the individual user or user group at hand in the current context. the smart product has to take the initiative in the interaction with the user. i. by reducing the number of options offered to the user. We must. and by guiding the user through complex tasks.1 Description One intended effect of the smartness in smart products is a reduction of the complexity of the product perceived by the user.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. by hiding irrelevant parts of the functionality.. to be effective – it has to be proactive. This is achieved by improving the interaction with the user.1..2]) enable the smart product to do this.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 33 . the adaptation mechanism and user models can evolve during the runtime through machine learning. ensure that the user understands the behaviour of the smart product and perceives the interaction with it as natural. whether the user needs information on certain topics or not).g. The SmartProducts platform supports the developer in context-adapted and personalized interaction by providing rich models for describing user interfaces and users (see [D1. e.4. the correct level of detail and the type of desired information (e.g.2. In smart products. Especially for the latter. The problem solving knowledge and its reasoning capabilities (see [D1.  Choosing which type of proactive behaviour suits the user or user group in the current context.4 Context-adapted & Personalized Interaction 3. GUI or other). Although the SmartProducts platform comes with working defaults for the adaptation mechanisms.3. and on which topics disabled. History is full of examples where IT systems taking the initiative were not well received by users [Gajos-2006].4: Final Concept for Smart Products 3.SmartProducts WP1 . proactive advices on which topics should be delivered.2]) and generic adaptation mechanisms.

SP.WP5. audio message in one situation vs. graphical message). allergies).1] relevant for context-adapted and personalized interaction.1.2..WP5. smart products should consider whether to initiate interaction with the approaching users or not.g. workshop worker vs. Smartproducts-d-1-2-4.3 Smart products shall be able to choose an appropriate modality of interaction based on long-term user characteristics (e. SP. SP.. Smart products shall be able to adapt to context-dependency of user preferences (e.1 When users are approaching smart products.1.WP5.. SP.WP5.PERS. Smart products shall be able to adapt content of interaction to user preferences (e.g.SmartProducts WP1 .WP5..WP5.6 Smart products shall be able to adapt content of interaction (such as level of details) to user experience / skills.PERS.7 Smart products shall be able to adapt modality of interaction to user preferences (e. SP. tolerance to interruptions).WP5.PERS.g.WP5. SP. SP. Smart products shall be able to adapt content of interaction to long-term SP. SP.WP5.8 products as possible).2 Related Requirements Table 8 shows a summary of the requirements from [D5.WP5. graphical message in SP. to suggest a diet including as many favourite food SP.2 Smart products should use input and output devices which are near to the user for interaction.PERS.LOC.. SP.LOC.PERS.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.. SP.INT.4: Final Concept for Smart Products 3.9 Smart products shall be able to adapt moment of interaction to user preferences (e.2 Smart products shall be able to choose an appropriate moment of interaction based on long-term user characteristics (e.WP5.PERS.5 Smart products shall be able to adapt form of interaction (such as choice of modality or device) to user experience / skills. capabilities and preferences of multiple users simultaneously. owner).8 Smart products should be able to adapt the interaction to available devices (e.WP5. audio vs.PERS.PERS..doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 34 . to notify the user well in advance or just before the event).PERS. tolerance to interruptions). Smart products shall be able to adapt modality of interaction to roles.4.10 another situation).4 user characteristics (e.g.g..1 Smart products shall be able to behave differently depending on users roles (for example.g.g. SP.g.PERS.WP5.WP5.11 skills.PERS. screen size).

Distributed and Secure Information about the UI options and the user model is stored by the Storage Ubiquitous Storage.12 capabilities and preferences of multiple users simultaneously.3.13 Smart products shall be able to protect privacy of group members. closest place to stop.PERS. Managing Proactive Knowledge [D1. Table 9: Relationship between Context-adapted & Personalized Interaction and other concepts Smartproducts-d-1-2-4.PERS.RL.14 application developers and for end users.2. when a situation demands user interaction.1.WP5. SP. Configuration of interaction with Smart products shall be convenient for SP. e. Related Concept Description Context processing As a prerequisite. Deriving symbolic context information is handled by the Context Manager. Modelling products [D1.3. Multi-device & Multi.2] the smart The user model.WP5.2] The UI adapter is triggered by the smart product applying problem solving knowledge (general or workflows).. trouble shooting procedures).. the smart product must be able to identify the user and the context of the interaction. multiple smart products can share and evolve a common user model. the UI options and the symbolic context domain information is described using the common framework of smart products ontologies developed in WP2. SP.2 Smart products should provide alternative workflows.WP5.WP5.15 The reason for interaction shall be provided to users.PERS.WP5. Thus.PERS. The adaptation mechanism can deal with imperfect knowledge and uncertainty.4 an error case.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 35 . Table 8: Requirements related to Context aware and Personalized Interaction 3.WP5.RL. SP. skills. SP.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.g.Once the right UI option is chosen it is passed to the Multimodality modal interaction Manager for rendering. Smart products should be able to propose tasks or information to users (e.SmartProducts WP1 . to recover from SP.3 Related Concepts Table 9 shows an overview of the relation between Context-adapted and Personalized interaction and other concepts.g.4: Final Concept for Smart Products Smart products shall be able to adapt content of interaction to roles.4. which necessarily follows from automatic processing of context information.

Apart from learning each user model from the history of interactions with this particular user only. Details about the UI Adapter implementation can be found in [D5. but can be adapted and modified using machine learning. Additionally.4.g. First. This seems reasonable. since there exist tools. however. so that these do not have to be re-implemented for every smart product. where every modality choice along with the context settings is a case. Details about the UI Adapter implementation can be found in [D5. users need to be able to manually control the adaptation. such as whether the chosen modality was later changed by the user. The User Model Learning component builds a user specific model. User Model Learning component also attempts at predicting user preferences for a Smartproducts-d-1-2-4. In these cases.2] and [D5. Thereby. The SmartProducts platform does. The Interaction Manager provides an identifier for the interaction to the UI Adapter.4. based on a single input model. e. The metric is however not static. User Model Learning The UI Adapter comes with a pre-configured set of decision models that were derived from the results of user studies [D5.4: Final Concept for Smart Products 3. considers the choices of the user as a feedback on the selection of the UI Adapter. Therefore.3]. and uses this to improve the selection function in the UI Adapter. The second problem.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 36 . such as Teresa [Paterno-2002].1.4.4.2. a single value is calculated for each UI option as a metric.1]. by overwriting the chosen modality. Replicating the functionality of these tools inside the SmartProducts platform is thus not necessary. the correct UI option must be selected. The User Model Learning component collects feedback from the user regarding the choices of the UI Adapter. UI options for different users and contexts must be generated and then. but rely on the developer to provide them. which cannot take into account the specifics of an individual user.2. UI Adapter The selection of UI options is done by comparing the parameters used to describe the UI option to the preferences of the user / user group and the current context. the selection of the right UI option needs to be done at runtime.4. and the UI Adapter retrieves the description of all matching UI options from the Ubiquitous Storage and then selects the most suitable. provide means to include standard control elements. which aims at better adaptation of interaction to some context when this context emerges again. it would increase the footprint of the platform..4 Implementation We have separated the task of personalized and context-aware interaction into two sub problems. the UI Adapter will not be able to select the best UI option for the user in all cases. and the option with the highest metric is chosen. The adaptation uses case-based reasoning.3].SmartProducts WP1 .2] and [D5.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. such as buttons for on-the-fly adaptation of the modality into the final UI. which generate a multitude of UI options. We do not support the former (automatic generation of UI options) inside the platform at runtime.

such as back / next buttons to navigate in a problem solving procedure. e. We assume that other tools are used to generate them in an efficient way. Furthermore. or shortcuts to switch between modalities on the fly.SmartProducts WP1 .4: Final Concept for Smart Products context that is new for this user. the SmartProducts platform supports the development of UI options by providing standardized blocks. the project provides guidelines for designing the interaction based on user experiments [D5. The Workflow Extractor provides support for extracting UIs containing workflow step instructions from legacy sources.2. distinguishing between detailed and concise instructions. Apart from providing implementation for these standard blocks. UI Options The individual UI options have to be provided by the developer. such as manuals.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.2.1] Smartproducts-d-1-2-4.1.g..doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 37 . They can be automatically annotated in terms that can be compared with the user models and adaptation rules. This is achieved via analyses of histories of interactions of a community of the users and finding like-minded users in this community [Vildjiounaite-2011].

The SmartProducts platform thus aims at supporting other modalities for interaction. they have to use interaction resources from the ambiance. pointing device. SP. using LEDs and other minimal feedback interaction devices.1 SmartProducts should be able to use a Text-To-Speech service in the environment.4: Final Concept for Smart Products 3. Obviously. beep). SP. A very important class of interaction devices that support this kind of interaction are smart phones. The challenge here is to develop a system that is capable to distribute the output to. such as voice are more natural. These other modalities include voice interaction.INT. have to be supported. it needs to be presented.2 Related Requirements Table 10 shows a summary of the requirements from [D1.2] relevant for multi-device and multi-modal interaction.INT.8 SmartProducts should be able to adapt the interaction to available devices (e. SP. and touch Smartproducts-d-1-2-4. Since smart products potentially have very limited interaction resources built-in.1. Thereby.SmartProducts WP1 . although different interaction devices are used. screen size). This is a prerequisite for most application use cases addressed in the SmartProducts project. we concentrate on the systems challenges related to making all these different modalities available in a platform.5 3.INT.2 SmartProducts shall be able to provide feedback on their own (e.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 38 .g.1 Multi-device & Multi-modal Interaction Description Once a UI option has been selected for interacting with the user. and collect the input from all interaction resources in the ambiance over the Communication Middleware... For example. GUI point and click interfaces. A challenge addressed is thus how to enable use of existing smart phones as interaction devices for smart products. it is likely that other paradigms are equally important in smart products settings.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. In many situations the user carries a smart phone already today. 3. The mechanism should be flexible enough to support different modalities of interaction. SP.5. remote control.5.INT. While GUIs have been the predominant paradigm for interacting with IT systems in the last decades.9 SmartProducts shall be able to utilise input from various devices in the environment (voice. gesture.2.1. when preparing a meal. A challenge on the level of human computer interaction is to maintain the user’s experience of a coherent interaction session with an individual product. the eyes and hands of the user are occupied and thus alternative means of interaction.g. Supporting this functionality with the SmartProducts platform should greatly add to the acceptance of the platform in practice. but also ambient interaction.

Embedding in Ambiances Resources for interacting with the user. To do so.INT.5.INT. like done in RDP.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. SP. a description of the UI is transferred into a device hardware specific description. Alternatively. and do the rendering afterwards.. transfer a frame buffer to a screen.9 SmartProducts should be able to provide a GUI. which the user can perceive and interact with (image on a screen.g. The SmartProducts platform supports a generic framework for sending arbitrary serialized UI descriptions over the communication middleware. Related Concept Description Context-adapted & Personalized Interaction The Multimodality Manager receives rendering and update requests which contain context-adapted and personalized UI options. First.5.3 Related Concepts Table 11 shows an overview of the relation between Context-adapted and Personalized interaction and other concepts. Table 10: Requirements for Multi-device & Multi-modal Interaction 3. like done in the Web. Second. The selected UI option contains a generic description of the UI. It is possible to do the rendering first.4 Implementation The process of turning the selected UI Option into a final interface. which is transferred to an interaction device. Multimodality Manager The Multimodality Manager is responsible for establishing a connection to the interaction device that best suits the selected UI option.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 39 . These two things are to some degree independent from one another.INT. SP. so that user input from the device can be received.4: Final Concept for Smart Products screen buttons). e.SmartProducts WP1 . SP. During the rendering process two things have to be performed. are accessed using the Communication Middleware.13 SmartProducts should be able to guide the user through the workflow using step-by-step instructions. Table 11: Relationship between Multi-device & Multi-modal Interaction and other concepts 3.2. To support maximum flexibility in terms of devices and modalities that can be used with smart products. the description must be serialized and sent over the Communication Middleware. configured voice recognition service) is called rendering. the UI description must be sent to the device and a channel must be set-up.14 A SmartProduct should be able to get implicit feedback from the user.1. It does so using the service discovery functionality Smartproducts-d-1-2-4. and. just like other resources in the ambiance. such as screens. one can transfer an abstract representation of the UI. we adopt the latter approach.

The session groups interaction events happening. On the one side. This is the role of the Input/Output Device Adapter. and they use the same protocol. it is possible to include other representation. e. they are a prime candidate for acting as a universal terminal device for smart products. but does not perform the transformation from the generic format into the hardware specific part. but based on direct product smart phone communication would be extremely useful.1. such as sensors.g.4. or the smart product requests a change to the output to the user. Being able to implement a generic renderer.. without network communication. to investigate the value of voice as a modality for interacting with smart products. and EMMA for input messages from the interaction device to the smart product.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 40 . Smartproducts-d-1-2-4.3]. The complexity for implementing an Input/Output Device Adapter depends on how well the UI description matches the underlying hardware.4.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. Finally. however. Thus. implements the protocol for connecting interaction devices to smart products. it is important to provide a solid framework and good documentation for how to build a custom Input/Output Adapter for smart phone platforms. however. Local interaction devices are also managed by the Multimodality Manager. Details about the implementation of these adapters can be found in [D5. an input/output device adapter for voice is developed. Since smart phones become more and more ubiquitous. text for a UI option targeting speech output and an image in a UI option targeting GUI output. Since the Web has been very successful as a basis for interaction and Web-based UI description have been successfully applied to support interaction with consumer appliances [DEES-2007]. The Multimodality Manager does not only access remote interaction devices. This component thus. For example. It is. we aim to provide an Input/Output Device Adapter for HTML / XForms UI descriptions. this adapter attaches to the hardware resources of an interaction device. it is easy to render a text to a textto-speech service. for interacting with their products.4: Final Concept for Smart Products of the Communication Middleware. Input / Output Device Adapter The Multimodality Manager coordinates the distribution.SmartProducts WP1 . based on HTML / XForms on these devices. However. on the other side it supports the protocol used by the Multimodality Manager.2. It then initiates and maintains a session with this interaction device. without relying on internet connectivity. camera etc. much more difficult if not impossible to render a binary image to the same interaction device. Details about the implementation and the protocol can be found in [D5. such as the user provides input. we allow the possibility to include arbitrary UI descriptions in the UI options. which cannot be realized with a generic renderer. Since many prospective vendors of smart products will demand use of phone specific features.3]. The protocol is optimized for HTML and XForms for output messages from the smart product to the interaction device. Such an adapter needs to be running on every interaction device that should be used with the platform.

The concepts presented in this deliverable provide the runtime and execution environment for connecting the functionality of a product described as proactive knowledge. These concepts are to be seen in relation to those presented in [D1.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.SmartProducts WP1 .2].4: Final Concept for Smart Products 4 Conclusion This deliverable gives an overview of the concepts that are realised and implemented in the SmartProducts platform. This provides a definition of the scope for the software development of the platform as well as for the research conducted in the technical work packages.3.1. Smartproducts-d-1-2-4. connecting them to the physical aspects of smart products.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 41 .2.

SmartProducts WP1 .4: Final Concept for Smart Products A List of Acronyms HTML WP EMMA ERP RDF RPC Hypertext Markup Language Work Package Extensible Multimodal Markup Language Enterprise Resource Planning System Resource Description Framework Remote Procedure Call WSDL Web Service Description Language Smartproducts-d-1-2-4.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 42 .Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.1.2.

doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 43 .3..1. Arrows denote dependency.3. Figure 6 Overview of concepts for proactive knowledge [D1.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D.2. There exist some mutual dependencies.g.2.SmartProducts WP1 . e.2] and smart products and their relationship. Smartproducts-d-1-2-4. deriving symbolic context information (Context Processing) requires reasoning (Managing Proactive Knowledge).g. such as workflows (Managing Proactive Knowledge) requires context information (Context Processing).2. Context Processing depends on the Modelling of the SmartProducts Domain.4 and D1. e..4: Final Concept for Smart Products B Overview of Concept Relationships Figure 6 shows an overview over all concepts in D1. and applying problem solving knowledge.

[Dees-2007] Walter Dees and Paul Shrubsole.2. Dees-2007: accessing web-based applications on consumer devices.3] D4. 2005.3. 2011. [D6.2. SmartProducts Consortium.1 Initial Concepts for Smart Products. [D1.4. Integration and System Architecture SmartProducts Consortium. SmartProducts Consortium.4. [D4. 2011.SmartProducts WP1 .2] D6.3.5.1. 2007.3.2 Final Requirements for Smart Products and Proactive Knowledge.1.1: Initial Smart Products Communication Middleware. SmartProducts Consortium. SmartProducts Consortium. SmartProducts Consortium.1.Harvard Business Review.4: Final Concept for Smart Products References [D1.2] D4. [D5. D6.2 Final Concept for Security and Privacy of Proactive Knowledge. [D6.2 Final Context and Environment Model Framework (to appear). 2011. SmartProducts Consortium.2] D1.2] D5. Allmendinger and R. [D4. Max Mühlhäuser: MundoCore: A Light-weight Infrastructure for Pervasive Computing.2] D6.1. 2011.345.145.3. pp.2 Final Smart Products Communication Middleware (to appear). Requirements for Technical Framework.3 Final Implementation of MMUI to Interact with Smart Products & Proactive Knowledge (to appear). SmartProducts Consortium. 2011. [D6. SmartProducts Consortium.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. 2010. [D5.5.1 Initial Methodology for Smart Products Usage Modeling and Personalisation.3.2] D6. SmartProducts Consortium.1. 2011. SmartProducts Consortium.4.2. [D6.1.1.3. [D1. 2007.2. Elsevier Science Publishers B. 2010.1] D1. Initial Sensor and Actuator Integration Framework & Initial Context and Environment Model Framework. [D6. 2011.3 Final Concept for Storing. 2010. In Proceedings of the 16th international conference Smartproducts-d-1-2-4. [D4. Distributing.3. 2009. [Allmendinger-2005] G. SmartProducts Consortium. 2010.1] D5.2.2 Final Sensor and Actuator Integration Framework (to appear). 83(10): pages 131. [Aitenbichler-2007] Erwin Aitenbichler.2] D4. 2010. (North-Holland).2.2.2] D1.4.2 Initial Implementation of MMUI To Interact with Smart Products & Proactive Knowledge. In: Pervasive and Mobile Computing.3.2 Implementation of the Required Set of Services to Manage Proactive Knowledge.V. 332-361.2. Lombreglia.5.1] D6. SmartProducts Consortium.1. Jussi Kangasharju. [D5.3] D5. [D4.1 & D6.4. 2011.1] D6. Final Concepts for Proactive Knowledge SmartProducts Consortium.3 Final Implementation of the Required Set of Services to Manage Proactive Knowledge (to appear).3] D4.4.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 44 . Four Strategies for the Age of Smart Services.3. SmartProducts Consortium. and Maintaining Proactive Knowledge Securely.1.4. 2011.

303126 [Dobson-2006] S.1145/1242572. NY. Mary Czerwinski. Anind K. New York.1506425 http://doi. 143--154.acm. Spending Moore's dividend.org/user (accessed: 28.W. Beigl. 18(3): pages 211-215. Desney S. Commun. “The End of Moore’s Law in 5 Years?”. Exploring the design space for adaptive graphical user interfaces. K. http://www. Amsterdam. Tan. C. Gellersen.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 45 .acm. Preface to the Focus Theme Section: 'Smart Products'. A.itrs. in Proc. 1999. 434-441.1145/1242572.com/blogs/The-End-of-Moores-Law-in-Five-Years-48287682.1242820 [Dey-2001] Dey. pages 341351. USA. ACM.2. [Gajos-2006] Krzysztof Gajos.1. Reusable Components for Knowledge Modelling. ACM 52. Abowd. [Gellersen-2002] H. Understanding and Using Context. Many Interfaces. [Dey-2006] Daniel Salber. USA. Dobson. pages 201-208. and Gregory D. USA. Varshney. Motta. M.1242820 http://doi. or just a program?: A taxonomy for autonomous agents. DOI=10.. 2006 [Feldman-2009] Feldman. Santoro. Stuart J. Maass and U. pp.1145/1506409. One Model. NJ: Prentice Hall Smartproducts-d-1-2-4. Ye (2006) Using fibrations for situation identification. The context toolkit: aiding the development of context-enabled applications. A. 2008. http://www. NY. 1303-1304. in Proceedings of Pervasive 2006 workshops.hpcwire. Personal Ubiquitous Computing.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D. Weld.acm. Is it an agent. [Motta-1999] E. 2009. J. ACM. Englewood Cliffs. Multi-sensor context-awareness in mobile devices and smart artifacts. Springer-Verlag.1145/302979. Springer. DOI=10. New York.1506425 [Maass-2008] W. ACM Press. In Proceedings of the SIGCHI conference on Human factors in computing systems: the CHI is the limit (CHI '99). 21–35 .net/ [Larus-2009] James Larus. Artificial Intelligence: A Modern Approach. Michael.1145/302979. Graesser. Franklin and A.org/10.1145/1506409. 1999. Berlin (1997) p. 5(1):4--7. NY. [Russel-2002] Russell. Intelligent agents III. and Daniel S.303126 http://doi. IOS Press.org/10.SmartProducts WP1 . and Peter Norvig (2002). In AVI '06: Proceedings of the working conference on Advanced visual interfaces. [Paterno-2002] Paternò.org/10. 2002 [ITRS] International Technology Roadmap for Semiconductors.html [Foldoc] http://foldoc. Mobile Networks and Applications 7 (5). 62-69. (2001). F. of CADUI'2002.05.2011) [Franklin-1997] S. Schmidt. New York. 5 (May 2009). DOI=10. 2006.4: Final Concept for Smart Products on World Wide Web (WWW '07). Dey.. Electronic Markets.

..05.. USA. Keränen. J.com/user (accessed: 28. R. Schreiber.. A. Mäntyjärvi. M. O. Kyllönen. Palo Alto. A. Designing Socially Acceptable Multimodal Interaction in Cooking Assistants. Feb.1. J.doc Copyright  SmartProducts Consortium 2009-2012 Dissemination Level: Public Page 46 . Vuorinen. Cambridge. [Vildjiounaite-2011] Vildjiounaite.2011) [WordNet] http://wordnetweb. Kantorovitch. Virtanen..2011) Smartproducts-d-1-2-4. E.. T. Mäkelä. Tokmakoff.05. W.org/wiki/End-user_(computer_science) (accessed: 28.wikipedia.. J.. B. Niskanen.wikipedia. N.edu/perl/webwn?s=user (accessed: 28. Shadbolt. Hillukkala.-M. I.SmartProducts WP1 . 2000.. 2011 International Conference on Intelligent User Interfaces. Peltola. Anjewierden.05.4: Final Concept for Smart Products [Schreiber-2000] G. H. de Hoog. Knowledge Engineering and Management: The CommonKADS Methodology. Wielinga. K.05.Integrated Concepts for Smart Products and Proactive Knowledge Deliverable D..org/wiki/User_(computing) (accessed: 28. MIT Press..princeton. Akkermans. van de Velde. V. 2011 [Wikipedia-enduser] http://en.2011) [Yourdictionary] http://www.yourdictionary.2..2011) [Wikipedia-user] http://en. S.