Component-based approach for embedded systems

1. Component-based approach for embedded systems Ivica Crnkovic Mälardalen University (MdH) Department of Computer Science and Electronics, Mälardalen Real-time Research Centre (MRTC) Sweden http://www.idt.mdh.se/~icc

2. Mälardalen University (MdH) Mälardalen University, Vasteras (Västerås) Prof. in Software Engineering http://www.idt.mdh.se/~icc ivica.crnkovic@mdh.se • Department of Computer Engineering • Real-Time Systems Design Lab • Computer Architecture Lab • Computer Science Lab • Software Engineering Lab

3. Outline • Basic characteristics of Component-based Software Engineering • Component-based approach in different domains – benefits and challenges • Embedded systems – some examples • CBSE for different types of embedded systems – concerns

4. Sources of information http://www-artist.imag.fr/Overview/ http://www.cbsenet.org/pls/CBSEnet/ecolnet.home SAVE http://www.mrtc.mdh.se/SAVE/ Ivica Crnkovic and Magnus Larsson: Building Reliable Component-Based Software Systems Artech House Publishers, 2002, ISBN 1-58053-327-2 http://www.idt.mdh.se/cbse-book/

5. Component-based approach • Building systems from (existing) components • Providing support for the development of systems as assemblies of components • Supporting the development of components as reusable units • Facilitating the maintenance and evolution of systems by customizing and replacing their components • Component-based Software Engineering • Provides methods and tools supporting different aspects of component-based approach • Process issues, organizational and management issues, technologies (for example component models), theories (component compositions), tools…

6. Why component-based approach? • Advantages from the business point of view: • Shorter time-to-market, lower development and maintenance costs • Advantages from technical and engineering point of view • Increased understability of (complex) systems • Increased the reusability, interoperability, flexibility, adaptability, dependability… • Advantages from strategic point of view of a society • Increasing software market, generation of new companies • CB-approach has been successful in many application domains: • Web- and internet-based applications • Desktop and office applications, Graphical tools, GUI-based applications • In certain segments of telecommunication, consumer electronics…

7. c c 1 2 Middleware framework Run-time system Component Model CBSE – basic definitions • The basis is the Component • Components can be assembled according to the rules specified by the component model • Components are assembled through their interfaces • A Component Composition is the process of assembling components to form an assembly, a larger component or an application • Component are performing in the context of a component framework • A component technology is a concrete implementation of a component model

8. Component Technology Supporting Tool Components Platform Component Framework Repository

9. Implications of the CBSE approach • Component development is separated from system development process • Less programming efforts to build systems • System verification and validation more difficult and more important • Different requirements management • A combination of a bottom-up and top-down approach • Many explicit and implicit assumptions • Architectural styles (middleware, deployment,..)

10. Software Component Definition Szyperski (Component Software beyond OO programming) • A software component is • a unit of composition • with contractually specified interfaces • and explicit context dependencies only. • A software component • can be deployed independently • it is subject to composition by third party.

11. Another definition • A software component is a software element that • confirms a component model • can be independently deployed • composed without modification according to a composition standard. • A component model defines specific interaction and composition standards. G. Heineman, W. Councel, Component-based software engineering, putting the peaces together, Addoson Wesley, 2001

12. Implications of Szyperski’s Definition • The following implications arise as a result of Szyperski’s definition: • For a component to be deployed independently, a clear distinction from its environment and other components is required. • A component must have clearly specified interfaces. • The implementation must be encapsulated in the component and is not directly reachable from the environment. (Black box nature)

13. white box white box glass box glass box grey box gray box black box black box Component specification • Components are described by their interfaces • (A black box character)

14. Components and Interfaces - UML definition Component – a set of interfaces required (in-interfaces) provided (out-interfaces) Interface – set of operations Operations – input and output parameters of certain type

15. IDL Example interface ISpellCheck : IUnknown { HRESULT check([in] BSTR *word, [out] bool *correct); }; interface ICustomSpellCheck : IUnknown { HRESULT add([in] BSTR *word); HRESULT remove([in] BSTR *word); }; library SpellCheckerLib { coclass SpellChecker { [default] interface ISpellCheck; interface ICustomSpellCheck; }; };

16. Contractually specified interfaces • Extension of Interface (adding contract) • a set of interfaces that each consists of a set of operations. • a set of preconditions and postconditions is associated with each operation. • A set of invariants • Also called: Contractually specified interfaces

