PLAY-OUT FOR HIERARCHICAL COMPONENT ARCHITECTURES

Transcription

1 PLAY-OUT FOR HIERARCHICAL COMPONENT ARCHITECTURES Jörg Holtmann, Matthias Meyer Automotive Software Engineering, 17. September 2013 Sheet 1

2 Introduction and Motivation Automotive Domain Approach to cope with complexity: component-based software development Requirements Elicitation Development process according to Automotive SPICE (supplier viewpoint) System Requirements Analysis System Testing System Architecture Design System Integration Test Hardware Requirements Analysis Software Requirements Analysis Software Testing Hardware Testing Hardware Design Software Design Software Integration Test Hardware Integration Test Module Test Software Construction Hardware Construction Module Test Software Focus Hardware Focus Sheet 2

3 cmp Presentation_ICSE ECU 1 * Car composite structure Pedelec Env ironment (SysML IBD) «EnvironmentElementExemplar» umgebung 1 schmutz «Flow» «EnvironmentElementExemplar» smartphone «Flow» «SystemExemplar» pedelec besitzt «Flow» «Flow» «EnvironmentElementExemplar» besitzer Software Hardware ladeenergiesmartphone stiehlt «Flow» ladeenergieladestation «Flow» «Flow» «EnvironmentElementExemplar» dieb «Environme ladestation composite structure Pedelec Env ironment (SysML IBD) «EnvironmentElementExemplar» umgebung schmutz «Flow» «EnvironmentElementExemplar» smartphone «Flow» «SystemExemplar» pedelec besitzt «Flow» «Flow» «EnvironmentElementExemplar» besitzer ladeenergiesmartphone stiehlt «Flow» ladeenergieladestation «Flow» «Flow» «EnvironmentElementExemplar» dieb «Environme ladestation Introduction and Motivation Automotive Domain Approach to cope with complexity: component-based software development System requirements System Requirements Analysis System architecture System Architecture Design Sy System In Software requirements Hardware Requirements Analysis Software Requirements Analysis Software Testing T Software Design Hardware Design Software Design Software Integration Test Hard Integ Test Software Construction Module Test Hardware Construction Sheet 3

4 Running Example Body Control Module (BCM) Remote key Body Control Module (BCM) Door Locks ID BCM System Requirements 49 When the remote key sends a central door locking request, the BCM has to send lock commands to all door locks. 236 When locking the doors was successful, the door locks have to confirm this by means of an nowledment message. 524 After the door locks were successfully locked, the BCM has to send a feedb command to the turn signal actuators. Speed Turn Signals 851 When the speed threshold spd_thrsh is exceeded, the body control module has to send commands to all door locks in order to lock the doors. Sheet 4

5 RemoteLockDoorsAndFeedb lockfeedbcmd SignalAcuator RemoteLockDoorsAndFeedb lockfeedbcmd SignalAcuator Introduction and Motivation Formal Requirements and Hierarchical Component Architectures Previous work Formal, scenario-based requirements engineering approach Not suited for hierarchical component architectures! RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb lockfeedbcmd SignalAcuator RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb SignalAcuator lockfeedbcmd? RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb How to specify formal requirements for hierarchical component architectures across several abstraction levels? Sheet 5

6 CONTENTS 1. Introduction + motivation 2. Preliminaries: Previous approach on formal requirements engineering 3. Problem description: Approach not sufficient for hierarchical component architectures 4. Adapted modeling approach 5. Simulative validation of requirements for hierarchical component architectures Sheet 6

7 Previous work Formal Requirements Engineering with Modal Sequence Diagrams (MSDs) Modal Sequence Diagrams (MSDs) UML-compliant variant of Live Sequence Charts Formal and modal semantics Environment elements RemoteLockDoors dl_passenger: System under development c = 0 c 100 Sheet 7

8 Previous work Formal Requirements Engineering with Modal Sequence Diagrams (MSDs) Modal Sequence Diagrams (MSDs) UML-compliant variant of Live Sequence Charts Formal and modal semantics Provisional message Analysis techniques Formal verification on consistency Simulative validation by means of Play-out algorithm Mandatory messages RemoteLockDoors c = 0 c 100 Timing requirement dl_passenger: Sheet 8

