Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Thesis Defense: Integration of Modeling Methods for Cyber-Physical Systems

100 visualizaciones

Publicado el

A slide deck from my PhD thesis defense.

The video of the defense talk can be seen here: https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=aebd3567-e42b-4281-94a7-a98f011d1268

Abstract: "Cyber-physical systems (CPS) incorporate digital (cyber) and mechanical (physical) elements that interact in complex ways. Many safety-critical CPS, such as autonomous vehicles and drones, are becoming increasingly widespread and hence demand rigorous quality assurance. To this end, CPS engineering relies on modeling methods, which use models to represent the system and design-time analyses to interpret/change the models. Coming from diverse scientific and engineering fields, these modeling methods are difficult to combine, or integrate, due to implicit relations and dependencies between them. CPS failures can lead to substantial damage or loss of life, and are often due to two key integration challenges: (i) inconsistencies between models — contradictions in models that do not add up to a cohesive design, and (ii) incorrect interactions of analyses — out-of-order executions in mismatched contexts, leading to erroneous analysis outputs.

This thesis presents a novel approach to detect and prevent integration issues between CPS modeling methods during the design phase. To detect inconsistencies between models, the approach allows engineers to specify integration properties — quantified logical statements that relate various elements of multiple models — in the Integration Property Language (IPL). IPL statements describe verifiable conditions that are equivalent to an absence of inconsistencies. To interface with the models, IPL relies on integration abstractions — simplified representations of models for integration purposes. Two abstractions are proposed in this thesis: views (annotated component-and-connector models, inspired by software architecture) and behavioral properties (expressions in model-specific languages, such as the linear temporal logic). Combining these abstractions enables engineers to mix model structure and behavior in IPL statements. To ensure correct interactions of analyses, I introduce analysis contracts — a lightweight specification that captures inputs, outputs, assumptions, and guarantees for each analysis, in terms of the integration abstractions. Given these contracts, an analysis execution platform performs analyses in the order of their dependencies, and only in contexts that guarantee correct outputs.

My approach to integration was validated on four case studies of CPS modeling methods in different systems: energy-aware planning in a mobile robot, collision avoidance in a mobile robot, thread/battery scheduling in a quadrotor, and reliable/secure sensing in an autonomous vehicle. The validation has shown that the approach supports expressive integration properties, which can be soundly checked within practical constraints, all while being customizable to diverse models, analyses, and domains."


