1. Real-Time Embedded Systems Assist. dr. Barbara Koroušić Seljak Barbara.Korousic@ijs.si (01) 4773-363

2. Jožef Stefan International Postgraduate School2 Where we have been... (1) Computers inside a system...

3. Jožef Stefan International Postgraduate School3 Where we have been... (2) ESs must meet requirements of: Real-time. Resource consumption (CPU, memory, power, physical space). Dependability (safety, reliability). Long-life systems (reusability, flexibility, portability). Interoperability.

4. Jožef Stefan International Postgraduate School4 Where we are going today... Designing and developing real-time software Implementation and performance issues

5. Jožef Stefan International Postgraduate School5 Designing and developing real- time software 1.Diagramming 2.Practical diagramming methods 3.Designing & constructing software

6. Jožef Stefan International Postgraduate School6 1. Diagramming

7. Jožef Stefan International Postgraduate School7 In 1999, General Motors had to recall 3.5 million vehicles because of an anti-lock braking SW defect. Stopping distances were extended by 15-20 meters. Federal investigators received reports of 2,111 crashes and 293 injuries. A typical design&development process in the past (?) 1.Programmers thought about the problem to be solved. 2.They wrote lines of code to solve it. 3.The code was tested and modified until it was correct. 4.This source code was released as the system documentation.

8. Jožef Stefan International Postgraduate School8 Today Practically all modern SW tools use diagrams as an integral part of the design & development process! What is a diagram? Partial graphical representation of a system's model, dealing with aspects: Problem recognition. Modularity. Tractability. Sequence. Circumstance.

9. Jožef Stefan International Postgraduate School9 Why use diagrams? As a DESIGN tool As a COMMUNICATION medium As a MAINTENANCE tool As a DOCUMENTATION technique

10. Jožef Stefan International Postgraduate School10 ESs are not trivial!

11. Jožef Stefan International Postgraduate School11 Diagrams for documentation High-level diagrams: Task oriented. Overall system structure + major subsystems. Overall functioning of the design. Interaction of the system with its environment. Functions & interactions of the subsystems. Low-level diagrams: Solution-oriented. Details. System internal information.

12. Jožef Stefan International Postgraduate School12 Diagrams for maintenance Don’t forget: System maintenance is usually carried out by workers who: Weren’t involved in the development in the first place. Have only a limited understanding of the overall task. Have to learn a lot very quickly to perform even small design changes.

13. Jožef Stefan International Postgraduate School13 Good diagramming features Small Simple Clear Complete Few abstract symbols Use formal rules The design approach must be stated in terms of the problem not its solution!

14. Jožef Stefan International Postgraduate School14 Overall diagram set for RT & E systems Always use a diagram set, which is in common use; forms part of accepted design methods; is supported by tools. System requirements/ specifications System context System configuration System architecture System usage System SW/HW structure System & SW behaviour SW distribution System & SW design UML SysML

15. Jožef Stefan International Postgraduate School15 Design aspects (1) System context: All external entities Entity attributes The relationship of external entitites with the system. System configuration: Identification and specification of the major physical components of the system.

16. Jožef Stefan International Postgraduate School16 Design aspects (2) System architecture: The system architectural model is driven mainly by system, not SW/HW, aspects. System usage: The design is driven by the needs of the system itself! System SW/HW structure: SW/HW solution independent of implementation techniques.

17. Jožef Stefan International Postgraduate School17 Design aspects (3) System and SW behaviour: Interactions between SW components and the outside world. Internal interactions between the SW components. Dynamical behaviour of the overall SW structure. Dynamical behaviour of individual SW components.

18. Jožef Stefan International Postgraduate School18 Design aspects (4) SW distribution: Operational and performance requirements (system responsiveness, safety, degradation and failure modes, test, commissioning and maintenance functions). Information concerning the execution times of individual objects. Timing data for inter-object communication activities. Network timing performance.

19. Jožef Stefan International Postgraduate School19 2. Practical diagramming methods

