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

1. A Methodology for Developing Industrial Embedded Systems:An Hardware/Software Co-Design Approach João Miguel Fernandes(miguel@di.uminho.pt)Dept. Informática UNIVERSIDADEDO 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 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.

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

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 Test Maintenance 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 <<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

19. 3. Analysis Issues- Object Diagram -

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

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 don’t 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 << “net1_s2”, param << condition_out) • multicast sub_return (sender << “send_other_amt2”, ret << TRUE)

38. 3. Analysis Issues- OBLOG Controller Region -

39. 3. Analysis Issues- Models Verification/Simulation -

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