UBIWARE Project

1. Resource Agent Resource Agent Resource Agent PI GB SC Industrial Ontologies Group “Smart Semantic Middleware for Ubiquitous Computing” Deliverable 2.1 UBIWARE Project “Expert” “Device” “Service” & shared services University of Jyväskylä

2. What is UBIWARE ? Just a reminder or short Introduction

3. What is UBIWARE ? (1) • UBIWARE is a generic, domain independent middleware platform, which is meant to be able to provide the following support: • integration; • interoperability; • proactivity; • communication, observation, negotiation, coordination and collaboration; • automation, design and installation; • lifecycle management, execution monitoring, diagnostics, maintenance; • self-descriptiveness, semantic search, discovery, sharing, reuse; • planning and decision-making; • adaptation; • learning, mining, knowledge discovery; • context-awareness; • self-management including self-configuration; • security, privacy and trust; • etc... • …for … (see next slide)

4. What is UBIWARE ? (2) • … for the following resources, systems and components (including their groups): • data information and knowledge:data, metadata, knowledge, logic, ontologies; • software and services:software components, software agents, softwareand information systems, services including Web-services; • humans:users, operators, experts, administration, customers, patients, doctors, etc; • hardware:machines, devices, networks, embedded electronics, RFID; • organizations; • intangibles:human and organizational capital, innovations, property rights, trust and reputation, brand recognition, etc.; • processes:behaviors, technologies and business models; • interfaces; • intelligence:reasoning, inference, planning, learning, data-mining, knowledge discovery, etc… engines; • ecosystems:environments, smart spaces, other middleware and CSCW tools; • abstractions and mathematical models; • etc.

5. What is UBIWARE ? (3) • Due to heterogeneity of provided services and supported components, UBIWARE is based on integration of several technologies:Semantic Web, Distributed Artificial Intelligence and Agent Technologies, Ubiquitous Computing, SOA (Service-Oriented Architecture), Web X.0, P2Pand related concepts. • The research and design on UBIWARE is started byIndustrial Ontologies Groupwithin UBIWARE project: “Smart Semantic Middleware for Ubiquitous Computing” (June 2007 – May 2010) funded by Tekes and industrial companies. • Project web page: http://www.cs.jyu.fi/ai/OntoGroup/UBIWARE_details.htm

6. What is UBIWARE (in short) • UBIWARE is a tool to support: • design and installation of…, • autonomic operation of… and • interoperability among… • … complex, heterogeneous, open, dynamic and self-configurable distributed industrial systems;… • … and to provide following services for systemcomponents: • adaptation; • automation; • centralized or P2P organization; • coordination, collaboration, interoperability and negotiation; • self-awareness, communication and observation; • data and process integration; • (semantic) discovery, sharing and reuse.

7. University of Jyväskylä Kharkov National Universityof Radioelectronics UBIWARE Team:Industrial Ontologies Group 2008-2009 • Researchers • Vagan Terziyan (Head) • Olena Kaykova • Artem Katasonov • Oleksiy Khriyenko • Sergiy Nikitin • Contact Person: Timo Tiihonen • e-mails: tiihonen@it.jyu.fi vagan@cc.jyu.fi • phone: +358 14 260 2741 • Michal Szydlowski • Joonas Kesäniemi • Michal Nagy • Arnim Bleier • Nikos Mouchtaris URL:http://www.cs.jyu.fi/ai/OntoGroup

8. Current UBIWARE Agent Architecture

9. UBIWARE Agent: Possible Future Architecture RBE – Reusable Behavior Engine SoftSoul “Life” Behavior HardSoul RAB – Reusable Atomic Behavior Meta-Beliefs (preferences) Shared Meta-Beliefs SoftMind Ontobilityis self-contained, self-described, semantically marked-up proactive agent capability (agent-driven ontonut), which can be “seen”, discovered, exchanged, composed and “executed” (internally or remotely) across the agent platform in a task-driven way and which can perform social utility-based behavior Shared RBEs RBE RBE RBE RBE HardMind Beliefs (facts, rules, policies, plans) Configuration(GENOME) Ontobilities Shared Beliefs SoftBody Shared RABs RAB RAB RAB RAB HardBody Hardware Shared Hardware Genomeis part of semantically marked-up agent configuration settings, which can serve as a tool for agent evolution: inheritance crossover and mutation “Visible” to other agents through observation Environment May be an agent

10. UBIWARE Workpackages

