Johan J. Lukkien, [e-mail]

1
Cooperating devices(research summary of SAN _at_
CS.TU/e)

• Johan Lukkien
• thanks to Yarema Mazuryk, Johan Muskens, Egor
  Bondarev, Dmitri Jarnikov

2
SAN, position

• One of eight research groups of Computer Science
• Visualization, Algorithmics
• Formal methods, Software construction
• Architecture of Information Systems, Databases
  Hypermedia
• Design and analysis of systems, SAN
• Staff 7 full-time, 4 part-time
• Temporary 12

3
General research area of SAN

• Networked, resource-constrained embedded systems
• distributed systems, distributed computing
• architecture, in particular, software
• non-functional requirements
• real-time techniques
• resource sharing (QoS), resource allocation
  (budgets)
• performance analysis
• systematic development of special-purpose
  algorithms
• e.g. signal processing for specialized embedded
  hardware

4
Characteristics

• Strong software orientation
• Bias towards consumer electronics
• embedded multi-media
• many projects and cooperations with Philips
  Research

5
Typical context
G
G
Wireless LAN
Firewire (IEEE1394)
Bluetooth
Ethernet
Powerline
6
Overview

• View on networked embedded systems
• Projects
• Service oriented architectures
• Space4U
• QoS for IHDN
• Conclusion

7
General view

• Evolution of networked embedded systems
• network unaware
• embedded hardware inaccessible
• network aware
• simple, proprietary connection to outside world
• network connected
• network is add-on, remote access, standards
• network central
• network(s) gets into the system design
• fully networked
• network connectivity essential for core
  functionality (single device rather useless)

8
Network central

• Devices have a stand-alone function
• PDA, TV set
• In addition, they serve as platform for
  networked applications
• specific device capabilities available on the
  network
• display, internal hardware (e.g. codecs),
  internal memory
• support for hosting (networked) applications
• components that can be down- and re-loaded
  routinely

9
Consequence

• Highly distributed applications
• composed of the cooperation of small services
• Highly mobile code
• services and applications realized in independent
  components that can be down- and re-loaded
  routinely
• Embedded knowledge
• decisions taken without direct user involvement
• at most some steering
• need a reference that separates good from bad
  decisions
• model, learning, feedback-control loops
• intelligence at many levels
• protocols, algorithms, system

10
Fully networked

• No stand-alone function
• dedicated, single function components
• e.g. networked storage, internet radio
• cheap devices, elementary behavior
• sensing, actuating, computing, communicating
  (sensor networks)
• Applications arise from cooperation

11
Automatic and invisible

• Devices cooperate to support user goals
  applications
• partners not known at design time
• applications not known at design time
• Cooperation goes beyond electrical standards and
  protocols, e.g.
• agreements on sharing of resources
• network, processing, storage
• derivation of behavior from general goals
• rather than explicit programming by a user
• resilience against service mobility
• Auto-configuration towards the application level

12
Key Aspects
Advanced interaction
Self organizing networks
Minimal (zero) configuration
Privacy
Open protocols
Transparent control
Embedded intelligence
13
Overview

• View on networked embedded systems
• Projects
• Service oriented architectures
• Space4U
• QoS for IHDN
• Conclusion

14
SOA characteristics

• Service behavior according to a contract
• functionality, quality and interface
• Complete decoupling of service provider and user
• through description, advertisement discovery
• Examples
• file service
• provided by networked storage, used by digital
  camera
• display service
• provided by PDA, used by thermostat
• transcoding service
• provided by PC, used by PDA

15
Service Oriented Architectures
Service
name
Service Description
Service Advertisement
Service Implementation
address
address
Service User
16
SOA advantages

• Modularity and generality
• must support composition, hierarchy
• build new services from existing ones
• Location transparency
• no need to know where service resides
• Tolerant against service failure
• no crash in case of absence or failure
• Very late binding

17
SOA - Place
Service1
Client1
Application
Client API
Service API
Client API
Service API
Middleware
Service Oriented Platform
Service Oriented Platform
Transport
Transport
Open protocol
18
SOA - use

• Design applications as a set of cooperating
  services
• make capabilities of an embedded system available
• storage, embedded algorithms, display, ...
• select service based on description
• more than one service may fit
• publish find bind execute
• Examples (more or less)
• UPnP
• Jini (?)
• JXTA
• Corba
• Web services