20. Jožef Stefan International Postgraduate School20 The major design techniques Structured / data flow methods: Functional modeling (‘80s) Greatest CASE tool support for the Yourdon & SDL approaches. Object-oriented (OO) methods: Data&functional modeling (’90s) The industry de facto standard: the Unified Modeling Language (UML). AADL, ACME, Wright, ADL.

21. Jožef Stefan International Postgraduate School21 Diagrams Structured designs Context diagrams Entity relationship diagram State transition diagrams... OO designs Use case diagrams Deployment diagrams Packages Class diagrams...

22. Jožef Stefan International Postgraduate School22 What is a(n OO) model? An abstract model of a system: 1.Defined by a set of (OO) diagrams. 2.Contains a semantic backplane: i.e., a documentation, such as written use cases, that drive the model elements and diagrams. 3.Its conceptual model (a computer program) attempts to simulate the abstract model.

23. Jožef Stefan International Postgraduate School23 Well-defined (OO)model Self-consistent Presents multiple levels of abstraction Complete Facilitates communication among the various stakeholders Allows easy changes over time

24. Jožef Stefan International Postgraduate School24 What is a pattern? Pattern is more than a model. It is a three-part rule, which expresses a relation between: a certain context, a certain system of forces which occurs repeatedly in that context, and a certain SW configuration which allows these forces to resolve themselves. http://hillside.net/patterns

25. Jožef Stefan International Postgraduate School25 OO development process (1) OO analysis: 1.Establish system requirements (problem analysis) 2.Develop the ideal SW model and map it onto the HW architecture (structural & behavioural analysis & modeling) 3.Develop the subsystem specification model (further object modeling) OO design: 1.For each processor develop the specification model (physical and interfacing aspects) 2.For each processor develop the implementation model (concurrent SW) 3.For each task produce its sequential code (code- related items).

26. Jožef Stefan International Postgraduate School26 OO development process (2) Spiral model of a SW process (Boehm, 1988) Recognition of risks! http://www.answers.com/topic/spiral-model

27. Jožef Stefan International Postgraduate School27 The Rational Unified Process (RUP; IBM, 2003) Inception: establish a business case for the system. Elaboration: develop an understanding of the problem domain. Construction: system design, programming & testing. Transition: moving the system to the user community.

28. Jožef Stefan International Postgraduate School28 The Agile Unified Process A ‘lite’ version of the RUP:

29. Jožef Stefan International Postgraduate School29 The historical development of UML (1) Previous efforts: OOD methods: Shlaer & Mellor, 1988 Coad & Yourdon, 1990 Abbott & Booch, 1991 Jacobson, et al, 1992... Objects, types & classes

30. Jožef Stefan International Postgraduate School30 The historical development of UML (2) Rational Software Corporation, 1994 Unified Method: Rumbaugh - OMT (OOA) Booch (OOD) Jacobson – Objectory (OOSE) OMG (Object Management Group), The UML specification, 1996  UML1.1, 1997 The Three Amigos Rumbaugh Booch Jacobson http://cs-exhibitions.uni-klu.ac.at/index.php?id=185

31. Jožef Stefan International Postgraduate School31 The main characteristics of UML Graphical (object) modeling language for complex systems: Specification, design, automatic code generation, documentation. Relatively easy to learn (intuitive) Well-defined (models can be verifiable) Independent of any programming language Great CASE tool support

32. Jožef Stefan International Postgraduate School32 What does UML include? Model elements, that capture the fundamental modeling concepts and semantics. A notation, for visual rendering of model elements. Rules, that describes idioms of usage. It also provides extensibility and specialization mechanisms to extend the core concepts.

33. Jožef Stefan International Postgraduate School33 Model elements All fundamental concept: From concrete language constructs (class). To abstract concepts (use case ). Sample design Design mirrored in the UML semantics model

34. Jožef Stefan International Postgraduate School34 The structure of UML UML diagrams represent three different views of a system model: 1.Functional requirements view 2.Static structural view 3.Dynamic behaviour view Warning: UML is a notation and NOT a methodology!

35. Jožef Stefan International Postgraduate School35 Functional requirements view Emphasizes the functional requirements of the system from the user's point of view. Includes: Use case diagrams: WHY system is used in WHO uses it!

