SlideShare a Scribd company logo

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

Ivan Ruchkin, profile picture
Ivan Ruchkin

The thesis defense presents an integration approach for modeling methods in cyber-physical systems (CPS) to address failures stemming from inconsistencies between models and incorrect interactions during analyses. It proposes that four qualities of effective integration—expressiveness, soundness, applicability, and customizability—are fulfilled through specific integration abstractions and verification processes. The findings highlight the importance of structured and formal combinations of modeling methods to enhance reliability in CPS design.

Software
Related topics:
Cyber-Physical Systems • Formal Methods in Computing
1 of 222
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
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 Cyber-physical systems (CPS)Cyber-physical systems (CPS)
3 CPS continue to failCPS continue to fail
4 CPS continue to failCPS continue to fail
5 CPS design relies on multiple modelsCPS design relies on multiple models
6 CPS design relies on multiple modelsCPS design relies on multiple models Model A
7 CPS design relies on multiple modelsCPS design relies on multiple models Model A Artifact
8 CPS design relies on multiple modelsCPS design relies on multiple models Model A Model B Artifact
9 CPS design relies on multiple modelsCPS design relies on multiple models Model A Model B Artifact Certificate
10 Two issues lead to CPS failuresTwo issues lead to CPS failures
11 Two issues lead to CPS failuresTwo issues lead to CPS failures 1. Inconsistencies between models
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 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 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model B Artifact Certificate
15 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model B Artifact Certificate
16 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate
17 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate
18 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate Inconsistent
19 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate Inconsistent
20 Example: inconsistency between modelsExample: inconsistency between models
21 Example: inconsistency between modelsExample: inconsistency between models Mobile robot
22 Example: inconsistency between modelsExample: inconsistency between models Power model Mobile robot
23 Example: inconsistency between modelsExample: inconsistency between models Power model Planning model Mobile robot
24 Example: inconsistency between modelsExample: inconsistency between models Potential inconsistency: different estimated energy costs Power model Planning model Mobile robot
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 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 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 CPS design relies on multiple modelsCPS design relies on multiple models Model A Model relation Model B Artifact Certificate
29 CPS design relies on multiple analysesCPS design relies on multiple analyses Analysis A Analysis B
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 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A Analysis B
32 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A Analysis B
33 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis B
34 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B
35 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B A nalysis dependency
36 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B #3 #2 #1
37 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B #3 #2 #1
38 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B #3 #2 #1
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 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B
41 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2
42 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’
43 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’ Context of analysis
44 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’ Context of analysis
45 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’ Context of analysis
46 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’ Context of analysis
47 Issues reframed with modeling methodsIssues reframed with modeling methods
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 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 SummarySummary Problem Thesis overview In-depth approach Validation
51 AgendaAgenda Problem Thesis overview In-depth approach Validation
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 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 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 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 Qualities of integrationQualities of integration
57 Qualities of integrationQualities of integration Expressiveness – Handles complex relations of structures & behaviors
58 Qualities of integrationQualities of integration Expressiveness – Handles complex relations of structures & behaviors Soundness – Delivers trustworthy results
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 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 Existing approaches fall shortExisting approaches fall short
62 Existing approaches fall shortExisting approaches fall short Approach Expressive? Sound? Applicable? Customizable? Ad hoc, system-specific ✓ ✓ Single model ✓ ✓ Frameworks ✓ ✓ ✓ My approach ✓ ✓ ✓ ✓
63 Existing approaches fall shortExisting approaches fall short Approach Expressive? Sound? Applicable? Customizable? Ad hoc, system-specific ✓ ✓ Single model ✓ ✓ Frameworks ✓ ✓ ✓ My approach ✓ ✓ ✓ ✓
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 Existing approaches fall shortExisting approaches fall short Approach Expressive? Sound? Applicable? Customizable? Ad hoc, system-specific ✓ ✓ Single model, single analysis ✓ ✓ Frameworks ✓ ✓ ✓ My approach ✓ ✓ ✓ ✓
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 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 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 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 Integration approachIntegration approach
71 Integration approachIntegration approach
72 Integration approachIntegration approach
73 Integration approachIntegration approach
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 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 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 Integration approachIntegration approach
78 Integration approachIntegration approach
79 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related
80 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related Model relation
81 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related Model relation Specification
82 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related Model relation Specification
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 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 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 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 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 Example: detecting inconsistencyExample: detecting inconsistency Potential inconsistency: different estimated energy costs Power model Planning model
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 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 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 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 Integration approachIntegration approach
94 Analyses change models/abstractionsAnalyses change models/abstractions
95 Contracts capture analysis meta-infoContracts capture analysis meta-info
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 AgendaAgenda Problem Thesis overview In-depth approach Validation
98 AgendaAgenda Problem Thesis overview In-depth approach Validation
99 AgendaAgenda Problem Thesis overview In-depth approach Validation
100 Integration approachIntegration approach
101 Part 1: views & behavioral propertiesPart 1: views & behavioral properties
102 Two important aspects of modelsTwo important aspects of models
103 Two important aspects of modelsTwo important aspects of models Model A
104 Two important aspects of modelsTwo important aspects of models Model A Structures in model A
105 Two important aspects of modelsTwo important aspects of models Model BModel A Structures in model A
106 Two important aspects of modelsTwo important aspects of models Model B Behaviors in model B Model A Structures in model A
107 Two important aspects of modelsTwo important aspects of models Model B Behaviors in model B Model A Structures in model A
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 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 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 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 Example: view for power modelExample: view for power model Mobile robot Power model tim e speed energy
113 Example: view for power modelExample: view for power model Map model Mobile robot Power model tim e speed energy
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 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 Example: view with robot tasksExample: view with robot tasks
117 Example: view with robot tasksExample: view with robot tasks
118 Example: view with robot tasksExample: view with robot tasks
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 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 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 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 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 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 Two important aspects of modelsTwo important aspects of models Model B Behaviors in model B Model A Structures in model A
126 Behavioral properties query behaviorsBehavioral properties query behaviors
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 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 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 Example: behavioral property in PCTLExample: behavioral property in PCTL Using probabilistic computation tree logic (PCTL)
131 Example: behavioral property in PCTLExample: behavioral property in PCTL Mobile robot Planning model Using probabilistic computation tree logic (PCTL)
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 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 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 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 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 What is a correct behavioral query?What is a correct behavioral query?
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 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 Part 1: views & behavioral propertiesPart 1: views & behavioral properties
141 Part 2: Integration Property LanguagePart 2: Integration Property Language
142 Part 2: Integration Property LanguagePart 2: Integration Property Language
143 Integration Property Language (IPL)Integration Property Language (IPL) Idea: specify integration properties as mutual constraints on views and behaviors
144 Integration Property Language (IPL)Integration Property Language (IPL) Idea: specify integration properties as mutual constraints on views and behaviors Behavioral property View
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 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 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 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 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 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 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 Example: integration property in IPLExample: integration property in IPL
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 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 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 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 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 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
159 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
160 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
161 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
162 Verification algorithm checks formulasVerification algorithm checks formulas
163 Verification algorithm checks formulasVerification algorithm checks formulas IPL verification: views, models ⊨ formula Quant·rigid&flexible
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 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 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 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 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 Part 2: Integration Property LanguagePart 2: Integration Property Language
170 Part 3: analysis contracts & executionPart 3: analysis contracts & execution
171 Part 3: analysis contracts & executionPart 3: analysis contracts & execution
172 Contracts capture meta-info about analysesContracts capture meta-info about analyses Assumptions = {…}, Guarantees = {…} Assumptions = {…}, Guarantees = {…}
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 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 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 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 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 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 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 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 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 Execution platform prevents errorsExecution platform prevents errors Goal: execute the target analysis without incorrect interactions
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 Execution platform prevents errorsExecution platform prevents errors Input: – Set of analyses annotated with contracts – The target analysis
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 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 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 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 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 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 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 AgendaAgenda Problem Thesis overview In-depth approach Validation
193 AgendaAgenda Problem Thesis overview In-depth approach Validation
194 AgendaAgenda Problem Thesis overview In-depth approach Validation
195 Validation assesses four qualitiesValidation assesses four qualities
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 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 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 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 Empirical validation of claimsEmpirical validation of claims Thesis part Claim Sys 1 Sys 2 Sys 3 Sys 4
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 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 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 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 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 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 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 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 Evidence of integration qualitiesEvidence of integration qualities ... Power model Planning model
210 Evidence of integration qualitiesEvidence of integration qualities Robot task view: represented robot tasks customizability→ sound & complete soundness→ ... Power model Planning model
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 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 Limitations of the approachLimitations of the approach
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 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 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 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 ContributionsContributions
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 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 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 SummarySummary Problem Thesis overview In-depth approach Validation

