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

Loading...

PPT – A Methodology for Developing Industrial Embedded Systems: An Hardware/Software Co-Design Approach PowerPoint presentation | free to download - id: 169961-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

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

Description:

Life cycle. 10. 2. Fundamental Concepts - UML Notation ... non standard data path/plant diagrams. data path/plant's resources static specification ... – PowerPoint PPT presentation

Number of Views:28
Avg rating:3.0/5.0
Slides: 42
Provided by: joomiguel
Learn more at: http://gec.di.uminho.pt
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

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


1
A Methodology for Developing Industrial
Embedded SystemsAn Hardware/Software Co-Design
Approach
João Miguel Fernandes(miguel_at_di.uminho.pt)Dept.
Informática
UNIVERSIDADE DO MINHO ESCOLA DE ENGENHARIA
2000-Apr-07
MICEI-99/00
2
Outline
  • 1. Introduction
  • 2. Fundamental Concepts
  • 3. Analysis Issues
  • 4. Conclusions
  • 5. Future Work

3
1. Introduction
  • What is our RD 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.

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

5
2. Fundamental Concepts- Systems
Characteristics -
  • State transition
  • Exceptions
  • Hierarchy
  • Concurrency
  • Distribution
  • Activity conclusion
  • Algorithmic constructions
  • Timeliness
  • Non-functional requirements
  • ...

6
2. Fundamental Concepts- HW/SW Co-Design -
  • 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.

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

8
2. Fundamental Concepts- Virtual Prototyping -
  • unified representations
  • executable specifications
  • modularity and reutilization
  • spiral process model

9
2. Fundamental Concepts - Waterfall lifecycle -
Implemen-tation
Analysis
Design
Feasibility
Use
Maintenance
Test
Development
Project
Life cycle
10
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

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

12
3. Analysis Issues- Process Model -
  • Operacional approach
  • Unified, graphical and multiple-view
    specification
  • Object-oriented Modelling

13
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

14
3. Analysis Issues- Environment Diagram -
15
3. Analysis Issues- Use Case Diagram -
16
3. Analysis Issues- Use Case Refinement by
Specialisation -
17
3. Analysis Issues- Use Case Refinement by
Decomposition -
18
3. Analysis Issues- Object Diagrams -
  • object diagrams
  • object finding using the 4-step rule set
    technique
  • 6 object ltlttypegtgt stereotypes
  • ltltcontrolgtgt, ltltinterfacegtgt and ltltdatagtgt (or
    ltltentitygtgt)
  • ltltsensorgtgt and ltltactuatorgtgt (sub-types of
    ltltdatagtgt)
  • ltltblack-boxgtgt
  • 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

19
3. Analysis Issues- Object Diagram -
20
3. Analysis Issues- Sequence Diagrams -
  • non standard data path/plant diagrams
  • data path/plants 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

21
3. Analysis Issues- Data Path/Plant Static
Specification -
22
3. Analysis Issues- Sequence Diagrams -
23
3. Analysis Issues- Scenery Diagrams -
24
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 dont have direct
    associations with the main ones
  • 3. keep the others

25
3. Analysis Issues- Collapsed Object Diagram -
26
3. Analysis Issues- Filtering the Collapsed
Object Diagram -
27
3. Analysis Issues- High-Level Object Diagram -
28
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

29
3. Analysis Issues- shobi-PN v2.0 Diagrams -
30
3. Analysis Issues- Class Diagrams -
  • Standard class diagrams
  • simple inheritance
  • abstract classes
  • avoid associations between classes
  • object-driven (object-based)

31
3. Analysis Issues- Controller Architecture -
32
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

33
3. Analysis Issues- OBLOG Decomposition Regions -
34
3. Analysis Issues- OBLOG Sensors Sub-Region -
35
3. Analysis Issues- OBLOG Actuators Sub-Region -
36
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

37
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 ltlt net1_s2, param ltlt
     condition_out)
  • multicast sub_return (sender ltlt send_other_amt2,
     ret ltlt TRUE)

38
3. Analysis Issues- OBLOG Controller Region -
39
3. Analysis Issues- Models Verification/Simulatio
n -
40
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

41
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)
  • ...
About PowerShow.com