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