1. Page 1, CBSE graduate course Lecture 3 CBSE in Embedded System Development

2. Agenda  Embedded and Real-Time Systems  ProCom  Extra-Functional Properties  PRIDE  Lab2 Page 2, CBSE graduate course

3. What are Embedded Systems ? 3 “special purpose computer built into a larger device to perform a specific functionality by combination of hardware and software”

4. October 24, 2015 Component-based real-time systems 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 RTsoftwaresystem Sensor Actuator Environment

5. Does someone know an example of an embedded system that you can find in a car? Page 5, CBSE graduate course

6. An airbag Page 6, CBSE graduate course

7. Example: An air bag must not be inflated too late, nor too early! Collision Too late time Too early Correct results at the right time

8. What is a real-time system? “ A real-time system is a system that reacts upon outside events and performs a function based on these and and gives a response within a certain time. Correctness of the function does not only depend on correctness of the result, but also the timeliness of it”.

9. October 24, 2015 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

10. Predictable vs. fast A robot arm with good timing catches the passing boll.

11. October 24, 2015 Ivica Crnkovic (c) : Component-based real-time systems Too fast robot arm misses the passing boll! Predictable vs. fast

12. What do you need to think about when developing ES? 12

13. Heterogeneous Development Concerns  Predictable react in well-specified ways and be highly dependable  Real-time demands react correctly to events in a given interval in time  Resource limitations memory bandwidth power … 13

14. Current Trend Today, the software part increases Additional functionality HW functionality replaced by SW functionality “special purpose computer built into a larger device to perform a specific functionality by combination of hardware and software” 14

15. Problems in current development methods  Traditional development method does not scale anymore (1 functionality/subsystem on 1 ECU) Software complexity Distribution Shared resources  Need solutions to: Manage software complexity Improve reusability Address some fundamental development concerns:  Timing demands  Resource limitations  Predictability 15

16. CBSE – The future of ES development?

17. 17

18. General Requirements  Cover the whole development process From early design up to deployment and synthesis  Centered around a unified notion of components Collection of requirements, documentation, source code, analysis models, test results, etc.  Enable the integration of various analysis techniques Manage and store the required/produced artefacts in a systematic way 18

19. Coexistence of Different Abstraction Levels  Example of development process 19 RequirementsSpecification Component repository Reuse of an already existing solution Fully implemented Component (architecture model +source code +analysis model) Partially implemented component Sketch of component Component-Based Design Deployment

20. Different Concerns at Different Granularity Levels 2010-03-08 Pau 20

21. Resource limitations Resource limitations Real-time demands Real-time demands Predictability Predictability Distribution Distribution ES specific requirements Managing complexity Managing complexity Different abstraction levels Different abstraction levels Different concerns at different levels Different concerns at different levels Integration of various analysis techniques Integration of various analysis techniques Component-based approach requirements Response-time Response-time CPU CPU Memory Usage Memory Usage Reliability Reliability Accuracy Accuracy Extra-Functional Properties 2010-03-0821 Pau Specifies component semantics Specifies component semantics Composition rules Composition rules Component Model

22. 22

23. ProCom – Key aspects (1)  Rich design-time concepts A collection of development artefacts  (source code, models of timing and resources, analysis results, documentation, etc.) Reuse all this information. Components of different maturity should be allowed to co-exist. 23

24. ProCom – Key aspects(2)  Components abstracted from physical deployment  Different concerns depending on granularity: Distribution, communication, analysis, etc. 24 Architectural model (CBD) Platform model mapping

25. ProCom  a Two-Layered Component Model 2010-03-08 25 System C1C1C2C2C3C3 Subsystem components Subsystem components Active, distributed Active, distributed Asynchronous message passing Asynchronous message passing Hierarchical Hierarchical ProSys (upper layer) "Function block" components "Function block" components Passive, non-distributed Passive, non-distributed Explicit transfer of data and control Explicit transfer of data and control Hierarchical Hierarchical ProSave (lower layer) A subsystem can internally be modelled by ProSave. A subsystem can internally be modelled by ProSave. Connection between the layers

