Design Of RealTime Systems Using UML

1
Design Of Real-Time SystemsUsing UML

• M.Tech., Seminar
• By
  Guided By
• Guntapudi V. Ramanaiah Prof. S.Ramesh
• School Of Information Technology,
  (CSE).
• IIT BOMBAY.

2
Motivation

• Increasing Demand Of RTS Day To Day
• Exciting Applications Of RTS
• To Familiarize To Interesting Features Of RTS
• To Face The Challenges Created By RTS
• Analyze the Complexity Of Time-Critical Tasks
• Adopting Innovative OO Modeling Language,UML
• Discuss the Fundamental Features Of UML
• Analyze and Design RTS With UML,Anesthesia
  Patient Ventilator as an Illustrative
• Drive towards the efficient OO Conceptual
  Specification Strategy,UML,To Master the
  Complexity Of RTS

3
Overview

• What is a Real-Time System?
• Controlling System and Controlled System
• Two types Hard and Soft
• Time critical tasks
• Periodic and Aperiodic
• Other Constraints
• Resource Constraints
• Precedence Constraints
• Concurrency Constraints
• Communication Constraints
• Placement Constraints
• Criticalness

4
Characteristics of RTS
Criticalness

• fast and predictable
• reliable
• adaptive
• Overview Of Current Practices in RTS
• System Considerations
• Integration and Performance issues
• Response Time
• Context Switching
• Interrupt Latency
• Data Transfer Rate

5
Emerging Principles Of RTS

• Specification,design and analysis
• Real-Time Languages
• Schedulability check
• Reusable RT s/w modules
• Support for distributed programs and fault
  tolerance

6
RTOS and DRTS

• RTOS
• Time Driven Resource management
• Problem-specific OS facilities
• Integrated System-wide Scheduling Support
• DRTS
• -can be classified as
• Heterogeneous or Homogeneous
• Centralized or Decentralized

7
Characteristics Of DRTS

• continuos operation
• Stringent Timing Constraints
• Asynchronous process interaction
• Unpredictable communication delays and race
  conditions
• Non deterministic and non operable
• Global clock reference and global state
• Multiple threads of process interaction

8
Architecture and Hardware of RTS

• Many RTS can be viewed as three-stage pipe
• data acquisition
• data processing
• output to actuators and/or displays
• Distributed system topology features
• Homogeneity
• Scalability
• Survivability
• Experimental flexibility

9
Emerging Principles Of RTS(Contd.)

• Communication in DRTS
• Fault Tolerance
• Interrupt Handling
• Features Of Scheduling
• dynamic or static
• centralized or distributed
• preemptive or non preemptive

10
UML,A New Tool For Designing Complex Systems

• A Brief Look At UML
• Conceived by Rational Group and Approved by OMG
• It is the Unification of Three Greatest OO
  Methodologists methods
• Grady Booch(Booch method),Jim Rambaugh(OTM),and
• Ivar Jacobson(OOSE and Use Case)
• It is an Industry perspective
• Problems,Solutions,and Problem Solving
• Projects
• Programs and processes
• Methods and methodologies

11
Role Of UML

• The role of UML is to enable and facilitate
• Specifying,visualizing,understanding,and
  documenting problems
• Capturing,communicating,and levering knowledge in
  problem solving
• Specifying,visualizing,constructing,and
  documenting solutions
• Problems and Solutions
• Problem Solving

12
Need For Adopting the UML

• It is a Specification Language for Complex
  systems
• The goals of UML are to
• Provide a common,expressive visual modeling for
  capturing object model semantics
• Provide a model with a formal and rigorous
  semantic basis that doesnt require too much
  formalism by the user
• Provide a metamodel which may be tailored and
  extended by the user
• Be independent of PL and development process
• Encourage the growth and maturity of the OO
  tools market

13
Why should Real-Time Embedded Developers Care?

• Objects can be made efficiently
• Better Correct than Fast
• Objects May Be Implemented In Any Language
• The Bigger the System,the More You need Objects
• Object Model A Key Feature Of OOS
• It defines the system structure by identifying
  objects and their relationships that exists
  between classes

14
UML Relationships

• GeneralizationOne class is more specialized
  version of another
• AssociationOne class uses the services of the
  another
• AggregationOne class owns another
• CompositionOne class is composed of another
• RefinementOne entity is a more refined version
  of another
• Dependency One class depends another

15
UML Notation for Multiplicities
1 One object must participate 0,1 At most one
object may participate x..y Any number of
objects may participate from x Exactly x
object(s) must participate Zero or more
object(s) may participate The syntax for
Transitions in UML is event-signature guard
/ action-list send-clause ex e1
e2 / f(x) e3 \ e4 are valid statements
16
Basic Building Blocks Of UML

• Use Cases and Use Case Diagrams
• Class Diagrams
• Sequence Diagrams
• Component Diagrams
• Deployment Diagrams
• State Chart Diagrams
• Collaboration Diagrams

17
Transitional Connectors

• Default Connector
• Terminal Connector
• History Connector
• Conditional Connector
• Complex Connector

18
Use Cases and Use Case Diagrams

• is a description of Business situation
• It describes the way in which actors interact one
  another
• eg University Information system
• Enroll students in courses
• Input student course marks
• produce student transcripts

19
Class Diagrams

• Are main aspect of OO modeling
• Also called Object Models
• Describes the Classes of System and their
  interrelationships
• Used to show that
• what system can do(analysis)
• how it is (design)
• eg Contact point analysis

20
Sequence Diagram

• Used to provide logic for Use Case scenario
• are used to validate Use Cases
• for example,
• Banking transaction system

21
Component Diagrams

• Are used to show the software components that
  make up
• a reusable piece of software
• their interfaces
• interrelationships
• For example,
• Architectural business view of telecommunication

