1 / 16

activities of KULeuven

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. (1) SEESCOA Contract Monitor. Current status Contract-based approach

naif
Download Presentation

activities of KULeuven

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. (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

  3. (1) Distributed Timing Monitoring • Distributed Monitoring Challenges • Managing resource utilization • Extra networkoverhead 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)

  4. (1) SEESCOA Distributed Contract Monitor Monitoring Node Cn1 Cm2 Cm1 Cn3 Cn5 Monitored Node 2 Cn2 Cn4 Cn6 Monitored Node 1 Violation reporting feedback DEADLINE PERIODICITY OTHER Probes Event Sort/Filter Sync. IF Config Config Clock IF Event Source contract file probe file NTP server Event Collector NTP client [<node>:<comp.>\<port>\<hook>\<occ.> + timestamp]

  5. (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

  6. (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)

  7. (2) Bandwidth contracts • Statistical analysis: • Port output: • avg ITBM = a • avg ITBM acc = b • var ITBM = c • var ITBM acc = d • max ITBM = e • min ITBM = f • Port input: • max ITMB < m • n < min ITMB • o < avg ITBM < p • q < 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

  8. (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: • relocation • user interaction

  9. (2) Bandwidth contracts example data • Camera surveillance case: • Bandwidth data characteristics from motion detector to switch

  10. (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

  11. (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 communication • DesktopDispatcher: routes messages to desktop components • IpaqDispatcher: routes messages to iPAQ components • TCP/IP over Bluetooth (no new transport protocols needed)

  12. (3) Test scenario setup

  13. (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 • …

  14. (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

  15. (4) Draco: architecture overview

  16. 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

More Related