11. Project Workpackages • Core Distributed AI platform design (UbiCore); • Managing Distributed Resource Histories (UbiBlog); • Smart Ubiquitous Resource Privacy and Security (SURPAS); • Self-Management, Configurability and Integration (COIN); • Smart Interfaces: Context-aware GUI for Integrated Data • (4i technology); • Middleware for Peer-to-Peer Discovery (MP2P); • Industrial cases and prototypes.

12. (2007-2010) “Smart Semantic Middleware for Ubiquitous Computing” UbiCore – CORE DISTRIBUTED AI PLATFORM DESIGN UbiCore – CORE DISTRIBUTED AI PLATFORM DESIGN UBIWARE Project DELIVERABLE D2.1 Workpackage WP1 TASK T2.1_w1 Workpackage leader Artem Katasonov

13. WP1 Tasks • How to realize organizational policies as restrictions put on the behavior of individual agents? • What mechanisms are needed for flexibly treating the potential (and likely) conflicts among the S-APL models (roles, policies) used by one agent? • Is it possible and if yes then how to implements a mechanism so that agents could “see” what other agents are doing, in so creating the basis for coordination through observation in addition to traditional coordination through communication? The WP tasks for the Year 2 are the following: Task T2.1_w1 (research):Answers to the questions above, and other, if appear in the process, related to an agent’s deliberation, i.e. acting based on the imposed behavior models. Design of the advanced behavior engine . Task T2.2_w1 (development):Incorporating the research findings to the UBIWARE prototype.

14. Q1: Dynamic coordination • Work on policies evolved towards more general work on agents’ coordination. • The traditional policies, such as of access control, are as a special, static, case of coordination: an agent with an authority sets some restrictions on the behavior of other agents to avoid possible conflicts of interests. • A more general case of coordination is where only when two autonomous behaviors conflict over the use of a resource some policy mechanism is applied. • Such a resolution policy may dictate, for example, that the agent with a higher organizational authority gets the priority in using the resource.

15. Query Data Domain ontology family: Domain ontology person: Responder Enquirer Definition of family: Definition of person: Upper ontology human: Upper ontology rdf: , rdfs: , owl: RDF-S / OWL rules Ontology linking org:Mary rdf:type person:Woman. org:Mary person:hasSon org:Jack. SELECT ?x WHERE {?x rdf:type family:Mother} org:Mary human:hasSex human:FemaleSex. org:Mary human:hasChild org:Jack. org:Mary rdf:type family:Mother. ?x = org:Mary person:Woman is a subclass of person:Person which is in turn a subclass of human:Human. person:Woman has a restriction to have a property human:hasSex with the value human:FemaleSex. Also, person:hasSon is a sub-property of human:hasChild. family:Mother is a subclass of human:Human with the restriction that it must have a property human:hasSex with the value human:FemaleSex and must also have at least one property human:hasChild.

16. No Has unknown concepts? Yes Intention Data Is a registered upper ontology? Yes No Domain ontology DO1 Domain ontology DO2 Agent 2 Agent 1 Obtain the definition of own domain ontology in terms of the upper ontology Definition of DO1 Definition of DO2 Upper ontology: Coordination • Attempt one or both: • Download online ontology definition • - may have to ask the sender for URL • Ask the sender for the ontology definition Upper ontology: BDI No Yes Success? Upper ontology rules Attempt ontology alignment Coordination rules Yes No Success? Respond: NOT UNDERSTOOD Done Dynamic ontological coordination • “I now z:Print a document on org:AgPS4e” • “Does Agent1’s intention concerns me?” • “I do not know what x:Copy means..” “I plan to x:Scan a book y:BlaBla on org:AgPS4e”

17. Dynamic coordination on S-APL • Can define classes of activities: • Can then attach coordination-related properties: org:Scan coord:requires ?scanner. • Can write then interpretations rules – to understand what activities take place and what resources are involved. • Can write then coordination rules – how e.g. to resolve a conflict if one is registered. • Can also define static policies:

18. Q2: Alternative Actions • The work related to conflicts of roles also resulted in somewhat extending the scope of the problem considered and shifting the focus – towards general-case agent’s decision making when confronted with several options. • Selecting among actions dictated by different roles is a special case of this. • Master’s Thesis of Arnim Bleier (completed). • The market-based approach is taken.

