hybrid collective adaptive systems

1

Hybrid Collective Adaptive Systems: Programming elements and incentive mechanisms

September 2015

Ognjen Šćekić

Distributed Systems GroupTU Vienna

dsg.tuwien.ac.at

2

Outline

• What are CAS? • Overview of research landscape.

• Motivating scenarios• Research challenges

• ... and how we tried to address them

• SmartSociety platform – a prototypical hCAS

• Focus on runtime controllability:• direct (programming)• indirect (incentivizing)

Collective Adaptive Systems• Collective Adaptive Systems – CAS

• Term jointly denoting highly diversified research fields

• Blending hybrid computational resources, social processes and inspiration from nature.

• The CAS book (written collectively from scratch in 3 days):

3http://focas.eu/documents/adaptive-collective-

systems.pdf

4

Machine-based Computing

Human-based Computing

Things-based Computing

Nature-basedComputing

Grid

Pro

cess

ing

Uni

tA

rchi

tect

ure

Com

m.

SMP

Ad hoc networks

Internet of things

CAS Computing Models

5

CAS Research Landscape• Multiple EU and national projects

• Coordinated through FoCAS• http://focas.eu/

6

Defining characteristics of CAS

7

hCAS – Where do we fit?

Focus on hybridity

Focus on humans and social aspects

Focus on collaboration

8

hCAS – Our vision• Hybrid Collective Adaptive Systems –

hCAS:

• Collaborative = ++Collective ;• People AND software complement each

other• socio-technical systems, social

machines• in future also ‘things’ (sensors,

actuators)• Respond/adapt to ad-hoc situations

• favor collaboration patterns instead of predefined workflows

• Leverage human creativity• Embrace uncertainty• No over-regulation• Human-driven adaptation

9

Motivating Scenario #1: Predictive Maintenance

• Humans: providing ad-hoc context interpretation and decision making

• Software: providing an on-demand sharing platform (Dropbox) and log mining and analytics service (splunk).

10

Motivating Scenario #2: Collaborative Ride-Sharing

11

hCAS – Challenges

• Virtualizing human and software elements

• Team formation • Execution orchestration• Privacy tradeoffs and ethical issues • Runtime control:

• direct: programming• indirect: incentives

12

Virtualizing human&software elements

• Existing approaches for virtualizing humans:

• service providers (e.g., HPS)• associating roles with

tasks/activities (e.g., BPEL4People)• free-form natural language

communication (e.g., Amazon mTurk)

• No uniform abstraction of the three approaches.

• No native concept of collective communicationP. Zeppezauer et al., Virtualizing communication for hybrid and diversity-aware collective adaptive

systems, WESOA@ICSOC, 2014.

13

SMARTCOM Middleware

[*] P. Zeppezauer, O. Scekic, H.-L. Truong, S. Dustdar: Virtualizing Communication for Hybrid and Diversity-Aware Collective Adaptive Systems, ICSOC’14 Workshops

14

Team formation

• Some existing approaches for team formation:

• no team formation – unstructured crowds (e.g., crowdsourcing platforms)

• social groups, i.e., individuals connected via relationships (e.g., social machines)

• algorithmic search and provisioning (e.g., SCU)

• swarm intelligence (e.g., swarm organs)

• Existing socio-technical systems do not support human-driven self-formation of teams

15

Past work: Algorithmic Team formation

Provisioning algorithms:

Ant Colony Optimization variants

FCFS Greedy

Trust model metrics:Supported query variables:

Skills Skill level (fuzzy) Connectedness

(fuzzy) Max Response

Time Cost Limit Optimization

objectives

[*] M.Z.C. Candra, H.-L. Truong, S. Dustdar: Provisioning Quality-aware Social Compute Units in the Cloud, ICSOC 2013.[*] M. Riveni, H.-L. Truong, S. Dustdar: Trust-aware Elastic Social Compute Units, TrustCom’15.

16

Execution orchestration

Important aspects:1. Runtime determination of

execution plans • as opposed to predefined*workflows only• coarse- vs fine-grained (think

choreography vs. orchestration)

2. Negotiation (on the plans)• guided by different protocols, but driven

by humans

3. Execution• self-enacted by human peers or

orchestrated by software peer(s)• monitored for constraint and QoR

satisfaction

17

Compose possible/optimal execution plans based on subtask offers submitted by crowd members. • Crowd requests dynamically determine possible execution

plans, involving both human activities and service invocations.

• Software determines acceptable plans w.r.t. user constraints. Plans are recommended/offered to interested crowd members Crowd are able to negotiate for participating in execution of

multiple plans concurrently, effectively making only a subset of them happen.

Negotiation orchestrated by the platform. Not trivial!

Composition

Offer

NegotiationExecution

Feedback

request

