1 / 54

Using the UML Profile for Schedulability, Performance and Time

Using the UML Profile for Schedulability, Performance and Time. Bruce Powel Douglass, Ph.D. Chief Evangelist I-Logix, Inc. www.ilogix.com bpd@ilogix.com. About the Author. 20++ years in safety-critical hard-real time systems

tomv
Télécharger la présentation

Using the UML Profile for Schedulability, Performance and Time

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. Using the UML Profile for Schedulability, Performance and Time Bruce Powel Douglass, Ph.D. Chief Evangelist I-Logix, Inc. www.ilogix.com bpd@ilogix.com

  2. About the Author • 20++ years in safety-critical hard-real time systems • Mentor, trainer, consultant in real-time and object-oriented systems • Author of • Real-Time UML 2nd Edition: Efficient Objects for Embedded Systems (Addison-Wesley, Dec. 1999) • Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns (Addison-Wesley, 1999) • Advisory Board • Embedded Systems Conference • UML World Conference • Software Development Magazine • UML World Advisory Board • Co-chair of OMG RTAD Work Group

  3. Collaborators • This work is a collaborative development effort by a number of companies and individuals. They include (primary contact, in alphabetical order by company) • Alan Moore (Artisan Software Tools, Inc.) • Bruce Douglass (I-Logix Inc.) • Bran Selic (Rational Software Corporation, Inc.) • Morgan Bjorkander (Telelogic AB) • Mark Gerhardt (Timesys Corporation) • Ben Watson (TriPacific Software)

  4. Agenda • What’s a Profile and Why Do I Care? • Overview of the RT Profile Submission • General Resource Model • Models of Time • Concurrency Model • Schedulability Model • Ongoing Work • Using the Profile • Work ongoing in the OMG

  5. What’s A Profile and Why Do I Care?

  6. UML Profiles • A UML Profile is a specialized subset of the UML that • Is consistent with the UML specification • May be constrained to omit portions of the UML or constrain how it is used • May include custom or specialized notation • Applies to a vertical market or application domain • Extends or specializes the UML using the “lightweight extension mechanisms” • Stereotypes • Tagged Values • Constraints

  7. The “RT UML” Profile • Submitted in response to an OMG RFP • RFP for a UML Profile for Schedulability, Performance, and Time (OMG document ad/99-03-13). • RFP generated by the Real-Time Analysis and Design Working Group (RTAD) within the OMG • Submitters (in alphabetical order): • Artisan Software Tools, Inc. • I-Logix Inc. • Rational Software Corporation, Inc. • Telelogic AB • Timesys Corporation • TriPacific Software

  8. Goal of the RT Profile Note: The UML is considered to be fully adequate to model real-time and embedded systems. The profile is NOT necessary to make UML applicable to real- time systems. • RFP calls for “proposals for a UML profile that defines standard paradigms of use for modeling of time-, schedulability-, and performance-related aspects of real-time systems” • Define some standard means to capture real-time modeling concerns • Permit exchange of model information between tools, e.g. • Between design automation tools • Between design automation and schedulability tools • Facilitate communication of design intent among engineering staff and other stakeholders

  9. Guiding Principles • Do not change the UML unless absolutely required • Do not limit the way UML is used. • Provide the ability to annotate a UML model to allow for [quantitative] analysis in a standard way. • Do not require a deep understanding of applicable analysis techniques, e.g. • Rate monotonic analysis • Queuing theory

  10. (More) Guiding Principles • Simple analysis should be simple to do. More complex analysis may require more work. • Support, but do not restrict modeling to existing techniques. • E.g. RMA, DMA • Automated tools should be able to influence the UML model. • E.g. update priorities of task threads so that they become schedulable • Support both model analysis and synthesis

  11. Using the RT Profile

  12. Overview of the RT Profile Submission

  13. Response to the RFP • RFP was issued by the OMG in March, 1999 • A consortium of companies formed to respond to the submission • The response has been adopted by the OMG in 2001

  14. General Approach • Use light-weight extensions to add standard modeling approaches and elements • Stereotypes, e.g. resources • Tagged values, e.g. QoS properties • Divide submission into sub-profiles to allow easier comprehension and usage of relevant parts

  15. RT Profile Structure Technology-specific subprofiles Required by virtually ALL real-time systems

  16. One person’s abstraction is another’s Concretization • Models can always be viewed at multiple levels of abstraction • Analysis may be need to be done at anyor all of these levels of abstraction • There is intrinsic difficulty in maintaining consistency among different levels of abstraction

  17. Abstraction Levels {period = 100ms; Execution time = 10ms; Priority = 3; Deadline = 100ms; } DisplayData Task {Execution time = 3 ms; Deadline = 25ms; } {Execution time = 1.5 ms; Deadline = 20ms; } {Execution time = 1 ms; Deadline = 5 ms; } DisplayData Task Waveform View FilterPolicy draw scroll filter Sensor Waveform Queue acquire {Execution time = 4 ms; Deadline = 40ms; } put get {Execution time = 0.5 ms; Deadline = 5ms; } {Execution time = 0.5 ms; Deadline = 5ms; }

  18. General Resource Model

  19. Basic Concepts Of the GRM • Resource: a model element that has some finite properties • reflects some finite physical quantity • may be logical (e.g., buffers) or physical • resources offer services (client-server model) • need to quantify the demand/supply of services • Quality of Service (QoS): limitations on services offered by a resource. • a (usually quantitative) specification of: • the level of service required by a client from a resource or • the level of service offered by a resource to its clients

  20. GRM (Static Form) • A somewhat simplified view of the relations between resources and clients of those resources • Allows general, but not necessarily, detailed quantitative analysis, e.g. • Global RMA

  21. GRM (Static Form)

  22. Required/Offered QoS

  23. Required/Offered QoS

  24. GRM (Static Form) Example 2

  25. GRM (Static Form) Example 2

  26. GRM (Dynamic) • Takes into account the dynamic behavior for qualitative analysis • More detailed, permitting more detailed qualitative analysis

  27. GRM (dynamic form)

  28. GRM (Dynamic) Example {qosActualExecTime = 2ms} {qosActualExecTime = 4ms} 3. filterData 2. acquireData 1. sendData {qosActualExecTime = 7ms} {qosActualExecTime = 1ms} 4. packetizeData 5. transmitPacket {qosActualExecTime = 1ms}

  29. Models of Time

  30. Time Model

  31. Concurrency Model

  32. Concurrency Model

  33. Schedulability Model

  34. Schedulability Modeling

  35. Using the Profile

  36. GIGO • Select the appropriate stereotypes and tags of the schedulability model to match the kind of analysis desired • Global RMA • Elements: active objects, resources • Tags: execution time, deadline, period, priority, blocking time, priority ceiling • Detailed RMA • Elements: active objects, resources, actions, events, scenarios, scenario steps, messages • Tags: execution time, deadline, period, priority, blocking time, priority ceiling • Simulation • Depends on particular approach • etc

  37. Model Processing Paradigm UML Model Tool vendor Model Processor Modeler Delivered System Customer

  38. Model Synthesis 1 Modeler designs system to meet requirements using standard stereotypes defined in the profile 2 Modeler annotates model with QoS properties using standard tags defined in the profile depending on the kind of analysis desired, for example • Priority (e.g. SAPriority) • Worst case execution time (e.g. SAWorstCaseExecutionTime) • Period (e.g. SAPeriod) • Blocking (e.g. SABlockingTime) • Deadline (e.g. SADeadline)

  39. Model synthesis 3a Modeler submits QoS annotated model to model processor • This may be written by a schedulability analysis tool vendor and know all the defined stereotypes and tags in the profile 4a Processor munches model • Analyses model for schedulability • Identifies constraint / allocation violations • Suggests changes to QoS annotations to enhance schedulability (may automatically update model) • Marks model as schedulable or not 5a Modeler manipulates model QoS properties or model itself to make it schedulable 6a Repeat as necessary

  40. Model Synthesis 3b Modeler generates application from Model 4b Modeler tests model with test vectors (incl. QoS characteristics) 5b Modeler updates model as necessary 6b Repeat as necessary 7b Modeler delivers system to customer

  41. ROPES Approach to Using RTP Translation Testing Unit Integration Testing Testing Coding Validation Testing Detailed Iterative Design Prototypes Mechanistic Party! Design Requirements Design Analysis Architectural Design Systems Engineering Object Analysis Analysis Test interfaces among components and subsystems Refine object internal details Test functional and QoS Requirements Capture Functional & QoS requirements Refine collaborations by applying design patterns Define architecture using concurrency and other patterns Define high level architecture & HW/SW breakdown Identify semantic “analysis-level” classes to realize Use Case collaborations

  42. ROPES – Requirements Analysis • Use cases organize requirements • Two Approaches • By example • By Specification • Detailed Requirements • Functional requirements • Messages • Sequences of messages • States • Actions and activities • Transitions • Quality of Service • Constraints on any of the above • States

  43. ROPES – Systems Engineering • Optional – depends on scope of project • Defines subsystem architecture (technology independent) • For each subsystem • Define subsystem-level use cases (derived from system use cases) • Functional requirements • QoS requirements • Define inter-subsystem interfaces • Demonstrate adequacy of architecture through execution of elaborated use case scenarios • Make hw/sw decomposition to optimize QoS

  44. ROPES – Object Analysis • For each use case • Identify semantic objects collaborating together to realize the use case • Test adequacy of collaboration by elaborating use case scenarios with collaboration structure and executing them • Use propagation of constraints to decompose use case QoS requirements into performance budgets on operations, messages, states, transitions, actions, etc.

  45. ROPES – Architectural Design • Apply architectural design pattern in each of the 5 areas of architecture • Subsystem and component • Concurrency • Distribution • Safety and Reliability • Deployment

  46. ROPES – Concurrency Architecture • Identify tasks using Task Identification Strategies • Define task synchronization / scheduling mechanisms • For each task • Create an active object • Group appropriate semantic (analysis-level) objects into the active object via composition relation • Add QoS properties (priority, period,etc) • Refine scenarios via elaboration • Test concurrency model via execution of elaborated use case scenarios

  47. ROPES – Mechanistic Design • For each collaboration • Optimize collaboration against QoS by applying mechanistic design patterns

  48. ROPES – Translation • Translate UML model into source level language • Automatically (code-gen) • Manually • Combination • Link in legacy source code and components • Unit test • Functional • Operation performance budgets (QoS constraints on operations, actions, messages, etc)

  49. ROPES – Integration Test • Apply Integration Test plan • This can be started after subsystem architecture and its interfaces are known • Systems Engineering (if present) • Architectural Design • Demonstrates adherence to architectural design • Signature • Preconditions / postconditions • QoS contracts (required QoS vs offered QoS)

More Related