19. Utility functions Agent’s Knowledge Base (KB) 1. Be able to describe pieces of the KB (i.e. beliefs) that collectively give the relevant “state of the world” 2. Be able to define a function that extracts relevant values from those beliefs and generates a utility value for the state. F 25 Room1 hasTemperature 25 Utility Value 3. Be able to apply the function to any given relevant KB. “Market-Based Approach” means that: • Social obligations, organizational values are to be translated into individual’s utilities. • Then, the choice is always made “selfishly” – based on individual utility. Design of utility functions requires human effort, but then in run-time the decision logic is straightforward.

20. Utility functions modeled • S-APL syntax is developed for defining discrete, linear, polynomial atomic functions, as well as complex multi-attribute functions made of the atomic ones.

21. Evaluating the utility of an action Selecting among alternative actions implies the ability to: • Construct the “hypothetical” KB – KB after the action is taken. • Evaluating the utility of the “hypothetical” KB.

22. Q3: Observation in MAS - What? • Different perspectives • state of being observable (source)‏ • act of observing (observer)‏ • information available through observation (manifestation)‏ • Observation is not communication in FIPA sense rather than interaction between agent and its environment • Observation based interaction • non-intentional • local • anonymous • time decoupled

23. Observation in MAS - Why? • Essential part of indirect interaction • “Interaction via persistent, observable changes to a common environment” (Keil2006)‏ • Models for observation based coordination in MAS • Property based coordination (Zargayouna2006)‏ • Behavioral Implicit Communication (Tummolini2005)‏ • Self-organization / emergent behavior • Examples • Overhearing/Oversensing • Stigmergic systems - Pheromones in digital and physical environments Keil2006, D. Keil and D. Goldin, “Indirect Interaction in Environments for Multi-agent Systems” Zargayyouna2006, M. Zargayouna and J. S. Trassy and F. Balbo, “Property Based Coordination” Tummolini2005, Tummolini L., Castelfranchi C., Ricci A., Viroli M., & Omicini A., “ "Exhibitionists" and "Voyeurs" Do It Better: A Shared Environment for Flexible Coordination with Tacit Messages”

24. Observation in MAS - How? • Introducing the Agent Observable Environment • Covers all the three perspectives of observation • Observable agents (source)‏ • Agent configurable foci (observer)‏ • Semantic Web driven representation of the observable environment (manifestation)‏ • Strict separation of concerns

25. Role of the environment • Explicitly modeled, first-class entity (Weyns2004)‏ • Layered approach (Viroli2007)‏ • Application layer • Execution platform layer • MAS middleware • Software deployment context • Physical support layer • Hardware deployment context • Cross-cuts the MAS (Platon2007)‏ Weyns2004, D. Weyns and H. V. D. Parunak and F. Michel and T. Holvoet and J. Ferber, “Environments for Multiagent Systems State-of-the-Art and Research Challenges” Viroli2007, M. Viroli and T. Holvoet and A. Ricci and K. Schelfthout and F. Zambonelli, “Infrastructures for the environment of multiagent systems” Platon2007, E. Platon and M. Mamei and N. Sabouret and S. Honiden and H. V. Parunak “Mechanisms for environments in multi-agent systems: Survey and opportunities”

26. Agent Observable Environment Allows agents to interact indirectly via changes to their persistent and observable softbodies

27. AOE - Main features Source's softbody • Only agents can be observers • Observation is based on softbodies • agent specific • local • represented in RDF • Agent's external action causes a change in the observable environment • Support for complex observations • static • dynamic • Support for ontologies (RDF-S, OWL)‏ • core ontology • Observational rules :I :do :ComputingTask1 :ComputingTask1 rdf:type ComputingIntensiveTask Source Observer Observer's softbody :I :observe Source

28. JADE implementation • Implemented as distributed JADE kernel level service • Sesame RDF repository for storing softbodies

29. What's next? • First stable version of the JADE plugin • Evaluation of the framework • Ubiware integration • Applications • Advanced softbodies • Hierarchical • Evolving • “Intelligent” • Implementation of algorithm for solving distributed constraint optimization problem (see WP4)‏

30. (2007-2010) “Smart Semantic Middleware for Ubiquitous Computing” UbiBlog – MANAGING DISTRIBUTED RESOURCE HISTORIES UbiBlog – MANAGING DISTRIBUTED RESOURCE HISTORIES UBIWARE Project DELIVERABLE D2.1 Workpackage WP2 TASK T2.1_w2 Workpackage leader Sergiy Nikitin

