a methodology for developing industrial embedded systems an hardware software co design approach
Skip this Video
Download Presentation
A Methodology for Developing Industrial Embedded Systems: An Hardware/Software Co-Design Approach

Loading in 2 Seconds...

play fullscreen
1 / 41

A Methodology for Developing Industrial Embedded Systems: An Hardware/Software Co-Design Approach - PowerPoint PPT Presentation

  • Uploaded on

A Methodology for Developing Industrial Embedded Systems: An Hardware/Software Co-Design Approach. João Miguel Fernandes ([email protected]) Dept. Informática. U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA. 2000-Apr-07. MICEI-99/00. Outline. 1. Introduction 2. Fundamental Concepts

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 ' A Methodology for Developing Industrial Embedded Systems: An Hardware/Software Co-Design Approach' - ezra-daniel

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
a methodology for developing industrial embedded systems an hardware software co design approach

A Methodology for Developing Industrial Embedded Systems:An Hardware/Software Co-Design Approach

João Miguel Fernandes([email protected])Dept. Informática






1. Introduction

2. Fundamental Concepts

3. Analysis Issues

4. Conclusions

5. Future Work

1 introduction
1. Introduction
  • What is our R&D job?
    • Define new methodologies and architectural solutions to help systems (hardware/software) engineers to do their job, in an easier way.
  • What is our application area?
    • Industrial real-time applications demanding direct intervention in real-time control, supervision and monitoring, computer vision, robotic systems and industrial communications.
1 introduction1
1. Introduction
  • What are our main concerns?
    • Control the complexity in system design.
    • Guarantee the models’ continuity during reification stages.
    • Use non-conventional target architectures in a technologically-transparent way.
  • What are our preferable target architectures?
    • Embedded, heterogeneous, reconfigurable and distributed processing architectures.

2. Fundamental Concepts- Systems’ Characteristics -

  • State transition
  • Exceptions
  • Hierarchy
  • Concurrency
  • Distribution
  • Activity conclusion
  • Algorithmic constructions
  • Timeliness
  • Non-functional requirements
  • ...
Co-Design: Development approach that faces the problem of designing heterogeneous systems (with hw and sw components) treating both kinds of components in an equal way, allowing the iterative migration of functionalities so that functional and non-functional requirements are optimally implemented.

2. Fundamental Concepts- HW/SW Co-Design -


2. Fundamental Concepts- HW/SW Co-Design -

  • hardware/software co-design allows:
    • hw/sw functional migrations
    • interface modifications
    • hw/sw corrections
    • better design-space exploration
  • i.e.:

HW/SW co-design promotes an effective concurrent, co-operative and co-ordinated design of the hardware and software components needed for the implementation of the system.


2. Fundamental Concepts- Virtual Prototyping -

  • unified representations
  • executable specifications
  • modularity and reutilization
  • spiral process model
2 fundamental concepts waterfall lifecycle
2. Fundamental Concepts- Waterfall lifecycle -










Life cycle

2 fundamental concepts uml notation
2. Fundamental Concepts- UML Notation -
  • UML includes several diagrams that allow the description of the most relevant aspects of a system, following an object-oriented approach.
  • Each diagram focus a specific view of the system.
  • Important UML diagrams to specify and document embedded systems:
    • use cases diagrams
    • class diagrams
    • object diagrams
    • interaction diagrams
    • statechart diagrams
2 fundamental concepts uml diagrams
2. Fundamental Concepts- UML Diagrams-
  • use cases diagram: show a set of functionalities and actors and the corresponding inter-relations.
  • class diagram: presents a set of concepts, types and classes and the respective relations.
  • object diagram: exhibit a collection of instances and their inter-connections.
  • interaction diagram: show how objects and actors collaborate by exchanging messages.
  • statechart diagram: specify the dynamic behaviour of an object, typically including several use cases.

3. Analysis Issues- Process Model -

  • Operacional approach
  • Unified, graphical and multiple-view specification
  • Object-oriented Modelling

