Modeling of embedded system behavior
1 / 113

Modeling of Embedded System Behavior - PowerPoint PPT Presentation

  • 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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
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


  • 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.

    • Cynapps Cynlib documentation (will need for HW #2)

  • 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 = <Nodes, Arcs>

    • 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

  • Fsm examples

    Source: B. P. Douglass & iLogix

    FSM Examples



    More complex fsm

    Source: B. P. Douglass & iLogix

    More 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

    Protocol controller fsm

    Source: B. P. Douglass & iLogix

    Protocol Controller FSM

    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



      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 & iLogix

    Mealy-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

    Retrigerrable one shot timer

    Source: B. P. Douglass & iLogix

    Retrigerrable One-shot Timer

    Problems with conventional fsm

    Source: B. P. Douglass & iLogix

    Problems with Conventional FSM

    • Scalability due to lack of metaphor for decomposition

    • No concurreny support

    • No support for orthogonal connections


    Source: B. P. Douglass & iLogix


    • Problem:

      • a device can be in states

        • Off, Starting-up, Operational, Error

      • And, can be running from

        • mains, battery

    • How to arrange these states?


    Source: B. P. Douglass & iLogix


    • Following are different states in Mealy/Moore view:

      • Operation with battery

      • Operation with mains

    • Leads to state explosion

    • Solution?

      • Allow states to operate concurrently

    Mealy moore solution

    Source: B. P. Douglass & iLogix

    Mealy-Moore Solution

    Concurrent state model solution

    Source: B. P. Douglass & iLogix

    Concurrent State Model Solution

    Orthogonal components

    Source: B. P. Douglass & iLogix

    Orthogonal Components

    How do you draw the state of this object?

    Approach 1 enumerate all

    Source: B. P. Douglass & iLogix

    Approach 1: Enumerate All

    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









    StateChart OR-decomposition









    Statechart and decomposition
    StateChart AND-decomposition
















































    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 & iLogix

    Order of Nested Actions

    • Executed from outermost – in on entry

    • Executed from innermost – out on exit


    Source: B. P. Douglass & iLogix


    • 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

    Conditional transitions

    Source: B. P. Douglass & iLogix

    Conditional Transitions

    Another example of the power of statechart formalism
    Another Example of the Power of StateChart Formalism




    • 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
















    Example jolt cola machine

    Source: B. P. Douglass & iLogix

    Example: Jolt Cola Machine

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




















    Example coin receptacle fsm

    Source: B. P. Douglass & iLogix

    Example: Coin Receptacle FSM

    Substate issuing can

    Source: B. P. Douglass & iLogix

    Substate: Issuing Can

    Concurrent statecharts

    Source: B. P. Douglass & iLogix

    Concurrent 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 & iLogix

    Concurrent 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 & iLogix

    Concurrent 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

    Explicit synchronization

    Source: B. P. Douglass & iLogix

    Explicit Synchronization

    Example concurrent fsm

    Source: B. P. Douglass & iLogix

    Example Concurrent FSM

    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

    Propagations and broadcasts

    Source: B. P. Douglass & iLogix

    Propagations and Broadcasts

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


    • 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 



    *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

    • 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 <body> watching <event>

      • the <body> is executed until either it terminates, or the <event> 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


    Flow Graph































    Synchronous data flow
    Synchronous Data Flow



















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





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

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


    Longest Path for T



    = 2m + 3





    Longest Path for T



    = m + 2


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

    Longest Path for T



    = m + 2










    Longest Path for T





    = m + 2


    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


    C/C++/Matlab/Java etc.

    Gap ???


    Verilog, VHDL

    RTL synthesis


    Verilog, Edif




    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


    • 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



    • System interaction with objects in the external environment

    • Messages

      • data content, arrival patterns, synchronization patterns

  • External event list

  • Physician



    Heart Activity




    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


    • Relationships Between Classes

      • Associations

      • Aggregation

      • Composition

      • Generalization (Template)

      • Refinement



    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



    • physical architecture

    • mapping to physical devices

    • task diagrams - show concurrency

    • node - processor, sensors, routers, displays, input devices, memory, etc.




    and Package





    Architectural patterns
    Architectural Patterns







    + 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.


    • Bran Selic & Jim Rumbaugh,“Using UML for Modeling Complex Real-Time Systems,” 1998.

    • Andrew Lyons, “UML for Real-Time Overview,” 1998.

    • Grady Booch, “Quality Software and the Unified Modeling Language.”




    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