1. 1 2015-06-23 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. 2 2015-06-23 Mälardalen University (MdH) Mälardalen University, Vasteras (Västerås) Department of Computer Engineering Real-Time Systems Design Lab Computer Architecture Lab Computer Science Lab Software Engineering Lab Prof. in Software Engineering http://www.idt.mdh.se/~icc ivica.crnkovic@mdh.se

3. 3 2015-06-23 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. 4 2015-06-23 Sources of information SAVE http://www.cbsenet.org/pls/CBSEnet/ecolnet.home http://www-artist.imag.fr/Overview/ 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. 5 2015-06-23 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. 6 2015-06-23 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. 7 2015-06-23 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 c 1 c 2 Middleware Run-time system framework Component Model

8. 8 2015-06-23 Component Technology Component Component Framework Platform Components Repository Supporting Tool

9. 9 2015-06-23 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. 10 2015-06-23 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. 11 2015-06-23 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. 12 2015-06-23 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. 13 2015-06-23 Component specification Components are described by their interfaces (A black box character) glass box black box white box grey boxgray box

14. 14 2015-06-23 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. 15 2015-06-23 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. 16 2015-06-23 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. 17 2015-06-23 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. 18 2015-06-23 Semantic Specification in a UML metamodel

19. 19 2015-06-23 Semantic Interface Specification context ISpellCheck::check(in word : String, out correct : Boolean): HRESULT pre: word <> “” post: SUCCEEDED(result) implies correct = words->includes(word) context ICustomSpellCheck::add(in word : String) : HRESULT pre: word <> “” post: SUCCEEDED(result) implies words = words@pre->including (word) context ICustomSpellCheck::remove(in word : String) : HRESULT pre: word <> “” post: SUCCEEDED(result) implies words = words@pre->exluding(word)

20. 20 2015-06-23 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

21. 21 2015-06-23 Extrafunctional properties specifications Credentials (Mary Shaw) A Credential is a triple –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 to components

22. 22 2015-06-23 Extra-functional Properties

23. 23 2015-06-23 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 C2 C3C4 Application A1 C1C5 C6C7 Application A2

24. 24 2015-06-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 C1C2 C3C4 Application A1 C1´C2 C3C4 Application A1

25. 25 2015-06-23 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)

26. 26 2015-06-23 Main principles: (3) Extensibility 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 C1C2C3 C1C2+C3 C1C2C3 C1C2C4C3

27. 27 2015-06-23 Main principles: (4) Composability 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 C1C2 assembly C

28. 28 2015-06-23 Components for Embedded Systems

29. 29 2015-06-23 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?

30. 30 2015-06-23 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). 99,8% of computer systems are embedded systems (DARPA 2000)

31. 31 2015-06-23 Characteristics of ES: Interaction with the environment 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… An embedded system interacts with the environment via sensors and actuators RT software system Sensor Actuator Process

32. 32 2015-06-23 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! Collision Too late time Too early ES – Real-time systems

33. 33 2015-06-23 Real-time in Football - Offside rules

34. 34 2015-06-23 Too late

35. 35 2015-06-23 Too eraly

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

37. 37 2015-06-23 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. Enough resources vs. Limited resources

38. 38 2015-06-23 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… Event driven vs. time driven systems

39. 39 2015-06-23 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… Hard vs. Soft real-time systems

40. 40 2015-06-23 New requirements (RT requirements) introduce new challenges in achieving the CBSE principles Example: –Substitution principle for RT components.

41. 41 2015-06-23 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?

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

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

44. 44 2015-06-23 Example of an embedded system: The architecture of a car control system Vehicle mechanics ECU Sensor ActuatorSensor ECU Sensor ActuatorSensor ECU Sensor Actuator Sensor gateway (CAN) BUS brakeinjection Infotaiment ECU – Electronic Control Unit

45. 45 2015-06-23 The architectural design challenge Vehicle stabilitySuspensionDrive by wire…… Complex functions Local Control Functions Sensor ActuatorSensor Basic functions Local Control Functions Sensor ActuatorSensor How to implement complex functions based on local control functions?

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

47. 47 2015-06-23 sensors Challenge – open and dependable platform Vehicle actuators Engine ControlLocal brake ControlTransmission……… local Vehicle stability Cruise control Antispin Global (complex) functions Hardware Input/output drivers Middleware ECU Applications SOFTWARE COMPONENTS Collision detection

48. 48 2015-06-23 Challenge – open and dependable platform Hardware Input/output drivers Middleware ECU Applications C1C2 Requirements Separation of hw from SW development Separation of SW component development

49. 49 2015-06-23 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

50. 50 2015-06-23 Basic concepts for Component-based Embedded Systems Main concern –Predictability of different properties (on account of flexibility) Difference between small and large embedded systems