3. Analysis Issues- Context and Use Case Diagrams -

  • context diagrams
    • non standard context diagrams for environment capturing
    • standard context diagrams for stakeholders capturing
  • hierarchical use case diagrams
    • formal numbering scheme by tagged values
    • use case risk-driven refinement
    • use case sub-behaviouring orthogonalisation
      • by specialisation
      • by decomposition

3. Analysis Issues- Object Diagrams -

  • object diagrams
    • object finding using the “4-step rule set” technique
    • 6 object <<type>> stereotypes
      • <<control>>, <<interface>> and <<data>> (or <<entity>>)
      • <<sensor>> and <<actuator>> (sub-types of <<data>>)
      • <<black-box>>
  • 4-step rule set
    • step 1: transform each use case into 3 objects (control, interface, data)
    • step 2: holistic filtering (object killing considering all textual descriptions)
    • step 3: aggregation for object superposition unified representation
    • step 4: object interconnecting for association finding

3. Analysis Issues- Sequence Diagrams -

  • non standard data path/plant diagrams
    • data path/plant’s resources static specification
    • UML does not define any diagram for that
  • extended sequence diagrams
    • timing inscriptions
  • non standard scenery diagrams
    • sequence diagrams with pictorial objects

3. Analysis Issues- Object Diagrams -

  • collapsed object diagram
    • one for each different sub-project
  • non standard high-level object diagram
    • high-level & global diagram
    • considers both control and controlled parts of the system
    • constructed from a filtering technique executed to the collapsed diagram
  • filtering technique

1. draw a circle around the main entities

2. eliminate entities that don’t have direct associations with the main ones

3. keep the others


3. Analysis Issues- State Diagrams -

  • UML statecharts
    • impose static modelling of concurrent activities, directly dependent on the number of FSMs
    • do not deal efficiently with arbitrary complex data structures
  • UML activity diagrams
    • do not support advanced hierarchical modelling
  • Petri nets (shobi-PN v2.0)
    • support dynamic, hierarchical, incremental and modular modelling
    • model the data path/plant reactive behaviour
    • allow the specification of aggregates of parallel and distributed controller objects

3. Analysis Issues- Class Diagrams -

Standard class diagrams

  • simple inheritance
  • abstract classes
  • avoid associations between classes
  • object-driven (object-based)

3. Analysis Issues- OBLOG Generation -

  • 3 decomposition regions
    • data path
      • sub-region sensors
      • sub-region actuators
      • sub-region nodes
    • controller
      • specifies the aggregates of state-machines
    • system
      • specifies the final system to be implemented

3. Analysis Issues- OBLOG Generation -

  • special attention must be paid to the following issues
    • state  Oblog is not state oriented
    • synchronism  Oblog is inherently asynchronous
    • hierarchy  Oblog does not directly support structural hierarchies
  • 3 sets of rules have been defined to allow the generation of Oblog to specify parallel controllers

1) rule-set for the definition of an abstract class of parallel controllers

2) rule-set for emulating state orientation

3) rule-set for the construction of a collection of sub-machines


3. Analysis Issues- OBLOG Generation -

  • rule-set for emulating state orientation
    • state change methods (Oblog self initiative operations)
    • event reaction oriented transition methods (event reaction operations)
    • eventless transition methods (event reaction operations)
    • state methods
    • exception handling to handle behavioural abortions
  • rule-set for the construction of a collection of sub-machines
    • upper to lower level machine communication by direct invocation
    • lower to upper level machine communication by
      • multicast sub_param (sender << “net1_s2”, param << condition_out)
      • multicast sub_return (sender << “send_other_amt2”, ret << TRUE)

4. Conclusions

  • Language
    • deal with exceptions
    • model data path/plant in a reactive way
    • support multiple-view operational meta-models
  • Complexity Control
    • support graphical and hierarchical formalisms
    • support middle-out approaches
  • Continuity of models
    • integrate co-related refined representations within the successive design stages for forward and backward navigation

5. Future Work

  • Apply the methodology to more projects
  • Replace Oblog by Java as a unified language
  • Include Quality and Re-engineering issues during Analysis
  • Incorporate the process simulation in the environment
  • Build tools (automatic code generation)
  • ...