Title: A Methodology for Developing Industrial Embedded Systems: An Hardware/Software Co-Design Approach
1A 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
2Outline
- 1. Introduction
- 2. Fundamental Concepts
- 3. Analysis Issues
- 4. Conclusions
- 5. Future Work
31. 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.
41. 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.
52. Fundamental Concepts- Systems
Characteristics -
- State transition
- Exceptions
- Hierarchy
- Concurrency
- Distribution
- Activity conclusion
- Algorithmic constructions
- Timeliness
- Non-functional requirements
- ...
62. 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.
72. 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.
82. Fundamental Concepts- Virtual Prototyping -
- unified representations
- executable specifications
- modularity and reutilization
- spiral process model
92. Fundamental Concepts - Waterfall lifecycle -
Implemen-tation
Analysis
Design
Feasibility
Use
Maintenance
Test
Development
Project
Life cycle
102. 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
112. 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.
123. Analysis Issues- Process Model -
- Operacional approach
- Unified, graphical and multiple-view
specification - Object-oriented Modelling
133. 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
143. Analysis Issues- Environment Diagram -
153. Analysis Issues- Use Case Diagram -
163. Analysis Issues- Use Case Refinement by
Specialisation -
173. Analysis Issues- Use Case Refinement by
Decomposition -
183. 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
193. Analysis Issues- Object Diagram -
203. 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
213. Analysis Issues- Data Path/Plant Static
Specification -
223. Analysis Issues- Sequence Diagrams -
233. Analysis Issues- Scenery Diagrams -
243. 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
253. Analysis Issues- Collapsed Object Diagram -
263. Analysis Issues- Filtering the Collapsed
Object Diagram -
273. Analysis Issues- High-Level Object Diagram -
283. 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
293. Analysis Issues- shobi-PN v2.0 Diagrams -
303. Analysis Issues- Class Diagrams -
- Standard class diagrams
- simple inheritance
- abstract classes
- avoid associations between classes
- object-driven (object-based)
313. Analysis Issues- Controller Architecture -
323. 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
333. Analysis Issues- OBLOG Decomposition Regions -
343. Analysis Issues- OBLOG Sensors Sub-Region -
353. Analysis Issues- OBLOG Actuators Sub-Region -
363. 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
373. 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)
383. Analysis Issues- OBLOG Controller Region -
393. Analysis Issues- Models Verification/Simulatio
n -
404. 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
415. 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)
- ...