Publicado en: Software
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Thesis Defense: Integration of Modeling Methods for Cyber-Physical Systems

  1. 1. Thesis Defense, PhD in Software EngineeringThesis Defense, PhD in Software Engineering Institute for Software ResearchInstitute for Software Research Carnegie Mellon UniversityCarnegie Mellon University November 8, 2018November 8, 2018 Thesis committee: David Garlan (chair) André Platzer Bruce Krogh Dionisio de Niz John Day Integration of Modeling Methods forIntegration of Modeling Methods for Cyber-Physical SystemsCyber-Physical Systems Ivan RuchkinIvan Ruchkin
  2. 2. 2 Cyber-physical systems (CPS)Cyber-physical systems (CPS)
  3. 3. 3 CPS continue to failCPS continue to fail
  4. 4. 4 CPS continue to failCPS continue to fail
  5. 5. 5 CPS design relies on multiple modelsCPS design relies on multiple models
  6. 6. 6 CPS design relies on multiple modelsCPS design relies on multiple models Model A
  7. 7. 7 CPS design relies on multiple modelsCPS design relies on multiple models Model A Artifact
  8. 8. 8 CPS design relies on multiple modelsCPS design relies on multiple models Model A Model B Artifact
  9. 9. 9 CPS design relies on multiple modelsCPS design relies on multiple models Model A Model B Artifact Certificate
  10. 10. 10 Two issues lead to CPS failuresTwo issues lead to CPS failures
  11. 11. 11 Two issues lead to CPS failuresTwo issues lead to CPS failures 1. Inconsistencies between models
  12. 12. 12 Two issues lead to CPS failuresTwo issues lead to CPS failures 1. Inconsistencies between models 2. Incorrect interactions between analyses – Out-of-order executions – Out-of-context executions
  13. 13. 13 Two issues lead to CPS failuresTwo issues lead to CPS failures 1. Inconsistencies between models 2. Incorrect interactions between analyses – Out-of-order executions – Out-of-context executions
  14. 14. 14 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model B Artifact Certificate
  15. 15. 15 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model B Artifact Certificate
  16. 16. 16 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate
  17. 17. 17 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate
  18. 18. 18 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate Inconsistent
  19. 19. 19 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate Inconsistent
  20. 20. 20 Example: inconsistency between modelsExample: inconsistency between models
  21. 21. 21 Example: inconsistency between modelsExample: inconsistency between models Mobile robot
  22. 22. 22 Example: inconsistency between modelsExample: inconsistency between models Power model Mobile robot
  23. 23. 23 Example: inconsistency between modelsExample: inconsistency between models Power model Planning model Mobile robot
  24. 24. 24 Example: inconsistency between modelsExample: inconsistency between models Potential inconsistency: different estimated energy costs Power model Planning model Mobile robot
  25. 25. 25 Two issues lead to CPS failuresTwo issues lead to CPS failures 1. Inconsistencies between models 2. Incorrect interactions between analyses – Out-of-order executions – Out-of-context executions
  26. 26. 26 Two issues lead to CPS failuresTwo issues lead to CPS failures 1. Inconsistencies between models 2. Incorrect interactions between analyses – Out-of-order executions – Out-of-context executions
  27. 27. 27 Two issues lead to CPS failuresTwo issues lead to CPS failures 1. Inconsistencies between models 2. Incorrect interactions between analyses – Out-of-order executions – Out-of-context executions
  28. 28. 28 CPS design relies on multiple modelsCPS design relies on multiple models Model A Model relation Model B Artifact Certificate
  29. 29. 29 CPS design relies on multiple analysesCPS design relies on multiple analyses Analysis A Analysis B
  30. 30. 30 Two issues lead to CPS failuresTwo issues lead to CPS failures 1. Inconsistencies between models 2. Incorrect interactions between analyses – Out-of-order executions – Out-of-context executions
  31. 31. 31 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A Analysis B
  32. 32. 32 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A Analysis B
  33. 33. 33 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis B
  34. 34. 34 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B
  35. 35. 35 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B A nalysis dependency
  36. 36. 36 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B #3 #2 #1
  37. 37. 37 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B #3 #2 #1
  38. 38. 38 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B #3 #2 #1
  39. 39. 39 Two issues lead to CPS failuresTwo issues lead to CPS failures 1. Inconsistencies between models 2. Incorrect interactions between analyses – Out-of-order executions – Out-of-context executions
  40. 40. 40 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B
  41. 41. 41 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2
  42. 42. 42 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’
  43. 43. 43 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’ Context of analysis
  44. 44. 44 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’ Context of analysis
  45. 45. 45 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’ Context of analysis
  46. 46. 46 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’ Context of analysis
  47. 47. 47 Issues reframed with modeling methodsIssues reframed with modeling methods
  48. 48. 48 Issues reframed with modeling methodsIssues reframed with modeling methods A modeling method – a model and its analyses Problem: ad hoc, informal combinations of CPS modeling methods lead to: + =
  49. 49. 49 Issues reframed with modeling methodsIssues reframed with modeling methods A modeling method – a model and its analyses Problem: ad hoc, informal combinations of CPS modeling methods lead to: A. Model inconsistencies B. Out-of-order analysis execution C. Out-of-context analysis execution + =
  50. 50. 50 SummarySummary Problem Thesis overview In-depth approach Validation
  51. 51. 51 AgendaAgenda Problem Thesis overview In-depth approach Validation
  52. 52. 52 Integration detects and prevents errorsIntegration detects and prevents errors Problem: ad hoc, informal combinations of CPS modeling methods lead to: A. Model inconsistencies B. Out-of-order analysis execution C. Out-of-context analysis execution + =
  53. 53. 53 Integration detects and prevents errorsIntegration detects and prevents errors Problem: ad hoc, informal combinations of CPS modeling methods lead to: A. Model inconsistencies B. Out-of-order analysis execution C. Out-of-context analysis execution Approach: integration of modeling methods detects A and prevents B & C + =
  54. 54. 54 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  55. 55. 55 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  56. 56. 56 Qualities of integrationQualities of integration
  57. 57. 57 Qualities of integrationQualities of integration Expressiveness – Handles complex relations of structures & behaviors
  58. 58. 58 Qualities of integrationQualities of integration Expressiveness – Handles complex relations of structures & behaviors Soundness – Delivers trustworthy results
  59. 59. 59 Qualities of integrationQualities of integration Expressiveness – Handles complex relations of structures & behaviors Soundness – Delivers trustworthy results Applicability – Useful in practice: scalable, flexible, finds/prevents errors
  60. 60. 60 Qualities of integrationQualities of integration Expressiveness – Handles complex relations of structures & behaviors Soundness – Delivers trustworthy results Applicability – Useful in practice: scalable, flexible, finds/prevents errors Customizability – Can be tailored to the domain and the system
  61. 61. 61 Existing approaches fall shortExisting approaches fall short
  62. 62. 62 Existing approaches fall shortExisting approaches fall short Approach Expressive? Sound? Applicable? Customizable? Ad hoc, system-specific ✓ ✓ Single model ✓ ✓ Frameworks ✓ ✓ ✓ My approach ✓ ✓ ✓ ✓
  63. 63. 63 Existing approaches fall shortExisting approaches fall short Approach Expressive? Sound? Applicable? Customizable? Ad hoc, system-specific ✓ ✓ Single model ✓ ✓ Frameworks ✓ ✓ ✓ My approach ✓ ✓ ✓ ✓
  64. 64. 64 Existing approaches fall shortExisting approaches fall short Approach Expressive? Sound? Applicable? Customizable? Ad hoc, system-specific ✓ ✓ Single model, single analysis ✓ ✓ Frameworks ✓ ✓ ✓ My approach ✓ ✓ ✓ ✓
  65. 65. 65 Existing approaches fall shortExisting approaches fall short Approach Expressive? Sound? Applicable? Customizable? Ad hoc, system-specific ✓ ✓ Single model, single analysis ✓ ✓ Frameworks ✓ ✓ ✓ My approach ✓ ✓ ✓ ✓
  66. 66. 66 Existing approaches fall shortExisting approaches fall short Approach Expressive? Sound? Applicable? Customizable? Ad hoc, system-specific ✓ ✓ Single model, single analysis ✓ ✓ Frameworks ✓ ✓ ✓ My approach ✓ ✓ ✓ ✓
  67. 67. 67 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  68. 68. 68 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  69. 69. 69 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  70. 70. 70 Integration approachIntegration approach
  71. 71. 71 Integration approachIntegration approach
  72. 72. 72 Integration approachIntegration approach
  73. 73. 73 Integration approachIntegration approach
  74. 74. 74 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  75. 75. 75 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  76. 76. 76 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  77. 77. 77 Integration approachIntegration approach
  78. 78. 78 Integration approachIntegration approach
  79. 79. 79 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related
  80. 80. 80 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related Model relation
  81. 81. 81 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related Model relation Specification
  82. 82. 82 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related Model relation Specification
  83. 83. 83 Integration argument for consistencyIntegration argument for consistency If: Integration properties express the intended consistency Abstractions are correct (defined later) Verification of integration properties is sound Then: The models are consistent iff the integration properties hold
  84. 84. 84 Integration argument for consistencyIntegration argument for consistency If: – Integration properties express the intended consistency Abstractions are correct (defined later) Verification of integration properties is sound Then: The models are consistent iff the integration properties hold
  85. 85. 85 Integration argument for consistencyIntegration argument for consistency If: – Integration properties express the intended consistency – Abstractions are correct (defined later) Verification of integration properties is sound Then: The models are consistent iff the integration properties hold
  86. 86. 86 Integration argument for consistencyIntegration argument for consistency If: – Integration properties express the intended consistency – Abstractions are correct (defined later) – Verification of integration properties is sound Then: The models are consistent iff the integration properties hold
  87. 87. 87 Integration argument for consistencyIntegration argument for consistency If: – Integration properties express the intended consistency – Abstractions are correct (defined later) – Verification of integration properties is sound Then: – The models are consistent iff the integration properties hold
  88. 88. 88 Example: detecting inconsistencyExample: detecting inconsistency Potential inconsistency: different estimated energy costs Power model Planning model
  89. 89. 89 Example: detecting inconsistencyExample: detecting inconsistency Potential inconsistency: different estimated energy costs Integration property: “the difference in energy estimates should not be greater than a predefined constant” Power model Planning model
  90. 90. 90 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  91. 91. 91 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  92. 92. 92 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  93. 93. 93 Integration approachIntegration approach
  94. 94. 94 Analyses change models/abstractionsAnalyses change models/abstractions
  95. 95. 95 Contracts capture analysis meta-infoContracts capture analysis meta-info
  96. 96. 96 Thesis statementThesis statement “Four qualities of modeling method integration for CPS — expressiveness, soundness, applicability, and customizability — are enabled by an approach based on three parts: 1. Two integration abstractions: views and behavioral properties, 2. Specification and verification of multi-model integration properties, 3. Execution of analyses based on analysis contracts.”
  97. 97. 97 AgendaAgenda Problem Thesis overview In-depth approach Validation
  98. 98. 98 AgendaAgenda Problem Thesis overview In-depth approach Validation
  99. 99. 99 AgendaAgenda Problem Thesis overview In-depth approach Validation
  100. 100. 100 Integration approachIntegration approach
  101. 101. 101 Part 1: views & behavioral propertiesPart 1: views & behavioral properties
  102. 102. 102 Two important aspects of modelsTwo important aspects of models
  103. 103. 103 Two important aspects of modelsTwo important aspects of models Model A
  104. 104. 104 Two important aspects of modelsTwo important aspects of models Model A Structures in model A
  105. 105. 105 Two important aspects of modelsTwo important aspects of models Model BModel A Structures in model A
  106. 106. 106 Two important aspects of modelsTwo important aspects of models Model B Behaviors in model B Model A Structures in model A
  107. 107. 107 Two important aspects of modelsTwo important aspects of models Model B Behaviors in model B Model A Structures in model A
  108. 108. 108 Views represent static structuresViews represent static structures Idea: extract simple structures from models through a unified representation Views: Component-and-connector models Customized with types and element properties (name- value pairs)
  109. 109. 109 Views represent static structuresViews represent static structures Idea: extract simple structures from models through a unified representation Views – Component-and-connector models Customized with types and element properties (name- value pairs)
  110. 110. 110 Views represent static structuresViews represent static structures Idea: extract simple structures from models through a unified representation Views – Component-and-connector models – Customized with types and element properties (name- value pairs)
  111. 111. 111 Views represent static structuresViews represent static structures Idea: extract simple structures from models through a unified representation Views – Component-and-connector models – Customized with types and element properties (name- value pairs) Type: CPU ID: “cpu1” Frequency: 1.7 Ghz
  112. 112. 112 Example: view for power modelExample: view for power model Mobile robot Power model tim e speed energy
  113. 113. 113 Example: view for power modelExample: view for power model Map model Mobile robot Power model tim e speed energy
  114. 114. 114 Example: view for power modelExample: view for power model Map model Mobile robot Power model tim e speed energy View: energies for robot tasks available on a map
  115. 115. 115 Example: view for power modelExample: view for power model Map model Mobile robot Power model tim e speed energy View: energies for robot tasks available on a map
  116. 116. 116 Example: view with robot tasksExample: view with robot tasks
  117. 117. 117 Example: view with robot tasksExample: view with robot tasks
  118. 118. 118 Example: view with robot tasksExample: view with robot tasks
  119. 119. 119 What is a correct view?What is a correct view? Sound: Every view element relates to relevant model elements Complete: Every relevant model element is represented
  120. 120. 120 What is a correct view?What is a correct view? Sound: Every view element relates to relevant model elements Complete: Every relevant model element is represented Correct: View Model
  121. 121. 121 What is a correct view?What is a correct view? Sound: – Every view element relates to relevant model elements Complete: Every relevant model element is represented Correct: View Model
  122. 122. 122 What is a correct view?What is a correct view? Sound: – Every view element relates to relevant model elements Complete: Every relevant model element is represented Correct: Unsound: View Model
  123. 123. 123 What is a correct view?What is a correct view? Sound: – Every view element relates to relevant model elements Complete: – Every relevant model element is represented Correct: Unsound: View Model
  124. 124. 124 What is a correct view?What is a correct view? Sound: – Every view element relates to relevant model elements Complete: – Every relevant model element is represented Correct: Incomplete: Unsound: View Model
  125. 125. 125 Two important aspects of modelsTwo important aspects of models Model B Behaviors in model B Model A Structures in model A
  126. 126. 126 Behavioral properties query behaviorsBehavioral properties query behaviors
  127. 127. 127 Behavioral properties query behaviorsBehavioral properties query behaviors Idea: use existing property languages as interfaces to models/behaviors – E.g., the linear temporal logic (LTL) Behavioral properties Expressions in model-specific languages Indirectly query/constrain behaviors of models G (P ⇒ Q ∧ R)
  128. 128. 128 Behavioral properties query behaviorsBehavioral properties query behaviors Idea: use existing property languages as interfaces to models/behaviors – E.g., the linear temporal logic (LTL) Behavioral properties – Expressions in model-specific languages over behaviors – Enable queries to compute the value of an expression G (P ⇒ Q ∧ R)
  129. 129. 129 Behavioral properties query behaviorsBehavioral properties query behaviors Idea: use existing property languages as interfaces to models/behaviors – E.g., the linear temporal logic (LTL) Behavioral properties – Expressions in model-specific languages over behaviors – Enable queries to compute the value of an expression G (P ⇒ Q ∧ R) Behavioral property Behavioral property language queries Model Behaviors is computed by
  130. 130. 130 Example: behavioral property in PCTLExample: behavioral property in PCTL Using probabilistic computation tree logic (PCTL)
  131. 131. 131 Example: behavioral property in PCTLExample: behavioral property in PCTL Mobile robot Planning model Using probabilistic computation tree logic (PCTL)
  132. 132. 132 Example: behavioral property in PCTLExample: behavioral property in PCTL Mobile robot Planning model All possible paths of the robot Using probabilistic computation tree logic (PCTL)
  133. 133. 133 Example: behavioral property in PCTLExample: behavioral property in PCTL Mobile robot Planning model All possible paths of the robot PCTL property Using probabilistic computation tree logic (PCTL)
  134. 134. 134 Example: behavioral property in PCTLExample: behavioral property in PCTL Query: compute the “maximum probability of the robot moving straight-turn-straight (t1 t→ 2 t→ 3)”
  135. 135. 135 Example: behavioral property in PCTLExample: behavioral property in PCTL Query: compute the “maximum probability of the robot moving straight-turn-straight (t1 t→ 2 t→ 3)” PCTL property
  136. 136. 136 Example: behavioral property in PCTLExample: behavioral property in PCTL Query: compute the “maximum probability of the robot moving straight-turn-straight (t1 t→ 2 t→ 3)” “…completing t1 , t2 , and t3 ” “Maximum probability of…” PCTL property
  137. 137. 137 What is a correct behavioral query?What is a correct behavioral query?
  138. 138. 138 What is a correct behavioral query?What is a correct behavioral query? It is sound: – The returned value corresponds to the model’s semantics Behavioral property Model
  139. 139. 139 What is a correct behavioral query?What is a correct behavioral query? It is sound: – The returned value corresponds to the model’s semantics It terminates: – Each query eventually returns a value Behavioral property Model Behavioral property Model
  140. 140. 140 Part 1: views & behavioral propertiesPart 1: views & behavioral properties
  141. 141. 141 Part 2: Integration Property LanguagePart 2: Integration Property Language
  142. 142. 142 Part 2: Integration Property LanguagePart 2: Integration Property Language
  143. 143. 143 Integration Property Language (IPL)Integration Property Language (IPL) Idea: specify integration properties as mutual constraints on views and behaviors
  144. 144. 144 Integration Property Language (IPL)Integration Property Language (IPL) Idea: specify integration properties as mutual constraints on views and behaviors Behavioral property View
  145. 145. 145 Integration Property Language (IPL)Integration Property Language (IPL) Idea: specify integration properties as mutual constraints on views and behaviors Behavioral property IPL formula View
  146. 146. 146 Integration Property Language (IPL)Integration Property Language (IPL) Idea: specify integration properties as mutual constraints on views and behaviors – Views are constrained via types/element property names Behavioral property IPL formulaconstrains View
  147. 147. 147 Integration Property Language (IPL)Integration Property Language (IPL) Idea: specify integration properties as mutual constraints on views and behaviors – Views are constrained via types/element property names – Behaviors are constrained by using behavioral properties as sub-formulas Behavioral property IPL formulaconstrains incorporates View
  148. 148. 148 Example: integration property in IPLExample: integration property in IPL Potential inconsistency: different estimated energy costs Integration property: “the difference in energy estimates should not be greater than a predefined constant” Power model Planning model
  149. 149. 149 Example: integration property in IPLExample: integration property in IPL Integration property: “the difference in energy estimates should not be greater than a predefined constant” Power model Planning model
  150. 150. 150 Example: integration property in IPLExample: integration property in IPL Integration property: “the difference in energy estimates should not be greater than a predefined constant” Power model Planning model PCTL property ... Robot task view
  151. 151. 151 Example: integration property in IPLExample: integration property in IPL Integration property: “the difference in energy estimates should not be greater than a predefined constant” Power model Planning model Robot task view PCTL property ...
  152. 152. 152 Example: integration property in IPLExample: integration property in IPL
  153. 153. 153 Example: integration property in IPLExample: integration property in IPL “For any three tasks from the task view that ― form a straight-turn-straight, non-intersecting sequence, and ― have sufficient energy, any execution of the planning model that ― visits the locations in the order and ― is initialized appropriately (required energy modulo err_cons), does not run out of power.”
  154. 154. 154 Example: integration property in IPLExample: integration property in IPL “For any three tasks from the task view that ― form a straight-turn-straight sequence and ― have sufficient energy, any execution of the planning model that ― visits the locations in the order and ― is initialized appropriately (required energy modulo err_cons), does not run out of power.”
  155. 155. 155 Example: integration property in IPLExample: integration property in IPL “For any three tasks from the task view that ― form a straight-turn-straight sequence and ― have sufficient energy, any execution of the planning model that ― visits the locations in the order and ― has initial energy = required energy does not run out of power.”
  156. 156. 156 Example: integration property in IPLExample: integration property in IPL “For any three tasks from the task view that ― form a straight-turn-straight sequence and ― have sufficient energy, any execution of the planning model that ― visits the locations in the order and ― has initial energy = required energy does not run out of power.”
  157. 157. 157 Example: integration property in IPLExample: integration property in IPL “For any three tasks from the task view that ― form a straight-turn-straight sequence and ― have sufficient energy, any execution of the planning model that ― visits the locations in the order and ― has initial energy = required energy does not run out of power.”
  158. 158. 158 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
  159. 159. 159 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
  160. 160. 160 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
  161. 161. 161 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
  162. 162. 162 Verification algorithm checks formulasVerification algorithm checks formulas
  163. 163. 163 Verification algorithm checks formulasVerification algorithm checks formulas IPL verification: views, models ⊨ formula Quant·rigid&flexible
  164. 164. 164 Verification algorithm checks formulasVerification algorithm checks formulas IPL verification: views, models ⊨ formula Formula transformations: to PNF, removal of quantifiers, abstraction of model subformulas (MS) Functional abstraction (FA): MS uninterpreted f-ns→ Constant abstraction (CA): MS uninterpreted consts→ Quant·rigid&flexible rigid&FA(var) rigid&CA
  165. 165. 165 Verification algorithm checks formulasVerification algorithm checks formulas IPL verification: views, models ⊨ formula Formula transformations: to PNF, removal of quantifiers, abstraction of model subformulas (MS) Functional abstraction (FA): MS uninterpreted f-ns→ Saturation with SMT (on views): find all free var solutions for FA ≠ CA Constant abstraction (CA): MS uninterpreted consts→ Quant·rigid&flexible rigid&FA(var) rigid&CA rigid&FA(var)≠ rigid&CA
  166. 166. 166 Verification algorithm checks formulasVerification algorithm checks formulas IPL verification: views, models ⊨ formula Formula transformations: to PNF, removal of quantifiers, abstraction of model subformulas (MS) Functional abstraction (FA): MS uninterpreted f-ns→ Saturation with SMT (on views): find all free var solutions for FA ≠ CA Model checking (on models): interpret FA on the above solutions Constant abstraction (CA): MS uninterpreted consts→ Quant·rigid&flexible rigid&FA(var) rigid&CA rigid&FA(var)≠ rigid&CA flexible(var)
  167. 167. 167 Verification algorithm checks formulasVerification algorithm checks formulas IPL verification: views, models ⊨ formula Formula transformations: to PNF, removal of quantifiers, abstraction of model subformulas (MS) Functional abstraction (FA): MS uninterpreted f-ns→ Saturation with SMT (on views): find all free var solutions for FA ≠ CA Model checking (on models): interpret FA on the above solutions Final check (on views): check quantified FA conjoined with the above interpretations Constant abstraction (CA): MS uninterpreted consts→ Quant·rigid&flexible rigid&FA(var) rigid&CA rigid&FA(var)≠ rigid&CA flexible(var) Quant·rigid&FA(var)
  168. 168. 168 Verification algorithm checks formulasVerification algorithm checks formulas IPL verification: views, models ⊨ formula Formula transformations: to PNF, removal of quantifiers, abstraction of model subformulas (MS) Functional abstraction (FA): MS uninterpreted f-ns→ Saturation with SMT (on views): find all free var solutions for FA ≠ CA Model checking (on models): interpret FA on the above solutions Final check (on views): check quantified FA conjoined with the above interpretations Constant abstraction (CA): MS uninterpreted consts→ Quant·rigid&flexible rigid&FA(var) rigid&CA rigid&FA(var)≠ rigid&CA flexible(var) Quant·rigid&FA(var) Detection of model inconsistencies
  169. 169. 169 Part 2: Integration Property LanguagePart 2: Integration Property Language
  170. 170. 170 Part 3: analysis contracts & executionPart 3: analysis contracts & execution
  171. 171. 171 Part 3: analysis contracts & executionPart 3: analysis contracts & execution
  172. 172. 172 Contracts capture meta-info about analysesContracts capture meta-info about analyses Assumptions = {…}, Guarantees = {…} Assumptions = {…}, Guarantees = {…}
  173. 173. 173 Contracts capture meta-info about analysesContracts capture meta-info about analyses Assumptions = {…}, Guarantees = {…} Assumptions = {…}, Guarantees = {…} Idea: capture meta-information about analyses to prevent incorrect analysis interactions → assumptions/guarantees
  174. 174. 174 Contracts capture meta-info about analysesContracts capture meta-info about analyses Assumptions = {…}, Guarantees = {…} Assumptions = {…}, Guarantees = {…} Idea: capture meta-information about analyses to prevent incorrect analysis interactions – Out-of-order executions – Out-of-context executions → assumptions/guarantees
  175. 175. 175 Contracts capture meta-info about analysesContracts capture meta-info about analyses Bin packing Assumptions = {…}, Guarantees = {…} Assumptions = {…}, Guarantees = {…} Idea: capture meta-information about analyses to prevent incorrect analysis interactions – Out-of-order executions – Out-of-context executions → assumptions/guarantees
  176. 176. 176 Contracts capture meta-info about analysesContracts capture meta-info about analyses Bin packing Assumptions = {…}, Guarantees = {…} Assumptions = {…}, Guarantees = {…} Idea: capture meta-information about analyses to prevent incorrect analysis interactions – Out-of-order executions → i/o dependencies – Out-of-context executions → assumptions/guarantees
  177. 177. 177 Contracts capture meta-info about analysesContracts capture meta-info about analyses Bin packing Contract: Inputs = {CPUs, CPU bindings, …} Outputs = {CPU frequencies} Assumptions = {…}, Guarantees = {…} Assumptions = {…}, Guarantees = {…} Idea: capture meta-information about analyses to prevent incorrect analysis interactions – Out-of-order executions → i/o dependencies – Out-of-context executions → assumptions/guarantees
  178. 178. 178 Contracts capture meta-info about analysesContracts capture meta-info about analyses Bin packing Contract: Inputs = {CPUs, CPU bindings, …} Outputs = {CPU frequencies} Assumptions = {…}, Guarantees = {…} Contract: Inputs = {Threads, CPUs, …} Outputs = {CPU bindings} Assumptions = {…}, Guarantees = {…} Idea: capture meta-information about analyses to prevent incorrect analysis interactions – Out-of-order executions → i/o dependencies – Out-of-context executions → assumptions/guarantees
  179. 179. 179 Contracts capture meta-info about analysesContracts capture meta-info about analyses Bin packing Contract: Inputs = {CPUs, CPU bindings, …} Outputs = {CPU frequencies} Assumptions = {…}, Guarantees = {…} Contract: Inputs = {Threads, CPUs, …} Outputs = {CPU bindings} Assumptions = {…}, Guarantees = {…} depends on Idea: capture meta-information about analyses to prevent incorrect analysis interactions – Out-of-order executions → i/o dependencies – Out-of-context executions → assumptions/guarantees
  180. 180. 180 Contracts capture meta-info about analysesContracts capture meta-info about analyses Bin packing Contract: Inputs = {CPUs, CPU bindings, …} Outputs = {CPU frequencies} Assumptions = {…}, Guarantees = {…} Contract: Inputs = {Threads, CPUs, …} Outputs = {CPU bindings} Assumptions = {…}, Guarantees = {…} depends on Idea: capture meta-information about analyses to prevent incorrect analysis interactions – Out-of-order executions → i/o dependencies – Out-of-context executions → assumptions/guarantees
  181. 181. 181 Contracts capture meta-info about analysesContracts capture meta-info about analyses Bin packing Contract: Inputs = {CPUs, CPU bindings, …} Outputs = {CPU frequencies} Assumptions = {…}, Guarantees = {…} Contract: Inputs = {Threads, CPUs, …} Outputs = {CPU bindings} Assumptions = {…}, Guarantees = {…} depends on Idea: capture meta-information about analyses to prevent incorrect analysis interactions – Out-of-order executions → i/o dependencies – Out-of-context executions → assumptions/guarantees
  182. 182. 182 Execution platform prevents errorsExecution platform prevents errors Goal: execute the target analysis without incorrect interactions
  183. 183. 183 Execution platform prevents errorsExecution platform prevents errors Goal: execute the target analysis without incorrect interactions Input: – Set of analyses annotated with contracts – The target analysis
  184. 184. 184 Execution platform prevents errorsExecution platform prevents errors Input: – Set of analyses annotated with contracts – The target analysis
  185. 185. 185 Execution platform prevents errorsExecution platform prevents errors Input: – Set of analyses annotated with contracts – The target analysis Check assumptions (if failed, abort) Perform the analysis Check guarantees (if failed, reverse the effects and abort) A4 A1 A3 A4A2
  186. 186. 186 Execution platform prevents errorsExecution platform prevents errors Input: – Set of analyses annotated with contracts – The target analysis Algorithm: Check assumptions (if failed, abort) Perform the analysis Check guarantees (if failed, reverse the effects and abort) A4 A1 A3 A4A2
  187. 187. 187 Execution platform prevents errorsExecution platform prevents errors Input: – Set of analyses annotated with contracts – The target analysis Algorithm: 1. Construct an I/O dependency graph Check assumptions (if failed, abort) Perform the analysis Check guarantees (if failed, reverse the effects and abort) A1 A2 A3 A4 A1 A3 A4A2 A4
  188. 188. 188 Execution platform prevents errorsExecution platform prevents errors Input: – Set of analyses annotated with contracts – The target analysis Algorithm: 1. Construct an I/O dependency graph 2. Determine an ordering that respects the dependencies Check assumptions (if failed, abort) Perform the analysis Check guarantees (if failed, reverse the effects and abort) A1 A2 A3 A4 A1 A3 A4 A1 A3 A4A2 A4
  189. 189. 189 Execution platform prevents errorsExecution platform prevents errors Input: – Set of analyses annotated with contracts – The target analysis Algorithm: 1. Construct an I/O dependency graph 2. Determine an ordering that respects the dependencies 3. Execute every analysis in that order ─ Check assumptions (if failed, abort) ─ Perform the analysis ─ Check guarantees (if failed, reverse the effects and abort) A1 A2 A3 A4 A1 A3 A4 A1 A3 A4A2 A4
  190. 190. 190 Execution platform prevents errorsExecution platform prevents errors Input: – Set of analyses annotated with contracts – The target analysis Algorithm: 1. Construct an I/O dependency graph 2. Determine an ordering that respects the dependencies 3. Execute every analysis in that order ─ Check assumptions (if failed, abort) ─ Perform the analysis ─ Check guarantees Prevention of out-of-order execution A1 A2 A3 A4 A1 A3 A4 A1 A3 A4A2 A4
  191. 191. 191 Execution platform prevents errorsExecution platform prevents errors Input: – Set of analyses annotated with contracts – The target analysis Algorithm: 1. Construct an I/O dependency graph 2. Determine an ordering that respects the dependencies 3. Execute every analysis in that order ─ Check assumptions (if failed, abort) ─ Perform the analysis ─ Check guarantees A1 A2 A3 A4 A1 A3 A4 A1 A3 A4A2 Prevention of out-of-context execution Prevention of out-of-order execution A4
  192. 192. 192 AgendaAgenda Problem Thesis overview In-depth approach Validation
  193. 193. 193 AgendaAgenda Problem Thesis overview In-depth approach Validation
  194. 194. 194 AgendaAgenda Problem Thesis overview In-depth approach Validation
  195. 195. 195 Validation assesses four qualitiesValidation assesses four qualities
  196. 196. 196 Validation assesses four qualitiesValidation assesses four qualities Claims: expressiveness, soundness, applicability, customizability of the approach Theoretical validation: soundness proof for IPL verification Empirical validation: Method: historical reviews & experiments Four case studies Sys 1: Energy-aware adaptation in a mobile robot Sys 2: Collision avoidance for a mobile robot Sys 3: Thread/battery scheduling in a quadrotor Sys 4: Reliable/secure sensing for an autonomous car
  197. 197. 197 Validation assesses four qualitiesValidation assesses four qualities Claims: expressiveness, soundness, applicability, customizability of the approach Theoretical validation: – Soundness/termination proof for IPL verification Empirical validation: Method: historical reviews & experiments Four case studies Sys 1: Energy-aware adaptation in a mobile robot Sys 2: Collision avoidance for a mobile robot Sys 3: Thread/battery scheduling in a quadrotor Sys 4: Reliable/secure sensing for an autonomous car
  198. 198. 198 Validation assesses four qualitiesValidation assesses four qualities Claims: expressiveness, soundness, applicability, customizability of the approach Theoretical validation: – Soundness/termination proof for IPL verification Empirical validation: – Method: historical reviews & experiments – Four case studies Sys 1: Energy-aware adaptation in a mobile robot Sys 2: Collision avoidance for a mobile robot Sys 3: Thread/battery scheduling in a quadrotor Sys 4: Reliable/secure sensing for an autonomous car
  199. 199. 199 Validation assesses four qualitiesValidation assesses four qualities Claims: expressiveness, soundness, applicability, customizability of the approach Theoretical validation: – Soundness/termination proof for IPL verification Empirical validation: – Method: historical reviews & experiments – Four case studies • Sys 1: Energy-aware adaptation in a mobile robot [1] • Sys 2: Collision avoidance for a mobile robot [2] • Sys 3: Thread/battery scheduling in a quadrotor [3] • Sys 4: Reliable/secure sensing for an autonomous car [4] [1] FM18 [2] CBSE15 [3] EMSOFT14 [4] CPS-SPC15
  200. 200. 200 Empirical validation of claimsEmpirical validation of claims Thesis part Claim Sys 1 Sys 2 Sys 3 Sys 4
  201. 201. 201 Empirical validation of claimsEmpirical validation of claims Thesis part Claim Sys 1 Sys 2 Sys 3 Sys 4 Integration abstractions Expressiveness ✓ ✓ ✓ ✓ Soundness ✓ ✓ ✓ Applicability ✓ ✓ ✓ ✓ Customizability ✓ ✓ ✓ ✓
  202. 202. 202 Empirical validation of claimsEmpirical validation of claims Thesis part Claim Sys 1 Sys 2 Sys 3 Sys 4 Integration abstractions Expressiveness ✓ ✓ ✓ ✓ Soundness ✓ ✓ ✓ Applicability ✓ ✓ ✓ ✓ Customizability ✓ ✓ ✓ ✓ Integration property language Expressiveness ✓ ✓ Soundness ✓ ✓ Applicability ✓ ✓ Customizability ✓ ✓ Analysis execution platform Soundness ✓ ✓ Applicability ✓ ✓
  203. 203. 203 Empirical validation of claimsEmpirical validation of claims Thesis part Claim Sys 1 Sys 2 Sys 3 Sys 4 Integration abstractions Expressiveness ✓ ✓ ✓ ✓ Soundness ✓ ✓ ✓ Applicability ✓ ✓ ✓ ✓ Customizability ✓ ✓ ✓ ✓ Integration property language Expressiveness ✓ ✓ Soundness ✓ ✓ Applicability ✓ ✓ Customizability ✓ ✓ Analysis execution platform Soundness ✓ ✓ Applicability ✓ ✓
  204. 204. 204 Empirical validation of claimsEmpirical validation of claims Thesis part Claim Sys 1 Sys 2 Sys 3 Sys 4 Integration abstractions Expressiveness ✓ ✓ ✓ ✓ Soundness ✓ ✓ ✓ Applicability ✓ ✓ ✓ ✓ Customizability ✓ ✓ ✓ ✓ Integration property language Expressiveness ✓ ✓ Soundness ✓ ✓ Applicability ✓ ✓ Customizability ✓ ✓ Analysis execution platform Soundness ✓ ✓ Applicability ✓ ✓
  205. 205. 205 Integration error discoveredIntegration error discovered Integration property: “the difference in energy estimates should not be greater than a predefined constant” Power model Planning model
  206. 206. 206 Integration error discoveredIntegration error discovered Integration property: “the difference in energy estimates should not be greater than a predefined constant” Power model Planning model Discovered error: battery := max(battery – req_energy, 0) (the last task does not require sufficient battery)
  207. 207. 207 Integration error discoveredIntegration error discovered Integration property: “the difference in energy estimates should not be greater than a predefined constant” Power model Planning model Discovered error: battery := max(battery – req_energy, 0) (the last task does not require sufficient battery) Impact of error: Some plans may lead to running out of power
  208. 208. 208 Integration error discoveredIntegration error discovered Integration property: “the difference in energy estimates should not be greater than a predefined constant” Power model Planning model Discovered error: battery := max(battery – req_energy, 0) (the last task does not require sufficient battery) Impact of error: Some plans may lead to running out of power Fix: Add check: battery > req_energy
  209. 209. 209 Evidence of integration qualitiesEvidence of integration qualities ... Power model Planning model
  210. 210. 210 Evidence of integration qualitiesEvidence of integration qualities Robot task view: represented robot tasks customizability→ sound & complete soundness→ ... Power model Planning model
  211. 211. 211 Evidence of integration qualitiesEvidence of integration qualities Power model Planning model Robot task view: represented robot tasks customizability→ sound & complete soundness→ ... IPL: real error found, verified within reasonable time → applicability
  212. 212. 212 Evidence of integration qualitiesEvidence of integration qualities Power model Planning model Robot task view: represented robot tasks customizability→ sound & complete soundness→ ... PCTL property: specified fixed missions → expressiveness IPL: real error found, verified within reasonable time → applicability
  213. 213. 213 Limitations of the approachLimitations of the approach
  214. 214. 214 Limitations of the approachLimitations of the approach Necessity of models – No model-free reasoning Expressiveness Integration abstractions/properties Analysis cycles Termination and scalability SMT solving, behavioral queries Practical viability Complexity Return on investment
  215. 215. 215 Limitations of the approachLimitations of the approach Necessity of models – No model-free reasoning Expressiveness – Integration abstractions/properties – Dependency cycles of analyses Termination and scalability SMT solving, behavioral queries Practical viability Complexity Return on investment
  216. 216. 216 Limitations of the approachLimitations of the approach Necessity of models – No model-free reasoning Expressiveness – Integration abstractions/properties – Dependency cycles of analyses Termination and scalability – SMT solving, behavioral queries Practical viability Complexity Return on investment
  217. 217. 217 Limitations of the approachLimitations of the approach Necessity of models – No model-free reasoning Expressiveness – Integration abstractions/properties – Dependency cycles of analyses Termination and scalability – SMT solving, behavioral queries Practical viability – Complexity – Return on investment
  218. 218. 218 ContributionsContributions
  219. 219. 219 ContributionsContributions Part 1: integration abstractions – A design of views and behavioral properties as integration abstractions [1] – A design of view abstractions for hybrid programs [2] – An implementation of SMT specs from AADL views [1, 3] – A generator of hybrid programs from hybrid program views [2] – Guidelines for practical application of integration abstractions [thesis] Part 2: integration property language A formalization of the syntax and semantics [1] A verification algorithm, the proof of soundness/termination [1] An implementation of an IPL modeling environment [1] Part 3: analysis contracts and execution A formalization of analysis contracts specifications [3] An algorithm to execute analyses correctly [3] An implementation of the analysis execution platform [3, 4] [1] FM18 [2] CBSE15 [3] EMSOFT14 [4] AVICPS14
  220. 220. 220 ContributionsContributions Part 1: integration abstractions – A design of views and behavioral properties as integration abstractions [1] – A design of view abstractions for hybrid programs [2] – An implementation of SMT specs from AADL views [1, 3] – A generator of hybrid programs from hybrid program views [2] – Guidelines for practical application of integration abstractions [thesis] Part 2: integration property language – A formalization of the syntax and semantics [1] – A verification algorithm, the proof of soundness/termination [1] – An implementation of an IPL modeling environment [1] Part 3: analysis contracts and execution A formalization of analysis contracts specifications [3] An algorithm to execute analyses correctly [3] An implementation of the analysis execution platform [3, 4] [1] FM18 [2] CBSE15 [3] EMSOFT14 [4] AVICPS14
  221. 221. 221 ContributionsContributions Part 1: integration abstractions – A design of views and behavioral properties as integration abstractions [1] – A design of view abstractions for hybrid programs [2] – An implementation of SMT specs from AADL views [1, 3] – A generator of hybrid programs from hybrid program views [2] – Guidelines for practical application of integration abstractions [thesis] Part 2: integration property language – A formalization of the syntax and semantics [1] – A verification algorithm, the proof of soundness/termination [1] – An implementation of an IPL modeling environment [1] Part 3: analysis contracts and execution – A formalization of analysis contracts specifications [3] – An algorithm to execute analyses correctly [3] – An implementation of the analysis execution platform [3, 4] [1] FM18 [2] CBSE15 [3] EMSOFT14 [4] AVICPS14
  222. 222. 222 SummarySummary Problem Thesis overview In-depth approach Validation

×