1 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 ThreadsDarwin HorCom Q & ¬ AKoalaTeddy Rob van Ommering Philips Research Eindhoven, The Netherlands November 7 th, 2003 Intro Component Based Architectures Formalization and Verification

2 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Introduction ThreadsDarwin 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 ThreadsDarwin HorCom Q & ¬ AKoalaTeddyIntro Philips Research Laboratories Philips Research Laboratories Philips Consumer Electronics Philips Consumer Electronics Philips Semiconductors Philips Semiconductors Philips Medical Systems Philips Medical Systems Universities Research Institutes Other Research Laboratories Other Research Laboratories Products Patents Processes People Industry as Laboratory Where do I work? Fundamental knowledge Applied knowledge

4 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 My interests ThreadsDarwin HorCom Q & ¬ AKoalaTeddyIntro My interests: smalllarge Number of problems low high Complexity of problem Not * But * I’m an architect I’m a tool guy I like pictures…

5 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 ‘03‘18‘05‘07‘12 My future? retirement My History ThreadsDarwin HorCom Q & ¬ AKoalaTeddyIntro My history A.I. Formal Specifications Architecture Formalization Verification Component Model Architecture Software Product Lines ‘82‘88‘92‘96‘98‘00

6 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 My Domain ThreadsDarwin HorCom Q & ¬ AKoalaTeddyIntro My domain: MB kB kB Moore’s Law 1965

7 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 My Talk ThreadsDarwin HorCom Q & ¬ AKoalaTeddyIntro My talk: Architecture Formalization And Verification Architecture Description Language and Component Model Non-functional Properties Coping with Evolution Composing Control Software *

8 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Teddy ThreadsDarwin HorCom Q & ¬ AKoalaIntro Problem Statement Architecture = 1 st (highest) level of design. Current (read: 1993) programming languages do not offer proper 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 TeddyThreadsDarwin HorCom Q & ¬ AKoalaIntro // 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 TeddyThreadsDarwin HorCom Q & ¬ AKoalaIntro ape nut mary tree rose fire B A A layered design:

11 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Relation Partition Algebra TeddyThreadsDarwin HorCom Q & ¬ AKoalaIntro treeroseapenut AB 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: Abstraction Function

12 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 RPA Tools TeddyThreadsDarwin HorCom Q & ¬ AKoalaIntro Easy to build tool support:

13 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 More Architectural Rules TeddyThreadsDarwin HorCom Q & ¬ AKoalaIntro u \ P -1  ( U  I )  P Some refinements: u \ P -1  U*  P u*  I u-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 TeddyThreadsDarwin HorCom Q & ¬ AKoalaIntro P P1P1 P2P2 P3P3 P4P4 P5P5 P6P6 C1C1 C3C3 C2C2 C4C4 C5C5 C7C7 C6C6 C8C8 Only allowed if visible through red arrows Architecture World Programmer’s World 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 ThreadsDarwin HorCom Q & ¬ AIntroTeddy We’ve seen how to formalize architecture, and verify 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 KoalaThreadsDarwin HorCom Q & ¬ AIntroTeddy 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 Inheritance code-carrying model

17 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Requires Interfaces KoalaThreadsDarwin HorCom Q & ¬ AIntroTeddy C4 C1 C2 C1 C3 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 KoalaThreadsDarwin HorCom Q & ¬ AIntroTeddy C1 C2 C1 C2 C1 C2 C3 Switch Glue Module Direct r p r p1p1 r p p2p2 m Connectors

19 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Composition KoalaThreadsDarwin HorCom Q & ¬ AIntroTeddy C1 C2 C3 The composition process is recursive… Component instances are encapsulated. Component types are not (necessarily) (see later). Component instances are encapsulated. Component types are 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 KoalaThreadsDarwin HorCom Q & ¬ AIntroTeddy C1 C2 C3 Diversity interfaces are outgoing interfaces which parameterize the component. Late compile time binding, a.k.a. partial evaluation, is used to create resource efficient configurations. Parameterization

21 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 A Real-Life Example KoalaThreadsDarwin HorCom Q & ¬ AIntroTeddy 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 Darwin HorCom Q & ¬ AIntroKoalaTeddy 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 ThreadsDarwin HorCom Q & ¬ AIntroKoalaTeddy Components specify their code size This can be summed at the product level C1 C3 C1 + 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 ThreadsDarwin HorCom Q & ¬ AIntroKoalaTeddy Components specify how many resources they require This can be summed and provided to the component that delivers the resources at the product level C1 C3 C1 + Resource Usage

