Multi-Design: designing self-adaptation of smart space features

1. Multi-Design:designing self-adaptation of smart space features João Pedro Sousa George Mason University USA Dagstuhl Seminar 10431―Oct 24-29, 2010 • Software Eng for Self-adaptive Systems

2. situate the workwhat adaptation footprint context- aware phone ring app w/ config file multi-Design Rainbow multi-Design Rainbow multi-Design SASSY SASSY SASSY SASSY automated MDD self-mod code SASSY

3. smart spacesmerge computing and physical world • spaces • public streets, train stations • organizational buildings, buses • private homes, cars • apps • safety and surveillance • energy management • health & assisted living • work & entertainment anywhere • …

4. smart spacesmerge computing and physical world • spaces • public streets, train stations • organizational buildings, buses • private homes, cars • users • move between spaces • bring expectations aka reqs • features, QoS

5. this talkmulti-Design • multi-Design: • system may adoptmultiple designsdepending on which users are present • multi-user design: • one design for multiple users • self-adaptation stems from • sharing of cyber-physical services • explicit intentions in design artifacts

6. design notations w/ complete semanticsfully automated deployment • users deploy and retire design artifacts at will middleware middleware • middleware • takes design artifacts as input • discovers and briefs/coordinates the required services • spatial constraints in the design guide discovery

7. expectations of mobile userscaptured as design artifacts • set of available design artifacts change as users come and go middleware middleware

8. users share physical spacesand the services deployed therein • set of available design artifacts change as users come and go middleware middleware purely software services can be replicated and sandboxed offering each user a logically separate systemeven if deployed on the same device(s)

9. multi-design design of a situated systemrun-time view: which components it includes and how they are interconnectedchanges with the designs users bring to a space and decide to deploy • set of available design artifactschange as users come and go middleware middleware • cyber-physical services may be logicallyshared among users • multi-touch table • thermostat next slide

10. logical sharing of servicesmay result in conflicting settings SASSY a relative of BPMN • users may create designs to set the thermostat in each space • Bob prefers 72ºF, Fred prefers 68ºF • other examples: TV channel, music volume, any numeric setting • what should happen when Bob and Fred are present?

11. approach:promote resolution mechanisms to design levelso that stakeholders may change policies at will (c) Schema made by the stakeholders at a specific space SASSY a relative of BPMN setTemp setTemp t:thermostat ask O S LM rem default default • space stakeholdersdefine resolution policy for accessing shared service(s) • access: authorized, open • multiplexing: exclusive, shared • resolution : fcfs, priority, least misery,…

12. track(Fred) track(Bob) approach:promote resolution mechanisms to design levelso that stakeholders may change policies at will heating @ anywhere • @.. set thermostat set leave heating @ anywhere TeC – a relative of spreadsheets • @.. pref thermostat set • space stakeholdersdefine resolution rules for accessing shared service(s) • principles are transferrable to different design notations

13. outlineself- adaptation in multi-Design context- aware phone ring multi-Design Rainbow multi-Design Rainbow multi-Design SASSY SASSY SASSY SASSY automated MDD self-mod code SASSY

14. track(Bob) dry self-adaptationcaptured in a design artifact • control deployment of sub-systems • start • stop save energy @ Bob.org/home @../laundry • save@../electric drying save smart meter pricey pause started cheap done resume • a smart power meter at Bob’s home issues pricing signals • Bob wants clothes dryer to suspend drying during high rates • and to resume only when night rates are in effect • Bob’s wife would like to have her clothes dry regardless

15. in summarymulti-Design • self-adaptation of cyber-physical SOA systems • system goals: dynamic, temporary, multiple, possibly conflicting • adaptation triggers: functional, foreseeable • mechanisms: assisted by middleware • structural: merging of systems, start and stop subsystems • parametric: conflict resolution • effects: mission-critical, safety-critical • applicable to a variety of design notations • SASSY – relative of BPMN – for domain experts • TeC – relative of spreadsheets – for end users

16. questions