• No results found

Memorandum. Zie bijlage. Behavioural and Societal Sciences Kampweg DE Soesterberg Postbus ZG Soesterberg. Van Dr. J.B.F.


Academic year: 2021

Share "Memorandum. Zie bijlage. Behavioural and Societal Sciences Kampweg DE Soesterberg Postbus ZG Soesterberg. Van Dr. J.B.F."


Loading.... (view fulltext now)

Full text



Behavioural and Societal Sciences Kampweg 5 3769 DE Soesterberg Postbus 23 3769 ZG Soesterberg www.tno.nl T +31 88 866 15 00 F +31 34 635 39 77 infodesk@tno.nl Datum 31 juli 2012 Onze referentie M10391 Doorkiesnummer +31 88 866 59 82 Van Dr. J.B.F. van Erp Onderwerp

ePartner architecture workshops 'The Results'


dinsdag 31 juli 2012

ePartner architecture workshop

The results



This presentation is the deliverable of the ePartner architecture workshop held on April 23 – 24, 2012 in Zeist as part of

ETP Gedrag & Innovatie.

What is an ePartner?

What are the requirements for an ePartner?

How does the architecture for an ePartner framework look like? Conclusions

Future work/Open research questions Roadmap


What does a ePartner do?

Support a human during life to realize human needs (Maslow*)

Physiological needs (e.g., nutrition) Safety needs (e.g., personal and

financial security, health and well-being) Belonging (e.g., social support)

Esteem (e.g., acknowledgement) Self-actualization (e.g., learning)


How does a ePartner do it?

An ePartner …

… collects data about the user and context (physical, social, temporal) … reasons, based on what all ePartners (and what their users?)

collectively know

… responds in a human-like manner (intuitive, empathetic, affective, own character) to what it knows

… socializes, i.e., involve social environment and ePartners


What are ePartner requirements?

An ePartner should …

… keep information private and safe

… be trustworthy for the user

… use its information in an ethical way


Task: construct an ePartner architecture

Group task

Construct a common, coherent and consistant architecture for ePartners to be developed in.

Proposed solution

Service oriented architecture based on intelligent sensor networks Tailored towards specific human-ePartner needs



Architecture: the big dataflow picture


“Isolation” of apps from sensing


Architecture: dataflow details

SUBWORLD MODEL S A DAQ & PROC APP primary (“raw”) derived (“processed”) proc. component proc. component processing component “trusted” app as processing component Implicit is the dataflow graph!


Architecture: dataflow details

connection (e.g. internet) proxy processing functionality proxy processing functionality access control discovery payment


Control flow


tokens world state

dataflow graph

Time scheduling is in the planner and NOT in DAQ & APP

general planning knowledge heuristics etc.



PLANNER tokens world state

dataflow graph general planning knowledge

heuristics etc.

Planner receives tokens (requests for information: calculation or acquisition from sensor &/or user)

It determines if, when and in which order to release propagated tokens

It considers metadescriptors (Quality, Timewindow, etc) in this process.


Flow of control

Keeping world model up to date always might not be useful all the time (wasting computation and communication resources)

Processing graph defines the dependencies between output, transformations and input

Request propagation needs non-trivial processing (because of specific ePartner requirements) [The planner]


Let’s add an app!

APP An app always has a descriptor

Simple case: all requirement for the app are already available on the device -> deploy and have fun.

Complex case: matching process takes into account: local capabilities and

available components in repository and makes a decision which components should be deployed

Matching can be simple or complex optimization process

Management (matching) can be done locally (not optimized) and centralized

DESCRIPTOR Input? Computational demand? Storage demand? Permissions/Payment? Repository

- Apps with descriptor

- Processing functionalities

- Data acquisition


Example: exercise/workout app

Basic idea: calculate the energy burned and giving feedback on quality of exercise. SUBWORLD MODEL S A DAQ & PROC APP primary (“raw”) derived (“processed”) proc. component proc. component processing component EW App S GPS Accelero User GPS Acc Motion state estimation Mood estimator

User (with attributes)




Each containing (Value, Unit, Certainty, Time stamp and

Time window)


Example: exercise/workout app data flow

Mood estimator APP Quality of exercise APP Energy burned Position estimator Speed estimator S user S gps S acc Quality/scoring Calories A screen A screen T T T T T

Token indicating the primary request for calorie information Propagated

tokens Both tokens are merged


Architecture: Physical view

ePartner architecture runs primarily local, but can be synchronized with your own home server (for backup and history, family etc)

ePartner server for repository and directory services (look up other ePartners) (Explicitly NOT sharing subworld models here)

ePartners can communicate over networks (Wifi/3G to internet, Bluetooth to local devices)



Different markets need specific ePartners

A generic framework helps TNO to create ePartners in a more efficient en faster way

A service oriented architecture could be tailored to fit the ePartner architecture needs

The ePartner expert group has a common understanding of the ePartner architecture

This outcome forms a solid base for future broad use within TNO


Future work/ Open research questions


Hoe afhankelijk is de privacy van gebruikers voor verschillende toepassingen.

Wat gebeurt er met privacy gevoelige gegevens binnen de ePartner? Wie is eigenaar?


Welke verantwoordelijkheden heeft een ePartner in ethische kwesties?

tov van de gebruiker tov de maaatschappij

“met drank op achter het stuur”, “door rood lopen”, advies rondom

zwangerschap” Einde van het spectrum: “Waar kan ik hier een bom kopen?”


Hoe perfect moet je ePartner zijn?

Hoe dwingend is de suggestie van een ePartner? In hoeverre vertrouwt de ePartner de informatie over jou?


“Zal ik dit voortaan automatisch voor je doen?”


why does ePartner behave the way it does and for whom?


Proposed steps towards implementation

First start with a mobile device and a server (for example use Android)

Extend the functionality

Extend the number of devices

Who to ask for implementation Service Oriented Architecture SOAP?

Mobile computing group TNO mobility DSS/imaging The Hague



2012 2017 2022

Current assistants are fragmented and standalone

Future ePartners are integrated, connected and personal

from Assistants to ePartners

Stand alone device

Fragmented apps

Single tasks

Reason over large datasets


Integrated in daily life Ambient &

non intrusive


Persuasive Sub conscious



Related documents

Thus, to produce counterfactual interest rate paths for each member-state, we estimate five different rules, using two sets of models: (i) a baseline linear rule, (ii) an

Cross, B.A., J.D., Associate Dean for Administration, Director of Legal Research, Writing and Advocacy Program and Senior Lecturer in Law.. Lynn Switzer Bozalis, B.A., J.D.,

However, to the extent that it would be possible to operate a department store or a manufacturing plant by capi- talizing the enterprise with deductible

The strongest evidence at present for active ingredients to reduce stigma pertains to direct social contact with people with mental illness, which has been shown to be effective

Unlike UV, higher expression of all six PA genes after blast infection in OsMKK6 EE overexpressing plants suggest possible role Figure 3 Staurosporin and MAPK cascade

Architecture has been proposed to implement the data security in cloud computing using symmetric cryptography technique.. The proposed architecture is based on block

Should the aid require repair in the following year, both the service and repair fees may be claimed regardless of when the repair occurs. Following this, the fees cannot be claimed

It can be acquired and implemented in any of several manners that significantly reduce the need for capital investment, that place the responsibilities (and costs) for software