26. ProSys – the upper layer  Components (subsystems): Active, possibly distributed. Interact through message ports. 26 Subsystem A Subsystem B Subsystem C

27. ProSys –communication  Communication Asynchronous messages Explicit message channels  Design entity for data shared between subsystems  Not a physical message channel like a bus ! Subsystem A Subsystem B Subsystem C Subsystem D steering angle speed

28. ProSave – the lower level  Passive components (similar to task or function block)  Interact through input- and output ports. Data ports Trigger port  Component semantics: Initially passive, receiving input data. When triggered, read input data and turn active. Write output once. Return to the passive state. Component A

29. ProSave – the lower level  More complex components can have: Multiple output groups:  Output can be produced at different points in time.  Each group written once per activation. Multiple input groups (services):  Services can share state.  Individual control flows Component A 2010-03-0829 Pau

30. Component C ProSave – the lower level  Separated data- and control flow Component A Component B Hierarchical nestingHierarchical nesting Primitive components (implemented in C)Primitive components (implemented in C) Composite componentsComposite components

31. ProSave – the lower level  Connectors for more elaborate control: 31 –Data fork –Data or –Control fork –Control join –Control selection –Control or

32. Modelling a ProSys subsystem in ProSave  Message ports  trigger and data  Clocks and events 32 C1 C2 C3 10 Hz

33. Electronic Stability Control in ProSys 33

34. Stability Control System in ProSave Primitive Subsytems 2010-03-0834 Pau

35. ProCom – Summary  A component model for “distributed control-intensive embedded systems”  Rich design-time component notion including models, properties, realisation, analysis results, etc.  Two layers for addressing the different paradigm existing at different abstraction level: ProSys: Active subsystems, message passing. ProSave: Passive components, trigger/data flow. 35

36. 36

37. 37 ProCom Component-Development Approach Extra-functional properties ??? Analysis ???

38. A Huge List of Properties 38 Execution time PrioritiesDeadline Schedule policy End-to-end deadline Response time Computation time WCET/BCET Static memory usage Dynamic memory usage CPU usage Power consumption Memory footprint Disk access Network access SafetyReliabilityAvailabilityRecoverabilityMaintainabilityAccessibility Nb of reuse Throughput Confidentiality Nb of tests Cost Value range Compliance to standard Precision Extensibility Confidentiality Integrity Security Evolvability CredibilityAccuracyLoC...

39. Characteristics of Extra-Functional Properties  Different representations numbers, intervals, formula, models, image,...  Different techniques to obtain the values model checking, measurement, calculation, expert estimate,....  Relation to different entities system, component, interfaces, links,...  Validity conditions: context hardware, specific library, scheduling policy, usage Profile, other properties,... 39

40. Example 40 Static Memory Usage value: 10, kB version: 1 timestamp: 080120#17:44 source: estimation value: 10, kB version: 1 timestamp: 080120#17:44 source: estimation value: 15, kB version: 2 timestamp: 080220#10:00 source: measurement platform: X value: 15, kB version: 2 timestamp: 080220#10:00 source: measurement platform: X WCETWCET value: 25, clock cycle version: 1 timestamp: 090128#11:00 source: analysis platform: X value: 25, clock cycle version: 1 timestamp: 090128#11:00 source: analysis platform: X value: 30, clock cycle version: 2 timestamp: 090105#15:00 source: estimation value: 30, clock cycle version: 2 timestamp: 090105#15:00 source: estimation

41. 41

42. PRIDE The ProCom Integrated Development Environment

43. Main Idea Emphasis on component development & component reuse Seamless integration of analysis techniques 43

44. Components: a central concept  Components are the main units of development  They follow the rich-desgin component concepts  “a component is the collection of all the artefacts produced or required during the development process”  Concretely, based on a predefined file structure  Source code folder,  Models folder,  Documentation folder,  Metadata file 44

45. The various facets of a component  Component type Defines all the fixed parts of the component Characterised by:  a universally unique ID,  a name (possibly non-unique)  a architectural description (ports, services, etc.)  a functionality  Component instances: Refer to the corresponding component type Used during the design and realisation of composite components Can have additional information, specific to that instance  Ex: worst case execution time 45