More Related Content

PDF
Leveraging HPC Resources to Improve the Experimental Design of Software Analy...
Chakkrit (Kla) Tantithamthavorn
 
PDF
Early Detection of Collaboration Conflicts & Risks in Software Development
Roopesh Jhurani
 
PDF
A Survey of functional verification techniques
IJSRD
 
PDF
The Impact of Mislabelling on the Performance and Interpretation of Defect Pr...
Chakkrit (Kla) Tantithamthavorn
 
PDF
Cross-project defect prediction
Thomas Zimmermann
 
PDF
ICSME 2016: Search-Based Peer Reviewers Recommendation in Modern Code Review
Ali Ouni
 
PDF
Mining Software Defects: Should We Consider Affected Releases?
Chakkrit (Kla) Tantithamthavorn
 
PDF
On The Relation of Test Smells to Software Code Quality
Delft University of Technology
 
Leveraging HPC Resources to Improve the Experimental Design of Software Analy...
Chakkrit (Kla) Tantithamthavorn
 
Early Detection of Collaboration Conflicts & Risks in Software Development
Roopesh Jhurani
 
A Survey of functional verification techniques
IJSRD
 
The Impact of Mislabelling on the Performance and Interpretation of Defect Pr...
Chakkrit (Kla) Tantithamthavorn
 