36. Jožef Stefan International Postgraduate School36 Functional requirements view 13 types of diagrams what must happen in the system

37. Jožef Stefan International Postgraduate School37 Static structural view Emphasizes the static structure of the system using: objects, attributes, operations, relationships. Includes: class diagrams (objects, packages, actors), composite structure diagrams.

38. Jožef Stefan International Postgraduate School38 Static structural view 13 types of diagrams what things must be in the system

39. Jožef Stefan International Postgraduate School39 Dynamic behaviour view Emphasizes the dynamic behavior of the system by showing collaborations among: objects and changes to the internal states of objects. Includes: sequence diagrams, activity diagrams, state machine diagrams.

40. Jožef Stefan International Postgraduate School40 Dynamic behaviour view 13 types of diagrams the flow of control and data among the things in the system

41. Jožef Stefan International Postgraduate School41 Structural elements & diagrams Objects, classes (structured classes, ports), and interfaces Relations (association, generalization, and dependency) Subsystems, components, and packages

42. Jožef Stefan International Postgraduate School42 Objects, classes, and interfaces Object: a run-time entity that occupies memory at some specific point in time: Has behavior (methods) & data (attributes) Class: a design-time concept that defines the structure and behavior for a set of objects to be created at run-time: Specifies behavior (methods) & data (attributes) Interface: a design time concept that specifies the messages a class receives: Has behavior only (operations)

43. Jožef Stefan International Postgraduate School43 Relations Primary Relations in UML Associations Normal association Aggregation Composition Generalization Dependency > for templates > for classes > and > for use cases...

44. Jožef Stefan International Postgraduate School44 Relations

45. Jožef Stefan International Postgraduate School45 Packages and subsystems Large-Scale Logical Design Packages capture larger scale decompositions that exist at design time (cannot be instantiated). Packages organize your model. Packages define a namespace for managing large numbers of model elements. Large-Scale Physical Design Subsystems capture larger scale decompositions that exist at run-time. Contains objects that collaborate to realize common function purpose (use case) of the subsystem.

46. Jožef Stefan International Postgraduate School46 Subsystems Provides opaque interfaces to its clients and achieves its functionality through delegation to objects that it owns internally. Contains components & objects on the basis of common run-time functional purpose. Metasubtype of both Classifier & Package. System Subsystem

47. Jožef Stefan International Postgraduate School47 Components Basic reusable element of software: Organizes objects together into cohesive run-time units that are replaced together. Provides language-independent opaque interfaces.

48. Jožef Stefan International Postgraduate School48 Behavioral elements & diagrams Actions and activities Operations and methods Activity diagrams Statecharts Interactions Use case and requirements models

49. Jožef Stefan International Postgraduate School49 UML diagram type usage (1) Use case: Capture requirements in terms of interactions between a system and it’s users. Class: Shows classes, attributes, associations and generalization. Object: Shows selected instances of classes and values for attributes at run time. Sequence: Shows synchronous and asynchronous interactions between objects. State Machine: Shows behavior over time in response to events.

50. Jožef Stefan International Postgraduate School50 UML diagram type usage (2) Component: Shows large-scale components and their interfaces. Composite Structure: Shows internal structure, ports, collaborations, structured classes. Package: Shows groupings of elements into packages and dependencies between them. Communication: Shows communications between objects (used to be called “collaborations”).

51. Jožef Stefan International Postgraduate School51 UML diagram type usage (3) Activity: Shows parallel and sequential behaviors connected by data and control flows. Interaction: Shows an overview of activities and interactions. Timing: Shows timing in a variation of sequence / interaction diagrams. Deployment: Shows deployment onto nodes in a specific implementation.

52. Jožef Stefan International Postgraduate School52 OO analysis (1) A number of UML techniques can come handy here: Use cases A class diagram drawn from the conceptual perspective. An activity diagram to show the work flow of the organization. A state diagram, which can be useful if a concept has an interesting life cycle.

53. Jožef Stefan International Postgraduate School53 OO analysis (2) Analysis of RT & E systems: Schedulability Scheduling policy Reliability Concurrent tasks Safety & impact of component failure Graph theory for dependence modeling