Execution orchestration[*] M. Rovatsos, D. I. Diochnos, M. Craciun: Agent protocols for social computation, W. on Multiagent Foundations of Soc. Comp., 2015.

18

Privacy tradeoffs and ethical issues

• Specific for systems involving humans as decision makers.

• Real example from ride-sharing: religion-gender issues

• Tradeoff: disclosing private data needed for decision making vs. restricted functionality

• Privacy by design, e.g.: • purpose specification• semantic obfuscation

[*] http://www.smart-society-project.eu/publications/deliverables/d_4_2/

Putting things together...

http://www.smart-society-project.eu/publications/deliverables/D_6_1/

crowd of human andmachine peers

www.smart-society-project.eu

[*] O. Scekic, et al.: SmartSociety -- A Platform for Collaborative People-Machine Computation, IEEE SOCA'15

[*] O. Scekic, et al.: SmartSociety -- A Platform for Collaborative People-Machine Computation, IEEE SOCA'15

Putting things together...

http://www.smart-society-project.eu/publications/deliverables/D_6_1/

crowd of human andmachine peers

www.smart-society-project.eu

privacy

model

virtualization &

communication

orchestration

team formation

virtualization &

communication

runtime control

21

Programming model for hCAS

• Collective-Based Task (CBT)• Concept representing a task to be

performed collectively.• Manages the lifecycle of the task across

different platform components.• Allows specifying different collaboration

models and adaptation policies.• Embodying properties of collectiveness and

adaptability.

22


[*] Ognjen Scekic, et al.: Programming Model Elements for Hybrid Collaborative Adaptive Systems, IEEE CIC'15

23


• Collective • Resident Collective (RC)

• Persistent collective defined and managed by peer store enforcing privacy model.

• Developer can know the members through their profiles defined by privacy model.

• represent a community, not a “task force”• Application-Based Collective (ABC)

• Temporary collective managed by application’s context used for specific task executions.

• Atomic and immutable to developer; platform can manage/change the composition (preventing user bias).

• Participants enjoy benefits of anonymity; platform guarantees reputation.

24


[*] Ognjen Scekic, et al.: Programming Model Elements for Hybrid Collaborative Adaptive Systems, IEEE CIC'15

25


26

Incentive Management

abstractioninterlayer

27


abstraction interlayer

• Identify common incentivizing patterns in existing systems• Express the patterns as compositions of fundamental,

platform-agnostic incentive elements.

28

Modeling Incentives

Examined incentive strategies in over 200 existing social computing platforms

Examined incentive mechanisms in economics, management science, sociology, psychology

Identified fundamental incentive mechanisms in use today and their constituent elements

New mechanisms can be built by composing and customizing well-known incentive elements

[*] O. Scekic, H.-L. Truong, S. Dustdar: Incentives and rewarding in social computing., Comm. ACM, 56(6), 72 (2013).

29



• Virtualize system-specific worker team representations into a system-agnostic model amenable to the application of incentives.

• Develop primitives for executing (applying) incentive actions.

30

Abstraction Interlayer

Allows modeling of human worker teams– storing and altering worker metrics– storing and altering worker structure– storing behavioral history and scheduling of incentive actions

Event-based communication with underlying socio-technical system

[*] Scekic, O., Truong, H.-L., Dustdar, S.: Programming incentives in information systems, CAiSE’13

31

Research Questions


• Design a declarative, human-friendly way of modeling incentives out of fundamental incentive elements.

• Translate the modeled incentive strategy into executable actions.

32

PRINGL – a DSL for Incentive Mgmt.

[*] Scekic, O., Truong, H.-L., Dustdar, S.: PRINGL: A Domain-Specific Language for Incentive Management in Crowdsourcing, Comp. Networks, 2015.

PRINGL – PRogrammable INcentive Graphical Language

Visuo-textual language– Graphical elements for modeling and

composing incentive elements– Traditional code snippets for additional

business logic

System-independent Human-friendly syntax Elements can be stored, shared, reused Translated to code executable on abstraction

interlayer

33

Managing Incentives with PRINGL

34

Conclusions

• Collective Adaptive Systems (CAS) – emerging and diversified field of interdisciplinary research, covering different computing and collaboration models, inspired by nature and society.

• Hybrid CAS – socio-technical systems characterized by notions of:• hybridity (collaboration of human and software peers)• collectiveness (collectives and not individuals are first class

citizens)• adaptiveness (driven by human peers) • controllability (direct and indirect)

35

Thanks for your attention!

Ognjen Šćekić

Distributed Systems GroupTU Wien

dsg.tuwien.ac.at

36

AcknowledgementsIncludes joint/ongoing work with members of the Distributed Systems Group (TU Vienna), and partners from the EU FP7 SmartSociety project (№ 600854). Co-sponsored by FoCAS (www.focas.eu).

www.smart-society-project.euwww.focas.eu www.tuwien.ac.at