A slide deck from my PhD thesis defense. The video of the defense talk can be seen here: https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=aebd3567-e42b-4281-94a7-a98f011d1268 Abstract: "Cyber-physical systems (CPS) incorporate digital (cyber) and mechanical (physical) elements that interact in complex ways. Many safety-critical CPS, such as autonomous vehicles and drones, are becoming increasingly widespread and hence demand rigorous quality assurance. To this end, CPS engineering relies on modeling methods, which use models to represent the system and design-time analyses to interpret/change the models. Coming from diverse scientific and engineering fields, these modeling methods are difficult to combine, or integrate, due to implicit relations and dependencies between them. CPS failures can lead to substantial damage or loss of life, and are often due to two key integration challenges: (i) inconsistencies between models — contradictions in models that do not add up to a cohesive design, and (ii) incorrect interactions of analyses — out-of-order executions in mismatched contexts, leading to erroneous analysis outputs. This thesis presents a novel approach to detect and prevent integration issues between CPS modeling methods during the design phase. To detect inconsistencies between models, the approach allows engineers to specify integration properties — quantified logical statements that relate various elements of multiple models — in the Integration Property Language (IPL). IPL statements describe verifiable conditions that are equivalent to an absence of inconsistencies. To interface with the models, IPL relies on integration abstractions — simplified representations of models for integration purposes. Two abstractions are proposed in this thesis: views (annotated component-and-connector models, inspired by software architecture) and behavioral properties (expressions in model-specific languages, such as the linear temporal logic). Combining these abstractions enables engineers to mix model structure and behavior in IPL statements. To ensure correct interactions of analyses, I introduce analysis contracts — a lightweight specification that captures inputs, outputs, assumptions, and guarantees for each analysis, in terms of the integration abstractions. Given these contracts, an analysis execution platform performs analyses in the order of their dependencies, and only in contexts that guarantee correct outputs. My approach to integration was validated on four case studies of CPS modeling methods in different systems: energy-aware planning in a mobile robot, collision avoidance in a mobile robot, thread/battery scheduling in a quadrotor, and reliable/secure sensing in an autonomous vehicle. The validation has shown that the approach supports expressive integration properties, which can be soundly checked within practical constraints, all while being customizable to diverse models, analyses, and domains."

1. Thesis Defense, PhD in Software EngineeringThesis Defense, PhD in Software Engineering
Institute for Software ResearchInstitute for Software Research
Carnegie Mellon UniversityCarnegie Mellon University
November 8, 2018November 8, 2018
Thesis committee:
David Garlan (chair)
André Platzer
Bruce Krogh
Dionisio de Niz
John Day
Integration of Modeling Methods forIntegration of Modeling Methods for
Cyber-Physical SystemsCyber-Physical Systems
Ivan RuchkinIvan Ruchkin

2. 2
Cyber-physical systems (CPS)Cyber-physical systems (CPS)

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

56. 56
Qualities of integrationQualities of integration

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

70. 70
Integration approachIntegration approach

71. 71
Integration approachIntegration approach

72. 72
Integration approachIntegration approach

73. 73
Integration approachIntegration approach

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

77. 77
Integration approachIntegration approach

78. 78
Integration approachIntegration approach

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

93. 93
Integration approachIntegration approach

94. 94
Analyses change models/abstractionsAnalyses change models/abstractions

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

100. 100
Integration approachIntegration approach

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

218. 218
ContributionsContributions

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