A Methodology for Developing A Methodology for Developing Industrial Embedded Systems: Industrial Embedded Systems: An Hardware/Software Co-Design An Hardware/Software Co-Design Approach Approach UNIVERSIDADE DO MINHO ESCOLA DE ENGENHARIA 2000-Apr- 07 João Miguel Fernandes João Miguel Fernandes ([email protected]) Dept. Informática Dept. Informática MICEI-99/00
41
Embed
A Methodology for Developing Industrial Embedded Systems: An Hardware/Software Co-Design Approach U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000-Apr-07.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
A Methodology for DevelopingA Methodology for Developing Industrial Embedded Systems: Industrial Embedded Systems:
An Hardware/Software Co-Design An Hardware/Software Co-Design ApproachApproach
– Define new methodologies and architectural solutions Define new methodologies and architectural solutions to help systems (hardware/software) engineers to do to help systems (hardware/software) engineers to do their job, in an easier way.their job, in an easier way.
What is our application area?What is our application area?
– Industrial real-time applications demanding direct Industrial real-time applications demanding direct intervention in real-time control, supervision and intervention in real-time control, supervision and monitoring, computer vision, robotic systems and monitoring, computer vision, robotic systems and industrial communications.industrial communications.
4
1. Introduction1. Introduction
What are our main concerns?What are our main concerns?
– Control the complexity in system design.Control the complexity in system design.
– Guarantee the models’ continuity during reification Guarantee the models’ continuity during reification stages.stages.
– Use non-conventional target architectures in a Use non-conventional target architectures in a technologically-transparent way.technologically-transparent way.
What are our preferable target What are our preferable target architectures?architectures?
– Embedded, heterogeneous, reconfigurable and Embedded, heterogeneous, reconfigurable and distributed processing architectures.distributed processing architectures.
Co-DesignCo-Design: Development : Development approach that faces the approach that faces the problem of designing problem of designing heterogeneous systems heterogeneous systems (with hw and sw (with hw and sw components) treating both components) treating both kinds of components in an kinds of components in an equal way, allowing the equal way, allowing the iterative migration of iterative migration of functionalities so that functionalities so that functional and non-functional and non-functional requirements are functional requirements are optimally implemented. optimally implemented.
HW/SW HW/SW coco-design promotes an effective -design promotes an effective coconcurrent, ncurrent, coco--operative and operative and coco-ordinated design of the -ordinated design of the hardwarehardware and and softwaresoftware components needed for the implementation of components needed for the implementation of the system.the system.
UML includes several diagrams that allow the UML includes several diagrams that allow the description of the most relevant aspects of a system, description of the most relevant aspects of a system, following an object-oriented approach. following an object-oriented approach.
Each diagram focus a specific view of the system.Each diagram focus a specific view of the system.
Important UML diagrams to specify and document Important UML diagrams to specify and document embedded systems:embedded systems:– use cases diagramsuse cases diagrams– class diagramsclass diagrams– object diagramsobject diagrams– interaction diagramsinteraction diagrams– statechart diagramsstatechart 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. 3. Analysis IssuesAnalysis Issues- Process Model- Process Model - -
An
aly
sis
7. protocol modelling
13. comparison
valid
non v
alid
3. description
Design
Viability Studies
11. specification
10. classification
4. transformation
6. behaviouralmodelling
5. data path/plantmodelling
8. selection
2. functional modelling
1. environment capturing
9. controloformalization
ContextDiagrams
Use CaseDiagrams
Textual Descriptionsof Use Cases
ClassDiagrams
ObjectDiagrams
Data Path/PlantSpecification
Sequence andScenary
Diagrams
Specification ofData Path/Plant
Using
Oblog RepositorySequenceDiagrams
Control Cycle inshobi-PN v2.0
Implementation
12. simulation
user's
requirem
ents
syste
m's
requirem
ents
Operacional approach
Unified, graphical and multiple-view specification
Object-oriented Modelling
13
3. 3. Analysis IssuesAnalysis Issues- Context and Use Case Diagrams- Context and Use Case Diagrams - -
context diagramscontext diagrams– non standard context diagrams for environment capturingnon standard context diagrams for environment capturing– standard context diagrams for stakeholders capturingstandard context diagrams for stakeholders capturing
hierarchical use case diagramshierarchical use case diagrams– formal numbering scheme by tagged valuesformal numbering scheme by tagged values– use case risk-driven refinementuse case risk-driven refinement– use case sub-behaviouring orthogonalisationuse case sub-behaviouring orthogonalisation
by specialisationby specialisation by decompositionby decomposition
object diagramsobject diagrams– object finding using the “4-step rule set” techniqueobject finding using the “4-step rule set” technique– 6 object <<type>> stereotypes6 object <<type>> stereotypes
<<control>>, <<interface>> and <<data>> (or <<entity>>)<<control>>, <<interface>> and <<data>> (or <<entity>>) <<sensor>> and <<actuator>> (sub-types of <<data>>)<<sensor>> and <<actuator>> (sub-types of <<data>>) <<black-box>><<black-box>>
4-step rule set4-step rule set– step 1: transform each use case into 3 objects (control, interface, step 1: transform each use case into 3 objects (control, interface,
data)data)– step 2: holistic filtering (object killing considering all textual step 2: holistic filtering (object killing considering all textual
descriptions)descriptions)– step 3: aggregation for object superposition unified representationstep 3: aggregation for object superposition unified representation– step 4: object interconnecting for association findingstep 4: object interconnecting for association finding
non standard data path/plant diagramsnon standard data path/plant diagrams– data path/plant’s resources static specificationdata path/plant’s resources static specification– UML does not define any diagram for thatUML does not define any diagram for that
collapsed object diagramcollapsed object diagram– one for each different sub-projectone for each different sub-project
non standard high-level object diagramnon standard high-level object diagram– high-level & global diagramhigh-level & global diagram– considers both control and controlled parts of the systemconsiders both control and controlled parts of the system– constructed from a filtering technique executed to the collapsed constructed from a filtering technique executed to the collapsed
diagramdiagram
filtering techniquefiltering technique1.1. draw a circle around the main entitiesdraw a circle around the main entities
2.2. eliminate entities that don’t have direct associations with the main eliminate entities that don’t have direct associations with the main onesones
3. 3. Analysis IssuesAnalysis Issues- State Diagrams- State Diagrams - -
UML statechartsUML statecharts– impose static modelling of concurrent activities, directly dependent on the impose static modelling of concurrent activities, directly dependent on the
number of FSMsnumber of FSMs– do not deal efficiently with arbitrary complex data structuresdo not deal efficiently with arbitrary complex data structures
UML activity diagramsUML activity diagrams– do not support advanced hierarchical modellingdo not support advanced hierarchical modelling
Petri nets (shobi-PN v2.0)Petri nets (shobi-PN v2.0)– support dynamic, hierarchical, incremental and modular modellingsupport dynamic, hierarchical, incremental and modular modelling– model the data path/plant reactive behaviourmodel the data path/plant reactive behaviour– allow the specification of aggregates of parallel and distributed controller objectsallow the specification of aggregates of parallel and distributed controller objects
* 3 : Move_E ( NB e ,n , down, empty, Time_GL, Time_BL, !res_ack>>res_ack1)
NB e ,n
NB e ,n
Move_E ( NB e,n , sense, full, Time_GL, Time_BL, res_ack)
res_ack = OK
Calc_Dest (id, NB line ,n .N, 3, Time_BL, dummy)
dummy = X dummy != X
NB e ,n
NB e ,n
E_type = updown E_type = downE_type = up
* 2
* 1
* 3 * 4
NB line ,n+NB e ,nNB line ,n+NB e ,n
NB e,n
NB e ,nNB e ,n
NB e ,nNB e ,n
NB e,nNB e ,n
NB e,nNB e ,n
NB e ,n
NB e,nNB e ,n
NB e,n
NB e ,n NB e,n
NB e,n
NB e,n
NB e,n
NB e,n
NB e,n
NB e,n
* 4 : Move_E ( NB e ,n , up, empty, Time_GL, Time_BL, !res_ack>>res_ack1)
Send_Other ( in NB line ,n : Node require d ,in id: Code,in dest: Lines,in Time_GL: Temp, in Time_BL: Temp )
NB e ,n
NB e ,n
NB e ,n
pre (dest > e) sense = downpre (dest < e) sense = up
NB line ,n
NB e ,n
NB e,n
NB line ,n
E_type = updownor
E_type = sense
E_type != updownand
E_type != sense
NB line ,n
NB line ,nNB line ,n
NB line ,n
NB line ,n
NB line ,n
C1 .MSG ("sense_error", NB l ine ,n , $TIME_SYS)res_ack = KO res_ack = KO
C1
sei
seo
te
Ret
t2
s2
s1
s0
t0
t1
t3 t4
t5 t6
t7
t8 t9
t10
t11 t12 t13
t14 t15
t16
s3
s4
s6
s5
s7
s8
s9 s10
s11
s12
30
3. 3. Analysis IssuesAnalysis Issues- Class Diagrams -- Class Diagrams -
Standard class diagramsStandard class diagrams– simple inheritancesimple inheritance– abstract classesabstract classes– avoid associations between avoid associations between
special attention must be paid to the following issuesspecial attention must be paid to the following issues– state state Oblog is not state oriented Oblog is not state oriented– synchronism synchronism Oblog is inherently asynchronous Oblog is inherently asynchronous– hierarchy hierarchy Oblog does not directly support structural hierarchies Oblog does not directly support structural hierarchies
3 sets of rules have been defined to allow the generation 3 sets of rules have been defined to allow the generation of Oblog to specify parallel controllersof Oblog to specify parallel controllers1) rule-set for the definition of an abstract class of parallel controllers1) rule-set for the definition of an abstract class of parallel controllers
2) rule-set for emulating state orientation2) rule-set for emulating state orientation
3) rule-set for the construction of a collection of sub-machines3) rule-set for the construction of a collection of sub-machines
rule-set for emulating state orientationrule-set for emulating state orientation– state change methods (Oblog self initiative operations)state change methods (Oblog self initiative operations)– event reaction oriented transition methods (event reaction operations)event reaction oriented transition methods (event reaction operations)– eventless transition methods (event reaction operations)eventless transition methods (event reaction operations)– state methodsstate methods– exception handling to handle behavioural abortionsexception handling to handle behavioural abortions
rule-set for the construction of a collection of sub-machinesrule-set for the construction of a collection of sub-machines– upper to lower level machine communication by direct invocationupper to lower level machine communication by direct invocation– lower to upper level machine communication bylower to upper level machine communication by
LanguageLanguage– deal with exceptionsdeal with exceptions– model data path/plant in a reactive waymodel data path/plant in a reactive way– support multiple-view operational meta-modelssupport multiple-view operational meta-models
Complexity ControlComplexity Control– support graphical and hierarchical formalismssupport graphical and hierarchical formalisms– support middle-out approachessupport middle-out approaches
Continuity of modelsContinuity of models– integrate co-related refined representations within the integrate co-related refined representations within the
successive design stages for forward and backward navigationsuccessive design stages for forward and backward navigation
41
5. 5. Future WorkFuture Work
Apply the methodology to more projects Apply the methodology to more projects
Replace Oblog by Java as a unified languageReplace Oblog by Java as a unified language
Include Quality and Re-engineering issues during Include Quality and Re-engineering issues during AnalysisAnalysis
Incorporate the process simulation in the Incorporate the process simulation in the environmentenvironment