46. Overview of the Architecture 46 PRIDE Component Explorer ComponentEditors Synthesis Analysis Tools Attribute Definitions Fault- Propagation Parametr ic WCET REMESMem.UsageWCET EFP Assurance REMES Simulator REMES Editor createsandadds AnalysisExpert uses Analyst ComponentRepository Core Concepts CBSEProCom Rich Components SystemDeveloper import/exportsynthetise BinaryFiles Support for EFPs RuntimeEfficiency......

47. 47

48. Demo Page 48, CBSE graduate course

49. 49

50. Introduction to Lab2 Page 50, CBSE graduate course

51. Page 51, CBSE graduate course Objectives  Apply component based software engineering principles to embedded system development Model an embedded system using a component based model Reuse components between systems Calculate its non functional properties Learn about composition and interaction semantics Uses a dedicated tool suite.

52. Expected Output  Same system as for Lab1 Archive files only (no folder) named ”Lab2X_Y.zip” where X=your name (and Y=name of your teammate if you work in pair).  1 report explaining your design choices and calculation results  The Project folder for your system  Individual work (or in pair) But nothing else! Both have to submit the archive file  Do not copy solutions from others ! Page 52, October 24, 2015 Advanced CBSE

53. Deadline  Tuesday 08 February 2011 23:59 (FIRM Deadline!)  If you submit your work late, you fail one submission opportunity => only one chance to pass the lab before Exam1!  Remember. Lab2 must also be approved to before Exam 1 Page 53, CBSE graduate course

54. The assignment  In 3 parts Modelling an industrial Baking Conveyor System using ProCom and PRIDE Practice reuse of components in adapting the system Calculate extra-functional properties on simple cases Page 54, CBSE graduate course

55. The Industrial Baking Conveyor System Page 55, CBSE graduate course  Main parts: Temperature Sensor Humidity Sensor Heating Unit Orchestrator Oven Conveyor Belt

56. Usage Scenario Page 56, CBSE graduate course Orchestrator Oven Conveyor Belt Oven monitors the temperature and humidity sensor measurements and determines 1. if the heat should be increased and 2. if the cookies are cooked correctly Carries the cookies from point A to point B in passing by the oven Ensure that the conveyor belt and the oven are working together

57. Part 1 - What you need to do?  To model this system with ProCom and PRIDE Tip 1  Start by understanding last year assignment (http://www.idt.mdh.se/kurser/cd5490/2010/Assignment%202/index.htm )http://www.idt.mdh.se/kurser/cd5490/2010/Assignment%202/index.htm  Use pen and paper before PRIDE  Once you are sure of your solution. Model it in PRIDE Tip 2:  While designing components, think about reuse  What would make that component more reusable?  What would prevent to reuse that components in different systems Page 57, CBSE graduate course

58. Part 2 - Reuse  You want to develop software for a second type of industrial baking conveyor system Page 58, CBSE graduate course Conveyor Belt Rotating TableOven Waste Ok

59. Part 2 - What you need to do?  To model this second system with ProCom and PRIDE Tip  Think carefully on the first system with reuse in mind  What are the impacts of this change in the model you design for the first system?  What are the components that you can reuse?  What need to be added or modified? And Why? Page 59, CBSE graduate course

60. Part 3 – Calculate Extra-Functional Properties  First on a simple example, you will need to Calculate static memory usage of whole system, based on static memory usage of all components used in system Calculate WCET of the system, based on all possible execution paths  Then on the oven element of your system, you will need to Calculate static memory usage of element, based on static memory usage of all components used in system Calculate its WCET, based on all possible execution paths Page 60, CBSE graduate course

61. Static Memory Usage and WCET  Static memory usage (without considering the glue code) 10 (A) + 8 (B) + 6 ( C) + 10 (D) = 34  Execution paths (I) A → B → D, (II) A → C → D  WCET Path (I) = 5 + 15 + 15 = 35 Path (II) = 5 + 20 + 15 = 40 = WCET Page 61, CBSE graduate course

62. Questions ?!? Page 62, CBSE graduate course Questions ?!!?