Your SlideShare is downloading. ×
  • Like
Causality in Message-Based Interface Contracts: A Temporal Logic "Whodunit"
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Causality in Message-Based Interface Contracts: A Temporal Logic "Whodunit"

  • 471 views
Published

Interface contracts are sets of constraints specifying valid exchanges of messages between two or more peers. A contract violation occurs when one of the peers fails to fulfil one of these constraints …

Interface contracts are sets of constraints specifying valid exchanges of messages between two or more peers. A contract violation occurs when one of the peers fails to fulfil one of these constraints and emits a message that is not a valid continuation of a message "trace". In some cases, the message that directly exposes the violation turns out to be the last of a succession of forced moves, while the "root cause" of the violation resides earlier in the trace and may emanate from a different peer. We formally define the notion of causality for interface contracts expressed in a first-order extension of Linear Temporal Logic. In particular, we show how the detection of root causes reduces to satisfiability solving of a precise set of formulæ. An experimental setup shows how causality can be analyzed automatically on a pre-recorded message trace.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
471
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Sylvain Hallé
  • 2. A lighthearted introductionSylvain Hallé 2
  • 3. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’Sylvain Hallé 2
  • 4. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ MovesSylvain Hallé 2
  • 5. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves RulesSylvain Hallé 2
  • 6. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ and O mu st alternate Moves 1. X symbols n’t put two . 2. Ca in sa me square must be ually, there . 3. Event Rules a line of three O’sSylvain Hallé 2
  • 7. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves RulesSylvain Hallé 2
  • 8. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves RulesSylvain Hallé 2
  • 9. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves RulesSylvain Hallé 2
  • 10. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves RulesSylvain Hallé 2
  • 11. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves Rules GameSylvain Hallé 2
  • 12. A lighthearted introduction ‘‘O’’ web service ‘‘X’’ web serviceSylvain Hallé 3
  • 13. A lighthearted introduction Move ‘‘O’’ web service ‘‘X’’ web serviceSylvain Hallé 3
  • 14. A lighthearted introduction <Move> Message <Player>X</Player> <Row>1</Row> <Col>A</Col> </Move> ‘‘O’’ web service ‘‘X’’ web serviceSylvain Hallé 3
  • 15. A lighthearted introduction <Move> Message <Player>X</Player> <Row>1</Row> <Col>A</Col> </Move> Interface contract ‘‘O’’ web service ‘‘X’’ web serviceSylvain Hallé 3
  • 16. A lighthearted introduction <Move> Message <Player>X</Player> <Row>1</Row> <Col>A</Col> </Move> Interface contract ‘‘O’’ web service ‘‘X’’ web service GameSylvain Hallé 3
  • 17. A lighthearted introduction <Move> Message <Player>X</Player> <Row>1</Row> <Col>A</Col> </Move> Interface contract ‘‘O’’ web service ‘‘X’’ web service TransactionSylvain Hallé 3
  • 18. A more serious example Shop service Each has its own requirements on the course of a transaction Customer serviceSylvain Hallé 4
  • 19. A more serious example S1. All carts with more than three items are labelled ‘‘large’’ and must be paid by credit . S2. Every cart created must be cbecked out . S3. Payment mode must be only one of ‘‘Credit’’ or ‘‘PayPal’’ C1. A cart created with a mode of payment must be checked out with the same mode of payment Interface contract = ‘‘sum’’ (i.e. logical conjunction) of individual requirementsSylvain Hallé 5
  • 20. Formalizing interface contracts The service’s behaviour follows constraints on... 1. Sequences of operations only 2. Parameter values only 3. Both at the same time LTL-FO+: extension of LTL with quantifiers on message parameters (Hallé & Villemaire, EDOC 2008)Sylvain Hallé 6
  • 21. Formalizing interface contracts LTL formula = assertion on a trace (of messages) Ga "always a" Xa "the next message is a" Fa "eventually a" aWb "a until b abacdcbaqqtam... G (a ® X b) FALSE Ø (q Ú t) W c TRUE But what about data contents?Sylvain Hallé 7
  • 22. Formalizing interface contracts What if symbols are XML documents? LTL-FO+ = LTL + first-order quantification on elements Let... p = argument of a function f... filters acceptable values for x... according to the current message s0 s |= $p x : j(x) Û $k : s |= j(k) AND k Îf(s0,p)Sylvain Hallé 8
  • 23. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 p = a/bSylvain Hallé 9
  • 24. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 XPath expression p = a/bSylvain Hallé 9
  • 25. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 p = a/b f(s0,p) =Sylvain Hallé 9
  • 26. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 p = a/b f(s0,p) = {1,2}Sylvain Hallé 9
  • 27. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 p = a/b f(s1,p) =Sylvain Hallé 9
  • 28. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 p = a/b f(s1,p) = {}Sylvain Hallé 9
  • 29. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 TRUE "a/b x : x=1 Ú x=2 TRUE "c x : x=5 FALSE G "c x : x=5 TRUE "c x : F $ c y : x=ySylvain Hallé 9
  • 30. LTL-FO+ ‘‘X and O must alternate’’Sylvain Hallé 10
  • 31. LTL-FO+ ‘‘X and O must alternate’’ G( )Sylvain Hallé 10
  • 32. LTL-FO+ ‘‘X and O must alternate’’ G ("Move/Player p : X (" p’ : p=p’))Sylvain Hallé 10
  • 33. LTL-FO+ ‘‘X and O must alternate’’ G ("Move/Player p : X (" p’ : p=p’))Sylvain Hallé 10
  • 34. LTL-FO+ ‘‘X and O must alternate’’ G ("Move/Player p : X ("Move/Player p’ : p=p’))Sylvain Hallé 10
  • 35. LTL-FO+ ‘‘X and O must alternate’’ G ("Move/Player p : X ("Move/Player p’ : p=p’)) /Sylvain Hallé 10
  • 36. LTL-FO+ ‘‘X and O must alternate’’ G ("Move/Player p : X ("Move/Player p’ : p=p’)) / A trace of messages m that satisfies an interface contract j is noted m jSylvain Hallé 10
  • 37. Contract compliance If m / j , whose fault is it? who·dun·it A whodunit (for "Who[s] done it?") is a complex, plot-driven variety of the detective story in which the puzzle is the main feature of interest. The reader is provided with clues from which the identity of the perpetrator of the crime may be deduced before the solution is revealed in the final pages of the book. (Wikipedia)Sylvain Hallé 11
  • 38. Contract compliance If m / j , whose fault is it? who·dun·it A whodunit (for "Who[s] done it?") is a complex, plot-driven variety of the detective story in which the puzzle is the main feature of interest. The reader is provided with clues from which the identity of the perpetrator of the crime may be deduced before the solution is revealed in the final pages of the book. (Wikipedia)Sylvain Hallé 11
  • 39. Contract compliance Applications: Which component does not implement the standard correctly? Which component should compensate the others for the violation? At runtime: which component should take a different action to avoid a violation?Sylvain Hallé 12
  • 40. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / jSylvain Hallé 13
  • 41. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / jSylvain Hallé 13
  • 42. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / j XSylvain Hallé 13
  • 43. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / j X X OSylvain Hallé 13
  • 44. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / j X X X O O XSylvain Hallé 13
  • 45. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / j X X X O O XSylvain Hallé 13
  • 46. Direct violation A message m is a direct violation for a trace m if: . · m j and · . X and/ O mu st alternate 1 m .m j symbols n’t put two . 2. Ca in sa me square must be ually, there . 3. Event a line of three O’s X X X O O XSylvain Hallé 13
  • 47. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / j Hypothesis #1 The sender of m is responsible for the contract violation X X X O O XSylvain Hallé 13
  • 48. Direct violation A message m is a direct violation for a trace m if: . · m j and WAN TED · m .m / j Hypothesis #1 The sender of m is responsible for the contract violation r ‘‘O’’ Playe g the for violatin ntract int erface co X X X O O XSylvain Hallé 13
  • 49. Direct violation Another example: X X X O O X X O X O X O X O X O X O X O X O X X X O X O X O X O OX X OSylvain Hallé 14
  • 50. Direct violation Another example: X X X O O X X O X O X O X O X O X O X O X O X X X O X O X O X O OX X OSylvain Hallé 14
  • 51. Direct violation Another example: and O mu st alternate 1. X ls X o symbo n’t put tw . X X 2. Ca O O X in sa me square must be ually, there . 3. EveX tO n a li reeOO’s ne of th X O X X O X X O O X X O X O X O X O X X O X O OX X OSylvain Hallé 14
  • 52. Direct violation Another example: X X X O O X X O X O X O X O X O X O X O X O X X X O X O X O X O OX X OSylvain Hallé 14
  • 53. Direct violation Another example: WANTED X X X O O X X O X O X O X O X O X O X O X O X X X O X O Player ‘‘ X’’ for violating the interface contrac X O X t O OX X OSylvain Hallé 14
  • 54. Root violation A message m is a root violation for a trace m if: . · m j and · for any (infinite) suffix m’, we have m.m.m’ / jSylvain Hallé 15
  • 55. Root violation A message m is a root violation for a trace m if: . · m j and · for any (infinite) suffix m’, we have m.m.m’ / j Hypothesis #2: The sender of m is responsible for the contract violationSylvain Hallé 15
  • 56. Root violation X X X O O X X O X O X O X O X O X O X O X O X X X O X O X O X O OX X OSylvain Hallé 16
  • 57. Root violation X X X O O X X O X O X O X O X O X O X O X O X X X O X O X O X O OX X OSylvain Hallé 16
  • 58. Root violation WANTED X X X O O X X O X O X O X O X O X O X O X O X X X O X O Player ‘‘O’’ for violating the interface contrac X O X t O OX X OSylvain Hallé 16
  • 59. ObservationsSylvain Hallé 17
  • 60. Observations 1. Root violations capture the fact that direct violations are sometimes the result of a sequence of ‘‘forced moves’’ X O X O X O X O X X O X O X O X O X O X O OX X X O X O X OSylvain Hallé 17
  • 61. Observations 1. Root violations capture the fact that direct violations are sometimes the result of a sequence of ‘‘forced moves’’ X O X O X O X O X X O X O X O X O X O X O OX X X O X O X O . WANTED WANTED 2. The faulty peer may not be the same vs. as in an ensuing direct violationSylvain Hallé 17
  • 62. Observations 1. Root violations capture the fact that direct violations are sometimes the result of a sequence of ‘‘forced moves’’ X O X O X O X O X X O X O X O X O X O X O OX X X O X O X O . WANTED WANTED 2. The faulty peer may not be the same vs. as in an ensuing direct violation . 3. The interface contract is not contradictory in itself: a root violation depends on the actual course of actions takenSylvain Hallé 17
  • 63. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTLSylvain Hallé 18
  • 64. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j a b a b b aSylvain Hallé 18
  • 65. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) a b a b b aSylvain Hallé 18
  • 66. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M . a b a b b aSylvain Hallé 18
  • 67. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M . a b a b m=a a bSylvain Hallé 18
  • 68. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M . a b a b m=ab a bSylvain Hallé 18
  • 69. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M: discard any pointer to . a b a b m=ab a bSylvain Hallé 18
  • 70. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M: discard any pointer to . a b a b m=aba a bSylvain Hallé 18
  • 71. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M: discard any pointer to . a b 4. A message is a root violation if a no pointer is left b m=aba a bSylvain Hallé 18
  • 72. How to find root violations? Problem: · Designed for LTL a b a b b aSylvain Hallé 19
  • 73. How to find root violations? Problem: · Designed for LTL . · With LTL-FO+, M is infinite a b a b b aSylvain Hallé 19
  • 74. How to find root violations? Solution #2 Conversion to LTL 1. Bound the domains for each path expression . 2. Convert quantifiers into equivalent expressions If f(_, a/b) Í {1,2} , then "a/b x : F $ a/b y : x=y becomes ( F $ a/b y : 1=y ) Ù ( F $ a/b y : 2=y ) ...and so onSylvain Hallé 20
  • 75. How to find root violations? Solution #2 Conversion to LTL 3. The formula is now pure LTL; use solution #1 OR 4. Send messages one by one to an LTL model checkerSylvain Hallé 20
  • 76. How to find root violations? Solution #2 Conversion to LTL 3. The formula is now pure LTL; use solution #1 OR 4. Send messages one by one to an LTL model checker m1 j ?Sylvain Hallé 20
  • 77. How to find root violations? Solution #2 Conversion to LTL 3. The formula is now pure LTL; use solution #1 OR 4. Send messages one by one to an LTL model checker m1 j ? m1 m2 j ?Sylvain Hallé 20
  • 78. How to find root violations? Solution #2 Conversion to LTL 3. The formula is now pure LTL; use solution #1 OR 4. Send messages one by one to an LTL model checker m1 j ? m1 m2 j ? m1 m2 m3 j ?Sylvain Hallé 20
  • 79. How to find root violations? Solution #2 Conversion to LTL 3. The formula is now pure LTL; use solution #1 OR 4. Send messages one by one to an LTL model checker m1 j ? m1 m2 j ? m1 m2 m3 j ? The first message that causes the validation to fail is a root violationSylvain Hallé 20
  • 80. How to find root violations? Problem: · Requires bounded data domains · Exponential blow-up of formula · Non-incremental processSylvain Hallé 21
  • 81. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic .Sylvain Hallé 22
  • 82. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic . 1. Monitor state = set of LTL-FO+ formulas sSylvain Hallé 22
  • 83. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic . 1. Monitor state = set of LTL-FO+ formulas 2. Upon each new message: update state according to transformation rules sSylvain Hallé 22
  • 84. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic . 1. Monitor state = set of LTL-FO+ formulas 2. Upon each new message: update state according to transformation rules s s’Sylvain Hallé 22
  • 85. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic . 1. Monitor state = set of LTL-FO+ formulas 2. Upon each new message: update state according to transformation rules 3. Compute an outcome function on resulting state to decide if contract is violated s s’Sylvain Hallé 22
  • 86. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic . 1. Monitor state = set of LTL-FO+ formulas 2. Upon each new message: update state according to transformation rules 3. Compute an outcome function on resulting state to decide if contract is violated s’Sylvain Hallé 22
  • 87. Runtime monitoring Algorithm overview: 1. An LTL formula is decomposed into nodes of the form sub-formulas that sub-formulas that must must be true now be true in the next state Example:Sylvain Hallé 23
  • 88. Runtime monitoring 2. Negations pushed inside (classical identities + dual of U = V) 3. At the leaves, G contains atoms + negations of atoms: we evaluate them Verdict: ! All leaves contain FALSE: formula is false ! A leaf is empty: formula is true ! Otherwise: 4. Next event: D copied into G and we continueSylvain Hallé 24
  • 89. Runtime monitoring Example: G (a ® X Øa)Sylvain Hallé 25
  • 90. Runtime monitoring Example: G (a ® X Øa) G (a ® X Øa) ’ a ® X Øa ’ G (a ® X Øa) Øa ’ G (a ® X Øa) a, X Øa ’ G (a ® X Øa) a ’ G (a ® X Øa), ØaSylvain Hallé 25
  • 91. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) a ’ G (a ® X Øa), ØaSylvain Hallé 25
  • 92. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) a ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
  • 93. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) a ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
  • 94. Runtime monitoring Example: G (a ® X Øa) a ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
  • 95. Runtime monitoring Example: G (a ® X Øa) ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
  • 96. Runtime monitoring Example: G (a ® X Øa) G (a ® X Øa), Øa ’ ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
  • 97. Runtime monitoring Example: G (a ® X Øa) G (a ® X Øa), Øa ’ a ® X b, b ’ G (a ® X Øa) Øa ’ G (a ® X Øa) a, X Øa, Øa ’ G (a ® X Øa) a, Øa ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
  • 98. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) a, Øa ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
  • 99. Runtime monitoring Example: G (a ® X Øa) A variable and its negation can never be true at the same time Øa ’ G (a ® X Øa) a, Øa ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
  • 100. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) a, Øa ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
  • 101. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) s=aSylvain Hallé 25
  • 102. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) s = aaSylvain Hallé 25
  • 103. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) s = aaSylvain Hallé 25
  • 104. Runtime monitoring Example: G (a ® X Øa) No way to extend the trace: formula is false, i.e. message c is a direct violation of the formula s = aaSylvain Hallé 25
  • 105. Detecting direct violations By construction (Gerth et al., PSTV 1995): Let N = be a monitor node resulting from the processing of a message m. The message is a direct violation of the conditions in N if and only if it contains p Ù Øp for some proposition p.Sylvain Hallé 26
  • 106. Detecting direct violations By construction (Gerth et al., PSTV 1995): Let N = be a monitor node resulting from the processing of a message m. The message is a direct violation of the conditions in N if and only if it contains p Ù Øp for some proposition p. Consequence m is a direct violation if this happens for all leaf nodesSylvain Hallé 26
  • 107. Detecting root violations Theorem Let N = be a monitor node resulting from the processing of a message m. The message is a root violation of the conditions in N if and only if the formula ( Ù G ) Ù X( Ù D ) is unsatisfiable. (See paper for the proof!)Sylvain Hallé 27
  • 108. Detecting root violations Theorem Let N = be a monitor node resulting from the processing of a message m. The message is a root violation of the conditions in N if and only if the formula ( Ù G ) Ù X( Ù D ) is unsatisfiable. (See paper for the proof!) Consequence m is a root violation if this happens for all leaf nodesSylvain Hallé 27
  • 109. Intuition 1. In the algorithm, each leaf node represents a possible set of conditions for a valid extension of the current trace sub-formulas that sub-formulas that must must be true now be true in the next state 2. If the conditions are contradictory, no trace extension can ever satisfy them . Ù 3. The formula p Ù Øp is a special case of ( G ) Ù X( Ù D), where the contradiction occurs in the current message . 4. Detection of root violations reduces to satisfiability solving of some set of LTL formulasSylvain Hallé 28
  • 110. Adding first-order quantifiers Decomposition rules can be added to deal with LTL-FO+; the definition of root violation does not change 1. Atoms become equality tests (and vice versa) 2. Decomposition rules for quantifiersSylvain Hallé 29
  • 111. A workflow for root violation detectionSylvain Hallé 30
  • 112. A workflow for root violation detection 1 1 ... n n } Leaf nodes from current monitor stateSylvain Hallé 30
  • 113. A workflow for root violation detection 1 1 ... n n } m Incoming messageSylvain Hallé 30
  • 114. A workflow for root violation detection 1 1 ... n n } m UPDATE Monitor update functionSylvain Hallé 30
  • 115. A workflow for root violation detection 1 1 ... n n } } 1 1 ... m UPDATE k k New leaf nodesSylvain Hallé 30
  • 116. A workflow for root violation detection Node sent to LTL-FO+ 1 1 ... n n satisfiability solver } } 1 1 S ... m UPDATE k kSylvain Hallé 30
  • 117. A workflow for root violation detection ... Kept if 1 1 n n satisfiable } } 1 1 S SAT 1 1 ... m UPDATE k kSylvain Hallé 30
  • 118. A workflow for root violation detection 1 1 ... n n } } 1 1 S UNSAT SAT 1 1 ... m UPDATE X Deleted if not k kSylvain Hallé 30
  • 119. A workflow for root violation detection 1 1 ... n n } } 1 1 S UNSAT SAT 1 1 ... m UPDATE X UNSAT k k S SAT k k Repeat for every nodeSylvain Hallé 30
  • 120. A workflow for root violation detection 1 1 ... n n } } 1 1 S UNSAT SAT 1 1 ... m UPDATE X UNSAT k k S SAT k k New monitor nodesSylvain Hallé 30
  • 121. A workflow for root violation detection 1 1 ... n n } } 1 1 S UNSAT SAT 1 1 ... m UPDATE X UNSAT k k S SAT k k Declare root violation if no node remains after pruningSylvain Hallé 30
  • 122. Experimental setup BeepBeep (Hallé & Villemaire, 2011) used as the LTL-FO+ runtime monitor TSPASS (Ludwig & Hustadt, 2010) used as the S temporal satisfiability solver 100 randomly-generated traces of shopping cart transactions Validation of the shopping cart contractSylvain Hallé 31
  • 123. Experimental results Experiment 1: overhead incurred by use of a solver Solver time: 40 13 ms / message Number of traces 30 20 10 0 <1 1-2 2-3 3-4 >4 OverheadSylvain Hallé 32
  • 124. Experimental results Experiment 2: difference (in messages) between root and direct violation 80 Number of traces 60 Violation detected ‘‘in advance’’: 18% 40 less messages consumed 20 0 0 1-5 6-10 11-15 16-20 Length differenceSylvain Hallé 33
  • 125. Future work The concept of violation is a parameterized one: s s’Sylvain Hallé 34
  • 126. Future work The concept of violation is a parameterized one: Call an error when the current trace cannot be extended by at least n suffixes with at least k messages s s’Sylvain Hallé 34
  • 127. Future work The concept of violation is a parameterized one: k = ‘‘lookahead’’ n = ‘‘degree of freedom’’ Call an error when the current trace cannot be extended by at least n suffixes with at least k messages s s’Sylvain Hallé 34
  • 128. Future work The concept of violation is a parameterized one: k = ‘‘lookahead’’ n = ‘‘degree of freedom’’ Call an error when · Direct violation the current trace cannot be extended by at least n=1, k=1 n suffixes with at least k messages s s’Sylvain Hallé 34
  • 129. Future work The concept of violation is a parameterized one: k = ‘‘lookahead’’ n = ‘‘degree of freedom’’ Call an error when · Direct violation the current trace cannot be extended by at least n=1, k=1 n suffixes with at least k messages · Root cause s n=1, k=¥ s’Sylvain Hallé 34
  • 130. Take-home points 1. The peer responsible for an interface contract violation may not cause it directly . 2. A root violation occurs when no infinite extension of the current transaction can ever fulfill an interface contract . 3. Using LTL-FO+ as the specification language, reduction to the propositional case results in an infinite search problem . 4. Leveraging on a runtime monitoring algorithm, root cause detection reduces to satisfiability solving . 5. An experimental setup can detect direct violations ahead of time with reasonable overheadSylvain Hallé 35