31. WP2 - Tasks • How to realize the possibility of querying a set of distributed, autonomous, and, hence, inevitably semantically heterogeneous resource histories as they were one virtual database, i.e. how to collect and integrate needed pieces of information from distributed sources? The WP tasks for the Year 2 are the following: Task T2.1_w2 (research):Answer to the question above. Design of mechanisms for information querying and integration from distributed histories . Task T2.2_w2 (development):Incorporating the research findings to the UBIWARE prototype.

32. Agent Beliefs WP2: Distributed Resource Histories (UbiBlog) • The main objectives of the WP2 are: • To develop means for an agent to plan and execute composite queries over the distributed sources as if the data from these sources was collected to one virtual graph Data Service Files Ontonut Bindings Ontonuts Role Script DB/KB agent-to-agent servicing adaptation of external sources

33. Scheduled Performance Monitoring Alarm History DB Experts’ diary WP2: Example Use case (UbiBlog) Expert Agent (Data Service) Paper Machine Agent Files Ontonut Bindings Ontonuts Role Script DB/KB

34. Excel sheet CSV file RDBMS WP2: Ontonuts architecture (UbiBlog) • Characteristics: • Three types of call: • Explicit • Goal-based • Query-based • Planning • Backward chaining algorithm • Execution • Handlers introduced to follow the state of the execution and change action plan Business Logic Script Ontonut capability Agent Beliefs (S-APL code) Ontonuts triggering rule Ontonuts Role Script Action Planner Plan Executor SQLReader TextTableReader ExcelReader … MessageSender MessageReceiver Reusable Atomic Behaviors (Java code) GoalAnalyser ActionPlanner Agent Services Web Service … External resources

35. .class Behavior Engine Ontonuts triggering MetaRule (1) {sapl:I sapl:do :nutid} sapl:configuredAs { x:precondition sapl:is {A A A} } sapl:I ont:haveGoal :id :id ont:haveGoalDef {B B B} (2) Live Activity (3) {B B ?x}=>{?x C C} Ontonut definition: :nutid ont:precondition {A A ?x} :nutid ont:effect {B B ?x} :nutid ont:script {implementation} Ontonut Ontonut Ontonut Ontonut Ontonut Ontonut Ontonut Ontonut Ontonut Activity Activity Activity Activity Activity Activity Activity Activity Activity S-APL WP2: Triggering Ontonuts (UbiBlog)

36. WP2: Query Types (UbiBlog) Parallel • subqueries can be executed independently from each other and results are merged Sequential • Inputs are dependent on the outputs from subqueries to other sources Hybrid (a combination of two above) • Possible cases: • Results of two or more parallel subqueries are merged and used as an input for a subsequent subquery • Result of one subquery is used as an input to a set of parallel subqueries • Result of a subquery is used as an input for both subsequent and non-susequent, parallel and non-parallel subqueries

37. WP2: Provision of Dynamic Information (UbiBlog) • An analog of platform-embedded constructs like: • sapl:Now sapl:is ?time (gets current system time) • But can be flexibly (re-)defined by user • fingrid:CurrentVoltage sapl:is ?voltage • metso:CurrentOilLevel sapl:is ?oillevel • innow:CurrentUsersOnline sapl:is ?usersonline • The approach simplifies the implementation of the agent’s business logic by introducing computable elements. The values of these elements are computed on-demand (only when a query appears in agent’s beliefs)

38. WP2: Provision of Dynamic Information (UbiBlog) • When extended to more abstract level, computable values can be applied for: • Counting statistics over dynamically updated data (e.g. average alarm rate per day, or number of students at the lecture now) • Collecting dynamic information about others. E.g. request “what is John’s location at the moment” would look like: • :John :currentLocation ?location

39. Service Bindings Agent Beliefs Agent Beliefs Ontonuts Role Script Agent Service Role Script Ontonut Bindings WP2: Future work (UbiBlog) • Ontonut vs agent service Agent Beliefs Service Client - client-service scenario - service provider - service consumer - Ontonut

40. WP2: Ontonuts – an Alternative to Live activity (UbiBlog) Agent Beliefs (General Context) (1) A A A . Gives C C A. {A A ?a} => {C C ?a}. (2) D D {A B B}. (3) {Ontonut triggering} sapl:is sapl:MetaRule (4) Gives ? :o1 rdf:type ont:Ontonut. :o1 ont:precondition {?x A ?y}. :o1 ont:effect {?x A ?y}. :o1 ont:script {D D {?x B ?y}=>{?x A ?y}}. (5) Agent Beliefs (General Context - G) (1) A A A . removed from G (2) D D {B B B}. (3) Gives C C B {Ontonut triggering} sapl:is sapl:MetaRule (4) The same (5) D D {A B ?a}=>{C C ?a} (6)