Cross-project defect prediction
Thomas Zimmermann
 
ICSME 2016: Search-Based Peer Reviewers Recommendation in Modern Code Review
Ali Ouni
 
Mining Software Defects: Should We Consider Affected Releases?
Chakkrit (Kla) Tantithamthavorn
 
On The Relation of Test Smells to Software Code Quality
Delft University of Technology
 

What's hot (20)

PDF
Software Analytics In Action: A Hands-on Tutorial on Mining, Analyzing, Model...
Chakkrit (Kla) Tantithamthavorn
 
PDF
Software Quality Analysis Using Mutation Testing Scheme
Editor IJMTER
 
PDF
Cross-project Defect Prediction Using A Connectivity-based Unsupervised Class...
Feng Zhang
 
PDF
Towards a Better Understanding of the Impact of Experimental Components on De...
Chakkrit (Kla) Tantithamthavorn
 
PDF
Defect effort prediction models in software
IAEME Publication
 
PDF
QUALITY METRICS OF TEST SUITES IN TESTDRIVEN DESIGNED APPLICATIONS
ijseajournal
 
PPT
Using Developer Information as a Prediction Factor
Tim Menzies
 
PPT
Experiments on Design Pattern Discovery
Tim Menzies
 
PDF
Csqe sample exam 1 solutions 05.00.04
binodrit98
 
PDF
Can we induce change with what we measure?
Michaela Greiler
 
PPTX
Impact of Coding Style Checker on Code Review -A case study on the OpenStack ...
Yuki Ueda
 
PDF
ICGSE2020: On the Detection of Community Smells Using Genetic Programming-bas...
Ali Ouni
 
PPTX
Automatically Customizing Static Analysis Tools to Coding Rules Really Follow...
Yuki Ueda
 
PPTX
Icsm2010 kamei
SAIL_QU
 
PDF
An empirical evaluation of
Aadhityaa Infomedia
 
PDF
Www.istqb.guru istqb question-paper5
Tomas Vileikis
 
PDF
Practices and Tools for Better Software Testing
Delft University of Technology
 
PDF
Strategies to Avoid Test Fixture Smells durin Software Evolution
Michaela Greiler
 
PDF
AI-Driven Software Quality Assurance in the Age of DevOps
Chakkrit (Kla) Tantithamthavorn
 
PDF
6 article azojete vol 9 51 67
Oyeniyi Samuel
 
Software Analytics In Action: A Hands-on Tutorial on Mining, Analyzing, Model...
Chakkrit (Kla) Tantithamthavorn
 
Software Quality Analysis Using Mutation Testing Scheme
Editor IJMTER
 
