1 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 ThreadsDarwin...

1© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003

Threads Darwin HorCom Q & ¬ AKoalaTeddy

Rob van OmmeringPhilips ResearchEindhoven, The Netherlands

November 7th, 2003

Intro

Component Based Architectures

Formalization and Verification

2© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Introduction

Threads Darwin HorCom Q & ¬ AKoalaTeddyIntro

First, a disclaimer:

I’m not a mathematician

I’m not a logician

I’m not even a computer scientist…

I studied physics…

Worse(?), I’m an engineer

Even worse(?), I’m a software architect

So there’s a lot that I don’t know…

3© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Where I work


PhilipsResearch

Laboratories

PhilipsResearch

Laboratories

PhilipsConsumer Electronics

PhilipsConsumer Electronics

PhilipsSemiconductors

PhilipsSemiconductors

PhilipsMedical Systems

PhilipsMedical Systems

UniversitiesUniversities

Research InstitutesResearch Institutes

OtherResearch Laboratories

OtherResearch Laboratories

ProductsPatentsProcessesPeople

Industryas

Laboratory

Where do I work?

Fundamentalknowledge

Appliedknowledge

4© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 My interests


My interests:

small large

Number ofproblems

low

high

Complexityof problem

Not *

But *

I’m an architect

I’m a tool guy

I like pictures…


‘03 ‘18‘05 ‘07 ‘12

My future?

retirement

My History


My historyA.I.

FormalSpecifications

ArchitectureFormalizationVerification

ComponentModel

Architecture

SoftwareProductLines

‘82 ‘88 ‘92 ‘96 ‘98 ‘00

6© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 My Domain


My domain:

20002000

2 MB2 MB

19901990

64 kB64 kB

19791979

1 kB1 kBMoore’s

LawMoore’s Law

19651965

7© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 My Talk


My talk:

ArchitectureFormalization

AndVerification

ArchitectureDescriptionLanguage

andComponentModel

Non-functionalProperties

Coping withEvolution

ComposingControl Software *

8© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Teddy

Teddy Threads Darwin HorCom Q & ¬ AKoalaIntro

Problem Statement

Architecture = 1st (highest) level of design.

Current (read: 1993) programming languages do not offerproper support for defining architecture.

How do I document and communicate an architecture?

How do I verify an implementation against its architecture?

9© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Structure of a Design


// File: ape.c#include “nut.h”...

// File: nut.h...

// File: nut.c#include “mary.h”...

// File: mary.h...

// File: mary.c#include ......

Programming in C:

ape

nut

mary

Abstraction:

10© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Layers


ape

nut

mary

tree

rose

fireB

A

A layered design:

11© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Relation Partition Algebra


tree rose ape nut

A B

u

P

U

usage

Usage

Part-of

U

The architecture

P,u

The implementation

P u P -1

Can observe this

P u P -1 U

Should hold

u P-1 U P

Should hold

u \ P-1 U P

Should be

Our abstraction:

AbstractionFunction

12© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 RPA Tools


Easy to build tool support:

13© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 More Architectural Rules


u \ P-1 ( U I ) P

Some refinements:

u \ P-1 U* P

u* I

u-

Allow self references

Transparent layers

Cycles

Nicer pictures

Et cetera

14© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Recursive Packages


P

P1 P2

P3 P4 P5 P6

C1 C3C2 C4 C5 C7C6 C8

Only allowed if visiblethrough red arrows

ArchitectureWorld

Programmer’sWorld

Design in the large

More information• Software Practice and Experience• Thesis Rene Krikhaar• Computer Languages

More information• Software Practice and Experience• Thesis Rene Krikhaar• Computer Languages

15© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Koala

Koala Threads Darwin HorCom Q & ¬ AIntro Teddy

We’ve seen how to formalize architecture, andverify whether implementations satisfy the architecture.

But this is a reactive process!And it doesn’t help the programmers.

Questions: Can I:

Make architecture explicit in a forward way?

Do this in embedded systems?

Support diversity and evolution?

16© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Provides Interfaces


C C

m

p : I

interface I{ int Max(int x, int y); float Sin(float x);}

