1 / 109

Real-Time Embedded Systems

Real-Time Embedded Systems. Assist. dr. Barbara Koroušić Seljak Barbara.Korousic@ijs.si (01) 4773-363. Where we have been... (1). Computers inside a system. Where we have been... (2). ESs must meet requirements of : Real-time. Resource consumption (CPU, memory, power, physical space).

stash
Télécharger la présentation

Real-Time Embedded Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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. Jožef Stefan International Postgraduate School

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

  5. Designing and developing real-time software • Diagramming • Practical diagramming methods • Designing & constructing software Jožef Stefan International Postgraduate School

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

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

  8. 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. Today Jožef Stefan International Postgraduate School

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

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

  11. 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. Diagrams for documentation Jožef Stefan International Postgraduate School

  12. 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. Jožef Stefan International Postgraduate School

  13. 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! Jožef Stefan International Postgraduate School

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

  15. 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. Jožef Stefan International Postgraduate School

  16. 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. Jožef Stefan International Postgraduate School

  17. 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. Jožef Stefan International Postgraduate School

  18. 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. Jožef Stefan International Postgraduate School

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

  20. 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. Jožef Stefan International Postgraduate School

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

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

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

  24. 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 forceswhich occurs repeatedly in that context, and • a certain SW configuration which allows these forces to resolve themselves. • http://hillside.net/patterns Jožef Stefan International Postgraduate School

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

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

  27. 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. The Rational Unified Process (RUP; IBM, 2003) Jožef Stefan International Postgraduate School

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

  29. 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 Jožef Stefan International Postgraduate School

  30. 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 The historical development of UML (2) Rumbaugh Booch Jacobson http://cs-exhibitions.uni-klu.ac.at/index.php?id=185 Jožef Stefan International Postgraduate School

  31. 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 The main characteristics of UML Jožef Stefan International Postgraduate School

  32. 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. Jožef Stefan International Postgraduate School

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

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

  35. 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! Functional requirements view Jožef Stefan International Postgraduate School

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

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

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

  39. 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. Dynamic behaviour view Jožef Stefan International Postgraduate School

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

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

  42. Objects, classes, and interfaces • Object: a run-time entity that occupiesmemory at some specific point in time: • Has behavior (methods) & data (attributes) • Class: a design-time concept thatdefines the structure and behavior for a setof objects to be created at run-time: • Specifies behavior (methods) & data (attributes) • Interface: a design time concept thatspecifies the messages a class receives: • Has behavior only (operations) Jožef Stefan International Postgraduate School

  43. Relations • Primary Relations in UML • Associations • Normal association • Aggregation • Composition • Generalization • Dependency • <<bind>> for templates • <<friend>> for classes • <<includes>> and <<extends>> for use cases • . . . Jožef Stefan International Postgraduate School

  44. Relations Jožef Stefan International Postgraduate School

  45. Packages and subsystems • Large-Scale Logical Design • Packages capture larger scale decompositions thatexist at design time (cannot be instantiated). • Packages organize your model. • Packages define a namespace for managing largenumbers of model elements. • Large-Scale Physical Design • Subsystems capture larger scale decompositionsthat exist at run-time. • Contains objects that collaborate to realizecommon function purpose (use case) of thesubsystem. Jožef Stefan International Postgraduate School

  46. Provides opaque interfacesto its clients and achieves its functionalitythrough delegation to objects that it ownsinternally. Contains components & objects on the basis ofcommon run-time functional purpose. Metasubtype of both Classifier & Package. Subsystems System Subsystem Jožef Stefan International Postgraduate School

  47. Components • Basic reusable element of software: • Organizes objects together into cohesive run-timeunits that are replaced together. • Provides language-independent opaqueinterfaces. Jožef Stefan International Postgraduate School

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

  49. 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. Jožef Stefan International Postgraduate School

  50. 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”). Jožef Stefan International Postgraduate School

More Related