Cross-project Defect Prediction Using A Connectivity-based Unsupervised Class...
Feng Zhang
 
Towards a Better Understanding of the Impact of Experimental Components on De...
Chakkrit (Kla) Tantithamthavorn
 
Defect effort prediction models in software
IAEME Publication
 
QUALITY METRICS OF TEST SUITES IN TESTDRIVEN DESIGNED APPLICATIONS
ijseajournal
 
Using Developer Information as a Prediction Factor
Tim Menzies
 
Experiments on Design Pattern Discovery
Tim Menzies
 
Csqe sample exam 1 solutions 05.00.04
binodrit98
 
Can we induce change with what we measure?
Michaela Greiler
 
Impact of Coding Style Checker on Code Review -A case study on the OpenStack ...
Yuki Ueda
 
ICGSE2020: On the Detection of Community Smells Using Genetic Programming-bas...
Ali Ouni
 
Automatically Customizing Static Analysis Tools to Coding Rules Really Follow...
Yuki Ueda
 
Icsm2010 kamei
SAIL_QU
 
An empirical evaluation of
Aadhityaa Infomedia
 
Www.istqb.guru istqb question-paper5
Tomas Vileikis
 
Practices and Tools for Better Software Testing
Delft University of Technology
 
Strategies to Avoid Test Fixture Smells durin Software Evolution
Michaela Greiler
 
AI-Driven Software Quality Assurance in the Age of DevOps
Chakkrit (Kla) Tantithamthavorn
 
6 article azojete vol 9 51 67
Oyeniyi Samuel
 
Ad

Similar to Thesis Defense: Integration of Modeling Methods for Cyber-Physical Systems (20)

PDF
SSBSE 2020 keynote
Shiva Nejati
 
PDF
Modelling and analysing contextual failures for dependability requirements
Engineering and Social Informatics (ESOTICS)
 
PDF
Cross-Project Build Co-change Prediction
Shane McIntosh
 
PDF
Inconsistencies in Models of Adaptive Service Robots
Ivan Ruchkin
 
PDF
Verifications and Validations in Finite Element Analysis (FEA)
Kartik Srinivas
 
PDF
Analytic Dependency Loops in Architectural Models of Cyber-Physical Systems
Ivan Ruchkin
 
PDF
A defect prediction model based on the relationships between developers and c...
Vrije Universiteit Brussel
 
DOC
ISTQB Advanced Study Guide - 7
Yogindernath Gupta
 
PDF
Final Exam Solutions Fall02
Radu_Negulescu
 
PPTX
First Year Report, PhD presentation
Bang Xiang Yong
 
PPTX
MLOps and Data Quality: Deploying Reliable ML Models in Production
Provectus
 
PPT
2cee Master Cocomo20071
CS, NcState
 
PPTX
Medical device manufacturer improves quality, cuts risk with historian
IntelligentManufacturingInstitute
 
PDF
Making Model-Driven Verification Practical and Scalable: Experiences and Less...
Lionel Briand
 
DOCX
PM3 ARTICALS
ra na
 
PDF
Requirements in Engineering AI- Enabled Systems: Open Problems and Safe AI Sy...
Lionel Briand
 
PDF
Adobe Audition Crack FRESH Version 2025 FREE
zafranwaqar90
 
PDF
Identifying and Resolving Consistency Issues between Model Representations
Ivan Ruchkin
 
PPT
Promise 2011: "Local Bias and its Impacts on the Performance of Parametric Es...
CS, NcState
 
PDF
Zue2015Uncertainties
William Chipman
 
SSBSE 2020 keynote
Shiva Nejati
 
Modelling and analysing contextual failures for dependability requirements
Engineering and Social Informatics (ESOTICS)
 
Cross-Project Build Co-change Prediction
Shane McIntosh
 
Inconsistencies in Models of Adaptive Service Robots
Ivan Ruchkin
 
Verifications and Validations in Finite Element Analysis (FEA)
Kartik Srinivas
 
Analytic Dependency Loops in Architectural Models of Cyber-Physical Systems
Ivan Ruchkin
 
A defect prediction model based on the relationships between developers and c...
Vrije Universiteit Brussel
 
ISTQB Advanced Study Guide - 7
Yogindernath Gupta
 