54. Jožef Stefan International Postgraduate School54 Use case diagram

55. Jožef Stefan International Postgraduate School55 OO design Useful UML design techniques: Class diagrams from a SW perspective. Sequence diagrams for common scenarios. Package diagrams to show the organization of the SW. State diagrams for classes with life histories. Deployment diagrams to show the physical layout of the SW.

56. Jožef Stefan International Postgraduate School56 Sequence diagram

57. Jožef Stefan International Postgraduate School57 UML for ESs Allows you to: work at a higher level of abstraction; visualize concurrent behavior. 25 % of RT&E projects in 2007 were using UML ( Venture Data Corporation ). Initially not designed for real- time: UML Profile for Modeling Quality of Service and Fault Tolerant Characteristics and Mechanisms; UML profile for schedulability, performance and time (MARTE). UML 1.4 Real-Time UML (UML-RT ROOM) is standard UML (2.0).

58. Jožef Stefan International Postgraduate School58 UML profiles What is a profile? A UML model, which describes extensions and subsets to UML; the OCL (Object Constraint Language) and stereotype definitions that describe the rules, which in UML 2, are captured in a package.

59. Jožef Stefan International Postgraduate School59 UML Profile for Modeling Quality of Service and Fault Tolerant Characteristics and Mechanisms http://www.omg.org/docs/ptc/04-09-01.pdf Defines stereotypes for properties, such as: performance, dependability, security, integrity, coherence (temporal consistency of data & SW elements), throughput, latency, efficiency, demand, reliability, and availability.

60. Jožef Stefan International Postgraduate School60 UML profile for Modeling and Analysis of Real-Time and Embedded systems MARTE Adds capabilities for analyzing schedulability & performance properties of UML specifications. Three main packages: 1.Time & concurrent resource modeling package 2.Real-time & embedded application modeling package 3.Real-time & embedded application analysis

61. Jožef Stefan International Postgraduate School61 RT Profile

62. Jožef Stefan International Postgraduate School62 Additional diagrams for RT systems System configuration diagrams System architecture diagrams System scope diagrams Node architecture diagrams Processor architecture diagrams Memory map diagrams Tasking diagrams

63. Jožef Stefan International Postgraduate School63 Concurrency Concurrency architecture refers to: Identification of task threads and their properties Mapping of passive classes to task threads Identification of synchronization policies Task scheduling policies Unit of concurrency in UML is an «active» object: «active» objects aggregate passive semantic objects via composition and delegate asynchronous messages to them. Standard icon is a class box with heavy line.

64. Jožef Stefan International Postgraduate School64 Tasking diagram Class diagram that shows elements related to the concurrency model: active objects, semaphore objects, message & data queues, constraints & tagged values. May use opaque or transparent interfaces.

65. Jožef Stefan International Postgraduate School65 EU Project MARTES

66. Jožef Stefan International Postgraduate School66

67. Jožef Stefan International Postgraduate School67 Textbooks about UML Douglass, B. P. (2002). Real-Time Design Patterns: Robust Scalable Architectures for Real-Time Systems, Addison-Wesley. Douglass, B. P. (2007). Real-Time UML Workshop for Embedded Systems, Elsevier-Newnes. Fowler, M. (2003). UML Distilled Third Edition, Addison-Wesley. Ambler, S. W. (2004). The Object primer Third Edition, Agile Model-Driven Development with UML 2.0, Cambridge University Press.

68. Jožef Stefan International Postgraduate School68 How to select a UML tool? Repository Support HTML documentation Pick lists for classes & methods Versioning Printing support Exporting diagrams Robustness New Releases Round-Trip engineering Full UML 2.x support Data modeling Model navigation Diagram views Scripting Platform In the future...

69. Jožef Stefan International Postgraduate School69 List of UML tools MS, Visio 2002 Professional Rhapsody, Telelogic BridgePoint UML Suite, Mentor Graphics http://www.objectsbydesign.com/tools/umltool s_byPrice.html ($ 11,500- $ 0)http://www.objectsbydesign.com/tools/umltool s_byPrice.html