17. Precondition, Postconditions, Invariants • Precondition • an assertion that the component assumes to be fulfilled before an operation is invoked. • Will in general be a predicate over the operation’s input parameters and this state • Postcondition • An assertion that the component guarantees will hold just after an operation has been invoked, provided the operation’s pre-conditions were true when it was invoked. • Is a predicate over both input and output parameters as well as the state just before the invocation and just after • Invariant • Is a predicate over the interface’s state model that will always hold

18. Semantic Specification in a UML metamodel

19. Extrafunctional properties • Extrafunctional (non-functional) properties • runt-time properties • Performance, latency • Dependability (Reliability, robustness, safety) • Lifecycle properties • Maintainability, usability, portability, testability,…. • There is no standards for specification of extrafunctional properties

20. Extrafunctional properties specifications Credentials (Mary Shaw) • A Credential is a triple <Attribute, Value, Credibility> • Attribute: is a description of a property of a component • Value: is a measure of that property • Credibility: is a description of how the measure has been obtained • Attributes in .NET • A component developer can associate attribute values with a component and define new attributes by sub-classing an existing attribute class. • ADL UniCon • allows association of <Attribute, Value> to components

21. Extra-functional Properties

22. Main principles of CBSE: (1) Reusability • Reusing components in different systems • The desire to reuse a component poses few technical constraints. • Good documentation (component specification…) • a well-organized reuse process • Similar architecture • …. C1 C1 C2 C1 C5 C3 C4 C6 C7 Application A1 Application A2

23. Main principles: (2) Substitutability • Alternative implementations of a component may be used. • The system should meet its requirements irrespective of which component is used. • Substitution principles • Function level • Non-functional level • Added technical challenges • Design-time: precise definition of interfaces & specification • Run-time: replacement mechanism C1 C2 C3 C4 Application A1 C1´ C2 C3 C4 Application A1

24. Substitution • Substituting a component Y for a component X is said to be safe if: • All systems that work with X will also work with Y • From a syntactic viewpoint, a component can safely be replaced if: • The new component implements at least the same interfaces as the older components • From semantic point of view? • Contractual interface holds (pre-, postconditions and invariants)

25. Comes in two flavors: extending components that are part of a system Increase the functionality of individual components Added technical challenges: Design-time: extensible architecture Run-time: mechanism for discovering new functionality Main principles: (3) Extensibility C1 C2 C3 C1 C2+ C3 C1 C2 C3 C1 C2 C4 C3

26. Composition of components P(c1 o c2) =P1(c1) o P2(c2) Composition of functions Composition of extra-functional properties Many challenges How to reason about a system composed from components? Different type of properties Different principles of compositions Main principles: (4) Composability C C1 C2 assembly

27. Components for Embedded Systems

28. Do existing component technologies meet the requirements of different domains? • Widely-used component models (Microsoft COM/DCOM and .NET, Sun EJB, OMG CCB,…) • Focus on functionality, flexibility, run-time adaptability, simpler development and maintenance • Do not consider a number of extra-functional requirements • Timing properties (performance), resource consumptions • Reliability, availability, quality of services… Important questions for CBSE feasibility: • Which are the primary requirements in different domains? • Can CBSE provide solutions that meet these requirements?

29. 99,8% of computer systems are embedded systems (DARPA 2000) What are embedded systems? An Embedded Computer System: A computer system that is part of a larger system and performs some of the requirements of that system. (IEEE, 1992).

30. A sensor transforms physical data (temperature, pressure) to digital format Examples: thermometer, microphone, video camera An actuator works the other way round - transforming digital data to physical format. Example: motors, pumps, machines… Characteristics of ES: Interaction with the environment An embedded system interacts with the environment via sensors and actuators RT software system Sensor Process Actuator

31. Collision Too late Too early time ES – Real-time systems RT Systems : Correct result at the right time Example: An air bag must not be inflated too late, not too early! In some cases the system must wait before it responds!

32. Real-time in Football - Offside rules

33. Too late

34. Too eraly

35. ready ready Challenges when constructing RT ES Most of the real-time systems are based on following: • Several parallel activities are given some unique priorities • A resource manager makes sure the task with the highest priority will execute Activities 1 Resource manager 3 2 1 3 CPU time • Processing requires resources (time, CPU-time, memory,..)