component C{ provides I p; contains module m; connects p = m; within m { p.Max(x,y) = x > y ? x : y; // p.Sin implemented in C …}

Provides Interfaces

Has-A rather than Is-A

Ports rather than Inheritancecode-carrying

model

17© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Requires Interfaces


C4C4

C1C1

C2C2

C1C1

C3C3 C

Looks like:

Darwin

Requires Interfaces

Can be bound differently in different products

18© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Connectors


C1C1

C2C2

C1C1

C2C2

C1C1

C2C2 C3C3

SwitchSwitch Glue ModuleGlue ModuleDirectDirect

r

p

r

p1

r

pp2

m

Connectors

19© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Composition


C1C1

C2C2 C3C3

The compositionprocess isrecursive…

The compositionprocess isrecursive…

Component instancesare encapsulated.

Component typesare not (necessarily)(see later).

Component instancesare encapsulated.

Component typesare not (necessarily)(see later).

Client of C2 and C3

Assembler of C1,C2 and C3.

Composition

20© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Diversity


C1C1

C2C2 C3C3

Diversity interfacesare outgoinginterfaces whichparameterize thecomponent.

Diversity interfacesare outgoinginterfaces whichparameterize thecomponent.

Late compile time binding,a.k.a. partial evaluation,is used to create resourceefficient configurations.

Late compile time binding,a.k.a. partial evaluation,is used to create resourceefficient configurations.

Parameterization

21© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 A Real-Life Example


More information• IEEE Computer• My thesis (TBP)

More information• IEEE Computer• My thesis (TBP)

A real-life example

22© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Threads

Threads Darwin HorCom Q & ¬ AIntro KoalaTeddy

So we’re now at Level 1 in the Bengt Jonsson scale .

What about non-functional properties?

What can I do within the current Koala framework?

What can I add to the Koala framework?

23© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Calculating Code Size


Components specify theircode sizeComponents specify theircode size

This can be summed at the product levelThis can be summed at the product level

C1C1C3C3

C1C1

+

Sometimes a very hot issue – now maintained in Excel (transpose matrix)

Code Size

24© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Configuring Resources


Components specify howmany resources they requireComponents specify howmany resources they require

This can be summed and provided tothe component that delivers theresources at the product level

This can be summed and provided tothe component that delivers theresources at the product level

C1C1C3C3

C1C1

+

Resource Usage

25© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Pumps and Pump Engines


C1C1

Step 1: use message pumps created on virtual pump engines required through a diversity interface

Step 1: use message pumps created on virtual pump engines required through a diversity interface

Step 2: bind these to pump engines (a real dispatcher loop)Step 2: bind these to pump engines (a real dispatcher loop)

Problem: many (>100) activities but few (<10) threadsProblem: many (>100) activities but few (<10) threads

C2C2

C3C3

CF

ireB

rigad

eC

Fire

Brig

ade

Same thread,No synchronisation required

Different thread,Synchronisation

required

Multi-threading

26© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Multi-threading attriutes


Threading Analysis

a

a

b

b

b

c

*

*

Specific symbolic thread

Same threadas above

May beanotherthread

Will bea newthread

Threadsafe

27© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Composition Rules


a

a

a

a

a

b

c

d

*

*

*

*

*

a

*

a

a

*

a

*

X

X

X

X

X

O

Composition Rules

28© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Unification


p

a

a

p

p

b

b

p

q

b

c

q

Thread labels

are unified

Prepared for

call on different

threads, but called

on the same thread

q must be

same as p

C is a new thread,

and cannot beequal to q

More information• PACC2

More information• PACC2

Unification

29© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Darwin

Darwin HorCom Q & ¬ AIntro ThreadsKoalaTeddy

Back to Level 1 in the Bengt Jonsson scale .

How can I build a product line?

More specifically:

How can I manage diversity?

How can I manage evolution?

Answer: use sub typing…

30© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Build-A-Bear


What is a product line?

31© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Convergence


‘Unforeseen’ combinations of existing functions new product

GPS + GSM GSM + DigCam PDA + GPS

Convergence

32© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Product Populations


A product population is: - a set of products with many commonalities, - but also with many differences, - developed by different suborganizations, - each with its own time-line / lifecycle.

A product population is: - a set of products with many commonalities, - but also with many differences, - developed by different suborganizations, - each with its own time-line / lifecycle.

SingleProductSingle

ProductProductFamily

ProductFamily

ProductPopulation

ProductPopulation

UnrelatedProductsUnrelatedProducts

DecompositionDedicated components

CompositionCOTS

Product Population

33© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Diversity & Evolution


CTunerCTuner CTuner’CTuner’

CSearchTuner

CSearchTuner

tun: ITuner tun: ITuner tun2: ITuner2

tun: ITuner stun: ISearchTuner

Div

ersi

ty

Evolution

C

Looks like:

Microsoft COM

Variation in Space and in Time

34© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Evolution Rules


CC C’C’

IB+ IBIB+ IB

Provide more...Provide more...

IA IB IA IB+ IC

C’ CC’ C

Koala subtypes interfaces based on set inclusion of

functions

Koala subtypes interfaces based on set inclusion of

functions

CC C’C’

IB- IBIB- IB

Require less…???Require less…???

IA IB-IA IB IC

C’ CC’ C

Koala reports an error if a non-existing interface is

bound…!

Koala reports an error if a non-existing interface is

bound…!

Evolution rules

35© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 More Evolution Rules


More information• WICSA• SPLC 2002

CC C’C’

IA IA

CC C’C’

IA IA

More evolution rules

Optional Interfaces

CC C’C’

a *

CC C’C’

* a

Thread attributes

36© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 HorCom

HorCom Q & ¬ AIntro Threads DarwinKoalaTeddy

We’ve seen mechanisms but no examples yet.

Control software is difficult to compose.

Question:

How can I create composable control software?

Answer: use a distributed algorithm

37© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 What’s in a TV?


TVTV

TubeTube

ElectronicsElectronics

SmallSignalPanel

SmallSignalPanel

38© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 A Control Problem


Tune(f)Tune(f)

1. BlankOutput1. BlankOutput2. SetFrequency2. SetFrequency

3. UnblankOutput3. UnblankOutput

TunerHardware

TunerHardware

OutputHardware

OutputHardwareantennaantenna tubetube

ControlSoftwareControl

Software

TunerDriverTunerDriver

OutputDriverOutputDriver

39© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 A more difficult problem


OutputHardware

OutputHardware

TunerHardware

TunerHardware

TunerHardware

TunerHardware

OutputHardware

OutputHardwareSwitchSwitchantennaantenna tubetube

ControlSoftwareControl

Software





SwitchDriverSwitchDriver

2. BlankOutput2. BlankOutput

3. SetFrequency3. SetFrequency

4. UnblankOutput4. UnblankOutput

Tune(t,f)Tune(t,f)

1. Which Output?1. Which Output?

40© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Composing Control


ProductSpecificCode

ProductSpecificCode

ReusableCodeReusableCode

… unless ...… unless ...

Control software is difficult to compose…

41© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Horizontal Communication


1. SetFrequency(f)1. SetFrequency(f)

2. DropRequest2. DropRequest

3. Restore3. Restore

TunerHardware

TunerHardware

OutputHardware

OutputHardware

antennaantenna tubetube



42© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Using LTSA


HORCOM = ( dr -> ( dr.t -> re -> re.r -> HORCOM | dr.f -> da -> ( re -> re.r -> da.r -> HORCOM | da.r -> re -> re.r -> HORCOM ) ) ).

We have modeled this with LTSA.

More information• SP&E 2003

Haven’t completed this yet…

Jeff Magee


Summary

• Architecture can (partially) be formalized and verified.

• Koala as ADL and component model

• Non functional properties in Koala

• Managing diversity and evolution with sub typing

• Decomposing control by distribution

Q & ¬ A

Q & ¬ AIntro Threads Darwin HorComKoalaTeddy

44© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Nomenclature


COLD

ICE

Winter

BEARPOLARPANDA

Teddy Koala Ursa

Darwin

Kangaroo

FormalSpecification

Nomenclature

45© 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Questions and Answers(?)


Q & ( ¬ ) A ?

Date post:	01-Apr-2015
Category:	Documents
Upload:	leslie-cubberley
View:	215 times
Download:	0 times

1 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 ThreadsDarwin...

Documents