70. Jožef Stefan International Postgraduate School70 3. Designing and constructing software

71. Jožef Stefan International Postgraduate School71 Design & construction methods Monolithic (great design plan  implementation): When one person is concerned with the design & build programme. For simple tasks. Modular (modular design plan  design integration  implementation): Pros: Subtasks are handled simultaneously by different designers. Cons: changes to the global values can produce design chaos. Independent or model-based (modular design plan  modular design implementation  integration)

72. Jožef Stefan International Postgraduate School72 Modular design & construction

73. Jožef Stefan International Postgraduate School73 Model-based design & construction

74. Jožef Stefan International Postgraduate School74 Three ways of using UML Sketch - UML is used informally (Fowler): 1.Few diagrams are sketched out and discussed, 2.coding proceeds directly. Blueprint - UML is used to specify the SW structure (Powell): 1.A tool can generate code frames from these models. 2.The developer then adds code directly to the model. 3.Warning: One-to-one correspondence between the UML diagrams and the code! Executable - UML is used as a programming language: The UML action model is designed to allow the model to be translated into any implementation.

75. Jožef Stefan International Postgraduate School75 The evolution of development

76. Jožef Stefan International Postgraduate School76 Approaches to using UML as a programming language Model Driven Architecture, MDA (Kleppe, et al.): 1.Build platform- independent model (PIM). 2.Tools can turn a PIM into a platform-specific model (PSM). 3.Further tools generate code from that PSM. Executable UML (xtUML, Mellor and Balcer): 1.Build platform- independent model. 2.Use a model compiler to turn that UML model into a deployable system in a single step. 3.Skeleton code  executable code

77. Jožef Stefan International Postgraduate School77

78. Jožef Stefan International Postgraduate School78 MDA ( OMG standard ) Formal specs of the system’s structure & function PIM + technical details, such as middleware, OS, network, CPU characteristics

79. Jožef Stefan International Postgraduate School79 The model is the embedded code with state machines for modeling concurrent behavior and exploring synchronization issues

80. Jožef Stefan International Postgraduate School80 xUML

81. Jožef Stefan International Postgraduate School81 How to use the xUML? (1) System Model Domain identification Defining use cases Iterate the system model Modeling a single domain Classes State machines – one for each class Procedures – one per each state machine Iterating the domain model – abstract the classes by modeling one role per class Iterating between domain and system model

82. Jožef Stefan International Postgraduate School82 How to use the xUML? (2) Verification and execution Model verification Static – like a syntax check Dynamic – requires real objects and a scenario to execute Model compilation xUML  implementation Drawback: no non-functional requirements: QoS, concurrency! Iterating verification and execution Nucleus BridgePoint

83. Jožef Stefan International Postgraduate School83 Project failures usually occur when Executable models are not employed Code is allowed to deviate from the models Development processes don’t manage risks through early validation

84. Jožef Stefan International Postgraduate School84 Choosing a programming language for ESs Ada 95: OO version in 1995; for safety-critical applications C: MISRA-C for safety-related systems Used by 77 % of projects C++: OO language; it is NOT an extended C Used by 44 % of projects Embedded C++: a subset of C++. Java

85. Jožef Stefan International Postgraduate School85 Implementation and performance issues 1.Analysing and testing source code 2.Mission-critical and safety-critical systems 3.Performance engineering 4.Documentation

86. Jožef Stefan International Postgraduate School86 1. Analysing and testing source code

87. Jožef Stefan International Postgraduate School87 SW source code test techniques SW source code testing Assessment of source code quality Assessment of source code behaviour SW source analysis (static analysis) SW code execution (dynamic analysis) Code execution Code inspection

88. Jožef Stefan International Postgraduate School88 Types of testing

89. Jožef Stefan International Postgraduate School89 Integrated development & testing

90. Jožef Stefan International Postgraduate School90 Black-box testing

91. Jožef Stefan International Postgraduate School91 UML & testing One objective of the UML 2.0 is executable UML (xUML) meaning Code generation Simulation Validation Test generation UML testing profile

92. Jožef Stefan International Postgraduate School92 UML testing profile

