activities of kuleuven
Post on 08-Jan-2016
20 Views
Preview:
DESCRIPTION
TRANSCRIPT
S
E
E
S
C
O
A
activities of KULeuven
(1) contract monitoring in general
(2) bandwidth contracts
(3) component system on other hardware Camera Surveillance case in a wireless environment
(4) iteration over component system
S
E
E
S
C
O
A
(1) SEESCOA Contract Monitor
Current status Contract-based approach
Monitor consists of 3 subsystems
Event collection/timestamping
Contract monitoring
Violation reporting
Is an optional part of SEESCOA component system
Default monitors for deadline and periodicity constraints
New monitor types can be added easily
Extensions Distributed contract monitoring
Online violation feedback
S
E
E
S
C
O
A
(1) Distributed Timing Monitoring
Distributed Monitoring Challenges Managing resource utilization
Extra network overhead due to the exchange of timing messages
Strategies needed for scheduling monitoring activities and managing the event history
Clock synchronization: clocks on the various nodes need to be synchronized in order to provide correct timestamps
SEESCOA Approach Monitoring functionality split in
Monitoring Node (# = 1): contract monitoring, violation reporting
Monitored Nodes (# = n): event collection/timestamping
Clock synchronization: NTP (Network Time Protocol)
Contract file (monitoring node) and Probe files (monitored nodes)
Violations made explicit through feedback ports (on contracts)
S
E
E
S
C
O
A
(1) SEESCOA Distributed Contract Monitor
Monitoring Node
NTPserver
Event Collector
Monitored Node 1
Monitored Node 2
NTPclient
EventSource
probefile
Sync. IFEvent Sort/Filter
DEADLINE PERIODICITY
Configcontract
file
ConfigClock IF
OTHER
Cn2
Cn3
Cn4
Cn5
Cn6
Probes
Cm1Cm2
feedback
[<node>:<comp.>\<port>\<hook>\<occ.> + timestamp]
Cn1
Violation reporting
S
E
E
S
C
O
A
(2) Bandwidth contracts
Why: Distributed SEESCOA components consume bandwidth Bandwidth feasibility should be checked at
design-time (component composition)run-time (component deployment)
Where: On each component’s ports
these produce messages
S
E
E
S
C
O
A
(2) Bandwidth contracts
How Statistical data-flow charact. of each port’s output Data-flow requirements on each port’s input
Data analysis No incomprehensible low-level data
no packets, time slots, ... From the designer’s point of view
Interval Time Between Messages (ITMB)Message Size (MS)
S
E
E
S
C
O
A
(2) Bandwidth contracts
Statistical analysis: Port output:
avg ITBM = aavg ITBM acc = bvar ITBM = cvar ITBM acc = dmax ITBM = emin ITBM = f
Port input:max ITMB < mn < min ITMBo < avg ITBM < pq < var ITMB < r
• avg MS = g• avg MS acc = h• var MS = i• var MS acc = j• max MS = k• min MS = l
• max MS < s• t < min MS• u < avg MS < v• w < var MS < x
S
E
E
S
C
O
A
(2) Bandwidth contracts
Design time contract check Do connected ports have compatible contracts?
matching contracts in both directions If not, design should be reviewed
Run-time contract check How much bandwidth can the middleware offer? Enough for connected ports with matching contracts? If not, conflict resolution:
relocationuser interaction
S
E
E
S
C
O
A
(2) Bandwidth contracts example data
Camera surveillance case: Bandwidth data characteristics from motion detector to switch
ITBM (ms) MS (bytes)
Average 17244 2999
Standard dev 29182 3010
Max 159427 5999
Min 766 30
KB/s
Average bandwidth needed: 0.170
Largest burst bandwidth: 3.824
S
E
E
S
C
O
A
(3) Component system on new hardware
Deploying component system on new hardware ARM processor on handheld PC (Compaq iPAQ) Linux operating system Java Virtual Machine
Deploying component system in wireless environment Using Bluetooth wireless communication (iPAQ built-in) Using Bluez protocol stack for Linux
S
E
E
S
C
O
A
(3) Wireless distribution of the test case
Camera Surveillance case in wireless environment Ad hoc communication possible (automatic link creation) Additional components to support ad hoc connection:
AdHocConnector: manages Bt communicationDesktopDispatcher: routes messages to desktop componentsIpaqDispatcher: routes messages to iPAQ components
TCP/IP over Bluetooth (no new transport protocols needed)
S
E
E
S
C
O
A
(3) Test scenario setup
S
E
E
S
C
O
A
(4) Improving the SEESCOA runtime
Current situation Working Implementation of the SEESCOA component standard Low Resource Usage
Improvements possible: Currently too much functionality in ‘Controller Component’
Reading and parsing ini-files Loading Components Distributed Aspects Connecting Component ports
Current design harder to extend Distributed Monitor Resource Monitoring Visualisation …
S
E
E
S
C
O
A
(4) Improving the SEESCOA runtime
New implementation: DRACO Modular Design that can be easily customized (e.g. add a
custom scheduler) Extensions to the Draco System are introduced using external
modules (no ‘controller-like’ functionality is placed in components)
Draco is not a component itself but offers a limited component-interface
External communication with Draco through a well defined interface that is implemented by a variety of shells
Detailed information on Draco can be found at the draco website: http://www.cs.kuleuven.ac.be/~yvesv/Draco
S
E
E
S
C
O
A
(4) Draco: architecture overview
S
E
E
S
C
O
A
K.U.Leuven Topics in Next Period
Monitor Distributed Monitoring (continued implementation in DRACO) New contract types
Specific timing contracts: Correlation, Periodicity (extended) Customizable timing contracts
Composer Tool Coupling design and implementation of application (code generation) Coupling design tool with monitor (contract generation)
Distribution module and Bandwidth monitoring Implementation of the distribution module in Draco Design & implementation of the bandwidth monitor for the distr. mod. Building a contract verifier that interacts with the bandwidth monitor
Dynamic Updating Implementation of dynamic updating in Draco
top related