1 / 62

UML, Embedded Systems, and Application Frameworks

UML, Embedded Systems, and Application Frameworks. Shang-Wei Lin, Chun-Hsian Huang, and Pao-Ann Hsiung Embedded Systems Laboratory National Chung Cheng University Taiwan. Outline. UML and Embedded System Design UML Model-Driven Development Rhapsody Embedded System Application Framework

adair
Download Presentation

UML, Embedded Systems, and Application Frameworks

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. UML, Embedded Systems, and Application Frameworks Shang-Wei Lin, Chun-Hsian Huang, and Pao-Ann Hsiung Embedded Systems Laboratory National Chung Cheng University Taiwan

  2. Outline • UML and Embedded System Design • UML Model-Driven Development • Rhapsody • Embedded System Application Framework • VERTAF

  3. Outline • UML and Embedded System Design • UML Model-Driven Development • Rhapsody • Embedded System Application Framework • VERTAF

  4. UML and Embedded System Design • Introduction • Embedded System • UML • Research Projects for Embedded Software

  5. Introduction • Embedded systems are becoming more and more pervasive in our daily life • The functionalities of embedded systems are also becoming more and more complex • Correctness is difficult to verify

  6. General Purpose vs. Embedded Systems

  7. Unified Modeling Language • UML is a standardized general-purposemodeling language in the field of software engineering • A set of graphical notationsfor creating abstract models of concrete systems • Object-Oriented Analysis (OOA) • Object-Oriented Design (OOD)

  8. UML (cont’d) • UML and object-oriented technology are quite suitable for modeling embedded software • However, the following have to be considered • Target architecture • Real-time characteristics

  9. Research Projects for Embedded Software • MoBIES • HUGO • DESS • VERTAF

  10. MoBIES • Model-Based Integration of Embedded Systems • Supported by USA DARPA • Consists of several subprojects

  11. MoBIES (cont’d) • Subprojects • AIRES (Automatic Integration of Reusable Embedded Software) • Automatically generates a run-time model from a structural model through several metamodels • Software architecture • Platform • … • Time Weaver • Captures para-functional properties into models of different semantic dimensions • Event flow • Concurrency • …

  12. HUGO • Developed by Germany’s Ludwig-Maximilians University • Model checking statecharts against collaborations • Code generation • Noscheduling

  13. DESS • Developed by EUREKA-ITEA • Only provides guidelines for incorporating various kinds of tools into the design process • Neither real implementation of the concepts nor any toolset is provided by DESS

  14. VERTAF • Developed by Embedded Systems Laboratory, National Chung Cheng University, Taiwan • An application framework that integrates • UML Modeling • Formal Software Synthesis • Scheduling • Code Generation • Formal Verification • Model Checking

  15. Outline • UML and Embedded System Design • UML Model-Driven Development • Rhapsody • Embedded System Application Framework • VERTAF

  16. Rhapsody • Introduction • Rhapsody for RTOS • Rhapsody Desktop • Target Platform • Rhapsody RTOS Adapter • Adapt Rhapsody to a New RTOS • OS Services for the Applications

  17. Introduction • Include a graphic editor for each of the UML diagrams • Use case, sequence, collaboration, object model, component, state machine and activity diagrams • Not only capture the design of the system but also generate implementation code • C, C++, Java and Ada

  18. Introduction (cont’d) • Provide Model-Driven Development (MDD) environment based on UML 2.1 • Systems and software development of real-time and embedded applications • Can use an iterative design approach • Software can be constantly executed and validated • Can rapidly target the platform independent application model to a real time embedded operating system

  19. Rhapsody for RTOS • Can construct portable and technology independent systems via • Generation of application code from platform independent models • Object eXecution Framework (OXF) • Use of OS-specific adaptors for most commercial RTOSs

  20. Platform-Independent Applications Platform-Independent Framework OS-Dependent Adapter RTOS Microprocessor Rhapsody for RTOS (cont’d) Source Code Compiler and Linker Model Entries Model-Entry Model Compiler Model Execution Model Tester Model Animation Target Platform Rhapsody Desktop

  21. Rhapsody Desktop • Model-Entry • enter the PIM using standard UML diagrams • Model Compiler • generate the source for the selected language and compiler • Model Tester • simulate and monitor the execution of the PIM-generated application

  22. Target Platform • PIM Framework • a real-time PIM framework provided by Rhapsody • OS-Dependent Adapter • a light-weight OS-specific adapter layer for handing interactions with the underlying RTOS

  23. Platform-Independent Applications Platform-Independent Framework OS-Dependent Adapter OS Abstraction Layer RTOS Microprocessor Rhapsody RTOS Adapter Rhapsody RTOS Adapter Generated Application OXF (Object eXecution Framework) RTOS

  24. Depend on Create Adapt Rhapsody to a New RTOS Rhapsody OXF Source Code OXF Libraries OS Abstraction Layer OS Environment Makefile Abstract OS Classes OS Environment Framework

  25. Generated Source Codes Adapt Rhapsody to a New RTOS (cont’d) Application Load Module Development Properties Generated Makefile Rhapsody OXF Libraries

  26. OS Services for the Applications • Tasking services • createOMOSThread(), createOMOSWrapperThread() • Synchronization services • OMOSMutex(), OMOSSemaphore() • Message queues • OMOSMessageQueue() • Communication port • OMOSConnectPort(), OMOSSocket() • Timer service • OMOSTimer()

  27. Outline • Unified Modeling Language (UML) • UML Model-Driven Development • Rhapsody • Embedded System Application Framework • VERTAF

  28. VERTAF • Background • Issues and Solutions • Framework Architecture • Framework Flow • Framework Phases • Application Examples

  29. Background • Verifiable Embedded Real-Time Application Framework (VERTAF) • A long-termresearch project of Embedded Systems Lab, National Chung Cheng University, Taiwan • Collaboration among several universities in Taiwan

  30. Background (cont’d) • Portions of work on this research project published already in several conferences and journals: • Scheduling: CODES’99, CODES’01, APSEC’01, CODES’02, APSEC’02, RTCSA’02, CODES’03, RTCSA’03, IEEE-TCE’04 • Verification: CODES’99, ECRTS’99, TACAS’99, COMPSAC’00, IEE-DCT’00, JSA’00, IEEE-TC’02 • Framework Architecture: RTAS’01, ISORC’02, IEEE-TSE’04, EUC’07, CLSS’07, JSPS’08

  31. Issues and Solutions Based on user given specifications for real-time embedded software, can we automaticallydesign, verify, and generate code? Yes, under some constraints!

  32. Issues and Solutions (cont’d) • How to specify real-time embedded software requirements? • UML models • Selected three types of models • Restricted as well as enhanced • Formal Semantics • For synthesis and verification • Specification Guidelines • For automatic analysis and design

  33. Issues and Solutions (cont’d) • What kinds of models can be used for each design phase? • Specification: Formal UML models • Synthesis: Real-Time Petri Nets • Verification: Extended Timed Automata • Model Continuity Problems: • Semantics Equivalence Checking • UML vs. Real-Time Petri Nets • UML vs. Extended Timed Automata

  34. Issues and Solutions (cont’d) • What is the Control-Flow? When to verify and when to synthesize? • Framework Approach • A semi-complete application • High-level architecture reuse • Inversion of control • Users fill in objects and functionalities, framework takes care of the software flow control • Proposed Flow • First, synthesize and then verify! • Smaller state-space

  35. Issues and Solutions (cont’d) • How to formally synthesize and verify? • Synthesis • Scheduling to satisfy local deadlines, global deadlines, memory constraints, power constraints • Verification • Model Checking • Interface Verification • Assume-Guarantee Reasoning • Abstraction Techniques

  36. Issues and Solutions (cont’d) • How to automatically generate code? • Code generation • Application • From formal UML models • Scheduler • From scheduled Petri Net models (derived from UML) • Code architecture • Multi-layered • Portable, Efficient

  37. Formal Verification Scheduler Generation LQS Scheduling HW Architecture Mapping Automatic Code Generation Framework Architecture UML Real-Time Embedded Object Model Reusable Components

  38. Framework Flow – Front End Modeling Verification Scheduling Scheduler Generation

  39. Framework Flow – Back End Architecture Mapping Code Generation

  40. Framework Phases • UML Modeling Phase • Scheduling Phase • Scheduler Generation Phase • Formal Verification Phase • Hardware Architecture Mapping Phase • Code Generation Phase

  41. UML Modeling Phase Modeling

  42. UML Modeling Phase (cont’d) • To specify requirements by a system model • Three diagrams chosen from UML: • Class Diagram with Deployments • Extended Sequence Diagrams • TimedStatecharts • Modifications for modeling real-time embedded software requirements • CD: Hardware deployments • SD: State marks, control extensions • SC: Timing control keywords, real-time constraints

  43. Scheduling Phase Scheduling

  44. Scheduling Phase (cont’d) • To ensure feasibility of a system • Low-Power Quasi-Dynamic Scheduling (LQS) • Generate Power-Aware Real-Time Petri Net models from UML sequence diagrams • Decompose into computations • Statically schedule each computation to satisfy • Time (local deadlines, global deadlines, periods) • Memory • Energy (I/O device, microprocessor) • Task precedence relationships

  45. Scheduler Generation Phase Scheduler Generation

  46. Scheduler Generation Phase (cont’d) • To ensure the generated application follows the scheduling result (static LQS schedules) • Scheduler • Generated from the scheduled task sequence • Two forms: • An extended timed automata (for verification) • Communications among the system ETA models • A piece of software code (for code generation) • Schedules and dispatches object tasks • Implementations: SST, TinyOS (sensor network)

  47. Formal Verification Phase Verification

  48. Formal Verification Phase (cont’d) • To ensure the functional correctness of the generated real-time embedded software • Model Checker: State Graph Manipulators (SGM) • System Model • A set of ETA translated from UML statecharts • A scheduler ETA generated by scheduling sequence diagrams • System Properties • TCTL formulas translated from UML/OCL specifications • Counterexample • A sequence diagram from ETA counterexample (computation run)

  49. Hardware Architecture Mapping Phase Architecture Mapping

  50. Hardware Architecture Mapping Phase (cont’d) • Reusable component models • Drivers, library modules, object files • Functional: state diagrams, … • For verification • Non-functional: response time, transfer rate, … • For scheduling • Portable generic interface for components • init(), reset(), read(), write()

More Related