9 Previous work Simulative Validation by Means of Play-out Algorithm Operational interpretation of formal semantics of MSDs Plays out messages specified by the scenarios RemoteLockDoors Cut = state of an active MSD Detects safety violations Allows to validate for unintended behavior LockingFeedb lockfeedbcmd Sheet 9

10 Previous work Simulative Validation by Means of Play-out Algorithm Operational interpretation of formal semantics of MSDs Plays out messages specified by the scenarios RemoteLockDoors Cut = state of an active MSD Detects safety violations Allows to validate for unintended behavior LockingFeedb lockfeedbcmd Sheet 10

11 Previous work Simulative Validation by Means of Play-out Algorithm Operational interpretation of formal semantics of MSDs Plays out messages specified by the scenarios RemoteLockDoors Cut = state of an active MSD Detects safety violations Allows to validate for unintended behavior LockingFeedb lockfeedbcmd Activation and synchronisation of scenarios by message exchange Sheet 11

12 Previous work Simulative Validation by Means of Play-out Algorithm Operational interpretation of formal semantics of MSDs Plays out messages specified by the scenarios RemoteLockDoors Cut = state of an active MSD Detects safety violations Allows to validate for unintended behavior LockingFeedb lockfeedbcmd Activation and synchronisation of scenarios by message exchange Sheet 12

13 Previous work Simulative Validation by Means of Play-out Algorithm Operational interpretation of formal semantics of MSDs Plays out messages specified by the scenarios RemoteLockDoors SpeedLockDoors idi: Inter Domain Interface speedthreshold Reached Detects safety violations Allows to validate for unintended behavior LockingFeedb lockfeedbcmd Sheet 13

14 Previous work Simulative Validation by Means of Play-out Algorithm Operational interpretation of formal semantics of MSDs Plays out messages specified by the scenarios RemoteLockDoors SpeedLockDoors idi: Inter Domain Interface speedthreshold Reached Detects safety violations Allows to validate for unintended behavior LockingFeedb lockfeedbcmd Sheet 14

15 Previous work Simulative Validation by Means of Play-out Algorithm Operational interpretation of formal semantics of MSDs Plays out messages specified by the scenarios RemoteLockDoors SpeedLockDoors idi: Inter Domain Interface speedthreshold Reached Detects safety violations Allows to validate for unintended behavior LockingFeedb lockfeedbcmd Unintended behavior: speed locking activates locking feedb! Sheet 15

16 Previous work Simulative Validation by Means of Play-out Algorithm Operational interpretation of formal semantics of MSDs Plays out messages specified by the scenarios Scenario merge: locking feedb only on remote key operation SpeedLockDoors idi: Inter Domain Interface speedthreshold Reached Detects safety violations RemoteLockDoorsAndFeedb Allows to validate for unintended behavior lockfeedbcmd Sheet 16

17 CONTENTS 1. Introduction + motivation 2. Preliminaries: Previous approach on formal requirements engineering 3. Problem description: Approach not sufficient for hierarchical component architectures 4. Adapted modeling approach 5. Simulative validation of requirements for hierarchical component architectures Sheet 17

18 Problem Description How to Specify and Simulate MSDs for Hierarchical Component Architectures? Component architectures Arranged hierarchically Ports + directed connectors lcm: Lockg CenMst fm: Flash Manager Until now: Plain class models as structural basis for MSDs Scenarios only at one hierarchy level Each entity can communicate with arbitrary others RemoteLockDoorsAndFeedb lockfeedbcmd Sheet 18

19 CONTENTS 1. Introduction + motivation 2. Preliminaries: Previous approach on formal requirements engineering 3. Problem description: Approach not sufficient for hierarchical component architectures 4. Adapted modeling approach 5. Simulative validation of requirements for hierarchical component architectures Sheet 19

20 Modeling Approach + + signature connector bdd System [Interfaces] bdd System [Blocks] type ref Top Level Subsystem Level Subsubsystem Level type ibd ibd represents refersto ProcessLockingRequest ProcessLockingRequest ibd Type View Internal Structure View Interaction View Sheet 20

