This document discusses hybrid collective adaptive systems (hCAS), which are socio-technical systems characterized by collaboration between human and software peers. It outlines research challenges in programming and controlling hCAS through both direct programming and indirect incentive mechanisms. It presents the SmartSociety platform as a prototype hCAS that addresses runtime controllability through a programming model and incentive management abstraction layer.

1. Hybrid Collective Adaptive Systems:
Programming elements and incentive mechanisms
September 2015
Ognjen Šćekić
Distributed Systems Group
TU Vienna
dsg.tuwien.ac.at
1

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)
2

3. 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):
3
http://focas.eu/documents/adaptive-collective-systems.pdf

4. Machine-based
Computing
Human-based
Computing
Things-based
Computing
Nature-based
Computing
Grid
Processing
Unit
ArchitectureComm.
SMP
Ad hoc
networks
Internet of
things
CAS Computing Models
4

5. CAS Research Landscape
• Multiple EU and national projects
• Coordinated through FoCAS
• http://focas.eu/
5

6. Defining characteristics of CAS
6

7. hCAS – Where do we fit?
Focus on hybridity
Focus on humans
and social aspects
Focus on collaboration
7

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
8

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).
9

10. Motivating Scenario #2:
Collaborative Ride-Sharing
10

11. hCAS – Challenges
• Virtualizing human and software elements
• Team formation
• Execution orchestration
• Privacy tradeoffs and ethical issues
• Runtime control:
• direct: programming
• indirect: incentives
11

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 communication
12

13. SMARTCOM Middleware
13
[*] 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
14

15. Past work: Algorithmic Team formation
15
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
16

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!
request
Execution orchestration
17
[*] 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
18
[*] http://www.smart-society-project.eu/publications/deliverables/d_4_2/

19. Putting things together...
crowd of human and
machine peers
www.smart-society-project.eu [*] O. Scekic, et al.: SmartSociety -- A Platform for Collaborative People-Machine Computation, IEEE SOCA'15

20. [*] O. Scekic, et al.: SmartSociety -- A Platform for Collaborative People-Machine Computation, IEEE SOCA'15
Putting things together...
crowd of human and
machine 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.
21

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

23. Programming model for hCAS
• 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.
23

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

25. Programming model for hCAS
25

26. Incentive Management
abstraction
interlayer
26

27. Incentive Management
abstraction
interlayer
• Identify common incentivizing patterns in existing systems
• Express the patterns as compositions of fundamental,
platform-agnostic incentive elements.
27

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).28

29. Incentive Management
abstraction
interlayer
• Virtualize system-specific worker team representations into a
system-agnostic model amenable to the application of incentives.
• Develop primitives for executing (applying) incentive actions.
29

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
30

31. Research Questions
abstraction
interlayer
• Design a declarative, human-friendly way of modeling incentives
out of fundamental incentive elements.
• Translate the modeled incentive strategy into executable actions.
31

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
32

33. Managing Incentives with PRINGL
33

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)
34

35. Thanks for your attention!
Ognjen Šćekić
Distributed Systems Group
TU Wien
dsg.tuwien.ac.at
35

36. Acknowledgements
Includes 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.eu
36
www.focas.eu www.tuwien.ac.at