19
Case Study
Distributed Data Storage in Service-Oriented
Fashion
JXTA
UPnP
...
ANALYZE COMPARE Performance (discovery
latency, memory usage, ...) Scalability Ad hoc
networking Client mobility ...
PROPOSE Service Oriented Framework
20
Overview

• View on networked embedded systems
• Projects
• Service oriented architectures
• Space4U
• QoS for IHDN
• Conclusion

21
Project Space4U

• ITEA (european context, applied research)
• Space4U elaborates on previous project Robocop
• TU/e contribution
• addresses software inside user terminals the
  consequences of routine download
• system integrity (SAN)
• secure download and remote diagnostics (SAN)
• predictable assembly (prof.dr. P.H.N. de With)
• software visualisation (VIZ)
• lead by Michel Chaudron

22
Domain

• High Volume Consumer Electronics

23
Scope Component Based Middleware
The middleware must enable robust and reliable
operation upgrading and extension component
trading
24
Robocop Executable Component

• Services have explicit dependencies
• Requires interfaces
• Services have interface for managing dependencies
• Services are instantiated at Run Time
• Service Manager is responsible for
• Instantiating services
• Presetting attributes
• Service Instance is an entity with its own data
  (state) and a unique identity
• Components are instantiated in OS terms
• Static in process (LIB)
• Dynamic in process (DLL)
• Dynamic out process (EXE)
• Component Entry point provides fixed entry points
  to
• Register to Run Time
• Service Manager

25
Goal Maintain System Integrity
During component addition,
removal,
replacement
26
Questions
?

• Is current system configuration healthy?
• Will system configuration be healthy after change
  X ?
• What modifications to the system configuration
  are needed to cure a un-healthy system?

27
Is this device healthy?
Reference Model
Nokia Server
Network
Application profile
Middleware profile
Platform profile
28
Middleware Profile

• Middle profile provides info on
• Run time Environment
• Version
• QoS Support (Yes / No)
• Registered components
• Location on the device
• Services
• Complies relations (between services)

29
Middleware Example
Part of my middleware
ltmiddlewaregt ltrre version'0.42a'/gt
ltcomponenent guid'BCF018E0-01CF-D711-87C6-0008744
C31AC'gt ltlocation url'file/libadvancedcomputer
players.so'/gt ltservice guid'20688A2F-01CF-D711-
87C6-0008744C31AC'/gt lt/componentgt ltcomponenent
guid'B7621504-7FCD-42EA-BCF0-90F67FE557C7'gt
ltlocation url'file/libcomputerplayers.so'/gt
ltservice guid'6782A98F-06D5-436F-AE89-0D6E064AB04
7'/gt lt/componentgt .. ltcompliesgt
ltcomplies_relation from'20688A2F-01CF-D711-87C6-0
008744C31AC' to'20688A2F-01CF-D711-87C6-0008744C3
1AC'gt ltcomplies_relation from'68CCA7C4-C24A-4BE
E-9A5E-AF79B806483D' to'20688A2F-01CF-D711-87C6-0
008744C31AC'gt ltcomplies_relation
from'6782A98F-06D5-436F-AE89-0D6E064AB047'
to'6782A98F-06D5-436F-AE89-0D6E064AB047'gt ..
lt/compliesgt lt/middlewaregt
30
Goal predictable assembly

• Find out at runtime what the non-functional
  requirements are of a set of cooperating
  components
• select component that fits
• perform reservations

31
Challenge to find required budget
Application

• to find required budget, we need to know timing
  properties of application (tasks, their period,
  deadlines and execution times)
• additionally, the tasks synchronization must be
  known
• to find task execution time we must know
  execution times of functions composing the task
• the platform nuances must be taken into account
  (context switches, caching, etc)
• Conclusion 3 different levels of defining timing
  properties
• - system level
• - application level
• - component level

Component 1 Function1 Execution time A
Component2 Function1 Execution time
Y Function2 Execution time X
Component 3 Function1 Execution time Z
32
Overview

• View on networked embedded systems
• Projects
• Service oriented architectures
• Space4U
• QoS for IHDN
• Conclusion

33
Project Quality of Service for IHDN

• Delivery of multimedia streams
• Assume a controlled domain
• clear notion of inside (in the home) and
  outside