21 Modeling Approach Overview Port interfaces Component types Internal structure signature connector Scenarios bdd System [Interfaces] bdd System [Blocks] type ref Top Level Subsystem Level Subsubsystem Level Top level Subsystem level(s) type ibd ibd represents refersto ProcessLockingRequest ProcessLockingRequest ibd Type View Internal Structure View Interaction View Sheet 21

22 signature connector Modeling Approach Top Level: Specify Port Interfaces + Component Types Interfaces specify, which messages can be sent within MSDs Top Level Subsystem Level Subsubsystem Level bdd System [Interfaces] bdd System [Blocks] type type ibd ProcessLockingRequest ProcessLockingRequest ibd ibd Type View Internal Structure View Interaction View Interface usages in ports define possible communication directions represents ref refersto bdd System [Interfaces] bdd System [Blocks] RK2BCM () type (provided) type (required) :~RK2BCM TurnSignal Actuator BCM2DL () DL2BCM () :RK2BCM BCM2TSA lockfeedbcmd() BodyControl Module Sheet 22 Blocks specify the types for the component architecture

23 signature connector bdd System [Interfaces] bdd System [Blocks] Modeling Approach Top Level: Specify Use Cases Top Level Subsystem Level Subsubsystem Level type type ibd ibd represents ProcessLockingRequest ProcessLockingRequest ibd ref refersto Type View Internal Structure View Interaction View Use cases by means of UML collaboration diagrams Specify participants for a particular use case to be used in its scenarios bdd System [Blocks] Directed connectors Lock Doors Remotely and Give Feedb rk2bcm dld2bcm bcm2dld BodyControl Module type Parts typed by blocks bcm2tsa Sheet 23

24 signature connector bdd System [Interfaces] bdd System [Blocks] Modeling Approach Top Level: Specify Scenarios bdd System [Interfaces] Lock Doors Remotely and Give Feedb Top Level Subsystem Level Subsubsystem Level type Type View type ibd ibd Internal Structure View represents ProcessLockingRequest ProcessLockingRequest ibd ref refersto Interaction View RK2BCM () rk2bcm dld2bcm bcm2dld Messages sent via connectors connector represents bcm2tsa Lifelines represent use case participants RemoteLockDoorsAndFeedb signature Messages compliant to port interfaces lockfeedbcmd Sheet 24

25 signature connector bdd System [Interfaces] bdd System [Blocks] Modeling Approach Subsystem Level(s): Decompose Structural Elements Lock Doors Remotely and Give Feedb Top Level Subsystem Level Subsubsystem Level type Type View type ibd ibd Internal Structure View represents ProcessLockingRequest ProcessLockingRequest ibd ref refersto Interaction View rk2bcm dld2bcm bcm2dld Hierarchically decompose components ibd Body bcm2tsa Connect inner components to superordinate level with delegation connectors Add and connect inner components Sheet 25 lcm: Lockg CenMst lcm2fm fm: Flash Manager

26 signature connector bdd System [Interfaces] bdd System [Blocks] Modeling Approach Subsystem Level(s): Specify Interactions Top Level Subsystem Level Subsubsystem Level type type ibd ibd represents ProcessLockingRequest ProcessLockingRequest ibd ref refersto Type View Internal Structure View Interaction View RemoteLockDoorsAndFeedb ref Connect MSDs with UML InteractionUse refersto lockfeedbcmd Messages crossing hierarchy levels connected via gates Add MSDs for new hierarchy level ProcessLockingRequest lcm: Lockg CenMst fm: Flash Manager lockfeedbreq lockfeedbcmd Sheet 26

27 Syntactical Constraints for Complete and Executable Models Automatic Checks as Support for the Engineer All links set? bdd System [Interfaces] RK2BCM () type (provided) type (required) bdd System [Blocks] :RK2BCM :~RK2BCM Connector directions respected? BodyControl Module type :~RK 2BCM RemoteLockDoorsAndFeedb rk2bcm :RK2 BCM connector Lock Doors Remotely and Give Feedb represents bcm2dld bcm2tsa dld2bcm :~DL2BC :BCM2 d D tsa Si :BCM 2TSA tsa_ Sign signature Interface compatibility? lockfeedbcmd Sheet 27