93. Jožef Stefan International Postgraduate School93 2. Mission-critical and safety- critical systems

94. Jožef Stefan International Postgraduate School94 Critical systems System in which failure(s) may have significant and far-reaching consequences: Mission-critical: telecommunication switch Safety-critical: airbag deployment system Fault = error Failure = numerical overflow, wrong number computed...

95. Jožef Stefan International Postgraduate School95 How to prevent failures? Formal specifications using formal specification languages (e.g. VDM) Basic design & programming issues! Dealing with run-time problems: Exception handling Backward error recovery N-version programming Real-world interfacing OSs Processor problems HW-based fault tolerance

96. Jožef Stefan International Postgraduate School96 3. Performance engineering

97. Jožef Stefan International Postgraduate School97 Why performance engineering is important? In most projects functional designs ARE correct. However, RT & E SW design is intrinsically driven by the need to meet system time requirements. Major categories of system timing requirements: Control loops Algorithmic processing Human factors Computational processing Response deadlines

98. Jožef Stefan International Postgraduate School98 Ways of performance modeling Top-down – requirements-driven: Design performance: Who knows! Bottom-up – results-driven: Based on using known data to predict system performance. Middle-out – risk-driven: Performance modeling is all about risk reduction in general.

99. Jožef Stefan International Postgraduate School99 Some practical issues in performance engineering Basic questions: What? Why? How the results will be used? Which modeling techniques are best suited to the problem? How much is it going to cost in manpower, time & money? Modeling & simulation options: Simple calculations (deterministic) Spreadsheet analysis (deterministic) Modeling tools (non- deterministic / deterministic): Simprocess (graphical modeling tool) Simscript (language- based tool) 5 % of the project costs

100. Jožef Stefan International Postgraduate School100 4. Documentation

101. Jožef Stefan International Postgraduate School101 Documentation 1.Why documentation is necessary? 2.Documentation structure: Basic questions: What? Who? When? Extend of supply Commercial plan & costing Project plan & management structure Quality plan Overall technical description

102. Jožef Stefan International Postgraduate School102 Overall technical description Overall system concepts System design philosophy System functional description Equipment (HW) description SW structure SW design techniques System performance features Testing & installation techniques Man-machine interfacing Maintenance & repair techniques Reliability estimates Failure mode behaviour

103. Jožef Stefan International Postgraduate School103 SW life-cycle documentation Requirements phases Design phases Implementation phases Test, integration & debug phases System functional specifications SW system specifications source code listings SW test documents SW application documents SW installation documents

104. Jožef Stefan International Postgraduate School104 System functional specifications System functional specs Block diagram description Functional diagram description Requirements specifications Overall system description Subsystem descriptions Functional block diagrams Control schemes Non-functional requirements Functional requirements Development requirements

105. Jožef Stefan International Postgraduate School105 SW system specifications System system specs Architectural structure Physical structure System levelSubsystem level System structure System inputs & outputs System dynamics system timing System protection Subsystem structure Logical processes Process interfaces Process communication Process synchronization System levelTask level Process models Process scheduling Process timing Process sychronization Process housekeeping & synchronization Task (program structure)

106. Jožef Stefan International Postgraduate School106 Organization (1) Consultation: JSI / room S6D, (01) 4773-363, barbara.korousic@ijs.si Web page (course material): csd.ijs.si/korousic/korousic.html

107. Jožef Stefan International Postgraduate School107 Organization (2) Course textbooks: J. Cooling, Software Engineering for Real-Time Systems, Addison-Wesley, 2003; I. Sommerville, Software Engineering, Addison- Wesley, 2004.

108. Jožef Stefan International Postgraduate School108 Organization (3) Course material: slide copies, books, papers Exam: seminar work OR oral exam May, June, September

109. Jožef Stefan International Postgraduate School109 Organization (3) Ideas for seminar works: Comparison of programming languages (xUML) Model-driven development SysML/UML for embedded systems Open-source Eclipse platform (UML 2.x metamodel), http://www.eclipse.orghttp://www.eclipse.org Domain-specific modeling Reverse-engineering