36. Enough resources vs. Limited resources Enough resources • You can always guarantee that all functions in the system are able to execute when they so desire. • Most often safety critical applications • Expensive • Example: ABS-system, ”fly-by-wire”-system, power plant… Limited resources • There may be occasions when the system is unable to handle all functions that wants to execute. • Designed to work well under normal conditions. • Example: telephone – everybody wants to make a phone call simultaneously will result in that some has to wait.

37. Event driven vs. time driven systems Event driven real-time systems • External events determines when a program is to be executed • Often through interrupts • Example: telephone switches, ”video-on-demand”, transaction systems… Time driven real-time systems • The system handles external events at predefined points in time • Most often cyclic systems  repeats a certain scenario • Example: ABS, control systems, manufacturing systems…

38. Hard vs. Soft real-time systems Hard real-time systems • The cost for not fulfilling the functional and temporal constraints are severe • Failing to meet hard real-time constraints results in computations, at best, being useless • Often safety critical  the correctness must be verified before system operation • Example: ABS, airbag, defence system, power plant… Soft real-time systems • Occasional miss of fulfilling a timing constraint can be acceptable • The usefulness of the computation is reduced (reduced service) Example: reservation systems, ATM machines, multimedia, virtual reality…

39. New requirements (RT requirements) introduce new challenges in achieving the CBSE principles • Example: • Substitution principle for RT components.

40. Substitution principles • When we can replace a component? • Goal: on-line upgrade task components in a ‘safe’ way • Two issues: • new components must not be faulty • schedulability of all tasks (components) must be guaranteed • Run-time upgrade possible if worst case execution time • WCET (new comp) ≤ WCET (old comp) • Is that correct?

41. task priority A high B medium C low rel(B) rel(A,C) dl(B) dl(A,C) A’ (b) Order of execution changed – deadline met Example 1: preemptive Fast priority scheduling rel(B) rel(A,C) dl(B) dl(A,C) Rel = release time dl = deadline A B C (a) A is replaced by A’; wcet(A’)<wcet(A) C B C

42. task priority A high B medium C low B misses deadline! rel(B) rel(A,C) dll(B) A’ (b) Example 2: non-preemptive FPS rel(B) rel(A,C) dl(B) dl(A,C) A B C (a) A is replaced by A’; wcet(A’)<wcet(A) dl(A,C) C B

43. Actuator Actuator Actuator Sensor Sensor Sensor Sensor Sensor Sensor ECU ECU ECU Example of an embedded system: The architecture of a car control system Infotaiment gateway (CAN) BUS brake injection Vehicle mechanics ECU – Electronic Control Unit

44. Actuator Actuator Sensor Sensor Sensor Sensor Local Control Functions Local Control Functions The architectural design challenge Vehicle stability Suspension Drive by wire …… Complex functions Basic functions How to implement complex functions based on local control functions?

45. Actuator … Actuator … Actuator 2 Actuator 3 Actuator 1 Sensor .. Sensor .. Sensor 3 Sensor 2 Sensor 1 Node … Node … Node 1 Node 2 Node 3 Problem: resource sharing Network resources Execution resources ++++++++++ ++++++++++ ++++++++++ Can functions of different criticality be allowed to share resources?

46. ECU ECU ECU SOFTWARE COMPONENTS Challenge – open and dependable platform Collision detection Antispin Global (complex) functions Cruise control Vehicle stability local Engine Control Local brake Control Transmission ……… sensors actuators Vehicle Applications Middleware Input/output drivers Hardware

47. C1 C2 Challenge – open and dependable platform Applications Middleware Input/output drivers Hardware ECU ECU ECU Requirements Separation of hw from SW development Separation of SW component development

48. Specific requirements of embedded systems • Real-time requirements • Resource consumption • CPU, Memory, Power, Physical space • Dependability • Safety, reliability, availability • Life-cycle properties (long life systems) • Maintainability, expandability • Portability • Increasing interoperability

49. Basic concepts for Component-based Embedded Systems • Main concern • Predictability of different properties (on account of flexibility) • Difference between small and large embedded systems

50. Run-time composition Component lifecycle, Run-time environment, Dynamic composition (late binding) Configuration composition Capable of generating monolithic firmware from component-based design, Optimization Re-configuration of the components Direct references Unit of composition and independent deployment Component technology More feasible for embedded systems