41. (2007-2010) “Smart Semantic Middleware for Ubiquitous Computing” PRINCIPLES OF THE CONFIGURABILITY PRINCIPLES OF THE CONFIGURABILITY UBIWARE Project DELIVERABLE D2.1 Workpackage WP4 TASK T2.1_w4 Workpackage leader Artem Katasonov

42. WP4 - Tasks • How a component of a system may realize the need for re-configuration of itself of the integral system, i.e. when the previous configuration of one or more components does not seem to work anymore? • What mechanism are needed for (re-)configuration of the integral system through local decision making of and supported by communication between agents representing components of the system (i.e. with no central decision maker)? The WP tasks for the Year 2 are the following: Task T2.1_w4 (research):Answer to the question above. Design of mechanisms for (re-) configuration of complex system in a distributed fashion. Task T2.2_w4 (development):Incorporating the research findings to the UBIWARE prototype.

43. Self-configuration and its benefits • The ability of the system to change the nature of its elements without any external programmer’s intervention • The system is able to configure itself based on some constraints • Types of self-configuration: • Self-configuration of the external environment • Self-configuration of UBIWARE components UBIWARE

44. DCOP as a mathematical model Distributed Constraint Optimization Problem Problem: • Group of several agents • Each agent is controlling one variable • Each variable has one domain • Group of constraints • Utility functions Goal: • find values for all variables with the highest global utility

45. X = {0,1}x{0,1}x{0,1}x{0,1} E = (Eij) U = {U12, U13, U23, U34} An Example of a DCOP problem Graph coloring problem • We have one graph that contains: • 4 vertices • 4 edges (links) • We have 2 colors – 0 and 1 • Condition for each edge: • On both sides there has to be a different color • Adjustment: Edge v1-v2 is less important then the rest

46. Reconfiguration When should a group of agents reconfigure? • The nature of the environment changed • Agents can sense the environment • If the influenced variable is present in at least one constraint, a change might be needed • The nature of the agent group changed • Infrastructure that keeps track of changes is needed • A new agent was added → Register • An old agent was removed → Unregister • Keep-alive mechanism

47. Complete algorithms Seek the global optimum Algorithms: Adopt OptAPO DPOP NCBB AFB Incomplete algorithms(k-optimal) Seek a local optimum k-optimum appears when there is no group of agents smaller or equal to k that can improve the solution Algorithms: MGM-1 DSA MGM-2 SCA-2 MGM-3 Comparison of existing algorithms

48. Test case: Self-configuration of a WiFi network Problem definition: • 4 WiFi access points (AP) in one building • We know the distance between them • Each AP can have 5 power levels: 0, 10, 20, 30, 40 mW Goal:Cover the whole area with the minimum interference Identification of variables and domains: Power level = 0, 10, 20, 30, 40 mW xi = {0, 1, 2, 3, 4} X = {0,1,2,3,4}x{0,1,2,3,4}x{0,1,2,3,4}x{0,1,2,3,4} X = {0,1,2,3,4}4

49. xi+xj=dij R=0 xi+xj<dij R=[dij-(xi+xj)] x (-3) xi+xj>dij R=[(xi+xj)-dij] x (-1) Test case: Self-configuration of a WiFi network Problem definition: • 4 WiFi access points (AP) in one building • We know the distance between them • Each AP can have 5 power levels: 0, 10, 20, 30, 40 mW Goal: Cover the whole area with the minimum interference Selection of utility functions and rewards: xi+xj=dij R=0 xi+xj<dij R=[dij-(xi+xj)] x (-3) xi+xj>dij R=[(xi+xj)-dij] x (-1) X = {0,1,2,3,4}4 E = (Eij) U = {U12, U14, U23, U34}

50. Conclusion and future work Conclusion • DCOP problem is a suitable way to solve the configuration problem in a multi-agent system • There are several complete and incomplete algorithms • Two real-life test cases were shown Next steps • Implement several algorithms • Compare the performance and suitability of them • Agent observable environment from WP1 can be used as a base for DCOP-solving algorithm implementation