Final Exam Solutions Fall02
Radu_Negulescu
 
First Year Report, PhD presentation
Bang Xiang Yong
 
MLOps and Data Quality: Deploying Reliable ML Models in Production
Provectus
 
2cee Master Cocomo20071
CS, NcState
 
Medical device manufacturer improves quality, cuts risk with historian
IntelligentManufacturingInstitute
 
Making Model-Driven Verification Practical and Scalable: Experiences and Less...
Lionel Briand
 
PM3 ARTICALS
ra na
 
Requirements in Engineering AI- Enabled Systems: Open Problems and Safe AI Sy...
Lionel Briand
 
Adobe Audition Crack FRESH Version 2025 FREE
zafranwaqar90
 
Identifying and Resolving Consistency Issues between Model Representations
Ivan Ruchkin
 
Promise 2011: "Local Bias and its Impacts on the Performance of Parametric Es...
CS, NcState
 
Zue2015Uncertainties
William Chipman
 
Ad

More from Ivan Ruchkin (20)

PDF
Neural Approximation of Vision-Controlled Systems for Reachability Analysis
Ivan Ruchkin
 
PDF
State-Dependent Conformal Perception Bounds for Neuro-Symbolic Verification
Ivan Ruchkin
 
PPTX
NeuroStrata: Harnessing Neuro-Symbolic Paradigms for Improved Testability and...
Ivan Ruchkin
 
PDF
State-Dependent Conformal Perception Bounds for Neuro-Symbolic Verification o...
Ivan Ruchkin
 
PDF
Four Principles for Physically Interpretable World Models
Ivan Ruchkin
 
PDF
State-Dependent Conformal Perception Bounds for Neuro-Symbolic Verification o...
Ivan Ruchkin
 
PDF
Four Principles for Physically Interpretable World Models (poster)
Ivan Ruchkin
 
PDF
Accelerating Neural Policy Repair with Preservation via Stability-Plasticity ...
Ivan Ruchkin
 
PDF
Distributionally Robust Statistical Verification with Imprecise Neural Networks
Ivan Ruchkin
 
PDF
Autonomous Drift Detection and Online Road Friction Estimation
Ivan Ruchkin
 
PDF
Neuro-Symbolic Bridge: From Perception to Estimation & Control
Ivan Ruchkin
 
PDF
Towards Physically Interpretable World Models: Meaningful Weakly Supervised R...
Ivan Ruchkin
 
PDF
How Safe Will I Be Given What I See? Calibrated Visual Safety Chance Predict...
Ivan Ruchkin
 
PDF
Bridging Dimensions: Confident Reachability for High-Dimensional Controllers...
Ivan Ruchkin
 
PDF
Poster: Bridging Dimensions: Confident Reachability for High-Dimensional Cont...
Ivan Ruchkin
 
PDF
Bridging Dimensions: Confident Reachability for High-Dimensional Controllers
Ivan Ruchkin
 
PDF
Poster: How Safe Am I Given What I See? Calibrated Prediction of Safety Chanc...
Ivan Ruchkin
 
PDF
Language-Enhanced Latent Representations for Out-of-Distribution Detection in...
Ivan Ruchkin
 
PDF
​Poster: Zero-shot Safety Prediction for Autonomous Robots with Foundation Wo...
Ivan Ruchkin
 
PDF
Curating Naturally Adversarial Datasets for Learning-Enabled Medical Cyber-Ph...
Ivan Ruchkin
 
Neural Approximation of Vision-Controlled Systems for Reachability Analysis
Ivan Ruchkin
 
State-Dependent Conformal Perception Bounds for Neuro-Symbolic Verification
Ivan Ruchkin
 
NeuroStrata: Harnessing Neuro-Symbolic Paradigms for Improved Testability and...
Ivan Ruchkin
 
State-Dependent Conformal Perception Bounds for Neuro-Symbolic Verification o...
Ivan Ruchkin
 
Four Principles for Physically Interpretable World Models
Ivan Ruchkin
 
State-Dependent Conformal Perception Bounds for Neuro-Symbolic Verification o...
Ivan Ruchkin
 
Four Principles for Physically Interpretable World Models (poster)
Ivan Ruchkin
 
Accelerating Neural Policy Repair with Preservation via Stability-Plasticity ...
Ivan Ruchkin
 