51. 51 2015-06-23 Unit of composition and independent deployment 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 More feasible for embedded systems Component technology

52. 52 2015-06-23 Explicit context dependencies Other components and interfaces –required & provided interfaces –(Contractual-based interfaces) Run-time environment –CPU, –RTOS, –Resource constraints –Component implementation language Embedded systems specific Component technology

53. 53 2015-06-23 Component granularity Coarse-grained components –“Bags” with many (partially unused) functions –Not resource-usage aware –Often distributed components Fine-grained components –unneeded functionality removed, –Scarcer uses of resources More feasible for embedded systems Component technology

54. 54 2015-06-23 Framework Component Repository Composition environment Run-time environment

55. 55 2015-06-23 The day after tomorrow… –Requirements on flexible upgrading Part of a system Updating software components Separation of software from hardware Binary standards will become important

56. 56 2015-06-23 In most cases the general-purpose component models will not be appropriate for embedded systems However other component-based approach is appealing !

57. 57 2015-06-23 Component-based approach for LARGE embedded systems the resource constraints are not the primary concerns. The complexity and interoperability important Minimizing the development costs For this reason general-purpose component technologies are of more interest than in a case for small systems.

58. 58 2015-06-23 Widely-used component models and embedded systems Direct use of component models –CORBA (telecommunication) –COM/DCOM,.NET – process industry Improved component-models (with added functionalities) –OPC (OLE process control Foundation) Restricted (use of) component-models to achieve predictability –Using only specification (IDL), no multiple interface, etc.

59. 59 2015-06-23 OPC (OLE for Process Control) industry standard for communication between components in field devices, automation equipment and business applications (generic driver) data model set of interfaces for COM –server interfaces –callback interfaces managed by OPC Foundation (www.opcfoundation.org)

60. 60 2015-06-23 OPC: Why is OPC needed? Software Driver Software Driver Software Driver Software Driver Display Application Trend Application Report Application

61. 61 2015-06-23 OPC: How does OPC Solve the Problem? Software Driver Software Driver Software Driver Software Driver OPC Display Application Trend Application Report Application OPC

62. 62 2015-06-23 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 must be guaranteed Existing approach – Sha 1998 –basic idea: monitor output to ensure values within valid range Run-time upgrade possible if WCET (new comp) ≤ WCET (old comp) –Is that correct?

63. 63 2015-06-23 ABC rel(A,C) rel(B) dl(B)dl(A,C) (a) BCC A is replaced by A’; wcet(A’)<wcet(A) Order of execution changed – deadline met A’ rel(A,C) rel(B) dl(B)dl(A,C) (b) Example 1: preemptive FPS task priority A high B medium C low

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

65. 65 2015-06-23 On-line upgrading of real-time components in priority-based RTS Solution? –preemptive FPS eliminate/predict preemptions at design stage –non-preemptive FPS work on the WCET predict exact execution time? Another solution –Off-line scheduling –Missing possibility of on-line upgrading of a component

66. 66 2015-06-23 From component model to RT execution model Task Allocation Win32 APPLICATION components -composition presentation Design- Time Compile- Time Run- Time <<SaveComp>> PC <<SaveComp>> Compose <<Assembly>> P Set Actual Control Attribute Assignment Glue CodeGeneration &Analysis C-compiler RTXC APPLICATION SimulationTarget

67. 67 2015-06-23 From component model to RT execution model Design- Time Component model Real-Time Analysis Real-time model Synthesis Compile- Time Model transformation Run- Time Target application RTOS t Task Allocation Attribute Assignment Analysis Glue Code Generation Target Compiler Component model RTOS Fully Automated Compile-Time Step Component code loading

68. 68 2015-06-23 Allocating components to real-time tasks Today one-to-one allocation is commonly used –Not efficient in terms of cpu-overhead and stack usage –However, highly analyzable How can the mapping between components and tasks be analyzable and efficient? Infeasible to calculate due to the many different possible mappings in a large system Limitations –Only pipe-and-filter architectures –No advanced real-time constraints

69. 69 2015-06-23 Mapping system usage profile to component usage profile When the known (measured) properties values can be reused? Reuse problem

70. 70 2015-06-23 Some examples of component models

71. 71 2015-06-23 The Koala Component Model – Philips CE C C2C2 C1C1 C3C3 Koala is: - a Software Component Model - with an ADL - to build populations of resource constrained products

72. 72 2015-06-23 Property key value PropertyBundle name Port type Direction range Connector type Component name scheduling memory Sub- components Event component Active component passive component event info thread info Pecos component model (ABB)

73. 73 2015-06-23 SaveComp Model - MdH

74. 74 2015-06-23 Conclusion & Summary There is a visible trend in acquiring CB approach in development of embedded systems New component technologoes and utilization of the existing theories important.