25 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Pumps and Pump Engines ThreadsDarwin HorCom Q & ¬ AIntroKoalaTeddy C1 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) Problem: many (>100) activities but few (<10) threads C2 C3 CFireBrigade 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 ThreadsDarwin HorCom Q & ¬ AIntroKoalaTeddy Threading Analysis a a b b b c * * Specific symbolic thread Same thread as above May be another thread Will be a new thread Thread safe

27 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Composition Rules ThreadsDarwin HorCom Q & ¬ AIntroKoalaTeddy 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 ThreadsDarwin HorCom Q & ¬ AIntroKoalaTeddy 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 be equal to q More information PACC2 More information PACC2 Unification

29 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Darwin HorCom Q & ¬ AIntroThreadsKoalaTeddy 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 Darwin HorCom Q & ¬ AIntroThreadsKoalaTeddy What is a product line?

31 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Convergence Darwin HorCom Q & ¬ AIntroThreadsKoalaTeddy ‘Unforeseen’ combinations of existing functions  new product GPS + GSMGSM + DigCamPDA + GPS Convergence

32 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Product Populations Darwin HorCom Q & ¬ AIntroThreadsKoalaTeddy 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. Single Product Product Family Product Population Unrelated Products Decomposition Dedicated components Composition COTS Product Population

33 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Diversity & Evolution Darwin HorCom Q & ¬ AIntroThreadsKoalaTeddy CTuner CTuner’ CSearch Tuner tun: ITuner tun2: ITuner2 tun: ITunerstun: ISearchTuner Diversity 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 Darwin HorCom Q & ¬ AIntroThreadsKoalaTeddy C C C’ IB +  IB Provide more... IAIBIAIB + IC C’  C Koala subtypes interfaces based on set inclusion of functions C C C’ IB -  IB Require less…??? IAIB - IAIBIC C’  C 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 Darwin HorCom Q & ¬ AIntroThreadsKoalaTeddy More information WICSA SPLC 2002 C C C’ IA C C C’ IA More evolution rules Optional Interfaces C C C’ a* C C *a Thread attributes

36 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 HorCom Q & ¬ AIntroThreadsDarwinKoalaTeddy 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? HorCom Q & ¬ AIntroThreadsDarwinKoalaTeddy TV Tube Electronics Small Signal Panel Small Signal Panel

38 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 A Control Problem HorCom Q & ¬ AIntroThreadsDarwinKoalaTeddy Tune(f) 1. BlankOutput 2. SetFrequency 3. UnblankOutput Tuner Hardware Output Hardware antenna tube Control Software Tuner Driver Output Driver

39 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 A more difficult problem HorCom Q & ¬ AIntroThreadsDarwinKoalaTeddy Output Hardware Tuner Hardware Output Hardware Switch antenna tube Control Software Output Driver Tuner Driver Output Driver Switch Driver 2. BlankOutput 3. SetFrequency 4. UnblankOutput Tune(t,f) 1. Which Output?

40 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Composing Control HorCom Q & ¬ AIntroThreadsDarwinKoalaTeddy Product Specific Code Reusable Code … unless... Control software is difficult to compose…

41 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Horizontal Communication HorCom Q & ¬ AIntroThreadsDarwinKoalaTeddy 1. SetFrequency(f) 2. DropRequest 3. Restore Tuner Hardware Output Hardware antenna tube Output Driver Tuner Driver

42 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Using LTSA HorCom Q & ¬ AIntroThreadsDarwinKoalaTeddy 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

43 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 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 & ¬ AIntroThreadsDarwin HorCom KoalaTeddy

44 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Nomenclature Q & ¬ AIntroThreadsDarwin HorCom KoalaTeddy COLD ICE Winter BEAR POLAR PANDA TeddyKoalaUrsa Darwin Kangaroo Formal Specification Nomenclature

45 © 2003 Philips Electronics BV, Rob van Ommering, FMCO 2003, November 7 th, 2003 Questions and Answers(?) Q & ¬ AIntroThreadsDarwin HorCom KoalaTeddy Q & ( ¬ ) A ?