• Three levels where QoS is addressed
• System level
• Application level
• Protocol level

34
Typical context
G
G
Wireless LAN
Firewire (IEEE1394)
Bluetooth
Ethernet
Powerline
35
System level

• System collection of devices and wiring making
  up the IHDN
• Address global optimization decisions
• trade-offs between computation and communication
• assignment of budgets (processing, bandwidth)
• typically cooperating OS kernels
• Need clear quality interface to protocol and
  application-level
• application must support negotiation of quality
• protocols and applications must comply with
  assigned budgets

36
Application use scalable algorithm

• Scalable support trade-off between resource
  consumption and quality
• can be done in the coding and/or in the transport
• Transport multi-layered video
• base layer enhancement layers
• quality triple
• ( layers, deadline misses, quality level
  changes)
• levels can be used to control both bandwidth
  and compute power

37
Work done (Dmitri Jarnikov)

• Development of a multi-layered encoding that
  limits dependencies between layers
• so loosing a frame affects fewer others
• Development of a method that limits the number of
  quality changes
• based on a Markov Decision process
• off-line
• Current work
• include feedback control
• on-line (dynamic) parameters

38
Experiment

• Controlled versus best-effort algorithm
• best effort show what is available at deadline
• Steady vs. variable
• variable change received layers randomly,
  every 4s on average
• 3 layers
• low budget controlled sacrifices quality to
  minimize deadline misses
• sufficient budget controlled performs better

39
Some results

• at 40 ms budget
• graph variable

Table 1 Number of quality level changes Table 1 Number of quality level changes Table 1 Number of quality level changes
Algorithm Steady test Variable test
Controlled 24 1484
Best-effort 36322 29411
40
Protocol level

• Design (transport) protocols to combine media and
  stream properties
• improving the best effort behavior of e.g. TCP
• Current work (Sergei Kozlov)
• Adapt TCP only at receiver side to better deal
  with certain failure models
• TCP-MM good results for video over WLAN (bursty
  loss)
• Continue with combining with multiple layering
• take what is transported into account

41
Overview

• View on networked embedded systems
• Projects
• Service oriented architectures
• Space4U
• QoS for IHDN
• Conclusion

42
Some research topics

• SOA
• investigate (taxonomize, evaluate) the
  alternatives
• service programming notation (scripting...)
• specification of (user) goals, embedded reference
  model steering system behavior
• dealing with non-functional requirements
• QoS support in contained domain
• e.g. controlling MAC layer from middleware
• real-time and networking
• Privacy, security and trust in these environments
• Representation of knowledge, intelligence

43
Some conclusions

• Ambient intelligence requires open, flexible
  systems
• cooperation beyond the protocol level
• New perspectives in design
• service orientation
• Embedded intelligence plays at multiple levels
• intelligence stack

44
System Architecture

• Architecture
• ... externally visible, overall structure of a
  system in terms of components, subsystems and
  interconnections
• ... the basic interfaces and interactions
• between these components
• and with the system environment
• The architecture is the prime place to address
  non-functional requirements
• timeliness, energy, speed
• look-and-feel, scalability, distribution, fault
  tolerance, security, consistency

45
Networking

• Whenever the interconnection pattern of
  components itself is of explicit interest
• topology
• as well as the signals/messages exchanged via
  these interconnections
• protocols defined and developed independent from
  the component themselves
• open and general purpose
• and the fact that the system is distributed
• distributed algorithms, concurrency
• Central in the architecture, these days!
• Trend everything gets networked

46
Interoperability heterogeneous context
G
G
Wireless LAN
Firewire (IEEE1394)
Bluetooth
Ethernet
Powerline
47
The situation

• Just pick your standard, there are enough of
  them
• different carriers lead to different domains
• ethernet (IEEE 802.x), bluetooth, powerline,
  firewire, IrDA, homePNA, LON, USB,...
• need routers, gateways
• different requirements lead to different network
  technologies not everything is IP
• timing requirements, bandwidth

48
Integrate gateway technology into SOA

• No single protocol
• take heterogeneous nature for granted
• pertains to physical architecture, network
  layering and middleware
• islands of devices that speak the same language
• Design for integration
• e.g. automatic proxy service for subnetworks
• middleware level, translating meaning
• discovery advertisement cross technology
• integrate functionality with existing software
• e.g. derive home-net control info from Outlook