Distributionally Robust Statistical Verification with Imprecise Neural Networks
Ivan Ruchkin
 
Autonomous Drift Detection and Online Road Friction Estimation
Ivan Ruchkin
 
Neuro-Symbolic Bridge: From Perception to Estimation & Control
Ivan Ruchkin
 
Towards Physically Interpretable World Models: Meaningful Weakly Supervised R...
Ivan Ruchkin
 
How Safe Will I Be Given What I See? Calibrated Visual Safety Chance Predict...
Ivan Ruchkin
 
Bridging Dimensions: Confident Reachability for High-Dimensional Controllers...
Ivan Ruchkin
 
Poster: Bridging Dimensions: Confident Reachability for High-Dimensional Cont...
Ivan Ruchkin
 
Bridging Dimensions: Confident Reachability for High-Dimensional Controllers
Ivan Ruchkin
 
Poster: How Safe Am I Given What I See? Calibrated Prediction of Safety Chanc...
Ivan Ruchkin
 
Language-Enhanced Latent Representations for Out-of-Distribution Detection in...
Ivan Ruchkin
 
​Poster: Zero-shot Safety Prediction for Autonomous Robots with Foundation Wo...
Ivan Ruchkin
 
Curating Naturally Adversarial Datasets for Learning-Enabled Medical Cyber-Ph...
Ivan Ruchkin
 

Recently uploaded (20)

PDF
Nekopoi APK 2025 free lastest update
umarali35kp
 
PDF
System and Network Administration Chapter 2
jaramharo
 
PDF
Understanding Forklifts - TECH EHS Solution
TECH EHS Solution
 
PDF
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
lawrenceomai2
 
PDF
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
William Chong
 
PPTX
VVF-Customer-Presentation2025-Ver1.9.pptx
blackmambaettijean
 
PDF
Adobe Premiere Pro 2025 (v24.5.0.057) Crack free
ghrom2211g
 
PDF
Odoo Companies in India – Driving Business Transformation.pdf
azhuhardeen1968
 
PDF
EN-Survey-Report-SAP-LeanIX-EA-Insights-2025.pdf
deepakkhaitan3
 
PPTX
Odoo POS Development Services by CandidRoot Solutions
CandidRoot Solutions Private Limited
 
PDF
AI in Product Development-omnex systems
omnex systems
 
PDF
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
OnePlan Solutions
 
PDF
Which alternative to Crystal Reports is best for small or large businesses.pdf
Varsha Nayak
 
PDF
medical staffing services at VALiNTRY
Tiyan Grayson
 
PPTX
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
mhxyzzp
 
PDF
System and Network Administraation Chapter 3
jaramharo
 
PPTX
Transform Your Business with a Software ERP System
Canada Software Company
 
PDF
PTS Company Brochure 2025 (1).pdf.......
pts464036
 
PDF
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
TechBuilder
 
PPTX
ai tools demonstartion for schools and inter college
harshavardhanreddyka11
 
Nekopoi APK 2025 free lastest update
umarali35kp
 
System and Network Administration Chapter 2
jaramharo
 
Understanding Forklifts - TECH EHS Solution
TECH EHS Solution
 
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
lawrenceomai2
 
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
William Chong
 
VVF-Customer-Presentation2025-Ver1.9.pptx
blackmambaettijean
 
Adobe Premiere Pro 2025 (v24.5.0.057) Crack free
ghrom2211g
 
Odoo Companies in India – Driving Business Transformation.pdf
azhuhardeen1968
 
EN-Survey-Report-SAP-LeanIX-EA-Insights-2025.pdf
deepakkhaitan3
 
Odoo POS Development Services by CandidRoot Solutions
CandidRoot Solutions Private Limited
 
AI in Product Development-omnex systems
omnex systems
 
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
OnePlan Solutions
 
Which alternative to Crystal Reports is best for small or large businesses.pdf
Varsha Nayak
 
medical staffing services at VALiNTRY
Tiyan Grayson
 
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
mhxyzzp
 
System and Network Administraation Chapter 3
jaramharo
 
Transform Your Business with a Software ERP System
Canada Software Company
 
PTS Company Brochure 2025 (1).pdf.......
pts464036
 
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
TechBuilder
 
