modeling of embedded system behavior
Download
Skip this Video
Download Presentation
Modeling of Embedded System Behavior

Loading in 2 Seconds...

play fullscreen
1 / 113

Modeling of Embedded System Behavior - PowerPoint PPT Presentation


  • 100 Views
  • Uploaded on

Modeling of Embedded System Behavior. EE298-2 (Fall 2000): Lecture #2 October 3, 2000. Reading. Required [Sgroi00] Sgroi, M.; Lavagno, L.; Sangiovanni-Vincentelli, A. Formal models for embedded system design. IEEE Design & Test of Computers, vol.17, (no.2), IEEE, April-June 2000. p.14-27.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Modeling of Embedded System Behavior' - zofia


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
modeling of embedded system behavior

Modeling of Embedded System Behavior

EE298-2 (Fall 2000): Lecture #2October 3, 2000

reading
Reading
  • Required
    • [Sgroi00] Sgroi, M.; Lavagno, L.; Sangiovanni-Vincentelli, A. Formal models for embedded system design. IEEE Design & Test of Computers, vol.17, (no.2), IEEE, April-June 2000. p.14-27.
    • [Douglass98] Douglass, B.P. State machines and statecharts. Embedded Systems Conference West, 1999. http://www.ilogix.com/dev/SMS.zip
    • Cynapps Cynlib documentation (will need for HW #2)http://chronos.cynapps.com/cgi-bin/download/lrm-index.pl
  • Recommended
    • [Harel97] Harel, D.; Gery, E. Executable object modeling with Statecharts. IEEE Computer, July 1997. p. 31-42.
    • [Edwards97] Edwards, S.; Lavagno, L.; Lee, E.A.; Sangiovanni-Vincentelli, A. Design of embedded systems: formal models, validation, and synthesis. Proceedings of the IEEE, vol.85, (no.3), IEEE, March 1997. p.366-90.
how to design embedded systems wescon 1975
How to Design Embedded Systems? (Wescon 1975)
  • “...deliberately avoid data processing aides such as assemblers, high-level languages, simulated systems, and control panels. These computer-aided design tools generally get in the way of cost-effective design and are more a result of the cultural influence of data processing, rather than a practical need.”
  • “It’ s my observation that the bulk of real-world control problems require less than 2,000 instructions to implement. For this size program computer aided design does little to improve the design approach and does a lot to separate the design engineer from intimate knowledge of his hardware.”
methodical design of embedded systems
Methodical Design of Embedded Systems
  • Ad hoc approach to design does not work beyond a certain level of complexity, that is exceeded by vast majority of embedded systems
  • Methodical, engineering-oriented, CAD tool-based approach is essential
      • specification, synthesis, optimization, verification etc.
      • prevalent for hardware, still rare for software
  • One key aspect is the creation of models
      • concrete representation of knowledge and ideas about a system being developed
      • model deliberately modifies or omits details (abstraction) but concretely represents certain properties to be analyzed, understood and verified
      • One of the few tools for dealing with complexity
abstractions and models
Abstractions and Models
  • Foundations of science and engineering
  • Activities usually start with informal specification
  • However, soon a need for Models and Abstractions is established
  • E.g.: Chess and Poker - No Rules, No Games
  • Connections to Implementation (EE & Hardware) and Application (CS & Software)
  • Two types of modeling: system structure and system behavior
good models
Good Models
  • Simple (Ptolemy vs. Galileo)
  • Amenable for Development of Theory
  • Has High Expressive Power (A game is interesting only if it has some level of difficulty)
  • Provides Ability for Critical Reasoning (Science vs. Religion)
  • Practice is currently THE only serious test of model quality
  • Executable
  • Synthesizable
elements of a model of computation language
Elements of a Model of Computation: Language
  • A language is a set of symbols with superimposed syntax and semantics
    • text-based, visual
  • Syntax: Rules for combining symbols
    • well structured, intuitive
  • Semantics: Rules for assigning meaning to symbols and combinations of symbols
    • without a rigorous semantic definition, precise model behavior over time is not well defined
      • full executability and automatic h/w or s/w synthesis is impossible
semantics and model of computation
Semantics and Model of Computation
  • Operational Semantics (Turing Machine): Which action can be taken by fully defined abstract machine
  • Denotational Semantics (Scott & Strachey): Meaning is defined in terms of relations
  • Model of Computation: How the machine can behave or what types of relationship are possible; May include communication style, aggregation, hierarchy, ...
design and model of computation
Design and Model of Computation
  • A design is a system of atomic components
  • The model of computation defines the behavior and interaction of atomic components
  • Model Generality / Efficiency of Design Trade-off
  • Models are easy to define; It is difficult to see their limitations and eventual Effectiveness
classical cs models for general purpose computing
Classical CS: Models forGeneral-Purpose Computing
  • Turing Machine, Post Machine, Universal Register Machine
  • RAM (von Neuman) => Algorithms and Computational Complexity
      • Algol, FORTRAN, Lisp, C, C++
  • CSP - Communicating Sequential Processes - C.A.R. Hoare
  • CCS - Calculus of Communicating Systems - R. Milner
behavior modeling for embedded systems
Behavior Modeling for Embedded Systems
  • Function: what does the system do
      • in non-real-time systems, this is sufficient
  • Time: meet temporal contract with the environment
      • temporal behavior important in real-time systems, as most embedded systems are
      • simple metric such as throughput, latency, jitter
      • more sophisticated quality-of-service metrics

Computation model must support description of both functional and temporal behavior

structure modeling for embedded systems
Structure Modeling for Embedded Systems
  • Embedded systems often have complex high-level run-time structures
      • e.g. redundancy structure in a fault-tolerant system
      • represent the “architecture core”
  • Topological relationship between individual entities or objects
      • Peer relationships between communicating objects
      • Containment relationships
      • Layering relationships
  • Dynamic run-time structures
infrastructure modeling for embedded systems
Infrastructure Modeling for Embedded Systems
  • ES are more constrained than general-purpose systems
      • e.g. need for timeliness, low-power etc.
  • Models must allow for early and accurate predictions of key attributes of the actual systems
      • response times, throughput, availability etc.
      • finite capacities of underlying computing resources
      • many techniques developed over the years
          • schedulability analysis, queuing theory
  • Need to model not only the behavior and structure of the computation, but also the engineering infrastructure
      • physical devices: processors, networks, busses etc.
      • logical devices: tasks, locks, queues, OS services etc.
  • Resource modeling essential both for accuracy and for systems with application-defined resource management
popular computation models for embedded systems
Popular Computation Models for Embedded Systems
  • Communicating Finite State Machines
  • Synchronous / Reactive
  • Dataflow
  • Process Networks
  • Rendezvous-based Models (CSP)
  • Petri Nets
  • Tagged-Signal Model
  • Object-oriented Models
  • Heterogeneous Models
graphs as an abstract syntax for models
Graphs as an Abstract Syntax for Models
  • Graph =
  • Many computation models are obtained by ascribing specific interpretations (semantics) to the nodes and arcs, and sometimes by constraining the structure of the graph
      • e.g.: Petri nets, Data flow, FSM
  • Hierarchical graphs offer a useful visual representation
finite state machines
Finite State Machines
  • FSM is a mathematical model of a system that attempts to reduce model complexity by assuming:
      • system can be in a finite # of conditions called states
      • system behavior within a given state is essentially identical
      • system resides in states for significant periods of time
      • system may change states only in a finite # of well-defined ways, called transitions
      • transitions are the response of the system to external or internal events
      • Functions or operations called actions my be executed when the transition is taken, a state is entered, or a state is exited
        • implemented by an internal or external datapath or object’s operations
      • transitions and actions take (approximately) zero time, i.e. instantaneous
        • “synchronous”
      • events not permitted in a state are ignored or result in error or queued
  • FSM = (Inputs, Outputs, States, InitialState, NextState, Outs)
  • Often suitable for controllers, protocols etc.
  • Not Turing Complete, but more amenable to analysis
  • Rarely suitable for Memory and Datapaths
more complex fsm
Source: B. P. Douglass & iLogixMore Complex FSM
  • Reliable transmission service for a protocol stack
  • A message is sent that requires thereceiver to ACK
  • If an ACK doesn’t occur, retransmit
  • If the message is transmitted 5 times without ACK, inform the sender
fsm example
FSM Example
  • Informal specification

if driver turns on the key and does not fasten seat belt within 5 seconds then sound the alarm for 5 seconds or until driver fastens the seat belt or turns off the key

  • Formal representation

Inputs = {KEY_ON, KEY_OFF, BELT_ON, BELT_OFF, 5_SECONDS_UP, 10_SECONDS_UP

Outputs = {START_TIMER, ALARM_ON, ALARM_OFF}

States = {Off, Wait, Alarm}

Initial State = off

NextState: CurrentState, Inputs -> NextState

e.g. NextState(WAIT, {KEY_OFF}) = OFF

Outs: CurrentStae, Inputs -> Outputs

e.g. Outs(OFF, {KEY_ON}) = START_TIMER

non deterministic fsm
Non-Deterministic FSM
  • A FSM is said to be non-deterministic when the NextState and Outs functions may be RELATIONs (instead of functions)
  • Non-determinism can be user to model
      • unspecified behavior
          • incomplete specification
      • unknown behavior
          • e.g., the environment model
      • abstraction
          • (the abstraction may result in insufficient detail to identify previously distinguishable situations)
mealy moore fsms
Source: B. P. Douglass & iLogixMealy-Moore FSMs
  • The set of states define the state space
  • State space are flat
    • all states are at the same level of abstraction
    • all state names are unique
  • State models are single threaded
    • only a single state can be valid at any time
  • Mealy state models: all actions are in transitions
  • Moore state models: all actions are upon state entry
problems with conventional fsm
Source: B. P. Douglass & iLogixProblems with Conventional FSM
  • Scalability due to lack of metaphor for decomposition
  • No concurreny support
  • No support for orthogonal connections
concurrency
Source: B. P. Douglass & iLogixConcurrency
  • Problem:
    • a device can be in states
      • Off, Starting-up, Operational, Error
    • And, can be running from
      • mains, battery
  • How to arrange these states?
concurrency1
Source: B. P. Douglass & iLogixConcurrency
  • Following are different states in Mealy/Moore view:
    • Operation with battery
    • Operation with mains
  • Leads to state explosion
  • Solution?
    • Allow states to operate concurrently
orthogonal components
Source: B. P. Douglass & iLogixOrthogonal Components

How do you draw the state of this object?

harel s statecharts extension of conventional fsms
Harel’s StateCharts: Extension of Conventional FSMs
  • Conventional FSMs are inappropriate for the behavioral description of complex control
      • flat and unstructures
      • inherently sequential in nature
      • give rise to an exponential blow-up in # of states
          • small system extensions cause unacceptable growth in the number of states to be considered
  • StateCharts support:
      • repeated decomposition of states into AND/OR sub-states
        • nested states, concurrency, orthogonal components
      • actions (may have parameters)
      • activities (functions executed as long as state is active)
      • guards
      • history
      • a synchronous (instantaneous broadcast) comm. mechanism
features of statecharts
Features of StateCharts
  • Nested states and hierarchy
    • Improves scalability and understandability
    • helps describing preemption
  • Concurrency - two or more states can be viewed as simultaneously active
  • Nondeterminism - there are properties which are irrelevant
state decomposition
State Decomposition
  • OR-states have sub-states that are related to each other by exclusive-or
  • AND-states have orthogonal state components (synchronous FSM composition)
      • AND-decomposition can be carried out on any level of states
          • more convenient than allowing only one level of communicating FSMs
  • Basic States: no sub-states (bottom of hierarchy)
  • Root State: no parent states (top of hierarchy)
statechart or decomposition
e

S

f

V

g[c]

f

T

h

StateChart OR-decomposition

U

e

S

V

f

g[c]

T

h

statechart and decomposition
StateChart AND-decomposition

V,W

h

k

U

g

V,Z

S

T

Z

V,Y

k

V

e

m,p

e

e

g

W

f

h

e

f

[in(Y)]

g

X,Z

X,Y

Y

X

m

e

e

k

h

X,W

e

p

p

e

n

n

p

m,p

R

Q

R

Q

p

statecharts syntax
StateCharts Syntax
  • The general syntax of an expression labeling a transition in a StateChart is n[c]/a, where
      • n is the event that triggers the transition
      • c is the condition that guards the transition(cannot be taken unless c is true when e occurs)
      • a is the action that is carried out if and when the transition is taken
  • Alternative: name(params)[guards]^event_list/action_list
      • Event list, aka propagated transitions, is a list of transitions that occur in other concurrent state machines because of this transitions
  • For each transition label, event condition and action are optional
      • an event can be the changing of a value
      • standard comparisons are allowed as conditions and assignment statements as actions
statecharts actions and events
StateCharts Actions and Events
  • An action a on the edge leaving a state may also appear as an event triggering a transition going into an orthogonal state
      • executing the first transition will immediately cause the second transition to be taken simultaneously
  • Actions and events may be associated to the execution of orthogonal components:
      • action start(A) causes activity A to start
      • event stopped(B) occurs when activity B stops
      • entered(S), exited(S), in(S) etc.
order of nested actions
Source: B. P. Douglass & iLogixOrder of Nested Actions
  • Executed from outermost – in on entry
  • Executed from innermost – out on exit
history
Source: B. P. Douglass & iLogixHistory
  • The history annotation H means that the state “remembers” the substate and returns to it as the default
  • Can also work with an initial state indicator
another example of the power of statechart formalism
Another Example of the Power of StateChart Formalism

reset/

Uninitialized

ackB/

  • Conflicting function & control behaviors
      • Function: primary service of the entity
      • Control: actions performed within the system context
  • Solutions: single automaton, two peer concurrent states

ReadyToSendA

send/^A

reset/

data/

data/

Initialized

Error

SendingA

SendingB

stop/

start/

Operational

ReadyToSendB

error/

send/^B

ackA/

the combined state machine in statechart formalism
The Combined State Machine in StateChart Formalism

reset/

Uninitialized

reset/

data/

data/

Initialized

Error

stop/

start/

Operational

error/

ackB/

ReadyToSendA

send/^A

SendingA

SendingB

ReadyToSendB

send/^B

ackA/

concurrent statecharts
Source: B. P. Douglass & iLogixConcurrent Statecharts
  • Many embedded systems consist of multiple threads, each running an FSM
  • State charts allow the modeling of these parallel threads
concurrent statecharts1
Source: B. P. Douglass & iLogixConcurrent Statecharts
  • States S and T are active at the same time as long as X is active
    • Either S.A or S.B must be active when S is active
    • Either T.C, T.D or T.E must be active when T is active
concurrent statecharts2
Source: B. P. Douglass & iLogixConcurrent Statecharts
  • When X exits, both S and T exit
    • If S exits first, the FSM containing X must wait until T exits
    • If the two FSMs are always independent, then they must be enclosed at the highest scope
communication in concurrent fsms
Communication in Concurrent FSMs
  • Broadcast events
    • Events are received by more than one concurrent FSM
    • Results in transitions of the same name in different FSM
  • Propagated transitions
    • Transitions which are generated as a result of transitions in other FSMs
graphical hierarchical fsm languages
Graphical Hierarchical FSM Languages
  • Several commercial & non-commercial variants
      • StateCharts, VisualHDL, SpecCharts, SpeedChart, StateVision, etc.
  • Easy to use in control dominated systems
  • Simulation, S/W and H/W synthesis
  • Extended with arithmetic
raphsody statemate etc by i logix
Raphsody, StateMate etc.by i-Logix
  • Set of tools for development of complex reactive systems
      • heavy graphical orientation
      • captures system behavior using StateCharts
      • rigorous executions and simulations
      • create run-time code for rapid-prototyping
  • Key features:
      • executable and analyzable specifications
      • visual formalisms
co design finite state machines cfsms
Co-design Finite State Machines (CFSMs)
  • Underlying model of computation for Berkeley’s POLIS system for H/W-S/W synthesis
  • Combines aspects of several other models
      • FSM extended with support for data handling and asynchronous communications
          • FSM part: I/O, states, transition & output relation
          • Data computation part: external, instantaneous functions without side effects
  • Mixes
      • synchronicity: zero & infinite delay
      • Asynchronicity: non-zero, finite, & bounded delay
  • Embedded systems have both aspects
network of cfsms
Network of CFSMs
  • Interacting CFSMs that communicate through a very low-level primitive: events
  • Broadcast communication model
      • a CFSM, or its environment, emits events
      • one or more CFSMs or the environment can later detect it
  • GALS: globally asynchronous, locally synchronous
      • contrast: in concurrent FSMs, all FSMs change states exactly at the same time
          • does not work in S/W with interleaved FSMs
communication primitives
Communication Primitives
  • Events implement a communication protocol that does not require acknowledgment
      • receiver waits for sender to emit event
      • sender can proceed immediately after emission
      • implicit one-place buffer between the sender and receiver saves the event until it is detected or overwritten
          • efficient H/W implementation with synchronous circuits, and S/W implementation using polling or interrupts
  • Handshake, if needed, modeled using events
more on events
More on Events
  • Sender does not remove the event immediately after sending it, only when emitting the next one
  • Each CFSM can detect an event at most once any time after the event’s emission, until another event of the same type overwrites it
      • event can be correctly received even with the unpredictable reaction time associated with S/W implementations
      • correct reception is ensured as long as
          • sender date rate < receiver processing ability
          • or, explicit synchronization is done
generalization to signals
Generalization to Signals
  • Signals carry information in the form of events and/or values
      • Event signals: present/absent
      • Data signals: arbitrary values
          • event, data may be paired
  • 1 input buffer / signal /receiver
  • Signal is emitted by sender (by setting buffer)
  • Consumed by receiver (by resetting buffer)
  • “Present” if emitted but not consumed
example cfsm specification
Example CFSM Specification

Wait

  • State of a CFSM includes those events that are at the same time input and output for it
      • non-zero reaction time implies storage capability

*Key = On  *Start

*End=5  *Alarm = On

*Key = Off or

*Belt = On 

Off

Alarm

*End=10 or

*Belt = On or

*Key = Off 

*Alarm = Off

discrete events
Discrete Events
  • Notion of time is fundamental
  • Events are objects which [usually] carry ordered time information
  • There is a casual relationship between events
  • Verilog and VHDL
  • Expensive - ordering tame stamps can be time consuming
  • Large state & Low Activity => Effective simulation
  • Simultaneous Events require complete conflict resolution schemes
reactive synchronous models
Reactive Synchronous Models
  • Assumptions
      • system reacts to internal and external events by emitting other events
      • events can only occur at discrete time steps
      • reactions are assumed to be instantaneous
          • negligible or relatively small time to process event
          • if processing is significant, start and end events can be associated with the tasks
  • Synchronous languages
      • Imperative: Estrel
      • Dataflow: Lustre, Signal, Argos
  • Simple and clean semantics (FSM based), deterministic behavior, and lots of CAD tools
esterel
Esterel
  • Describes collection of FSMs
  • Imperative syntax
      • S1;S2 executes in sequence
      • S1 || S2 in parallel
      • [S1||S2] in parallel until both terminate
  • Succinct specification of interrupts
      • do watching
          • the is executed until either it terminates, or the occurs
  • As the number of signals to watch increases, the size of the Esterel program grows linearly, while the FSM complexity grows exponentially
esterel example
Esterel Example

module EsterelFSMinput A, B, R;output O;loop do [await A || await B]; emit O; halt; watching Rend loop

end module;

flow graph models
Flow Graph Models

Control/Data

Flow Graph

Implementation

2

3

2

...

2

1

1

...

Reg

Reg

Multiplier

x

4

3

2

...

D

+

Reg

Reg

4

7

9

...

Adder

0

4

7

...

synchronous data flow
Synchronous Data Flow

+

-

x

x

+

-

D

D

+

-

x

x

x

x

+

-

x

x

what latency sample period can a sdfg achieve
What Latency & Sample Period can a SDFG achieve?

x

y

+

+

  • TL = max(I-O path, D-O path)
  • TS = max(D-D path, I-D path)

D1

Longest Path for T

L

T

= 2m + 3

L

+

+

D2

Longest Path for T

S

T

= m + 2

S

cdfg can be transformed to affect t l t s
CDFG can be Transformed to Affect TL & TS

Longest Path for T

L

T

= m + 2

L

x

y

+

+

S1

S3

+

+

Longest Path for T

S

S2

S4

T

= m + 2

S

dataflow process networks
Dataflow Process Networks
  • Graph: Nodes (actors) are computations, edges (arcs) are ordered sequences of events (tokens)
  • Kahn process network is generalization where unbounded FIFO buffering is available
  • Firing - quant of computation
  • Karp-Miller computation graphs, Lee-Messerschmidt's synchronous SDF, ...
modeling in hardware asic design
Modeling in Hardware (ASIC) Design

Algorithm

C/C++/Matlab/Java etc.

Gap ???

RTL

Verilog, VHDL

RTL synthesis

netlist

Verilog, Edif

layout

Physical

GDS-II

cost of the disconnect between system hardware design
Cost of the Disconnect between System & Hardware Design
  • Tools
    • Separate suite of tools in both environments
  • Knowledge
    • Lose information when starting over in HDL
  • Design Time
    • Starting from scratch (e.g. VHDL or Verilog) and hope that it produces the same behaviour as the original architecture model
    • Separate testbenches/verification efforts
solution approaches
Solution Approaches
  • Approach #1: do hardware RTL design in the same languages as system design (C/C++/Java)
    • Over 50% of today’s designs begin with architecture modeling in C/C++
    • Iteratively refine to RTL C/C++
    • Synthesize RTL C/C++ to Verilog/VHDL
    • System-C, Cynapps etc.
  • Approach #2: use formal languages for system modeling (SDL, UML etc.), and synthesize VHDL/Verilog RTL design via behavioral synthesis
  • Comment: VHDL (unlike Verilog) can model at higher levels than RTL, but the computation model is too rich for synthesis tools to handle
emerging c c based unified design environments
Emerging C/C++-based Unified Design Environments
  • The hope is that they will allow
    • System/Algorithm Modelling
    • Software Design
    • Hardware Design

…to be done in the same language

example cynapps s c cynlib
Example: CynApps’s C++/Cynlib
  • http://www.cynapps.com
  • Open source C++ library (Cynlib) for RTL modeling and simulation
  • Tools are not free
modeling approaches based on software design methods
Modeling Approaches based on Software Design Methods
  • No systematic design in 60s
  • From 70s, many different s/w design strategies
      • Design methods based on functional decomposition
          • Real-Time Structured Analysis and Design (RTSAD)
      • Design methods based on concurrent task structuring
          • Design Approach for Real-Time Systems (DARTS)
      • Design methods based on information hiding
          • Object-Oriented Design method (OOD)
      • Design methods based on modeling the domain
          • Jackson System Development method (JSD)
          • Object-Oriented Design method (OOD)
object oriented design methods
Object-Oriented Design Methods
  • Based on three essential concepts
      • abstraction
          • separate specification from internal body
      • information hiding
          • structuring to decide what information is hidden
      • inheritance
          • relationship among classes where a child class can share the structure and operations of a parent class and adapt it for its own use
object oriented modeling languages uml
Object-Oriented Modeling Languages: UML
  • What is UML?

“a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems”

-- Object Management Group, Inc. (OMG)

  • In Essence:a tool used through the analysis and design phases of system development for expressing the constructs and relationships of complex systems
uml goals
UML Goals

1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models

2. Provide extensibility and specialization mechanisms to extend the core concepts.

3. Be independent of particular programming languages and development processes.

4. Provide a formal basis for understanding the modeling language.

5. Encourage the growth of the Object-Oriented tools market.

6. Support higher-level development concepts such as collaborations, frameworks, patterns and components.

7. Integrate best practices.

history origins
History & Origins
  • Mid 1970s -1980s: Object-Oriented methodology and modeling languages
  • Mid 1990s: 2nd Generation - Booch method, Object Modeling Technique (OMT), Object-Oriented Software Engineering(OOSE)
  • 1994-95: Grady Booch, Jim Rumbaugh, Ivan Jacobson join forces to unify methods
  • OMG push for standardization
  • January 1997: UML 1.0 Definition
languages for modeling
Languages for Modeling
  • Languages have long been used for modeling hardware
      • VHDL, Verilog
  • Also, in specific domains
      • SDL in telecommunication systems
  • UML achieves that for software-oriented complex system modeling
language based hardware design
Language-based Hardware Design
  • Language-level “model” of hardware
      • create a functional fascimile of the target circuit
      • models can be simulated, analyzed, synthesized.
  • Language-level “design” of hardware
      • create a functional implementation of the target circuit
          • translation of functional implementation into a gate-level circuit is well defined.
  • HDL thesis:
      • (Relevant) executable models can be refined into a gate-level implementation under designer control
      • structured as data and control refinement.
why uml and why oo for real time embedded systems
Why UML (and Why OO) for Real-time Embedded Systems?
  • UML is application independent
  • Correspondence between analysis and design views
  • Improved stability in the presence of changes
  • Easier reuse
  • Improved scalability - less coupling
  • Better support for reliability + safety concerns
  • Inherent support for concurrency - objects
major features of uml
Major Features of UML
  • Object model
  • Use cases and scenarios
  • Behavioral modeling with statecharts
  • Packaging of various kinds of entities
  • Representation of tasking and task synchronization
  • Models of physical topology
  • Models of source code organization
  • Support for object-oriented patterns
visual modeling in uml set of diagrams
Visual Modeling in UML: Set of Diagrams
  • Context diagram
      • an UML object diagram
  • Use Case diagram
  • Scenarios
      • Sequence Diagram, Collaboration Diagram
  • Class diagram
  • Message Trace
  • Behavior Modeling
  • Models of Architecture and Patterns

How do these model aspects ofReal-Time Systems?

requirements analysis context diagrams
Requirements Analysis: Context Diagrams

Arrhythmia

Alarm

  • System interaction with objects in the external environment
  • Messages
      • data content, arrival patterns, synchronization patterns
  • External event list

Physician

EKG

Monitor

Heart Activity

Remote

Display

Patient

use cases
Use Cases
  • General cases of interaction among the system and external objects
      • provide another view of system context
  • Functional decomposition of system’s behavior without regard to the system’s internal structure
  • Describe the behavior of a set of objects
  • Group functionally related messages together into protocols
  • Protocols - obligations between objects
use cases contd
Use Cases (contd.)

Use Case 1

Actor 1

Use Case 2

Actor 4

Use Case 3

Actor 2

Use Case 4

Actor 3

scenarios or interaction diagram
Scenarios or Interaction Diagram
  • Instances of use cases
  • Model order-dependent message sequences among objects collaborating to produce system behavior
  • Different scenarios for a use case show permutations of object interactions
  • Annotated with timing constraints
  • Two scenario models
      • sequence diagrams
      • collaboration diagrams
sequence diagram vs collaboration diagram
Sequence Diagram vs. Collaboration Diagram
  • Sequence Diagram
      • shows the interactions or exchanged messages among objects
      • does not show any associations among the objects
      • the interactions are arranged in a time/life-line scale to show their progression over time
      • enhancements: “state marks” to allow following the state changes, “time marks”, broadcast messages
  • Collaboration Diagram
      • focuses on the interactions or messages among objects
      • each interaction carryies a sequence number to display its role in an ordered flow of operations
analysis defining the object structure
Analysis: Defining the Object Structure
  • After system’s external environment is defined
  • Identification of key objects and classes, and their relationships within the system
      • identify objects
      • identify object associations
      • group objects into classes
      • identify and classify class relationships
      • identify class behaviors
      • group classes into domains
      • validate classes and objects
class diagrams
Class Diagrams

Class Name

Attributes

  • Relationships Between Classes
      • Associations
      • Aggregation
      • Composition
      • Generalization (Template)
      • Refinement

Operations

Class

Class inside

analysis defining the object behavior
Analysis: Defining the Object Behavior
  • Define and refine operations and behaviors
  • Three ways of behavior modeling
      • simple behavior
          • no memory e.g. pure mathematical functions
      • state or reactive behavior
          • e.g. FSM, StateChart
      • continuous behavior
          • e.,g. digital filters
  • Scenario modeling to test behavioral models
  • State and scenario models lead to definitions of class models
modeling architecture
Modeling Architecture

Node

Name

  • physical architecture
  • mapping to physical devices
  • task diagrams - show concurrency
  • node - processor, sensors, routers, displays, input devices, memory, etc.

Subsystem

Package

Subsystem

and Package

Package

Active

Object

Task

architectural patterns
Architectural Patterns

Master-Slave

Pattern

Master

Slave

Coprocessor

Controller

+ Sequence Diagram

uml for real time
UML for Real-Time
  • Uses standard UML and Real-Time Object-Oriented Modeling Language (ROOM)
  • Principal Constructs: Capsules; Ports; Protocols
  • Capsules - objects that interact with surroundings
  • Ports - interface object; physical part of implementation of a capsule; implements behavior defined by protocols
  • Relay Ports - connected to sub-capsules; let all signals pass through
uml for real time contd
UML for Real-Time (contd.)
  • End Ports - connected to the capsule’s state machine; where connectors terminate and communicate with state machine
  • Protocols - rules, formats, and procedures agreed upon by object wanting to communicate
  • Connectors - abstract views of signal-based communication channels ; modeled by associations
modeling the engineering infrastructure in uml
Modeling the Engineering Infrastructure in UML
  • Resources can be modeled by appropriate stereotypes of Class and Node
  • Resources “support” logical elements
      • A logical element may require multiple rsources
  • Resources can be viewed as servers with service interfaces
      • operations of QoS (quality of service) attributes with numerical values e.g. latency, energy
  • Similar approach for OS services
  • Element-to-resource mapping
      • relate logical model to a particular hardware configuration
  • Resource-to-value mapping
      • Attribute values for resources of an implementation machine
references for uml
References for UML
  • Bruce Douglass, “Real-Time UML - Developing Efficient Objects for Embeded Systems,” Addison-Wesley, 1998.
  • http://www.rational.com/
  • Bran Selic & Jim Rumbaugh,“Using UML for Modeling Complex Real-Time Systems,” 1998. http://www.rational.com/support/techpapers/umlrt/
  • Andrew Lyons, “UML for Real-Time Overview,” 1998. http://www.rational.com/support/techpapers/umlrt_overview
  • Grady Booch, “Quality Software and the Unified Modeling Language.” http://www.rational.com/support/techpapers/soft_uml.html
  • http://www.omg.org/news/pr97/umlprimer.html
  • http://spider.ipac.altech.edu/~brundage/presents/uml/index.html
  • http://www.jr-and-assoc.demon.co.uk/uml_int.htm
how models influence an application design
How Models Influence an Application Design?
  • Example: given input from a camera, digitally encode it using MPEG II encoding standards.
      • this task involves: storing the image for processing going through a number of processing steps, e.g., Discrete cosine transform (DCT), Quantization, encoding (variable length encoding), formatting the bit stream, Inverse Discrete Cosine transform (IDCT), ...
  • Is this problem appropriate for
      • Reactive Systems, Synchronous Data flow, CSP, ...
  • More than one model be reasonable.
choice of model
Choice of Model
  • Model Choice: depends on
      • application domain
          • DSP applications use data flow models
          • Control applications use finite state machine models
          • Event driven applications use reactive models
      • efficiency of the model
          • in terms of simulation time
          • in terms of synthesized circuit/code.
  • Language Choice: depends on
      • underlying semantics
          • semantics in the model appropriate for the application.
      • available tools
      • personal taste and/or company policy
ad