Using the UML Profile for Schedulability Performance and

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 Page 1

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 2 nd 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 Page 2

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 (Tri. Pacific Software) Page 3

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

Caveat This is work in progress, so any or all of the means, techniques, and elements described herein are subject to change! Page 5

What’s A Profile and Why Do I Care? Page 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 Page 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 Tri. Pacific Software Page 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 realtime 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 Page 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 Page 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 Page 11

Using the RT Profile Page 12

Overview of the RT Profile Submission Page 13

Response to the RFP • RFP was issued by the OMG in March, 1999 • A consortium of companies formed to respond to the submission • Work is ongoing • Initial (incomplete) draft of the response has been provisionally accepted by the OMG • Final submission is due June 18, 2001 Page 14

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

RT Profile Structure Required by virtually ALL real-time systems Technology-specific subprofiles Page 16

One person’s abstraction is another’s concretization • Models can always be viewed one multiple levels of abstraction • Analysis may be need to be done at any or all of these levels of abstraction • There is intrinsic difficulty in maintaining consistency among different levels of abstraction Page 17

Abstraction Levels Display. Data Task {period = 100 ms; Execution time = 10 ms; Priority = 3; Deadline = 100 ms; } {Execution time = 3 ms; Deadline = 25 ms; } {Execution time = 1. 5 ms; Deadline = 20 ms; } {Execution time = 1 ms; Deadline = 5 ms; } Display. Data Task Filter. Policy Waveform View filter draw scroll Sensor Waveform Queue acquire put get {Execution time = 0. 5 ms; Deadline = 5 ms; } {Execution time = 4 ms; Deadline = 40 ms; } Page 18

General Resource Model Page 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 (Qo. S): 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 Page 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 Page 21

GRM (Static Form) Page 22

Required/Offered Qo. S Page 23

Required/Offered Qo. S Page 24

GRM (Static Form) Example 2 Page 25

GRM (Static Form) Example 2 Page 26

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

GRM (dynamic form) Page 28

GRM (Dynamic) Example {qos. Actual. Exec. Time = 4 ms} {qos. Actual. Exec. Time = 2 ms} 3. filter. Data 2. acquire. Data 1. send. Data {qos. Actual. Exec. Time = 7 ms} {qos. Actual. Exec. Time = 1 ms} 4. packetize. Data 5. transmit. Packet {qos. Actual. Exec. Time = 1 ms} Page 29

Models of Time Page 30

Time Model Page 31

Concurrency Model Page 32

Concurrency Model (preliminary) Page 33

Schedulability Model Page 34

Schedulability Modeling Page 35

Ongoing Work Page 36

Areas being written • Concurrency model • Notational additions – Timing Diagrams • Relating RT Profile to RT CORBA • Tying together all submodels Page 37

Using the Profile Page 38

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, scenario steps, messages • Tags: execution time, deadline, period, priority, blocking time, priority ceiling – Simulation • Depends on particular approach – etc Page 39

Model Processing Paradigm Tool vendor Modeler UML Model Delivered System Model Processor Customer Page 40

Model Synthesis 1 Modeler designs system to meet requirements using standard stereotypes defined in the profile 2 Modeler annotates model with Qo. S 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. SAWorst. Case. Execution. Time) – Period (e. g. SAPeriod) – Blocking (e. g. SABlocking. Time) – Deadline (e. g. SADeadline) Page 41

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

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

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

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 Page 45

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 • Qo. S requirements – Define inter-subsystem interfaces – Demonstrate adequacy of architecture through execution of elaborated use case scenarios – Make hw/sw decomposition to optimize Qo. S Page 46

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 Qo. S requirements into performance budgets on operations, messages, states, transitions, actions, etc. Page 47

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

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 Qo. S properties (priority, period, etc) – Refine scenarios via elaboration – Test concurrency model via execution of elaborated use case scenarios Page 49

Concurrency Model Example Page 50

Example Page 51

ROPES – Mechanistic Design • For each collaboration – Optimize collaboration against Qo. S by applying mechanistic design patterns Page 52

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 (Qo. S constraints on operations, actions, messages, etc) Page 53

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 • Qo. S contracts (required Qo. S vs offered Qo. S) Page 54

ROPES – Validation Test • Tests against requirements – Known after Requirements Analysis – Use case scenarios translate into test vectors – Test Both • Functional Requirements • Qo. S requirements Page 55

Work ongoing in the OMG Page 56

Work Ongoing • An RFP is currently being written in RTAD to address non-time related Qo. S, e. g. fault tolerance, safety, reliability, etc. • Action Semantics submission should be submitted by this time • A total of 3 UML 2. 0 RFPs are released and submissions work is underway. – Infrastructure (internal metamodel stuff) – Superstructure (modeler-visible stuff) – OCL • XMI standard RFP release to include diagram and notation Page 57

Some References of Interest • Douglass, Bruce Powel Doing Hard Time: Developing Real-Time Systems With UML, Objects, Frameworks and Patterns Addison -Wesley, 1999 • Douglass, Bruce Powel Real-Time UML 2 nd Edition: Developing Efficient Objects for Embedded Systems Addison-Wesley, 1999 • OMG Documents (www. omg. org) – Response to the OMG RFP for Schedulability, Performance, and Time Version 1. 1 (OMG Document ad/2000 -08 -04) – OMG RFP for a UML Profile for Schedulability, Performance, and Time (OMG document ad/99 -03 -13) – UML 2. 0 Infrastructure RFP ( OMG Document ad/2000 -09 -01) – UML 2. 0 OCL RFP (OMG Document: ad/2000 -09 -03) – UML 2. 0 Superstructure RFP (OMG Document: ad/00 -09 -02) – OMG Unified Modeling Language Version 1. 4 Page 58