Johan Muskens

1
(No Transcript)
2
Outline

• Problem domain
• Scope
• Introduction to Robocop
• Research topics in Space4U
• Initial Ideas on some of these topics
• Fault Management
• Terminal Management

3
Problem domain

• High Volume Consumer Electronics

4
Scope

• Component Based Middleware

5
Introduction to Robocop
6
Robocop aim

• Aim
• Define an open, component-based framework for
  the middle-ware layer in high-volume consumer
  devices
• that enables
• robust and reliable operation
• upgrading and extension
• component trading

7
Robocop Component

• A Robocop Component is a set of Models
• Model can be machine and/or human readable /
  executable
• Typically one of those is executable on a target
  system
• Called the (executable) component
• No definition of the packaging yet
• (such as .NET assembly)
• (thinking about e.g. XML)

8
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

9
Things to remember about Robocop

• A Robocop Component is a set of models

• Execution component contains a set of Services

• Service has set of Interfaces (provides
  requires)

• An Interface has a set of Operations

• At runtime Services are instantiated (Service
  Instance ? object)

10
Our Research Topics (for Space4U)
certification of real-time components
maintain integrity
design of real-time components
repair a broken system
adapt a system
11
Fault Terminal Management

• Fault Terminal Management have in common that
  they aim to maintain system integrity Health
  Management
• Fault Management handles unforeseen events
• Terminal Management handle foreseen changes
• Both tasks may benefit from the same mechanisms.

12
Health Management

• Goal Maintain a system integrity

Self External
Prevention
Monitoring
Diagnosis
Curing
Who
Tasks
13
Health Management

• Goal Maintain a healthy system

• Self model of whole system
• Must be machine processable
• Express system-wide non-functional properties
• Reflection mechanism in Robocop Architecture
• update self-model?
• Self-model of services
• Integrity-tests
• Certificate
• could be Robocop models

Self External
Prevention
Monitoring
Diagnosis
Curing
Who
Tasks
14
Health Management External

• Goal Maintain a healthy system

• Protocols APIs for remote monitoring,
  diagnosis curing
• communicate about self-model with external
  parties
• Visualization techniques
• Certification

Self External
Prevention
Monitoring
Diagnosis
Curing
Who
Tasks
15
Self Prevention

• Eat healthy
• Only bind your required Interface to certified
  service.
• Check before you eat
• Check third party results before you are going to
  use them.
• Coding styles

16
External Prevention

• Maintain a healthy configuration of services
• Keep configuration compliant with self model
• Only use certified services in your system
• Protect services from bad input

17
Self Monitoring

• Application or service will recognize when its
  ill.
• Coding styles
• Asserts
• Exceptions
• Dedicated task of a service
• Continuously check of simple conditions
  (Checklist)
• Self model of an application

18
External Monitoring

• Third party will investigate health of an
  application.
• Checking vital signs
• Heart beat interface for services
• Checking responses
• Test scenario with correct responses

19
Self Diagnostics

• Application or service will diagnose itself when
  its ill.
• Checklist
• - simple check list a service can use to do
  simple diagnosis.
• Example
• Condition Cause
• Attr X NULL Init Failed

20
External Diagnostics

• Third party will diagnose an application.
• Checking vital signs
• Vitals interface for services
• Enables more extensive testing
• Checking responses
• Test scenario with wrong responses and possible
  causes.
• Fault propagation model

• Check possible reponses with possible causes

• Relate faults in input to faults in output

21
Self Curing

• Application or service will cure itself.
• Actions depending on diagnose
• Diagnose Action
• Init Failed init()
• Restore default situation (and start over)
• Use default values for attributes
• Corrupted service can replace itself with fresh
  instance.
• Data can be saved
• Switch to safe mode
• Offer less functionality / low quality of service

22
External Curing

• Third party will interfere an application.
• Application Level
• New Image
• Fresh but probably basic system
• Reboot
• Data loss
• Service Level
• External replacement of services
• Trusted party needed
• Instance of same service vs. instance of
  compatible service.

23
People

• Michel Chaudron (Health Management)
• Johan Muskens (Health Management)
• Johan Lukkien Postdoc(Terminal Management)
• Alex Telea Postdoc (SW visualization)
• Peter de With Postdoc (Real Time)

24
Follow the progress

• http//www.win.tue.nl/space4u