ai tools demonstartion for schools and inter college
harshavardhanreddyka11
 

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

  • 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
  • 3. 3 CPS continue to failCPS continue to fail
  • 4. 4 CPS continue to failCPS continue to fail
  • 5. 5 CPS design relies on multiple modelsCPS design relies on multiple models
  • 6. 6 CPS design relies on multiple modelsCPS design relies on multiple models Model A
  • 7. 7 CPS design relies on multiple modelsCPS design relies on multiple models Model A Artifact
  • 8. 8 CPS design relies on multiple modelsCPS design relies on multiple models Model A Model B Artifact
  • 9. 9 CPS design relies on multiple modelsCPS design relies on multiple models Model A Model B Artifact Certificate
  • 10. 10 Two issues lead to CPS failuresTwo issues lead to CPS failures
  • 11. 11 Two issues lead to CPS failuresTwo issues lead to CPS failures 1. Inconsistencies between models
  • 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 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 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model B Artifact Certificate
  • 15. 15 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model B Artifact Certificate
  • 16. 16 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate
  • 17. 17 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate
  • 18. 18 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate Inconsistent
  • 19. 19 Inconsistencies can lead to failuresInconsistencies can lead to failures Model A Model relation Model B Artifact Certificate Inconsistent
  • 20. 20 Example: inconsistency between modelsExample: inconsistency between models
  • 21. 21 Example: inconsistency between modelsExample: inconsistency between models Mobile robot
  • 22. 22 Example: inconsistency between modelsExample: inconsistency between models Power model Mobile robot
  • 23. 23 Example: inconsistency between modelsExample: inconsistency between models Power model Planning model Mobile robot
  • 24. 24 Example: inconsistency between modelsExample: inconsistency between models Potential inconsistency: different estimated energy costs Power model Planning model Mobile robot
  • 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 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 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 CPS design relies on multiple modelsCPS design relies on multiple models Model A Model relation Model B Artifact Certificate
  • 29. 29 CPS design relies on multiple analysesCPS design relies on multiple analyses Analysis A Analysis B
  • 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 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A Analysis B
  • 32. 32 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A Analysis B
  • 33. 33 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis B
  • 34. 34 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B
  • 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 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B #3 #2 #1
  • 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 Out-of-order analysis leads to errorsOut-of-order analysis leads to errors Analysis A1 Analysis A2 Analysis B #3 #2 #1
  • 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 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B
  • 41. 41 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2
  • 42. 42 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’
  • 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 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’ Context of analysis
  • 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 Out-of-context analysis leads to errorsOut-of-context analysis leads to errors Analysis A1 Analysis A2 Analysis B’ Context of analysis
  • 47. 47 Issues reframed with modeling methodsIssues reframed with modeling methods
  • 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 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 SummarySummary Problem Thesis overview In-depth approach Validation
  • 51. 51 AgendaAgenda Problem Thesis overview In-depth approach Validation
  • 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 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 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 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.”
  • 57. 57 Qualities of integrationQualities of integration Expressiveness – Handles complex relations of structures & behaviors
  • 58. 58 Qualities of integrationQualities of integration Expressiveness – Handles complex relations of structures & behaviors Soundness – Delivers trustworthy results
  • 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 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 Existing approaches fall shortExisting approaches fall short
  • 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 Existing approaches fall shortExisting approaches fall short Approach Expressive? Sound? Applicable? Customizable? Ad hoc, system-specific ✓ ✓ Single model ✓ ✓ Frameworks ✓ ✓ ✓ My approach ✓ ✓ ✓ ✓
  • 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 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 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 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 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 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.”
  • 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 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 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.”
  • 79. 79 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related
  • 80. 80 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related Model relation
  • 81. 81 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related Model relation Specification
  • 82. 82 Role of integration propertiesRole of integration properties Idea: letting engineers specify how models should be related Model relation Specification
  • 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 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 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 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 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 Example: detecting inconsistencyExample: detecting inconsistency Potential inconsistency: different estimated energy costs Power model Planning model
  • 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 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 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 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.”
  • 95. 95 Contracts capture analysis meta-infoContracts capture analysis meta-info
  • 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 AgendaAgenda Problem Thesis overview In-depth approach Validation
  • 98. 98 AgendaAgenda Problem Thesis overview In-depth approach Validation
  • 99. 99 AgendaAgenda Problem Thesis overview In-depth approach Validation
  • 101. 101 Part 1: views & behavioral propertiesPart 1: views & behavioral properties
  • 102. 102 Two important aspects of modelsTwo important aspects of models
  • 103. 103 Two important aspects of modelsTwo important aspects of models Model A
  • 104. 104 Two important aspects of modelsTwo important aspects of models Model A Structures in model A
  • 105. 105 Two important aspects of modelsTwo important aspects of models Model BModel A Structures in model A
  • 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 Two important aspects of modelsTwo important aspects of models Model B Behaviors in model B Model A Structures in model A
  • 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 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 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 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 Example: view for power modelExample: view for power model Mobile robot Power model tim e speed energy
  • 113. 113 Example: view for power modelExample: view for power model Map model Mobile robot Power model tim e speed energy
  • 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 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 Example: view with robot tasksExample: view with robot tasks
  • 117. 117 Example: view with robot tasksExample: view with robot tasks
  • 118. 118 Example: view with robot tasksExample: view with robot tasks
  • 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 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 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 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 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 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 Two important aspects of modelsTwo important aspects of models Model B Behaviors in model B Model A Structures in model A
  • 126. 126 Behavioral properties query behaviorsBehavioral properties query behaviors
  • 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 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 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 Example: behavioral property in PCTLExample: behavioral property in PCTL Using probabilistic computation tree logic (PCTL)
  • 131. 131 Example: behavioral property in PCTLExample: behavioral property in PCTL Mobile robot Planning model Using probabilistic computation tree logic (PCTL)
  • 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 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 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 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 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 What is a correct behavioral query?What is a correct behavioral query?
  • 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 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 Part 1: views & behavioral propertiesPart 1: views & behavioral properties
  • 141. 141 Part 2: Integration Property LanguagePart 2: Integration Property Language
  • 142. 142 Part 2: Integration Property LanguagePart 2: Integration Property Language
  • 143. 143 Integration Property Language (IPL)Integration Property Language (IPL) Idea: specify integration properties as mutual constraints on views and behaviors
  • 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 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 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 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 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 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 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 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 Example: integration property in IPLExample: integration property in IPL
  • 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 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 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 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 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 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
  • 159. 159 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
  • 160. 160 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
  • 161. 161 IPL syntax combines rigid & flexible termsIPL syntax combines rigid & flexible terms
  • 162. 162 Verification algorithm checks formulasVerification algorithm checks formulas
  • 163. 163 Verification algorithm checks formulasVerification algorithm checks formulas IPL verification: views, models ⊨ formula Quant·rigid&flexible
  • 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 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 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 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 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 Part 2: Integration Property LanguagePart 2: Integration Property Language
  • 170. 170 Part 3: analysis contracts & executionPart 3: analysis contracts & execution
  • 171. 171 Part 3: analysis contracts & executionPart 3: analysis contracts & execution
  • 172. 172 Contracts capture meta-info about analysesContracts capture meta-info about analyses Assumptions = {…}, Guarantees = {…} Assumptions = {…}, Guarantees = {…}
  • 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 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 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 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 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 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 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 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 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 Execution platform prevents errorsExecution platform prevents errors Goal: execute the target analysis without incorrect interactions
  • 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 Execution platform prevents errorsExecution platform prevents errors Input: – Set of analyses annotated with contracts – The target analysis
  • 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 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 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 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 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 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 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 AgendaAgenda Problem Thesis overview In-depth approach Validation
  • 193. 193 AgendaAgenda Problem Thesis overview In-depth approach Validation
  • 194. 194 AgendaAgenda Problem Thesis overview In-depth approach Validation
  • 195. 195 Validation assesses four qualitiesValidation assesses four qualities
  • 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 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 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 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 Empirical validation of claimsEmpirical validation of claims Thesis part Claim Sys 1 Sys 2 Sys 3 Sys 4
  • 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 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 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 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 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 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 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 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 Evidence of integration qualitiesEvidence of integration qualities ... Power model Planning model
  • 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 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 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 Limitations of the approachLimitations of the approach
  • 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 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 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 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
  • 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 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 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 SummarySummary Problem Thesis overview In-depth approach Validation