1. Cooperating devices (research summary of SAN @ CS.TU/e)
Johan Lukkien
thanks to Yarema Mazuryk, Johan Muskens, Egor Bondarev, Dmitri Jarnikov
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

4. Characteristics Strong software orientation
Bias towards consumer electronics
embedded multi-media
many projects and cooperations with Philips Research
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

5. Typical context G G 29-Dec-18
Currently at home we have lots of software intensive devices. The trend is such, that eventually all these devices will become connected to the network, and we, certainly would like to benefit from it by, say, having applications in which several devices are collaborating. The challenge is that the devices may use different types of physical media, thus making the development of the mentioned applications extremely difficult. So, primarily, we would like to answer the question if there is a model (abstraction level) in which all devices look the same, disregarding their HW and SW platforms, types of network connection. This model has to take into account the nature of the home network, which can be described by following:
Wireless LAN
Firewire (IEEE1394)
Bluetooth
Ethernet
Powerline
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

6. Overview View on networked embedded systems Projects Conclusion
Service oriented architectures
Space4U
QoS for IHDN
Conclusion
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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)
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

9. Consequence Highly distributed applications Highly mobile code
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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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”
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

12. Key Aspects Transparent control Advanced interaction
Self organizing networks
Minimal (zero)
configuration
The PROGRESS workshop on domestic appliances defined a set of the research directions, which are interested to the industry as well:
Self organizing networks –
Privacy –
Embedded intelligence –
Transparent control –
Open communication protocols –
Minimal configuration of the systems –
Advanced interaction issues – (input and output part)
We think that the service oriented architectures is a framework, which can help addressing these issues. So what is the service orientation, and where do we see it’s place in the embedded Internet?
Privacy
Open protocols
Embedded intelligence
Transparent control
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

13. Overview View on networked embedded systems Projects Conclusion
Service oriented architectures
Space4U
QoS for IHDN
Conclusion
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

15. Service Oriented Architectures
+name
Service
Description
Service Advertisement
Service
Implementation
Service
Advertisement
provides
+address
+address
uses
retrieves
Service
Discovery
Service
User
Eventing,
Control
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

16. SOA advantages Modularity and generality Location transparency
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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

17. SOA - Place Application Middleware Service Oriented Platform
Client1
Service1
Application
Client
API
Service
API
Client
API
Service
API
Middleware
Service Oriented
Platform
Service Oriented
Platform
Transport
Transport
Open protocol
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

19. Performance (discovery latency, memory usage, ...)
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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

20. Overview View on networked embedded systems Projects Conclusion
Service oriented architectures
Space4U
QoS for IHDN
Conclusion
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

22. High Volume Consumer Electronics
Domain
High Volume Consumer Electronics
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

23. Scope: Component Based Middleware
Device
Applications
App N
. . .
App 2
App 1
Middleware
RC N
RC 2
RC 1
Run-time Environment
Device Hardware
External World
The middleware must enable:
robust and reliable operation
upgrading and extension
component trading
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
Component Entry point
Executable Component
Service 1
Manager
Service1
Instance 1
Service 2
Instance 2
Service2
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

25. Goal: Maintain System Integrity
Network
Nokia
Server
3rd Party
During component addition,
removal,
replacement
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

26. ? Network Questions Nokia Server 3rd Party
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?
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

27. Is this device healthy? Application profile Middleware profile
Reference
Model
Nokia
Server
Network
Device
Applications
App N
. . .
App 2
App 1
Middleware
RC N
RC 2
RC 1
Run-time Environment
Device Hardware
External World
Application
profile
Middleware
profile
Platform
profile
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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)
Device
Applications
App N
. . .
App 2
App 1
Middleware
RC N
RC 2
RC 1
Run-time Environment
Device Hardware
External World
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

29. Middleware Example Part of my middleware: <middleware>
<rre version='0.42a'/>
<componenent guid='BCF018E0-01CF-D711-87C C31AC'>
<location url='file:/libadvancedcomputerplayers.so'/>
<service guid='20688A2F-01CF-D711-87C C31AC'/>
</component>
<componenent guid='B FCD-42EA-BCF0-90F67FE557C7'>
<location url='file:/libcomputerplayers.so'/>
<service guid='6782A98F-06D5-436F-AE89-0D6E064AB047'/> ..
<complies>
<complies_relation from='20688A2F-01CF-D711-87C C31AC' to='20688A2F-01CF-D711-87C C31AC'>
<complies_relation from='68CCA7C4-C24A-4BEE-9A5E-AF79B806483D' to='20688A2F-01CF-D711-87C C31AC'>
<complies_relation from='6782A98F-06D5-436F-AE89-0D6E064AB047' to='6782A98F-06D5-436F-AE89-0D6E064AB047'>
</complies>
</middleware>
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
Tasks synchronization point
Component 1
Function1:
Execution time A
Component2
Function1:
Execution time Y
Function2:
Execution time X
Component 3
Function1:
Execution time Z
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

32. Overview View on networked embedded systems Projects Conclusion
Service oriented architectures
Space4U
QoS for IHDN
Conclusion
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

34. Typical context G G 29-Dec-18
Currently at home we have lots of software intensive devices. The trend is such, that eventually all these devices will become connected to the network, and we, certainly would like to benefit from it by, say, having applications in which several devices are collaborating. The challenge is that the devices may use different types of physical media, thus making the development of the mentioned applications extremely difficult. So, primarily, we would like to answer the question if there is a model (abstraction level) in which all devices look the same, disregarding their HW and SW platforms, types of network connection. This model has to take into account the nature of the home network, which can be described by following:
Wireless LAN
Firewire (IEEE1394)
Bluetooth
Ethernet
Powerline
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

38. Experiment Controlled versus best-effort algorithm Steady vs. variable
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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

39. Some results at 40 ms budget: graph variable:
Table 1 – Number of quality level changes
Algorithm
‘Steady’ test
‘Variable’ test
‘Controlled’ 24
1484
‘Best-effort’
36322
29411
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

41. Overview View on networked embedded systems Projects Conclusion
Service oriented architectures
Space4U
QoS for IHDN
Conclusion
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

42. Some research topics SOA QoS support in contained domain
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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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’
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

46. Interoperability: heterogeneous context
Currently at home we have lots of software intensive devices. The trend is such, that eventually all these devices will become connected to the network, and we, certainly would like to benefit from it by, say, having applications in which several devices are collaborating. The challenge is that the devices may use different types of physical media, thus making the development of the mentioned applications extremely difficult. So, primarily, we would like to answer the question if there is a model (abstraction level) in which all devices look the same, disregarding their HW and SW platforms, types of network connection. This model has to take into account the nature of the home network, which can be described by following:
Wireless LAN
Firewire (IEEE1394)
Bluetooth
Ethernet
Powerline
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking

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
29-Dec-18
Johan J. Lukkien,
TU/e Computer Science, System Architecture and Networking