22
Deployment Diagrams

• Show the configuration of run-time processing
  units including s/w and h/w
• Same notation as Component Diagrams
• show the components to deploy particular
  application
• for example,
• 3-tier client/server application

23
State chart Diagrams

• Are used to show how Objects work
• Represents both state and behavior
• for example,
• bank account transaction

24
Collaboration Diagrams

• Show the message flow between Objects
• It is an extension to class diagram where message
  flow is not depicted
• for example,
• University application

25
How the UML Diagrams Fit Together

• We prefer to use Collaboration diagrams to show
  asynchronous messaging between Objects
• And Sequence Diagrams for synchronous logic

26
Developing Real-Time Systems Using UML

• Why Should Embedded Developers Care?
• Increased Complexity due to critical aspects of
  RTS
• Execution speed
• Memory size
• Lack of standard notation and Design process
• Analyzing OO Systems
• A anesthesia patient ventilator as an
  illustrative
• Pressure sensor
• Volume flow sensor

27
Gasp-O-Matic Ventilator

• Having both controlled and measured parameters
• Parameters are
• Inspiratory flow rate, Expiratory flow rate,
  Respiration rate, IE ratio
• Peak pressure,Expiratory pressure
• Inspiratory O2 Concentration
• Expiratory CO2 Concentration,etc.,
• Modes Of Operation
• Ventilation mode
• Configuration mode
• Service mode

28
Requirements Analysis

• Problem Domain Come into the picture
• Discussion on What the system do,how it interacts
  with external world
• The Basic Tools Of RA are
• Use Cases
• Scenarios
• Next S/W Requirements Analysis turn
• For example,Use Case Diagram for Gasp-O-Matic is
  given by

29
A Use Case diagram for Gasp-O-Matic
30
Object Analysis

• Object Identification
• Class Diagrams
• For Gasp-O-matic ,possible strategies are
• Physical Elements
• ventilator,O2 sensor,CO2 sensor,Button,etc,.
• Visual Elements
• Visual GUI elements
• Label string
• Value string,etc.,
• Data Elements(measured or controlled)
• Transactions

31
Object Analysis(Contd.)

• Relationships
• Two kinds of associations
• Association
• Generalization
• ex.,controlled parameter
• MvTv R and IEP60/R
• Scenarios
• State charts
• Patient mode (Neonate,Pediatric,Adult)
• Breath control
• Alarm

32
Designing Real-Time Systems Using UML

• Gasp-O-Matic Design Issues
• Physical topology of processors
• Safety-criticality and reliability
• Concurrency model
• Management of collection of objects
• Resolution of logical messages into object
  operations
• State machine implementation policy
• Memory management
• A design pattern
• is a kind of design template for a solution to a
  common type of problem

33
Designing Real-Time Systems Using UML(Contd.)

• A design pattern Consists of three elements
• A common problem
• The problem context
• A general solution
• Phases Of Real-Time Systems Design
• Architectural Design
• Mechanistic Design
• Detailed Design

34
Architectural Design of the Gasp-O-matic

• The Primary Architectural Design questions are
• How many processors should be used?
• How should processors be linked together?
• What software should run on each of these
  processors?
• What kind of architectural support should we have
  to ensure patient safety?
• What kind of policies should we use to manage
  memory to avoid memory fragmentation?
• How can we ensure all deadlines are met now and
  in the future?

35
Architectural design of the Gasp-O-matic(contd.)

• Safety Architecture
• to handle time-base problem, we use
• Watchdog and Redundant processors
• Concurrency Model
• independent operation of Objects in their own
  thread of control results in inefficiency
• Need for multiple threads having small set of
  objects in each thread
• Using Preemptive scheduling

36
Contd.,

• Two strategies To group Objects into Threads
• Handling of information to/from different
  devices
• Special purpose components, such as alarm
  handling
• Global Memory Management
• Garbage collection is not practical,because it is
  non- deterministic
• Pre allocation Objects is also is not practical
• Dynamic memory allocation is problematic for
  systems that run for long periods of time,causes
  fragmentation
• Solution By using Fixed Size Block Pattern
• CommunicationUsing COB-ID,ROID and SID

37
Mechanistic Design Of the Gasp-O-matic

• The mechanistic Design issues are
• How should we manage the different 1- object
  collections?
• How can we help prevent dangling pointers and
  memory leaks as objects are created and
  destroyed?
• How should the objects that have associations
  with remote objects communicate?
• Smart Pointersprovides a simple and powerful
  programmatic mechanisms to reference

38
Detailed Design Of the Gasp-o-matic

• Detailed Design Issues
• Mapping logical messages from the analysis model
  to object operations
• Support for safety and reliability with
  visibility and encapsulation,and optimization
  with derived attributes
• Mapping Messages To Methods
• 11 approach, and single acceptor approaches
• Ensuring Data Integrity
• Ones Compliment checked data pattern
• CRC checked data pattern

39
Applications Of RTS

• Military Command and Control Systems
• Consumer Electronics
• Process control and Industrial automation
• Local and Wide area Communications
• Aerospace systems and Space Defence systems(SDI)
• Undersea Exploration and Space shuttle avionics
• Medical and Scientific Research
• Computer Graphics and CAT
• Robotics and Industrial Instrumentation
• Reservation Systems

40
Conclusions

• Many Real-Time Systems
• large and complex
• function in distributed and dynamic
• involve complex timing constraints
• To meet such challenges
• A good and efficient design methodology
  compulsory
• Since,UML is having OO perspective
• It can meet needs of complex systems like RTS
• It can provide basic OO concepts like
  Inheritance,Code-reusability,and
  Polymorphism,which are desirable features
• From this,we conclude that UML may perfectly be
  suitable for Designing RTS

41

• Thank You