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