28 CONTENTS 1. Introduction + motivation 2. Preliminaries: Previous approach on formal requirements engineering 3. Problem description: Approach not sufficient for hierarchical component architectures 4. Adapted modeling approach 5. Simulative validation of requirements for hierarchical component architectures Sheet 28

29 Hierarchical Play-out Functional Principle RemoteLockDoorsAndFeedb ref lockfeedbcmd refersto ProcessLockingRequest lcm: Lockg CenMst fm: Flash Manager lockfeedbreq lockfeedbcmd Sheet 29

30 Hierarchical Play-out Functional Principle RemoteLockDoorsAndFeedb ref lockfeedbcmd refersto ProcessLockingRequest lcm: Lockg CenMst fm: Flash Manager lockfeedbreq lockfeedbcmd Sheet 30

31 Hierarchical Play-out Functional Principle RemoteLockDoorsAndFeedb ref lockfeedbcmd refersto ProcessLockingRequest lcm: Lockg CenMst fm: Flash Manager lockfeedbreq lockfeedbcmd Sheet 31

32 Hierarchical Play-out Functional Principle RemoteLockDoorsAndFeedb ref lockfeedbcmd refersto ProcessLockingRequest lcm: Lockg CenMst fm: Flash Manager lockfeedbreq lockfeedbcmd Sheet 32

33 Hierarchical Play-out Functional Principle RemoteLockDoorsAndFeedb ref lockfeedbcmd refersto ProcessLockingRequest lcm: Lockg CenMst fm: Flash Manager lockfeedbreq lockfeedbcmd Sheet 33

34 Hierarchical Play-out Functional Principle RemoteLockDoorsAndFeedb ref lockfeedbcmd refersto ProcessLockingRequest lcm: Lockg CenMst fm: Flash Manager lockfeedbreq lockfeedbcmd Sheet 34

35 Hierarchical Play-out Functional Principle RemoteLockDoorsAndFeedb ref lockfeedbcmd refersto ProcessLockingRequest lcm: Lockg CenMst fm: Flash Manager lockfeedbreq lockfeedbcmd Sheet 35

36 Hierarchical Play-out Functional Principle RemoteLockDoorsAndFeedb ref lockfeedbcmd refersto ProcessLockingRequest lcm: Lockg CenMst fm: Flash Manager lockfeedbreq lockfeedbcmd Sheet 36

37 RemoteLockDoorsAndFeedb lockfeedbcmd SignalAcuator RemoteLockDoorsAndFeedb lockfeedbcmd SignalAcuator Starting Situation Formal Requirements and Hierarchical Component Architectures Previous work Formal, scenario-based requirements engineering approach Not suited for hierarchical component architectures! RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb lockfeedbcmd SignalAcuator RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb SignalAcuator lockfeedbcmd? RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb How to specify formal requirements for hierarchical component architectures across several abstraction levels? Sheet 37

38 Summary and Outlook Lock Doors Remotely and Give Feedb dld2bcm :~DL2BCM :DL2BCM rk2bcm :~BCM bcm2dld :~RK :BCM2DL :RK2 2DL 2BCM BCM :~BCM2TSA bcm2tsa SignalAcuator :BCM 2TSA RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb RemoteLockDoorsAndFeedb ref lockfeedbcmd SignalAcuator ibd Body lcm: Lockg CenMst fm: Flash Manager ProcessLockingRequest ProcessLockingRequest ProcessLockingRequest lcm: Lockg fm: Flash CenMst Manager lockfeedbreq lockfeedbcmd ibd FlashManager Outlook ibd LockgCenMst Verification of correct refinement Cover AUTOSAR specifics More detailed timing information Alignment with systems engineering Enables integrated requirements engineering and component architecture design across multiple abstraction levels! Sheet 38

39 Vielen Dank für Ihre Aufmerksamkeit Dipl.-Inform. Jörg Holtmann Fraunhofer-Institut für Produktionstechnik Projektgruppe Entwurfstechnik Mechatronik Zukunftsmeile Paderborn Telefon: Fax: Joerg.Holtmann@ipt.fraunhofer.de Dr. Matthias Meyer Fraunhofer-Institut für Produktionstechnik Projektgruppe Entwurfstechnik Mechatronik Zukunftsmeile Paderborn Telefon: Fax: Matthias.Meyer@ipt.fraunhofer.de Sheet 39