Using Formal Analysis and Search-based Techniques to
Address the Assurance of Cyber-Physical Systems at the Requirements Level
By
Byron DeVries

A DISSERTATION
Submitted to
Michigan State University
in partial fulfillment of the requirements
for the degree of
Computer Science - Doctor Of Philosophy
2017

ABSTRACT
Using Formal Analysis and Search-based Techniques to
Address the Assurance of Cyber-Physical Systems at the Requirements Level
By
Byron DeVries
For high-assurance cyber-physical systems (CPS), such as the onboard features in modern
transportation systems (e.g., automobiles, trains, and flight systems), ensuring acceptable
and safe behavior is of paramount importance. Furthermore, the increasing complexity and
the number of onboard features for autonomous vehicles further exacerbates the challenge
of guaranteeing safe behavior. The operation of these high-assurance cyber-physical systems
depends on the specification, implementation, and verification of those systems. Obstacles
to assessing and ensuring assurance for cyber-physical system requirements may occur in
many forms, but two significant sources of specification errors are incomplete requirements
specifications and undesired feature interactions. In the case of incomplete requirements, it
can be challenging to enumerate all the decomposed requirements necessary to satisfy a requirement (i.e., ensuring completeness), especially when considering different combinations
of environmental conditions. A feature interaction occurs when two or more features satisfy
specific properties in isolation, but no longer satisfy those properties when they are composed
together. It may be necessary to analyze an exponential number of feature combinations to
detect all possible interactions, resulting in a potentially exponential number of feature interaction results presented to the system developer. Furthermore, the uncertainty created by
unexpected system and environmental scenarios exacerbates already difficult requirements
specifications problems, many of which involve an exhaustive search for errors and their
causes. That is, the exponential number of possibilities represents not only computational
growth but also growth in the effort it takes the system designer to assess the results. This
doctoral research tackles two key requirements assurance problems that exhibit these characteristics: requirements incompleteness and undesired feature interactions. The work explores

how formal analysis and search-based techniques can be used in a complementary and synergistic fashion to address the assurance of cyber-physical systems facing environmental and
system uncertainty, both at design time and run time. Industrial applications are used to
demonstrate the respective techniques.

ACKNOWLEDGMENTS

I would like to thank my advisor, Dr. Betty H. C. Cheng, for taking a chance on a
non-traditional student who remained in the workforce. Without Dr. Cheng’s understanding
and support I would have never had such an opportunity, much less completed a doctoral
program. I could not have asked for a better advisor, or one I could have learned more from.
I would also like to thank my committee members, especially for their flexibility given
their very busy schedules. A heart felt thank you to Dr. Kalyanmoy Deb, Dr. Sandeep
Kulkarni, and Dr. Philip McKinley.
Many thanks to those I met along the way, especially those from the SENS lab. A special
thanks to Dr. Tony Clark, Dr. Erik Fredericks, and Dr. Jared Moore whose experiences I
could learn from as they went through the process before me.
I would be remiss if I did not thank Dr. Paul Jorgensen, a true friend and mentor, for
sparking my interest in software engineering in his graduate courses. Additionally, I would
like to thank Dr. Greg Wolffe for allowing me to take part in my first real academic research,
and Dr. Christian Trefftz for his constant positivity, supportiveness, and providing a very
kind introduction to Dr. Cheng.
Most importantly, I would like to thank my wife Angela. Without her, this would have
never been possible. I have leaned on her for both practical and emotional support throughout, and she gave liberally of both.

iv

TABLE OF CONTENTS

LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ix

LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

Chapter 1 Introduction . . . . .
1.1 Problem Description . . . .
1.2 Thesis Statement . . . . . .
1.3 Research Contributions . . .
1.4 Organization of Dissertation

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

1
2
4
4
6

Chapter 2 Background . . . . . . . . . . . . . .
2.1 Goal Models . . . . . . . . . . . . . . . . . .
2.2 Utility Functions . . . . . . . . . . . . . . .
2.3 Symbolic Analysis . . . . . . . . . . . . . . .
2.4 Evolutionary Computation . . . . . . . . . .
2.5 Industrial Applications . . . . . . . . . . . .
2.5.1 Automotive Braking Systems . . . .
2.5.2 Automotive Adaptive Cruise Control

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

8
8
10
11
11
12
12
13

Chapter 3 Detecting Incomplete Requirements: Using Symbolic Analysis
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Adaptive Cruise Control Input Model . . . . . . . . . . . . . . . . . . . . . .
3.3 Symbolic Analysis Approach . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Ares Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Scalability and Limitations . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Symbolic Analysis Case Study . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Incomplete AND Decomposition: Goal D.1 . . . . . . . . . . . . . . .
3.4.2 Incomplete OR Decomposition: Goal B.3 . . . . . . . . . . . . . . . .
3.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.4 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Symbolic Analysis Related Work . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15
16
18
21
24
28
29
29
34
38
38
39
40

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

Chapter 4
4.1
4.2

4.3

Detecting Incomplete Requirements: Using Evolutionary Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evolutionary Computation Approach . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Step 1: Generate Detection Logic . . . . . . . . . . . . . . . . . . . .
4.2.2 Step 2: Search for Counterexamples and Summarize . . . . . . . . . .
4.2.3 Scalability and Limitations . . . . . . . . . . . . . . . . . . . . . . . .
Evolutionary Computation Case Study . . . . . . . . . . . . . . . . . . . . .
v

41
41
43
44
46
49
49

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

50
50
50
51
52
53
53
54
54

Chapter 5 Detecting Incomplete Requirements: At Run Time
5.1 Detecting at Run Time . . . . . . . . . . . . . . . . . . . . . . .
5.2 Complete Adaptive Cruise Control Input Model . . . . . . . . .
5.3 Run-Time Approach . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 DFD Step 1: Generate Logical Expression . . . . . . . .
5.3.2 DFD Step 2: Generate Monitoring Code . . . . . . . . .
5.3.3 Execution Time & Deployment . . . . . . . . . . . . . .
5.3.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Run-Time Examples . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . .
5.4.2 Incomplete Requirement Decomposition . . . . . . . . .
5.4.3 Inconsistent Requirement Decomposition . . . . . . . . .
5.4.4 Threats to Validity . . . . . . . . . . . . . . . . . . . . .
5.5 Run-Time Related Work . . . . . . . . . . . . . . . . . . . . . .
5.5.1 Requirements Completeness . . . . . . . . . . . . . . . .
5.5.2 Run-Time Monitors . . . . . . . . . . . . . . . . . . . . .
5.6 Lykus Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

55
56
59
61
62
65
66
67
67
68
68
70
72
73
73
74
74

Chapter 6 Detecting Feature Interactions: Using Symbolic Analysis
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Formally Specifying Feature Interactions . . . . . . . . . . . . . . . .
6.2.1 Standard Feature Interactions . . . . . . . . . . . . . . . . . .
6.2.2 N-Way Feature Interaction Extension . . . . . . . . . . . . . .
6.2.3 Requirements-Based Formalization of Feature Interactions . .
6.2.4 Phorcys Feature Interaction Causes . . . . . . . . . . . . . . .
6.3 Proofs of Soundness and Completeness . . . . . . . . . . . . . . . . .
6.4 Goal-Based Modeling of Features . . . . . . . . . . . . . . . . . . . .
6.4.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.2 Pre- and Post-Conditions . . . . . . . . . . . . . . . . . . . . .
6.4.3 Braking System Goal Model Example . . . . . . . . . . . . . .
6.5 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1 FI Detection Process . . . . . . . . . . . . . . . . . . . . . . .
6.5.2 Assumptions and Limitations . . . . . . . . . . . . . . . . . .
6.6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.1 Specification Error Causes . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

75
76
78
78
79
79
81
82
85
85
86
87
89
89
98
99
99

4.4

4.5

4.3.1 Symbolic Analysis . . . . . . . .
4.3.2 Evolutionary Computation . . . .
4.3.3 SA Initialization then EC . . . .
4.3.4 Periodic SA with EC Results . .
4.3.5 Comparison . . . . . . . . . . . .
Evolutionary Computation Related Work
4.4.1 Requirements Completeness . . .
4.4.2 Search for Diversity . . . . . . . .
Summary . . . . . . . . . . . . . . . . .

vi

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

6.7

6.8

6.6.2 Modeling Error Introduces FI .
6.6.3 Feature Interaction Free Model
6.6.4 Discussion . . . . . . . . . . . .
Related Work . . . . . . . . . . . . . .
6.7.1 Feature Interaction . . . . . . .
6.7.2 Feature Representation . . . . .
Summary . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

101
104
105
105
105
107
108

Chapter 7 Detecting Feature Interactions: Using Evolutionary Computation109
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.2 Input Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.3 Evolutionary Computation Approach . . . . . . . . . . . . . . . . . . . . . . 112
7.3.1 Phorcys-EC Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.3.2 Comparison of Analysis Approaches . . . . . . . . . . . . . . . . . . . 116
7.4 Evolutionary Computation Case Study . . . . . . . . . . . . . . . . . . . . . 119
7.4.1 Symbolic Analysis (SA) . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.4.2 Evolutionary Computation (EC) . . . . . . . . . . . . . . . . . . . . . 122
7.4.3 SA+EC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.4.4 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.5 Evolutionary Computation Related Work . . . . . . . . . . . . . . . . . . . . 125
7.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Chapter 8 Detecting Feature Interactions: At Run Time
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Run-Time Approach . . . . . . . . . . . . . . . . . . . .
8.2.1 Step (1): Generate FI Detection Logic . . . . . .
8.2.2 Step (2): Generate Executable Code . . . . . . . .
8.2.3 Record Failures and/or Adapt . . . . . . . . . . .
8.2.4 Limitations . . . . . . . . . . . . . . . . . . . . .
8.3 Run-Time Case Study . . . . . . . . . . . . . . . . . . .
8.4 Run-Time Related Work . . . . . . . . . . . . . . . . . .
8.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

127
127
129
130
131
132
133
133
136
137

Chapter 9 Detecting Interactions of Non-Functional Properties
9.1 Detecting Feature Interactions . . . . . . . . . . . . . . . . . . . .
9.2 Representation of Non-Functional Requirements . . . . . . . . . .
9.2.1 Non-Functional Properties . . . . . . . . . . . . . . . . . .
9.2.2 Weak Mitigation . . . . . . . . . . . . . . . . . . . . . . .
9.2.3 Strong Mitigation . . . . . . . . . . . . . . . . . . . . . . .
9.3 Detection via Symbolic Analysis Approach . . . . . . . . . . . . .
9.4 Detection of Interactions . . . . . . . . . . . . . . . . . . . . . . .
9.4.1 Safety Case Study: Collision . . . . . . . . . . . . . . . . .
9.4.2 Safety Case Study: Battery Charging . . . . . . . . . . . .
9.4.3 Performance Case Study . . . . . . . . . . . . . . . . . . .
9.4.4 Safety & Performance Case Study . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

139
140
143
143
144
146
146
157
157
163
170
178

vii

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

9.5
9.6

Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Chapter 10 Contributions . . . . . . . . . . . . .
10.1 Summary of Contributions . . . . . . . . . .
10.1.1 Requirements Incompleteness . . . .
10.1.2 Feature Interactions . . . . . . . . .
10.1.3 Non-functional Interactions . . . . .
10.2 Future Investigations . . . . . . . . . . . . .
10.2.1 Requirements Incompleteness Caused
10.2.2 Partial Feature Interactions . . . . .
10.2.3 Partial Requirements Incompleteness
10.2.4 Automatic Mitigation Strategies . . .
10.2.5 Non-Functional Security Interactions
10.2.6 Incomplete Test Sets . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

187
187
189
191
193
195
195
195
196
196
196
197

APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A Incomplete Requirements Artifacts . . . . . . .
Appendix B Feature Interaction Artifacts . . . . . . . . . . .
Appendix C Non-Functional Feature Interaction Artifacts

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

198
199
255
293

. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
by FI
. . . .
. . . .
. . . .
. . . .
. . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

BIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

viii

LIST OF TABLES

Table 3.1:

Agents used in Goal Model . . . . . . . . . . . . . . . . . . . . . . . .

20

Table 3.2:

ENV, MON, and REL Properties . . . . . . . . . . . . . . . . . . .

22

Table 3.3:

Units and Scaling for Variables in Table 3.2 . . . . . . . . . . . . . .

23

Table 3.4:

Counterexample Variables for D.1 in Goal Model M . . . . . . . . . .

32

Table 3.5:

Counterexample Variables for B.3 in Goal Model M 0 . . . . . . . . .

36

Table 5.1:

Agents used in Goal Model . . . . . . . . . . . . . . . . . . . . . . . .

60

Table 5.2:

ENV, MON, and REL Properties . . . . . . . . . . . . . . . . . . .

61

Table 5.3:

Units and Scaling for Variables in Table 5.2 . . . . . . . . . . . . . .

61

Table 5.4:

Satisfaction Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

Table 5.5:

Incomplete Decomposition Values . . . . . . . . . . . . . . . . . . . .

70

Table 5.6:

Environmental Assumptions: Incompleteness . . . . . . . . . . . . . .

70

Table 5.7:

Inconsistent Decomposition Values . . . . . . . . . . . . . . . . . . .

71

Table 5.8:

Environmental Assumptions: Inconsistency . . . . . . . . . . . . . . .

72

Table 6.1:

FI Causes in Goal Model M . . . . . . . . . . . . . . . . . . . . . . .

99

Table 6.2:

Variables for Cause B Counterexample in Goal Model M . . . . . . . 100

Table 6.3:

Variables for Cause C Counterexample in Goal Model M . . . . . . . 101

Table 6.4:

FI Causes in Goal Model M 0 . . . . . . . . . . . . . . . . . . . . . . . 102

Table 6.5:

Counterexamples for FIs in Goal Model M 0 . . . . . . . . . . . . . . . 104

Table 6.6:

Detected FI Causes in Goal Model M 00 . . . . . . . . . . . . . . . . . 105

Table 7.1:

FI Causes in the Goal Model . . . . . . . . . . . . . . . . . . . . . . . 119
ix

Table 7.2:

Feature B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Table 7.3:

Feature C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Table 8.1:

Variables for Failure of Feature B . . . . . . . . . . . . . . . . . . . . 134

Table 8.2:

Run-Time Results for Feature B . . . . . . . . . . . . . . . . . . . . . 135

Table 8.3:

Variables for Failure of Feature C . . . . . . . . . . . . . . . . . . . . 135

Table 8.4:

Run-Time Results for Feature C . . . . . . . . . . . . . . . . . . . . . 136

Table 9.1:

Possible Failure Resolutions . . . . . . . . . . . . . . . . . . . . . . . 156

Table 9.2:

Counterexample: Variables for Interaction in Goal Model M 0 . . . . . 159

Table 9.3:

Counterexample: Variables for Failure in Goal Model M 00 . . . . . . . 161

Table 9.4:

Counterexample: Variables for Failure in Goal Model M 000 . . . . . . . 162

Table 9.5:

Example Counterexample for Non-Functional FI Causes . . . . . . . . 181

x

LIST OF FIGURES

Figure 1.1: Top Level Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Figure 2.1: Braking System Overview . . . . . . . . . . . . . . . . . . . . . . . .

13

Figure 3.1: Adaptive Cruise Control Goal Model . . . . . . . . . . . . . . . . . .

19

Figure 3.2: Ares Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . .

25

Figure 3.3: Example AND Decomposition in Goal Model M . . . . . . . . . . . .

30

Figure 3.4: Revised AND Decomposition in Goal Model M 0 . . . . . . . . . . . .

33

Figure 3.5: Example OR Decomposition in Goal Model M 0 . . . . . . . . . . . .

34

Figure 3.6: Revised OR Decomposition in Goal Model M 00 . . . . . . . . . . . . .

37

Figure 4.1: Ares-EC Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . .

44

Figure 4.2: Requirement D.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

Figure 4.3: Requirement B.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

Figure 5.1: Adaptive Cruise Control Goal Model . . . . . . . . . . . . . . . . . .

59

Figure 5.2: Lykus Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . .

62

Figure 5.3: Updated Utility Function Listing of C.1 . . . . . . . . . . . . . . . .

66

Figure 5.4: Experimental Autonomous Car . . . . . . . . . . . . . . . . . . . . .

68

Figure 6.1: Braking System Goal Model . . . . . . . . . . . . . . . . . . . . . . .

88

Figure 6.2: Phorcys Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . .

90

Figure 6.3: Goal Configurations that Satisfy Top-Level Goal . . . . . . . . . . . .

91

Figure 6.4: Goal Configuration 2 in Figure 6.3 . . . . . . . . . . . . . . . . . . .

92

Figure 6.5: Feature Interaction in Goal Configuration Set {B, C, E} . . . . . . . .

96

xi

Figure 6.6: 3-Way FI in Figure 6.1 Caused by B or C . . . . . . . . . . . . . . . . 101
Figure 6.7: 3-Way FI in M 0 Caused by B or C . . . . . . . . . . . . . . . . . . . . 104
Figure 7.1: Braking System Goal Model . . . . . . . . . . . . . . . . . . . . . . . 113
Figure 7.2: Phorcys-EC Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . 114
Figure 7.3: Phorcys-EC Data Flow Diagram: Step 2, SA . . . . . . . . . . . . . . 116
Figure 7.4: Phorcys-EC Data Flow Diagram: Step 2, SA+EC . . . . . . . . . . . 119
Figure 7.5: 3-Way FI in Figure 7.1 Caused by B or C . . . . . . . . . . . . . . . . 121
Figure 7.6: Environmental Variables . . . . . . . . . . . . . . . . . . . . . . . . . 124
Figure 8.1: Thoosa Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 8.2: Variables Calculated for FI Detection in Figure 6.1 . . . . . . . . . . 132
Figure 8.3: Propagation Function for SS (Slip Sensor) Figure 6.1 . . . . . . . . . 132
Figure 8.4: 3-Way FI in Figure 6.1 Caused by B or C . . . . . . . . . . . . . . . . 134
Figure 9.1: Safety Model: Non-Functional Properties . . . . . . . . . . . . . . . . 144
Figure 9.2: Non-Functional Model: Weak Mitigation . . . . . . . . . . . . . . . . 145
Figure 9.3: Non-Functional Model: Strong Mitigation . . . . . . . . . . . . . . . . 147
Figure 9.4: Soter Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . 148
Figure 9.5: Non-Functional Feature: Non-Functional Properties . . . . . . . . . . 150
Figure 9.6: Non-Functional Feature: Weak Mitigation . . . . . . . . . . . . . . . 151
Figure 9.7: Non-Functional Feature: Strong Mitigation . . . . . . . . . . . . . . . 152
Figure 9.8: Woven Goal Model Example . . . . . . . . . . . . . . . . . . . . . . . 153
Figure 9.9: Goal Model Woven With Non-Functional Safety Property (M ) . . . . 158
Figure 9.10: Goal Model Woven With Strong Mitigation (M 0 ) . . . . . . . . . . . 159
Figure 9.11: Brake Force Goal Update Excerpts of M 00
xii

. . . . . . . . . . . . . . . 161

Figure 9.12: Model Woven With Weak & Strong Mitigation (M 000 ) . . . . . . . . . . . 162
Figure 9.13: Model Woven With Updated Weak Mitigation (M f inal ) . . . . . . . . . . 163
Figure 9.14: Safety Model: Non-Functional Properties . . . . . . . . . . . . . . . . 164
Figure 9.15: Non-Functional Feature: Non-Functional Properties . . . . . . . . . . 165
Figure 9.16: Goal Model Woven With Non-Functional Battery Safety Property . . 165
Figure 9.17: Non-Functional Model: Weak Mitigation . . . . . . . . . . . . . . . . 166
Figure 9.18: Non-Functional Feature: Weak Mitigation . . . . . . . . . . . . . . . 167
Figure 9.19: Goal Model Woven With Non-Functional Battery Safety Weak Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Figure 9.20: Non-Functional Model: Strong Mitigation . . . . . . . . . . . . . . . . 168
Figure 9.21: Non-Functional Feature: Strong Mitigation . . . . . . . . . . . . . . . 169
Figure 9.22: Goal Model Woven With Non-Functional Battery Safety Strong Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Figure 9.23: Safety Model: Non-Functional Properties . . . . . . . . . . . . . . . . 171
Figure 9.24: Non-Functional Feature: Non-Functional Properties . . . . . . . . . . 172
Figure 9.25: Goal Model Woven With Non-Functional Battery Performance Property172
Figure 9.26: Non-Functional Model: Weak Mitigation . . . . . . . . . . . . . . . . 173
Figure 9.27: Non-Functional Feature: Weak Mitigation . . . . . . . . . . . . . . . 174
Figure 9.28: Goal Model Woven With Non-Functional Battery Performance Weak
Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Figure 9.29: Non-Functional Model: Strong Mitigation . . . . . . . . . . . . . . . . 176
Figure 9.30: Non-Functional Feature: Strong Mitigation . . . . . . . . . . . . . . . 177
Figure 9.31: Goal Model Woven With Non-Functional Battery Performance Strong
Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Figure 9.32: Woven Model: Functional With Both Safety and Performance Mitigation179
xiii

Figure 9.33: Environmental Variables for Non-Functional Failures due to FI . . . . 182
Figure 9.34: Final Braking System Goal Model . . . . . . . . . . . . . . . . . . . . 184
Figure 10.1: General Framework DFD . . . . . . . . . . . . . . . . . . . . . . . . . 189
Figure 10.2: Requirements Completeness DFD . . . . . . . . . . . . . . . . . . . . 191
Figure 10.3: Feature Interaction DFD . . . . . . . . . . . . . . . . . . . . . . . . . 193
Figure 10.4: Non-Functional Interactions DFD . . . . . . . . . . . . . . . . . . . . 194

xiv

Chapter 1
Introduction
For high-assurance cyber-physical systems, such as the onboard features in modern
transportation systems (e.g., automobiles, trains, and flight systems), ensuring acceptable
and safe behavior is important [65]. Furthermore, the increasing complexity and the number
of onboard features for autonomous vehicles further exacerbates the challenge of guaranteeing
safe behavior [4]. The operation of these high-assurance cyber-physical systems depends on
the specification, implementation, and verification of those systems. Obstacles to assurance
introduced early in the product life-cycle create a cascading effect that impacts downstream
artifacts. Worse, system specifications are often the basis for both implementation and testing
artifacts, resulting in specification errors that are not detected until negative consequences
occur in deployed systems. The difficulty in identifying specification errors is compounded
by both system and environmental uncertainty. The composition of independently-developed
features that realize a system introduces uncertainty when considering their cumulative behavior. Similarly, the impact of dimensionality (i.e., each of the environmental parameters
can be viewed as a dimension, thus increasing the environmental space with each added
parameter) from environmental parameters introduces uncertainty when unexpected environmental scenarios occur in an exponential number of possible environmental scenarios.
Consequently, automated techniques to detect counterexamples to the assurance of cyber1

physical systems within system specifications is fundamentally important, especially when
system and environmental uncertainty abound.
Obstacles to assessing and ensuring assurance for cyber-physical system requirements
may occur in many forms, but two significant sources of specification errors are incomplete
requirements specifications and undesired feature interactions. In the case of incomplete
requirements, it can be challenging to enumerate all the decomposed requirements necessary
to satisfy a requirement (i.e., ensuring completeness), especially when considering different
combinations of environmental conditions. A feature interaction occurs when two or more
features satisfy specific properties in isolation, but no longer satisfy those properties when
they are composed together [20]. It may be necessary to analyze an exponential number of
feature combinations to detect all possible interactions, resulting in a potentially exponential
number of feature interaction results presented to the system developer [5].

1.1

Problem Description

The uncertainty created by unexpected system and environmental scenarios exacerbates
already difficult requirements specifications problems, many of which involve an exhaustive
search for errors and their causes. That is, the exponential number of possibilities represents
not only computational growth but also growth in the effort it takes the system designer
to assess the results. This doctoral research tackles two key requirements assurance problems that exhibit these characteristics: requirements incompleteness and undesired feature
interactions.

Requirements Completeness: The usefulness of a system specification depends in part
on the completeness of the requirements [38]. However, enumerating all necessary requirements is difficult, especially when requirements interact with an unpredictable environment.
A specification built with an idealized environmental view is incomplete if it does not include
requirements to handle non-idealized behavior [38]. Often incomplete requirements are not
2

detected until implementation, testing, or worse, after deployment. Even when performed
during requirements analysis, detecting incomplete requirements is typically an error prone,
tedious, and manual task. Worse yet, a single completeness counterexample may not clearly
indicate the extent that incomplete requirements impacts the system or what range of environmental scenarios are affected.

Feature Interaction: Independently-developed features often exhibit overlapping, yet
conflicting behavior termed feature interactions [40]. Detecting unwanted feature interactions amongst even a moderate number of features can involve the analysis of an exponential
number of possible interactions. To combat growth in both computational and designer effort, many researchers limit their analysis to pair-wise interactions [10, 21, 41, 59] where
only combinations of two features are analyzed at a time. However, a recent study found
interactions greater than pair-wise were found in every system analyzed [5]. This finding
indicates that n-way interaction detection techniques are needed that do not overwhelm the
system designer with results. A potentially human resource-intensive step is the subsequent
effort needed by the system designer to assess each detected interaction to determine the
failure caused by the feature interaction. Further, the definition of safety requirements are
intended to ensure the safety properties of the system under development. However, safety
properties of the system often crosscut functional and non-functional requirements. These
cross-cutting concerns are dispersed throughout the requirements. This dispersion renders
manual insertion of the safety concerns difficult and error prone.

Key Challenges: In order to address industry-relevant problems with respect to these
two areas, we must develop techniques with the following characteristics:
• Automated analysis techniques to reason about the specification of a system,
• Techniques to explore a broad solution space given challenges posed by environmental
and system uncertainty, and
3

• Techniques that can be applied at design time and run time.

1.2

Thesis Statement

This research defines a set of analysis methods to address the generation of counterexamples in model-based definitions of requirements. Specifically, we detect interactions and
incomplete requirement decompositions in hierarchical requirements models.
Thesis Statement: Formal analysis and search-based techniques can be used in a complementary and synergistic fashion to address the automated detection and counterexample
generation of incomplete requirements and n-way feature interactions in cyber-physical systems facing environmental and system uncertainty.

1.3

Research Contributions

This dissertation research focuses on identifying solutions to two key challenges: identifying incomplete requirements and undesired feature interactions. The research contributions
of this work are as follows.
1. Requirements Incompleteness: Detect incomplete requirements decomposition in
hierarchical requirements models. We illustrate our approach by analyzing a requirements model of an industry-based automotive adaptive cruise control system. We describe the following techniques that we developed to address this problem:
(a) Symbolic analysis to formally define requirements incompleteness and guarantee
detection of requirements completeness counterexamples if they exist [37].
(b) Evolutionary computation and symbolic analysis to detect a representative range
of requirements completeness counterexamples [38].
(c) Run-time analysis to detect incomplete requirements at run time [39].
4

2. Interaction Detection: Detect unwanted n-way feature interactions and determining their causes at the requirements level. Unlike previous n-way feature interaction
detection approaches that attempt to enumerate every set of interacting features, our
approach analyzes each feature for its ability to cause an interaction with other features, thus reducing designer assessment effort to be linear with respect to the number
of features. We illustrate our approach by applying our approach to an industry-based
automotive braking system comprising multiple subsystems. We describe the following
techniques that we have developed for this dissertation:
(a) Symbolic analysis to formally analyze feature interactions and guarantee detection
of interactions if they exist [40].
(b) Evolutionary computation and symbolic analysis to detect a representative range
of scenarios where a given feature interaction manifests [40].
(c) Run-time analysis to detect feature interactions at run time.
3. Non-functional Interaction Detection: Detect feature interactions that include
safety and/or performance non-functional requirements and may include, but are not
limited to include, functional requirements. We describe the following techniques that
we have developed for this dissertation:
(a) Symbolic analysis to formally analyze non-functional feature interactions and
guarantee detection of interactions if they exist.
(b) Evolutionary computation and symbolic analysis to detect a representative range
of scenarios where a given non-functional feature interaction manifests.
(c) Run-time analysis to detect non-functional feature interactions at run time.
This dissertation presents a framework comprising multiple automated analysis techniques that collectively identify counterexamples to assurance in the specifications of cyberphysical systems in the presence of system and environmental uncertainty. Specifically, we
5

analyze requirements models for the existence of counterexamples that identify requirements
incompleteness and feature interactions. Throughout this dissertation, we present the theoretical foundation of each technique, a prototype implementation, and the empirical validation on an industrial-based application. The flowchart in Figure 1.1 illustrates the relation
between identifying completeness counterexamples and identifying interactions in requirements models. A system designer-defined set of requirements are analyzed for incomplete
requirements decomposition. If an incomplete decomposition exists, then the requirements
model is redefined by the system designer based on the detected counterexample. When no
additional decomposition counterexamples exist, then the requirements are analyzed for interactions. If an interaction exists, then the system designer updates the requirements model
to remove the interaction and the process may be reapplied. When no additional interactions
exist, then a complete and interaction free requirements model is returned.
Legend:

Requirements
Model

Artifact
Flow
Process

Detect
Incompleteness

System
Designer
Update

Yes

Incomplete?

No

Detect
Interaction

Interaction?

Yes

No

Revised
Requirements
Model

Figure 1.1: Top Level Flowchart

1.4

Organization of Dissertation

The organization of the remainder of this dissertation is as follows. Chapter 2 reviews
background material on modeling techniques used in this work, feature interactions, symbolic
6

analysis, evolutionary computation, and two industrial case studies in automotive braking
systems and adaptive cruise control. In Chapter 3, we introduce Ares, an approach to detect
incomplete requirements decomposition in hierarchical goal models using symbolic analysis,
and then apply it to an automotive adaptive cruise control case study. Chapter 4 presents
Ares-EC, a process of combining both symbolic and evolutionary computation to detect
wider ranges of requirements completeness counterexamples when applied to the same case
study. Next, in Chapter 5 we describe Lykus, a technique of generating run-time detection
code for incomplete and inconsistent requirements. We then move to feature interaction detection. In Chapter 6, we describe Phorcys, an approach to detect feature interactions and
identify their causes; and we illustrate the approach using the automotive braking system
case study. Chapter 7 presents Phorcys-EC, a process of combining both symbolic and evolutionary computation to detect wider ranges of feature interaction counterexamples in both
the feature space and environmental scenario space. Next, in Chapter 8, we describe Thoosa,
a process of generating run-time detection code for the features that fail due to a feature
interaction. Chapter 9 describes Soter, a process for detecting non-functional interactions
across both non-functional and functional features, including both safety and performance
non-functional requirements. Related work is included in each of the individual chapters. Finally, Chapter 10 presents a summary of the contributions of this dissertation and overviews
future investigations.

7

Chapter 2
Background
This chapter provides background information for the dissertation. An overview of goal
modeling is provided followed by information on utility functions. Symbolic analysis is covered along with evolutionary computation. Finally, the two industry applications used for
this research, automotive braking systems and adaptive cruise control systems, are described.

2.1

Goal Models

While the concepts of this dissertation are applicable to any hierarchical requirements
modeling framework, including i * [96], KAOS goal modeling [87], or simply hierarchical requirements modeling [82], the case studies in this dissertation make use of the KAOS goal
modeling notation.1 True of all hierarchical requirements modeling approaches, requirements
are specified by decomposed requirements that are necessary to satisfy their parent requirement. Decomposition continues until some termination criteria is met.
KAOS goal modeling realizes Goal-Oriented Requirements Engineering (GORE) via a
graph-based decomposition of high-level goals and objectives that make up the system-to-be.
High-level objectives are decomposed into subsequently finer-grained goals and ultimately
into system requirements and environmental expectations, or prerequisites satisfied by agents
1

For this work we do not use the KAOS formal decomposition patterns.

8

of the environment. Decomposition within KAOS goal modeling allows for both AND and
OR decompositions [87]. The satisfaction of an AND-decomposed goal only occurs if all of its
aggregate decomposed goals are satisfied. In contrast, the satisfaction of an OR-decomposed
goal occurs if any of its aggregate decomposed goals are satisfied. Decomposition terminates
when a system requirement can be satisfied by an agent or an environmental expectation
can be measured by an agent of the environment [87].
Goals are classified as either functional or non-functional. A functional goal defines a
service, or element of functionality, of the system-to-be (e.g., ‘stop the car’). Non-functional
goals, in contrast, define a constraint on the services that a functional goal provides (e.g.,
‘stop the car quickly’). Functional goals may be further refined into either invariant or noninvariant goals, denoted ‘Maintain’ (e.g., Maintain(Current Speed)) and ‘Achieve,’ (e.g.,
Achieve(Higher Speed)) respectively. Decomposition is terminated when a requirement or
expectation can be fully satisfied by a single agent [48]. Since the methods presented are
intended to be generally applicable to hierarchical goal and requirements modeling, we refer
to goals and requirements interchangeably.
Typically, requirements incompleteness is due to unexpected scenarios for which the
system designer did not anticipate and are unsatisfied for the high-level objectives of the
system-to-be, more detailed, decomposed requirements do not imply their parent requirement. Formally, when the decomposed requirements (R1 , R2 , R3 , R... , Rn ), as well as the domain properties and assumptions, Dom (e.g., an increase in throttle causes an increase in
speed), of the parent requirement (R) are satisfied, then the parent requirement is satisfied,
as indicated by the entailment operator (i.e., ) in the following expression [87]:

{R1 , R2 , R3 , R... , Rn , Dom}  R.

(2.1)

If a requirement cannot be discharged or handled by a single agent, then it must be decomposed into additional aggregate requirements that collectively can be combined to satisfy
9

the parent requirement. A requirement may even be decomposed into a single decomposed
requirement if the parent requirement cannot be satisfied by a single agent of the system. A
set of aggregate decomposed requirements is one of potentially numerous possible decompositions, and thereby constrains the solution for a given (parent) requirement to the behavior
specified by the aggregate decomposed requirements. Necessarily, the parent requirement
may be satisfied for any complete decomposition, but not all decompositions are necessarily
equivalent with respect to the behavior of any other complete decomposition.
In this dissertation, goal and requirement model labels are in bold courier font, while
variable names, goal and requirement text, and emphasis are indicated by italics.

2.2

Utility Functions

Utility functions [89] have been used for run-time monitoring [45, 47] to assess the
satisfaction of requirements. Satisfaction, while typically specified as a Boolean expression,
may also be represented as a degree of satisfaction called satisficement [92]. Previously,
Athena [75] was developed to automatically generate utility functions from specific properties
of the environment (ENV, MON, REL), where:
• ENV represents environmental properties related to the satisfaction of the goal that
may or may not be directly observable (e.g., the expected speed of a vehicle at a future
time),
• MON represents monitors (e.g., agents and sensors) in the system that are able to
monitor specific values (e.g., a GPS speed sensor that measures the speed of a vehicle
at the current time), and
• REL represents relationships between the monitors and environmental properties that
relate to the satisfaction or satisficement of goals (e.g., relating expected future vehicle speed and current vehicle speed to measure the satisficement of a requirement to
increase speed).
10

Athena uses the REL properties to compute the degree of satisficement that the utility
function returns as either state-, metric-, or fuzzy-logic based satisficement results, represented as Boolean, numeric, or functions of real values, respectively. Utility functions encode
domain properties and assumptions (Dom) that are present in the ENV, MON, and REL
that describe the system. The domain properties are manually specified by the requirements
engineer [24]. While the addition of utility functions adds additional properties for each requirement that must be documented, in cases where utility functions are already used to
assess run-time satisfaction, the utility functions can be used with no additional documentation required.

2.3

Symbolic Analysis

Satisfiability Modulo Theories (SMT) solvers solve constraints defined in either SMTLIB [76] or SMT-LIB version 2 [12] standards [27]. SMT solvers are a collection of decidable
theories, represented as decision procedures, and a SAT solver, all of which are applied via
strategies to solve a diverse range of constraint problems [33]. In this dissertation, we use
the Microsoft Z3 SMT Solver [32], given its ubiquity and availability.

2.4

Evolutionary Computation

Genetic Algorithms are a stochastic optimization method often used to optimize complex
problems [51, 70]. A population of proposed solutions is randomly initialized and assigned a
fitness value that represents an evaluation of the performance of the individual in a population. Additional individuals are ‘born’ using evolutionary operators including crossover and
mutation. Crossover mates two or more individuals by combining aspects of their genetic
code into a new individual. Mutation modifies an individual randomly. Typically, a portion
of the new and existing individuals are kept for the next generation. The process of simulated
evolution continues until some upper bound, often a number of generations, is reached.
11

2.5

Industrial Applications

In this dissertation, we make use of two industrial systems within the automotive domain: braking systems and adaptive cruise control. A general overview of each of these
systems is described in this section.

2.5.1

Automotive Braking Systems

Braking systems, such as the one considered in this dissertation, while often viewed
as a single subsystem within a vehicle, in fact, comprise two categories of subsystems: 1)
control subsystems that command a specific brake force and 2) actuator subsystems that
apply the commanded brake force. For the braking system used in this dissertation, the
two subsystems that apply a specific brake force are standard force braking (i.e., physical
hydraulic force applied to brake rotors in disk brakes to cause friction that slows the turning
speed of the wheels) and regenerative braking in hybrid vehicles (i.e., use of electric generators
to reduce speed and store energy). The two subsystems that can command the commanded
brake force, thus providing active braking, are continuous braking (i.e., use of electroniccommanded signals to braking subsystems rather than physical hydraulic force) and antilock braking (i.e., intermittent application of braking to reduce wheel lockup). Braking is
performed by the friction provided by electric generators in regenerative braking, by the
friction created by standard disk brakes, or a combination of both. Regenerative braking
only provides limited stopping force, thus necessitating standard force braking for larger
commanded brake forces. Figure 2.1 provides a graphical overview indicating the brake force
from the brake pedal distribution to both the continuous and anti-lock braking features.
Both the continuous and anti-lock braking features distribute a commanded brake force
to the brake application features (i.e., standard and regenerative force). We differentiate
between the features that apply brake force to those that command brake force as a design
decision to promote extensibility. A commanded brake force, in the case of larger onboard
12

systems, may not even be directly tied to the brake force read from a pedal. For example,
an adaptive cruise control system may employ brake force to prevent collision with a target
car (i.e., car in front of current vehicle). Many cars also use the braking system to allow for
traction control on snowy or icy roads, by applying braking to only the wheels that spin out
of control.
Brake Force
Feature D
Anti-Lock Brakes

Command
Brake Force

Feature E
Continuous
Brakes

Commanded Brake Force
Feature C
Regen Force

Standard Brake
Force

Regen Brake
Force

Apply
Brake Force

Feature B
Standard Force

Figure 2.1: Braking System Overview

Onboard vehicle systems, including the braking system, may be viewed as individual
features. Similarly, the subsystems of a given system may also be viewed as individual features
depending on the level of subsystem decomposition. Herein, we use the term “feature” to refer
to the observable services and functionality provided by a given “subsystem” [10], where our
analysis focus is at the requirements level of a given feature (i.e., observable functionality).
That is, each feature may have multiple requirements and is viewed as a subsystem. For our
braking system, we have four subsystems, each of which is considered a feature: standard
force braking, regenerative force braking, continuous braking, and anti-lock braking.

2.5.2

Automotive Adaptive Cruise Control

An Adaptive Cruise Control (ACC) system uses radar to adjust vehicle speed ensuring a
safe following distance from the car ahead while maintaining as close to the desired speed as
13

possible. An ACC can be viewed in four parts: cruise control modes (e.g., on, off), increasing
speed, lowering speed, and maintaining speed. Speed is increased or lowered to match the
desired speed, however speed may also be lowered if there is not a safe distance to the target
car (i.e., car immediately in front). Similarly, the speed will not continue to increase if the
safe distance is violated. The speed is maintained if both the desired speed is met and the
target car is a safe distance.

14

Chapter 3

Detecting Incomplete Requirements:
Using Symbolic Analysis

The usefulness of a system specification depends in part on the completeness of the
requirements. However, enumerating all necessary requirements is difficult, especially when
requirements interact with an unpredictable environment. A specification built with an idealized environmental view is incomplete if it does not include requirements to handle nonidealized behavior. Often incomplete requirements are not detected until implementation,
testing, or worse, after deployment. Even when performed during requirements analysis,
detecting incomplete requirements is typically an error prone, tedious, and manual task.
This chapter introduces Ares, a design-time approach for detecting incomplete requirements
decomposition using symbolic analysis of hierarchical requirements models. We illustrate
our approach by applying Ares to a requirements model of an industry-based automotive
adaptive cruise control system. Ares is able to automatically detect specific instances of incomplete requirements decompositions at design-time, many of which are subtle and would
be difficult to detect, either manually or with testing.
15

3.1

Introduction

Despite the best efforts and intentions of system developers, developing complete requirements is often a challenge. Exhaustively enumerating all cases sufficient to satisfy expected functionality can be prohibitively difficult, especially when unexpected scenarios arise.
Verification of decomposed requirements commonly requires domain expertise to ensure completeness. However, verification is often performed manually, at some expense, and without
guarantee. This chapter presents Ares,1 a symbolic analysis approach to automatically identifying counterexamples to completeness in hierarchical requirements models.
The process used to create requirements that are decomposed completely is not
straightforward, and detecting incomplete requirements is still an active research question [2, 23, 46, 69, 98]. For example, a requirement for a vehicle may be to stop. In an idealized
system, applying brake force (e.g., from hydraulic brakes) would be sufficient. However, in a
realistic system, applying the maximum amount of brake force may not be sufficient in the
presence of the maximum amount of throttle. In inclement weather, brake force may not be
sufficient without anti-lock brakes. Enumerating all decomposed requirements necessary to
satisfy a requirement (e.g., to stop) can be challenging especially when considering different
combinations of environmental conditions. While formal methods exist to decompose goals
and requirements with guaranteed completeness [31], they are not widely used in practice,
and system designers are limited to only specific formal decomposition rules. Methods also
exist for identifying counterexamples to completeness [2], but are limited to completeness
with respect to specific domain properties (i.e., the set of system and environmental variables and states) rather than with respect to decomposition and require manual review for
relevance and applicability. Currently, no methods exist that automate the detection of incomplete requirements decomposition without imposing restrictions on how requirements are
decomposed or described.
This chapter describes Ares, a symbolic analysis approach to automatically identify
1

Ares is the Greek god of war, especially the untamed aspects of war.

16

environmental configurations where completeness properties are violated in a hierarchical
requirements model. Hierarchical requirements satisfaction can be assessed in two ways: its
individual satisfaction, or the satisfaction of a requirement’s aggregate decomposed requirements (i.e., children or sub-requirements). Given complete decomposition, a requirement
should be satisfied whenever its aggregate decomposed requirements are satisfied. For example, given a requirement to stop and a decomposed requirement to brake, the requirement
to stop should be satisfied if the aggregated decomposed requirements are satisfied (i.e., to
brake). However, if the throttle can overwhelm the brakes, then the requirement to stop
may not actually be satisfied. An additional aggregate decomposed requirement is needed
when a requirement is not satisfied even though its aggregate decomposed requirements are
satisfied. Since the requirement to stop is unsatisfied due to the force created by the throttle,
one possible solution would be AND decomposed into two requirements: a requirement to
brake and a requirement to use no throttle (e.g., remove foot from gas pedal), both of which
are necessary for the satisfaction of the requirement to stop. Ares identifies incomplete decompositions in the form of counterexamples that are summarized for the system designer
to revise the requirements accordingly.
Ares analyzes individual requirements within a hierarchical requirements model using
expressions from utility functions [75] that represent requirements satisfaction. Utility functions translate system-monitored data to scalar values that scale proportionally to the degree a requirement is satisfied. Utility functions are typically used to monitor requirements
at run-time [75]. Rather than using the utility functions for run-time monitoring, Ares uses
the expressions themselves for symbolic analysis. For each requirement’s decomposition, Ares
identifies, via symbolic analysis of the range of possible requirement variables values, whether
are any environmental conditions exist that cause a requirement to be unsatisfied while
its aggregate decomposed requirements are satisfied. Counterexamples are identified for an
industry-based requirements model for an adaptive cruise control system, and incomplete
requirements decompositions are summarized and presented to the system designer.
17

The contributions of this chapter are as follows:
• We introduce Ares, a design-time, symbolic analysis approach to automatically detect
incomplete decomposition in hierarchical requirements models.
• We present a prototype implementation of the Ares symbolic analysis approach.
• We demonstrate the applicability of Ares on an industry-based automotive example,
an adaptive cruise control system.
The remainder of this chapter is organized into the following sections. Section 3.2 provides an overview of the input model. Section 3.3 details the approach. Section 3.4 describes
the results of a case study, and Section 3.5 details related work. Finally, Section 3.6 summarizes the work.

3.2

Adaptive Cruise Control Input Model

The Adaptive Cruise Control system is a cruise control system with radar that adjusts the vehicle’s speed autonomously to ensure a safe distance with a target vehicle, while
maintaining a desired speed. Figure 3.1 is a KAOS goal model for the ACC system. Keywords Maintain and Achieve are shortened to M and A, respectively. Table 3.1 identifies
the agents referenced in Figure 3.1. The ACC model defined here was manually developed
by the authors in conjunction with automotive industrial practitioners and is intended to be
representative of a realistic example of industrial requirements engineering artifacts.2
In Figure 3.1, the goals that begin with prefix ‘A.’ (top left) contain the overall hierarchy
of ACC modes and also includes manual throttle and manual brake response requirements.
Goals A.6 through A.14 refer to the state of the value of their respective agents. For example,
A.6 indicates that its agent, Cruise Switch Sensor , is Off . All of A.6 through A.14 are
2

Conversations with automotive industrial practitioners included reviewing our goal modeling approach
to automotive systems, including review of the specific ACC requirements model included here, over the
course of several meetings.

18

A.1 M(Adaptive Cruise System)

B.2
A(Slower Speed)

A(Off, Off)

M(Off, Off)

A.2

M(On, Off)

M(On, On)

A.4

A.3

A.5

B.3
A(Slow Car)

B.1
A.6

= On

1

2

A(Off)

A.12

A.13

= On

= Off

= On

= On

1

2

1

2

A.11

A.8

A.7

= Off

A.9

A.10

= Off

= Off

1

2

3

A.14

M(Automatic Control)

B.4
A(Reduce Throttle)

B.5
B.8

M(Manual Control)

A.16
M(Throttle
Response)

A.18

Speed > Desired Speed OR
Distance < Safe Distance

A.17

A.19

A.21

A.20

A(Throttle Actuator =
Throttle Pedal Sensor)

4

5

6

B.13

GPS Speed >
Desired Speed

8

Distance 2 <
Safe Distance

10

C.1

B.17

B.18

A(Brake Actuator =
Brake Pedal Sensor + 1)

A(Brake Pedal
Sensor Reading)

7

6

C.2

B.15
A(Increase Brake)

11

B.16

A(Faster Speed)

Speed < Desired Speed AND
Distance > Safe Distance

B.14

Distance 1 <
Safe Distance

9

7

4

4

Distance <
Safe Distance

B.12

Wheel Speed >
Desired Speed

A(Brake Actuator =
A(Brake Pedal
Sensor Reading) Brake Pedal Sensor
Reading)

Throttle Angle > 0

B.10

Speed >
Desired Speed

B.11

B.7

A(Throttle Pedal
Sensor Reading)

5

B.9

M(Brake Response)

A(Throttle Pedal
Sensor Reading)

B.6

A(Throttle Actuator =
Throttle Pedal Sensor - 1)

A.15

B.19

Throttle Pedal
Sensor = 0

Brake Pedal
Sensor < 45

4

6

D.1

C.3

M(Speed)

A(Increase Throttle)

C.12
C.4

C.5

C.6
Wheel Speed Sensor
< Desired Speed

5

7

10

5

Throttle Angle < 45

11

A(Throttle Pedal Sensor Reading)

Speed = Desired Speed

D.8

4

C.11
Distance Sensor 2 >
Safe Distance

D.5

D.4

C.9

Distance >
Safe Distance

C.10
Distance Sensor 1 >
Safe Distance

Speed = Desired Speed AND
Distance > Safe Distance

C.8

GPS Speed Sensor
< Desired Speed

9

A(Throttle Actuator =
Throttle Pedal Sensor)

D.2

C.7

8

D.3

A(Brake Angle = 0)

A(Throttle Actuator =
Throttle Pedal
Sensor + 1)

Speed < Desired Speed

C.13
A(Throttle Pedal
Sensor Reading)

Distance > Safe Distance

D.6

8

4

4

D.7

Wheel Speed Sensor =
Desired Speed

GPS Speed Sensor =
D.9
Desired Speed
Distance Sensor 1 >
Safe Distance
9

10

D.10
Distance Sensor 2 >
Safe Distance
11

Figure 3.1: Adaptive Cruise Control Goal Model

expectations (i.e., conditions to be handled by the environment or outside the control of the
system), except for A.8 which is a system goal to turn Off the Cruise Active Switch. The toplevel goal, A.1, is decomposed into four categories of functionality (A.2, A.3, A.4, and A.5),
each of these indicates a pair of values from Cruise Switch Sensor and Cruise Active Sensor ,
respectively. This functionality is dependent on the values of the Cruise Switch Sensor and
Cruise Active Sensor, which are either maintained or achieved. In goals A.3 and A.4, where
the Cruise Active Sensor is Off, the throttle is controlled manually. If the Cruise Active
Sensor is On, but the Cruise Switch Sensor is Off (i.e., goal A.2), then the Cruise Active
Switch is turned off via an Achieve goal (i.e., A.8). In goal A.5 where both Cruise Active
Sensor and Cruise Switch Sensor are both On, the throttle is automatically controlled. The
remainder of the goal model, where goals are prefixed with ‘B.’, ‘C.’, or ‘D.’ represents
19

Table 3.1: Agents used in Goal Model
#
1
2
3
4
5
6
7
8
9
10
11

Agent (Sensor / Actuator)
Cruise Switch Sensor
Cruise Active Sensor
Cruise Active Switch
Throttle Pedal Sensor
Throttle Actuator
Brake Pedal Sensor
Brake Actuator
Wheel Speed Sensor
GPS Speed Sensor
Distance Sensor 1
Distance Sensor 2

portions of the automatic control for throttle and braking by changing or maintaining the
speed, detailed as follows:
Goal B.2 : ‘A(Slower Speed)’ decreases the speed by reducing throttle via goal B.4 or increase braking via goal B.15 when the Speed is greater than the Desired Speed (goal
B.9) or the Distance measured is less than the defined Safe Distance (goal B.10).
Goal C.1 : ‘A(Faster Speed)’ increases the speed by increasing the throttle via goal C.3
while ensuring braking is minimized via goal C.12 when the Speed is less than the
Desired Speed (goal C.4) and the Distance measured is greater than the defined
Safe Distance (goal C.9).
Goal D.1 : ‘M(Speed)’ maintains the speed by maintaining the current throttle position via
goal D.3 when the Speed is equal to the Desired Speed and the Distance measured is
greater than the defined Safe Distance (goal D.8).
The ENV, MON, and REL properties for the goal model in Figure 3.1 are defined in
Table 3.2. Environmental properties (ENV) that are not directly observable via agents or
sensors are calculated using a combination of monitors (MON) and a relationship (REL) to
compute their respective values. The ENV and MON properties are only listed when used
in the relationship (REL). For example, goals A.1 through A.21 can be assessed directly with
20

monitors (MON) without directly accessing environmental conditions. The ENV, MON,
and REL properties are generated manually by the requirements engineer. Table 3.3 defines
the range and unit for each of the variables defined in Table 3.2.

3.3

Symbolic Analysis Approach

Ares is a method for symbolically analyzing hierarchical requirements models for completeness. Issues with completeness are detectable when the measured satisficement of a
requirement is not logically implied by its decomposed requirements. For each decomposed
goal, symbolic analysis is used to evaluate the entire applicable range of all environmental
configurations and system variables referenced in the parent goal and its decomposed aggregate requirements. Unlike variable testing with a finite number of concrete instantiations
where instances of completeness counterexamples may be missed, all possibilities can be simultaneously analyzed symbolically. As shown in Expression (2.1), a requirement is satisfied
if its aggregate decomposed requirements are complete and satisfied over the domain properties and assumptions (Dom). For AND-decomposition, the following equation must be true
for complete decompositions:

(R1 ∧ ... ∧ Ri ∧ ... ∧ Rn ) ∧ Dom =⇒ R.

(3.1)

For OR-decomposition, the following equation must be true for complete decompositions:

(R1 ∨ ... ∨ Ri ∨ ... ∨ Rn ) ∧ Dom =⇒ R.

In

the

case

of

AND-

and

OR-decompositions,

the

(3.2)

set

of

requirements

(R1 , R2 , R3 , R... , Rn ) composed by the decomposition operator (OR or AND) implies
the parent requirement (R), assuming the domain properties and assumptions (Dom) hold.
When using utility functions to assess satisficement, Boolean logic is not sufficient due to
21

Table 3.2: ENV, MON, and REL Properties
Goal
A.1
A.2
A.3
A.4
A.5
A.6
A.7
A.8
A.9
A.10
A.11
A.12
A.13
A.14

ENV

A.15
A.16
A.17
A.18
A.19
A.20
A.21
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
B.9
B.10
B.11
B.12
B.13
B.14
B.15
B.16
B.17
B.18
B.19
C.1
C.2
C.3
C.4
C.5
C.6
C.7
C.8
C.9
C.10
C.11
C.12
C.13
D.1
D.2
D.3
D.4
D.5
D.6
D.7
D.8
D.9
D.10
Speed t
Speed t
Speed t+1
Distance

MON
Cruise Switch Sensor , Cruise Active Sensor
Cruise Switch Sensor , Cruise Active Sensor
Cruise Switch Sensor , Cruise Active Sensor
Cruise Switch Sensor , Cruise Active Sensor
Cruise Switch Sensor , Cruise Active Sensor
Cruise Switch Sensor
Cruise Active Sensor
Cruise Active Switch
Cruise Switch Sensor
Cruise Active Sensor
Cruise Switch Sensor
Cruise Active Sensor
Cruise Switch Sensor
Cruise Active Sensor
Throttle Pedal Sensor , Throttle Actuator ,
Brake Pedal Sensor , Brake Actuator
Throttle Pedal Sensor , Throttle Actuator
Brake Pedal Sensor , Brake Actuator
Throttle Pedal Sensor , Throttle Actuator

Speed t , Speed t+1 , Distance
Speed t , Speed t+1
Speed t , Speed t+1

Brake Pedal Sensor , Brake Actuator
Safe Distance

Throttle Actuator , Throttle Pedal Sensor
Throttle Actuator , Throttle Pedal Sensor

Speed t , Distance
Speed t
Distance

Throttle Pedal Sensor
Desired Speed , Safe Distance
Desired Speed
Safe Distance
Wheel Speed Sensor , Desired Speed
GPS Speed Sensor , Desired Speed
Distance Sensor 1 , Safe Distance
Distance Sensor 2 , Safe Distance
Brake Actuator , Brake Pedal Sensor
Brake Actuator , Brake Pedal Sensor
Throttle Pedal Sensor
Brake Pedal Sensor

Speed t , Speed t+1
Speed t , Distance
Speed t

Distance

Speed t , Speed t+1
Speed t , Distance
Speed t

Distance

Desired Speed , Safe Distance
Throttle Actuator , Throttle Pedal Sensor
Desired Speed
Throttle Actuator , Throttle Pedal Sensor
Wheel Speed Sensor , Desired Speed
GPS Speed Sensor , Desired Speed
Throttle Pedal Sensor
Safe Distance
Distance Sensor 1 , Safe Distance
Distance Sensor 2 , Safe Distance
Brake Actuator

Desired Speed , Safe Distance
Throttle Actuator , Throttle Pedal Sensor
Desired Speed
Wheel Speed Sensor , Desired Speed
GPS Speed Sensor , Desired Speed
Safe Distance
Distance Sensor 1 , Safe Distance
Distance Sensor 2 , Safe Distance
Wheel Speed Sensor , GPS Speed Sensor
Throttle Pedal Sensor , Brake Pedal Sensor
Throttle Actuator , Brake Actuator
Distance Sensor 1 , Distance Sensor 2

22

REL
true
Cruise Switch Sensor == Off ∧ Cruise Active Sensor == On
Cruise Switch Sensor == Off ∧ Cruise Active Sensor == Off
Cruise Switch Sensor == On ∧ Cruise Active Sensor == Off
Cruise Switch Sensor == On ∧ Cruise Active Sensor == On
Cruise Switch Sensor == Off
Cruise Active Sensor == On
Cruise Active Switch == Off
Cruise Switch Sensor == Off
Cruise Active Sensor == Off
Cruise Switch Sensor == On
Cruise Active Sensor == Off
Cruise Switch Sensor == On
Cruise Active Sensor == On
Throttle Pedal Sensor == Throttle Actuator ∧
Brake Pedal Sensor == Brake Actuator
Throttle Pedal Sensor == Throttle Actuator
Brake Pedal Sensor == Brake Actuator
true
Throttle Pedal Sensor == Throttle Actuator
true
Brake Pedal Sensor == Brake Actuator
Speed t >= Speed t+1 ∨ Distance < Safe Distance
Speed t > Speed t+1 ∨ (Speed t == MIN ∧ Speed t+1 == MIN )
Speed t > Speed t+1 ∨ (Speed t == MIN ∧ Speed t+1 == MIN )
Throttle Actuator < Throttle Pedal Sensor
Throttle Actuator < Throttle Pedal Sensor
true
Throttle Pedal Sensor > 0
Speed t > Desired Speed ∨ Distance < Safe Distance
Speed t > Desired Speed
Distance < Safe Distance
Wheel Speed Sensor > Desired Speed
GPS Speed Sensor > Desired Speed
Distance Sensor 1 < Safe Distance
Distance Sensor 2 < Safe Distance
Brake Actuator > Brake Pedal Sensor
Brake Actuator > Brake Pedal Sensor
true
Throttle Pedal Sensor == M IN
Brake Pedal Sensor < M AX
Speed t < Speed t+1
Speed t < Desired Speed ∧ Distance > Safe Distance
Throttle Actuator > Throttle Pedal Sensor
Speed t < Desired Speed
Throttle Actuator > Throttle Pedal Sensor
Wheel Speed Sensor < Desired Speed
GPS Speed Sensor < Desired Speed
Throttle Pedal Sensor < MAX
Distance > Safe Distance
Distance Sensor 1 > Safe Distance
Distance Sensor 2 > Safe Distance
Brake Actuator == MIN
true
Speed t == Speed t+1
Speed t == Desired Speed ∧ Distance > Safe Distance
Throttle Actuator == Throttle Pedal Sensor
Speed t == Desired Speed
true
Wheel Speed Sensor == Desired Speed
GPS Speed Sensor == Desired Speed
Distance > Safe Distance
Distance Sensor 1 > Safe Distance
Distance Sensor 2 > Safe Distance
Wheel Speed Sensor ∨ GPS Speed Sensor
max (MIN , Throttle Pedal Sensor − Brake Pedal Sensor )
max (MIN , Throttle Actuator − Brake Actuator )
Distance Sensor 1 ∨ Distance Sensor 2

Table 3.3: Units and Scaling for Variables in Table 3.2
Variable
Speed t
Speed t+1
Distance
Desired Speed
Safe Distance
Throttle Actuator
Throttle Pedal Sensor
Brake Actuator
Brake Pedal Sensor
Distance Sensor 1
Distance Sensor 2
Wheel Speed Sensor
GPS Speed Sensor
Cruise Switch Sensor
Cruise Active Sensor
Cruise Active Switch

Min
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
Off
Off
Off

Max
100.0
100.0
50.0
100.0
50.0
100.0
100.0
100.0
100.0
50.0
50.0
100.0
100.0
On
On
On

Unit
MPH
MPH
Feet
MPH
Feet
%
%
%
%
Feet
Feet
MPH
MPH
Boolean
Boolean
Boolean

the real-valued results. Therefore, the minimum satisficement of the decomposed goals is
used for AND-decomposition and maximum satisficement of the decomposed goals is used
for OR-decomposition [75]. The measure of decompositional completeness for assessing
satisficement for Expression (3.1) (i.e., AND decomposition) is captured in Expression (3.3):

min(Satisficement(R1 ),

(3.3)

...,
Satisficement(Ri ),
...,
Satisficement(Rn )) =⇒ Satisficement(R),

where the Satisficement function is the corresponding utility function (i.e., measure of the
range of satisfaction from unsatisfied at 0.0 to satisfied at 1.0) for the respective requirement parameter. For example, Satisficement(B.2) is the REL expression from row B.2 in
Table 3.2. Similarly, the measure of decompositional completeness for assessing satisficement
23

for Expression (3.2) (i.e., OR decomposition) is captured in Expression (3.4):

max (Satisficement(R1 ),

(3.4)

...,
Satisficement(Ri ),
...,
Satisficement(Rn )) =⇒ Satisficement(R)

In both Expressions (3.3) and (3.4), the utility functions (i.e., Satisficement) encode
the applicable domain properties and assumptions (Dom) via the ENV, MON, and REL
properties as specified in Table 3.2. Specifically, the REL properties are used to describe the
degree of satisficement that the utility function returns as either state- or metric-logic based
satisficement results, that is, Boolean or real-value, respectively.
The remainder of this section describes the Ares process for detecting incomplete requirements decompositions by finding counterexamples to Expressions (3.3) and (3.4).

3.3.1

Ares Process

Figure 3.2 overviews the Ares process in a Data Flow Diagram (DFD). The circles
represent processing elements. The parallel horizontal bars represent persistent data. The
labeled arrows represent data flows. The boxes represent external entities. Ares makes use
of Athena [75] to generate utility functions from a goal model (e.g., Figure 3.1) and ENV,
MON, and REL properties (e.g., Table 3.2). Step 1 of Figure 3.2 accepts a goal model and
the Athena-derived utility functions to produce a set of satisficement functions based on the
defined relationships for all the hierarchically decomposed requirements. Step 2 applies the
symbolic analysis to the satisficement expressions to identify decomposition counterexamples.
24

Revised
s
Propertie

System
Designer

ENV, MON, REL
Properties

Revised
Goal M
odel

Prope

rties

Generate
Utility Functions
via Athena

Goals

KAOS
Goal Model

Utility
Functions

De
co
mp

Incomplete
Decompositions

itio
pe
nO

Counterexample

Utility Functions

os

Optimizing
SMT Solver

Expressions

ra

Logical Expressions

s

(2)
Process Logical
Expressions &
Summarize

tor

Logical
Expressions

(1)
Generate
Detection
Logic

Process Key:
Process
Flow
External I/O
Persistent Data

Figure 3.2: Ares Data Flow Diagram
DFD Step 1: Generate Detection Logic
Ares uses the expressions generated by Athena, as well as the decomposition operators
(either AND or OR) to build an expression that measures the numerical difference in the
satisficement of a requirement and its decomposed requirements. Any requirement that does
not measure satisficement, but only discrete satisfaction (i.e., satisfied or not-satisfied) is
mapped to a satisficement of 1.0 for ‘satisfied’ and 0.0 for ‘not satisfied.’ The aggregate
decomposed requirements use the respective decomposition operator to define their collective
satisficement. For example, the satisficement of any requirement can be measured via its
utility function, therefore the satisficement of B.4 is measured by Expression (3.5) based on
the REL property specified by the requirements engineer in Table 3.2 and taken from the
25

generated utility function.

Satisficement(B.4) =Throttle Actuator <

(3.5)

Throttle Pedal Sensor

The satisficement of a set of aggregate decomposed goals is dependent on the decomposition operator, where OR-decomposed requirements are satisficed, as a group, at the
maximum any individual requirement is satisficed (i.e., the antecedent of the implication in
Expression (3.4)). For example, the requirements OR-decomposed from B.8 are:

Satisficement Decomp (B.8) = max (Satisficement(B.9),

(3.6)

Satisficement(B.10)).

In contrast, requirements decomposed via an AND operator are satisficed as a group at
the minimum that any individual requirement is satisficed (i.e., the antecedent of the implication in Expression (3.3)). For example, the satisficement of requirements AND-decomposed
from B.4 are:

Satisficement Decomp (B.4) = min(Satisficement(B.5),

(3.7)

Satisficement(B.6),
Satisficement(B.7)).

In order to detect completeness decomposition errors, a counterexample must be found
where the satisficement of the aggregate decomposed requirements do not imply the satisficement of the parent requirement. For example, analysis of Expression (3.8) is used to
determine if goal B.4 has a completeness counterexample.

Counterexample B.4 = ¬(Satisficement Decomp (B.4) =⇒ Satisficement(B.4)).

26

(3.8)

Since satisficement of the goals is measured in terms of a real value in the range of 0.0
to 1.0, maximizing the difference between the decomposed requirements satisficement and
the parent requirement satisficement identifies the most significant (e.g., largest difference
between decomposed and parent satisficement) completeness counterexample (in case there
is more than one completeness counterexample for a given decomposed goal). For example,
maximizing Expression (3.9) identifies the most significant completeness counterexample for
the decomposition of B.4:

Counterexample B.4 = Satisficement Decomp (B.4) − Satisficement(B.4).

(3.9)

Identifying the maximum of Expression (3.9) yields counterexamples to Expressions
(3.3) and (3.4), where the parent requirement, B.4 is satisfied while the decomposed requirements are not.
For all decomposed goals, the corresponding difference expressions (e.g., Expression
(3.9) for B.4) are encoded in SMT version 2 [12], along with additional optimization
commands (e.g., maximize) [14, 15] that maximize a designated expression (e.g., Expression
(3.9) for B.4). The encoded expressions along with the decomposition operator are output
to Step 2 in Figure 3.2.

DFD Step 2: Process Logical Expressions & Summarize
The expressions generated from Step 1 are processed, along with the decomposition
operator from the goal model, to generate the following values for each decomposition:
• Measures of satisficement for individual requirements using utility functions (e.g., Expression (3.5)),
• Measures of satisficement for requirements based on their decomposed requirement’s
utility functions (e.g., Expressions (3.6) and (3.7)), and
27

• Measures of the maximum numerical difference between the satisficement of a requirement and its aggregate decomposed requirements (e.g., Expression (3.9)).
Each counterexample provides the previously generated values for the decomposition along
with the concrete values for environmental and system variables specific to the counterexample.
Each expression that is analyzed represents a single requirement and its aggregate decomposed requirements. To analyze the entire goal model, each decomposed requirement
must be analyzed for completeness.
Counterexamples representing the maximum satisficement differences are summarized
and can be used by the system designer to update the requirements model and/or ENV,
MON, and REL properties. Possibly unreachable, but also unguarded, scenarios that indicate incomplete decomposition will be detected. Specific requirement guards (e.g., expectations) should be used to address the incomplete decomposition counterexample, due to
possible changes in reachability throughout the life of the system. For example, the limitations of a vehicle engine may bound the acceleration such that an incomplete decomposition
related to high acceleration is unreachable (i.e., impossible). However, if the car is modified,
then the incomplete decomposition may become reachable.
Incomplete requirements may arise due to a variety of causes, including missing or
superfluous requirements for either all environmental configurations or a subset of possible
environmental configurations. Alternatively, the parent or decomposed requirements may
simply be incorrect. Revising the goal model for each of these causes may require additional
levels of decomposition to allow for alternate requirement choices for subsets of cases, the
addition or removal of requirements, or correcting individual requirements.

3.3.2

Scalability and Limitations

Detection of incomplete requirements decomposition relies on the assumption that individual requirements are correctly measured for satisficement by the respective utility func28

tions. Without such an assumption, no decompositions, including complete decompositions,
could be reasoned about due to possible measurement errors. The generation of utility functions requires ENV, MON, and REL properties for each requirement, thereby increasing
the volume of information required by Ares. Increases in data or information required is an
issue shared by techniques that focus on the relationship of requirements models and the
environment [1, 64]. However, in cases where utility functions already exist (e.g., for run-time
monitoring) there is no additional information overhead.
Ares processes each decomposition individually, therefore the computational cost of
analyzing a goal model grows linearly with respect to the number of decompositions in
the context of the worst-case single decomposition. Given that individual decompositions
are typically small (e.g., not more than a dozen), Ares can provide scalable analysis, even
for large requirements specifications (e.g., tens of thousands to hundreds of thousands of
requirements). The execution time of the case study detailed in Section 3.4 is less than 3
seconds for each decomposition analysis on a 1.3 GHz Intel Core i5 processor with 4 GB of
1600 MHz DDR3 RAM.

3.4

Symbolic Analysis Case Study

This section describes the case study results of applying Ares to the ACC system in
Figure 3.1, referred to as goal model M .

3.4.1

Incomplete AND Decomposition: Goal D.1

The ACC system defined in Figure 3.1 identifies numerous decomposed requirements.
We start by describing the Ares processes for a single decomposed requirement, D.1. The
decomposition of D.1 is shown in its entirety in Figure 3.3. The goal D.1 in goal model
M is intended to specify requirements for the ACC system to maintain the current speed
by controlling the accelerator. The decomposition requires all three of its decomposed re29

quirements to be satisfied (i.e., D.2, D.3, and D.5). First, in goal D.2, the environmental expectations must be met. The current speed (Speed t ) must match the desired speed
(Desired Speed ) set in the ACC and there must be sufficient distance to maintain the current
speed safely (Distance > Safe Distance)3 . Second, in goal D.3, the current throttle position
(Throttle Pedal Sensor ) is maintained in the expressed throttle position (Throttle Actuator ).
Third, in goal D.5, the current throttle position is read from the responsible agent (i.e., the
Throttle Pedal Sensor ).
...

D.1
M(Speed)

D.3

D.2

A(Throttle Actuator =
Throttle Pedal Sensor)

Speed = Desired Speed AND
Distance > Safe Distance
...

5

D.5

A(Throttle Pedal Sensor Reading)
4

Figure 3.3: Example AND Decomposition in Goal Model M

1-M ) Generate Detection Logic for Model M
We start by maximizing a version of Expression (3.9), instantiated for D.1:

Counterexample D.1 = Satisficement Decomp (D.1) − Satisficement(D.1).

(3.10)

Expanding Satisficement Decomp via Expression (3.7) (i.e., the expression that defines the
satisfaction of a combination of child goals) for D.1 yields the following expression, where
3

While optimization typically requires an epsilon to be defined for less-than or greater-than, the optimization methods used in this dissertation do not require an explicitly defined epsilon.

30

the child goals of D.1 are D.2, D.5, and D.3:

Counterexample D.1 = min(Satisficement(D.2),

(3.11)

Satisficement(D.5),
Satisficement(D.3)) − Satisficement(D.1).

Employing the utility functions defined in Table 3.2, where true is mapped to 1.0 and
false is mapped to 0.0, Expression (3.12) is generated where the parent requirement is subtracted from the minimum (i.e., equivalent to an AND operation) of the decomposed requirements.

Counterexample D.1 = min(Speed t == Desired Speed ∧

(3.12)

Distance > Safe Distance,
true,
Throttle Actuator == Throttle Pedal Sensor )−
Speed t == Speed t+1

2-M ) Process Logical Expressions & Summarize
The completeness counterexample expression (Expression (3.12)) is maximized, while
ensuring the domain properties and assumptions (i.e., Speed t , Speed t+1 , and Distance) in
Table 3.2 are maintained, resulting in a maximized value of 1.0 (i.e., true). This result
indicates the existence of a completeness counterexample. The counterexample provides the
specific environmental configuration of variables, in both the normalized (from 0.0 to 1.0)
values symbolically analyzed and their real world values (see Table 3.4). The counterexample
indicates that while goal D.1 is unsatisfied, and therefore the current speed (Speed t ) is not
maintained, all of the decomposed goals are satisfied. Therefore, it is not sufficient to maintain
speed via the throttle. The utility function for goal D.1, Speed t == Speed t+1 , indicates
31

that the current and next speed values will not be the same. The domain properties and
assumptions of the environment for both Speed t and Speed t+1 , as documented in Table 3.2,
depend on the throttle and brake. This finding is reasonable, as we would expect the speed
of a vehicle to be impacted by the application of the brake. Clearly, the decomposition of
goal D.1 must include braking control.

Table 3.4: Counterexample Variables for D.1 in Goal Model M
Variable or
Requirement
Speed t
Speed t+1
Distance
Desired Speed
Safe Distance
Throttle Actuator
Throttle Pedal Sensor
Brake Actuator
Brake Pedal Sensor
Goal D.1
Goal D.2
Goal D.3
Goal D.5

Normalized
Value
0.5
0.0
0.5
0.5
0.0
0.5
0.5
0.75
0.0
0.0
1.0
1.0
1.0

Value
50.0 MPH
0.0 MPH
25.0 Feet
50.0 MPH
0.0 Feet
50.0%
50.0%
75.0%
0.0%
Unsatisfied
Satisfied
Satisfied
Satisfied

Following the example of goals D.3, and D.5, two additional requirements are added
to the decomposition in revised goal model M 0 for brake control. The partial goal model
in Figure 3.4 shows the updated portion of goal model M 0 where requirements D.New1 and
D.New2 are newly added to the decomposition of goal D.1. The new goals, D.New1 and
D.New2, set the Brake Actuator to the current pedal position and read the current pedal
position, respectively.
32

...

D.1
M(Speed)

D.3

D.2

A(Throttle Actuator =
Throttle Pedal Sensor)

Speed = Desired Speed AND
Distance > Safe Distance
...
A(Brake Actuator =
Brake Pedal Sensor)
7

5

D.5

D.New1

A(Throttle Pedal Sensor Reading)
4

D.New2
A(Brake Pedal Sensor Reading)
6

Figure 3.4: Revised AND Decomposition in Goal Model M 0
1-M 0 ) Generate Detection Logic for Model M 0
The associated utility functions for these new requirements model M 0 are:

Satisficement(D.New1) = Brake Actuator == Brake Pedal Sensor

(3.13)

Satisficement(D.New2) = true,

(3.14)

where Satisficement(D.New1) includes two MON properties: Brake Actuator

and

Brake Pedal Sensor . Goal D.New2 includes no properties, only requires a sensor reading.
Inserting these additional utility functions (Expressions (3.13) and (3.14)) to those defined in Table 3.2, results in the following completeness counterexample detection expression:

Counterexample D.1 = min(Speed t == Desired Speed ∧
Distance > Safe Distance, true,
Throttle Actuator == Throttle Pedal Sensor ,
Brake Actuator == Brake Pedal Sensor ,
true) − Speed t == Speed t+1 .

33

(3.15)

2-M 0 ) Process Logical Expressions & Summarize

Maximizing Expression (3.15) for goal D.1 in goal model M 0 , while ensuring the domain
properties and assumptions (i.e., Speed t , Speed t+1 , and Distance) in Table 3.2 are maintained,
results in a maximized value of 0.0 (i.e., false). This result indicates that no completeness
counterexample exists in the updated M 0 goal model for decomposition from D.1.

3.4.2

Incomplete OR Decomposition: Goal B.3

In this section, we describe the Ares process for a single decomposed requirement, B.3,
in goal model M 0 . The decomposition of goal B.3 is shown in Figure 3.5. The goal B.3 is
intended to specify requirements allowing the ACC system to reduce the current speed by
controlling both the accelerator and brake. The decomposition requires either of its decomposed requirements to be satisfied. First, in goal B.4, the throttle (Throttle Actuator ) must
be reduced. Second, in goal B.15, the brake (Brake Actuator ) must be increased. Either one
of these, or both, is intended to be sufficient to lower the speed of the vehicle unless the
speed (Speed t ) is already zero.

...

B.3
A(Slow Car)

B.4

B.15

A(Reduce Throttle)

A(Increase Brake)

...

...

Figure 3.5: Example OR Decomposition in Goal Model M 0

34

1-M 0 ) Generate Detection Logic for Model M 0
In order to detect a completeness counterexample, we maximize an expression similar
to Expression (3.9), but instantiated for B.3:

Counterexample B.3 = Satisficement Decomp (B.3) − Satisficement(B.3).

(3.16)

Expanding Expression (3.16) via Expression (3.7) and the decomposition specific for
goal B.3 results in:

Counterexample B.3 = max (Satisficement(B.4),

(3.17)

Satisficement(B.15)) − Satisficement(B.3).

Using the corresponding utility functions defined in Table 3.2 yields the following incompleteness detection expression:

Counterexample B.3 = min(Throttle Actuator < Throttle Pedal Sensor ,

(3.18)

Brake Actuator > Brake Pedal Sensor )−
(Speed t > Speed t+1 ∨
(Speed t == MIN ∧ Speed t+1 == MIN )).

2-M 0 ) Process Logical Expressions & Summarize
Maximizing the completeness counterexample Expression (3.18), while ensuring the domain properties and assumptions (e.g., Speed t , and Speed t+1 ) in Table 3.2 are maintained,
results in a maximized value of 1.0. This result indicates the existence of a completeness
counterexample. The counterexample provides the specific environmental configuration of
variables defined in Table 3.5, in both the normalized (from 0.0 to 1.0) values symbolically
analyzed and their real world values. The counterexample indicates that goal B.3 is unsat35

isfied, and therefore the current speed (Speed t ) does not decrease even when at least one of
the decomposed goals is satisfied (i.e., B.4). Therefore, the decomposition is not sufficient
to decrease speed. While either decomposed goal would be sufficient to slow the car if there
were no other changes, when goal B.4 decreases the throttle by a fractional amount (in this
case 50.0% of the available throttle) the brake can also be reduced by a comparable amount,
causing a neutral impact to the vehicle speed.

Table 3.5: Counterexample Variables for B.3 in Goal Model M 0
Variable or
Requirement
Speed t
Speed t+1
Throttle Actuator
Throttle Pedal Sensor
Brake Actuator
Brake Pedal Sensor
Goal B.3
Goal B.4
Goal B.15

Normalized
Value
0.5
0.5
0.5
1.0
0.0
0.5
0.0
1.0
0.0

Value
50.0 MPH
50.0 MPH
50.0%
100.0%
0.0%
50.0%
Unsatisfied
Satisfied
Unsatisfied

In order for the decomposition of goal B.3 to be complete, there must be a requirement
that ensures the satisfaction of one decomposed goal is not negatively impacted by another
decomposed goal. Many specifications would be sufficient and could be represented via additional requirements, including adjusting the throttle and brake proportionally to one another.
However, one of the most straightforward possible solutions is to change the decomposition
operator from OR to AND. If both decomposed goals are required to contribute to slowing
the car, then neither goal can negatively impact the other. Figure 3.6 shows the portion of
the updated goal model, M 00 , where the decomposition of goal B.3 has been revised from an
OR-decomposition to an AND-decomposition.
36

...

B.3
A(Slow Car)

B.4

B.15

A(Reduce Throttle)

A(Increase Brake)

...

...

Figure 3.6: Revised OR Decomposition in Goal Model M 00
1-M 00 ) Generate Detection Logic for Model M 00
While the utility functions do not change, the decomposition operator does. Expression (3.17) is updated to use the minimum of the decomposed requirements (i.e., AND)
instead of the maximum (i.e., OR) in the following equation:

Counterexample B.3 = min(Satisficement(B.4),

(3.19)

Satisficement(B.15)) − Satisficement(B.3).

Using the corresponding utility functions defined in Table 3.2 yields the following incompleteness detection expression:

Counterexample B.3 = min(Throttle Actuator < Throttle Pedal Sensor ,

(3.20)

Brake Actuator > Brake Pedal Sensor )−
(Speed t > Speed t+1 ∨
(Speed t == MIN ∧ Speed t+1 == MIN )).
2-M 00 ) Process Logical Expressions & Summarize
Maximizing the updated completeness counterexample expression (i.e., the entire Expression (3.20), where the minimum satisficement of any of the decomposed requirements is
used, rather than the maximum satisficement of any of the decomposed requirements) for
37

goal B.3 in goal model M 00 , while ensuring the domain properties and assumptions (e.g.,
Speed t , and Speed t+1 ) in Table 3.2 are maintained, results in a maximized value of 0.0 (i.e.,
false). This indicates that no completeness counterexample exists in the updated M 00 goal
model for B.3.

3.4.3

Discussion

The application of Ares to each of the decompositions in goal model M identifies two
incomplete decompositions: an AND decomposition from goal D.1, and an OR decomposition from B.3. Both of these incompleteness causes are requirements specification errors
that would be difficult to detect with either manual analysis or testing techniques due to
the unexpected simultaneous use of brake and throttle. Neither incomplete decomposition
was artificially inserted, instead they were unexpected artifacts that remained even after
review by automotive industrial collaborators. The first incomplete decomposition, goal D.1,
required additional requirements (D.New1, and D.New2). The revised goal model, M 0 , still
contained an incomplete decomposition for goal B.3. This final incompleteness problem was
addressed by changing the decomposition operator of B.3 from OR to AND to obtain the
final goal model M 00 , which contained no further incomplete requirements decompositions.

3.4.4

Threats to Validity

Ares depends on the accuracy of the utility functions provided by Athena [75]. However,
these utility functions are not guaranteed to be correct. The accuracy of the completeness
counterexample detection is bounded by the accuracy of the utility functions and the related
domain properties and assumptions.
38

3.5

Symbolic Analysis Related Work

While a number of projects have dealt with partial specifications and uncertainty about
the requirements (e.g., [85, 93]), this work focuses on automatically detecting incomplete
requirements in the context of requirements decomposition (i.e., requirements refinement).
Several different strategies have been developed to address requirements incompleteness with
respect to decomposition. We overview these techniques and compare them to the Ares
approach.
A search-based technique for the generation of obstacles [2] has been used to create
counterexamples to completeness, where the incompleteness is detected with respect to the
domain properties. However, this process requires manual review of the obstacles generated
to ensure their relevance and applicability. Ares automatically generates counterexamples
that are guaranteed to indicate incomplete requirement decomposition based on the artifacts
provided, and does so within the context of the decomposed requirement rather than the
entire domain.
Methods with formal guarantees exist, including analysis of behavioral state-based systems [56] and the application of theorem provers to formally described requirements [87].
However, methods that employ formal proofs are heavyweight solutions that require expertise with theorem proving to describe requirements [87] or low-level functional details [56].
Ares supports the use of hierarchical requirements modeling, supplemented by specifications
of environmental conditions, described in terms of simple scalar and Boolean expressions
involving application variables.
Formal decomposition of requirements that guarantees completeness with respect to
decomposition [31] is limited to defined decomposition strategies and requires a high degree
of formality. It is possible to add completeness criteria to formal specification languages,
though not all criteria can be enforced via language semantics [67], thus potentially allowing
incomplete requirements. Ares is not limited to specific decompositions or language semantics
but supports unrestricted decomposition patterns and requirement descriptions.
39

Process rigor [98] and analysis of natural language requirements [46, 69] have both been
used to lower the likelihood of incomplete requirements, but are unable to provide guaranteed
detection or avoidance of incomplete requirements.
Ares is unique as it applies symbolic analysis to automatically-generated utility functions
to detect incomplete decompositions. By using symbolic analysis of application and domain
specific properties provided by domain experts at design-time, Ares supports full analysis of
the hierarchical requirements models.

3.6

Summary

In this chapter, we have presented Ares, a design-time approach for detecting incomplete requirements decomposition using symbolic analysis of hierarchical requirements models. Unlike previous incomplete requirements detection methods, Ares detects incomplete
requirements decompositions while not limiting the allowable decomposition strategies.
We demonstrate Ares on an adaptive cruise control system developed in collaboration
with our automotive industrial collaborators. We show that Ares is able to automatically
detect incomplete requirements decompositions and provide completeness counterexamples
in seconds.

40

Chapter 4
Detecting Incomplete Requirements:
Using Evolutionary Computation
While we previously developed a technique to detect incomplete requirements decomposition with respect to a given environmental scenario, a single completeness counterexample
may not clearly indicate the extent that incomplete requirements impacts the system or what
range of environmental scenarios are affected. This chapter introduces Ares-EC, a designtime approach for detecting incomplete requirements decomposition using a combination of
evolutionary computation and symbolic analysis of hierarchical requirements models to detect a set of representative incompleteness counterexamples. We again illustrate our approach
by applying Ares-EC to the requirements model of an industry-based automotive adaptive
cruise control system. Ares-EC is able to apply symbolic analysis and evolutionary computation to automatically detect multiple, diverse, and representative sets of requirements
incompleteness counterexamples at design time.

4.1

Introduction

Even when requirements incompleteness is automatically identified, a single counterexample may not be not sufficient. Just as it is not sufficient for a system designer to correct a
41

single environmental scenario impacted by incompleteness, neither is it sufficient to simply
indicate that requirements are incomplete. Instead, the range of environmental scenarios impacted by incomplete requirements decomposition should be identified in order to facilitate
the task of revising the requirements. For example, a requirement for a vehicle may be to stop.
In an idealized system, applying brake force (e.g., from hydraulic brakes) would be sufficient.
Applying the brakes may be insufficient if the throttle can overwhelm the braking force, thus
indicating that the decomposition is incomplete. However, that single counterexample is not
representative of the range of operational scenarios that are impacted by incompleteness. For
example, in inclement weather, brake force may not be sufficient without anti-lock brakes.
Not only is enumerating all necessary decomposed requirements difficult, it is also challenging
to identify the range of impacted scenarios to assess necessary additional requirements.
This chapter describes Ares-EC, an approach that combines symbolic analysis and evolutionary computation to automatically identify sets of representative environmental configurations where completeness properties are violated in a hierarchical requirements model.
Hierarchical requirements satisfaction can be assessed in two ways: its individual satisfaction
or the satisfaction of a requirement’s aggregate decomposed requirements (i.e., children or
sub-requirements). Given complete decomposition, a requirement should be satisfied whenever its aggregate decomposed requirements are satisfied [37]. Ares-EC uses symbolic analysis
to identify individual counterexamples and uses evolutionary computation to search for sets
of diverse representations of counterexamples based on the previously identified counterexamples. By employing symbolic analysis, Ares-EC can guarantee that a single counterexample will be found, if one exists. Evolutionary computation, on the other hand, can identify
multiple diverse counterexamples in parallel. Ares-EC identifies incomplete decompositions
in the form of sets of representative environmental scenarios, or counterexamples, within a
valid range of values for the variables in the system in which the incompleteness is expressed.
Counterexamples are then summarized for the system designer to revise the requirements
accordingly.
42

Ares-EC applies utility functions [75] to assess individual requirements for completeness
within a hierarchical requirements model. Expressions representing completeness counterexamples used in both symbolic and evolutionary computation are defined in terms of these
utility functions. While utility functions have been used to measure run-time satisfaction of
requirements [50, 75], Ares-EC analyzes the utility functions (via expressions representing
incompleteness) at design time. For each requirement’s decomposition, Ares-EC identifies
a representative set of counterexamples from the range of possible requirement variables’
values. Counterexamples are identified as environmental conditions that cause a requirement to be unsatisfied while its aggregate decomposed requirements are satisfied. Sets of
counterexamples are identified for an industry-based requirements model for an automotive
application, and the incomplete requirements decompositions along with their representative
set of counterexamples are summarized for the system designer.
The contributions of this chapter are as follows:
• We introduce a design-time, symbolic analysis and evolutionary computation approach
to automatically detect diverse and representative sets of completeness counterexamples in hierarchical requirements models.
• We present a prototype implementation of the Ares-EC approach.
• We demonstrate the applicability of Ares-EC on an industry-based automotive example, an adaptive cruise control system.
The remainder of this chapter is organized into the following sections. Section 4.2 details
the Ares-EC approach. Section 4.3 describes the results of a case study, and Section 4.4 details
related work. Finally, Section 4.5 summarizes the work.

4.2

Evolutionary Computation Approach

Ares-EC is an automated method for identifying sets of completeness counterexamples
43

in a hierarchical requirements model. A requirement is considered to be incompletely decomposed if there exists a case such that a parent requirement is unsatisfied while the set of its
decomposed requirements are satisfied [37].
The Ares-EC process, as shown in Figure 4.1, generates detection logic using utility
functions and the decompositions in a hierarchical goal model. These logical expressions are
then processed by a search based method to identify solutions that represent completeness
counterexamples. Next, we detail the Ares-EC approach and provide a comparison of four
search methods that were considered before determining which approach to finally use.

System
Designer

Incomplete
Decompositions

Revised
s
Propertie
Revised
Goal M
odel

ENV, MON, REL
Properties
Hierarchical
Goal Model

rties

Goals
De

Satisfiability
Results

(2)
Search for
Counterexamples
& Summarize

Prope

Optimizing
SMT Solver

co
Op mpo
era siti
tor on
s

SMT2
Expressions
Logical Expressions
Process Key:
External I/O

Process
Flow

Generate
Utility Functions
via Athena
Utility
Functions

Utility Functions
Expressions

(1)
Generate
Detection
Logic

Persistent Data

Figure 4.1: Ares-EC Data Flow Diagram

4.2.1

Step 1: Generate Detection Logic

Ares-EC makes use of utility functions generated by Athena [75], just as Ares does.
A completeness counterexample is an unsatisfied parent requirement with a set of satisfied
decomposed requirements [37] indicating there are additional child requirements necessary
to satisfy the parent requirement. For example, D.1 is incompletely decomposed if it is not
satisfied according to its utility function value, but the set of its decomposed requirements
(i.e., D.2, D.5, and D.3) is satisfied (i.e., the minimum of an AND-decomposition) as shown
44

in Equation (4.1).

Counterexample D.1 = min(Satisficement(D.2),

(4.1)

Satisficement(D.5),
Satisficement(D.3)) − Satisficement(D.1).

Each of the requirements referenced in Equation (4.1) may either be satisfied (i.e., 1.0)
or unsatisfied (i.e., 0.0) based on their utility function. By instantiating the satisficement
expressions in Equation (4.1) with their respective utility values (from Table 3.2), we obtain
the expression in Equation (4.2).

Counterexample D.1 = min(Speed t == Desired Speed ∧

(4.2)

Distance > Safe Distance,
true,
Throttle Actuator == Throttle Pedal Sensor )−
Speed t == Speed t+1

Similarly, OR-decomposed requirements such as B.3 use the maximum of the decomposed
requirements, as shown in Equation (4.3).

Counterexample B.3 = max (Satisficement(B.4),

(4.3)

Satisficement(B.15)) − Satisficement(B.3).

A similar expression is generated for every requirement that is decomposed. Identifying an
optimum (i.e., a return value of 1.0) for a completeness counterexample expression indicates
a counterexample exists.

45

4.2.2

Step 2: Search for Counterexamples and Summarize

In this work, we compare four methods to identify which provides the largest range
of multiple counterexamples. Previously, symbolic analysis has been used to identify single
counterexamples of incomplete requirements decomposition [37]. In contrast, here we apply
evolutionary computation to search for a range of distributed counterexamples. Since we
know that evolutionary computation is not guaranteed to find a solution, especially in ‘needle
in a haystack’ cases, we supplement our evolutionary approach with initial optimal results
from our symbolic approach. Finally, we periodically use our symbolic approach to re-seed
the evolutionary population as a means to overcome additional ‘needle in a haystack’ cases.
For simplicity, we configure the parameters for evolutionary computation based on empirical feedback with an emphasis on optimal results and execution time. All instances of
evolutionary computation used in this work make use of 200 individuals in the population, a
tournament size of 8 is used for mating selection, a tournament of size 4 is used for survival
selection, and a mutation rate of 5%. Executions have been limited to 2000 generations and
execution is on the order of seconds. Mating selection is performed by an eight-way tournament based on the novelty of individuals within a set of randomly-selected individuals.
Crossover for mating is performed by the SBX crossover operator [35] for each real-valued
variable (i.e., variable in the completeness counterexample expressions) in the individuals
selected. Mutation is performed on five percent of the individuals by randomly modifying a
single real-value representing a variable in the genome. Survival via a four-way tournament
is used to maintain population size and is based on fitness as measured by the satisfaction of
the completeness counterexample expression and is elite preserving as no member of the population will be replaced with a less optimal member. Tournaments of this size were selected
in an effort to increase the likelihood that an optimal value takes part in the tournament.
The genetic algorithm emphasizes search diversity via the mating selection and mutation
operators (5% chance of mutation), while survival selection optimizes the results of the
diverse search. The optimal is a population where each individual is at an optimum and
46

each individual is as far as possible from the other individuals based on the Manhattan
distance [28] of the genotype. The genetic evolution described here differs from other genetic
algorithms that search for a single optimal individual, since we are looking for a collection
of diverse solutions.

Symbolic Analysis Only:
For each requirement, a utility function is used to represent the satisfaction of the requirement based on a set of environmental and system variables that make up the utility
function. The parent requirement is symbolically compared to the combined derived requirements, via the completeness counterexample expressions. Detecting a single completeness counterexample is identified via symbolic analysis of the completeness counterexample
expressions (e.g., Equation (4.1) or (4.3)) using existing techniques [37]. We include this
technique here as a means to establish existence of at least one counterexample and for comparison to the other search-based techniques. Specifically, symbolic analysis, via Microsoft’s
SMT solver Z3 [32], is used to evaluate the entire range of applicable environmental configurations and system variables used in the completeness counterexample expressions for each
decomposed requirement.
In cases where the completeness counterexample expression cannot be satisfied, then no
counterexample exists and the requirement is thus complete, thereby alleviating the need to
perform additional analysis.

Evolutionary Computation Only:
EC-only employs evolutionary computation in the form of a genetic algorithm to search
for both novel and optimal results. Instead of searching for a single optimal solution to a
counterexample expression, EC-only searches for multiple solutions with optimal phenotype
responses (e.g., requirements with utility function values that indicate an incomplete decomposition) and maximized genotype novelty (e.g., a large difference in the environmental
47

scenario upon which the requirements are applied). The expected results are a population of
optimal individuals (i.e., individuals that represent counterexample) distributed across the
range of the genotype. The genome is an array of real-valued variables, one for each variable
that exists in the completeness counterexample expression.

Symbolic Analysis, then Evolutionary Computation:
While evolutionary computation alone can provide a method of searching with an emphasis on diversity, two issues can occur:
• First, the so called ‘needle in a haystack’ problem may make finding the optimum
solution significantly unlikely to be found.
• Second, expressions without a gradient between satisfied and unsatisfied are likely to
take more time to find the optimum, and perhaps degenerate to random search, since
the requirements satisfaction is used to calculate the fitness function.
EC-SA alleviates these two problems by utilizing symbolic analysis to identify a single
optimum, which is used to seed a portion (10%, or 20 of the 200 individuals) of the initial
population. Given an initial optimum, the diverse search is intended to identify a distributed
set of optimum values.

Periodic Evolutionary Computation with Symbolic Analysis:
Symbolic analysis may provide a starting point for evolutionary computation, yet despite
the guarantee of optimal individuals in the initial population, two issues can still occur:
• First, while the ‘needle in a haystack’ problem is alleviated for a single optimum,
additional optima may also be similarly unlikely to be found.
• Second, a change in one variable may require a change in another variable in a single
individual to identify another optimum, resulting in additional search time.
48

PSAEC overcomes these problems by periodically re-analyzing the completeness counterexample expression symbolically, with an added constraint to maximize the distance from
a selection of existing individuals in the population. If another optimum is found then that
individual is added to the population. We allow PSAEC to select up to 10 random individuals in the population to create a distance constraint from each of them during the first half of
the generations. If a new and diverse counterexample is found, then 20 random individuals
are replaced with the new counterexample.

4.2.3

Scalability and Limitations

Ares-EC is not guaranteed to identify all completeness counterexamples, even when
using evolutionary computation with periodic symbolic analysis. For example, given a set
of ‘needles in a haystack,’ two ‘needles’ that are close in genotype distance (e.g., when the
throttle is at 72% and 74%, but not at 73%) may cause one to be ignored in favor of counterexamples that are further afield. While no guarantees can be made about identifying all
completeness counterexamples, the larger the set of counterexamples and greater the diversity found, the more representative the solution set is of the incompleteness. Ultimately,
detecting completeness counterexamples is limited to the quality and fidelity of the hierarchical requirements model and utility functions.

4.3

Evolutionary Computation Case Study

This section describes and compares the results of applying the four different methods
of identifying counterexamples that satisfy the generated requirement completeness counterexample expressions. These methods are symbolic analysis only (SA), evolutionary computation only (EC), SA-Initialized EC (SAIEC), and Periodic-SA with EC (PSAEC). Each
of these methods were executed 50 times1 . For the SA results, there is no difference between
1

To ensure reproducibility via statistical measures given the stochastic nature of evolutionary computation.

49

executions, but for the results that include EC, the results vary across executions. Results
are compared for two incomplete requirements (Goals D.1 and B.3, to ‘Maintain Speed’ and
‘Slow Car’, respectively) that were previously shown to be incomplete using SA [37]. However,
in contrast to previous solutions [37], Ares-EC identifies multiple representative counterexamples as measured by a distance metric. Methods are compared based on their ability to
return diverse counterexamples. Next, we describe in detail the results from applying each
of these four techniques and analyze the results.

4.3.1

Symbolic Analysis

SA identified a single counterexample for both goals D.1 and B.3. Intrinsically, there
is no range or diversity in a solution set of one result. SA has been previously used to
identify completeness counterexamples [37] and is included here for comparison with the
other search-based methods.

4.3.2

Evolutionary Computation

EC attempts to address the fundamental shortcoming with the results from only SA by
identifying a population of results, rather than a single result. However, even after 50 executions, no counterexamples could be identified. Unlike the single SA result, EC attempts to
identify a range of solutions that are more representative of the scope in which the requirement incompleteness exists. In this case, the lack of variation in fitness (i.e., fitness values are
either 0.0 or 1.0) reduces the EC to random search. Significantly larger populations (5000)
and generations (20000) were also used with no success.

4.3.3

SA Initialization then EC

While the EC-based method alone was unable to provide counterexamples to a single requirement incompleteness, it is possible to start with a known optimum and search for similar
50

counterexamples. The SAIEC method results in 200 counterexamples within a population of
200. This result does not mean that there are 200 missing or incomplete requirements, only
that this method identified 200 representative counterexamples for each single incomplete
requirement. For example, if incomplete requirements decompositions were only found when
the brake is depressed more than 50%, then the 200 counterexamples should be in a distribution ranging from being pressed 50% to being pressed 100%. Unlike the EC-only method,
providing the EC algorithm with a sample optimum has made it possible to find additional
optima resulting in the identification of usable counterexamples from the population.
The SAIEC method is able to find a counterexample for every member of the population for each of the known incomplete requirements (Goals D.1 and B.3). SAIEC is clearly
superior to EC alone, as EC alone is unable to identify any counterexamples. SAIEC is
also clearly superior to SA, as SA is unable to provide any range or diversity within its
counterexamples as SA only identifies a single counterexample.

4.3.4

Periodic SA with EC Results

The additional number of optimal results provided by initializing the EC-based method
with a counterexample found from SA still may leave an intrinsic bias to the original optimal
set in the results. When multiple variables must change in order to maintain an optimum,
it is more difficult to identify additional optima due to the likelihood of a crossover or
mutation maintaining the relationship between those variables. In an effort to identify the
largest range of counterexamples, it may be that periodically adding an optimal solution
outside of the known solutions would improve the overall range of solutions by overcoming
the dependencies between variables. Similar to the SAIEC method, the PSAEC identifies
200 diverse counterexamples within a population of 200.
Similar to SAIEC, the PSAEC method is clearly superior to EC alone for the same
reason that PSAEC is able to identify counterexamples while using EC only is not. PSAEC
is also superior to SA only, as SA only identifies a single counterexample.
51

0.8
0.6

0.8

Mean Range

●

0.2
0.0

0.0

SAIEC

PSAEC

SAIEC

Figure 4.2: Requirement D.1

4.3.5

●

0.4

0.6
0.4

●

0.2

Mean Range

●

●
●
●
●

PSAEC

Figure 4.3: Requirement B.3

Comparison

While SA can only be used to identify the existence of a requirement completeness
counterexample, additional counterexamples provide more information on the range and
scope of the incompleteness. EC-based methods can identify additional counterexamples in
parallel, but encounter difficulties satisfying expressions with fitness cliffs or ‘needle in a
haystack’ solutions (i.e., in an EC-only method) or difficulties with identifying additional
novel solutions due to correlated variables (i.e., in a SAIEC search method). In fact, in this
specific case, the EC-only method was unable to identify results due to the lack of a fitness
gradient. In the general case, the greatest range of optimal genotype values is provided by
the PSAEC that escapes limitations of the SAIEC search methods. Evidence of this finding
can be seen in Figures 4.2 and 4.3 for requirements incompleteness for goals D.1 and B.3,
respectively, where the mean range of genotype values in each individual can be seen in box
plots.
It is necessary to statistically compare the two methods that identified a range of solutions (i.e., SAIEC and PSAEC), since they are both able to identify the same number
52

of counterexamples. We define the null hypothesis H0 to state that there is no difference
between the range of optimal solutions for the SAIEC and PSAEC methods. We also define
an alternative hypothesis, H1 , that states that there is a difference between the range of
optimal solutions for SAIEC and PSAEC methods. In both cases, in goals B.3 and D.1,
PSAEC achieves statistically significant larger mean range values over 50 executions as measured using the Mann-Whitney U-test (p < 0.05 where p = 2.2 ∗ 10−16 ). Therefore we can
reject the null hypothesis, H0 , in favor of the alternate hypothesis H1 due to the statistically
significant difference.

4.4

Evolutionary Computation Related Work

This section covers related work for both requirements completeness and search methods
that maintain diversity. While there is a broad collection of research into leveraging searchbased techniques for requirements-related tasks, many of which are described in surveys [54,
99], to the best of the authors’ knowledge, none have explicitly tackled the problem of
requirements decomposition incompleteness.

4.4.1

Requirements Completeness

Outside of process rigor [98], formal guarantees of requirements completeness exist in
the form of decomposition strategies that are proven to define complete decomposed requirements [31]. Completeness criteria may be added to formal specification languages, though
incomplete requirements may still exist due to criteria that cannot be enforced by language
semantics [67]. A method exists to detect incomplete decompositions using symbolic analysis,
however only a single counterexample for each incomplete requirement is produced [37].
Ares-EC is unique as it applies symbolic analysis and evolutionary computation to
automatically-generated utility functions to detect sets of representative completeness counterexamples without restricting decompositions to a finite set of formal patterns.
53

4.4.2

Search for Diversity

Multi-objective optimization (e.g., NSGA-II [36]) identifies multiple solutions, but the
solutions represent the Pareto front of a tradeoff between two or more objectives [34]. However, if the objectives are not competing, then the problem collapses to single-objective
optimization. Our method of searching for requirement completeness counterexamples does
not contain competing objectives, but rather a single objective with multiple solutions.
Novelty search uses evolutionary computation to identify novel behaviors [66] across
the genotype. Rather than identifying a population of optimum solutions, novelty search
identifies the range of possible solutions from an optimum to the worst solution. Niching is
typically used for multi-modal problems [43], rather than problems with an area of optimal
results.
The search method used by Ares-EC identifies multiple optimum solutions in parallel
while maximizing diversity of the solutions.

4.5

Summary

In this chapter, we have presented Ares-EC, a design-time approach for detecting incomplete requirements decomposition using symbolic analysis and evolutionary computation
to analyze hierarchical requirements models. Unlike previous incomplete requirements detection methods, Ares-EC detects representative sets of incomplete requirements decompositions
while not limiting the allowable decomposition strategies.
We demonstrated Ares-EC on an adaptive cruise control system developed in collaboration with our automotive industrial collaborators. We show that Ares-EC is able to automatically detect incomplete requirements decompositions and provide sets of completeness
counterexamples in seconds, allowing holistic correction of the fundamental incompleteness
issues rather than the correction of single counterexamples. Further, by combining symbolic
analysis with evolutionary computation we achieve the benefits of both techniques.

54

Chapter 5

Detecting Incomplete Requirements:
At Run Time

The validity of run-time monitoring of system goals and requirements depends on both
the completeness of the requirements, as well as the correctness of the environmental assumptions. Often specifications are built with an idealized view of the environment that
leads to incomplete and inconsistent requirements related to non-idealized behavior. Worse
yet, requirements may be measured as satisfied at run time despite an incomplete or inconsistent decomposition of requirements due to violated environmental assumptions. While
methods exist to detect incomplete requirements at design time, environmental assumptions
may be invalidated in unexpected run-time environments causing undetected incomplete decompositions. This chapter introduces Lykus, an approach for using models at run time to
detect incomplete and inconsistent requirements decompositions at run time [39]. We illustrate our approach by applying Lykus to a requirements model of an adaptive cruise control
system from our industrial collaborators. Lykus is able to automatically detect instances of
incomplete and inconsistent requirements decompositions at run time.
55

5.1

Detecting at Run Time

While run-time requirement monitors are intended to measure and report the satisfaction of the requirements in a software system, they are only effective if the requirements
are complete and consistent. Problematically, unexpected environmental scenarios that may
lead to incomplete or inconsistent requirements in cyber-physical systems may also allow
run-time monitors to erroneously assess requirements satisfaction. For example, if a requirements decomposition is incomplete, then the decomposed requirement would be satisfied even
if the missing requirement(s) were unsatisfied. This chapter presents Lykus,1 an approach to
automatically detect incomplete requirements coverage at run time.
Detecting incomplete requirements is still an active research area [2, 23, 46, 69, 98, 37],
which becomes more complicated when design-time environmental assumptions are found
to be invalid at run time. For example, a requirement for a vehicle may be to accelerate.
In an idealized system, applying the throttle (e.g., pressing the gas pedal) would be sufficient. However, the assumption that spinning the wheels faster due to an increased throttle
affects vehicle speed may be found to be invalid. Given an environmental scenario with low
traction (e.g., ice) or where the vehicle’s wheels do not touch the ground (e.g., the vehicle
is flipped over) would invalidate the earlier assumption when the vehicle did not accelerate.
Formal design-time methods to decompose goals and requirements with guaranteed completeness exist [31], though they are limited to only specific formal decomposition rules.
Design-time methods exist that are not limited to formal decomposition patterns [37, 38],
but make assumptions about the environment that may be shown to be invalid at run time.
Problematically, run-time monitoring of incompletely decomposed requirements may indicate satisfaction when the missing requirement(s) would be unsatisfied (e.g., the throttle is
increased indicating satisfaction, but the vehicle does not accelerate). Currently, no methods
exist to detect incomplete and inconsistent requirements decompositions at run time in order
to ensure relevant requirement satisfaction assessment.
1

Lykus is the mortal son of Ares, who sacrificed strangers to his father.

56

This chapter describes Lykus, the extension of Ares, a design time model-driven technique [37] to detect incomplete and inconsistent requirements decompositions at run time.
Lykus adapts run-time monitors to ensure relevant assessment in the context of the physical
environment and requirements model. While requirements in a hierarchical decomposition
may be assessed directly or based on the satisfaction of the decomposed child requirements,
neither method is sufficient to assess satisfaction alone in the presence of an incomplete
or inconsistent decomposition. However, by using a combination of both assessments, it is
possible to detect an incomplete or inconsistent decomposition and calculate the correct
requirement satisfaction. For example, given a parent requirement to accelerate a vehicle,
it may appear that the requirement is satisfied when all of the decomposed child requirements (e.g., increase throttle) are satisfied. If the vehicle does not accelerate, then there is an
incomplete requirement decomposition and additional requirements that are unrepresented
are unsatisfied. Similarly, if the vehicle does accelerate but the decomposed requirements are
not satisfied, then the parent requirement to accelerate is not being satisfied in the manner
specified by the child requirements. Instead, it could be that the vehicle is rolling down a hill
rather than accelerating via throttle. In both cases, the intent of the acceleration requirement
is not met, therefore the requirement is unsatisfied. Lykus identifies incomplete and inconsistent decompositions at run time to dynamically modify requirement satisfaction monitors in
order to provide more environmentally relevant assessments of the requirements unsatisfied.
Lykus also identifies violated environmental assumptions when incomplete or inconsistent
decompositions are identified at run time.
Lykus uses utility functions [75] to analyze individual requirements within the system
specification. Rather than return the raw assessment values generated by the utility functions, Lykus identifies incomplete requirements (i.e., additional requirements are necessary
but not specified) and inconsistent requirements (i.e., the system is not constrained in the
manner defined by the requirements) at run time by comparing the utility function values
for parent and child requirements. In the case of incomplete requirements, the parent utility
57

function value is modified to be ‘unsatisfied,’ as there exists at least one requirement that
should have been decomposed (but was not) that is ‘unsatisfied.’ Similarly, in the case of
an inconsistent satisfied requirement, the parent utility function value is also modified to
be unsatisfied since the satisfaction did not take place according to the constraints imposed
by the decomposed requirements. Lykus explicitly uses the decompositions from within a
hierarchically decomposed goal model, typically a design-time model, to analyze the decomposition completeness and consistency at run time where specific scenarios representing the
actual state of the environment and system are continually processed, or streamed, through
the detection system.
The contributions of this chapter are as follows:
• We introduce a run-time approach to automatically detect incomplete and inconsistent
requirement decompositions in hierarchical requirements models.
• We adapt the utility function results in the case of incomplete and inconsistent decompositions in order to assess satisfaction with respect to the actual physical environment
conditions, as opposed to an environmental model.
• We identify the environmental assumptions that are shown to be invalid and are the
contributing factor to the incomplete or inconsistent decomposition.
• We present a prototype implementation of the Lykus run-time analysis and requirement
assessment approach.
• We demonstrate the applicability of Lykus on an adaptive cruise control system implemented on a rover vehicle.
The remainder of this chapter is organized into the following sections. The model used
for the example application is defined in Section 5.2. Section 5.3 details the approach. Section
5.4 describes an example application, and Section 5.5 details related work. Finally, Section
5.6 discusses the conclusions and avenues of future work.
58

5.2

Complete Adaptive Cruise Control Input Model

Figure 5.1 details a hierarchical goal and requirements model of an Adaptive Cruise Control system that uses distance sensors to ensure a safe following distance from the car ahead
by adjusting vehicle speed while simultaneously maintaining as close to the desired speed as
possible. This goal model is updated from the one presented in Chapter 3 (Figure 3.1) to
reflect the modifications performed according to Ares and Ares-EC analyses. Abbreviations
M and A are used for Maintain and Achieve, respectively. Leaf nodes (i.e., agents) that are
numbered in the requirements model are provided in Table 5.1. The ACC model defined here
has been previously shown to be complete [37], given the assumed environmental conditions.
A.1 M(Adaptive Cruise System)

B.2
A(Slower Speed)

A(Off, Off)

M(Off, Off)

A.2

M(On, Off)

M(On, On)

A.4

A.3

B.3

A.5

A(Slow Car)

B.1
A.6

= On

1

2

A(Off)

A.12

A.13

= On

= Off

= On

= On

1

2

1

2

A.11

A.8

A.7

= Off

A.9

A.10

= Off

= Off

1

2

3

A.14

M(Automatic Control)

B.4
A(Reduce Throttle)

B.5
B.8

M(Manual Control)

A.16
M(Throttle
Response)

A.18

Speed > Desired Speed OR
Distance < Safe Distance

A.17

A.19

4

5

6

B.12

Wheel Speed >
Desired Speed

GPS Speed >
Desired Speed

8

9

7

C.2
Speed < Desired Speed AND
Distance > Safe Distance

C.4

C.6

Throttle Angle < 45

Brake Pedal
Sensor < 45

7

6

4

6

D.3

A(Brake Pedal Sensor Reading)

D.New1
A(Brake Actuator =
Brake Pedal Sensor)

C.9

A(Throttle Actuator =
Throttle Pedal Sensor)

6

Speed = Desired Speed AND
Distance > Safe Distance

A(Throttle Pedal Sensor Reading)

D.6
C.11

10

11

4

4

D.7

Wheel Speed Sensor =
Desired Speed

C.13

A(Throttle Pedal
Sensor Reading)

D.8
Distance > Safe Distance

9

Distance Sensor 2 >
Safe Distance

5

D.5
D.4

Speed = Desired Speed

7

4

Distance Sensor 1 >
Safe Distance

B.19

Throttle Pedal
Sensor = 0

M(Speed)

7

C.8

C.10

B.18

A(Brake Pedal
Sensor Reading)

D.2

Distance > Safe Distance
8

B.17

A(Brake Actuator =
Brake Pedal Sensor + 1)

D.New2

A(Brake Angle = 0)

C.7
5

11

B.15
A(Increase Brake)

D.1

A(Throttle Actuator =
Throttle Pedal
Sensor + 1)

Wheel Speed Sensor < GPS Speed Sensor <
Desired Speed
Desired Speed

10

A(Increase Throttle)

C.5

B.14

Distance 2 <
Safe Distance

C.3
C.12

Speed < Desired Speed

B.13

Distance 1 <
Safe Distance

B.16

C.1
A(Faster Speed)

4

4

Distance <
Safe Distance

B.11

A.21

A(Brake Actuator =
A(Brake Pedal
Sensor Reading) Brake Pedal Sensor
Reading)

Throttle Angle > 0

B.10

Speed >
Desired Speed

A.20

A(Throttle Actuator =
Throttle Pedal Sensor)

B.7

A(Throttle Pedal
Sensor Reading)

5

B.9

M(Brake Response)

A(Throttle Pedal
Sensor Reading)

B.6

A(Throttle Actuator =
Throttle Pedal Sensor - 1)

A.15

8

GPS Speed Sensor =
D.9
Desired Speed
Distance Sensor 1 >
Safe Distance
9

10

D.10
Distance Sensor 2 >
Safe Distance
11

Figure 5.1: Adaptive Cruise Control Goal Model
The ACC model in Figure 5.1 is defined by four primary components: cruise control
modes (i.e., goals with a prefix of ‘A.’), speed increase (i.e., goals decomposed from C.1),
59

Table 5.1: Agents used in Goal Model
#
1
2
3
4
5
6
7
8
9
10
11

Agent (Sensor / Actuator)
Cruise Switch Sensor
Cruise Active Sensor
Cruise Active Switch
Throttle Pedal Sensor
Throttle Actuator
Brake Pedal Sensor
Brake Actuator
Speed Sensor 1
Speed Sensor 2
Distance Sensor 1
Distance Sensor 2

speed decrease (i.e., goals decomposed from B.2), and maintain speed (i.e., goals decomposed
from D.1). The speed is increased or decreased to maximize speed up to the desired speed
while maintaining a safe distance from the target car (i.e., the car immediately in front).
In cases where the safe distance is violated, the speed is decreased regardless of the desired
speed. In cases that both the desired speed and safe distance are met, the speed is maintained.

The utility functions for the requirements in Figure 5.1 are derived from the ENV,
MON, and REL properties in Table 5.2, where, for brevity, only values related to the
ongoing example are presented. For example, the utility function for requirement C.1 is
given in Expression 5.1 indicating that goal C.1 (‘Achieve Faster Speed’ ) is satisfied if the
speed value at time t, Speedt , is less than the value at time t + 1, Speedt+1 . Table 5.3 defines
the variable value ranges and units.

Satisficement(C.1) = Speed t < Speed t+1

60

(5.1)

Table 5.2: ENV, MON, and REL Properties
C.1
C.2
C.3
C.12
Speed t
Speed t
Speed t+1
Distance

ENV
Speed t , Speed t+1
Speed t , Distance

MON
Desired Speed , Safe Distance
Throttle Actuator , Throttle Pedal Sensor
Brake Actuator
Speed Sensor 1 , Speed Sensor 2
Throttle Pedal Sensor , Brake Pedal Sensor
Throttle Actuator , Brake Actuator
Distance Sensor 1 , Distance Sensor 2

REL
Speed t < Speed t+1
Speed t < Desired Speed ∧ Distance > Safe Distance
Throttle Actuator > Throttle Pedal Sensor
Brake Actuator == MIN
Speed Sensor 1 ∨ Speed Sensor 2
max (MIN , Throttle Pedal Sensor − Brake Pedal Sensor )
max (MIN , Throttle Actuator − Brake Actuator )
Distance Sensor 1 ∨ Distance Sensor 2

Table 5.3: Units and Scaling for Variables in Table 5.2
Variable
Speed t
Speed t+1
Distance
Desired Speed
Safe Distance
Throttle Actuator
Throttle Pedal Sensor
Brake Actuator
Brake Pedal Sensor
Distance Sensor 1
Distance Sensor 2
Speed Sensor 1
Speed Sensor 2
Cruise Switch Sensor
Cruise Active Sensor
Cruise Active Switch

5.3

Min
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
Off
Off
Off

Max
100.0
100.0
50.0
100.0
50.0
100.0
100.0
100.0
100.0
50.0
50.0
100.0
100.0
On
On
On

Unit
MPH
MPH
Inches
MPH
Inches
%
%
%
%
Inches
Inches
MPH
MPH
Boolean
Boolean
Boolean

Run-Time Approach

An overview of Lykus is presented in Figure 5.2. Similar to Ares, Lykus makes use of
Athena [75] to generate the utility functions that are used as run-time monitors to detect
incomplete and inconsistent decompositions of parent requirements in the goal model (e.g.,
Figure 5.1) using the properties in Table 5.2. Optionally, Ares can be used to detect incomplete requirements decompositions that can be identified at design-time [37]. The utility
functions and goal model are then used by Lykus to generate logical expressions that represent the decompositions within the hierarchically decomposed goal model to detect both
incomplete and inconsistent decompositions. These logical expressions are used by Lykus to
61

generate executable monitoring code that detects incomplete and inconsistent decompositions and accurately report parent satisfaction. The executable monitoring code generated
by Lykus is used at run time to monitor the system operating in its physical environment to
detect counterexamples and report satisfaction throughout the system’s execution.
Goals

Goal Model

(Optional)
Ares

Goals &
Utility Functions

Athena

(Complete)
Goals &
Utility Functions

Run-Time
Monitoring
Code

Process Key:

Run-Time
Monitoring
Code

Process
Flow
External I/O
File

(2)
Generate
Monitoring
Code

Logical
Expressions

(1)
Generate Logical
Expressions

Figure 5.2: Lykus Data Flow Diagram

Lykus is applicable to systems that interact with their environment, where the environment is anything that is outside of the system-to-be. The environment may be other systems,
not just a physical environment. Additionally, the system must be able to sense its expected
impact on the environment to allow utility functions to measure the satisfaction of individual requirements directly, or indirectly using relationships between multiple sensors. Finally,
requirements must be defined hierarchically to detect decompositional counterexamples.

5.3.1

DFD Step 1: Generate Logical Expression

The input to Step 1 is a goal model that may be analyzed at design-time for incomplete
requirement decompositions using Ares [37] and utility functions generated by Athena [75].
Lykus outputs a set of requirements monitors and additional logic that detects incomplete
62

Table 5.4: Satisfaction Cases

Row
1
2
3
4

Utility Function
Parent
Child
Requirement Requirements
Unsatisfied
Unsatisfied
Unsatisfied
Satisfied
Satisfied
Unsatisfied
Satisfied
Satisfied

Updated
Parent
Requirement
Unsatisfied
Unsatisfied (Incomplete)
Unsatisfied (Inconsistent)
Satisfied

and inconsistent requirements decomposition, as well as provides the status of the parent
requirement satisfaction.
Unlike design-time solutions that use utility functions for analysis across an entire range
of possible scenarios [37], Lykus applies the utility value functions at run time for a single
scenario that the system is currently experiencing. Based on the results of the comparisons of
the realized utility value functions, analysis is performed each time the utility functions are
calculated at run time. Counterexamples are identified, and subsequently used immediately
for run-time requirement assessments.
Table 5.4 lists the satisfaction of both the parent requirement and the set of decomposed child requirements along with the updated parent requirement satisfaction status to
reflect the run-time evaluation of the parent in actual environmental conditions. For each
decomposed requirement, two additional checks are performed, one for incomplete decomposition and one for inconsistent composition. If the requirement is neither incomplete nor
inconsistent, then the requirement’s utility function is unmodified. The possible parent and
decomposed child requirement satisfaction results listed in Table 5.4 are discussed in the
following subsections. If the parent’s and decomposed child requirements’ satisfactions do
not match, then the parent must be unsatisfied due to either incomplete or inconsistent decomposition. Table 5.4 identifies the possible combinations of parent and decomposed child
requirements satisfaction, along with the updated parent satisfaction based on run-time satisfaction measures.
63

Standard Unsatisfied Requirements
In the case where both the parent and the child requirements are unsatisfied (i.e., Row
1 in Table 5.4), the satisfaction of the parent does not change and the parent requirement
remains unsatisfied at run time. Since both the utility function representing the satisfaction
of the parent requirement and the combined satisfaction of child requirements are both unsatisfied, then the result is neither incomplete nor inconsistent. The requirement is correctly
assessed as unsatisfied by both the parent and child requirements. That is, there is not a
known missing requirement due to an unsatisfied parent requirement nor is there an inappropriately satisfied parent requirement due to a solution not specified by the decomposed
child requirements. When a parent requirement is unsatisfied, we would normally expect the
decomposed child requirements to be unsatisfied.

Unsatisfied Due to Incompleteness
In the case where the parent is unsatisfied, yet the decomposed child requirements are
satisfied (i.e., Row 2 in Table 5.4), the parent requirement should remain unsatisfied due to an
incomplete decomposition. While the aggregate child requirements indicate that the parent
requirement should be satisfied, they only indicate satisfaction due to a missing requirement
that would alter the satisfaction of the aggregate set.

Unsatisfied Due to Method Used
In the case where the parent requirement is satisfied, yet the decomposed child requirements are unsatisfied (i.e., Row 3 in Table 5.4), the parent status must be modified to indicate
that it is unsatisfied. While the parent requirement utility function indicates that the parent
requirement is satisfied, the method of satisfaction is not constrained to the solution provided
by the decomposed requirements.
64

Standard Satisfied Requirement

In the case where the parent requirement and the decomposed child requirements are
both satisfied (i.e., Row 4 in Table 5.4), then the decomposition is neither incomplete nor
inconsistent. Regardless of the method of assessing the requirement (i.e., directly or via the
requirement’s decomposed child requirements) the assessment results in satisfaction for both
the parent and children.

5.3.2

DFD Step 2: Generate Monitoring Code

The logic for comparing parent requirement and aggregate child requirements satisfactions is generated for each decomposed parent requirement. Neither direct measurement
of each requirement (e.g., measuring parent requirements for satisfaction) nor measuring a
requirement’s aggregate decomposed requirements (e.g., measuring the set of child requirements for satisfaction) is sufficient to assess the satisfaction of the parent requirement in all
cases. An implementation of Table 5.4 to calculate the updated satisfaction of requirement
C.1 at run time is given in Figure 5.3. This approach differs from the Ares approach, since
here we detect at run time if a single specific environmental and system scenario related to the
current state of the system includes incomplete or inconsistent requirements decomposition.
The requirements, values of the variables, and (when included) environmental assumptions
are recorded upon the detection of an incomplete or inconsistent requirements decomposition. Similar functions that update parent requirement status, as measured from the original
utility functions, are provided for each of the parent requirements in the goal model in order
to detect incomplete and inconsistent decompositions and the associated variables at run
time.
65

bool updated sat of c1 () {
// A s s e s s Parent S a t i s f a c t i o n
bool parent sat = s a t o f c 1 ( ) ;
// A s s e s s Aggregate Child S a t i s f a c t i o n
b o o l c h i l d s a t = s a t o f c 2 ( ) &&
s a t o f c 3 ( ) && s a t o f c 1 2 ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return parent sat ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ‘ ‘C . 1 ’ ’ ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
Figure 5.3: Updated Utility Function Listing of C.1

5.3.3

Execution Time & Deployment

For each requirements decomposition, the computational effort of Lykus grows linearly
with respect to the number of decomposed requirements, assuming a constant maximum size
of each utility function. Instead of calculating if a requirements decomposition is incomplete
or inconsistent in any scenario, Lykus calculates if a requirement decomposition is incomplete
or inconsistent in only the current scenario (e.g., the agents periodically read from sensors
to support the calculation of the utility functions). This is similar to checking a known NP
problem, SAT, for a single set of true or false assignments rather than attempting to find
which true or false assignments satisfy the Boolean expression.
More formally, identifying incomplete or inconsistent requirements decompositions exists
is NP-Complete. That is, identifying an incomplete or inconsistent requirements decompositions is computationally expensive but verifying a specific incomplete or inconsistent requirements decomposition can be done very quickly. Lykus leverages the latter property and
66

verifies the decompositional completeness and consistency with respect to only the current
environmental scenario.
Given that utility functions are widely used as run-time monitors [75] (e.g., “ sat of ∗()”
in Figure 5.3), the additional cost Lykus incurs is used to calculate a single Boolean expression based on the concrete satisfaction of the utility functions (e.g., calculation of
“parent sat == child sat” in Figure 5.3) for each decomposition.
Lykus calculates if each decomposition is incomplete or inconsistent for the current
scenario as measured by the utility functions and their respective monitor properties (i.e.,
agents and sensors). The utility functions are updated as new sensor results are available (as
often as 20 times per second) based on the control loop of the software and the speed of the
processor and senor responses. When the utility function values are updated, the decompositions that include the requirements with updated utility function values are checked for
incompleteness. That is, the decompositions of the requirements specification are evaluated
and re-evaluated for incompleteness throughout the execution of the system in which the
generated run-time monitoring code is deployed.

5.3.4

Limitations

The accuracy of Lykus is only as good as the accuracy of the ENV, MON, and REL
properties used to define the utility functions. Additionally, counterexamples may be present
in a scenario that occurs only between sensor readings. In such cases, the values calculated
by the utility functions never represent an incompleteness or inconsistency and, therefore,
no counterexample is detected.

5.4

Run-Time Examples

This section covers examples of an incomplete requirement decomposition and an inconsistent requirement decomposition. Lykus is able to generate code to use utility functions
67

to detect incomplete and inconsistent requirements decompositions at run time to ensure
run-time relevant requirements assessment.

5.4.1

Experimental Setup

The updated utility functions and detection logic are executed during the operation of
a small autonomous car. The car, shown in Figure 5.4, comprises a 16 MHz ATmega328
microcontroller and two speed controllers driving 4 motors turning 4 wheels. Distance measurements are provided by an ultrasonic sensor, speed measurements are provided by a
cumulative accelerometer, and user input is provided by infrared remote control. The small
autonomous car was placed into two different environmental scenarios intended to elicit the
detection of both incomplete and inconsistent decompositions.

Figure 5.4: Experimental Autonomous Car

5.4.2

Incomplete Requirement Decomposition

In order to demonstrate an incomplete requirement decomposition for a parent requirement, the aggregate child requirements must be satisfied while the parent requirement itself
is unsatisfied. Using goal C.1 as an example, the car must be placed in a position where
the utility function is invalid. Specifically, the speed cannot increase over some given time
68

despite an increase in throttle with no braking. An environmental scenario outside of the
idealized environmental model (i.e., as defined in Table 5.2 for rows Speed t , Speed t+1 , and
Distance) may elicit previously undetected incomplete requirement decompositions.
In this example, we physically flip the vehicle onto its back, allowing none of the wheels
to touch the ground. Since our idealized environmental model never considered the possibility
of rolling the vehicle over, the standard method of accelerating does not apply. The updated
utility function code generated by Lykus detects an incomplete decomposition from C.1 at
run time and records the incomplete decomposition, the system and environmental variables,
and violated environmental assumptions.
Importantly, in order to maintain the set speed, the cruise control system attempts
to accelerate by increasing the throttle (via goal C.3) while the brake is not applied (via
goal C.12); there is a safe distance to any upcoming obstacle and the current speed is less
than the desired speed (via expectation C.2). Despite these decomposed child goals being
satisfied, the speed (both at the current time and in the future) are 0. Due to the detected
incomplete decomposition, parent goal C.1 is reported as unsatisfied based on run-time
monitored conditions. The variables recorded for the incompleteness are shown in Table 5.5
and are limited to a resolution of 10% for percentage-based values and one tenth (i.e., 0.1)
for all other values due to the truncation of sensor and actuator resolution to minimize
oscillation and measurement error.
Given the list of environmental assumptions defined in Table 5.2, the values of the
counterexample variables can be used to identify violated environmental assumptions at run
time. Table 5.6 includes the list of environmental assumptions and indicates if they are valid
or not. It is important to note that if the optional design-time completeness detection was
not performed by Ares, there may be no environmental assumptions documented. In this
case, Table 5.6 shows that rows 2 and 3 both include violated environmental assumptions
related to the calculation of speed from only the brake and throttle, ignoring the possibility
of outside influences (e.g., rollovers). This information can be logged for analysis of failures
69

Table 5.5: Incomplete Decomposition Values
Row
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Variable or Goal
Brake Actuator
Brake Pedal Sensor
Desired Speed
Distance
Distance Sensor 1
Distance Sensor 2
Safe Distance
Speed Sensor 1
Speed Sensor 2
Speedt
Speedt+1
Throttle Actuator
Throttle Pedal Sensor
Goal C.1
Goal C.2
Goal C.3
Goal C.12

Value
MIN
MIN
MAX
MAX
MAX
MAX
6 Inches
MIN
MIN
MIN
MIN
80%
70%
Unsatisfied
Satisfied
Satisfied
Satisfied

Table 5.6: Environmental Assumptions: Incompleteness
Row
1
2
3
4

Environmental Assumption
Speed t = Speed Sensor 1 ∨ Speed t = Speed Sensor 2
Speed t = max (MIN ,
Throttle Pedal Sensor − Brake Pedal Sensor )
Speed t+1 = max (MIN ,
Throttle Actuator − Brake Actuator )
Distance = Distance Sensor 1 ∨
Distance = Distance Sensor 2

Valid
True
False
False
True

after they occur, or used as inputs to existing adaptation methods beyond the scope of this
chapter.

5.4.3

Inconsistent Requirement Decomposition

In order to demonstrate an inconsistent requirements decomposition, the speed must
increase despite not increasing the throttle. We achieve this case by allowing the vehicle
to drive off a ‘cliff,’ represented by the edge of a desk. The car accelerates through its fall
70

Table 5.7: Inconsistent Decomposition Values
Row
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Variable or Goal
Brake Actuator
Brake Pedal Sensor
Desired Speed
Distance
Distance Sensor 1
Distance Sensor 2
Safe Distance
Speed Sensor 1
Speed Sensor 2
Speedt
Speedt+1
Throttle Actuator
Throttle Pedal Sensor
Goal C.1
Goal C.2
Goal C.3
Goal C.12

Value
MIN
MIN
2 MPH
MAX
MAX
MAX
6 Inches
1.2 MPH
1.2 MPH
1.2 MPH
2 MPH
20%
20%
Satisfied
Unsatisfied
Unsatisfied
Satisfied

despite not increasing the throttle. Just as with the incomplete requirements decomposition,
the updated utility function code generated by Lykus detects an inconsistent decomposition
from C.1 and records the inconsistent decomposition (i.e., the parent requirement is satisfied
in a method outside of what is specified by the decomposed requirements), the system and
environmental variables, and violated environmental assumptions.
In this case, the ACC system accelerates without increasing the throttle (via goal C.3)
while the brake is not applied (via goal C.12). While there is a safe distance to any upcoming
obstacle, the current speed is not less than the desired speed (via expectation C.2). Despite
not satisfying these decomposed child goals, the speed increases due to the precipitous drop.
Due to the detected inconsistent decomposition, goal C.1 is reported as unsatisfied, as it is
not satisfied in the method required by the decomposed child requirements. The variables
recorded for the inconsistency are shown in Table 5.7 and are limited to a resolution of 10%
for percentage based values and one tenth (i.e., 0.1) for all other values due to the truncation
of sensor and actuator resolution to minimize oscillation and measurement error.
71

Given the list of environmental assumptions previously identified in Table 5.2, Table 5.8
lists the environmental assumptions and indicates their run-time validity. Similar to the incompleteness counterexample, rows 2 and 3 both include violated environmental assumptions
related to the calculation of speed from only the brake and throttle, ignoring the possibility
of outside influences (e.g., drastic changes in terrain). The system designer may choose to
adapt to solutions that do not depend on the invalid environmental assumptions, or the
invalid environmental assumptions may be recorded for later revision of the system.

Table 5.8: Environmental Assumptions: Inconsistency
Row
1
2
3
4

5.4.4

Environmental Assumption
Speed t = Speed Sensor 1 ∨ Speed t = Speed Sensor 2
Speed t = max (MIN ,
Throttle Pedal Sensor − Brake Pedal Sensor )
Speed t+1 = max (MIN ,
Throttle Actuator − Brake Actuator )
Distance = Distance Sensor 1 ∨
Distance = Distance Sensor 2

Valid
True
False
False
True

Threats to Validity

Since Lykus is most realistically validated at run time, rather than using a simulation
or static analysis, the validation is limited to the finite set of scenarios that occur. We
have ensured that both inconsistent and incomplete requirements decompositions can be
identified, however additional inconsistent and incomplete requirements decompositions may
exist within the requirements model. The validation of the detection classification, however,
is done by specific cases (i.e., Table 5.4) within the description of the approach. Additionally,
methods that could manage sensor uncertainty (e.g., RELAXed goals and requirements [94])
are not included in the examples of incomplete and inconsistent requirements.
72

5.5

Run-Time Related Work

This section overviews related work, including requirements completeness and run-time
monitoring of requirements. Unlike proposals to use run-time specific models to support
run-time analysis [30], we use goal models intended for design time use for run-time analysis.

5.5.1

Requirements Completeness

Multiple methods have been developed to identify incomplete requirements decomposition. We overview these strategies and compare them to Lykus. Obstacles to requirements
completeness have been generated using search-based techniques [2], however the counterexamples must be manually reviewed for applicability. Formal methods of guaranteeing
complete requirements exist for behavioral state-based systems [56], formally described requirements using theorem provers [87], and low-level functional details [56]. Additionally,
decomposition with formally-proven completeness properties also exist, where a system defined by repeated application of the formal decomposition patterns guarantees completeness.
Problematically, formal methods are intrinsically heavyweight solutions that often require
expertise with theorem proving [87] or limit possible solutions to the formally defined patterns.
Tools also exists that identify single [37] or multiple [38] counterexamples (Ares and
Ares-EC, respectively) in hierarchical requirements decompositions at design time without
restrictions on decomposition patterns or heavyweight formal descriptions and analysis.
Lykus differs by acknowledging that invalid environmental assumptions made at design
time may leave incomplete decompositions intact until they occur at run time. Lykus detects
these incomplete decompositions at run time rather than at design-time and provides more
accurate utility function assessment in the presence of incomplete decompositions.
73

5.5.2

Run-Time Monitors

Several frameworks exist to monitor requirements at run time [45, 47, 78] that are
intended to support instrumentation, diagnosis, and reconfiguration operations within the
system. The utility functions whose values we adapt in Lykus, as generated by Athena [75],
provide the same support with the benefit of automatic generation from a set of environmental properties. Lykus differs from existing run-time monitors by detecting incomplete
and inconsistent requirements at run time and adapting the results of existing run-time
monitors [75] to provide more accurate results.

5.6

Lykus Conclusion

In this chapter, we have presented Lykus, a run-time approach for detecting incomplete
and inconsistent requirements decomposition and using that information to identify invalid
environmental assumptions and unsatisfied requirements. Lykus reports the issues detected
with requirements, as well as the invalid environmental assumptions, while automatically
updating the satisfaction results of requirements monitoring.
We demonstrate Lykus on an adaptive cruise control system developed in collaboration
with our industrial collaborators and implemented on a robotic vehicle. We show that Lykus
is able to detect incomplete and inconsistent requirements at run time due to invalid environmental assumptions. Specifically, we show that while existing tools identify no incomplete
requirements, incomplete decompositions may still exist due to incorrect assumptions that
are detectable using run-time monitors.
In the future, we plan to apply Lykus to additional examples, including requirements
models with RELAXed requirements [94] that make use of fuzzy logic in specifying requirements. Additionally, we plan to investigate how Lykus can be used to trigger additional
mitigations at run time due to unsatisfied requirements that would not be detected with
other methods.

74

Chapter 6

Detecting Feature Interactions: Using
Symbolic Analysis

Independently-developed features often exhibit overlapping, yet conflicting behavior
termed feature interactions. Detecting unwanted feature interactions amongst even a moderate number of features can involve analysis of an exponential number of possible interactions.
A potentially human resource-intensive step is the subsequent effort needed by the system
designer to assess each detected interaction. This chapter introduces Phorcys, a symbolic
analysis, design-time approach for detecting unwanted n-way feature interactions and determining their causes at the requirements level. Unlike previous n-way feature interaction
detection approaches that attempt to enumerate every set of interacting features, Phorcys
analyzes each feature for its ability to cause an interaction with other features, thus reducing
designer assessment effort to be linear with respect to the number of features. To the best of
the authors’ knowledge, Phorcys is the only technique to detect both the existence of n-way
feature interactions and identify the respective cause. We illustrate our approach by applying
Phorcys to an industry-based automotive braking system comprising multiple subsystems.
75

6.1

Introduction

Despite ongoing research since the 1980s, feature interactions (FIs) still pose a significant challenge to modularity and assurance in software development and design [4]. While
heavily researched within the telecommunications domain, the increasing complexity and
number of features in onboard and cyber-physical systems has created a new generation of
challenges [4]. Detecting feature interactions is challenging due to the exponential growth
of potential interactions with respect to the number of features [17] and the range of environmental possibilities in cyber-physical systems. More formally, when defining a feature
interaction by the minimal set of features that are necessary for the interaction to occur, the
number of possible interactions is O(2|F | ), where F is the set of features [5]. The development
of additional features is ultimately overwhelmed by integrating features and managing the
feature interaction problem [18], thus making it impractical for a system designer to assess all
possible feature combinations that cause an interaction. The growth in the number possible
feature interactions and consequently the number of possible feature interactions that must
be assessed can result in latent behavior that impacts the system dependability at run-time.
This problem is particularly prominent in cyber-physical systems where unexpected adverse
environmental conditions may occur and impact the dependability of the system. This chapter presents Phorcys,1 a method for symbolically detecting each feature that causes an n-way
feature interaction in a requirements goal model, thus reducing the system designer’s effort
to assessing only as many interactions as there are features.
In order to address the computational intractability of feature interaction detection,
many researchers have focused on pair-wise interactions [10, 21, 41, 59]. Rather than detecting interactions amongst any number of features, only pairs of features are analyzed. While
this approach decreases the number of potential interactions detected to O(|F |2 ), interactions that only emerge when three or more features are present will not be detected [5].
In typical development projects, where features are added incrementally [20], pair-wise fea1

Phorcys (pronounced ‘forsis’) is the Greek god of hidden dangers in the deep.

76

ture interaction analysis only assesses the newly added feature paired with each existing
feature. Given that a recent study found interactions greater than pair-wise in every system
analyzed [5], n-way interaction detection techniques are also needed.
This chapter presents Phorcys, a method for symbolically analyzing a feature, represented in a goal model, to detect an n-way feature interaction. Rather than analyze every
combination of features for an interaction, Phorcys analyzes each individual feature for its
ability to cause an interaction.2 For example, consider 3 features, F1 , F2 , and F3 . If an interaction exists, then at least one feature (F1 , F2 , or F3 ) no longer operates as it did independently.
When the inclusion of F1 is impacted by the functionality of F2 , F3 , or F2 and F3 together,
then F1 is the cause of the feature interaction. This relationship is not exclusive, if F1 impacts the functionality of F3 , it may also be true that F3 impacts the functionality of F1 .
This concept of the cause of the interaction scales to any number of features. Any feature
under analysis can be the cause of an interaction if it is impacted by any features in the set
of features.
Phorcys analyzes features represented in goal models that hierarchically decompose
a high-level goal down to individual requirements [87]. Phorcys analyzes each feature by
symbolically representing the possible feature combinations of the goal model and uses a
constraint solver to check for the existence of any combination of features where the analyzed
feature causes conflict in one or more requirements to be satisfied. As such, Phorcys is able
to check for many feature interaction possibilities in a single analysis. Where previous nway feature interaction detection methods may present an intractably large (exponential)
set of automatically detected interactions for the system designer to assess manually for
causes [18, 20], Phorcys only presents features that cause an interaction and a corresponding
counterexample scenario for each of those interactions.
The contributions of this chapter are as follows:
2

Phorcys identifies one counterexample for each feature that causes an interaction (e.g., the number of
counterexamples to be reviewed by the designer is linear with respect to the number of features). This does
not imply a linear run time, as each analysis may be computationally expensive.

77

• We introduce a new symbolic approach for analyzing requirements to detect unintended n-way feature interactions and the features that cause them, including proofs
of soundness and completeness,
• We present Phorcys, a prototype implementation of the approach, and
• We demonstrate the applicability of Phorcys on an industry-based application of an
automotive braking system based in part on the feature interaction issues in the 2010
Toyota Prius [29, 63], a hybrid vehicle. Analysis shows that Phorcys is able to identify
feature interaction causes in the braking system goal model, involving two or more
features.
The remainder of this chapter is organized as follows. Section 6.2 describes how feature
interactions can be formalized, including the cause of feature interactions while Section 6.3
covers proofs of soundness and completeness for the formalization. Section 6.4 introduces
the Phorcys approach to modeling features in goal models. Section 6.5 describes the Phorcys
process and gives technical details of the detection methods. Section 6.6 provides results of
the Phorcys process applied to the braking system goal model. Sections 6.7 and 6.8 present
related work and a summary, respectively.

6.2

Formally Specifying Feature Interactions

This section formally defines pairwise feature interactions based on previous work [20]
and extends the formalization to n-way interactions. The n-way feature interaction problem
is then refined in terms of requirement specifications and detecting feature interaction causes.

6.2.1

Standard Feature Interactions

Previously, Calder, et al. [20] described a feature interaction between two features (F1
and F2 ) and their respective properties (φ1 and φ2 ). The description is as follows. A feature,
78

F1 , satisfies a property, φ1 , denoted as F1 |= φ1 . Features may be combined, or composed,
via a composition operator (‘⊕’). Since decomposed goals and features in a goal model are
satisfied or unsatisfied in parallel, the composition operator (i.e., ‘⊕’) is a parallel composition
operator. Since requirements in goal models are declarative and must be satisfied in parallel
to satisfy the root goal, we only consider parallel composition. Future work may include
sequential composition. For example, features F1 and F2 , may be composed as F1 ⊕F2 . When
F1 |= φ1 and F2 |= φ2 , the expected composition of F1 and F2 should satisfy the conjunction
of their respective properties, that is, F1 ⊕ F2 |= φ1 ∧ φ2 . However, if the composition of the
features does not satisfy the conjunction of their respective properties, then there exists a
feature interaction [20] as shown in Equation 6.1:

F1 ⊕ F2 6|= φ1 ∧ φ2 .

6.2.2

(6.1)

N-Way Feature Interaction Extension

This 2-way interaction concept can be extended to represent n-way interactions where
any number of composed features result in the satisfaction of their aggregate properties:
|F |
M

|F |

(Fi ) 6|=

i=1

^

(φi ),

(6.2)

i=1

where F is a set of features that satisfies any overall feature composition requirements and
includes features in the full feature set, S, that contains all features of the system-to-be (i.e.,
F ⊆ S).

6.2.3

Requirements-Based Formalization of Feature Interactions

A feature can be defined by its pre-conditions, implementation, and post-conditions [16].
Since the implementation is unknown (i.e., an unimplemented requirement) but assumed
to fulfill the specification (i.e., pre- and post-conditions), each feature Fi , where Fi ∈ F
79

satisfies a property (i.e., φi ), measured as a post-condition such that when the pre-condition
is satisfied we expect the post-condition to be satisfied. For a given feature Fi , where Fi ∈ F :

Pi =⇒ Ri ,

(6.3)

where Pi is the precondition for feature Fi , P is the set of all pre-conditions for the system under development (i.e., the system-to-be), Ri is the post-condition for feature Fi , and
R is the set of post-conditions. Since we are performing our analysis at the requirements
level (rather than implementation), we reason about feature implementation indirectly by
assuming that if the pre-conditions are satisfied, then the feature is satisfied. If the feature
is satisfied, then the post-conditions of the feature must be satisfied unless there is a conflict
between the post-conditions (i.e., a feature interaction between any possible implementations of the features that fulfills the specification). Therefore, the composition of features
(conjunction of pre-conditions) fulfills their properties (conjunction of post-conditions) when
no feature interaction exists:

|F |

^

|F |

(Pi ) =⇒

i=1

^

(Ri ).

(6.4)

i=1

We detect feature interactions when the properties (conjunction of post-conditions) are
not met since no implementation could possibly satisfy conflicting post-condition specifications, leaving at least one feature post-condition unsatisfied. As such, the complement of
Equation 6.4 used to detection feature interactions is as follows:

|F |

^

|F |

(Pi ) ∧ 

i=1

^

(Ri ).

(6.5)

i=1

That is not to say that Equation 6.5 is identical to Equation 6.2. Equation 6.2 defines
a feature interaction where the implementation of a feature is specified (e.g., FI in code),
while Equation 6.5 defines a feature interaction given a specification and assuming an imple80

mentation (e.g., FI in requirements). While Equation 6.2 may detect a feature interaction
between two implementations, Equation 6.5 would detect conflicting specifications.

6.2.4

Phorcys Feature Interaction Causes

Features in Phorcys are specified as a collection of pre-conditions (P ) and post-conditions
(R) for each feature in the set of features (F ). The composition of features and their decomposed components is parallel. Sequential composition and temporal properties are not
considered. When pre-conditions (P ) are satisfied, the presumed implementation is expected
to satisfy the post-conditions (R) (i.e., Equation 6.3) representing the properties (φ). We
define a feature interaction in the Phorcys process to be a parallel composition of features
where one feature (Fcause ) causes the interaction by not satisfying its respective property
(φcause ) assessed by its post-condition (Rcause ). The cause is individually effected such that
it causes the system as a whole (i.e., the root goal) to be unsatisfied. That is:
• We consider a feature to be satisfied if its pre-conditions are satisfied (i.e., the feature
would be executed in an implemented system),
• We expected the properties of a feature, as measured by the post-conditions, to be
satisfied when the feature would be executed in an implemented system (i.e., the preconditions are satisfied), and
• When the post-conditions cannot be satisfied due to a conflict with other postconditions (i.e., two or more features are specified to fulfill conflicting properties) we
consider a feature interaction to have occurred.
In logical terms, we define Expression 6.6 as a feature interaction for some set of features,
F , such that the features in F satisfy the compositional requirements of the system (e.g.,
the features in F satisfy the top-level goal in a goal model) and Fcause ∈ F :
|F |

^

(Pi ) ∧ Rcause .

i=1

81

(6.6)

Equation 6.6 is based on the formal definition for n-way feature interaction detection in
Equation 6.5; however, instead of detecting unsatisfied post-conditions in any feature (i.e.,
ÂŹ

V|F |

i=1 (Ri )),

Equation 6.6 identifies unsatisfied post-conditions in a single feature under

analysis (i.e., ÂŹRcause ) as the feature interaction cause.

6.3

Proofs of Soundness and Completeness

The feature interaction detection logic defined in the Phorcys process is functionally
equivalent to existing definitions that do not explicitly detect the cause of the feature interaction (i.e., Equation 6.5). We assume a subset of features that satisfies the compositional
requirements of the system. In the case of Phorcys, the subset of features is defined by the
goal model decomposition of the features.
The reasoning behind completeness (i.e., no missing interactions) and soundness (i.e., no
superfluous interactions detected) is straightforward. Given definitions for feature interaction
detection in Equation 6.5 and Equation 6.6, for Phorcys feature interaction detection, a
single post-condition is both necessary and sufficient to cause the entire conjunction of postconditions to be unsatisfied in the presence of a satisfied set of pre-conditions that are
assumed to satisfy their properties (i.e., post-conditions), unless otherwise constrained. The
proofs of completeness and soundness prove a single post-condition is both necessary and
sufficient to be true.

Completeness Theorem
For the purposes of feature interaction detection, completeness is defined such that every
feature interaction that is detected via existing methods (i.e., Equation 6.5) is detected via
the Phorcys method (i.e., Equation 6.6). Therefore, if Phorcys feature interaction detection
is complete, any feature interaction detected in Equation 6.5 implies a feature interaction is
detected in Equation 6.6:
82



|F |

|F |

^

^



(Pi ) ∧ 

i=1





|F |

(Ri ) ⇒ 

^

i=1



(Pi ) ∧ Rcause .

(6.7)

i=1

The completeness proof below shows that in any case where a feature interaction is
detected (i.e., the logical conjunction of post-conditions of some set of features are not
satisfied) then at least one of the features must be the cause of the interaction (i.e., at least
one of the post-conditions must not be satisfied).

Proof. A proof by contradiction will be used. We assume the completeness equation in Equation 6.7 is false. That is:


|F |

|F |



^

^

(Pi ) ∧ 

i=1





|F |

(Ri ) ⇒ 

^



(Pi ) ∧ Rcause .

(6.8)

i=1

i=1

Applying logical simplification and converting implications to their logical structures
yields:



|F |

|F |

^

^

(Pi ) ∧ 

i=1







|F |

(Ri ) ∧ 

^

(Pi ) ∨ Rcause .

(6.9)

i=1

i=1

i.) In the case where Rcause is false, ‘¬

V|F |

i=1 (Pi )’

and ‘

V|F |

must both be true,

V|F |

must also be true.

i=1 (Pi )’

which is a contradiction. Therefore Rcause cannot be false.
ii.) In the case where Rcause is true, ‘

V|F |

i=1 (Pi )’

and ‘¬

i=1 (Ri )’

Given the assumption that each feature satisfies its property unless otherwise constrained
(Pi =⇒ Ri for every Fi ∈ F due to Equation 6.3) there must exist a Rcause that is not true
for ‘¬

V|F |

i=1 (Ri )’

to be true. Therefore Rcause cannot be true for all features if ‘¬

V|F |

i=1 (Ri )’

is

true.
Since Rcause cannot be false and it cannot be true for all features when a FI is detected
(e.g., ÂŹ

V|F |

i=1 (Ri )),

then Phorcys cannot be incomplete.
83

Soundness Theorem
For the purposes of feature interaction detection, soundness is defined such that every
feature interaction that is detected via the Phorcys method is also detected using existing
methods (i.e., Equation 6.5). Therefore, if Phorcys feature interaction detection is sound,
any feature interaction detected in Equation 6.6 implies a feature interaction is detected in
Equation 6.5:







|F |

|F |

(Pi ) ∧ ¬Rcause  ⇒ 

^

^

|F |

^


i=1

(Pi ) ∧ 

i=1



(Ri ).

(6.10)

i=1

The soundness proof below shows that in any case where at least one of the features
is the cause of a feature interaction (i.e., at least one of the post-conditions must not be
satisfied) then a feature interaction must also be detected (i.e., the logical conjunction of
post-conditions of some set of features are not satisfied).

Proof. A proof by contradiction will be used. We assume the soundness equation in Equation
6.10 is false. That is:


|F |



^





|F |

|F |

(Pi ) ∧ ¬Rcause  ⇒ 

^

^

(Pi ) ∧ 

(Ri ).

(6.11)

i=1

i=1

i=1



Applying logical simplification and converting implications to their logical structures
yields:




|F |

^




(Pi ) ∧ Rcause  ∧ 

i=1

i.) In the case where

|F |

^

^

(Pi ) ∨

i=1

V|F |

i=1 (Ri )

is false, ‘¬

V|F |

which is a contradiction. Therefore ‘
ii.) In the case where

|F |

V|F |

i=1 (Ri )’

i=1 (Ri )

V|F |

i=1 (Pi )’



(Ri ).

(6.12)

i=1

and ‘

V|F |

i=1 (Pi )’

must both be true,

cannot be false.

is true, ‘
84

V|F |

i=1 (Pi )’

and ‘¬Rcause ’ must also be true.

Since Rcause ∈ R and

0

V|F |

i=1 (Ri )’

are both satisfied it is not possible for expression ÂŹRcause to

be true.
Since

V|F |

i=1 (Ri )

cannot be false and true at the same time, then Phorcys cannot be

unsound.

Given the proofs of both soundness and completeness, it is true that the Phorcys feature interaction cause detection is equivalent (i.e., is capable of detecting the same feature
interactions) to feature interaction detection with the addition of explicitly identifying the
cause of the interaction.

6.4

Goal-Based Modeling of Features

This section details the Phorcys approach to modeling features within goal models. This
section includes our annotations for features, pre- and post-conditions, as well as an example
braking system goal model that is used throughout the remainder of the dissertation.

6.4.1

Features

Goal Models [87] are notationally extended in this work to include the concept of features. While a goal model defines the system-to-be [48], we add an additional notation, ‘(f),’
to denote specific goals and their decompositions representing features within the system.
For example, the braking system goal model in Figure 6.1, goals B, C, D, and E are annotated
with an (f) as high-level goals for four different features. While the additional notation to
identify features adds information about the system-to-be, it does not change the underlying
semantics of a goal model. Any standard goal model can be annotated to identify features,
or used as a standard goal model without the additional annotation.
85

6.4.2

Pre- and Post-Conditions

In this work, we use expectations to define the expected environmental properties that
exist before and after the fulfillment of a requirement. Since elements of the system are used
to satisfy a requirement, the element performs some action that causes an observable effect.
The expression of these changes is measurable via elements in the environment, and are
therefore specified as expectations. We differentiate between expectations of the environment
before the requirement’s satisfaction, or pre-conditions, and those that are expressed after
the requirement satisfaction, or post-conditions. The use of expectations in this manner is
similar to awareness requirements that document domain assumptions [81, 83] and expectations in KAOS goal modeling [87]. Pre- and post-conditions are explicitly included only when
necessary to ensure satisfaction of the unique constraints of a requirement, and are shared
amongst AND-decomposed siblings. We distinguish these expectations in goal models by
the annotations ‘(pre)’ and ‘(post)’, respectively. For example, in Figure 6.1, expectations
B.3 and B.1 are annotated as pre- and post-conditions, respectively. The pre-condition B.3
ensures only positive brake forces can be applied via requirement B.2. Similarly, the postcondition B.1 indicates that after requirement B.2 has been satisfied, the standard brake
force (SF ) is equal to the commanded brake force (CBF ). Expectations may expect properties that are changed by the actions of the agent responsible for a requirement. For example,
an expectation may be that a car must be in Park to allow a gear shift via a requirement from
Park to Drive. However, after the requirement (shift from Park to Drive), the expectation
is no longer satisfied. Just as an expectation may be expected before a requirement, it may
be expected after as well. For example, another expectation may be that the car must be
in Drive after having shifted from Park to Drive. One expectation is measured before the
requirement, and one after. These expectations do not necessarily conflict if one measures the
state of the car’s transmission now, and one measures state of the car’s transmission later.
Similar to the feature annotation, this annotation provides additional information about the
86

system-to-be that could be applied to any goal model or removed from an annotated goal
model without consequence on standard goal model semantics.

6.4.3

Braking System Goal Model Example

The goal model in Figure 6.1 represents an automotive braking system with several
features. In general, a feature reads the actual brake pedal position and relates that information to a commanded brake force that is translated to an external braking force via a
braking mechanism. However, for this system, the braking system has been developed as
four individual features (i.e., B, C, D, E) rather than as a single, monolithic system. The use
of multiple brake features is based on a known 2010 Toyota Prius braking system issue [29].
The braking system features defined here have been independently developed without respect for each other and is intended to be a realistic example of industrial design artifacts at
the requirements level, based on our collaboration with automotive industrial practitioners.3
Specific ratios used in the braking system goal model are commonly included in high-level
specifications regarding input and output limitations of line-replaceable components that
interface with the system under development.
The features included are standard force braking, regenerative braking, continuous braking, and anti-lock brakes, where the target vehicle is a hybrid (i.e., contains both an electric
motor and gas engine). Acronyms used are: PBF (Previous Brake Force), CBF (Commanded
Brake Force), SS (Slip Sensor), RF (Regenerative Brake Force), SF (Standard Brake Force),
and BF (Brake Force). Each of these features was specified without specific regard for the
other features, and operates as described below.
Feature B: ‘Achieve(Standard Force Braking)’ applies (via B.2) a brake force through
standard force brake methods (e.g., disk brakes on the wheels) based on a commanded brake
force using the Hydraulic Brake Actuator .
Feature C: ‘Achieve(Regen Braking)’ applies a brake force using both standard brake
3

Collaboration with automotive industrial practitioners included reviewing our goal modeling approach
to automotive systems, however the specific braking system presented here was not explicitly reviewed.

87

A
Maintain(Brake
System)
AND

A.1
Maintain(Brake
Force)

A.2
Maintain(Brake
Command)

OR

B (f)
Achieve(Standard
Force Braking)

OR

E (f)
Achieve(Continuous
Braking)

C (f)
Achieve(Regen
Braking)

AND

AND

AND

B.1 (post)
SF = CBF

B.2
Achieve(Apply
Standard Force)

E.2
Achieve(Read
CBF)

B.3 (pre)
CBF > 0
C.1 (pre)
CBF > 0

C.2
Achieve(Regen
& Standard Force)

E.4
Achieve(Read
Brake Force)

E.3 (post)
CBF = BF

OR

C.3
Achieve(
Standard Force)

C.8 (pre)
CBF < 50
C.5 (post)
SF = 0.2 * CBF

C.6
Achieve(Apply
Standard Force)

C.4
Achieve(Regen
Force)

E.5 (pre)
BF > 0

AND

C.9
Achieve(Apply
Regen Force)

C.10 (post)
RF = 0.8 * CBF

D.5
Achieve(Brake
Pulse)

C.7 (pre)
CBF > 20
D.2
Achieve(Read
CBF)

E.7
Achieve(
Read SS)

D (f)
Achieve(AntiLock Braking)

AND

AND

E.6 (pre)
SS = false

D.6 (pre)
SS = true

OR

D.3 (pre)
BF > 0

D.4
Achieve(Read
Brake Force)

D.8
Achieve(Brake
On)

D.9
Achieve(Brake
Off)

AND

D.10 (pre)
PBF = 0

D.11 (post)
CBF = BF

D.7
Achieve(Read
Slip Sensor)

D.12
Achieve(Brake
Force Change)

AND

D.13 (post)
CBF = 0

D.14 (pre)
PBF > 0

Figure 6.1: Braking System Goal Model
force methods (via C.3) as well as regenerative braking methods (via C.4) that help capture
electrical energy from braking. Due to limitations in the amount of braking force that regenerative braking may provide, three combinations are used for braking: regenerative force is
used alone for low-braking force needs; a combination of both is used when a mid-range braking force is needed; and standard braking force is used when a large amount of braking force is
needed. In all cases, the amount of braking force is dependent on the commanded brake force
and is applied using the Hydraulic Brake Actuator and/or the Regeneration Brake Actuator ,
depending on the Commanded Brake Force value.
Feature D:

‘Achieve(Anti-Lock Braking)’ reads the current brake force from the

Brake Pedal Sensor (D.4) and alternates applying it to the Commanded Brake Force (D.8)
or applying no commanded brake force (D.9) when the Slip Sensor detects slippage of the
wheels on the driving surface (D.6 and D.7).
Feature E: ‘Achieve(Continuous Braking)’ reads (E.4) the current brake force from
88

the Brake Pedal Sensor and applies it to the Commanded Brake Force (E.2) when the
Slip Sensor does not detect any slippage (E.7).
These features either command the brake force (e.g., D, E) or physically apply the brake
force (e.g., B, C). In order to satisfy the top-level braking goal (A), there must be a commanded
and applied brake force. Features D and E are mutually exclusive due to pre-conditions
E.6 (SS = false) and D.6 (SS = true), since both E.6 and D.6 cannot both be satisfied
simultaneously. Therefore, due to the AND decomposition of both goal D and goal E, if
either pre-condition D.6 or E.6 is unsatisfied, then the entire feature is inactive. The set of
features that satisfies the top-level goal is captured via the decompositions in goals A, A.1,
and A.2.

6.5

Approach

Phorcys is a method for symbolically analyzing a goal model for n-way feature interactions that cause a conflict in the way requirements satisfy their specifications as defined by
their respective pre- and post-conditions. The equations limit symbolically instantiated goal
models to concrete instances that contain feature interactions. These counterexamples are
generated for each feature that can cause an interaction.

6.5.1

FI Detection Process

Figure 6.2 overviews the Phorcys process with a DFD. As shown in Step 1 of Figure 6.2,
Phorcys accepts a goal model defined in its entirety by the system designer (including feature
and pre- and post-condition annotations), such as the one in Figure 6.1. Step 2 analyzes each
feature to determine if each feature can cause a feature interaction. The Phorcys output from
Step 3, contains the features that cause an interaction along with affected features, as well
as the concrete values of the variables in the system. Next, we describe each of the steps in
the DFD in turn.
89

Goals

Goal Model

(1)
Generate
FI Detection
Logic
SMT2
Expressions

Refined
Goal Model

SMT Solver
System
Designer

Satisfiability
Results

(2)
Process Logical
Expressions

Feature
Interactions
& Causes

Process Key:
Process
Flow
External I/O
File

Logical
Expressions

Feature
Interactions
& Causes

Counter
Examples

Feature
Interactions
& Causes

(3)
Counterexample
Summary

Figure 6.2: Phorcys Data Flow Diagram
Step (1): Generate FI Detection Logic
Phorcys feature interaction causes are detected based on generated logical expressions
for each feature represented in the goal model provided by the system designer. The logical
expressions are generated from the pre- and post-conditions in the goal model that are
satisfied when a goal model instance is both i) valid and ii) contains properties of a feature
interaction as defined within this step. The specific goal model instances are created by
symbolically analyzing the logical expressions.
i) Valid Goal Configurations: Phorcys limits the allowable feature sets to those that
satisfy the top level goal. For example, given the goal model in Figure 6.1, the pre-conditions
of features that, when combined, satisfy goal A define the allowable feature sets:

(PB ∨ PC ) ∧ (PD ∨ PE ),

(6.13)

where PB , PC , PD , and PE represent the sets of pre-conditions that refer to conditions that
should be true before realization of features B, C, D, E. For example, PB = B.3 = (CBF > 0),
90

since the only pre-condition in feature B is B.3. Figure 6.3 shows all possible goal configurations represented at the feature level for the braking system, where shading is used to denote
satisfied goals.
A

1.)

A

2.)
AND

A.1

A.2

OR

A

3.)
AND

A.1
OR

OR

AND

A.2

A.1
OR

OR

A.2
OR

B

C

D

E

B

C

D

E

B

C

D

E

...

...

...

...

...

...

...

...

...

...

...

...

A

4.)

A.1

A.2

OR

A

5.)

AND

A.1
OR

OR

A

6.)

AND

A.2

AND

A.1
OR

OR

A.2
OR

B

C

D

E

B

C

D

E

B

C

D

E

...

...

...

...

...

...

...

...

...

...

...

...

A

7.)

A

8.)
AND

A.1

A.2

OR

A

9.)
AND

A.1
OR

OR

AND

A.2

A.1
OR

OR

A.2
OR

B

C

D

E

B

C

D

E

B

C

D

E

...

...

...

...

...

...

...

...

...

...

...

...

Satisfiability Key:
Satisfied
Not Satisfied

Figure 6.3: Goal Configurations that Satisfy Top-Level Goal
It is important to note that while all the goal configurations shown in Figure 6.3 would
satisfy the top level goal (i.e., goal A) at a feature level, not all of those goal configurations
are valid and would satisfy Equation 6.13. For example, a goal model configuration with
both E.6 and D.6 cannot be feasible since E.6, SS = false while D.6, SS = true, and
expression (SS = false) ∧ (SS = true) cannot be satisfied. This means that in Figure 6.3,
goal configurations that have both D and E satisfied simultaneously are not valid (i.e., goal
91

configurations 7, 8, and 9). For example, goal configuration 2 in Figure 6.3 must be fully
satisfied as shown in Figure 6.4.
A
AND

A.1

A.2

OR

OR

D

C

B

E

AND

AND

E.2
B.1

B.2

B.3

C.1

C.3

C.2

E.6

E.3

C.4

E.7

E.5

E.4

AND

C.5

C.6

C.7

C.8

C.10

C.9

D.5

AND D.7
D.6

D.4
D.2

OR

D.3
D.8

D.9
AND

Satisfiability Key:
Satisfied
Not Satisfied

D.10 D.11 D.12 D.13 D.14

Figure 6.4: Goal Configuration 2 in Figure 6.3
ii) Feature Interaction Properties: Feature interactions are only detected in goal
configurations where the top-level goal would be satisfied if it were not for the interaction.
For example, when analyzing feature B as the cause (i.e., Fcause with post-condition Rcause )
only goal configurations 2, 3, 5, 6, 8, and 9 in Figure 6.3 are applicable. For the detection
analysis, the potential causing feature (e.g., B) is then constrained to satisfy its pre-condition
expectations (e.g., B.3) while not satisfying its post-condition expectations (e.g., ÂŹB.1).
For example, feature B is evaluated for satisfaction of Expression 6.14 that is derived from
Expression 6.6, an example of a feature interaction property:
|F |

^

(Pi ) ∧ RB ,

i=1

92

(6.14)

where F can be any of the sets of features that satisfy Equation 6.13 and include the feature
under analysis (i.e., at least feature B and one of feature D or E). That is, the causing
feature (i.e., B) would be satisfied (i.e., implemented to the specification) if it were not
for the presence of the other features in the set. Given a feature interaction analysis for
feature B as the cause, the possible sets of features that satisfy the top-level goal and satisfy
their pre-conditions (i.e., Equation 6.13) are: {B, E}, {B, C, E}, {B, D}, {B, C, D}. Feature sets
that do not include feature B cannot have feature B as a feature interaction cause, and
we already know that feature D and feature E are mutually exclusive. In order to detect a
feature interaction, the set of features must constrain the possible implementations of feature
B such that feature B cannot be implemented according to its specifications. Importantly,
for each feature’s pre-condition (Pi ) that is satisfied, the post-condition (Ri ) is satisfied
unless otherwise constrained (i.e., Equation 6.3) For example, the pre- and post-conditions
for feature set {B, E} are:

PB = (CBF > 0)

(6.15)

PE = (SS = false) ∧ (BF > 0)

(6.16)

RB = (SF = CBF)

(6.17)

RE = (CBF = BF).

(6.18)

In order for Equation 6.14 to detect a feature interaction caused by feature B given the
feature set of {B, E}, three conditions must be satisfied. First, the pre-conditions of both
features (i.e., PB and PE ) must be satisfied. Second, the properties (post-conditions) of the
features with satisfied pre-conditions must be satisfied (i.e., RB and RE ), unless otherwise
constrained by another expectation (i.e., pre- or post-condition). Finally, the feature under
analysis as the cause (i.e., feature B) must violate its properties (i.e., ÂŹRB ) due to the preor post-condition of another feature in the feature set. However, since SF is not constrained
93

by any other pre- or post-condition, then feature B cannot be a feature interaction cause
given the feature set {B, E}. In summary, for feature set {B, E} with feature B under analysis,
the following equation representing the feature interaction properties must be satisfiable to
detect a feature interaction caused by feature B:

(PB ∧ PE ) ∧ RB ,

(6.19)

where both RB and RE must also be satisfied, unless constrained by any other pre- or postcondition (i.e., elements of P , and R, respectively).
However, in the case of {B, C, E}, the pre- and post-conditions are:

PB = (CBF > 0)

(6.20)

PC = ((CBF > 0) ∧ ((CBF > 20) ∨ (CBF < 50))

(6.21)

PE = (SS = false) ∧ (BF > 0)

(6.22)

RB = (SF = CBF)

(6.23)

RC = (SF = 0.2 ∗ CBF) ∨ (RF = 0.8 ∗ CBF)

(6.24)

RE = (CBF = BF).

(6.25)

In order for Equation 6.14 to detect a feature interaction caused by feature B given the
feature set of {B, C, E}, three conditions must be satisfied. First, the pre-conditions of both
features (i.e., PB , PC , and PE ) must be satisfied. Second, the properties (post-conditions) of the
features with satisfied pre-conditions must be satisfied (i.e., RB , RC , and RE ), unless otherwise
constrained by another expectation (i.e., pre- or post-condition). Finally, the feature under
analysis as the cause (i.e., feature B) must violate its properties (i.e., ÂŹRB ) due to the pre- or
post-condition of another feature in the feature set. Unlike the set {B, E}, in the set {B, C, E}
the variable SF is constrained by both RB and RC .
94

Importantly, in order for a post-condition to violate its properties due to another preor post-condition, several things must be true. That is, a post-condition must fail due to
the constraint imposed by another pre- or post-condition where 1) the variables have all
been constrained by another pre- or post-condition and 2) the pre- and post-conditions
contribute (or would contribute if not for the FI) to the satisfaction of the top level goal. This
necessitates that the pre- and post-conditions are decomposed from a satisfied parent, applied
recursively until the top-level goal is satisfied (i.e., each parent is either decomposed from
another satisfied parent or is the top-level goal). Similarly, the variables must be constrained
by variables that are either similarly constrained or initialized by reading the variables from
the environment (e.g., in requirements E.2, E.4, E.7, D.2, D.4, and D.7) where those preor post-conditions or requirements also contribute to the satisfaction of the top level goal.

Figure 6.5 identifies one possible configuration of satisfied goals that could lead to the
violation of feature B’s post-condition. It is important to note that the pre-condition expression (i.e., PC ) for feature C is satisfied, despite the satisfaction of only one of its decomposed
goals (i.e., goal C.3). Further, since each pre- and post-condition must contribute to the
satisfaction of the top-level goal, the pre- and post-condition expressions for feature C (i.e.,
PC and PC , respectively) must be satisfied by expectations C.5 and C.7, C.8 and C.10, or
both due to their respective decompositions from goals C.3 and C.4. The post-condition for
feature B (i.e., B.1) is unsatisfied due to the conflict between itself and post-condition C.9.
Post-condition B.1 is exempt from contributing to the top-level goal due to its violation from
another pre- or post-condition, an exemption which is applicable to any post-condition, not
just those within the feature under analysis.

Specific values identified by Phorcys when analyzing feature B are presented in the
feature interaction detection examples section (Section 6.6). The analysis logic presented
here is generated for each feature.
95

A
AND

A.1

A.2

OR

OR

D

C

B

E

AND

AND

E.2
B.1

B.2

B.3

C.1

C.3

C.2

E.6

E.3

C.4

E.7

E.5

E.4

AND

C.5

C.6

C.7

C.8

C.10

C.9

D.5
D.4

D.2

AND D.7
D.6
OR

D.3
D.8

D.9
AND

Satisfiability Key:
Satisfied
Not Satisfied

D.10 D.11 D.12 D.13 D.14

Figure 6.5: Feature Interaction in Goal Configuration Set {B, C, E}
Step (2): Process Logical Expressions
The logical expressions defined by the process in Step 1, of the DFD in Figure 6.2
are translated into SMT v.2 [12] for analysis by a Satisfiability Modulo Theories (SMT)
solver. SMT solvers follow the SMT-LIB [76] or SMT-LIB v.2 [12] standards to determine
the satisfiability or validity of defined constraints [27]. In this work, we make use of the
Microsoft Z3 SMT Solver [32].
For each feature, the valid goal configurations and feature interaction properties (i.e.,
the conjunction of Equations 6.13 and 6.14) specific for the feature under analysis are submitted to the SMT solver, and counterexamples are returned after processing the logical
expressions. Therefore, a maximum of one counterexample is detected for each feature that
acts as the cause of a feature interaction. If a conflict is detected, then it is added to the set
of counterexamples to be summarized in Step 3.
96

Step (3): Counterexample Summary
For each feature that causes an interaction, the following information is summarized
from the counterexample:
• The feature that caused the interaction,
• The set of features involved in the interaction, and
• The values of the instantiated variables.
Importantly, the features satisfied in the goal model may not be necessary for the feature
interaction to occur but they are sufficient for the interaction to occur. There is no guarantee
of minimal sets of features that cause an interaction, however the feature that causes an
interaction is identified. Summarized counterexamples are stored for review by the system
designer.

Update Goal Model by System Designer
The summarized counterexamples are intended to be used by the system designer to
revise the input goal model. The root cause of a feature interaction may include one or more
of the following incomplete list of possible problems:
• Incorrect pre- or post-conditions for a requirement,
• Incorrect decomposition of goals that do not meet desired requirements specification,
or
• Incorrect decomposition of goals that indicate incorrect requirements specification.
The features identified as the cause of a feature interaction may be revised by: modifying the
requirement and/or its associated pre- and post-conditions, or revising the decomposition
of the goal model to restrict the feature interaction from occurring. Additional means of
mitigating feature interactions are outside the scope of this chapter. A revised goal model
97

may then be analyzed again by Phorcys to detect newly introduced or remaining feature
interactions.

6.5.2

Assumptions and Limitations

While a goal model, or its collection of pre-conditions, can be verified for satisfiability
in a specific case by checking each expectation, identifying a specific satisfiable case is not
always as computationally tractable. Using expectations (e.g., pre-conditions), a goal model
is capable of representing a conjunction of disjunctions over variables to represent any instance of 3-SAT. Due to this reduction, the properties of 3-SAT also apply to goal model
satisfaction in the expectations. Given that 3-SAT is an NP-Complete problem [62], goal
model satisfiability is as well. Further, based on the exponential time hypothesis [57], such a
problem is hypothesized not to be solvable in sub-exponential time in the worst case. Given
the exponential nature of the feature interaction problem, this worst case is not unexpected.
In fact, previous methods of n-way feature interaction detection using satisfiability have
also been exponential in the worst case [9]. In general, reliably detecting n-way interactions
requires exponential enumeration of possible interactions [5]. As such, Phorcys is no worse
than existing feature interaction detection techniques in the worst case. However, the worst
case is dependent on the system defined. Other hierarchically decomposed models, such as
feature models, have been shown to typically be computationally inexpensive to symbolically
analyze for realistic systems [68].
Similar to other feature interaction detection methods [41], Phorcys only analyzes a
single step in time for feature interactions. This strategy may allow for unguarded, but still
unreachable states to be detected as feature interactions. Similarly, cyclical or sequential
changes, such as over and under shooting for a desired state, are undetectable as feature
interactions even if the cycling is caused by competing features.
98

6.6

Examples

This section describes the results from applying Phorcys to the braking system goal
model in Figure 6.1. Phorcys is used to illustrate two different types of feature interaction
scenarios, involving more than two features: incorrect requirements and a typographical error,
both of which could be extremely difficult to detect and identify using traditional testing
techniques if these errors were propagated to program code.

6.6.1

Specification Error Causes

The braking system defined in Figure 6.1 identifies two potential sources for driving
brake commands (features D and E) that provide the inputs to two methods of physically
applying the brakes (features B and C). This initial braking system model is referred to as
M . Table 6.1 provides the results of applying Phorcys to each of the features (B, C, D, and
E) in goal model M to determine if any are the cause of a feature interaction.
Table 6.1: FI Causes in Goal Model M
Set of Features
{B, C, E}
{B, C, E}
N/A
N/A

Feature Under Analysis
B
C
D
E

Causes FI
Yes
Yes
No
No

After analysis, both features B and C are shown to cause a feature interaction. In both
cases, the full set of features involved in the interaction are features B, C, and E, as shown in
the ‘Set of Features’ column that identifies the features involved in the interaction.

Analyzing Feature B as Cause
The values of the variables in the goal model counterexample are shown in Table 6.2.
Figure 6.6 illustrates the applicable parts of the goal model (at the feature level) for the
3-way feature interaction caused by feature B where the red text (SF = ?) indicates the
99

conflict detected. (The set of features represented in Figure 6.6 is goal configuration 6 in
Figure 6.3). The brake force (BF = 21.0) is provided externally by the driver pressing on the
brake pedal. This value is read via the ‘Brake Pedal Sensor’ and converted to a commanded
brake force (CBF = 21.0) by feature D. The features that apply the brake force, B and C, read
this commanded brake force (CBF ) from memory and use it to apply external brake forces.
Feature B applies, via B.2, the entire commanded brake force to standard braking force
(SF = 21.0) (e.g., drum or disk brakes on the wheels). Feature C applies a portion (defined
by C.5) of the commanded brake force to the standard braking force (SF = 4.2) and a
portion (defined by C.10) to the regenerative braking force (RF = 16.8). The interaction
occurs due to the conflict where features B and C attempt to set SF to different values, clearly
SF = 21.0 ∧ SF = 4.2 cannot be true simultaneously. Phorcys, in two separate analysis runs,
is able to identify that both B or C can act as the cause of the interaction.
Table 6.2: Variables for Cause B Counterexample in Goal Model M
Variable
SF
CBF
PBF
RF
BF
SS

Value
21.0/5.0 = 4.2
21
0.0
84.0/5.0 = 16.8
21.0
true

Analyzing Feature C as Cause
A counterexample with a similar type of cause as the interaction caused by feature B:
a conflict between B and C attempting to set SF to different values. Since the SMT solver
identifies a different counterexample, the values identified for the goal model variables are
different (as shown in Table 6.3), where feature C is the cause.
The interaction caused by feature C is a three-way feature interaction (i.e., B, C, D)
where two features (i.e., B, C) are performing conflicting actions due to the commands of a
third feature (i.e., D). This unwanted feature interaction is a requirements specification flaw
100

Key:

A
Maintain(Brake
System)

Input
Output
Satisfied
Not Satisfied

AND

A.2
Maintain(Brake
Command)

A.1
Maintain(Brake
Force)
OR

B
Achieve(Standard
Force Braking)
100%
SF=21

SF=?

OR

C
Achieve(Regen
Braking)

E
D
Achieve(Anti- Achieve(Continuous
Braking)
Lock Braking)

20%
SF=4.2

CBF=21

RF=16.8

BF=21

Figure 6.6: 3-Way FI in Figure 6.1 Caused by B or C
Table 6.3: Variables for Cause C Counterexample in Goal Model M
Variable
SF
CBF
PBF
RF
BF
SS

Value
21.0
21.0
0.0
84.0/5.0 = 16.8
21.0
true

(e.g., incorrect requirements) in the specification of the goal model. Two conflicting values
should not be applied to SF . However, it may not be obvious that such an interaction exists
due to a requirements specification flaw when features are developed independently. This
specification flaw was not purposefully injected into the goal model and was not obvious to
the authors when the features were developed independently and without any consideration
for other features.

6.6.2

Modeling Error Introduces FI

One method of handing conflicts due to specification flaws, such as the one that exists
in Figure 6.1, is strengthening the pre-condition expectations for one or both of the causing features. This strategy reduces, or even eliminates, the overlap between features when
101

conflicting goals are satisfied. For example, it may be reasonable to enforce standard force
braking only, as provided by feature B, when the commanded brake force is over 80%. Conversely, C would be applicable under a commanded force of 80%. The reasoning behind such
a change may be related to safety where standard force brakes have known historical failure rates while regenerative braking is a relatively new technology. Standard force braking
(feature B) may be more reliable than a combination of braking methods (feature C) that
include regenerative braking. Therefore, if the commanded brake force is high (greater than
80%) it may be reasonable to assume braking is safety related, thus justifying the use of
only standard brake force using feature B. However, braking forces that are lower (under
80%) may indicate a less safety critical need and justify the electrical power capture from
regenerative braking in feature C.
The system designer adds additional pre-condition expectations to both goals B and
C to remove the interaction. The additional pre-condition expectation for goal B is B.0,
CBF ­ 80.0, and the additional pre-condition expectation for goal C is C.0, CBF  80.0.
This revised goal model is referred to as M 0 .
Phorcys is then used to process the goal model M 0 to identify any remaining or newly
introduced feature interactions. Executing Phorcys shows that features B and C still cause
feature interactions, as shown in Table 6.4.
Table 6.4: FI Causes in Goal Model M 0
Set of Features
{B, C, D}
{B, C, E}
N/A
N/A

Feature Under Analysis
B
C
D
E

Causes FI
Yes
Yes
No
No

Analyzing Feature B as Cause
In the revised goal model, the set of features in the counterexample are B, C, and
D. Despite the pre-condition expectation B.0, an interaction is still caused by feature B.
102

However, as shown in Table 6.5a, CBF is equal to 80.0, exactly the intended cutoff between
features B and C. Importantly, a modeling error (i.e., typo) has been inadvertently introduced
by the system designer while manually updating the goal model that allows features B and
C to overlap due to both expectations including the value 80.0, thus allowing an interaction
to continue to exist when CBF = 80.0.
Similar to the previous interaction causes in model M , the interactions in model M 0 pass
a value from the driver set brake force (BF = 80.0) that is then passed on to the commanded
brake force (CBF = 80.0) via feature D. Just as before, features B and C both attempt to
set the standard brake force (SF ) to differing values (80.0 and 16.0 via expectations B.1
and C.5, respectively). In this case, the additional expectations (B.0 and C.0) only allow
features B and C to occur simultaneously when the commanded brake force (CBF ) is exactly
80.0.

Analyzing Feature C as Cause
The counterexample includes features B, C, and D. As shown in the counterexamples
variable values in Table 6.5b, CBF is equal to 80.0 just as it was when B was the cause.
The difference is which feature sets SF to a value. In the case where feature C is the cause
of the interaction, standard braking force is set to 80.0. In the case where feature B is the
cause, standard braking force is set to 16.0. Thus, the causing feature is the one that is not
satisfied, and thus causes the top-level goal to be unsatisfied, in the presence of the other
feature.
Both of these detected FIs are present in the goal model shown in Figure 6.7, a detailed view of goal configuration 6 from Figure 6.3 representing one of the 9 possible goal
configurations.
Instead of correcting the feature interaction in model M by adding pre-condition expectations to the features that caused the interactions, the M 0 revision allowed for a single point
of overlap between the additional pre-conditions at a commanded brake force of exactly 80.0.
103

Table 6.5: Counterexamples for FIs in Goal Model M 0
Variable
SF
CBF
PBF
RF
BF
SS

Value
16.0
80.0
0.0
65.0
80.0
true

Variable
SF
CBF
PBF
RF
BF
SS

(a) Cause B Variables

(b) Cause C Variables

Key:

A
Maintain(Brake
System)

Input
Output
Satisfied
Not Satisfied

AND

A.2
Maintain(Brake
Command)

A.1
Maintain(Brake
Force)
OR

B
Achieve(Standard
Force Braking)
100%
SF=80

Value
80.0
80.0
−1.0
0.0
80.0
false

OR

C
Achieve(Regen
Braking)

E
D
Achieve(Anti- Achieve(Continuous
Braking)
Lock Braking)

20%
SF=16

CBF=80

SF=?

BF=80

Figure 6.7: 3-Way FI in M 0 Caused by B or C

This form of feature interaction is not a specification error, but rather a modeling error that
is still caught by Phorcys. Again, this error is subtle and difficult to detect with existing
state of practice techniques.

6.6.3

Feature Interaction Free Model

We can mitigate this feature interaction by revising of the pre-conditions of the causing
feature C. Specifically, expectation C.0 is revised to CBF < 80.0 to yield model M 00 . Applying
Phorcys to M 00 detects no further interactions as shown in the results in Table 6.6.
104

Table 6.6: Detected FI Causes in Goal Model M 00

B
C
D
E

6.6.4

Feature
Achieve(Standard Force Braking)
Achieve(Regen Braking)
Achieve(Anti-Lock Braking)
Achieve(Continuous Braking)

Causes FI
No
No
No
No

Discussion

Phorcys is able to detect n-way feature interactions with more than two features and
provide counterexamples to support specification updates. Due to the feature-oriented requirements specification, an initial requirements specification flaw is uncovered in model M
that could produce an unwanted interaction when the features are combined. In the revised
model M 0 , a subsequent modeling error (e.g., typo) was inadvertently introduced by the
system designer leading to a single possible 3-way unwanted interaction. Finally, an updated
model (M 00 ) is shown to be interaction free. All executions were performed on a laptop with
a 1.3 GHz Intel Core i5 processor and 4 GB of 1600 MHz DDR3 RAM in fractions of a
second.

6.7

Related Work

Significant work has been done in the area of representing features as well as detecting,
avoiding, and resolving feature interactions. This section overviews and compares related
work. More comprehensive surveys on feature interaction have been presented elsewhere [4,
5, 20].

6.7.1

Feature Interaction

In general, feature interactions have been addressed by three main categories of techniques: detection, avoidance, and resolution [20], each of which is detailed below.
105

Detection
Typically, the detection of feature interactions focuses on identifying minimal sets of
features that are necessary for a feature interaction to take place [41, 59, 6, 7]. Often, these
methods are limited to pair-wise detection [21, 41], where only interactions between two
features can be detected. For n-way feature interaction detection techniques, these minimal
sets require a potentially exponential number of feature interactions to be detected [7].
Phorcys detects which features can cause an interaction thus providing a linear number of
representative interactions that the system designer must assess (not to be conflated with a
linear run-time). Search-based techniques for discovering latent properties, including feature
interactions, exist, but require manual analysis of discovered properties [52, 60]. Phorcys
differs from existing feature interaction detection methods by combining three key elements:
• it operates at the requirements level,
• it detects n-way feature interactions, and
• it identifies the cause of the interaction.

Avoidance
Feature Interaction avoidance composes features using operators that are conflictfree [55, 58] or makes use of frameworks that ensure separation of potentially conflicting
concerns, eliminating specific classes of feature interactions [86]. Using these methods, the
design and development of features is limited to the operators or frameworks employed.
Detection methods, including Phorcys, could be employed to ensure no unexpected feature
interactions occur due to limitations of the composition operators or frameworks.

Resolution
Feature Interaction resolution is often performed at run-time, and includes techniques
such as prioritization [22] and negotiation [53] between features. Recently, methods to resolve
106

interactions based on the conflicting variables have been presented to reduce the number of
resolutions [17], though dependencies between variables (e.g., speed and acceleration) are
not considered for interactions. This method does not provide guarantees that the resolution
provides desired behavior for the system. Therefore, while resolution at run-time may be
better than allowing a conflict to occur, detecting and removing an interaction at designtime with Phorcys allows for verification of the modified behavior. When resolutions must
be defined at design-time, detection methods like Phorcys can be used to identify which
resolutions are necessary, thus eliminating excess resolutions.

6.7.2

Feature Representation

In this dissertation, we use annotated goal models to represent features, however features
have also been represented as various behavioral models [41], logical representations [21, 9],
or product line models [26, 61]. Often product lines are represented as feature models [59].
While goal modeling, product lines, and feature models are high-level representations of
systems, behavioral and logical specifications necessitate specific implementation details.
Feature models only decompose to the feature level and use cross-tree constraints that are
limited to the feature level [13]. Therefore, feature models can only model conflicts between
entire features and miss requirements-level conflicts that often cause feature interactions [6,
84]. For example, in Figure 6.1, features B and C conflict for only a range of values. The
cross-tree constraints represented in feature models cannot adequately constrain the features
without also constraining non-interacting functionality. The annotated goal models presented
in this dissertation allow features to be decomposed to the requirements level, allowing for
the detection of interactions that occur only in a portion of a feature’s functionality while
allowing for detection before implementation artifacts are created.
107

6.8

Summary

In this chapter, we have presented Phorcys, a design-time approach for detecting unwanted n-way feature interactions and determining their causes at the requirements level.
Unlike previous n-way feature interaction detection approaches that attempt to enumerate
every set of features that interact, Phorcys reduces the effort of the system developer by analyzing each feature for its ability to cause an interaction with other features. The method
we present offers several advantages to reducing the cost of feature interaction detection.
First, Phorcys reduces the computational and system designer effort by detecting interactions at the requirements level rather than implementation specifications. Second, Phorcys
reduces the system designer effort by identifying which features cause an interaction rather
than reviewing a potentially exponential set of interactions. Third, Phorcys reduces the computational effort to detect feature interactions for a subset of feature interaction detection
problems by applying optimized constraint solvers in the form of SMT solvers to feature
interaction detection. We demonstrated Phorcys on a cyber-physical system represented as
a braking system goal model comprised of several features that are composed to realize an
automotive braking system. We show that Phorcys is able to automatically detect the causes
of n-way feature interactions due to specification and modeling flaws in fractions of a second.

108

Chapter 7
Detecting Feature Interactions: Using
Evolutionary Computation

Ensuring acceptable and safe behavior is of paramount importance for high-assurance
systems across the full range of functionality, not just a single scenario. However, detecting
whether each feature can cause of a feature interaction only provides a single counterexample
for each feature. This chapter introduces Phorcys-EC, a design-time approach for detecting
unwanted failures caused by n-way feature interactions at the requirements level using both
symbolic analysis and evolutionary computation to identify multiple counterexamples. Unlike
previous n-way feature interaction detection approaches that look for single features that
cause an interaction, Phorcys-EC uses a combination of symbolic analysis and evolutionary
computation to identify multiple counterexamples for each feature, thus providing more
guidance for mitigation (e.g., revising specifications, adding constraints, etc.). To the best of
the authors’ knowledge, Phorcys-EC is the only technique to detect failures caused by n-way
feature interactions using a combination of symbolic analysis and evolutionary computation.
We illustrate our approach by applying Phorcys-EC to an industry-based automotive braking
system comprising multiple subsystems.
109

7.1

Introduction

This chapter presents Phorcys-EC,1 a method for 1) identifying whether a feature fails
due to a feature interaction and 2) returning a collection of diverse counterexamples across
features and environmental properties using a combination of symbolic analysis and evolutionary computation.
N-way feature interaction detection methods typically detect a potentially exponential number of feature interactions (i.e., O(|F |2 ), where F is the set of features). In order
to address the computational intractability of n-way feature interaction detection, many researchers have focused on pair-wise interactions [10, 21, 41, 59]. While this approach decreases
the number of potential interactions detected to O(|F |2 ), interactions that only emerge when
three or more features are present will not be detected [5]. Methods to detect which features
cause an interaction without “creating all possible feature interactions” [5] have previously
been considered unreliable, but such methods that are sounds and complete are a necessity.
Additionally, a single counterexample may be insufficient
This chapter presents Phorcys-EC, an extension of the symbolic approach Phorcys.
Phorcys-EC detects feature interactions using a combination of symbolic analysis and evolutionary computation. That is, feature interaction counterexamples are identified via a
feature-oriented analysis based on whether a feature can fail due to an interaction. For example, consider 3 features, F1 , F2 , and F3 . If an interaction exists, then at least one feature
(F1 , F2 , or F3 ) no longer operates as it did independently. However, where Phorcys would
provide up to a single counterexample for each feature, Phorcys-EC identifies multiple counterexamples with diverse feature sets and environmental scenarios for each feature.
Phorcys-EC analyzes features represented in goal models that hierarchically decompose
a high-level goal down to individual requirements [87]. Phorcys-EC, using Phorcys, symbolically analyzes each feature with respect to different possible feature combinations of the
goal model and uses a constraint solver to check for the existence of any combination of
1

Phorcys-EC (pronounced ‘forsis’) is the Greek god of hidden dangers in the deep.

110

features (i.e., feature set) where the analyzed feature can fail due to a conflict in one or more
requirements to be satisfied. The initially identified feature interaction counterexample is
used to pre-populate a genetic algorithm that searches for additional diverse counterexamples. Periodically, the symbolic analysis will be re-applied to re-seed the genetic algorithm
during evolution. Where previous n-way feature interaction detection methods may present
an intractably large set of automatically detected interactions that are only diverse across
features (i.e., do not include additional counterexamples with diverse environmental scenarios for a single interacting feature set) for the system designer to assess manually as to what
environmental conditions are necessary for the feature interaction to occur [18, 20], PhorcysEC identifies sets of feature interaction counterexamples for each feature that can fail due to
an interaction. The diverse nature of the counterexamples provides more information (i.e., a
larger range of environmental scenarios and/or a larger set of features) that can be utilized
when revising the requirements and assumptions to mitigate the feature interaction.
The contributions of this chapter are as follows:
• We introduce a new approach for analyzing requirements to detect unintended feature
failures caused by n-way feature interactions using symbolic analysis and evolutionary
computation,
• The new approach can identify multiple counterexamples that represent diverse sets
of features and diverse environmental scenarios for a given feature that can cause a
feature interaction,
• We present Phorcys-EC, a prototype implementation of the approach, and
• We demonstrate the applicability of Phorcys-EC on an industry-based application of
an automotive braking system based in part on the feature interaction issues in the
2010 Toyota Prius [29, 63], a hybrid vehicle. Analysis shows that Phorcys-EC is able
to identify feature failures caused by feature interactions in the braking system goal
model involving two or more features.
111

The remainder of this chapter is organized as follows. Section 7.2 provides background
information on the automotive braking system used for feature interaction analysis in this
chapter. The Phorcys-EC approach, examples, and results are included in Sections 7.3 and
7.4, respectively. Work related to Phorcys-EC is presented in Section 7.5, and our conclusions
are described in Section 7.6.

7.2

Input Model

The goal model in Figure 7.1 represents an automotive braking system with several
features. This model is similar to previous braking system goal models; however it has been
updated such that the variables are mapped appropriately to a range of zero to one to allow
for a more direct application of evolutionary computation in the range of zero to one. This
not only causes some changes to the goal model, but subsequently to the results themselves.
In general, a feature reads the actual brake pedal position and relates that information to a
commanded brake force that is translated to an external braking force via a braking mechanism. However, for this system, the braking system has been developed as four individual
features (i.e., B, C, D, E) rather than as a single, monolithic system. The use of multiple
brake features is based on a known 2010 Toyota Prius braking system issue [29]. The braking system features defined here have been independently developed without consideration
for each other and is intended to be a realistic example of industrial design artifacts at the
requirements level, based on our collaboration with automotive industrial practitioners.2

7.3

Evolutionary Computation Approach

This section presents the Phorcys-EC approach and a comparison of analysis approaches.
2

Collaboration with automotive industrial practitioners included reviewing our goal modeling approach
to automotive systems, however the specific braking system presented here was not explicitly reviewed.

112

A
Maintain(Brake
System)
AND

A.1
Maintain(Brake
Force)

A.2
Maintain(Brake
Command)

OR

B (f)
Achieve(Standard
Force Braking)

OR

E (f)
Achieve(Continuous
Braking)

C (f)
Achieve(Regen
Braking)

AND

AND

AND

B.1 (post)
SF = CBF

B.2
Achieve(Apply
Standard Force)

E.2
Achieve(Read
CBF)

B.3 (pre)
CBF > 0
C.1 (pre)
CBF > 0

C.2
Achieve(Regen
& Standard Force)

E.4
Achieve(Read
Brake Force)

E.3 (post)
CBF = BF

OR

C.3
Achieve(
Standard Force)

C.8 (pre)
CBF < 0.5
C.5 (post)
SF = 0.2 * CBF

C.6
Achieve(Apply
Standard Force)

C.4
Achieve(Regen
Force)

E.5 (pre)
BF > 0

AND

C.9
Achieve(Apply
Regen Force)

C.10 (post)
RF = 0.8 * CBF

D.5
Achieve(Brake
Pulse)

C.7 (pre)
CBF > 0.2
D.2
Achieve(Read
CBF)

E.7
Achieve(
Read SS)

D (f)
Achieve(AntiLock Braking)

AND

AND

E.6 (pre)
SS = false

D.6 (pre)
SS = true

OR

D.3 (pre)
BF > 0

D.4
Achieve(Read
Brake Force)

D.8
Achieve(Brake
On)

D.9
Achieve(Brake
Off)

AND

D.10 (pre)
PBF = 0

D.11 (post)
CBF = BF

D.7
Achieve(Read
Slip Sensor)

D.12
Achieve(Brake
Force Change)

AND

D.13 (post)
CBF = 0

D.14 (pre)
PBF > 0

Figure 7.1: Braking System Goal Model

7.3.1

Phorcys-EC Approach

Figure 7.2 overviews the Phorcys-EC process with a DFD. As shown in Step 1 of Figure 7.2, Phorcys-EC accepts a goal model defined by the system designer (including feature
and pre-/post-condition annotations), such as the one in Figure 7.1. Step 2 analyzes each
feature to determine if a feature can fail due to a feature interaction. The Phorcys-EC output
from Step 3 contains the features that fail due to an interaction along with affected features,
as well as the concrete values of the variables in the system. Next, we describe each of the
steps in the DFD in turn.

Step (1): Generate FI Detection Logic
Features that can fail due to a feature interaction, or the causes of feature interactions,
are detected based on generated logical expressions for each feature represented in the goal
113

Goal Model

Goals

(1)
Generate
FI Detection
Logic
SMT2
Expressions

Refined
Goal Model

SMT Solver

System
Designer

Logical
Expressions

(2)
Process Logical
Expressions

Satisfiability
Results
Counter
Examples

Feature
Interactions
& Causes

Feature
Interactions
& Causes

Feature
Interactions
& Causes

(3)
Counterexample
Summary

Process Key:
Process
Flow
External I/O
File

Figure 7.2: Phorcys-EC Data Flow Diagram

model provided by the system designer. The logical expressions are generated from the preand post-conditions in the goal model that are satisfied when a goal model instance is both
i) valid and ii) contains properties of a feature interaction as defined within this step. The
specific goal model instances are created by symbolically analyzing the logical expressions
(i.e., Equation 6.6).

The feature interaction detection logic generated is identical to that of Phorcys, and is
used for both symbolic analysis and evolutionary computation. Specific values identified by
Phorcys-EC when analyzing feature B are presented in the Examples section (Section 7.4).
The analysis logic is generated for each feature.
114

Step (2): Process Logical Expressions
The logical expressions generated by Phorcys-EC are processed by one of three methods
that are compared in this chapter: Symbolic Analysis (SA), Evolutionary Computation (EC),
or Symbolic Analysis and Evolutionary Computation (SA+EC).
Step (3): Counterexample Summary
For each feature that can fail due to an interaction, the following information is summarized from the counterexample(s):
• The feature that failed due to the interaction,
• The set of features involved in the interaction, and
• The values of the instantiated variables.
Importantly, the features satisfied in the goal model may not be necessary for the feature
interaction to occur but they are sufficient for the interaction to occur. There is no guarantee
of minimal sets of features that cause an interaction, however as the analysis identifies if a
feature can cause a feature interaction (i.e., fail due to a feature interaction) the cause is
intrinsically identified. Summarized counterexamples can be reviewed by the system designer.
Update Goal Model by System Designer
The summarized counterexamples are intended to be used by the system designer to
revise the input goal model. The root cause of a feature interaction may include one or
more of the following incomplete list of possible problems: incorrect pre- or post-conditions
for a requirement; incorrect decomposition of goals that do not meet desired requirements
specification; or indicate incorrect requirements specification.
The features identified as failing due to a feature interaction may be revised by: modifying the requirement and/or its associated pre- and post-conditions or revising the decomposition of the goal model to restrict the feature interaction from occurring. A revised goal
115

model may then be analyzed again by Phorcys-EC to detect newly introduced or remaining
feature interactions.

7.3.2

Comparison of Analysis Approaches

This subsection provides details of three implementations used to analyze the logical
expressions, as shown in Step (2) in the Phorcys-EC DFD in Figure 7.2.

Symbolic Analysis (SA)
As illustrated in Figure 7.3, the symbolic analysis instantiation of Step (2) in Figure 7.2
accepts the logical expressions defined by the process in Step (1). These logical expressions are
translated into SMT version 2 [12] for analysis by a Satisfiability Modulo Theories (SMT)
solver and the results are returned. SMT solvers follow the SMT-LIB [76] or SMT-LIB
version 2 [12] standards to determine the satisfiability or validity of defined constraints [27]
in a diverse range of constraint problems [33]. In this work, we make use of the Microsoft Z3
SMT Solver [32].
Logical
Expressions

SMT2
Expressions

SMT Solver

Satisfiability
Results

(2)
Process Logical
Expressions:
SA
Counter
Examples

Figure 7.3: Phorcys-EC Data Flow Diagram: Step 2, SA

For each feature, the valid goal configurations and feature interaction properties (i.e., the
conjunction of Equations 6.13 and 6.14) specific for the feature under analysis are submitted
116

to the SMT solver, and counterexamples are returned after processing the logical expressions.
Therefore, a maximum of one counterexample is detected for each feature that can fail due to
a feature interaction. If a conflict is detected, then it is added to the set of counterexamples
to be summarized in Step 3.

Evolutionary Computation (EC) Analysis
While symbolic analysis can identify individual counterexamples, EC naturally lends itself to identifying multiple counterexamples (i.e., optimum). The genome itself is represented
by the variables in the logical expressions generated by Phorcys-EC, where each variable in
the expression is represented by a real value.
The EC configuration parameters in this work are based on empirical feedback where
both optimal results and execution time were emphasized. Both analysis approaches using evolutionary computation (i.e., the EC-only analysis approach, as well as the combined
SA+EC analysis approach) make use of a population of 200, a novelty proportionate tournament of size 8 for mating selection, a fitness proportionate tournament of size 4 is used
for survival selection, as well as a 5% mutation rate applied by randomly modifying a single
real-value representing a variable in the genome. Mating is performed by the SBX crossover
operator [35] for each real-value in the individuals selected. Novelty and fitness measures are
based on minimum Manhattan distance [28] of the selected genotype values (e.g., features
included in the feature set or environmental variables) from any other individual and the existence of a failure for the feature under analysis caused by a feature interaction, respectively.
The number of generations is limited to 500. The intention of this genetic algorithm is to
emphasize diversity using both the mating and mutation operators while survival selection
optimizes the results by culling from the diverse individuals.
Therefore, evolutionary computation is used to search for both optimal (i.e., a feature
interaction is detected via the Phorcys-EC generated detection logic) and novel results (e.g.,
counterexamples including diverse sets of features or diverse environmental scenarios). In117

stead of searching for a single counterexample identifying a feature interaction, EC looks for
multiple solutions using the entire population of the genetic algorithm. The expected results
are optimal individuals spread across a range of genotypes.

SA+EC Analysis
While EC can search for multiple solutions with diversity, the following limitations and
problems can occur:
• A single or multiple ‘needle(s) in a haystack’ may exist as the optimum and be prohibitively difficult to find.
• There may be no gradient between optimal and non-optimal results providing no basis
for improvement related to changes in fitness resulting in a degradation to random
search.
• Dependencies between variables may require changes in additional variables to maintain optimality.
Phorcys-EC overcomes these issues by combining symbolic analysis with evolutionary computation. As illustrated in the DFD in Figure 7.4, Phorcys-EC initially and then
periodically performs symbolic analysis to identify a single diverse counterexample. That
symbolically-identified counterexample is used to supply or replace a portion of the genetic
algorithm’s population. In order to select this single diverse counterexample, Phorcys-EC
selects 10 random individuals in the population to create a distance constraint from each
of them during the first half of the generations. If a new and diverse counterexample is
found, then 20 random individuals are replaced with the new counterexample. This process
is performed initially without the existing random chosen individuals and another 4 times
(for a total of 5 symbolic analyses, selected based on empirical feedback), evenly distributed
throughout the first half of the genetic algorithm’s generations.
118

(2)
Process Logical
Expressions:
SA+EC

Logical
Expressions

SMT2
Expressions

Symbolic
Analysis

SMT Solver
Satisfiability
Results

Counterexample,
Logical Expressions

Counterexamples

Genetic
Algorithm

Counter
Examples

Figure 7.4: Phorcys-EC Data Flow Diagram: Step 2, SA+EC

7.4

Evolutionary Computation Case Study

This section provides the results of the Phorcys-EC tool when applied with each of the
three methods of analyzing logical expressions (i.e., Step 2 in the Phorcys-EC DFD in Figure
7.2), as well as a comparison of the three methods.

7.4.1

Symbolic Analysis (SA)

The braking system defined in Figure 7.1 identifies two potential sources for driving
brake commands (features D and E) that provide the inputs to two methods of physically
applying the brakes (features B and C). Table 7.1 provides the results of applying Phorcys-EC
to each of the features (B, C, D, and E) in the goal model to determine if any are the cause
of a feature interaction.
Table 7.1: FI Causes in the Goal Model
Set of Features
{B, C, E}
{B, C, E}
N/A
N/A

Feature Under Analysis
B
C
D
E
119

Fails Due to FI
Yes
Yes
No
No

After analysis, both features B and C are shown to fail due to a feature interaction. In
both cases, the full set of features involved in the interaction are features B, C, and E, as
shown in the ‘Set of Features’ column that identifies the features involved in the interaction.

Analyzing Feature B for Failure Due to FI
The values of the variables in the goal model counterexample are shown in Table 7.2.
Figure 7.5 illustrates the applicable parts of the goal model (at the feature level) for the
3-way feature interaction caused by feature B where the red text (SF = ?) indicates the
conflict detected. (The set of features represented in Figure 7.5 is goal configuration 6 in
Figure 6.3). The brake force (BF = 0.35) is provided externally by the driver pressing on the
brake pedal. This value is read via the ‘Brake Pedal Sensor’ and converted to a commanded
brake force (CBF = 0.35) by feature D. The features that apply the brake force, B and C, read
this commanded brake force (CBF ) from memory and use it to apply external brake forces.
Feature B applies, via B.2, the entire commanded brake force to standard braking force
(SF = 0.35) (e.g., drum or disk brakes on the wheels). Feature C applies a portion (defined
by C.5) of the commanded brake force to the standard braking force (SF = 0.07) and a
portion (defined by C.10) to the regenerative braking force (RF = 0.28). The interaction
occurs due to the conflict where features B and C both attempt to set SF to different values,
clearly SF = 0.35 and SF = 0.07 cannot be true simultaneously. SA, in two separate analysis
runs, is able to identify that both B or C can fail due to the interaction.

Analyzing Feature C for Failure Due to FI
A counterexample with a similar type failure of feature C: a conflict between B and C
attempting to set SF to different values. Since the SMT solver identifies a different counterexample, the values identified for the goal model variables are different (as shown in Table
7.3), where feature C fails due to the interaction.
The interaction caused by feature C is a 3-way feature interaction (i.e., B, C, D) where
120

Key:

A
Maintain(Brake
System)

Input
Output
Satisfied
Not Satisfied

AND

A.2
Maintain(Brake
Command)

A.1
Maintain(Brake
Force)
OR

B
Achieve(Standard
Force Braking)
100%
SF=0.35

OR

C
Achieve(Regen
Braking)

E
D
Achieve(Anti- Achieve(Continuous
Braking)
Lock Braking)

20%
SF=0.07

SF=?

CBF=0.35

RF=0.28

BF=0.35

Figure 7.5: 3-Way FI in Figure 7.1 Caused by B or C

Variable
SF
CBF
PBF
RF
BF
SS

Value
0.07
0.35
0.0
0.28
0.35
true

Variable
SF
CBF
PBF
RF
BF
SS

Table 7.2: Feature B

Value
0.35
0.35
0.0
0.28
0.35
true

Table 7.3: Feature C
Variables for Failure

two features (i.e., B, C) are performing conflicting actions due to the commands of a third
feature (i.e., D). This unwanted feature interaction is a requirements specification flaw (e.g.,
incorrect requirements) in the specification of the goal model. Two conflicting values should
not be applied to SF . However, it may not be obvious that such an interaction exists due
to a requirements specification flaw when features are developed independently of one another. This specification flaw was not purposefully injected into the goal model and was not
obvious to the authors when the features were developed independently and without any
consideration for other features.
121

7.4.2

Evolutionary Computation (EC)

The EC method uses a genetic algorithm to generate variable instantiations for the
logical expressions to detect feature interactions in an effort to address the limitations of
a single counterexample result identified by symbolic analysis. However, EC is unable to
identify a single counterexample, much less a set of counterexamples, within 50 full executions
of the genetic algorithm. Even significantly larger generations (2000) and larger populations
(500) did not lead to success for the genetic algorithm. The most likely reason for the lack
of results is the lack of a fitness gradient (i.e., either 0.0 or 1.0) for the detection of feature
interactions causing the genetic algorithm to function as random search.

7.4.3

SA+EC

SA+EC detected both features B and C as features that can fail due to feature interactions, just as they were identified in the SA-only method. In the cases of features B and
C, the SA+EC method is always able to identify a set of diverse counterexamples. In all 50
executions of the genetic algorithm, at least 97% of the population succeeded in finding a
counterexample (i.e., feature interaction).
Feature Diversity
In the cases of both features B and C, the possible feature sets that are involved in the
interaction are both B and C as well as one of either D or E. All executions of SA+EC, using
feature diversity, identified all possible feature combinations that could provide the feature
interaction that causes the feature under analysis to fail. That is, each of the 50 executions
for both features B and C identified the exhaustive list of possible feature sets.
Environmental Diversity
Regardless of which feature, or features, failed due to the feature interaction, at least
99.9% of the feature interactions identified by SA+EC analysis included unique environmen122

tal variable values. That is, the feature interaction counterexamples identified were almost
always completely unique and every set of counterexamples (i.e., in a population of 200 identified by the SA+EC) included significant diversity as measured by the Manhattan distance
of the environmental scenarios. This diversity is illustrated in Figures 7.6a and 7.6b that
show the range (distance from minimum to maximum) each environmental variable took
across each set of 200 individuals in the SA+EC analysis, where the box plot represents all
50 executions of the SA+EC. It should be noted, that it is expected that some of the ranges
are limited since they represent the ranges of environmental variable values necessary for
feature interactions to cause a feature to fail. In both cases, we can see that SS , PBF , and
RF have a large range of values while the remainder (i.e., BF , SF , and CBF ) are limited due
to the smaller range of those environmental variable values when feature interactions occur.
With just the box plots of the ranges, it is clear that the feature interaction will be related
to the variables BF , SF , and CBF . System designers may infer that the values with a more
restricted range must be within those ranges in order for a feature interaction to occur, while
variables with a larger range are not limited to specific values for a feature interaction to
occur.

7.4.4

Comparison

The SA+EC approach used by Phorcys-EC is preferred over either SA or EC alone.
Though SA can only identify a single counterexample for every feature that can fail due
to a feature interaction, the failure is guaranteed to detect the interactions. This analysis
differs from EC where there is no guarantee that a counterexample will be found even when
one is known to exist. This weakness is especially apparent when the EC approach failed to
detect any of the feature interactions due to the discrete nature of the fitness assessment.
Therefore, while SA is limited to a single counterexample, it provides a guaranteed result
and is the preferred solution when comparing between a SA approach or an EC approach.
However, SA+EC is not only able to identify failures due to feature interactions as consis123

1.0
0.8
0.6
0.4
●

●
●
●
●
●

●

0.6
0.4

●

0.2

0.2

RF

PBF

SS

CBF

BF

RF

PBF

(a) B Failing

SF

0.0

●

SS

●

CBF

SF

●
●

●

BF

0.0

●
●
●
●

0.8

●

Execution Range

Execution Range

1.0

●

(b) C Failing

Figure 7.6: Environmental Variables

tently as SA, but SA+EC also identifies a diverse and unique set of counterexamples. Since
SA+EC uses the SA approach, the guarantees of SA are also the guarantees of SA+EC since
the EC portion is elite preserving and does not remove true counterexamples for anything
but a more diverse true counterexample. Additionally, SA+EC was able to identify an exhaustive list of feature sets that can take part in a feature interaction and over 99.9% of
counterexamples identified were unique. Therefore, SA+EC is preferable to the SA approach
alone as SA+EC includes both the completeness and soundness guarantees of SA, as well
as providing diverse results that better inform how to mitigate the feature interaction with
respect to the requirements and/or expectation revisions.
124

7.5

Evolutionary Computation Related Work

Significant work has been done in the area of representing features as well as detecting,
avoiding, and resolving feature interactions. This section overviews and compares related
work limited to those that address detection, the focus of this work. More comprehensive
surveys on feature interaction have been presented elsewhere [4, 5, 20].
Typically, the detection of feature interactions focuses on identifying minimal sets of
features that are necessary for a feature interaction to take place [41, 59, 6, 7]. Often, these
methods are limited to pair-wise detection [21, 41], where only interactions between two
features can be detected. For n-way feature interaction detection techniques, these minimal
sets require a potentially exponential number of feature interactions to be detected (i.e., every
possible feature set) [7], while Phorcys detects which features can fail due to an interaction,
up to only a single counterexample for each feature is provided. Search-based techniques
for discovering latent properties, including feature interactions, exist, but require manual
analysis of discovered properties [52, 60]. Phorcys-EC differs from existing feature interaction
detection methods by combining several key elements:
• it operates at the requirements level,
• it determines if a feature can fail due to a feature interaction automatically (i.e., without
manual analysis),
• it employs a combination of both symbolic analysis and evolutionary computation to
generate a representative and diverse range of counterexamples for each feature that
can fail due to a feature interaction.

7.6

Summary

In this chapter, we have described Phorcys-EC, a design-time approach for detecting
unwanted n-way feature interactions and determining their causes at the requirements level
125

using symbolic analysis and evolutionary computation to identify diverse counterexamples.
Unlike Phorcys, Phorcys-EC uses evolutionary computation and symbolic analysis to detect
multiple counterexamples that represent diverse feature sets and environmental scenarios for
each feature without sacrificing guaranteed detection. We have demonstrated Phorcys-EC
on a braking system goal model comprising several features to realize an automotive braking
system.
Future research will continue to explore how Phorcys-EC can be extended to address
additional assurance challenges posed by computing-based systems as they interact with the
environment. For example, we will explore how to detect feature interactions in the face of
uncertainty due to environmental conditions as they impact system conditions. Additionally, while Phorcys-EC detects feature interactions at design-time, we will also investigate
run-time feature interaction detection and mitigation strategies, just as existing SA+EC
requirements completeness approaches [38] have been extended to run-time approaches [39].
We will also explore the use of RELAXed goals [94], whose utility functions are evaluated according to fuzzy logic expressions, or applying other transformations to introduce a gradient
to requirements satisfaction in support of evolutionary search.

126

Chapter 8
Detecting Feature Interactions: At
Run Time
The validity of systems at run time depends on the features included in those systems
operating as specified. However, when feature interactions occur, the specifications no longer
reflect the state of the run-time system due to the conflict. While methods exist to detect
feature interactions at design time [40], conflicts that cause features to fail may still arise
when new detected feature interactions are considered unreachable, new features are added,
or an exhaustive design-time detection approach is impractical due to computational costs.
This chapter introduces Thoosa, an approach for using models at run time to detect features
that can fail due to feature interactions at run time. We illustrate our approach by applying
Thoosa to an industry-based automotive braking system comprising multiple subsystems.

8.1

Introduction

While systems are expected to satisfy their specifications at run time, these specifications
can only be satisfied if they are logically sound and do not include conflicts that result in
feature interactions. Detecting feature interactions is challenging due to the exponential
growth of potential interactions with respect to the number of features [17] and the range of
127

environmental possibilities in cyber-physical systems. More formally, when defining a feature
interaction by the minimal set of features that are necessary for the interaction to occur,
the number of possible interactions is O(2|F | ), where F is the set of features [5]. The growth
in the number possible feature interactions and consequently the number of possible feature
interactions that must be assessed can result in latent behavior that impacts the system
dependability at run time. This problem is particularly prominent in cyber-physical systems
where unexpected adverse environmental conditions may occur and impact the dependability
of the system. However, run-time detection of feature interactions reduces the possible feature
and environmental combinations to a single concrete instantiation that must be analyzed for
feature interactions. This chapter presents Thoosa,1 a method for detecting each feature that
causes an n-way feature interaction in a requirements goal model at run time.
This chapter presents Thoosa, a method for detecting each feature that fails at run time
due to feature interactions using executable code generated from a symbolic representation of
feature interactions. That is, feature interaction counterexamples are identified via a featureoriented analysis based on whether a feature can fail due to an interaction given the concrete
instantiation of the system at a given time. For example, consider 3 features, F1 , F2 , and F3 .
If an interaction exists, then at least one feature (F1 , F2 , or F3 ) no longer operates as it did
independently. Thoosa reduces the computational effort by only analyzing a single scenario
or set of features, at run time, while still detecting n-way feature interactions.
Thoosa analyzes features represented in goal models that hierarchically decompose a
high-level goal down to individual requirements [87]. Thoosa executes generated logic, in the
form of C++ code, that analyzes each feature with respect to the current feature combinations of the goal model and identifies if the analyzed feature can fail due to a conflict in one
or more requirements to be satisfied at run time. Each feature is analyzed for failure due
to a feature interaction. Where previous run-time feature interaction detection techniques

1

Thoosa is a Greek sea nymph associated with swiftness and the daughter of Phorcys.

128

indicate that a feature interaction exists, Thoosa identifies which features fail due to the
feature interaction.
The contributions of this chapter are as follows:

• We introduce a new approach for analyzing requirements to determine if they fail at
run time due to a feature interaction,

• We present Thoosa, a prototype implementation of the approach, and

• We demonstrate the applicability of Thoosa on an industry-based application of an
automotive braking system based in part on the feature interaction issues in the 2010
Toyota Prius [29, 63], a hybrid vehicle. Analysis shows that Thoosa is able to identify feature failures caused by feature interactions in the braking system goal model
involving two or more features.

The remainder of this chapter is organized into the following sections. Section 8.2 details
the approach. Section 8.3 describes an example application, and Section 8.4 details related
work. Finally, Section 8.5 discusses the conclusions and avenues of future work.

8.2

Run-Time Approach

Figure 8.1 overviews the Thoosa process with a DFD. As shown in Step 1 of Figure 8.1,
Thoosa accepts a goal model defined by the system designer (including feature and pre/post-condition annotations), such as the one in Figure 6.1, and generates feature interaction
detection logic. Step 2 generates monitoring code that can be executed at run time based
on the feature interaction detection logic. The Thoosa output from Step 2 contains the
generated monitoring code that can detect feature failures due to feature interactions. Next,
we describe each of the steps in the DFD in turn.
129

Annotated
Goal Model

Goals,
Expectations,
Requirements

(1)
Generate
FI Detection
Logic

Process Key:
Process
Flow
External I/O

Logical
Expressions

File

Run-Time
Monitoring
Code

Run-Time
Monitoring
Code

(2)
Generate
Monitoring
Code

Figure 8.1: Thoosa Data Flow Diagram

8.2.1

Step (1): Generate FI Detection Logic

A failure of a specific feature is identified when that specific feature’s properties are
unsatisfied for a specific composition of features that includes the feature under analysis, as
indicated in Equation (6.6). Assuming all features are analyzed for failure due to a feature
interaction, Equation (6.6) is both complete (i.e., no missing interactions) and sound (i.e.,
no superfluous interactions detected). In this chapter, we employ Equation 6.6 to detect if
a feature can fail due to a feature interaction where we measure the inclusion of a feature
based on that feature’s pre-conditions, while the feature properties are measured by the
satisfaction of the feature’s post-conditions.
Features that can fail due to a feature interaction are detected based on generated logical
expressions for each feature represented in the goal model provided by the system designer.
The logical expressions are generated from the pre- and post-conditions in the goal model
that are satisfied when a goal model instance is both i) valid and ii) contains properties of a
130

feature interaction as defined within previous work on symbolically analyzing goal models for
feature interactions in Chapter 6. That is, the feature interaction detection logic generated
by Thoosa is the same as that generated by Phorcys.

8.2.2

Step (2): Generate Executable Code

Thoosa automatically generates executable code based on the logic generated to detect
failures that are caused by feature interactions in Step (1). Specifically, the following items
are calculated and assigned to variables based on the current state of goal model variables
(i.e., the values those variables take on at run time while executing the implemented system):
• The satisfaction of the goal model based on the decomposition of the top-level features,
• The satisfaction of each of the feature pre-conditions (i.e., corresponding to if the
feature should be included in the feature set and satisfied), and
• The satisfaction of each of the features including their pre- and post-conditions.
An example of the generated code is shown in the partial code listing in Figure 8.2, where
the top-level goal satisfaction, feature pre-condition satisfaction, and feature satisfaction are
all calculated. A full listing of the generated code is included in the Appendix.
Importantly, all features are analyzed for failure for the generated code instead of analyzing features one at a time. That is, each feature is analyzed for its current ability to
cause a feature interaction (e.g., ‘B fails,’ ‘C fails,’ ‘D fails,’ and ‘E fails’ in Figure 8.2). The
system designer must update the propagation, or ‘freshness,’ of any variables in the system
by updating functions starting with a ‘V ’ to return true when the variable has been updated, and false when it has not. For example, Figure 8.3 includes the sample code listing
for ‘V SS ’ that must be updated to return true when the slip sensor variable has been read
from the sensor, and false when it is out of date. In a typical system, sensors would likely be
read continuously while actuators would only propagate when they are specifically set to a
value by the system.
131

// C a l c u l a t e t he top−l e v e l g o a l s a t i s f a c t i o n
( t o p L e v e l S a t i s f a t i o n = ( (B( ) | | C( ) ) && (D( ) | | E ( ) ) ) ) ;
//
//
(B
(C
(D
(E

C a l c u l a t e t he s a t i s f a c t i o n o f each f e a t u r e ’ s
preconditions
precondition = B P ( ) ) ;
precondition = C P ( ) ) ;
precondition = D P ( ) ) ;
precondition = E P ( ) ) ;

//
(B
(C
(D
(E

Calculate
f a i l s = B PP ( ) ) ;
f a i l s = C PP ( ) ) ;
f a i l s = D PP ( ) ) ;
f a i l s = E PP ( ) ) ;

Figure 8.2: Variables Calculated for FI Detection in Figure 6.1
// C a l c u l a t e v a r i a b l e p r o p a g a t i o n :
b o o l V SS ( ) {
return true ;
}
Figure 8.3: Propagation Function for SS (Slip Sensor) Figure 6.1

8.2.3

Record Failures and/or Adapt

Based on the values that are returned from the run-time detection of feature interactions
and the features that fail due to the interaction, a partial list of appropriate systems actions
that could be manually defined by the system designer are:
• The feature interaction along with the failing feature(s) could be recorded for later
analysis. For example, a recorded feature interaction may be used by the system designer to update the system to mitigate that feature interaction.
• Specific mitigations may be put in place to allow fail-safe or fail-silent operation.
• Specific feature failures due to feature interactions and their satisfied pre-conditions
132

may be used as guidance or input to run-time adaptations to adapt from the feature
set that causes a feature interaction.

8.2.4

Limitations

Counterexamples may be present in a scenario that occurs only between sensor readings.
In such cases, the values calculated by the utility functions never represent an incompleteness
or inconsistency and, therefore, no counterexample is detected.

8.3

Run-Time Case Study

This section provides the results of applying the Thoosa tool with simulated run-time
inputs. The braking system defined in Figure 6.1 identifies two potential sources for driving
brake commands (features D and E) that provide the inputs to two methods of physically
applying the brakes (features B and C). Previous analysis of the braking system has shown
that both features B and C can cause an interaction. We apply the variables identified in
the symbolic approach in Chapter 6, to ensure the run-time approach of Thoosa correctly
identifies features that can fail due to an interaction.

Run-Time Analysis of Feature B for Failure Due to FI
The values of the variables in the goal model counterexample when Feature B is the
cause of a feature interaction are shown in Table 8.1 and are applied to the run-time system
for detection. Figure 8.4 illustrates the applicable parts of the goal model (at the feature
level) for the 3-way feature interaction caused by feature B where the red text (SF = ?)
indicates the conflict that should be detected. The brake force (BF = 0.35) is provided
externally by the driver pressing on the brake pedal. This value is read via the ‘Brake Pedal
Sensor’ and converted to a commanded brake force (CBF = 0.35) by feature D. The features
that apply the brake force, B and C, read this commanded brake force (CBF ) from memory
133

and use it to apply external brake forces. Feature B applies, via B.2, the entire commanded
brake force to standard braking force (SF = 0.35) (e.g., drum or disk brakes on the wheels).
Feature C applies a portion (defined by C.5) of the commanded brake force to the standard
braking force (SF = 0.07) and a portion (defined by C.10) to the regenerative braking force
(RF = 0.28). The interaction occurs due to the conflict where features B and C both attempt
to set SF to different values, clearly SF = 0.35 and SF = 0.07 cannot be true simultaneously.
Table 8.1: Variables for Failure of Feature B
Variable
SF
CBF
PBF
RF
BF
SS

Key:

Value
0.07
0.35
0.0
0.28
0.35
true

A
Maintain(Brake
System)

Input
Output
Satisfied
Not Satisfied

AND

A.2
Maintain(Brake
Command)

A.1
Maintain(Brake
Force)
OR

B
Achieve(Standard
Force Braking)
100%
SF=0.35

SF=?

OR

C
Achieve(Regen
Braking)

E
D
Achieve(Anti- Achieve(Continuous
Braking)
Lock Braking)

20%
SF=0.07

CBF=0.35

RF=0.28

BF=0.35

Figure 8.4: 3-Way FI in Figure 6.1 Caused by B or C

Thoosa does identify that feature B fails due to a feature interaction, along with the
remainder of the run-time results shown in Table 8.2. That is, when a known counterexample
is used to initialize the system variables, the detection code generated by Thoosa is able
to detect the known feature interaction. Note, the top level goal is still satisfied because
134

either goal B or goal C is required, and goal C is still satisfied. Therefore, despite the feature
interaction the system still succeeds, but not as intended. In this case the system designer
may desire this feature interaction to be recorded, but adaptation is not strictly necessary due
to the top-level satisfaction of the system. Other strategies are proposed in Sub-Section 8.2.3.
Table 8.2: Run-Time Results for Feature B
Identifier
Top-Level (Goal A)
Feature B Fails
Feature C Fails
Feature D Fails
Feature E Fails
Pre-Conditions for B
Pre-Conditions for C
Pre-Conditions for D
Pre-Conditions for E

In Code
topLevelSatisfaction
B fails
C fails
D fails
D fails
B precondition
C precondition
D precondition
E precondition

Result
Satisfied
True
False
False
False
True
True
True
False

Run-Time Analysis of Feature C for Failure Due to FI
A counterexample with a similar type of failure is the interaction failure of feature C: a
conflict between B and C attempting to set SF to different values. The variable values applied
to the run-time system, as shown in Table 8.3, result in the detection of a failure of feature
C due to the interaction.
Table 8.3: Variables for Failure of Feature C
Variable
SF
CBF
PBF
RF
BF
SS

Value
0.35
0.35
0.0
0.28
0.35
true

Thoosa does identify that feature C fails due to a feature interaction, along with the
remainder of the run-time results shown in Table 8.4. Note, the top-level goal is still satisfied
because either goal B or goal C is required, and goal B is still satisfied. Therefore, despite
135

the feature interaction the system still succeeds, but not as intended. This is similar to
the top-level satisfaction shown when feature B fails due to a feature interaction. Again, no
adaptation is strictly required, however recording the feature interaction is one of several
possibilities proposed in Sub-Section 8.2.3.
Table 8.4: Run-Time Results for Feature C
Identifier
Top-Level (Goal A)
Feature B Fails
Feature C Fails
Feature D Fails
Feature E Fails
Pre-Conditions for B
Pre-Conditions for C
Pre-Conditions for D
Pre-Conditions for E

8.4

In Code
topLevelSatisfaction
B fails
C fails
D fails
D fails
B precondition
C precondition
D precondition
E precondition

Result
Satisfied
False
True
False
False
True
True
True
False

Run-Time Related Work

Significant work has been done in the area of detecting, avoiding, and resolving feature interactions. This section overviews and compares related work limited to those that
address run-time detection, the focus of this work. More comprehensive surveys on feature
interactions have been presented elsewhere [4, 5, 20].
Often run-time detection techniques are paired with an effort at run-time resolution, including techniques such as prioritization [22] and negotiation [53] between features. Recently,
methods to resolve interactions based on the conflicting variables have been presented to reduce the number of resolutions [17, 100], though dependencies between variables (e.g., speed
and acceleration) are not considered for interactions. This method does not provide guarantees that the resolution provides desired behavior for the system. Therefore, while resolution
at run-time may provide an acceptable solution, it is not guaranteed. Thoosa operates at
the requirements level and identifies which features fail due to the feature interaction and
136

allows for mitigations to be created that adapt from an interacting set of features while still
satisfying the top-level goal.
Typically, the design-time detection of feature interactions focuses on identifying minimal sets of features that are necessary for a feature interaction to take place [41, 59, 6, 7].
Often, these methods are limited to pair-wise detection [21, 41] or other small feature sets [44],
where only interactions between two features can be detected to reduce computational cost.
Thoosa, however, detects n-way feature interactions at run-time, and only inspects a single
scenario (i.e., set of variables and features) at a time.
Thoosa differs from existing feature interaction detection methods by combining three
key elements:
• it operates at the requirements level,
• it detects n-way feature interactions, and
• it identifies which features can fail due to an interaction, and
• it only inspects a single scenario (i.e., set of variables and features) at run time, reducing
computational cost.

8.5

Summary

In this chapter, we have described Thoosa, a run-time approach for detecting unwanted
n-way feature interactions and determining features that they can cause to fail. Thoosa
is an important practical assessment of feature interactions at run time when the designtime computational costs of n-way interactions are infeasible. Unlike previous n-way feature
interaction detection approaches that detect feature interactions at run time, Thoosa also
identifies the features that can fail due to the feature interaction that is detected. Thoosa
reduces the effort to log errors or adapt run-time behavior by identifying which features fail
in an interaction rather than simply detecting that an interaction has occurred. We have
137

demonstrated Thoosa on a braking system goal model comprising several features to realize
an automotive braking system.

138

Chapter 9
Detecting Interactions of
Non-Functional Properties

Non-functional requirements, including safety requirements, are intended to ensure the
non-functional properties of the system under development. However, non-functional properties of the system often crosscut functional and non-functional requirements. These crosscutting concerns are dispersed throughout the requirements. This dispersion renders manual
insertion of the non-functional requirements difficult and error prone. One approach to address this challenge is to take an aspect-oriented modeling approach, where the cross-cutting
concerns (i.e., aspects) are modeled separately from the functional concerns and then woven
together, thus facilitating traceability and maintainability. This chapter introduces Soter, a
method for aspect-oriented modeling of non-functional requirements and properties, which
applies a symbolic analysis, evolutionary computation and symbolic analysis, and run timebased approaches to detect unwanted interactions between non-functional properties and/or
functional requirements for cyber-physical systems. We illustrate our approach by applying
Soter to detect unwanted interactions in the aspect-oriented safety and performance models
and requirements of an industry-based automotive braking system.
139

9.1

Detecting Feature Interactions

Including safety requirements in a requirements specification can be challenging, especially in cyber-physical systems. The safety requirements may be violated due to unwanted
system behavior in response to adverse or unexpected environmental conditions. Safety requirements, often cross-cutting, must be meticulously applied to any system scenario that
could cause a violation. For high-assurance systems (e.g., automotive braking systems), ensuring safety requirements are satisfied is of paramount importance. The increasing complexity and the number of onboard features in modern vehicles further exacerbates the
challenge of guaranteeing safety requirements. Aspect-Oriented Requirements Engineering
(AORE) [11] provides a method of modeling non-functional requirements, including safety
requirements, independent of the overall requirements model. However, issues of composition, weaving, traceability, and analyzability must be addressed to ensure safety across the
suite of requirements. This chapter presents Soter,1 an automated approach to detect nonfunctional requirement violations, including safety violations, and unwanted interactions between cross-cutting non-functional requirements and functional requirements at design time
and run time.
Current methods of defining non-functional goals and properties in Goal-Oriented Requirements Engineering require explicitly defined links between non-functional requirements
and functional goals and requirements in the GORE model. Goals to avoid non-functional
violations, or mitigations, can be included in a requirements decomposition [87]. For example, obstacles for a given goal can be directly linked to requirements within a KAOS goal
model. Mitigation of obstacles can be performed at or above the level of abstraction of the
obstructed requirement to allow for both weak and strong mitigation, respectively [87]. Nonfunctional goals can be linked to existing goals and requirements based on their contribution
to functional goals and requirements [95]. Each of these methods requires a direct connection
to specific functional goals or requirements without taking into account how interactions on
1

Soter is the Greek spirit of safety, preservation, and deliverance from harm.

140

requirements impact the subsequent contribution to other requirements in the system. While
methods for defining non-functional requirements as aspects exist, they have not been used to
explicitly represent important non-functional requirements like safety requirements [77], require manual detection processes [25], or only assist in identifying cross-cutting concerns [97]
in a model.

This chapter describes Soter, an approach to detecting violated cross-cutting nonfunctional requirements, including safety and performance requirements to detect feature
interaction at design time, using a symbolic analysis and evolutionary computation-based
approach, and run time. Currently, only a limited number of methods exist to detect aspect interactions at the requirements level, despite the similarity to feature interactions [71].
Soter leverages the similarity between aspect and feature interactions by translating the
aspect-oriented safety requirements into features representing the non-functional requirements. These additional non-functional features are woven into the existing GORE model.
Feature interaction detection analysis is applied to each of the functional features and nonfunctional features to determine if they cause an interaction or non-functional property violation [40]. The counterexamples for each detected interaction amongst the safety features
are classified according to the safety model properties and provided to the system designer
to guide the revision of the functional and safety requirements. For example, an Adaptive
Cruise Control may have a safety requirement to avoid collision with other cars depending
on a specific proximity, while the requirements model for the ACC also has requirements
to maintain the driver’s desired speed. The safety requirement to avoid a collision, (i.e., a
non-functional requirement) can be violated when the driver’s desired speed is maintained
and therefore an interaction exists between the requirements to avoid collision and maintain
the driver’s desired speed.

Soter provides a method for modeling aspect-oriented non-functional goals, including
safety and performance goals, that includes goal decomposition strategies that provide func141

tional mitigations. Soter recombines the non-functional property and an optional mitigation
decomposition to create non-functional features that represent one of the following cases:
• Non-Functional Properties: non-functional invariants of the system with no mitigation,
• Weak Mitigations: mitigations that are applied when non-functional properties are
violated, and
• Strong Mitigations: mitigations that are applied to ensure non-functional properties
are never violated.
These non-functional features are defined separately (i.e., as aspect models) from the traditional requirements decomposition hierarchy and are subsequently woven into the relevant
portions of the requirements model automatically. Counterexamples representing interactions
between functional and non-functional features are generated by a feature interaction detection tool, Phorcys [40], and categorized by Soter as to whether the non-functional properties,
the mitigation objectives, or both were violated.
The contributions of this chapter are as follows:
• We propose a goal modeling approach to modeling non-functional requirements as
cross-cutting concerns,
• We introduce an approach to automatically detect conflicts between non-functional
requirements and functional requirements by exploiting the similarity between aspect
and feature interactions, and
• We present a prototype implementation of the Soter approach, and demonstrate the
applicability of Soter on an industry-based automotive braking system using nonfunctional safety and performance goals and requirements.
The remainder of this chapter is organized as follows. Section 9.2 describes and gives
examples of the Soter aspect-oriented requirements model. Section 9.3 introduces the Soter
142

approach. Section 9.4 describes the application of Soter to an industry-based example. Section 9.5 covers related work, and Section 9.6 discusses conclusions and future work.

9.2

Representation of Non-Functional Requirements

Soter supports the modeling and the analysis of three kinds of non-functional requirements models: non-functional properties, weak mitigation (of non-functional property violation), and strong mitigation (of non-functional property violation). Each of these three
comprise a non-functional property trigger that assesses non-functional property violations
and for the latter two model types, a goal decomposition representing the mitigation requirements. Importantly, each of these non-functional requirement models are based on a crosscutting non-functional goal that represents a cross-cutting non-functional concern. Each of
the three kinds of non-functional requirements models may be applied to a functional goal
model individually or in combination with any number of additional non-functional requirements models.

9.2.1

Non-Functional Properties

Non-functional properties specify non-functional goals (e.g., ‘Avoid collision’) and are
represented by non-functional models that use a non-functional property trigger to detect
a non-functional property goal violation. For example, in Figure 9.1a, the Non-Functional
Goal is violated when the non-functional property Trigger is satisfied, denoted by a single
hashed directed edge from the non-functional property trigger to the non-functional goal.
The non-functional property Trigger may be decomposed as needed.
The system, as a whole, is intended to continuously satisfy the Non-Functional Goal
by never satisfying the non-functional property Trigger. For example, in Figure 9.1b, goal PT
is the cross-cutting safety goal intended to avoid front collisions. Goal PT, a safety property
trigger, indicates a safety goal violation if the ‘Front Distance’ is zero or less, which is true
143

if either of the front distance sensors (‘FD Sensor 1’ or ‘FD Sensor 2’ ) report a value of
zero or less (i.e., via goals PT.1 or PT.2, respectively).

...

PT.2
FD Sensor 2 <= 0

PT.1
FD Sensor 1 <= 0
OR

Trigger

PT
Front Distance <= 0
Non-Functional
Goal

NFG
Avoid(Collision)

(a) Template

(b) Safety Instantiation

Figure 9.1: Safety Model: Non-Functional Properties

9.2.2

Weak Mitigation

Weak mitigations are represented by non-functional requirement models that provide
alternative functionality when the non-functional goal is violated as detected by the nonfunctional property trigger. For example, in Figure 9.2a, goal Non-Functional Goal is still
the cross-cutting non-functional goal. The non-functional property trigger, goal Trigger
and its derived expectations, measures violations of the non-functional goal. For this nonfunctional requirements model, when the non-functional goal is violated, the Mitigation
Goal provides alternate behavior to mitigate the impact of the non-functional goal violation.
The Mitigation Goal is identified by a double hashed edge from the Non-Functional
Goal to the Mitigation Goal. These mitigation requirements may attempt to minimize
the adverse impact of the violation of the non-functional goal or provide fail-safe behavior
when the non-functional goal is known to be violated.
Weak mitigations are used to model non-functional requirements whose violation cannot be prevented, but necessitate an alternative behavior when the non-functional goal is
violated. For example, in Figure 9.2b, a fail-safe mitigation applies full brakes in the event
144

of an imminent collision. The safety property trigger, decomposed from goal PT, indicates a
violation of the non-functional safety goal when the distance measured by either of the front
distance sensors (i.e., ‘FD Sensor 1’ or ‘FD Sensor 2’ ) is zero. When the non-functional
safety property violation occurs, the mitigation (i.e., Goal M) and its decomposed goals and
requirements apply the maximum amount of standard braking (i.e., Goals M.1, M.3, and
M.4) while minimizing regenerative braking (i.e., Goals M.2, M.5, M.6) to prevent the battery from being charged during a collision. Goals M.3 and M.5 are expectations expressed as
post-conditions of the M.1 and M.2 requirements, respectively.

PT.1
FD Sensor 1 <= 0

PT.2
FD Sensor 2 <= 0
OR

PT
Front Distance <= 0
...

NFG
Avoid(Collision)

Trigger

M
Minimize Collision

Non-Functional
Goal

AND

M.1
Achieve(Max
SF Braking)

Mitigation
Goal

M.2
Achieve(Max
Regen Braking)

AND

...

M.3 (post)
SF = MAX

(a) Template

M.4
Achieve(Apply
Standard Force)

AND

M.5 (post)
RF = MIN
M.6
Achieve(Apply
Regen Force)

(b) Safety Instantiation

Figure 9.2: Non-Functional Model: Weak Mitigation

145

9.2.3

Strong Mitigation

Strong mitigations are represented by non-functional requirement models that provide
mitigation requirements that guarantee the non-functional goal will not be violated. For
example, in Figure 9.3a the non-functional property Trigger measures the violation of the
Non-Functional & Mitigation Goal. However, unlike weak mitigations, the decomposition of the mitigation is a decomposition of the non-functional goal itself. If the mitigation
is satisfied, then the non-functional goal must not be violated.
Strong mitigations are used to model non-functional requirements whose violation can
be prevented, but necessitate additional mitigation behavior to ensure the non-functional
goal is not violated. For example, in Figure 9.3b, the non-functional safety property trigger
(i.e. Goal ST) should never indicate that the distance measured by either of the front distance
sensors is zero indicating that the non-functional safety goal (i.e., NGF & M) is violated. The
non-functional safety goal is not violated as the mitigation itself (i.e., NGF & M) is decomposed
from the non-functional safety goal. In Figure 9.3b, a front collision is avoided by applying
the brakes well before the distance sensors measure zero when there is still adequate distance
to avoid the collision (i.e., Safe Distance in goals M.2, M.5, and M.6).

9.3

Detection via Symbolic Analysis Approach

Soter is a tool for symbolically analyzing the woven goal model comprising the crosscutting non-functional concerns and the functional requirements to detect interactions or
failures. Feature interaction detection is applied to detect aspect interactions and failures
in aspect-oriented non-functional requirements models (e.g., Figures 9.1b, 9.2b, and 9.3b)
where non-functional requirements have been translated into features in a goal model.
An overview of the Soter process is shown in the DFD in Figure 9.4. Step 1 accepts the
non-functional models and transforms them into features represented in terms of hierarchical
goal models with pre- and post-conditions and requirements at the leaf level that can be
146

PT.1
FD Sensor 1 <= 0

PT.2
FD Sensor 2 <= 0
OR

PT
Front Distance <= 0

NFG & M
Avoid(Collision)

...

AND

Trigger
M.1
Achieve(Maximum
Stopping)

Non-Functional
& Mitigation
Goal
...

M.2
Front Distance <=
Safe Distance

AND

M.3
Achieve(Max
SF Braking)

AND

M.4
Achieve(Max
Regen Braking)

AND

M.6 (pre)
FD Sensor 2 <=
Safe Distance

AND

(a) Template
M.9 (post)
RF = MAX

M.8
Achieve(Apply
Standard Force)
M.7 (post)
SF = MAX

M.10
Achieve(Apply
Regen Force)

M.5 (pre)
FD Sensor 1 <=
Safe Distance

(b) Safety Instantiation

Figure 9.3: Non-Functional Model: Strong Mitigation

woven into a functional goal model (e.g., Figure 7.1). Step 2 weaves the generated nonfunctional features into an overall woven goal model that includes both the non-functional
models and functional goal model. In Step 3, the overall woven goal model woven with the
non-functional features is processed to identify feature interactions and failures. Finally, in
Step 4, the counterexamples detected are classified according to the type of failure (i.e., nonfunctional property, mitigation, or both). The classified counterexample causes are provided
to the system designer to facilitate the revision of the functional goal model and/or nonfunctional models. (For brevity, the updated non-functional models and functional goal model
147

in this section may use goal names to refer to previously defined goals without repeating
their full specification.) Next, we describe the details of each of the key steps for Soter.

Process Key:
Process
Flow
External I/O

Non-Functional
Models

Non-Functional
Models

File

(1)
Transform
Non-Functional
Models to
Features
Non-Functional
Features

Updated
Models

System
Designer

Classified
Counterexamples

Goal
Model

Goal
Model

Classified
Counterexamples

(2)
Weave
Non-Functional
Features
into Goal
Model
Goal
Model
with
Non-Functional
Features

Classified
Counterexamples

(3)
Classifies
Counterexamples

Non-Functional
Counterexamples

FI Detection

Figure 9.4: Soter Data Flow Diagram

Step (1): Transform Non-Functional Models to Features
Step 1 accepts the non-functional models developed by the system designer and translates them to non-functional features in terms of a hierarchical goal model. For each of the
three types of non-functional models, a separate transformation process is needed for the respective non-functional feature: non-functional property features, weak mitigation features,
and strong mitigation features. All three include a non-functional trigger that specifies a
measure that indicates whether the aspect-oriented non-functional goal has been violated.
148

Non-Functional Properties
The complement of the non-functional property trigger specifies the properties that the
system as a whole must maintain if it is not to violate the non-functional goal. A nonfunctional property model comprises this measure (i.e., the non-functional property trigger)
and the aspect-oriented non-functional goal. The feature is modeled as the complement of the
non-functional property trigger, as shown in Figure 9.5a. The only way that a non-functional
property feature can be satisfied is if none of the non-functional property triggers detect a
violation of the non-functional goal. Given that there are no pre-conditions for the feature,
the feature’s applicability is not restricted by its specification. A non-functional property
model is intrinsically applicable, or crosscuts, the entire specification in which it is included.
For example, the non-functional safety model in Figure 9.1b is transformed into a feature
in Figure 9.5b (as denoted by ‘(f)’). The shaded goals in Figure 9.5a are portions of the template that are carried forward into the instantiated feature, while the non-shaded goals are
replaced by instantiated goals from the non-functional safety model (e.g., Figure 9.1b). Just
as in Figure 9.5a, Figure 9.5b includes a top-level feature goal (i.e., goal Non-Functional
Property: Avoid Collision), as well as the complement of the non-functional safety trigger (i.e., goal ÂŹPT and its decomposed goals) from the non-functional safety model in Figure
9.1b (i.e., PT and its decomposed goals). Notice that due to the negation of the non-functional
safety property trigger, the decomposition changes from an OR-decomposition to an ANDdecomposition in the non-functional safety properties feature goal decomposition. Importantly, neither goal PT.1 nor goal PT.2 can be violated if the non-functional safety property
trigger, goal PT, is to remain unviolated.

Weak Mitigation
A weak mitigation non-functional model provides alternate behavior via the mitigation. Figure 9.6a, presents a template of a weak mitigation feature with two behaviors that
define the translation from a safety model. In one branch, goal Trigger and Mitigation
149

Non-Functional
Property:
Avoid Collision
(f)

Non-Functional
Property
(f)

ÂŹ PT (post)

ÂŹ Trigger (post)

AND

...

ÂŹ PT.1

(a) Template

ÂŹ PT.2

(b) Safety Instantiation

Figure 9.5: Non-Functional Feature: Non-Functional Properties
is AND-decomposed into non-functional goal violations and the corresponding mitigation,
both of which must be satisfied (i.e., provide alternate functionality) to satisfy the weak
mitigation feature. The second branch is the complement of non-functional properties (i.e.,
goal ÂŹTrigger) which is satisfied when the non-functional goal is not violated.
For example, the weak mitigation non-functional safety model in Figure 9.2b is translated into a weak mitigation non-functional safety feature in Figure 9.6b. Based on the
template in Figure 9.6a, the translated weak mitigation non-functional safety feature in Figure 9.6b includes alternatives for when the non-functional safety goal is violated (i.e., goal
Trigger and Mitigation: Minimize Collision) and when it is not violated (i.e., ÂŹPT).
Functionally, the mitigation (i.e., applying the maximum brake force to both standard friction and regenerative braking) is applied if the non-functional safety goal is violated (i.e.,
goal PT is satisfied due to the distance measured by the front distance sensors). Otherwise,
the mitigation is not applied if the safety goal is not violated (i.e., ÂŹPT).

Strong Mitigation
A strong mitigation non-functional model provides a mitigation that, when applied,
ensures the non-functional goal is never violated. Figure 9.7a defines the translation template
used to generate a strong mitigation non-functional feature. Similar to a weak mitigation non150

Weak Mitigation:
Minimize Collision
(f)
OR

Weak
Mitigation
(f)

Trigger and
Mitigation

OR

Trigger and
Mitigation

ÂŹPT (post)
AND

AND

ÂŹTrigger (post)

ÂŹPT.1

ÂŹPT.2

...

AND

PT (pre)

M
AND

OR

Trigger (pre)

Mitigation

...

...

PT.1

PT.2

M.2

M.1
AND

AND

(a) Template
M.3 (post)

M.4

M.5 (post)

M.6

(b) Safety Instantiation

Figure 9.6: Non-Functional Feature: Weak Mitigation

functional feature, a strong mitigation non-functional feature includes two behavior cases.
The first case is a mitigation that is applied when the non-functional goal is not violated
(i.e., goal Trigger and Mitigation). In the second case, no mitigation is applied when the
non-functional goal is not violated (i.e., ÂŹTrigger).
For example, the instantiated strong mitigation non-functional safety model in Figure
9.3b is translated into the feature goal model in Figure 9.7b. In both alternatives, the complement of the non-functional safety property trigger is required (i.e., goals ÂŹPT), while in
goal NFG & M, the mitigation is also applied. Functionally, the non-functional safety feature
cannot be satisfied unless the non-functional safety goal is satisfied (i.e., not violated by the
complement of the non-functional safety trigger). That is, the distance as measured by the
front distance sensors must not be equal to (or less than) 0. In cases where the mitigation
may be applied due to a distance measured that is less than or equal to the ‘Safe Distance’,
the brakes are applied.
151

Strong Mitigation:
Avoid Collision
(f)
OR

Trigger and
Mitigation

Strong
Mitigation
(f)

AND

AND

ÂŹPT.2

ÂŹPT.1

OR

Trigger and
Mitigation

ÂŹPT (post)

ÂŹTrigger (post)

NFG & M

ÂŹPT (post)

AND

AND

...

AND

M.2
AND

ÂŹPT.1
ÂŹTrigger (post)

ÂŹPT.2

Mitigation

...

M.1
AND

...

M.4

M.3

(a) Template

M.5 (pre)

AND

M.7 (post)

M.8

M.6 (pre)
AND

M.9 (post)

M.10

(b) Safety Instantiation

Figure 9.7: Non-Functional Feature: Strong Mitigation

Step (2): Weave Non-Functional Features into Goal Model
The second step of the Soter process weaves the non-functional features generated from
the translation in Step 1 into the functional goal model provided by the system designer
(e.g., Figure 7.1). Unlike source code weaving in aspect-oriented programming, where the
aspects are woven into joinpoints along the execution path by the information provided in
pointcuts [88], goal models have no implicit ordering of requirements based solely on the
structure of the model itself. Weaving safety features into a goal model is based on pointcuts
described by pre-conditions of the safety feature and expressed as joinpoints of pre-conditions
in the non-functional feature that are satisfied by the agents of the system or environment.
Since requirements are declarative, they are globally applicable unless filtered by the preconditions, unlike source code where a portion of code is applicable only if it is executed. To
accomplish the weaving of requirements, each non-functional feature (e.g., Figure 9.5b, 9.6b,
152

or 9.7b), along with the functional goal model (i.e., Figure 7.1) is AND-decomposed from a
new root goal. The translated non-functional features are logically propagated to where the
pre-conditions of the functional goals and that of the non-functional features are satisfied
(i.e., the pre-condition is satisfied by the environmental and system instantiated values),
otherwise they are not applicable.
For example, in Figure 9.8, the non-functional safety feature (Safety Model (f)) has
been woven into the braking system goal model in Figure 7.1 at the newly introduced root
(i.e., ‘Woven Goal Model’). Both the non-functional safety feature (i.e., Safety Model) and
the original functional goal model (i.e., A) are AND-decomposed under a single top-level
goal.
Woven
Goal Model
AND

A
Maintain(Brake
System)

Safety
Model
(f)

...

...

Figure 9.8: Woven Goal Model Example

In order for the Woven Goal Model to be satisfied, the original goal model and the
non-functional safety feature must be satisfied.

FI Detection
Using the features in the goal model, including the woven safety features representing
the safety models, symbolic feature interaction detection is used to detect features that
cause interactions or safety failures [40]. A previously developed symbolic feature interaction
detection method, Phorcys [40], is used to detect the interactions and failures from the woven
goal model and returns a set of counterexamples.
153

Step (3): Classifies Counterexamples
Causes of an interaction or non-functional property violation are individual features
where the post-conditions are not satisfied in a given counterexample. Soter categorizes
these counterexamples based on the location of the unsatisfied post-conditions. If the unsatisfied post-condition exists in a functional feature, then the failure is classified as a feature
interaction. However, if the unsatisfied post-condition exists in a safety feature, then Soter
categorizes the failure based on the type of safety feature violated, as defined below.
Non-Functional Property Features
The only post-condition in a non-functional property feature is the complement of the
non-functional property trigger. Given a counterexample that identifies a non-functional
property feature as the feature that fails in a feature interaction, Soter classifies the failure
as a safety goal violation.
For example, in the translated non-functional safety property feature in Figure 9.5b, if
the counterexample shows that at least one of the front distance sensors (e.g., ‘Front Distance
Sensor 1’ or ‘Front Distance Sensor 2’ ) is less than or equal to zero, then the safety goal SG
in Figure 9.1b has been violated.
Weak Mitigation Features
In weak mitigation features, two sets of post-conditions may be violated and can be
traced back to the non-functional model: the complement of the non-functional property
trigger and the post-conditions that exist in the weak mitigation. Soter classifies failure
based on the post-conditions that are violated as follows:
• The complement of the non-functional property trigger is violated indicating
the mitigation pre-conditions must be violated and the non-functional model is not
sufficient to provide alternate functionality in all cases where the non-functional goal
is measured as violated by the non-functional property triggers.
154

• The complement of the non-functional property trigger and the mitigation
post-condition is violated indicating an interaction exists with the mitigation functionality that prevents alternate functionality in all cases where the non-functional goal
is measured as violated by the safety triggers.
When the mitigation post-condition is violated, it is assumed that the complement of the
non-functional property triggers are also violated. Otherwise the feature could be satisfied
by the complement of the non-functional property triggers alone.

Strong Mitigation Features
Strong mitigation features, similar to weak mitigation features, have the same two
sets of post-conditions that may be violated and traced back to the original non-functional
model (i.e., the complement of the non-functional property trigger and the mitigation postconditions). However, the complement of the non-functional property triggers are used as
post-conditions in both alternatives of the non-functional model (i.e., ÂŹTrigger in Figure
9.7a). Soter classifies the failures based on the post-conditions that are violated as follows:
• The complement of the non-functional property trigger is violated indicating
the mitigation is unable to prevent the violation of the non-functional goal in the
non-functional model as measured by the non-functional property triggers.
• The mitigation post-condition is violated indicating an interaction exists that
prevents the mitigation from satisfying its specification, but has not caused a nonfunctional goal violation as measured by the non-functional property triggers.
• The complement of the non-functional property trigger and the mitigation post-condition is violated indicating an interaction exists with the mitigation
functionality that prevents the mitigation from ensuring the non-functional goal is not
violated as measured by the non-functional property triggers.
155

System Designer Revisions
The analysis results, including the failure caused by the unwanted interaction and the
non-functional property violation is provided to the system designer for manual revision. For
each of the possible combinations of non-functional model type and failure or interaction
source, a possible resolution is provided in Table 9.1. The resolution is not identified automatically by Soter, but rather is identified by the system designer. It may also be necessary
to weaken non-functional property triggers or even mitigation model type, if non-functional
goals are not practically achievable within the system specification.
Table 9.1: Possible Failure Resolutions
#
1
2
3
4
5
6
7

Model
Type
Non-Functional
Property
Weak
Mitigation
Weak
Mitigation
Strong
Mitigation
Strong
Mitigation
Strong
Mitigation

Failure
Source

Possible Resolution

Trigger

Weaken non-functional goal or update
goal model.

Trigger

Weaken pre-condition of mitigation.

Trigger,
Mitigation

Update mitigation and/or goal model
to prevent interaction.

Trigger

Weaken mitigation pre-condition.

Functional

Feature

Mitigation
Trigger,
Mitigation

Update mitigation and/or goal model
to prevent interaction.
Update mitigation and/or goal model
to prevent interaction.
Update goal model and/or nonfunctional mitigation.

Additionally, the type of non-functional model initially used may not be sufficient. For
example, if a non-functional property is violated then it may be necessary to provide a weak
or strong mitigation. It is suggested to first implement a non-functional model as a nonfunctional property (i.e., without a mitigation) to determine if the non-functional property
is ever violated. If it is, then a strong mitigation is the most appropriate mitigation since
a strong mitigation ensures the original non-functional property would never be violated.
However, if no mitigation exists that prevents the non-functional violation, then it is im156

portant to minimize the negative impact via a weak mitigation that is applied when the
non-functional violation occurs.
Updates to the aspect-oriented non-functional models or functional goal model that are
performed by the system designer may be analyzed again by Soter to determine whether
there exist remaining or newly-introduced interactions or failures.

9.4

Detection of Interactions

This section details the detection of interactions and failures caused by the nonfunctional safety models developed in Sections 9.2 and 9.3 and their impact on the functional
model. This subsection can be viewed as a complete example of Soter, as it illustrates the
detection and mitigation of interactions caused by the non-functional and functional models.
Additionally, we develop non-functional models for an additional non-functional safety goal
and a non-functional performance goal to illustrate the generally applicable nature of Soter
by creating non-functional property models, non-functional weak mitigation models, and
non-functional strong mitigation models. Finally, three of the non-functional models (two
safety and one performance) are woven into the functional model and any interactions are
detected.

9.4.1

Safety Case Study: Collision

This subsection gives the results of applying Soter to aspect-oriented safety models related to collisions for the braking system goal model in Figure 7.1. Soter is used to detect
safety failures, safety model interactions with functional requirements, and interactions between safety models. The safety models used in this example application are defined by
the system designer and represent three different non-functional goals intended to avoid or
minimize the effect of a collision.
157

Avoid Collision via Safety Property
Initially, the non-functional safety property model in Figure 9.5b (translated from Figure
9.1b) is woven into the functional goal model in Figure 7.1 in order to detect any feature
interactions or failures caused by the safety properties necessary to avoid a frontal collision.
An excerpt of the woven goal model, including the functional braking system and the safety
properties model is shown in Figure 9.9. This initial woven model is referred to as M .
Woven
Goal Model
(M)
AND

A
Maintain(Brake
System)

Non-Functional Property:
Avoid Collision
(f)

...

ÂŹPT (post)
...

Figure 9.9: Goal Model Woven With Non-Functional Safety Property (M )
Applying Soter to detect interactions and failures caused by the safety model results in
a counterexample that includes a violation of the safety model without an interaction (i.e.,
a safety failure). In this counterexample, one of the front distance sensors (FD Sensor 1 )
results in a distance of 0.0. This safety goal violation is caused by there being nothing in the
functional goal model (i.e., Figure 7.1) that applies the brakes based on information from
the distance sensors.

Avoid Collision via Strong Mitigation
In order to avoid a safety goal violation, a mitigation must be employed to avoid the
violation. Accordingly, we replace the non-functional safety property model, which only
detects the violation of the non-functional safety properties, with a strong mitigation model
158

that attempts to avoid the violation entirely. The strong mitigation model in Figure 9.7b
(translated from Figure 9.3b) attempts to apply the brakes before an object becomes too
close (i.e., causes a front collision) to the front distance sensors. The new woven goal model,
including the functional braking system and the strong mitigation model, is shown in Figure
9.10. This updated woven model is referred to as M 0 .
Woven
Goal Model
(M)
AND

A
Maintain(Brake
System)
...

Strong Mitigation:
Avoid Collision
(f)
OR

Trigger and
Mitigation

ÂŹPT (post)
...

...

Figure 9.10: Goal Model Woven With Strong Mitigation (M 0 )

Applying Soter to detect interactions and failures caused by the safety model results in
an interaction detected with features B and E. Table 9.2 provides the values of the variables in
the counterexample, and indicates by which post-conditions a given variable is constrained.
Table 9.2: Counterexample: Variables for Interaction in Goal Model M 0
Variable
BF
CBF
DS1
DS2
RF
SF
SS

Value
0.40
0.40
0.0
0.0
0.32
0.08
false

Constrained In
E.3, D.11, D.13

C.10, SG.9
B.1, C.5, SG.7
E.6, D.6

While features B and E are satisfied, the strong mitigation model is violated. Specifically,
goals SG.7 and SG.9 are violated since they are unable to set regenerative brake force (RF )
or standard brake force (SF ) to the MAX value (100.0). Further, the safety trigger is satisfied
159

(i.e., a safety goal violation) since the front distance sensors both read 0.0 (DS1 and DS2 ).
Given the source of the cause and the safety model type, Table 9.1, row 6 suggests an update
to either the mitigation or the goal model could be used to remove the interaction.

The purpose of the mitigation in the safety model in Figure 9.3b is to prevent the
vehicle from violating the safety goal by applying brake force before the vehicle is involved
in a collision. Since the safety goal is violated and we do not want to permit collisions, an
update to allow the mitigation is necessary, and the functional goal model must be updated.
Functionally, any expectation that changes the value of standard or regenerative braking
force (SF or RF ), must only be applied when the mitigation from the strong mitigation
model is not applied. The functional goals that change the braking force values are B.1, C.5,
and C.10. Each of these goals is replaced with a system designer-defined goal decomposition
excerpt to remove the conflict when changing the braking force values. The update for B.1
is AND-decomposed from goal B, taking the position previously occupied by B.1, while goal
B.1 moves to the gray goal as shown in Figure 9.11a. Similarly, both expectations C.5 and
C.10 that are AND decomposed from goals C.3 and C.4 are updated in Figures 9.11b and
9.11c, respectively.

The updates to goals B.1, C.5, and C.10 using the update excerpts in Figures 9.11a,
9.11b, and 9.11c result in an updated goal model, referred to as M 00 . However, when Soter
analyzes goal model M 00 , the mitigation no longer fails due to an interaction, but the safety
trigger can still indicate a safety goal violation. The counterexample variable values for this
safety goal violation are shown in Table 9.3. Importantly DS1 and DS2 , the distance sensors,
both show a distance of zero, indicating a collision despite maximum (MAX ) braking for
both regenerative and standard braking (RF and SF ). Unfortunately, the strong mitigation
is not sufficient to guarantee the prevention of a collision.
160

...

...

...

B (f)

C.3

C.4
AND

AND

B.0

New BF

B.2

New BF

OR

B.3

M.6
(pre)

AND

B.1

C.9

New BF
OR

Limited
BF

M.2

AND

AND

C.8

C.6

OR

Limited
BF

M.2

AND

ÂŹM.2

M.5
(pre)
ÂŹM.5
(pre)

ÂŹM.6
(pre)

M.5
(pre)

(a) B.1 Excerpt

Limited
BF

M.2

AND

M.6
(pre)

OR

C.7

AND

AND

C.5

OR

ÂŹM.5
(pre)

M.6
(pre)

ÂŹM.2

ÂŹM.6
(pre)

M.5
(pre)

(b) C.5 Excerpt

C.10

ÂŹM.2
OR

ÂŹM.5
(pre)

ÂŹM.6
(pre)

(c) C.10 Excerpt

Figure 9.11: Brake Force Goal Update Excerpts of M 00
Table 9.3: Counterexample: Variables for Failure in Goal Model M 00
Variable
BF
CBF
DS1
DS2
RF
SF
SS

Value
0.40
0.40
0.0
0.0
MAX
MAX
false

Constrained In
E.3, D.11, D.13

C.10, SG.9
B.1, C.5, SG.7
E.6, D.6

Minimize Collision via Weak Mitigation
Without significant additional sensors and actuators, it is not possible to prevent a
collision simply by braking. For example, a completely stopped vehicle may still be unable
to avoid a frontal collision if another vehicle drives into it. In the event of a collision, it is
desirable to have a fail-safe, or behavior intended to preserve safe operation. In the case of
regenerative brakes, there is the possibility that batteries could be damaged in a collision
making it unsafe to recharge them. A weak mitigation model, such as the one in Figure 9.2b
could be used as a fail-safe to ensure that when the safety goal is violated, the regenerative
161

braking force (RF ) is set as low as possible to ensure no generation of electricity to recharge
the batteries while maximizing the standard braking force (SF ) in order to prevent charging
damaged batteries. Updating the woven goal model by weaving both the weak and strong
mitigations yields the goal model in Figure 9.12, referred to as M 000 .
Woven
Goal Model
AND

A
Maintain(Brake
System)

Weak Mitigation:
Minimize Collision
(f)

Strong Mitigation:
Avoid Collision
(f)

...

...

...

Figure 9.12: Model Woven With Weak & Strong Mitigation (M 000 )
Applying Soter to the goal model M 000 where, both the weak and strong mitigation
models have been woven indicates that both can fail due to an interaction. In the case
where the front distance sensors read 0.0, the weak mitigation model attempts to set the
regenerative brake force to MIN , while the strong mitigation attempts to set the same
regenerative brake force to MAX , resulting in an interaction between safety mitigations.
When the strong mitigation is the cause, the values of the counterexample variables are as
shown in Table 9.4.
Table 9.4: Counterexample: Variables for Failure in Goal Model M 000
Variable
BF
CBF
DS1
DS2
RF
SF
SS

Value
0.40
0.40
0.0
0.0
MIN
MAX
false

Constrained In
E.3, D.11, D.13

C.10, SG.9
B.1, C.5, SG.7
E.6, D.6

Since the strong mitigation is unable to prevent the violation of the safety goal, it should
have been removed when the weak mitigation was put in place. The model woven with only
162

the weak mitigation is shown in Figure 9.13, referred to as M f inal . Applying Soter to model
M f inal , which after analysis by Soter, has no interactions or safety violations.

Woven
Goal Model
AND

A
Maintain(Brake
System)

Weak Mitigation:
Minimize Collision
(f)

...

...

Figure 9.13: Model Woven With Updated Weak Mitigation (M f inal )

Summary
We have demonstrated that Soter can detect safety model violations (e.g., M 0 ), feature interactions between safety models and functional requirements (e.g., M 00 ), and feature
interactions between multiple safety models (e.g., M 000 ).

9.4.2

Safety Case Study: Battery Charging

This subsection gives the results of applying Soter to aspect-oriented safety models related to battery charging for the braking system goal model in Figure 7.1. Soter is used to
detect safety failures, safety model interactions with functional requirements, and interactions between safety models. The safety models used in this example application are defined
by the system designer. The safety goal modeled in this subsection is intended to ensure that
the battery is never overcharged, in order to prevent battery damage that could lead to fire
or explosion.
163

Maintain Safe Charge via Safety Property
Initially, a non-functional safety property is created (i.e., as shown in Figure 9.14b)
based on the template of a non-functional property (i.e., as shown in Figure 9.14a). The
non-functional safety property assesses one condition: if the battery has been charged to
100% or more (i.e., Battery Charge ­ 1.0). If that property is violated, then the safety
property is violated and must be mitigated.
...

PT
Battery Charge >=
MAX Battery

Trigger

NFG
Maintain(Safe
Charge)

Non-Functional
Goal

(b) Battery Safety Instantiation
(a) Template

Figure 9.14: Safety Model: Non-Functional Properties
The non-functional safety property model defined in Figure 9.14b is converted by Soter
into a feature by applying the template in Figure 9.15a, resulting in the non-functional safety
property feature defined in Figure 9.15b. As expected, the feature can only be satisfied if the
non-functional trigger is not satisfied, that is, when the battery is not charged to or beyond
100%. Due to the relative simplicity of the non-functional safety property, the translation
of the non-functional safety model to the feature instantiation in Figure 9.15b only requires
the negation of the single non-functional property.
Once Soter translates the non-functional safety property model in Figure 9.14b into
the feature represented in Figure 9.15b, the feature is woven into the functional goal model
by creating a new top-level goal and AND decomposing the new non-functional feature in
Figure 9.15b with the functional goal model in Figure 7.1. The complete woven goal model
is shown in Figure 9.16.
Soter analyzes the woven goal model in Figure 9.16 to detect any feature interactions
164

Non-Functional
Property
(f)

Non-Functional
Property:
Maintain(Safe
Charge) (f)

ÂŹ Trigger (post)
ÂŹPT (post)
...
(b) Battery Safety Instantiation

(a) Template

Figure 9.15: Non-Functional Feature: Non-Functional Properties
Woven
Goal Model
AND

A
Maintain(Brake
System)

Non-Functional
Property:
Maintain(Safe
Charge) (f)

...
...

Figure 9.16: Goal Model Woven With Non-Functional Battery Safety Property
or failures of the non-functional feature woven into the functional goal model. Since it is still
possible to use the regenerative brakes, which would result in a continued charging of the
battery, the non-functional safety property is able to fail. Therefore, a mitigation of some
form is required.

Maintain Safe Charge via Weak Mitigation
After the failure of the non-functional safety property, it is necessary to perform some
kind of mitigation. In this case, we attempt to create a weak mitigation (as shown in Figure 9.17b) based on the template of a non-functional weak mitigation (i.e., as shown in
Figure 9.17a). The effect of a weak mitigation is that in the event of a non-functional prop165

erty violation, in this case the violation of a safety property related to the amount a battery
is charged, the mitigation is required in an effort to minimize the negative impact of the
non-functional property violation. This weak mitigation works to ensure the regenerative
force braking is set to no force (i.e., 0.0) to ensure that the potentially damaged batteries
are no longer being charged.
...

PT
Battery Charge >=
MAX Battery

Trigger
NFG
Maintain(Safe
Charge)

Non-Functional
Goal

M
Achieve(Safe
Charge)
AND

Mitigation
Goal
M.1
Achieve(Apply
No Regen Force)

...

(a) Template

M.2 (post)
RF = 0.0

(b) Battery Safety Instantiation

Figure 9.17: Non-Functional Model: Weak Mitigation
The non-functional safety weak mitigation model defined in Figure 9.17b is converted
by Soter into a feature by applying the template in Figure 9.18a, resulting in the nonfunctional safety weak mitigation feature defined in Figure 9.18b. In order for the feature
representing the non-functional safety weak mitigation model to be satisfied, one of two
conditions must be true: either the non-functional trigger (i.e., ÂŹPT) is not violated or the
non-functional trigger is violated (i.e., PT) and the mitigation is performed. That is, when
the non-functional trigger indicates a violation, the mitigation (i.e., setting the regenerative
force to 0.0 to prevent battery charging) is required.
Once Soter translates the non-functional weak mitigation model in Figure 9.17b into
the feature represented in Figure 9.18b, the feature is woven into the functional goal model
by creating a new top-level goal and AND decomposing the new non-functional feature in
166

Weak Mitigation:
Maintain Safe Charge
(f)

Weak
Mitigation
(f)

OR

OR

Trigger and
Mitigation

ÂŹTrigger (post)

AND

...

AND

Trigger (pre)

Mitigation

...

...

ÂŹPT (post)

Trigger and
Mitigation

PT (pre)

M
AND

M.1

M.2 (post)

(a) Template
(b) Battery Safety Instantiation

Figure 9.18: Non-Functional Feature: Weak Mitigation
Figure 9.18b with the functional goal model in Figure 7.1. The complete woven goal model
is shown in Figure 9.19.

Woven
Goal Model
AND

A
Maintain(Brake
System)

Weak Mitigation:
Maintain Safe Charge
(f)

...

...

Figure 9.19: Goal Model Woven With Non-Functional Battery Safety Weak Mitigation

Soter analyzes the woven goal model in Figure 9.19 to detect any feature interactions
or failures of the non-functional feature woven into the functional goal model. Since it is
still possible to use the regenerative brakes, which would result in a continued charging of
the battery, the non-functional safety property is able to fail due to an interaction when
the non-functional property is violated, thus requiring a mitigation. However, the mitigation
(specifically M.2) conflicts with goal C.10 (i.e., ‘RF = 0.8 ∗ CBF ’) in the functional goal
model. However, a pre-condition requiring a non-violated non-functional property (i.e., ÂŹPT)
167

can be added to the children of goal C.4 to ensure the conflict does not occur. That is, goal
C.10 would never execute when M.2 was required as a mitigation. The update ensures the
battery is no longer charging once it has become dangerous to do so.

Maintain Safe Charge via Strong Mitigation
Based on the success of the weak mitigation in preventing additional charging, it may be
possible to mitigate issues with battery charging before a safety violation even takes place. In
this case, we attempt to create a strong mitigation (as shown in Figure 9.20b) based on the
template of a non-functional strong mitigation (i.e., as shown in Figure 9.20a). The effect of a
strong mitigation is that the mitigation should prevent the non-functional property violation
from ever occurring. In this case, the violation of a safety property is related to the amount
a battery is charged, and the mitigation is required to ensure the negative impact of the nonfunctional property violation never occurs. Rather than wait until the non-functional safety
property has been violated, the regenerative braking force is limited before the violation
occurs.
PT
Battery Charge >=
MAX Battery
...

NFG & M
Maintain(Safe
Charge)

Trigger

AND

Non-Functional
& Mitigation
Goal

M.1 (pre)
Battery Charge > 0.99

M.3 (post)
RF = 0

...

M.2
Achieve(Apply
Full Regen Force)

(a) Template

(b) Battery Safety Instantiation

Figure 9.20: Non-Functional Model: Strong Mitigation
168

The non-functional safety strong mitigation model defined in Figure 9.20b is converted
by Soter into a feature by applying the template in Figure 9.21a, resulting in the nonfunctional safety strong mitigation feature defined in Figure 9.21b. In order for the feature
representing the non-functional safety strong mitigation model to be satisfied, one of two
conditions must be true: either the non-functional trigger (i.e., ÂŹPT) is not violated or the
non-functional trigger is not violated and the mitigation is performed. That is, when strong
mitigation is performed, the non-functional trigger should not indicate a violation. Instead,
the mitigation (i.e., setting the regenerative force to 0.0 to prevent battery charging) prevents
the violation before it takes place.
Strong Mitigation:
Maintain Safe Charge
(f)

Strong
Mitigation
(f)

OR

OR

Trigger and
Mitigation

Trigger and
Mitigation

ÂŹTrigger (post)

ÂŹPT (post)

AND
...

AND

ÂŹPT (post)
ÂŹTrigger (post)

Mitigation

...

...

NFG & M
AND

M.1 (pre)

(a) Template

M.2

M.3 (post)

(b) Battery Safety Instantiation

Figure 9.21: Non-Functional Feature: Strong Mitigation
Once Soter translates the non-functional strong mitigation model in Figure 9.20b into
the feature represented in Figure 9.21b, the feature is woven into the functional goal model
by creating a new top-level goal and AND decomposing the new non-functional feature in
Figure 9.21b with the functional goal model in Figure 7.1. The complete woven goal model
is shown in Figure 9.22.
Soter analyzes the woven goal model in Figure 9.22 to detect any feature interactions
or failures of the non-functional feature woven into the functional goal model. Since it is still
possible to use the regenerative brakes, which would result in a continued charging of the
169

Woven
Goal Model
AND

A
Maintain(Brake
System)

Strong Mitigation:
Maintain Safe Charge
(f)

...

...

Figure 9.22: Goal Model Woven With Non-Functional Battery Safety Strong Mitigation
battery, the non-functional safety property is able to fail due to an interaction when the nonfunctional property is violated, requiring a mitigation. However, the mitigation (specifically
M.3) conflicts with goal C.10 in the functional goal, just as goal C.10 conflicted in the
weak mitigation. However, just as before, a pre-condition can be added to ensure that when
M.3 is mitigating, C.10 is not setting the regenerative brake force. Goal M.3 only sets the
regenerative brake force when M.1 is true, so adding ÂŹM.1 as a pre-condition to the children
of goal C.4 ensures the conflict does not occur. That is, goal C.10 would never execute when
M.2 is required as a mitigation. The update ensures the battery is no longer charged once it
has become close to violating the non-functional safety property.

Summary
We have demonstrated that Soter can detect safety interactions with functional requirements symbolically by demonstrating each of the three non-functional model types (property,
weak mitigation, and strong mitigation). Using the strong mitigation, we can prevent the
safety violation from ever occurring, making strong mitigation the clearly appropriate nonfunctional safety model to select since it can completely prevent the safety violation.

9.4.3

Performance Case Study

This subsection gives the results of applying Soter to aspect-oriented performance models for the braking system goal model in Figure 7.1. Soter is used to detect performance
170

interactions and failures. The performance models used in this example application are defined by the system designer. The performance goals modeled in this subsection are intended
to ensure that the battery is always charged to some minimal acceptable level to ensure that
the hybrid drive functionality is ensured to operate.

Maintain Charge via Safety Property
Initially, a non-functional performance property is created (as shown in Figure 9.23b)
based on the template of a non-functional property (as shown in Figure 9.23a). The nonfunctional performance property assesses one characteristic: if the battery has been discharged to less than 50% (i.e., Battery Charge < 50). If that property is violated, then the
performance property is violated and must be mitigated.
...

PT
Battery Charge < MIN
Desired Battery

Trigger

NFG
Maintain(Charge)

Non-Functional
Goal

(b) Safety Instantiation
(a) Template

Figure 9.23: Safety Model: Non-Functional Properties

The non-functional performance property model defined in Figure 9.23b is converted by
Soter into a feature by applying the template in Figure 9.24a, resulting in the non-functional
performance property feature defined in Figure 9.24b. The feature can only be satisfied if the
non-functional trigger is not satisfied, that is, when the battery is not discharged to less than
50%. Due to the relative simplicity of the non-functional performance property, the translation of the non-functional performance model to the feature instantiation in Figure 9.24b
only requires the negation of the single non-functional property.
Once Soter translates the non-functional performance property model in Figure 9.23b
171

Non-Functional
Property
(f)

Non-Functional
Property:
Maintain(Charge)
(f)

ÂŹ Trigger (post)
ÂŹPT (post)
...

(b) Performance Instantiation

(a) Template

Figure 9.24: Non-Functional Feature: Non-Functional Properties

into the feature represented in Figure 9.24b, the feature is woven into the functional goal
model by creating a new top-level goal and AND decomposing the new non-functional feature
in Figure 9.24b with the functional goal model in Figure 7.1. The complete woven goal model
is shown in Figure 9.25.

Woven
Goal Model
AND

A
Maintain(Brake
System)

Non-Functional
Property:
Maintain(Charge)
(f)

...
...

Figure 9.25: Goal Model Woven With Non-Functional Battery Performance Property

Soter analyzes the woven goal model in Figure 9.25 to detect any feature interactions
or failures of the non-functional feature woven into the functional goal model. Since it is still
possible to discharge the battery when driving, which may not be made up by subsequent
braking, the non-functional safety property is able to fail. Therefore, a mitigation of some
form is required.
172

Maintain Charge via Weak Mitigation
After the failure of the non-functional performance property, it is necessary to perform
some kind of mitigation. In this case, we attempt to create a weak mitigation (as shown
in Figure 9.26b) based on the template of a non-functional weak mitigation (as shown in
Figure 9.26a). The effect of a weak mitigation is that in the event of a non-functional property
violation, in this case, the violation of a performance property related to the amount a battery
is charged, the mitigation is required in an effort to minimize the impact of the non-functional
property violation. This weak mitigation works to ensure the regenerative force braking is
set to the entire commanded brake force to ensure that the batteries are charged as much as
possible.
...

PT
Battery Charge < MIN
Desired Battery

Trigger
NFG
Maintain(Charge)

Non-Functional
Goal
M
Achieve(Charge)
AND

Mitigation
Goal
M.1
Achieve(Apply
Full Regen Force)

...

(a) Template

M.2 (post)
RF = 1.0 * CBF

(b) Performance Instantiation

Figure 9.26: Non-Functional Model: Weak Mitigation
The non-functional performance weak mitigation model defined in Figure 9.26b is converted by Soter into a feature by applying the template in Figure 9.27a, resulting in the
non-functional performance weak mitigation feature defined in Figure 9.27b. In order for the
feature representing the non-functional performance weak mitigation model to be satisfied,
one of two properties must be true: either the non-functional trigger (i.e., ÂŹPT) is not violated or the non-functional trigger is violated (i.e., PT) and the mitigation is performed.
173

That is, when the non-functional trigger indicates a violation, the mitigation (i.e., setting
the regenerative force to the entire commanded brake force to maximize battery charging)
is required.
Weak Mitigation:
Maintain Charge
(f)

Weak
Mitigation
(f)

OR

OR

Trigger and
Mitigation

AND

...

AND

PT (pre)
Trigger (pre)

Mitigation

...

...

ÂŹPT (post)

Trigger and
Mitigation

ÂŹTrigger (post)

M
AND

M.1

M.2 (post)

(a) Template
(b) Performance Instantiation

Figure 9.27: Non-Functional Feature: Weak Mitigation
Once Soter translates the non-functional weak mitigation model in Figure 9.26b into
the feature represented in Figure 9.27b, the feature is woven into the functional goal model
by creating a new top-level goal and AND decomposing the new non-functional feature in
Figure 9.27b with the functional goal model in Figure 7.1. The complete woven goal model
is shown in Figure 9.28.
Woven
Goal Model
AND

A
Maintain(Brake
System)

Weak Mitigation:
Maintain Charge
(f)

...

...

Figure 9.28: Goal Model Woven With Non-Functional Battery Performance Weak Mitigation
Soter analyzes the woven goal model in Figure 9.28 to detect any feature interactions
174

or failures of the non-functional feature woven into the functional goal model. Since it is
still possible to drive the car without braking, which would result in a continued discharging
of the battery, the non-functional performance property is able to fail due to an interaction
when the non-functional property is violated, requiring a mitigation. However, the mitigation
(specifically M.2) conflicts with goal C.10 (i.e., ‘RF = 0.8 ∗ CBF ’) in the functional goal.
However, a pre-condition requiring a non-violated non-functional property (i.e., ÂŹPT) can be
added to the children of goal C to ensure the conflict does not occur by allowing the mitigation
to provide all the commanded brake force when the performance property is violated. That
is, goal C.10 would never execute when M.2 is required as a mitigation. The update ensures
the battery is charged once it has become low enough to be below the desired charge level.
While the mitigation cannot prevent further discharging of the battery, it is unlikely that
a strong mitigation will be found that guarantees the performance non-functional property
will remain unviolated.

Maintain Charge via Strong Mitigation
In this case, we attempt to create a strong mitigation to prevent the non-functional
performance property from every being violated. The strong mitigation is shown in Figure 9.29b) and is based on the template of a non-functional strong mitigation (as shown
in Figure 9.29a). The effect of a strong mitigation is that the mitigation should prevent
the non-functional property violation from ever occurring. In this case, the violation of a
performance property is related to the amount a battery is charged, and the mitigation is
required to ensure the negative impact of the non-functional property violation never occurs.
Rather than wait until the non-functional safety property has been violated, the regenerative
braking force is used to charge the battery before the violation.
The non-functional performance strong mitigation model defined in Figure 9.29b is
converted by Soter into a feature by applying the template in Figure 9.30a, resulting in
the non-functional performance strong mitigation feature defined in Figure 9.30b. In order
175

...

PT
Battery Charge < MIN
Desired Battery

Trigger
NFG & M
Achieve(Charge)

Non-Functional
& Mitigation
Goal
...

AND

M.1
Achieve(Apply
Full Regen Force)

(a) Template

M.2 (post)
RF > 0.1

(b) Performance Instantiation

Figure 9.29: Non-Functional Model: Strong Mitigation
for the feature representing the non-functional performance strong mitigation model to be
satisfied, one of two properties must be true: either the non-functional trigger (i.e., ÂŹPT) is
not violated or the non-functional trigger is not violated and the mitigation is performed.
That is, when strong mitigation is performed, the non-functional trigger should not indicate
a violation. Instead, the mitigation (i.e., setting the regenerative force to some amount to
attempt to ensure the battery is charged) prevents the violation before it takes place.
Once Soter translates the non-functional strong mitigation model in Figure 9.29b into
the feature represented in Figure 9.30b, the feature is woven into the functional goal model
by creating a new top-level goal and AND decomposing the new non-functional feature in
Figure 9.30b with the functional goal model in Figure 7.1. The complete woven goal model
is shown in Figure 9.31.
Soter analyzes the woven goal model in Figure 9.31 to detect any feature interactions
or failures of the non-functional feature woven into the functional goal model. Since it is
still possible to use the discharge brakes due to driving, the non-functional performance
property is able to fail due to an interaction when the non-functional property is violated,
requiring a mitigation. However, the mitigation (specifically M.2) conflicts with goal C.10 in
the functional goal, just as goal C.10 conflicted in the weak mitigation. However, this time it
is incorrect to give precedence to the mitigation over the functional braking system. Simply
176

Strong Mitigation:
Maintain Charge
(f)

Strong
Mitigation
(f)

OR

OR

Trigger and
Mitigation

Trigger and
Mitigation

ÂŹTrigger (post)

AND

...

AND

ÂŹPT (post)

ÂŹTrigger (post)

Mitigation

...

...

ÂŹPT (post)

NFG & M
AND

M.1

(a) Template

M.2 (post)

(b) Performance Instantiation

Figure 9.30: Non-Functional Feature: Strong Mitigation

Woven
Goal Model
AND

A
Maintain(Brake
System)

Strong Mitigation:
Maintain Charge
(f)

...

...

Figure 9.31: Goal Model Woven With Non-Functional Battery Performance Strong Mitigation

ensuring the regenerative brakes are on at all times will help to recharge the battery, but
will ultimately also reduce both the battery and gasoline energy stores.
Strong mitigation to ensure that the battery remains sufficiently charged exists, including those that would use the gas engine to charge the battery of a hybrid vehicle. However,
using the braking system alone, battery recharging may only be accomplished via braking
when the vehicle is moving. Since the vehicle may not brake often enough to ensure the
177

battery is charged, the best course of action is to mitigate the low battery state when it
occurs (i.e., weak mitigation).

Summary
We have shown that Soter can detect performance interactions with functional requirements symbolically with respect to each of the three non-functional model types (property,
weak mitigation, and strong mitigation). Given the interactions and potential updates to the
functional goal model, weak performance mitigation is the appropriate model to use since
there is no model that can reasonably prevent the safety violation from ever occurring within
the scope of the braking system.

9.4.4

Safety & Performance Case Study

This subsection gives the results of applying Soter to aspect-oriented safety models and
performance models for the braking system goal model in Figure 7.1. Soter is used to detect interactions between safety models, performance models, and the functional goal model
using symbolic analysis, a combination of symbolic analysis and evolutionary computation
(SA+EC), and finally via generated run-time detection code. The models used in this example application are defined by the system designer.

Interactions Detected via Symbolic Analysis
The braking system goal model in Figure 7.1 has been previously woven with three necessary non-functional models: the weak mitigations for maintaining charge and minimizing
collision and the strong mitigation for maintaining a safe charge amount (Figures 9.18b,
9.5b, and 9.30b, respectively). Soter weaves these three non-functional models that have
been translated to features into the braking system goal model in Figure 7.1 resulting in the
woven goal model shown in Figure 9.32.
Applying Soter to detect interactions due to the inclusion of non-functional properties
178

Woven
Goal Model
(SPM)
AND

A
Maintain(Brake
System)

Weak Mitigation:
Maintain Charge
(f)

Weak Mitigation:
Minimize Collision
(f)

...

...

...

Strong Mitigation:
Maintain Safe Charge
(f)
...

Figure 9.32: Woven Model: Functional With Both Safety and Performance Mitigation
in the overall goal model (i.e., the woven goal model shown in Figure 9.32) results in the
following interactions caused by failures in:

• Weak Mitigation: Maintain Charge: As illustrated in the previous section describing this mitigation, it is still possible to drive the car without braking, which would
result in a continued discharging of the battery. The non-functional performance property is able to fail due to an interaction when the non-functional property is violated,
thus requiring a mitigation. However, the mitigation (specifically M.2) conflicts with
goal C.10 in the functional goal. However, a pre-condition requiring a non-violated
non-functional property (i.e., ÂŹPT) can be added to the children of goal C to ensure
the conflict does not occur by allowing the mitigation to provide all the commanded
brake force when the performance property is violated. That is, goal C.10 would never
execute when M.2 was required as a mitigation. The update ensures the battery is
charged once it has become low enough to be below the desired charge level. While the
mitigation cannot prevent further discharging of the battery, it is unlikely that a strong
mitigation will be found that guarantees the performance non-functional property will
remain unviolated.
• Weak Mitigation: Minimize Collision: Since this weak mitigation sets both the
standard brake force and the regenerative brake force, an interaction can exist whenever
the braking system has a commanded brake force that is used to set either of the
179

standard or regenerative brake forces to a value outside of the weak safety mitigation
(i.e., goals B.1, C.5, and C.10). To prevent this interaction, the functional goal model
must be updated according to the changes specified in the previous section describing
this mitigation and detailed in Figures 9.11a, 9.11b, and 9.11c for goals B.1, C.5, and
C.10, respectively.
• Strong Mitigation: Maintain Safe Charge: As illustrated in the previous section
describing this mitigation, it is still possible to use the regenerative brakes, which would
result in a continued charging of the battery, the non-functional safety property is able
to fail due to an interaction when the non-functional property is violated, requiring a
mitigation. However, the mitigation (specifically M.3) conflicts with goal C.10 in the
functional goal, just as goal C.10 conflicted in the weak mitigation. However, just as
before, a pre-condition can be added to ensure that when M.3 is mitigating, C.10 is
not setting the regenerative brake force. Goal M.3 only sets the regenerative brake
force when M.1 is true, so adding ÂŹM.1 as a pre-condition to the children of goal C.4
ensures the conflict does not occur. That is, goal C.10 would never execute when M.2
was required as a mitigation. The update ensures the battery is no longer charged once
it has become close to violating the non-functional safety property.

Using symbolic analysis available to Soter, each of the non-functional models that have
been translated into features and included in the woven goal model (i.e., in Figure 9.32)
can fail to be satisfied due to a feature interaction across functional and non-functional
specifications. For example, Table 9.5 shows a scenario where the functional model is satisfied
and yet every single one of the non-functional features is unsatisfied due to an interaction.

Interactions Detected via SA+EC
Soter-EC combines SA and EC by making use of Phorcys-EC to detect failures in
all three non-functional features (i.e., features Weak Mitigation: Maintain Charge, Weak
180

Table 9.5: Example Counterexample for Non-Functional FI Causes
Variable
SF
CBF
PBF
RF
BF
SS
FD Sensor 1
FD Sensor 2
Battery Charge

Value
0.07
0.35
0.0
0.28
0.35
true
0.0
0.0
M AX

Mitigation: Minimize Collision, and Strong Mitigation: Maintain Safe Charge)
as features that can fail due to FIs, just as they were identified in the SA-only method
when woven with the functional goal model individually. In all 50 executions of the genetic algorithm where each feature was analyzed for failure due to a FI, at least 97% of the
population succeeded in finding a counterexample (i.e., FI).
Regardless of which feature, or features, failed due to the FI, at least 99.9% of the FIs
identified included unique environmental variable values. That is, the FI counterexamples
identified were almost always completely unique and every set of counterexamples (i.e., in
a population of 200 identified by the SA+EC) included significant diversity as measured
by the Manhattan distance of the environmental scenarios. This diversity is illustrated in
Figures 9.33a, 9.33b and 9.33c that show the range (distance from minimum to maximum)
each environmental variable took across each set of 200 individuals in the SA+EC analysis,
where the box plot represents all 50 executions of the SA+EC. It should be noted, that it is
expected that some of the ranges are limited since they represent the ranges of environmental
variable values necessary for FIs to cause a feature to fail.
In all three cases, we can see that Charge, Dist, SF , SS , PBF , and RF have a large
range of values while the remainder (i.e., BF and CBF ) are limited due to the smaller
range of those environmental variable values when FIs occur. Variables with a smaller range
displayed are more likely to have an impact on the expression of the feature interaction,
181

●

0.4

●

0.2

●

●

0.0

●

0.6

●
●
●

0.4
0.2

(a) Weak Mitigation:
Maintain Charge

(b) Weak Mitigation:
Minimize Collision

SS

PBF

SF

●

CBF

Dist

●

BF

●

0.0
Charge

RF

SS

CBF

●

PBF

●

SF

●

BF

Dist

Charge

RF

SS

●
●

PBF

CBF

●
●

●

SF

Dist

Charge

0.0

●

●
●
●

●

RF

0.4

0.6

●
●
●
●
●
●
●

●
●

0.8

●

Execution Range

●

1.0

●
●
●
●

0.8
●

0.6

0.2

●

●
●
●

●

BF

Execution Range

0.8

1.0

●
●
●

●
●
●
●
●
●
●

Execution Range

1.0

(c) Strong Mitigation:
Maintain Safe Charge

Figure 9.33: Environmental Variables for Non-Functional Failures due to FI
due to the feature interaction only occurring over a small portion of the variable’s range.
However, variables with a larger range displayed are less likely to have an impact on the
expression of the feature interaction, since a feature interaction could be expressed over a
large portion of the variable’s range. System designers can use this information to assess the
types of situations in which an interaction could occur, possibly directing additional testing
to scenarios more likely to be adversely impacted by feature interactions.

Interactions Detected at Run Time
Soter-RT generates run-time code using Thoosa. Given the SA+EC analysis already
applied (using Soter-EC), there are more than 9,750 individual and diverse examples for
each of the three non-functional models (i.e., Weak Mitigation: Maintain Charge, Weak
Mitigation: Minimize Collision, and Strong Mitigation: Maintain Safe Charge)
that have been converted into features. That is, they are the causes of feature interactions, all of which are non-functional features converted from non-functional models. Each of
these non-functional features has been previously identified using SA+EC to have multiple
counterexamples.
The run-time detection code is verified by applying the set of individuals in the genetic
population that identify known failures due to feature interactions, and ensuring that the en182

vironmental and system scenarios described by those individuals result in a detected feature
interaction at simulated run time. In the case of the more than 29,000 individual examples
identified by the SA+EC detection process, all (100%) are correctly detected and reported
by the generated run-time detection code. That is, we use the existing counterexamples
identified by SA+EC and initialize the run-time detection code with the values identified to
simulate the scenario in order to verify the run-time detection code.

Functional Goal Model Updates and Re-analysis
Finally, the functional goal model originally introduced in Figure 7.1 must be updated
to ensure the mitigations put in place by the non-functional features remain in effect. The
updated functional goal model is shown in Figure 9.34 that is based on Figure 7.1 with the
following changes made to the functional goal model to mitigate the feature interactions:

1. The functional goal model must be updated according to the changes specified in the
previous section describing this mitigation and detailed in Figures 9.11a, 9.11b, and
9.11c for goals B.1, C.5, and C.10, respectively.

2. The functional goal model must be updated to constrain the satisfaction of goal C.4
such that it is only specified if Battery Charge ­ 0.50 by adding such a pre-condition
(i.e., C.New2) as one of goal C.4’s decomposed goals.

3. The functional goal model must be updated to constrain the satisfaction of goal C such
that it is only specified if Battery Charge < 1.0 by adding such a pre-condition (i.e.,
C.New1) as one of goal C’s decomposed goals.

Applying Soter to the functional goal model updated by these three changes and woven
into Figure 9.32 results in no further interactions.
183

A
Maintain(Brake
System)
AND

A.1
Maintain(Brake
Force)

A.2
Maintain(Brake
Command)

OR

OR

E (f)
Achieve(Continuous
Braking)

C (f)
Achieve(Regen
Braking)

AND

AND

E.1 (post)
CBFt =

E.2
Achieve(Read
CBF)

CBF
C.2
Achieve(Regen
& Standard Force)

C.1 (pre)
CBFt+1 > 0

E.3 (post)
CBFt+1 = BF

OR

C.New1 (pre)
Battery Charge < 0

E.6 (pre)
SS = false

E.4
Achieve(Read
Brake Force)

E.7
Achieve(
Read SS)

E.5 (pre)
BF > 0

D (f)
Achieve(AntiLock Braking)

C.4
AND

AND

C.8

C.9

New BF
OR

B (f)

AND

AND

New BF

B.2

M.6
(pre)

OR

Limited
BF

M.2
AND

M.6
(pre)

B.3

AND

B.1

D.1 (post)
CBFt =

Limited
BF

M.2

AND

B.0

C.New2 (pre)
Battery Charge >= 0.5

M.5
(pre)

C.10

CBF

ÂŹM.2
OR

ÂŹM.5
(pre)

D.5
Achieve(Brake
Pulse)

D.3 (pre)
BF > 0

D.2
Achieve(Read
CBF)

OR

D.4
Achieve(Read
Brake Force)

D.8
Achieve(Brake
On)

D.10 (pre)
CBFt = 0

C.3

D.9
Achieve(Brake
Off)

AND

ÂŹM.6
(pre)

ÂŹM.2

D.6 (pre)
SS = true

D.11 (post)
CBFt+1 = BF

D.12
Achieve(Brake
Force Change)

D.7
Achieve(Read
Slip Sensor)

AND

D.13 (post)
CBFt+1 = 0

D.14 (pre)
CBFt > 0

OR

M.5
(pre)

AND

ÂŹM.5
(pre)

ÂŹM.6
(pre)

New BF

C.6

OR

Limited
BF

M.2
AND

M.6
(pre)
M.5
(pre)

C.7

AND

C.5

ÂŹM.2
OR

ÂŹM.5
(pre)

ÂŹM.6
(pre)

Figure 9.34: Final Braking System Goal Model

Summary

We have demonstrated that Soter can detect interactions between safety and performance models in an example of one of two weak mitigations (i.e., safety or performance)
that failed due to a conflict with the other weak mitigation. Therefore, Soter can detect
failures due to interactions when multiple aspect oriented non-functional goal models fail
due to an interaction.
184

9.5

Related Work

Aspect-oriented requirements engineering allows for early separation of concerns, including cross-cutting safety and performance concerns [77]. However, aspect interactions
may introduce failures early in the development process and require continued research [74].
This section broadly covers existing AORE work, especially as it relates to explicit modeling
of safety and detecting interactions in aspect-oriented requirements.
Non-functional goals and properties are currently represented in GORE by directed
edges that connect goals or properties. In KAOS goal modeling, non-functional goals may
be included in the requirements decomposition or defined by obstacles and mitigations that
are connected to goals or requirements [87]. For i*, non-functional goals are connected to
existing GORE elements based on the impact of the non-functional goal to the connected
element [95]. The non-functional models defined using the Soter process are defined in relation
to a non-functional concern, represented as an aspect-oriented non-functional goal model and
is developed independently of the dominant decomposition.
Methods for modeling aspect-oriented requirements exist in multiple modeling
paradigms, including UML [8] and GORE [91]. Existing requirements models can even be
analyzed to identify candidate aspect-oriented requirements [79]. The Soter process is applied
to GORE models specifically for analyzing cross-cutting non-functional concerns, including
safety and performance.
Aspect interactions occur when separate and conflicting aspects are woven into the same
model [71]. While aspect interaction detection in Aspect-Oriented Programming (AOP) can
detect behavioral interactions [42, 90, 3], aspect interactions can also occur at the requirements level. Soter operates at the requirements level modeled by goals and detects aspect
interactions in the corresponding goal models.
In aspect-oriented requirements engineering, aspect interactions can be detected in textual requirements [80], but more often, formalized models are used [71, 72, 73]. Some methods
include conflict resolution for interactions [80, 19]. Soter differs from existing AORE aspect
185

interaction detection methods in that it identifies the failure caused by the interaction and is
applied specifically to safety and performance non-functional concerns and directly utilizes
the similarity between aspect and feature interactions by translating cross-cutting safety
goals into formally analyzable features.

9.6

Conclusion

In this chapter, we have presented Soter, a design-time and run-time approach for detecting aspect interactions and non-functional model violations in aspect-oriented non-functional
models. Unlike previous methods of detecting aspect interactions, Soter leverages the similarity between feature interaction and aspect interaction by using feature interaction detection
techniques with aspect-oriented non-functional models translated into features.
We demonstrate Soter on an industry-based automotive braking system. We show that
Soter is able to automatically detect safety and performance-based violations and aspect
interactions in fractions of a second by translating aspect-oriented non-functional models
into features and analyzing those features while maintaining traceability to the original
models. Additionally, Soter-EC applies SA+EC to identify multiple diverse counterexamples
that can be used by the system designer to more fully assess the impact of the interaction.
Finally, Soter-RT generates run-time detection code and ensures the generated code can
detect known counterexamples identified via Soter-EC.

186

Chapter 10
Contributions
This chapter summarizes our contributions with respect to the detection of incomplete
requirements decompositions and feature interactions in the fields of software and requirements engineering. Additionally, we also propose future investigations to complement this
body of work.

10.1

Summary of Contributions

Given the increasing complexity and intrinsic uncertainty in specifying cyber-physical
systems, the design-time assurance of requirements specifications is necessary to reduce and,
if possible, eliminate the proliferation of specification errors. Errors in the specification of
cyber-physical systems may be introduced in several ways. First, specification errors may be
introduced due to an idealized view of the environment where requirements do not account for
environmental uncertainty. Second, specification errors may be introduced due to conflicting
specifications due to system uncertainty. Due to the growth of system and environmental
uncertainty in cyber-physical systems, researchers are actively exploring the analysis and
detection of counterexamples in the specification of cyber-physical systems at design-time [4].
We have presented several methods to automatically identify counterexamples to completeness and consistency of requirements by identifying incomplete requirements and feature
187

interactions. First, we applied Ares, Ares-EC, and Lykus (i.e., a set of incomplete requirements detection tools) to detect incomplete requirements decompositions within a modelbased hierarchical requirements decomposition. Second, we applied Phorcys, Phorcys-EC,
and Thoosa (i.e., a set of feature interaction detection tools) to detect n-way feature interactions between the functional feature requirements specifications. Finally, we have applied
Soter to non-functional requirements, including safety and performance non-functional requirements. We have demonstrated these approaches to requirements models related to the
adaptive cruise control and braking systems, both of which are examples of onboard automotive system.

The methods and tools presented in this body of work fit within a general framework
represented by the DFD in Figure 10.1. First, a problem is converted to propositional logic
allowing for the creation of a method to verify solutions as correct or incorrect (i.e., detect if
an existing solution for the propositional logic satisfies the propositional logic) and a method
to solve problems by creating solutions (i.e., generating a new solution for the propositional
logic that is known to satisfy the propositional logic). Since each of these problems can be
used to represent any instance of 3-SAT, an NP-Complete problem [62], verifying solutions
(i.e., checking if the solution satisfies the propositional logic) can be done quickly (i.e., in
polynomial time) while the worst case for generating a new solution (i.e., generating a new
solution that satisfies the propositional logic) is not in polynomial time. Where the faster
solution verification method can be used to analyze either at run time or as part of a fitness
function within a genetic algorithm, the slower solution generation method can be used to
generate single results. These methods (i.e., solution verification and solution generation)
can be employed to generate multiple solutions via a combination of evolutionary computation (EC) and symbolic analysis (SA), potentially multiple results as they are encountered
individually at run time via verification of potential solutions (i.e., streaming results), or
a single result via symbolic analysis of the solution generation method. Subsequently, we
188

identify the portions of the DFD in relation to the chapters presented in this body of work.
The remainder of the contributions and future work are identified within this framework.

Manual
Definition

Problem
Problem
Properties
Conversion
Tool

Automatic Definition

Produce
Verification
Method

Propositional
Logic

method

Produce
Solution
Method
method

Run-time
Method

SA+EC
Method

SA
Method

counterexample

counterexamples

counterexample

Streaming
Results

Multiple
Results

Single
Results

Figure 10.1: General Framework DFD

10.1.1

Requirements Incompleteness

We detect incomplete requirements decomposition in hierarchical requirements models.
We illustrate our approach by analyzing a requirements model of an industry-based auto189

motive adaptive cruise control system. We describe the following techniques that we are
developing to address this problem:

1. Symbolic analysis (Ares) to formally define requirements incompleteness and guarantee
detection of requirements completeness counterexamples if they exist [37].

2. Evolutionary computation and symbolic analysis (Ares-EC) to detect a representative
range of requirements completeness counterexamples [38].

3. Run-time analysis (Lykus) to detect incomplete requirements at run time [39].

Figure 10.2 depicts the applicability of the generalized framework (i.e., Figure 10.1) for
the three pieces of work in the requirements incompleteness space.
190

Manual
Definition

Incomplete
Requirements
Properties

Incomplete Req
Conversion Tool

Automatic Definition

Produce
Verification
Method

Propositional
Logic

method

Produce
Solution
Method
method

Lykus

Ares-EC

Ares

counterexample

counterexamples

counterexample

Streaming
Results

Multiple
Results

Single
Results

Figure 10.2: Requirements Completeness DFD

10.1.2

Feature Interactions

We detect unwanted n-way feature interactions and determining their causes at the
requirements level. Unlike previous n-way feature interaction detection approaches that attempt to enumerate every set of interacting features, our approach analyzes each feature
for its ability to cause an interaction with other features, thus reducing designer assessment
effort to be linear with respect to the number of features. We illustrate our approach by
191

applying our approach to an industry-based automotive braking system comprising multiple
subsystems. We describe the following techniques that we have developed for this dissertation:

1. Phorcys: Symbolic analysis to formally define feature interactions and guarantee detection of interactions if they exist [40].

2. Phorcys-EC: Evolutionary computation and symbolic analysis to detect a representative
range of feature interactions [40].

3. Thoosa: Run-time analysis to detect feature interactions at run time.

Figure 10.3 demonstrates the applicability of the generalized framework (i.e., Figure 10.1) for the three pieces of work in the feature interaction detection space.
192

Manual
Definition

Feature
Interactions
Properties
FI
Properties
FI Conversion
Tool

Automatic Definition

Produce
Verification
Method

Propositional
Logic

method

Produce
Solution
Method
method

Thoosa

Phorcys-EC

Phorcys

counterexample

counterexamples

counterexample

Streaming
Results

Multiple
Results

Single
Results

Figure 10.3: Feature Interaction DFD

10.1.3

Non-functional Interactions

We detect feature interactions that include safety and/or performance non-functional
requirements and may include, but are not limited to include, functional requirements. We
illustrate our approach by applying it to detect unwanted interactions in the safety models
and requirements of an industry-based automotive braking system. We apply the detection
method to the following types of non-functional requirements:
193

1. Safety requirements, and

2. Performance requirements.

Figure 10.4 depicts the applicability of the generalized framework (i.e., Figure 10.1) for
the non-functional interaction detection.

Manual
Definition

Non-Functional
Interactions
Properties
Non-Functional FI
Properties
Non-Functional
Conversion Tool

Automatic Definition

Produce
Verification
Method

Propositional
Logic

method

Produce
Solution
Method
method

Soter-RT

Soter-EC

Soter

counterexample

counterexamples

counterexample

Streaming
Results

Multiple
Results

Single
Results

Figure 10.4: Non-Functional Interactions DFD
194

10.2

Future Investigations

This dissertation has presented a framework for applying symbolic analysis, evolutionary
computation, and run-time detection to feature interactions, requirements completeness, and
non-functional feature interactions. Given these results, we now describe future work that
would complement what has been presented in this dissertation. Each of these is described
in turn.

10.2.1

Requirements Incompleteness Caused by FI

While we detect both incomplete requirements decomposition and feature interactions
within this work, we do not consider the combination of the two problems. However, there
are almost certainly situations where a specification cannot act as it is intended due to a
feature interaction. Those instances may introduce requirements incompleteness that are
not inherent to the local structure of the decomposition, but the cross-cutting structure of
conflicting specifications. Whereas our requirements completeness work analyzes each decomposition independently of the remaining specification, an interaction outside of that
individual decomposition may introduce an incompleteness not previously detected. We envision analyzing the entire specification for incomplete decompositions and identifying if any
of the unsatisfied requirements are due to a feature interaction.

10.2.2

Partial Feature Interactions

Currently the feature interaction logic that is generated by Phorcys applies logic-based
on discrete satisfaction of the features in questions. The satisfaction of those features is
derived from the satisfaction of the decomposed goals, requirements, and expectations that
make up those features. However, Phorcys does not take into account partial satisfaction, or
satisficement, of goal model elements that would correspond to a partially-satisfied feature.
Naturally, an interaction between two (or more) features is a conflict that allows for a trade195

off between two (or more) features that are partially satisfied. We envision extending the
Phorcys work to include feature interaction detection logic for partially satisfied features,
allowing for multi-objective optimization of the trade-offs between features.

10.2.3

Partial Requirements Incompleteness

Currently the case study for requirements incompleteness includes no RELAXed or AutoRELAXED requirements [49], despite the use of satisficement to measure the proportional
satisfaction of each requirement. As such, results are binary for requirements incompleteness,
while RELAXed (or otherwise proportionally satisfied) requirements may result in partial
requirements incompleteness due to their own intrinsic proportional satisfaction. We envision
the application of the Ares set of tools to RELAXed goal models to automatically detect
partial requirements incompleteness.

10.2.4

Automatic Mitigation Strategies

The methods detailed in this work focus on the detection of problematic states. Even
the work on non-functional interactions where mitigations are included requires manual definition of the mitigations. However, significant existing work exists in dynamically adaptive
software systems that could be leveraged to employ adaptation when such problematic states
are encountered. The adaptive mitigation techniques can be particularly applicable to the
Thoosa, Lykus, and Soter run-time detection methods detailed within this work.

10.2.5

Non-Functional Security Interactions

The non-functional interaction detection in this work has been shown to be applicable
to both safety and performance non-functional goals. However, the detection method is
generally applicable to all non-functional requirements. We envision the application of the
existing framework to include case studies with non-functional security requirements.
196

10.2.6

Incomplete Test Sets

Similar to requirements completeness, which depends on the complete decomposition of
a parent requirement by its children, individual requirements should be tested by a complete
set of tests. That is, the functionality defined by the parent should be completely covered
by the set of tests that exercise the system. If a specific instance of functionality exists that
is not tested, the test set is incomplete. We envision using the Ares tool set to describe
requirements and their tests as parent and child requirements where the child requirements
are OR decomposed (i.e., disjunct) from one another.

197

APPENDICES

198

Appendix A
Incomplete Requirements Artifacts
This appendix presents the goal model specifications as well as the satisfiability-modulo
theory (SMT) solver and code (C++) outputs from the Ares and Lykus tools for incomplete
requirements detection. Incomplete requirements artifacts are included in this appendix since
no complete example can be given, due to issues of space, within Chapters 3 and 5.

A.1

Goal Model Specifications

This section of the appendix includes the XML schema for representing goal models in
XML, as well as XML representations of the adaptive cruise control system goal model used
in Chapters 3, 4, and 5.

A.1.1

Goal Model Schema
Listing A.1: XSD Goal Model XML Schema for Incomplete Requirements

1 <?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?>
2 <xs : schema xmlns : xs=”h t t p : / /www. w3 . o r g /2001/XMLSchema”
3
elementFormDefault=” q u a l i f i e d ”
4
xmlns : x s i =”h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ”>
5
<xs : e l e m e n t name=”g o a l m o d e l”>
6
<xs : complexType>
7
<xs : sequence >

199

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

<xs : e l e m e n t r e f =”g o a l ”/>
<xs : e l e m e n t r e f =”environment”/>
</xs : sequence >
</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”environment”>
<xs : complexType>
<xs : sequence >
<xs : e l e m e n t minOccurs=”0” maxOccurs=”unbounded ” r e f =”env”/>
</xs : sequence >
</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”env”>
<xs : complexType>
<xs : a t t r i b u t e name=”name” u s e=” r e q u i r e d ” type=”xs : NCName”/>
<xs : a t t r i b u t e name=” r e l a t i o n s h i p ” u s e=” r e q u i r e d ” type=”xs :
s t r i n g ”/>
</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”g o a l ”>
<xs : complexType>
<xs : c h o i c e >
<xs : e l e m e n t maxOccurs=”unbounded ” r e f =”g o a l ”/>
<xs : e l e m e n t r e f =”a g e n t ”/>
</xs : c h o i c e >
<xs : a t t r i b u t e name=”c o n t e n t s ” u s e=” r e q u i r e d ” type=”xs : s t r i n g
”/>
<xs : a t t r i b u t e name=”name” u s e=” r e q u i r e d ” type=”xs : NCName”/>
<xs : a t t r i b u t e name=” r e l a t i o n s h i p ” u s e=” r e q u i r e d ” type=”xs :
s t r i n g ”/>
<xs : a t t r i b u t e name=”type ” u s e=” r e q u i r e d ” type=”xs : NCName”/>
</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”a g e n t”>
<xs : complexType>
<xs : a t t r i b u t e name=”c o n t e n t s ” u s e=” r e q u i r e d ” type=”xs : s t r i n g
”/>
<xs : a t t r i b u t e name=” l o c a t i o n ” u s e=” r e q u i r e d ” type=”xs : NCName
”/>
<xs : a t t r i b u t e name=”name” u s e=” r e q u i r e d ” type=”xs : NCName”/>
</xs : complexType>
</xs : element>
</xs : schema>

200

A.1.2

Incomplete Requirements Goal Model for Adaptive Cruise
Control System
Listing A.2: Incomplete ACC Goal Model

1 <?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?>
2 <!−− c r e a t e d with XMLSpear −−>
3 <g o a l m o d e l xmlns : x s i =”h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ”
x s i : noNamespaceSchemaLocation =’ g o a l m o d e l . xsd ’>
4
5
<g o a l name=”A. 1 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”t r u e ” type=”OR”>
6
<g o a l name=”A. 2 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(and2 (EQUALS
C r u i s e S w i t c h S e n s o r 0 . 0 ) (EQUALS C r u i s e A c t i v e S e n s o r 1 . 0 ) )
” type=”AND”>
7
<g o a l name=”A. 6 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e S w i t c h S e n s o r 0 . 0 ) ” type=”PRE”>
8
</g o a l >
9
<g o a l name=”A. 7 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e A c t i v e S e n s o r 1 . 0 ) ” type=”REQ”>
10
</g o a l >
11
<g o a l name=”A. 8 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e A c t i v e S w i t c h 0 . 0 ) ” type=”REQ”>
12
</g o a l >
13
</g o a l >
14
<g o a l name=”A. 3 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(and (=
C r u i s e S w i t c h S e n s o r f a l s e ) (= C r u i s e A c t i v e S e n s o r f a l s e ) ) ”
type=”AND”>
15
<g o a l name=”A. 9 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e S w i t c h S e n s o r 0 . 0 ) ” type=”PRE”>
16
</g o a l >
17
<g o a l name=”A. 1 0 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e A c t i v e S e n s o r 0 . 0 ) ” type=”PRE”>
18
</g o a l >
19
<g o a l name=”A. 1 5 a ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(and2 (
EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) (EQUALS
B r a k e P e d a l S e n s o r BrakeActuator ) ) ” type=”AND”>
20
<g o a l name=”A. 1 6 a ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) ”
type=”AND”>
21
<g o a l name=”A. 1 8 a ” c o n t e n t s =”NA” r e l a t i o n s h i p =”
t r u e ” type=”REQ”>
22
</g o a l >
23
<g o a l name=”A. 1 9 a ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(EQUALS T h r o t t l e P e d a l S e n s o r
T h r o t t l e A c t u a t o r ) ” type=”PRE”>
24
</g o a l >

201

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

</g o a l >
<g o a l name=”A. 1 7 a ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) ” type=”
AND”>
<g o a l name=”A. 2 0 a ” c o n t e n t s =”NA” r e l a t i o n s h i p =”
t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”A. 2 1 a ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) ”
type=”PRE”>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”A. 4 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(and (=
C r u i s e S w i t c h S e n s o r t r u e ) (= C r u i s e A c t i v e S e n s o r f a l s e ) ) ”
type=”AND”>
<g o a l name=”A. 1 1 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e S w i t c h S e n s o r 1 . 0 ) ” type=”PRE”>
</g o a l >
<g o a l name=”A. 1 2 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e A c t i v e S e n s o r 0 . 0 ) ” type=”PRE”>
</g o a l >
<g o a l name=”A. 1 5 b” c o n t e n t s=”NA” r e l a t i o n s h i p =”(and2 (
EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) (EQUALS
B r a k e P e d a l S e n s o r BrakeActuator ) ) ” type=”AND”>
<g o a l name=”A. 1 6 b” c o n t e n t s=”NA” r e l a t i o n s h i p =”(
EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) ”
type=”AND”>
<g o a l name=”A. 1 8 b” c o n t e n t s=”NA” r e l a t i o n s h i p =”
t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”A. 1 9 b” c o n t e n t s=”NA” r e l a t i o n s h i p
=”(EQUALS T h r o t t l e P e d a l S e n s o r
T h r o t t l e A c t u a t o r ) ” type=”PRE”>
</g o a l >
</g o a l >
<g o a l name=”A. 1 7 b” c o n t e n t s=”NA” r e l a t i o n s h i p =”(
EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) ” type=”
AND”>
<g o a l name=”A. 2 0 b” c o n t e n t s=”NA” r e l a t i o n s h i p =”
t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”A. 2 1 b” c o n t e n t s=”NA” r e l a t i o n s h i p
=”(EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) ”
type=”PRE”>
</g o a l >

202

51
52
53
54

55
56
57
58
59

60

61

62

63

64
65
66
67

68
69
70

71

72

</g o a l >
</g o a l >
</g o a l >
<g o a l name=”A. 5 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(and (=
C r u i s e S w i t c h S e n s o r f a l s e ) (= C r u i s e A c t i v e S e n s o r t r u e ) ) ”
type=”AND”>
<g o a l name=”A. 1 3 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e S w i t c h S e n s o r 1 . 0 ) ” type=”PRE”>
</g o a l >
<g o a l name=”A. 1 4 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e A c t i v e S e n s o r 1 . 0 ) ” type=”PRE”>
</g o a l >
<g o a l name=”B. 1 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”( o r 3 (
EQUALS S p e e d t S p e e d t p l u s 1 ) (GREATER S p e e d t
S p e e d t p l u s 1 ) ( LESS D i s t a n c e S a f e D i s t a n c e ) ) ” type
=”OR”>
<g o a l name=”B. 2 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”( o r 2 (
and2 (EQUALS S p e e d t 0 . 0 ) (EQUALS S p e e d t p l u s 1
0 . 0 ) ) (GREATER S p e e d t S p e e d t p l u s 1 ) ) ” type=”
AND”>
<g o a l name=”B. 3 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
o r 2 ( and2 (EQUALS S p e e d t 0 . 0 ) (EQUALS
S p e e d t p l u s 1 0 . 0 ) ) (GREATER S p e e d t
S p e e d t p l u s 1 ) ) ” type=”OR”>
<g o a l name=”B. 4 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(LESS T h r o t t l e A c t u a t o r
T h r o t t l e P e d a l S e n s o r ) ” type=”AND”>
<g o a l name=”B. 5 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS T h r o t t l e A c t u a t o r
T h r o t t l e P e d a l S e n s o r ) ” type=”REQ”>
</g o a l >
<g o a l name=”B. 6 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”B. 7 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER
T h r o t t l e P e d a l S e n s o r 0 . 0 ) ” type=”PRE
”>
</g o a l >
</g o a l >
<g o a l name=”B. 1 5 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER BrakeActuator
B r a k e P e d a l S e n s o r ) ” type=”AND”>
<g o a l name=”B. 1 6 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER BrakeActuator
B r a k e P e d a l S e n s o r ) ” type=”REQ”>
</g o a l >

203

73
74
75

76
77

78
79
80
81

82

83

84
85

86
87
88

89

90
91

92
93
94
95
96

<g o a l name=”B. 1 7 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”B. 1 8 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(EQUALS
T h r o t t l e P e d a l S e n s o r 0 . 0 ) ” type=”PRE
”>
</g o a l >
<g o a l name=”B. 1 9 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS B r a k e P e d a l S e n s o r
1 . 0 ) ” type=”PRE”>
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”B. 8 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
o r 2 (GREATER S p e e d t D e s i r e d S p e e d ) ( LESS
D i s t a n c e S a f e D i s t a n c e ) ) ” type=”OR”>
<g o a l name=”B. 9 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(GREATER S p e e d t D e s i r e d S p e e d ) ” type=”
AND”>
<g o a l name=”B. 1 1 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER
WheelSpeedSensor D e s i r e d S p e e d ) ” type
=”PRE”>
</g o a l >
<g o a l name=”B. 1 2 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER
GPSSpeedSensor D e s i r e d S p e e d ) ” type=”
PRE”>
</g o a l >
</g o a l >
<g o a l name=”B. 1 0 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS D i s t a n c e
S a f e D i s t a n c e ) ” type=”AND”>
<g o a l name=”B. 1 3 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS D i s t a n c e S e n s o r 1
S a f e D i s t a n c e ) ” type=”PRE”>
</g o a l >
<g o a l name=”B. 1 4 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS D i s t a n c e S e n s o r 2
S a f e D i s t a n c e ) ” type=”PRE”>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”C. 1 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(LESS
S p e e d t S p e e d t p l u s 1 ) ” type=”AND”>

204

97

98

99

100
101

102
103
104

105

106
107

108
109
110
111

112

113
114

115
116
117
118
119

<g o a l name=”C. 2 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
and2 ( LESS S p e e d t D e s i r e d S p e e d ) (GREATER
D i s t a n c e S a f e D i s t a n c e ) ) ” type=”AND”>
<g o a l name=”C. 4 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(LESS S p e e d t D e s i r e d S p e e d ) ” type=”AND
”>
<g o a l name=”C. 6 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS WheelSpeedSensor
D e s i r e d S p e e d ) ” type=”PRE”>
</g o a l >
<g o a l name=”C. 7 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS GPSSpeedSensor
D e s i r e d S p e e d ) ” type=”PRE”>
</g o a l >
</g o a l >
<g o a l name=”C. 9 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(GREATER D i s t a n c e S a f e D i s t a n c e ) ” type
=”AND”>
<g o a l name=”C. 1 0 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER
D i s t a n c e S e n s o r 1 S a f e D i s t a n c e ) ” type
=”PRE”>
</g o a l >
<g o a l name=”C. 1 1 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER
D i s t a n c e S e n s o r 2 S a f e D i s t a n c e ) ” type
=”PRE”>
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”C. 3 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
GREATER T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r
) ” type=”AND”>
<g o a l name=”C. 5 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(GREATER T h r o t t l e A c t u a t o r
T h r o t t l e P e d a l S e n s o r ) ” type=”REQ”>
</g o a l >
<g o a l name=”C. 8 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(LESS T h r o t t l e P e d a l S e n s o r 1 . 0 ) ” type=”
PRE”>
</g o a l >
<g o a l name=”C. 1 3 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”t r u e ” type=”PRE”>
</g o a l >
</g o a l >
<g o a l name=”C. 1 2 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
EQUALS BrakeActuator 0 . 0 ) ” type=”REQ”>

205

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

</g o a l >
</g o a l >
<g o a l name=”D. 1 ” c o n t e n t s=”NA” r e l a t i o n s h i p =”(
EQUALS S p e e d t S p e e d t p l u s 1 ) ” type=”AND”>
<g o a l name=”D. 2 ” c o n t e n t s=”NA” r e l a t i o n s h i p =”(
and2 (EQUALS S p e e d t D e s i r e d S p e e d ) (GREATER
D i s t a n c e S a f e D i s t a n c e ) ) ” type=”AND”>
<g o a l name=”D. 4 ” c o n t e n t s=”NA” r e l a t i o n s h i p
=”(EQUALS S p e e d t D e s i r e d S p e e d ) ” type=”
AND”>
<g o a l name=”D. 6 ” c o n t e n t s=”NA”
r e l a t i o n s h i p =”(EQUALS
WheelSpeedSensor D e s i r e d S p e e d ) ” type
=”PRE”>
</g o a l >
<g o a l name=”D. 7 ” c o n t e n t s=”NA”
r e l a t i o n s h i p =”(EQUALS GPSSpeedSensor
D e s i r e d S p e e d ) ” type=”PRE”>
</g o a l >
</g o a l >
<g o a l name=”D. 8 ” c o n t e n t s=”NA” r e l a t i o n s h i p
=”(GREATER D i s t a n c e S a f e D i s t a n c e ) ” type
=”AND”>
<g o a l name=”D. 9 ” c o n t e n t s=”NA”
r e l a t i o n s h i p =”(GREATER
D i s t a n c e S e n s o r 1 S a f e D i s t a n c e ) ” type
=”PRE”>
</g o a l >
<g o a l name=”D. 1 0 ” c o n t e n t s=”NA”
r e l a t i o n s h i p =”(GREATER
D i s t a n c e S e n s o r 2 S a f e D i s t a n c e ) ” type
=”PRE”>
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”D. 5 ” c o n t e n t s=”NA” r e l a t i o n s h i p =”
t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”D. 3 ” c o n t e n t s=”NA” r e l a t i o n s h i p =”(
EQUALS T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r )
” type=”REQ”>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
</g o a l >

206

146
147
148
149
150

<environment>
<env name=” s p e e d t a ” r e l a t i o n s h i p =”( o r (= S p e e d t
WheelSpeedSensor ) (= S p e e d t GPSSpeedSensor ) ) ”/>
<env name=” s p e e d t b ” r e l a t i o n s h i p =”(= S p e e d t ( max2 0 . 0 (−
T h r o t t l e P e d a l S e n s o r B r a k e P e d a l S e n s o r ) ) ) ”/>
<env name=” s p e e d t p l u s o n e ” r e l a t i o n s h i p =”(= S p e e d t p l u s 1
( max2 0 . 0 (− T h r o t t l e A c t u a t o r BrakeActuator ) ) ) ”/>
<env name=” d i s t a n c e ” r e l a t i o n s h i p =”( o r (= D i s t a n c e
D i s t a n c e S e n s o r 1 ) (= D i s t a n c e D i s t a n c e S e n s o r 2 ) ) ”/>
</environment>

151
152
153 </goalmodel>

A.1.3

Complete Requirements Goal Model for Adaptive Cruise
Control System
Listing A.3: Complete ACC Goal Model

1 <?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?>
2 <!−− c r e a t e d with XMLSpear −−>
3 <g o a l m o d e l xmlns : x s i =”h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ”
x s i : noNamespaceSchemaLocation =’ g o a l m o d e l . xsd ’>
4
5
<g o a l name=”A. 1 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”t r u e ” type=”OR”>
6
<g o a l name=”A. 2 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(and2 (EQUALS
C r u i s e S w i t c h S e n s o r 0 . 0 ) (EQUALS C r u i s e A c t i v e S e n s o r 1 . 0 ) )
” type=”AND”>
7
<g o a l name=”A. 6 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e S w i t c h S e n s o r 0 . 0 ) ” type=”PRE”>
8
</g o a l >
9
<g o a l name=”A. 7 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e A c t i v e S e n s o r 1 . 0 ) ” type=”REQ”>
10
</g o a l >
11
<g o a l name=”A. 8 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e A c t i v e S w i t c h 0 . 0 ) ” type=”REQ”>
12
</g o a l >
13
</g o a l >
14
<g o a l name=”A. 3 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(and (=
C r u i s e S w i t c h S e n s o r f a l s e ) (= C r u i s e A c t i v e S e n s o r f a l s e ) ) ”
type=”AND”>
15
<g o a l name=”A. 9 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e S w i t c h S e n s o r 0 . 0 ) ” type=”PRE”>
16
</g o a l >
17
<g o a l name=”A. 1 0 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e A c t i v e S e n s o r 0 . 0 ) ” type=”PRE”>

207

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

</g o a l >
<g o a l name=”A. 1 5 a ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(and2 (
EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) (EQUALS
B r a k e P e d a l S e n s o r BrakeActuator ) ) ” type=”AND”>
<g o a l name=”A. 1 6 a ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) ”
type=”AND”>
<g o a l name=”A. 1 8 a ” c o n t e n t s =”NA” r e l a t i o n s h i p =”
t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”A. 1 9 a ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(EQUALS T h r o t t l e P e d a l S e n s o r
T h r o t t l e A c t u a t o r ) ” type=”PRE”>
</g o a l >
</g o a l >
<g o a l name=”A. 1 7 a ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) ” type=”
AND”>
<g o a l name=”A. 2 0 a ” c o n t e n t s =”NA” r e l a t i o n s h i p =”
t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”A. 2 1 a ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) ”
type=”PRE”>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”A. 4 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(and (=
C r u i s e S w i t c h S e n s o r t r u e ) (= C r u i s e A c t i v e S e n s o r f a l s e ) ) ”
type=”AND”>
<g o a l name=”A. 1 1 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e S w i t c h S e n s o r 1 . 0 ) ” type=”PRE”>
</g o a l >
<g o a l name=”A. 1 2 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e A c t i v e S e n s o r 0 . 0 ) ” type=”PRE”>
</g o a l >
<g o a l name=”A. 1 5 b” c o n t e n t s=”NA” r e l a t i o n s h i p =”(and2 (
EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) (EQUALS
B r a k e P e d a l S e n s o r BrakeActuator ) ) ” type=”AND”>
<g o a l name=”A. 1 6 b” c o n t e n t s=”NA” r e l a t i o n s h i p =”(
EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) ”
type=”AND”>
<g o a l name=”A. 1 8 b” c o n t e n t s=”NA” r e l a t i o n s h i p =”
t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”A. 1 9 b” c o n t e n t s=”NA” r e l a t i o n s h i p

208

44
45
46

47
48
49

50
51
52
53
54

55
56
57
58
59

60

61

62

63

64
65

=”(EQUALS T h r o t t l e P e d a l S e n s o r
T h r o t t l e A c t u a t o r ) ” type=”PRE”>
</g o a l >
</g o a l >
<g o a l name=”A. 1 7 b” c o n t e n t s=”NA” r e l a t i o n s h i p =”(
EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) ” type=”
AND”>
<g o a l name=”A. 2 0 b” c o n t e n t s=”NA” r e l a t i o n s h i p =”
t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”A. 2 1 b” c o n t e n t s=”NA” r e l a t i o n s h i p
=”(EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) ”
type=”PRE”>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”A. 5 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(and (=
C r u i s e S w i t c h S e n s o r f a l s e ) (= C r u i s e A c t i v e S e n s o r t r u e ) ) ”
type=”AND”>
<g o a l name=”A. 1 3 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e S w i t c h S e n s o r 1 . 0 ) ” type=”PRE”>
</g o a l >
<g o a l name=”A. 1 4 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(EQUALS
C r u i s e A c t i v e S e n s o r 1 . 0 ) ” type=”PRE”>
</g o a l >
<g o a l name=”B. 1 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”( o r 3 (
EQUALS S p e e d t S p e e d t p l u s 1 ) (GREATER S p e e d t
S p e e d t p l u s 1 ) ( LESS D i s t a n c e S a f e D i s t a n c e ) ) ” type
=”OR”>
<g o a l name=”B. 2 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”( o r 2 (
and2 (EQUALS S p e e d t 0 . 0 ) (EQUALS S p e e d t p l u s 1
0 . 0 ) ) (GREATER S p e e d t S p e e d t p l u s 1 ) ) ” type=”
AND”>
<g o a l name=”B. 3 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
o r 2 ( and2 (EQUALS S p e e d t 0 . 0 ) (EQUALS
S p e e d t p l u s 1 0 . 0 ) ) (GREATER S p e e d t
S p e e d t p l u s 1 ) ) ” type=”AND”>
<g o a l name=”B. 4 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(LESS T h r o t t l e A c t u a t o r
T h r o t t l e P e d a l S e n s o r ) ” type=”AND”>
<g o a l name=”B. 5 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS T h r o t t l e A c t u a t o r
T h r o t t l e P e d a l S e n s o r ) ” type=”REQ”>
</g o a l >
<g o a l name=”B. 6 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”t r u e ” type=”REQ”>

209

66
67

68
69
70

71

72
73
74
75

76
77

78
79
80
81

82

83

84
85

86
87
88

</g o a l >
<g o a l name=”B. 7 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER
T h r o t t l e P e d a l S e n s o r 0 . 0 ) ” type=”PRE
”>
</g o a l >
</g o a l >
<g o a l name=”B. 1 5 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER BrakeActuator
B r a k e P e d a l S e n s o r ) ” type=”AND”>
<g o a l name=”B. 1 6 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER BrakeActuator
B r a k e P e d a l S e n s o r ) ” type=”REQ”>
</g o a l >
<g o a l name=”B. 1 7 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”B. 1 8 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(EQUALS
T h r o t t l e P e d a l S e n s o r 0 . 0 ) ” type=”PRE
”>
</g o a l >
<g o a l name=”B. 1 9 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS B r a k e P e d a l S e n s o r
1 . 0 ) ” type=”PRE”>
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”B. 8 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
o r 2 (GREATER S p e e d t D e s i r e d S p e e d ) ( LESS
D i s t a n c e S a f e D i s t a n c e ) ) ” type=”OR”>
<g o a l name=”B. 9 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(GREATER S p e e d t D e s i r e d S p e e d ) ” type=”
AND”>
<g o a l name=”B. 1 1 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER
WheelSpeedSensor D e s i r e d S p e e d ) ” type
=”PRE”>
</g o a l >
<g o a l name=”B. 1 2 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER
GPSSpeedSensor D e s i r e d S p e e d ) ” type=”
PRE”>
</g o a l >
</g o a l >
<g o a l name=”B. 1 0 ” c o n t e n t s =”NA”

210

89

90
91

92
93
94
95
96
97

98

99

100
101

102
103
104

105

106
107

108
109
110
111

r e l a t i o n s h i p =”(LESS D i s t a n c e
S a f e D i s t a n c e ) ” type=”AND”>
<g o a l name=”B. 1 3 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS D i s t a n c e S e n s o r 1
S a f e D i s t a n c e ) ” type=”PRE”>
</g o a l >
<g o a l name=”B. 1 4 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS D i s t a n c e S e n s o r 2
S a f e D i s t a n c e ) ” type=”PRE”>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”C. 1 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(LESS
S p e e d t S p e e d t p l u s 1 ) ” type=”AND”>
<g o a l name=”C. 2 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
and2 ( LESS S p e e d t D e s i r e d S p e e d ) (GREATER
D i s t a n c e S a f e D i s t a n c e ) ) ” type=”AND”>
<g o a l name=”C. 4 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(LESS S p e e d t D e s i r e d S p e e d ) ” type=”AND
”>
<g o a l name=”C. 6 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS WheelSpeedSensor
D e s i r e d S p e e d ) ” type=”PRE”>
</g o a l >
<g o a l name=”C. 7 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(LESS GPSSpeedSensor
D e s i r e d S p e e d ) ” type=”PRE”>
</g o a l >
</g o a l >
<g o a l name=”C. 9 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(GREATER D i s t a n c e S a f e D i s t a n c e ) ” type
=”AND”>
<g o a l name=”C. 1 0 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER
D i s t a n c e S e n s o r 1 S a f e D i s t a n c e ) ” type
=”PRE”>
</g o a l >
<g o a l name=”C. 1 1 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”(GREATER
D i s t a n c e S e n s o r 2 S a f e D i s t a n c e ) ” type
=”PRE”>
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”C. 3 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(

211

112

113
114

115
116
117
118
119
120
121
122
123

124

125

126
127

128
129
130

131

132
133

GREATER T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r
) ” type=”AND”>
<g o a l name=”C. 5 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(GREATER T h r o t t l e A c t u a t o r
T h r o t t l e P e d a l S e n s o r ) ” type=”REQ”>
</g o a l >
<g o a l name=”C. 8 ” c o n t e n t s =”NA” r e l a t i o n s h i p
=”(LESS T h r o t t l e P e d a l S e n s o r 1 . 0 ) ” type=”
PRE”>
</g o a l >
<g o a l name=”C. 1 3 ” c o n t e n t s =”NA”
r e l a t i o n s h i p =”t r u e ” type=”PRE”>
</g o a l >
</g o a l >
<g o a l name=”C. 1 2 ” c o n t e n t s =”NA” r e l a t i o n s h i p =”(
EQUALS BrakeActuator 0 . 0 ) ” type=”REQ”>
</g o a l >
</g o a l >
<g o a l name=”D. 1 ” c o n t e n t s=”NA” r e l a t i o n s h i p =”(
EQUALS S p e e d t S p e e d t p l u s 1 ) ” type=”AND”>
<g o a l name=”D. 2 ” c o n t e n t s=”NA” r e l a t i o n s h i p =”(
and2 (EQUALS S p e e d t D e s i r e d S p e e d ) (GREATER
D i s t a n c e S a f e D i s t a n c e ) ) ” type=”AND”>
<g o a l name=”D. 4 ” c o n t e n t s=”NA” r e l a t i o n s h i p
=”(EQUALS S p e e d t D e s i r e d S p e e d ) ” type=”
AND”>
<g o a l name=”D. 6 ” c o n t e n t s=”NA”
r e l a t i o n s h i p =”(EQUALS
WheelSpeedSensor D e s i r e d S p e e d ) ” type
=”PRE”>
</g o a l >
<g o a l name=”D. 7 ” c o n t e n t s=”NA”
r e l a t i o n s h i p =”(EQUALS GPSSpeedSensor
D e s i r e d S p e e d ) ” type=”PRE”>
</g o a l >
</g o a l >
<g o a l name=”D. 8 ” c o n t e n t s=”NA” r e l a t i o n s h i p
=”(GREATER D i s t a n c e S a f e D i s t a n c e ) ” type
=”AND”>
<g o a l name=”D. 9 ” c o n t e n t s=”NA”
r e l a t i o n s h i p =”(GREATER
D i s t a n c e S e n s o r 1 S a f e D i s t a n c e ) ” type
=”PRE”>
</g o a l >
<g o a l name=”D. 1 0 ” c o n t e n t s=”NA”
r e l a t i o n s h i p =”(GREATER

212

D i s t a n c e S e n s o r 2 S a f e D i s t a n c e ) ” type
=”PRE”>
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”D. 5 ” c o n t e n t s=”NA” r e l a t i o n s h i p =”
t r u e ” type=”REQ”>
</g o a l >
<g o a l name=”D. 3 ” c o n t e n t s=”NA” r e l a t i o n s h i p =”(
EQUALS T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r )
” type=”REQ”>
</g o a l >
<g o a l name=”D. New1” c o n t e n t s=”NA” r e l a t i o n s h i p
=”(EQUALS BrakeActuator B r a k e P e d a l S e n s o r ) ”
type=”PRE”>
</g o a l >
<g o a l name=”D. New2” c o n t e n t s=”NA” r e l a t i o n s h i p
=”t r u e ” type=”REQ”>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
</g o a l >

134
135
136
137
138
139

140
141

142
143
144
145
146
147
148
149
150
151

<environment>
<env name=” s p e e d t a ” r e l a t i o n s h i p =”( o r (= S p e e d t
WheelSpeedSensor ) (= S p e e d t GPSSpeedSensor ) ) ”/>
<env name=” s p e e d t b ” r e l a t i o n s h i p =”(= S p e e d t ( max2 0 . 0 (−
T h r o t t l e P e d a l S e n s o r B r a k e P e d a l S e n s o r ) ) ) ”/>
<env name=” s p e e d t p l u s o n e ” r e l a t i o n s h i p =”(=
S p e e d t p l u s 1 ( max2 0 . 0 (− T h r o t t l e A c t u a t o r
BrakeActuator ) ) ) ”/>
<env name=” d i s t a n c e ” r e l a t i o n s h i p =”( o r (= D i s t a n c e
D i s t a n c e S e n s o r 1 ) (= D i s t a n c e D i s t a n c e S e n s o r 2 ) ) ”/>
</environment>

152
153

154

155
156
157 </goalmodel>

A.2

Design-Time Detection Constraints (SMT)

This section of the appendix includes the SMT constraint output for detecting incomplete requirements decompositions in Chapter 3. Constraint sets are listed for an incomplete
requirements model and a complete requirements model.
213

A.2.1

Detection Constraints for Incomplete Adaptive Cruise Control System
Listing A.4: Incomplete Adaptive Cruise Control System Constraints

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

( d e f i n e −fun min2 ( ( x1 Real ) ( x2 Real ) ) Real
( / (− (+ x1 x2 ) ( abs (− x1 x2 ) ) ) 2 ) )
( d e f i n e −fun and2 ( ( x1 Real ) ( x2 Real ) ) Real
( min2 x1 x2 ) )
( d e f i n e −fun and3 ( ( x1 Real ) ( x2 Real ) ( x3 Real ) ) Real
( and2 ( and2 x1 x2 ) x3 ) )
( d e f i n e −fun and4 ( ( x1 Real ) ( x2 Real ) ( x3 Real ) ( x4 Real ) ) Real
( and2 ( and3 x1 x2 x3 ) x4 ) )
( d e f i n e −fun and5 ( ( x1 Real ) ( x2 Real ) ( x3 Real ) ( x4 Real ) ( x5 Real )
) Real
( and2 ( and4 x1 x2 x3 x4 ) x5 ) )
( d e f i n e −fun max2 ( ( x1 Real ) ( x2 Real ) ) Real
( / (+ x1 x2 ( abs (− x1 x2 ) ) ) 2 ) )
( d e f i n e −fun o r 2 ( ( x1 Real ) ( x2 Real ) ) Real
( max2 x1 x2 ) )
( d e f i n e −fun o r 3 ( ( x1 Real ) ( x2 Real ) ( x3 Real ) ) Real
( o r 2 x1 ( o r 2 x2 x3 ) ) )
( d e f i n e −fun o r 4 ( ( x1 Real ) ( x2 Real ) ( x3 Real ) ( x4 Real ) ) Real
( o r 2 x1 ( o r 3 x2 x3 x4 ) ) )
( d e f i n e −fun not1 ( ( x1 Real ) ) Real
(− 1 . 0 x1 ) )
( d e f i n e −fun EQUALS ( ( a Real ) ( b Real ) ) Real
( i t e (= a b ) 1 . 0 0 . 0 ) )
( d e f i n e −fun GREATER ( ( a Real ) ( b Real ) ) Real
( i t e (> a b ) 1 . 0 0 . 0 ) )
( d e f i n e −fun LESS ( ( a Real ) ( b Real ) ) Real
( i t e (< a b ) 1 . 0 0 . 0 ) )
( d e c l a r e −c o n s t S p e e d t Real )

214

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

( a s s e r t ( and (<= S p e e d t 1 . 0 ) (>= S p e e d t 0 . 0 ) ) )
( d e c l a r e −c o n s t S p e e d t p l u s 1 Real )
( a s s e r t ( and (<= S p e e d t p l u s 1 1 . 0 ) (>= S p e e d t p l u s 1 0 . 0 ) ) )
( d e c l a r e −c o n s t D i s t a n c e Real )
( a s s e r t ( and (<= D i s t a n c e 1 . 0 ) (>= D i s t a n c e 0 . 0 ) ) )
( d e c l a r e −c o n s t S a f e D i s t a n c e Real )
( a s s e r t ( and (<= S a f e D i s t a n c e 1 . 0 ) (>= S a f e D i s t a n c e 0 . 0 ) ) )
( d e c l a r e −c o n s t D e s i r e d S p e e d Real )
( a s s e r t ( and (<= D e s i r e d S p e e d 1 . 0 ) (>= D e s i r e d S p e e d 0 . 0 ) ) )
( d e c l a r e −c o n s t T h r o t t l e A c t u a t o r Real )
( a s s e r t ( and (<= T h r o t t l e A c t u a t o r 1 . 0 ) (>= T h r o t t l e A c t u a t o r 0 . 0 ) ) )
( d e c l a r e −c o n s t T h r o t t l e P e d a l S e n s o r Real )
( a s s e r t ( and (<= T h r o t t l e P e d a l S e n s o r 1 . 0 ) (>= T h r o t t l e P e d a l S e n s o r
0.0) ) )
( d e c l a r e −c o n s t WheelSpeedSensor Real )
( a s s e r t ( and (<= WheelSpeedSensor 1 . 0 ) (>= WheelSpeedSensor 0 . 0 ) ) )
( d e c l a r e −c o n s t GPSSpeedSensor Real )
( a s s e r t ( and (<= GPSSpeedSensor 1 . 0 ) (>= GPSSpeedSensor 0 . 0 ) ) )
( d e c l a r e −c o n s t D i s t a n c e S e n s o r 1 Real )
( a s s e r t ( and (<= D i s t a n c e S e n s o r 1 1 . 0 ) (>= D i s t a n c e S e n s o r 1 0 . 0 ) ) )
( d e c l a r e −c o n s t D i s t a n c e S e n s o r 2 Real )
( a s s e r t ( and (<= D i s t a n c e S e n s o r 2 1 . 0 ) (>= D i s t a n c e S e n s o r 2 0 . 0 ) ) )
( d e c l a r e −c o n s t BrakeActuator Real )
( a s s e r t ( and (<= BrakeActuator 1 . 0 ) (>= BrakeActuator 0 . 0 ) ) )
( d e c l a r e −c o n s t B r a k e P e d a l S e n s o r Real )
( a s s e r t ( and (<= B r a k e P e d a l S e n s o r 1 . 0 ) (>= B r a k e P e d a l S e n s o r 0 . 0 ) ) )
( d e c l a r e −c o n s t C r u i s e S w i t c h S e n s o r Real )
( a s s e r t ( and (<= C r u i s e S w i t c h S e n s o r 1 . 0 ) (>= C r u i s e S w i t c h S e n s o r
0.0) ) )
( d e c l a r e −c o n s t C r u i s e A c t i v e S e n s o r Real )
( a s s e r t ( and (<= C r u i s e A c t i v e S e n s o r 1 . 0 ) (>= C r u i s e A c t i v e S e n s o r
0.0) ) )

84

215

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

( d e c l a r e −c o n s t C r u i s e A c t i v e S w i t c h Real )
( a s s e r t ( and (<= C r u i s e A c t i v e S w i t c h 1 . 0 ) (>= C r u i s e A c t i v e S w i t c h
0.0) ) )
( a s s e r t ( o r (= S p e e d t WheelSpeedSensor ) (= S p e e d t GPSSpeedSensor )
))
( a s s e r t ( o r (= D i s t a n c e D i s t a n c e S e n s o r 1 ) (= D i s t a n c e
DistanceSensor2 ) ) )
( a s s e r t (= S p e e d t p l u s 1 ( max2 0 . 0 (− T h r o t t l e A c t u a t o r
BrakeActuator ) ) ) )
( a s s e r t (= S p e e d t ( max2 0 . 0 (− T h r o t t l e P e d a l S e n s o r
BrakePedalSensor ) ) ) )
( d e f i n e −fun A 1 ( ) Real
1.0)
( d e f i n e −fun A 2 ( ) Real
( and2 (EQUALS C r u i s e S w i t c h S e n s o r 0 . 0 ) (EQUALS
CruiseActiveSensor 1.0) ) )
( d e f i n e −fun A 3 ( ) Real
( and2 (EQUALS C r u i s e S w i t c h S e n s o r 0 . 0 ) (EQUALS
CruiseActiveSensor 0.0) ) )
( d e f i n e −fun A 4 ( ) Real
( and2 (EQUALS C r u i s e S w i t c h S e n s o r 1 . 0 ) (EQUALS
CruiseActiveSensor 0.0) ) )
( d e f i n e −fun A 5 ( ) Real
( and2 (EQUALS C r u i s e S w i t c h S e n s o r 1 . 0 ) (EQUALS
CruiseActiveSensor 1.0) ) )
( d e f i n e −fun A 6 ( ) Real
(EQUALS C r u i s e S w i t c h S e n s o r 0 . 0 ) )
( d e f i n e −fun A 7 ( ) Real
(EQUALS C r u i s e A c t i v e S e n s o r 1 . 0 ) )
( d e f i n e −fun A 8 ( ) Real
(EQUALS C r u i s e A c t i v e S w i t c h 0 . 0 ) )
( d e f i n e −fun A 9 ( ) Real
(EQUALS C r u i s e S w i t c h S e n s o r 0 . 0 ) )
( d e f i n e −fun A 10 ( ) Real
(EQUALS C r u i s e A c t i v e S e n s o r 0 . 0 ) )

216

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

( d e f i n e −fun A 11 ( ) Real
(EQUALS C r u i s e S w i t c h S e n s o r 1 . 0 ) )
( d e f i n e −fun A 12 ( ) Real
(EQUALS C r u i s e A c t i v e S e n s o r 0 . 0 ) )
( d e f i n e −fun A 13 ( ) Real
(EQUALS C r u i s e S w i t c h S e n s o r 1 . 0 ) )
( d e f i n e −fun A 14 ( ) Real
(EQUALS C r u i s e A c t i v e S e n s o r 1 . 0 ) )
( d e f i n e −fun A 15 ( ) Real
( and2 (EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) (EQUALS
B r a k e P e d a l S e n s o r BrakeActuator ) ) )
( d e f i n e −fun A 16 ( ) Real
(EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) )
( d e f i n e −fun A 17 ( ) Real
(EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) )
( d e f i n e −fun A 18 ( ) Real
1.0)
( d e f i n e −fun A 19 ( ) Real
(EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) )
( d e f i n e −fun A 20 ( ) Real
1.0)
( d e f i n e −fun A 21 ( ) Real
(EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) )
( d e f i n e −fun B 1 ( ) Real
( o r 3 (EQUALS S p e e d t S p e e d t p l u s 1 ) (GREATER S p e e d t
S p e e d t p l u s 1 ) ( LESS D i s t a n c e S a f e D i s t a n c e ) ) )
( d e f i n e −fun B 2 ( ) Real
( o r 2 ( and2 (EQUALS S p e e d t 0 . 0 ) (EQUALS S p e e d t p l u s 1 0 . 0 )
) (GREATER S p e e d t S p e e d t p l u s 1 ) ) )
( d e f i n e −fun B 3 ( ) Real
( o r 2 ( and2 (EQUALS S p e e d t 0 . 0 ) (EQUALS S p e e d t p l u s 1 0 . 0 )
) (GREATER S p e e d t S p e e d t p l u s 1 ) ) )
( d e f i n e −fun B 4 ( ) Real

217

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

( LESS T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r ) )
( d e f i n e −fun B 5 ( ) Real
( LESS T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r ) )
( d e f i n e −fun B 6 ( ) Real
1.0)
( d e f i n e −fun B 7 ( ) Real
(GREATER T h r o t t l e P e d a l S e n s o r 0 . 0 ) )
( d e f i n e −fun B 8 ( ) Real
( o r 2 (GREATER S p e e d t D e s i r e d S p e e d ) ( LESS D i s t a n c e
SafeDistance ) ) )
( d e f i n e −fun B 9 ( ) Real
(GREATER S p e e d t D e s i r e d S p e e d ) )
( d e f i n e −fun B 10 ( ) Real
( LESS D i s t a n c e S a f e D i s t a n c e ) )
( d e f i n e −fun B 11 ( ) Real
(GREATER WheelSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun B 12 ( ) Real
(GREATER GPSSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun B 13 ( ) Real
( LESS D i s t a n c e S e n s o r 1 S a f e D i s t a n c e ) )
( d e f i n e −fun B 14 ( ) Real
( LESS D i s t a n c e S e n s o r 2 S a f e D i s t a n c e ) )
( d e f i n e −fun B 15 ( ) Real
(GREATER BrakeActuator B r a k e P e d a l S e n s o r ) )
( d e f i n e −fun B 16 ( ) Real
(GREATER BrakeActuator B r a k e P e d a l S e n s o r ) )
( d e f i n e −fun B 17 ( ) Real
1.0)
( d e f i n e −fun B 18 ( ) Real
(EQUALS T h r o t t l e P e d a l S e n s o r 0 . 0 ) )
( d e f i n e −fun B 19 ( ) Real
( LESS B r a k e P e d a l S e n s o r 1 . 0 ) )

218

212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256

( d e f i n e −fun C 1 ( ) Real
( LESS S p e e d t S p e e d t p l u s 1 ) )
( d e f i n e −fun C 2 ( ) Real
( and2 ( LESS S p e e d t D e s i r e d S p e e d ) (GREATER D i s t a n c e
SafeDistance ) ) )
( d e f i n e −fun C 3 ( ) Real
(GREATER T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r ) )
( d e f i n e −fun C 4 ( ) Real
( LESS S p e e d t D e s i r e d S p e e d ) )
( d e f i n e −fun C 5 ( ) Real
(GREATER T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r ) )
( d e f i n e −fun C 6 ( ) Real
( LESS WheelSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun C 7 ( ) Real
( LESS GPSSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun C 8 ( ) Real
( LESS T h r o t t l e P e d a l S e n s o r 1 . 0 ) )
( d e f i n e −fun C 9 ( ) Real
(GREATER D i s t a n c e S a f e D i s t a n c e ) )
( d e f i n e −fun C 10 ( ) Real
(GREATER D i s t a n c e S e n s o r 1 S a f e D i s t a n c e ) )
( d e f i n e −fun C 11 ( ) Real
(GREATER D i s t a n c e S e n s o r 2 S a f e D i s t a n c e ) )
( d e f i n e −fun C 12 ( ) Real
(EQUALS BrakeActuator 0 . 0 ) )
( d e f i n e −fun C 13 ( ) Real
1.0)
( d e f i n e −fun D 1 ( ) Real
(EQUALS S p e e d t S p e e d t p l u s 1 ) )
( d e f i n e −fun D 2 ( ) Real
( and2 (EQUALS S p e e d t D e s i r e d S p e e d ) (GREATER D i s t a n c e
SafeDistance ) ) )

219

257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303

( d e f i n e −fun D 3 ( ) Real
(EQUALS T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r ) )
( d e f i n e −fun D 4 ( ) Real
(EQUALS S p e e d t D e s i r e d S p e e d ) )
( d e f i n e −fun D 5 ( ) Real
1.0)
( d e f i n e −fun D 6 ( ) Real
(EQUALS WheelSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun D 7 ( ) Real
(EQUALS GPSSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun D 8 ( ) Real
(GREATER D i s t a n c e S a f e D i s t a n c e ) )
( d e f i n e −fun D 9 ( ) Real
(GREATER D i s t a n c e S e n s o r 1 S a f e D i s t a n c e ) )
( d e f i n e −fun D 10 ( ) Real
(GREATER D i s t a n c e S e n s o r 2 S a f e D i s t a n c e ) )
( d e f i n e −fun A 1 decomp ( ) Real
( or4 A 2 A 3 A 4 A 5 ) )
( d e f i n e −fun A 2 decomp ( ) Real
( and3 A 6 A 7 A 8 ) )
( d e f i n e −fun A 3 decomp ( ) Real
( and3 A 9 A 10 A 15 ) )
( d e f i n e −fun A 4 decomp ( ) Real
( and3 A 15 A 11 A 12 ) )
( d e f i n e −fun A 5 decomp ( ) Real
( and3 A 13 A 14 B 1 ) )
( d e f i n e −fun A 15 decomp ( ) Real
( and2 A 16 A 17 ) )
( d e f i n e −fun A 16 decomp ( ) Real
( and2 A 18 A 19 ) )
( d e f i n e −fun A 17 decomp ( ) Real

220

304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350

( and2 A 20 A 21 ) )
( d e f i n e −fun B 1 decomp ( ) Real
( and3 C 1 B 2 D 1 ) )
( d e f i n e −fun B 2 decomp ( ) Real
( and2 B 8 B 3 ) )
( d e f i n e −fun B 3 decomp ( ) Real
( o r 2 B 4 B 15 ) )
( d e f i n e −fun B 4 decomp ( ) Real
( and3 B 5 B 6 B 7 ) )
( d e f i n e −fun B 8 decomp ( ) Real
( o r 2 B 9 B 10 ) )
( d e f i n e −fun B 9 decomp ( ) Real
( and2 B 11 B 12 ) )
( d e f i n e −fun B 10 decomp ( ) Real
( and2 B 13 B 14 ) )
( d e f i n e −fun B 15 decomp ( ) Real
( and4 B 16 B 17 B 18 B 19 ) )
( d e f i n e −fun C 1 decomp ( ) Real
( and3 C 2 C 3 C 12 ) )
( d e f i n e −fun C 2 decomp ( ) Real
( and2 C 4 C 9 ) )
( d e f i n e −fun C 3 decomp ( ) Real
( and3 C 5 C 13 C 8 ) )
( d e f i n e −fun C 4 decomp ( ) Real
( and2 C 6 C 7 ) )
( d e f i n e −fun C 9 decomp ( ) Real
( and2 C 10 C 11 ) )
( d e f i n e −fun D 1 decomp ( ) Real
( and3 D 2 D 5 D 3 ) )
( d e f i n e −fun D 2 decomp ( ) Real
( and2 D 4 D 8 ) )

221

351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397

( d e f i n e −fun D 4 decomp ( ) Real
( and2 D 6 D 7 ) )
( d e f i n e −fun D 8 decomp ( ) Real
( and2 D 9 D 10 ) )
( push )
( maximize (− A 1 decomp A 1 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 2 decomp A 2 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 3 decomp A 3 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 4 decomp A 4 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 5 decomp A 5 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 15 decomp A 15 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 16 decomp A 16 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 17 decomp A 17 ) )
( check−s a t )
( pop )
( push )

222

398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444

( maximize (− B 1 decomp B 1 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 2 decomp B 2 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 3 decomp B 3 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 4 decomp B 4 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 8 decomp B 8 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 9 decomp B 9 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 10 decomp B 10 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 15 decomp B 15 ) )
( check−s a t )
( pop )
( push )
( maximize (− C 1 decomp C 1 ) )
( check−s a t )
( pop )
( push )
( maximize (− C 2 decomp C 2 ) )
( check−s a t )

223

445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480

( pop )
( push )
( maximize (− C 3 decomp C 3 ) )
( check−s a t )
( pop )
( push )
( maximize (− C 4 decomp C 4 ) )
( check−s a t )
( pop )
( push )
( maximize (− C 9 decomp C 9 ) )
( check−s a t )
( pop )
( push )
( maximize (− D 1 decomp D 1 ) )
( check−s a t )
( pop )
( push )
( maximize (− D 2 decomp D 2 ) )
( check−s a t )
( pop )
( push )
( maximize (− D 4 decomp D 4 ) )
( check−s a t )
( pop )
( push )
( maximize (− D 8 decomp D 8 ) )
( check−s a t )
( pop )

A.2.2

Detection Constraints for Complete Adaptive Cruise Control System
Listing A.5: Complete Adaptive Cruise Control System Constraints

1
2
3

( d e f i n e −fun min2 ( ( x1 Real ) ( x2 Real ) ) Real
( / (− (+ x1 x2 ) ( abs (− x1 x2 ) ) ) 2 ) )

224

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

( d e f i n e −fun and2 ( ( x1 Real ) ( x2 Real ) ) Real
( min2 x1 x2 ) )
( d e f i n e −fun and3 ( ( x1 Real ) ( x2 Real ) ( x3 Real ) ) Real
( and2 ( and2 x1 x2 ) x3 ) )
( d e f i n e −fun and4 ( ( x1 Real ) ( x2 Real ) ( x3 Real ) ( x4 Real ) ) Real
( and2 ( and3 x1 x2 x3 ) x4 ) )
( d e f i n e −fun and5 ( ( x1 Real ) ( x2 Real ) ( x3 Real ) ( x4 Real ) ( x5 Real )
) Real
( and2 ( and4 x1 x2 x3 x4 ) x5 ) )
( d e f i n e −fun max2 ( ( x1 Real ) ( x2 Real ) ) Real
( / (+ x1 x2 ( abs (− x1 x2 ) ) ) 2 ) )
( d e f i n e −fun o r 2 ( ( x1 Real ) ( x2 Real ) ) Real
( max2 x1 x2 ) )
( d e f i n e −fun o r 3 ( ( x1 Real ) ( x2 Real ) ( x3 Real ) ) Real
( o r 2 x1 ( o r 2 x2 x3 ) ) )
( d e f i n e −fun o r 4 ( ( x1 Real ) ( x2 Real ) ( x3 Real ) ( x4 Real ) ) Real
( o r 2 x1 ( o r 3 x2 x3 x4 ) ) )
( d e f i n e −fun not1 ( ( x1 Real ) ) Real
(− 1 . 0 x1 ) )
( d e f i n e −fun EQUALS ( ( a Real ) ( b Real ) ) Real
( i t e (= a b ) 1 . 0 0 . 0 ) )
( d e f i n e −fun GREATER ( ( a Real ) ( b Real ) ) Real
( i t e (> a b ) 1 . 0 0 . 0 ) )
( d e f i n e −fun LESS ( ( a Real ) ( b Real ) ) Real
( i t e (< a b ) 1 . 0 0 . 0 ) )
( d e c l a r e −c o n s t S p e e d t Real )
( a s s e r t ( and (<= S p e e d t 1 . 0 ) (>= S p e e d t 0 . 0 ) ) )
( d e c l a r e −c o n s t S p e e d t p l u s 1 Real )
( a s s e r t ( and (<= S p e e d t p l u s 1 1 . 0 ) (>= S p e e d t p l u s 1 0 . 0 ) ) )
( d e c l a r e −c o n s t D i s t a n c e Real )
( a s s e r t ( and (<= D i s t a n c e 1 . 0 ) (>= D i s t a n c e 0 . 0 ) ) )
( d e c l a r e −c o n s t S a f e D i s t a n c e Real )

225

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

( a s s e r t ( and (<= S a f e D i s t a n c e 1 . 0 ) (>= S a f e D i s t a n c e 0 . 0 ) ) )
( d e c l a r e −c o n s t D e s i r e d S p e e d Real )
( a s s e r t ( and (<= D e s i r e d S p e e d 1 . 0 ) (>= D e s i r e d S p e e d 0 . 0 ) ) )
( d e c l a r e −c o n s t T h r o t t l e A c t u a t o r Real )
( a s s e r t ( and (<= T h r o t t l e A c t u a t o r 1 . 0 ) (>= T h r o t t l e A c t u a t o r 0 . 0 ) ) )
( d e c l a r e −c o n s t T h r o t t l e P e d a l S e n s o r Real )
( a s s e r t ( and (<= T h r o t t l e P e d a l S e n s o r 1 . 0 ) (>= T h r o t t l e P e d a l S e n s o r
0.0) ) )
( d e c l a r e −c o n s t WheelSpeedSensor Real )
( a s s e r t ( and (<= WheelSpeedSensor 1 . 0 ) (>= WheelSpeedSensor 0 . 0 ) ) )
( d e c l a r e −c o n s t GPSSpeedSensor Real )
( a s s e r t ( and (<= GPSSpeedSensor 1 . 0 ) (>= GPSSpeedSensor 0 . 0 ) ) )
( d e c l a r e −c o n s t D i s t a n c e S e n s o r 1 Real )
( a s s e r t ( and (<= D i s t a n c e S e n s o r 1 1 . 0 ) (>= D i s t a n c e S e n s o r 1 0 . 0 ) ) )
( d e c l a r e −c o n s t D i s t a n c e S e n s o r 2 Real )
( a s s e r t ( and (<= D i s t a n c e S e n s o r 2 1 . 0 ) (>= D i s t a n c e S e n s o r 2 0 . 0 ) ) )
( d e c l a r e −c o n s t BrakeActuator Real )
( a s s e r t ( and (<= BrakeActuator 1 . 0 ) (>= BrakeActuator 0 . 0 ) ) )
( d e c l a r e −c o n s t B r a k e P e d a l S e n s o r Real )
( a s s e r t ( and (<= B r a k e P e d a l S e n s o r 1 . 0 ) (>= B r a k e P e d a l S e n s o r 0 . 0 ) ) )
( d e c l a r e −c o n s t C r u i s e S w i t c h S e n s o r Real )
( a s s e r t ( and (<= C r u i s e S w i t c h S e n s o r 1 . 0 ) (>= C r u i s e S w i t c h S e n s o r
0.0) ) )
( d e c l a r e −c o n s t C r u i s e A c t i v e S e n s o r Real )
( a s s e r t ( and (<= C r u i s e A c t i v e S e n s o r 1 . 0 ) (>= C r u i s e A c t i v e S e n s o r
0.0) ) )
( d e c l a r e −c o n s t C r u i s e A c t i v e S w i t c h Real )
( a s s e r t ( and (<= C r u i s e A c t i v e S w i t c h 1 . 0 ) (>= C r u i s e A c t i v e S w i t c h
0.0) ) )
( a s s e r t ( o r (= S p e e d t WheelSpeedSensor ) (= S p e e d t GPSSpeedSensor )
))
( a s s e r t ( o r (= D i s t a n c e D i s t a n c e S e n s o r 1 ) (= D i s t a n c e
DistanceSensor2 ) ) )

226

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

( a s s e r t (= S p e e d t p l u s 1 ( max2 0 . 0 (− T h r o t t l e A c t u a t o r
BrakeActuator ) ) ) )
( a s s e r t (= S p e e d t ( max2 0 . 0 (− T h r o t t l e P e d a l S e n s o r
BrakePedalSensor ) ) ) )
( d e f i n e −fun A 1 ( ) Real
1.0)
( d e f i n e −fun A 2 ( ) Real
( and2 (EQUALS C r u i s e S w i t c h S e n s o r 0 . 0 ) (EQUALS
CruiseActiveSensor 1.0) ) )
( d e f i n e −fun A 3 ( ) Real
( and2 (EQUALS C r u i s e S w i t c h S e n s o r 0 . 0 ) (EQUALS
CruiseActiveSensor 0.0) ) )
( d e f i n e −fun A 4 ( ) Real
( and2 (EQUALS C r u i s e S w i t c h S e n s o r 1 . 0 ) (EQUALS
CruiseActiveSensor 0.0) ) )
( d e f i n e −fun A 5 ( ) Real
( and2 (EQUALS C r u i s e S w i t c h S e n s o r 1 . 0 ) (EQUALS
CruiseActiveSensor 1.0) ) )
( d e f i n e −fun A 6 ( ) Real
(EQUALS C r u i s e S w i t c h S e n s o r 0 . 0 ) )
( d e f i n e −fun A 7 ( ) Real
(EQUALS C r u i s e A c t i v e S e n s o r 1 . 0 ) )
( d e f i n e −fun A 8 ( ) Real
(EQUALS C r u i s e A c t i v e S w i t c h 0 . 0 ) )
( d e f i n e −fun A 9 ( ) Real
(EQUALS C r u i s e S w i t c h S e n s o r 0 . 0 ) )
( d e f i n e −fun A 10 ( ) Real
(EQUALS C r u i s e A c t i v e S e n s o r 0 . 0 ) )
( d e f i n e −fun A 11 ( ) Real
(EQUALS C r u i s e S w i t c h S e n s o r 1 . 0 ) )
( d e f i n e −fun A 12 ( ) Real
(EQUALS C r u i s e A c t i v e S e n s o r 0 . 0 ) )
( d e f i n e −fun A 13 ( ) Real
(EQUALS C r u i s e S w i t c h S e n s o r 1 . 0 ) )

227

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

( d e f i n e −fun A 14 ( ) Real
(EQUALS C r u i s e A c t i v e S e n s o r 1 . 0 ) )
( d e f i n e −fun A 15 ( ) Real
( and2 (EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) (EQUALS
B r a k e P e d a l S e n s o r BrakeActuator ) ) )
( d e f i n e −fun A 16 ( ) Real
(EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) )
( d e f i n e −fun A 17 ( ) Real
(EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) )
( d e f i n e −fun A 18 ( ) Real
1.0)
( d e f i n e −fun A 19 ( ) Real
(EQUALS T h r o t t l e P e d a l S e n s o r T h r o t t l e A c t u a t o r ) )
( d e f i n e −fun A 20 ( ) Real
1.0)
( d e f i n e −fun A 21 ( ) Real
(EQUALS B r a k e P e d a l S e n s o r BrakeActuator ) )
( d e f i n e −fun B 1 ( ) Real
( o r 3 (EQUALS S p e e d t S p e e d t p l u s 1 ) (GREATER S p e e d t
S p e e d t p l u s 1 ) ( LESS D i s t a n c e S a f e D i s t a n c e ) ) )
( d e f i n e −fun B 2 ( ) Real
( o r 2 ( and2 (EQUALS S p e e d t 0 . 0 ) (EQUALS S p e e d t p l u s 1 0 . 0 )
) (GREATER S p e e d t S p e e d t p l u s 1 ) ) )
( d e f i n e −fun B 3 ( ) Real
( o r 2 ( and2 (EQUALS S p e e d t 0 . 0 ) (EQUALS S p e e d t p l u s 1 0 . 0 )
) (GREATER S p e e d t S p e e d t p l u s 1 ) ) )
( d e f i n e −fun B 4 ( ) Real
( LESS T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r ) )
( d e f i n e −fun B 5 ( ) Real
( LESS T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r ) )
( d e f i n e −fun B 6 ( ) Real
1.0)

228

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

( d e f i n e −fun B 7 ( ) Real
(GREATER T h r o t t l e P e d a l S e n s o r 0 . 0 ) )
( d e f i n e −fun B 8 ( ) Real
( o r 2 (GREATER S p e e d t D e s i r e d S p e e d ) ( LESS D i s t a n c e
SafeDistance ) ) )
( d e f i n e −fun B 9 ( ) Real
(GREATER S p e e d t D e s i r e d S p e e d ) )
( d e f i n e −fun B 10 ( ) Real
( LESS D i s t a n c e S a f e D i s t a n c e ) )
( d e f i n e −fun B 11 ( ) Real
(GREATER WheelSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun B 12 ( ) Real
(GREATER GPSSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun B 13 ( ) Real
( LESS D i s t a n c e S e n s o r 1 S a f e D i s t a n c e ) )
( d e f i n e −fun B 14 ( ) Real
( LESS D i s t a n c e S e n s o r 2 S a f e D i s t a n c e ) )
( d e f i n e −fun B 15 ( ) Real
(GREATER BrakeActuator B r a k e P e d a l S e n s o r ) )
( d e f i n e −fun B 16 ( ) Real
(GREATER BrakeActuator B r a k e P e d a l S e n s o r ) )
( d e f i n e −fun B 17 ( ) Real
1.0)
( d e f i n e −fun B 18 ( ) Real
(EQUALS T h r o t t l e P e d a l S e n s o r 0 . 0 ) )
( d e f i n e −fun B 19 ( ) Real
( LESS B r a k e P e d a l S e n s o r 1 . 0 ) )
( d e f i n e −fun C 1 ( ) Real
( LESS S p e e d t S p e e d t p l u s 1 ) )
( d e f i n e −fun C 2 ( ) Real
( and2 ( LESS S p e e d t D e s i r e d S p e e d ) (GREATER D i s t a n c e
SafeDistance ) ) )

218

229

219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264

( d e f i n e −fun C 3 ( ) Real
(GREATER T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r ) )
( d e f i n e −fun C 4 ( ) Real
( LESS S p e e d t D e s i r e d S p e e d ) )
( d e f i n e −fun C 5 ( ) Real
(GREATER T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r ) )
( d e f i n e −fun C 6 ( ) Real
( LESS WheelSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun C 7 ( ) Real
( LESS GPSSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun C 8 ( ) Real
( LESS T h r o t t l e P e d a l S e n s o r 1 . 0 ) )
( d e f i n e −fun C 9 ( ) Real
(GREATER D i s t a n c e S a f e D i s t a n c e ) )
( d e f i n e −fun C 10 ( ) Real
(GREATER D i s t a n c e S e n s o r 1 S a f e D i s t a n c e ) )
( d e f i n e −fun C 11 ( ) Real
(GREATER D i s t a n c e S e n s o r 2 S a f e D i s t a n c e ) )
( d e f i n e −fun C 12 ( ) Real
(EQUALS BrakeActuator 0 . 0 ) )
( d e f i n e −fun C 13 ( ) Real
1.0)
( d e f i n e −fun D New1 ( ) Real
(EQUALS BrakeActuator B r a k e P e d a l S e n s o r ) )
( d e f i n e −fun D New2 ( ) Real
1.0)
( d e f i n e −fun D 1 ( ) Real
(EQUALS S p e e d t S p e e d t p l u s 1 ) )
( d e f i n e −fun D 2 ( ) Real
( and2 (EQUALS S p e e d t D e s i r e d S p e e d ) (GREATER D i s t a n c e
SafeDistance ) ) )
( d e f i n e −fun D 3 ( ) Real

230

265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311

(EQUALS T h r o t t l e A c t u a t o r T h r o t t l e P e d a l S e n s o r ) )
( d e f i n e −fun D 4 ( ) Real
(EQUALS S p e e d t D e s i r e d S p e e d ) )
( d e f i n e −fun D 5 ( ) Real
1.0)
( d e f i n e −fun D 6 ( ) Real
(EQUALS WheelSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun D 7 ( ) Real
(EQUALS GPSSpeedSensor D e s i r e d S p e e d ) )
( d e f i n e −fun D 8 ( ) Real
(GREATER D i s t a n c e S a f e D i s t a n c e ) )
( d e f i n e −fun D 9 ( ) Real
(GREATER D i s t a n c e S e n s o r 1 S a f e D i s t a n c e ) )
( d e f i n e −fun D 10 ( ) Real
(GREATER D i s t a n c e S e n s o r 2 S a f e D i s t a n c e ) )
( d e f i n e −fun A 1 decomp ( ) Real
( or4 A 2 A 3 A 4 A 5 ) )
( d e f i n e −fun A 2 decomp ( ) Real
( and3 A 6 A 7 A 8 ) )
( d e f i n e −fun A 3 decomp ( ) Real
( and3 A 9 A 10 A 15 ) )
( d e f i n e −fun A 4 decomp ( ) Real
( and3 A 15 A 11 A 12 ) )
( d e f i n e −fun A 5 decomp ( ) Real
( and3 A 13 A 14 B 1 ) )
( d e f i n e −fun A 15 decomp ( ) Real
( and2 A 16 A 17 ) )
( d e f i n e −fun A 16 decomp ( ) Real
( and2 A 18 A 19 ) )
( d e f i n e −fun A 17 decomp ( ) Real
( and2 A 20 A 21 ) )

231

312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358

( d e f i n e −fun B 1 decomp ( ) Real
( and3 C 1 B 2 D 1 ) )
( d e f i n e −fun B 2 decomp ( ) Real
( and2 B 8 B 3 ) )
( d e f i n e −fun B 3 decomp ( ) Real
( and2 B 4 B 15 ) )
( d e f i n e −fun B 4 decomp ( ) Real
( and3 B 5 B 6 B 7 ) )
( d e f i n e −fun B 8 decomp ( ) Real
( o r 2 B 9 B 10 ) )
( d e f i n e −fun B 9 decomp ( ) Real
( and2 B 11 B 12 ) )
( d e f i n e −fun B 10 decomp ( ) Real
( and2 B 13 B 14 ) )
( d e f i n e −fun B 15 decomp ( ) Real
( and4 B 16 B 17 B 18 B 19 ) )
( d e f i n e −fun C 1 decomp ( ) Real
( and3 C 2 C 3 C 12 ) )
( d e f i n e −fun C 2 decomp ( ) Real
( and2 C 4 C 9 ) )
( d e f i n e −fun C 3 decomp ( ) Real
( and3 C 5 C 13 C 8 ) )
( d e f i n e −fun C 4 decomp ( ) Real
( and2 C 6 C 7 ) )
( d e f i n e −fun C 9 decomp ( ) Real
( and2 C 10 C 11 ) )
( d e f i n e −fun D 1 decomp ( ) Real
( and5 D 2 D 5 D 3 D New1 D New2 ) )
( d e f i n e −fun D 2 decomp ( ) Real
( and2 D 4 D 8 ) )
( d e f i n e −fun D 4 decomp ( ) Real
( and2 D 6 D 7 ) )

232

359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405

( d e f i n e −fun D 8 decomp ( ) Real
( and2 D 9 D 10 ) )
( push )
( maximize (− A 1 decomp A 1 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 2 decomp A 2 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 3 decomp A 3 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 4 decomp A 4 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 5 decomp A 5 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 15 decomp A 15 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 16 decomp A 16 ) )
( check−s a t )
( pop )
( push )
( maximize (− A 17 decomp A 17 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 1 decomp B 1 ) )
( check−s a t )

233

406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452

( pop )
( push )
( maximize (− B 2 decomp B 2 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 3 decomp B 3 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 4 decomp B 4 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 8 decomp B 8 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 9 decomp B 9 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 10 decomp B 10 ) )
( check−s a t )
( pop )
( push )
( maximize (− B 15 decomp B 15 ) )
( check−s a t )
( pop )
( push )
( maximize (− C 1 decomp C 1 ) )
( check−s a t )
( pop )
( push )
( maximize (− C 2 decomp C 2 ) )
( check−s a t )
( pop )

234

453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486

( push )
( maximize (− C 3 decomp C 3 ) )
( check−s a t )
( pop )
( push )
( maximize (− C 4 decomp C 4 ) )
( check−s a t )
( pop )
( push )
( maximize (− C 9 decomp C 9 ) )
( check−s a t )
( pop )
( push )
( maximize (− D 1 decomp D 1 ) )
( check−s a t )
( pop )
( push )
( maximize (− D 2 decomp D 2 ) )
( check−s a t )
( pop )
( push )
( maximize (− D 4 decomp D 4 ) )
( check−s a t )
( pop )
( push )
( maximize (− D 8 decomp D 8 ) )
( check−s a t )
( pop )

A.3

Run-Time Detection Code (C++)

This section of the appendix includes the C++ code output for detecting incomplete
and inconsistent requirements at run time in Chapter 5.
Listing A.6: Incomplete and Inconsistent Requirements Detection
1 #include <cmath>
2 #include <s t r i n g >
3

235

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

void r e c o r d c o u n t e r e x a m p l e ( s t d : : s t r i n g message ) {
;
}
double min2 ( double x1 , double x2 ) {
return ( ( ( x1 + x2 ) − ( s t d : : abs ( x1 − x2 ) ) ) / 2 . 0 ) ;
}
double and2 ( double x1 , double x2 ) {
return ( min2 ( x1 , x2 ) ) ;
}
double and3 ( double x1 , double x2 , double x3 ) {
return ( and2 ( and2 ( x1 , x2 ) , x3 ) ) ;
}
double and4 ( double x1 , double x2 , double x3 , double x4 ) {
return ( and2 ( and3 ( x1 , x2 , x3 ) , x4 ) ) ;
}

double and5 ( double x1 , double x2 , double x3 , double x4 , double x5 )
{
25
return ( and2 ( and4 ( x1 , x2 , x3 , x4 ) , x5 ) ) ;
26 }
27
28 double max2 ( double x1 , double x2 ) {
29
return ( ( x1 + x2 + ( s t d : : abs ( x1 − x2 ) ) ) / 2 ) ;
30 }
31
32 double o r 2 ( double x1 , double x2 ) {
33
return ( max2 ( x1 , x2 ) ) ;
34 }
35
36 double o r 3 ( double x1 , double x2 , double x3 ) {
37
return ( o r 2 ( x1 , o r 2 ( x2 , x3 ) ) ) ;
38 }
39
40 double o r 4 ( double x1 , double x2 , double x3 , double x4 ) {
41
return ( o r 2 ( x1 , o r 3 ( x2 , x3 , x4 ) ) ) ;
42 }
43
44 double not1 ( double x1 ) {
45
return ( 1 . 0 − x1 ) ;
46 }
47
48 double EQUALS( double a , double b ) {
49
return ( s t d : : abs ( a − b ) < 0 . 0 0 0 1 ) ? 1 . 0 : 0 . 0 ;

236

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

}
double GREATER( double a , double b ) {
return ( a > b ) ? 1 . 0 : 0 . 0 ;
}
double LESS ( double a , double b ) {
return ( a < b ) ? 1 . 0 : 0 . 0 ;
}
double
double
double
double
double
double
double
double
double
double
double
double
double
double
double
double

Speed t ;
Speed t plus 1 ;
Distance ;
SafeDistance ;
DesiredSpeed ;
ThrottleActuator ;
ThrottlePedalSensor ;
WheelSpeedSensor ;
GPSSpeedSensor ;
DistanceSensor1 ;
DistanceSensor2 ;
BrakeActuator ;
BrakePedalSensor ;
CruiseSwitchSensor ;
CruiseActiveSensor ;
CruiseActiveSwitch ;

double A 1 ( ) {
return 1 . 0 ;
}

double A 2 ( ) {
return ( and2 (EQUALS( C r u i s e S w i t c h S e n s o r , 0 . 0 ) , (EQUALS(
CruiseActiveSensor , 1.0) ) ) ) ;
83 }
84
85 double A 3 ( ) {
86
return ( and2 (EQUALS( C r u i s e S w i t c h S e n s o r , 0 . 0 ) , (EQUALS(
CruiseActiveSensor , 0.0) ) ) ) ;
87 }
88
89 double A 4 ( ) {
90
return ( and2 (EQUALS( C r u i s e S w i t c h S e n s o r , 1 . 0 ) , (EQUALS(
CruiseActiveSensor , 0.0) ) ) ) ;
91 }
92
93 double A 5 ( ) {

237

return ( and2 (EQUALS( C r u i s e S w i t c h S e n s o r , 1 . 0 ) , (EQUALS(
CruiseActiveSensor , 1.0) ) ) ) ;

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

}
double A 6 ( ) {
return (EQUALS( C r u i s e S w i t c h S e n s o r , 0 . 0 ) ) ;
}
double A 7 ( ) {
return (EQUALS( C r u i s e A c t i v e S e n s o r , 1 . 0 ) ) ;
}
double A 8 ( ) {
return (EQUALS( C r u i s e A c t i v e S w i t c h , 0 . 0 ) ) ;
}
double A 9 ( ) {
return (EQUALS( C r u i s e S w i t c h S e n s o r , 0 . 0 ) ) ;
}
double A 10 ( ) {
return (EQUALS( C r u i s e A c t i v e S e n s o r , 0 . 0 ) ) ;
}
double A 11 ( ) {
return (EQUALS( C r u i s e S w i t c h S e n s o r , 1 . 0 ) ) ;
}
double A 12 ( ) {
return (EQUALS( C r u i s e A c t i v e S e n s o r , 0 . 0 ) ) ;
}
double A 13 ( ) {
return (EQUALS( C r u i s e S w i t c h S e n s o r , 1 . 0 ) ) ;
}
double A 14 ( ) {
return (EQUALS( C r u i s e A c t i v e S e n s o r , 1 . 0 ) ) ;
}

double A 15 ( ) {
return ( and2 (EQUALS( T h r o t t l e P e d a l S e n s o r , T h r o t t l e A c t u a t o r ) , (
EQUALS( BrakePedalSensor , BrakeActuator ) ) ) ) ;
135 }
136
137 double A 16 ( ) {
138
return (EQUALS( T h r o t t l e P e d a l S e n s o r , T h r o t t l e A c t u a t o r ) ) ;

238

139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162

}
double A 17 ( ) {
return (EQUALS( BrakePedalSensor , BrakeActuator ) ) ;
}
double A 18 ( ) {
return 1 . 0 ;
}
double A 19 ( ) {
return (EQUALS( T h r o t t l e P e d a l S e n s o r , T h r o t t l e A c t u a t o r ) ) ;
}
double A 20 ( ) {
return 1 . 0 ;
}
double A 21 ( ) {
return (EQUALS( BrakePedalSensor , BrakeActuator ) ) ;
}

double B 1 ( ) {
return ( o r 3 (EQUALS( Sp ee d t , S p e e d t p l u s 1 ) , (GREATER( S pe ed t ,
S p e e d t p l u s 1 ) ) , ( LESS ( D i s t a n c e , S a f e D i s t a n c e ) ) ) ) ;
163 }
164
165 double B 2 ( ) {
166
return ( o r 2 ( and2 (EQUALS( Spe e d t , 0 . 0 ) , (EQUALS( S p e e d t p l u s 1 ,
0 . 0 ) ) ) , (GREATER( Spe e d t , S p e e d t p l u s 1 ) ) ) ) ;
167 }
168
169 double B 3 ( ) {
170
return ( o r 2 ( and2 (EQUALS( Spe e d t , 0 . 0 ) , (EQUALS( S p e e d t p l u s 1 ,
0 . 0 ) ) ) , (GREATER( Spe e d t , S p e e d t p l u s 1 ) ) ) ) ;
171 }
172
173 double B 4 ( ) {
174
return ( LESS ( T h r o t t l e A c t u a t o r , T h r o t t l e P e d a l S e n s o r ) ) ;
175 }
176
177 double B 5 ( ) {
178
return ( LESS ( T h r o t t l e A c t u a t o r , T h r o t t l e P e d a l S e n s o r ) ) ;
179 }
180
181 double B 6 ( ) {
182
return 1 . 0 ;

239

183
184
185
186
187
188
189
190

}
double B 7 ( ) {
return (GREATER( T h r o t t l e P e d a l S e n s o r , 0 . 0 ) ) ;
}

double B 8 ( ) {
return ( o r 2 (GREATER( S pe ed t , D e s i r e d S p e e d ) , ( LESS ( D i s t a n c e ,
SafeDistance ) ) ) ) ;
191 }
192
193 double B 9 ( ) {
194
return (GREATER( Sp ee d t , D e s i r e d S p e e d ) ) ;
195 }
196
197 double B 10 ( ) {
198
return ( LESS ( D i s t a n c e , S a f e D i s t a n c e ) ) ;
199 }
200
201 double B 11 ( ) {
202
return (GREATER( WheelSpeedSensor , D e s i r e d S p e e d ) ) ;
203 }
204
205 double B 12 ( ) {
206
return (GREATER( GPSSpeedSensor , D e s i r e d S p e e d ) ) ;
207 }
208
209 double B 13 ( ) {
210
return ( LESS ( D i s t a n c e S e n s o r 1 , S a f e D i s t a n c e ) ) ;
211 }
212
213 double B 14 ( ) {
214
return ( LESS ( D i s t a n c e S e n s o r 2 , S a f e D i s t a n c e ) ) ;
215 }
216
217 double B 15 ( ) {
218
return (GREATER( BrakeActuator , B r a k e P e d a l S e n s o r ) ) ;
219 }
220
221 double B 16 ( ) {
222
return (GREATER( BrakeActuator , B r a k e P e d a l S e n s o r ) ) ;
223 }
224
225 double B 17 ( ) {
226
return 1 . 0 ;
227 }
228

240

229
230
231
232
233
234
235
236
237
238
239
240
241
242

double B 18 ( ) {
return (EQUALS( T h r o t t l e P e d a l S e n s o r , 0 . 0 ) ) ;
}
double B 19 ( ) {
return ( LESS ( BrakePedalSensor , 1 . 0 ) ) ;
}
double C 1 ( ) {
return ( LESS ( S pe ed t , S p e e d t p l u s 1 ) ) ;
}

double C 2 ( ) {
return ( and2 ( LESS ( S pe ed t , D e s i r e d S p e e d ) , (GREATER( D i s t a n c e ,
SafeDistance ) ) ) ) ;
243 }
244
245 double C 3 ( ) {
246
return (GREATER( T h r o t t l e A c t u a t o r , T h r o t t l e P e d a l S e n s o r ) ) ;
247 }
248
249 double C 4 ( ) {
250
return ( LESS ( S pe ed t , D e s i r e d S p e e d ) ) ;
251 }
252
253 double C 5 ( ) {
254
return (GREATER( T h r o t t l e A c t u a t o r , T h r o t t l e P e d a l S e n s o r ) ) ;
255 }
256
257 double C 6 ( ) {
258
return ( LESS ( WheelSpeedSensor , D e s i r e d S p e e d ) ) ;
259 }
260
261 double C 7 ( ) {
262
return ( LESS ( GPSSpeedSensor , D e s i r e d S p e e d ) ) ;
263 }
264
265 double C 8 ( ) {
266
return ( LESS ( T h r o t t l e P e d a l S e n s o r , 1 . 0 ) ) ;
267 }
268
269 double C 9 ( ) {
270
return (GREATER( D i s t a n c e , S a f e D i s t a n c e ) ) ;
271 }
272
273 double C 10 ( ) {
274
return (GREATER( D i s t a n c e S e n s o r 1 , S a f e D i s t a n c e ) ) ;

241

275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302

}
double C 11 ( ) {
return (GREATER( D i s t a n c e S e n s o r 2 , S a f e D i s t a n c e ) ) ;
}
double C 12 ( ) {
return (EQUALS( BrakeActuator , 0 . 0 ) ) ;
}
double C 13 ( ) {
return 1 . 0 ;
}
double D New1 ( ) {
return (EQUALS( BrakeActuator , B r a k e P e d a l S e n s o r ) ) ;
}
double D New2 ( ) {
return 1 . 0 ;
}
double D 1 ( ) {
return (EQUALS( S pe ed t , S p e e d t p l u s 1 ) ) ;
}

double D 2 ( ) {
return ( and2 (EQUALS( S pe ed t , D e s i r e d S p e e d ) , (GREATER( D i s t a n c e ,
SafeDistance ) ) ) ) ;
303 }
304
305 double D 3 ( ) {
306
return (EQUALS( T h r o t t l e A c t u a t o r , T h r o t t l e P e d a l S e n s o r ) ) ;
307 }
308
309 double D 4 ( ) {
310
return (EQUALS( S pe ed t , D e s i r e d S p e e d ) ) ;
311 }
312
313 double D 5 ( ) {
314
return 1 . 0 ;
315 }
316
317 double D 6 ( ) {
318
return (EQUALS( WheelSpeedSensor , D e s i r e d S p e e d ) ) ;
319 }
320

242

321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367

double D 7 ( ) {
return (EQUALS( GPSSpeedSensor , D e s i r e d S p e e d ) ) ;
}
double D 8 ( ) {
return (GREATER( D i s t a n c e , S a f e D i s t a n c e ) ) ;
}
double D 9 ( ) {
return (GREATER( D i s t a n c e S e n s o r 1 , S a f e D i s t a n c e ) ) ;
}
double D 10 ( ) {
return (GREATER( D i s t a n c e S e n s o r 2 , S a f e D i s t a n c e ) ) ;
}
double A 1 decomp ( ) {
return ( o r 4 ( A 2 ( ) , A 3 ( ) , A 4 ( ) , A 5 ( ) ) ) ;
}
double A 2 decomp ( ) {
return ( and3 ( A 6 ( ) , A 7 ( ) , A 8 ( ) ) ) ;
}
double A 3 decomp ( ) {
return ( and3 ( A 9 ( ) , A 10 ( ) , A 15 ( ) ) ) ;
}
double A 4 decomp ( ) {
return ( and3 ( A 15 ( ) , A 11 ( ) , A 12 ( ) ) ) ;
}
double A 5 decomp ( ) {
return ( and3 ( A 13 ( ) , A 14 ( ) , B 1 ( ) ) ) ;
}
double A 15 decomp ( ) {
return ( and2 ( A 16 ( ) , A 17 ( ) ) ) ;
}
double A 16 decomp ( ) {
return ( and2 ( A 18 ( ) , A 19 ( ) ) ) ;
}
double A 17 decomp ( ) {
return ( and2 ( A 20 ( ) , A 21 ( ) ) ) ;
}

243

368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414

double B 1 decomp ( ) {
return ( and3 ( C 1 ( ) , B 2 ( ) , D 1 ( ) ) ) ;
}
double B 2 decomp ( ) {
return ( and2 ( B 8 ( ) , B 3 ( ) ) ) ;
}
double B 3 decomp ( ) {
return ( and2 ( B 4 ( ) , B 15 ( ) ) ) ;
}
double B 4 decomp ( ) {
return ( and3 ( B 5 ( ) , B 6 ( ) , B 7 ( ) ) ) ;
}
double B 8 decomp ( ) {
return ( o r 2 ( B 9 ( ) , B 10 ( ) ) ) ;
}
double B 9 decomp ( ) {
return ( and2 ( B 11 ( ) , B 12 ( ) ) ) ;
}
double B 10 decomp ( ) {
return ( and2 ( B 13 ( ) , B 14 ( ) ) ) ;
}
double B 15 decomp ( ) {
return ( and4 ( B 16 ( ) , B 17 ( ) , B 18 ( ) , B 19 ( ) ) ) ;
}
double C 1 decomp ( ) {
return ( and3 ( C 2 ( ) , C 3 ( ) , C 12 ( ) ) ) ;
}
double C 2 decomp ( ) {
return ( and2 ( C 4 ( ) , C 9 ( ) ) ) ;
}
double C 3 decomp ( ) {
return ( and3 ( C 5 ( ) , C 13 ( ) , C 8 ( ) ) ) ;
}
double C 4 decomp ( ) {
return ( and2 ( C 6 ( ) , C 7 ( ) ) ) ;

244

415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461

}
double C 9 decomp ( ) {
return ( and2 ( C 10 ( ) , C 11 ( ) ) ) ;
}
double D 1 decomp ( ) {
return ( and5 ( D 2 ( ) , D 5 ( ) , D 3 ( ) , D New1 ( ) , D New2 ( ) ) ) ;
}
double D 2 decomp ( ) {
return ( and2 ( D 4 ( ) , D 8 ( ) ) ) ;
}
double D 4 decomp ( ) {
return ( and2 ( D 6 ( ) , D 7 ( ) ) ) ;
}
double D 8 decomp ( ) {
return ( and2 ( D 9 ( ) , D 10 ( ) ) ) ;
}
bool u p d a t e d s a t o f A 1 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = A 1 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = A 1 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ”A 1” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f A 2 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = A 2 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = A 2 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;

245

462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508

else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ”A 2” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f A 3 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = A 3 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = A 3 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ”A 3” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f A 4 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = A 4 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = A 4 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ”A 4” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f A 5 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = A 5 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n

246

509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555

bool c h i l d s a t = A 5 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ”A 5” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f A 1 5 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = A 15 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = A 15 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ” A 15 ” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f A 1 6 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = A 16 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = A 16 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ” A 16 ” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}

247

556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602

bool u p d a t e d s a t o f A 1 7 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = A 17 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = A 17 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ” A 17 ” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f B 1 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = B 1 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = B 1 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”B 1” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f B 2 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = B 2 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = B 2 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”B 2” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t

248

603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649

return f a l s e ;
}
}
bool u p d a t e d s a t o f B 3 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = B 3 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = B 3 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”B 3” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f B 4 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = B 4 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = B 4 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”B 4” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f B 8 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = B 8 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = B 8 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {

249

650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696

// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”B 8” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f B 9 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = B 9 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = B 9 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”B 9” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f B 1 0 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = B 10 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = B 10 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ” B 10 ” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f B 1 5 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = B 15 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = B 15 decomp ( ) ;

250

697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743

i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ” B 15 ” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f C 1 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = C 1 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = C 1 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”C 1” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f C 2 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = C 2 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = C 2 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”C 2” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f C 3 ( ) {

251

744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790

// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = C 3 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = C 3 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”C 3” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f C 4 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = C 4 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = C 4 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”C 4” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f C 9 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = C 9 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = C 9 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
record counterexample ( ”C 9” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;

252

791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837

}
}
bool u p d a t e d s a t o f D 1 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = D 1 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = D 1 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ”D 1” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f D 2 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = D 2 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = D 2 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t
r e c o r d c o u n t e r e x a m p l e ( ”D 2” ) ;
// Unsat i f i n c o m p l e t e / i n c o r r e c t
return f a l s e ;
}
}
bool u p d a t e d s a t o f D 4 ( ) {
// A s s e s s Parent S a t i s f a c t i o n
bool p a r e n t s a t = D 4 ( ) ;
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
bool c h i l d s a t = D 4 decomp ( ) ;
i f ( p a r e n t s a t == c h i l d s a t )
return p a r e n t s a t ;
else {
// Save v a r i a b l e s and r e q u i r e m e n t

253

838
r e c o r d c o u n t e r e x a m p l e ( ”D 4” ) ;
839
840
// Unsat i f i n c o m p l e t e / i n c o r r e c t
841
return f a l s e ;
842
}
843 }
844
845 bool u p d a t e d s a t o f D 8 ( ) {
846
// A s s e s s Parent S a t i s f a c t i o n
847
bool p a r e n t s a t = D 8 ( ) ;
848
// A s s e s s A g g r e g a t e C h i l d S a t i s f a c t i o n
849
bool c h i l d s a t = D 8 decomp ( ) ;
850
851
i f ( p a r e n t s a t == c h i l d s a t )
852
return p a r e n t s a t ;
853
else {
854
// Save v a r i a b l e s and r e q u i r e m e n t
855
r e c o r d c o u n t e r e x a m p l e ( ”D 8” ) ;
856
857
// Unsat i f i n c o m p l e t e / i n c o r r e c t
858
return f a l s e ;
859
}
860 }

254

Appendix B
Feature Interaction Artifacts
This appendix presents the goal model specifications as well as the satisfiability-modulo
theory (SMT) solver and code (C++) outputs from the Phorcys and Thoosa tools for feature
interaction detection. Feature interaction artifacts are included in this appendix since no
complete example can be given, due to issues of space, within Chapters 6 and 8.

B.1

Goal Model Specifications

This section of the appendix includes the XML schema for representing goal models in
XML, as well as XML representations of the braking system goal model used in Chapters 6,
7, and 8.

B.1.1

Goal Model Schema
Listing B.1: XSD Goal Model XML Schema for Feature Interactions

1 <?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?>
2 <xs : schema xmlns : xs=”h t t p : / /www. w3 . o r g /2001/XMLSchema”
3
elementFormDefault=” q u a l i f i e d ”
4
xmlns : x s i =”h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ”>
5
<xs : e l e m e n t name=”g o a l m o d e l”>
6
<xs : complexType>
7
<xs : sequence >
8
<xs : e l e m e n t r e f =”g o a l ”/>
9
<xs : e l e m e n t r e f =”environment”/>
10
</xs : sequence >

255

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

</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”environment”>
<xs : complexType>
<xs : sequence >
<xs : e l e m e n t minOccurs=”0” maxOccurs=”unbounded ” r e f =”env”/>
</xs : sequence >
</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”env”>
<xs : complexType>
<xs : a t t r i b u t e name=”name” u s e=” r e q u i r e d ” type=”xs : NCName”/>
<xs : a t t r i b u t e name=” r e l a t i o n s h i p ” u s e=” r e q u i r e d ” type=”xs :
s t r i n g ”/>
</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”g o a l ”>
<xs : complexType>
<xs : c h o i c e >
<xs : e l e m e n t maxOccurs=”unbounded ” r e f =”g o a l ”/>
<xs : e l e m e n t r e f =”a g e n t ”/>
</xs : c h o i c e >
<xs : a t t r i b u t e name=”c o n t e n t s ” u s e=” r e q u i r e d ” type=”xs : s t r i n g
”/>
<xs : a t t r i b u t e name=”name” u s e=” r e q u i r e d ” type=”xs : NCName”/>
<xs : a t t r i b u t e name=” r e l a t i o n s h i p ” u s e=” r e q u i r e d ” type=”xs :
s t r i n g ”/>
<xs : a t t r i b u t e name=”type ” u s e=” r e q u i r e d ” type=”xs : NCName”/>
</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”a g e n t”>
<xs : complexType>
<xs : a t t r i b u t e name=”c o n t e n t s ” u s e=” r e q u i r e d ” type=”xs : s t r i n g
”/>
<xs : a t t r i b u t e name=” l o c a t i o n ” u s e=” r e q u i r e d ” type=”xs : NCName
”/>
<xs : a t t r i b u t e name=”name” u s e=” r e q u i r e d ” type=”xs : NCName”/>
</xs : complexType>
</xs : element>
</xs : schema>

B.1.2

Goal Model for Braking System in Chapter 6
Listing B.2: Braking System Goal Model in Chapter 6

1 <?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?>
2 <!−− c r e a t e d with XMLSpear −−>

256

3 <g o a l m o d e l xmlns : x s i =”h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ”
x s i : noNamespaceSchemaLocation =’ g o a l m o d e l . xsd ’>
4
5
<g o a l name=”A” c o n t e n t s =”Maintain ( Brake System ) ” r e l a t i o n s h i p
=”” type=”AND”>
6
<g o a l name=”A 1” c o n t e n t s=”Maintain ( Brake Force ) ”
r e l a t i o n s h i p =”” type=”OR”>
7
<g o a l name=”B” c o n t e n t s=”Achieve ( Standard Force Braking
) ” r e l a t i o n s h i p =”” type=”AND”>
8
<g o a l name=”B 1 ” c o n t e n t s =”(= SF C B F t p l u s o n e ) ”
r e l a t i o n s h i p =”” type=”POST”>
9
<a g e n t name=”B 1 Agent ” c o n t e n t s=”H y d r a u l i c Brake
S e n s o r ” l o c a t i o n =”environment”/>
10
</g o a l >
11
<g o a l name=”B 2 ” c o n t e n t s =”Achieve ( Apply Standard
Force ) ” r e l a t i o n s h i p =”” type=”REQ”>
12
<a g e n t name=”B 2 Agent ” c o n t e n t s=”H y d r a u l i c Brake
Actuator ” l o c a t i o n =”system”/>
13
</g o a l >
14
<g o a l name=”B 3 ” c o n t e n t s =”(&g t ; C B F t p l u s o n e 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
15
<a g e n t name=”B 3 Agent ” c o n t e n t s=”CBF Value ”
l o c a t i o n =”environment”/>
16
</g o a l >
17
</g o a l >
18
<g o a l name=”C” c o n t e n t s=”Achieve ( Regen Braking ) ”
r e l a t i o n s h i p =”” type=”AND”>
19
<g o a l name=”C 1 ” c o n t e n t s =”(&g t ; C B F t p l u s o n e 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
20
<a g e n t name=”C 1 Agent ” c o n t e n t s=”CBF Value ”
l o c a t i o n =”environment”/>
21
</g o a l >
22
<g o a l name=”C 2 ” c o n t e n t s=”Achieve ( Regen and Standard
Force ) ” r e l a t i o n s h i p =”” type=”OR”>
23
<g o a l name=”C 3 ” c o n t e n t s=”Achieve ( Standard Force
Braking ) ” r e l a t i o n s h i p =”” type=”AND”>
24
<g o a l name=”C 5 ” c o n t e n t s =”(= SF ( ∗
C B F t p l u s o n e 0 . 2 ) ) ” r e l a t i o n s h i p =”” type=”
POST”>
25
<a g e n t name=”C 5 Agent ” c o n t e n t s=”H y d r a u l i c
Brake S e n s o r ” l o c a t i o n =”environment”/>
26
</g o a l >
27
<g o a l name=”C 6 ” c o n t e n t s=”Achieve ( Apply
Standard Force ) ” r e l a t i o n s h i p =”” type=”REQ”>
28
<a g e n t name=”C 6 Agent ” c o n t e n t s=”H y d r a u l i c
Brake Actuator ” l o c a t i o n =”system”/>
29
</g o a l >

257

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

<g o a l name=”C 7 ” c o n t e n t s =”(&g t ; C B F t p l u s o n e
2 0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”C 7 Agent ” c o n t e n t s=”CBF Value ”
l o c a t i o n =”environment”/>
</g o a l >
</g o a l >
<g o a l name=”C 4 ” c o n t e n t s=”Achieve ( Regen Force ) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”C 8 ” c o n t e n t s =”(& l t ; C B F t p l u s o n e
5 0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”C 7 Agent ” c o n t e n t s=”CBF Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”C 9 ” c o n t e n t s=”Achieve ( Apply Regen
Force ) ” r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”C 6 Agent ” c o n t e n t s=”R e g e n e r a t i o n
Brake Actuator ” l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”C 10 ” c o n t e n t s =”(= RF ( ∗
C B F t p l u s o n e 0 . 8 ) ) ” r e l a t i o n s h i p =”” type=”
POST”>
<a g e n t name=”C 5 Agent ” c o n t e n t s=”R e g e n e r a t i o n
Brake S e n s o r ” l o c a t i o n =”environment”/>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”A 2” c o n t e n t s=”Maintain ( Brake Command) ”
r e l a t i o n s h i p =”” type=”OR”>
<g o a l name=”D” c o n t e n t s =”Achieve ( Brake−by−Wire ) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”D 2” c o n t e n t s=”Achieve ( Read CBF) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”D 2 Agent ” c o n t e n t s =”Memory (CBF) ”
l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”D 3” c o n t e n t s =”(&g t ; BF 0 . 0 ) ” r e l a t i o n s h i p
=”” type=”PRE”>
<a g e n t name=”D 3 Agent ” c o n t e n t s =”BF Value ” l o c a t i o n
=”environment”/>
</g o a l >
<g o a l name=”D 4” c o n t e n t s=”Achieve ( Read Brake Force ) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”D 4 Agent ” c o n t e n t s =”Brake Pedal S e n s o r
(BF) ” l o c a t i o n =”system”/>
</g o a l >

258

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

<g o a l name=”D 5” c o n t e n t s=”Achieve ( Brake P u l s e ) ”
r e l a t i o n s h i p =”” type=”OR”>
<g o a l name=”D 8” c o n t e n t s=”Achieve ( Brake On) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”D 10 ” c o n t e n t s =”(= CBF t 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”D 10 Agent ” c o n t e n t s =”CBF Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”D 11 ” c o n t e n t s =”(= C B F t p l u s o n e BF)
” r e l a t i o n s h i p =”” type=”POST”>
<a g e n t name=”D 11 Agent ” c o n t e n t s =”Brake Pedal
S e n s o r (BF) ” l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”D 12a ” c o n t e n t s=”Achieve ( Brake Force
Change ) ” r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”D 12a Agent ” c o n t e n t s=”Memory (
C B F t p l u s o n e ) ” l o c a t i o n =”system”/>
</g o a l >
</g o a l >
<g o a l name=”D 9” c o n t e n t s=”Achieve ( Brake O f f ) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”D 12b ” c o n t e n t s=”Achieve ( Brake Force
Change ) ” r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”D 12b Agent ” c o n t e n t s=”Memory (
C B F t p l u s o n e ) ” l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”D 13 ” c o n t e n t s =”(= C B F t p l u s o n e
0 . 0 ) ” r e l a t i o n s h i p =”” type=”POST”>
<a g e n t name=”D 13 Agent ” c o n t e n t s =”
C B F t p l u s o n e Value ” l o c a t i o n =”environment
”/>
</g o a l >
<g o a l name=”D 14 ” c o n t e n t s =”(&g t ; CBF t 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”D 14 Agent ” c o n t e n t s =”CBF Value ”
l o c a t i o n =”environment”/>
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”D 6” c o n t e n t s =”(= SS 1 . 0 ) ” r e l a t i o n s h i p =””
type=”PRE”>
<a g e n t name=”D 6 Agent ” c o n t e n t s =”SS Value ” l o c a t i o n
=”environment”/>
</g o a l >
<g o a l name=”D 7” c o n t e n t s=”Achieve ( Read SS ) ”
r e l a t i o n s h i p =”” type=”REQ”>

259

87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107

<a g e n t name=”D 7 Agent ” c o n t e n t s =” S l i p S e n s o r ”
l o c a t i o n =”system”/>
</g o a l >
</g o a l >
<g o a l name=”E” c o n t e n t s=”Achieve ( Anti−Lock Braking ) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”E 2 ” c o n t e n t s =”Achieve ( Read CBF) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”E 2 Agent ” c o n t e n t s=”Memory (CBF) ”
l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”E 3 ” c o n t e n t s =”(= C B F t p l u s o n e BF) ”
r e l a t i o n s h i p =”” type=”POST”>
<a g e n t name=”E 3 Agent ” c o n t e n t s=”BF Value ” l o c a t i o n
=”environment”/>
</g o a l >
<g o a l name=”E 4 ” c o n t e n t s =”Achieve ( Read Brake Force ) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”E 4 Agent ” c o n t e n t s=”Brake Pedal S e n s o r
(BF) ” l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”E 5 ” c o n t e n t s =”(&g t ; BF 0 . 0 ) ” r e l a t i o n s h i p
=”” type=”PRE”>
<a g e n t name=”E 5 Agent ” c o n t e n t s=”BF Value ” l o c a t i o n
=”environment”/>
</g o a l >
<g o a l name=”E 6 ” c o n t e n t s =”(& l t ; SS 1 . 0 ) ” r e l a t i o n s h i p
=”” type=”PRE”>
<a g e n t name=”E 6 Agent ” c o n t e n t s=”SS Value ” l o c a t i o n
=”environment”/>
</g o a l >
<g o a l name=”E 7 ” c o n t e n t s =”Achieve ( Read SS ) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”E 7 Agent ” c o n t e n t s=” S l i p S e n s o r ”
l o c a t i o n =”system”/>
</g o a l >
</g o a l >
</g o a l >
</g o a l >

108
109
110
111
112
113
<environment/>
114 </goalmodel>

B.1.3

Goal Model for Braking System in Chapter 7 and 8
Listing B.3: Braking System Goal Model in Chapter 7 and 8
260

1 <?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?>
2 <!−− c r e a t e d with XMLSpear −−>
3 <g o a l m o d e l xmlns : x s i =”h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ”
x s i : noNamespaceSchemaLocation =’ g o a l m o d e l . xsd ’>
4
5
<g o a l name=”A” c o n t e n t s =”Maintain ( Brake System ) ” r e l a t i o n s h i p
=”” type=”AND”>
6
<g o a l name=”A 1” c o n t e n t s=”Maintain ( Brake Force ) ”
r e l a t i o n s h i p =”” type=”OR”>
7
<g o a l name=”B” c o n t e n t s=”Achieve ( Standard Force Braking
) ” r e l a t i o n s h i p =”” type=”AND”>
8
<g o a l name=”B 1 ” c o n t e n t s =”(= SF C B F t p l u s o n e ) ”
r e l a t i o n s h i p =”” type=”POST”>
9
<a g e n t name=”B 1 Agent ” c o n t e n t s=”H y d r a u l i c
Brake S e n s o r ” l o c a t i o n =”environment”/>
10
</g o a l >
11
<g o a l name=”B 2 ” c o n t e n t s =”Achieve ( Apply Standard
Force ) ” r e l a t i o n s h i p =”” type=”REQ”>
12
<a g e n t name=”B 2 Agent ” c o n t e n t s=”H y d r a u l i c
Brake Actuator ” l o c a t i o n =”system”/>
13
</g o a l >
14
<g o a l name=”B 3 ” c o n t e n t s =”(&g t ; C B F t p l u s o n e
0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
15
<a g e n t name=”B 3 Agent ” c o n t e n t s=”CBF Value ”
l o c a t i o n =”environment”/>
16
</g o a l >
17
</g o a l >
18
<g o a l name=”C” c o n t e n t s=”Achieve ( Regen Braking ) ”
r e l a t i o n s h i p =”” type=”AND”>
19
<g o a l name=”C 1 ” c o n t e n t s =”(&g t ; C B F t p l u s o n e
0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
20
<a g e n t name=”C 1 Agent ” c o n t e n t s=”CBF Value ”
l o c a t i o n =”environment”/>
21
</g o a l >
22
<g o a l name=”C 2 ” c o n t e n t s=”Achieve ( Regen and
Standard Force ) ” r e l a t i o n s h i p =”” type=”OR”>
23
<g o a l name=”C 3 ” c o n t e n t s=”Achieve ( Standard
Force Braking ) ” r e l a t i o n s h i p =”” type=”AND”>
24
<g o a l name=”C 5 ” c o n t e n t s =”(= SF ( ∗
C B F t p l u s o n e 0 . 2 ) ) ” r e l a t i o n s h i p =””
type=”POST”>
25
<a g e n t name=”C 5 Agent ” c o n t e n t s=”
H y d r a u l i c Brake S e n s o r ” l o c a t i o n =”
environment”/>
26
</g o a l >
27
<g o a l name=”C 6 ” c o n t e n t s=”Achieve ( Apply

261

28

29
30

31
32
33
34
35
36

37
38
39

40

41
42

43

44
45
46
47
48
49
50
51

Standard Force ) ” r e l a t i o n s h i p =”” type=”
REQ”>
<a g e n t name=”C 6 Agent ” c o n t e n t s=”
H y d r a u l i c Brake Actuator ” l o c a t i o n =”
system”/>
</g o a l >
<g o a l name=”C 7 ” c o n t e n t s =”(&g t ;
C B F t p l u s o n e 0 . 2 ) ” r e l a t i o n s h i p =””
type=”PRE”>
<a g e n t name=”C 7 Agent ” c o n t e n t s=”CBF
Value ” l o c a t i o n =”environment”/>
</g o a l >
</g o a l >
<g o a l name=”C 4 ” c o n t e n t s=”Achieve ( Regen Force )
” r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”C 8 ” c o n t e n t s =”(& l t ;
C B F t p l u s o n e 0 . 5 ) ” r e l a t i o n s h i p =””
type=”PRE”>
<a g e n t name=”C 7 Agent ” c o n t e n t s=”CBF
Value ” l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”C 9 ” c o n t e n t s=”Achieve ( Apply
Regen Force ) ” r e l a t i o n s h i p =”” type=”REQ
”>
<a g e n t name=”C 6 Agent ” c o n t e n t s=”
R e g e n e r a t i o n Brake Actuator ”
l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”C 10 ” c o n t e n t s =”(= RF ( ∗
C B F t p l u s o n e 0 . 8 ) ) ” r e l a t i o n s h i p =””
type=”POST”>
<a g e n t name=”C 5 Agent ” c o n t e n t s=”
R e g e n e r a t i o n Brake S e n s o r ” l o c a t i o n
=”environment”/>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”A 2” c o n t e n t s=”Maintain ( Brake Command) ”
r e l a t i o n s h i p =”” type=”OR”>
<g o a l name=”D” c o n t e n t s =”Achieve ( Brake−by−Wire ) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”D 2” c o n t e n t s =”Achieve ( Read CBF) ”
r e l a t i o n s h i p =”” type=”REQ”>

262

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

<a g e n t name=”D 2 Agent ” c o n t e n t s =”Memory (CBF) ”
l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”D 3” c o n t e n t s =”(&g t ; BF 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”D 3 Agent ” c o n t e n t s =”BF Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”D 4” c o n t e n t s =”Achieve ( Read Brake Force
) ” r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”D 4 Agent ” c o n t e n t s =”Brake Pedal
S e n s o r (BF) ” l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”D 5” c o n t e n t s =”Achieve ( Brake P u l s e ) ”
r e l a t i o n s h i p =”” type=”OR”>
<g o a l name=”D 8” c o n t e n t s=”Achieve ( Brake On) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”D 10 ” c o n t e n t s =”(= CBF t 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”D 10 Agent ” c o n t e n t s =”CBF
Value ” l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”D 11 ” c o n t e n t s =”(=
C B F t p l u s o n e BF) ” r e l a t i o n s h i p =”” type
=”POST”>
<a g e n t name=”D 11 Agent ” c o n t e n t s =”
Brake Pedal S e n s o r (BF) ” l o c a t i o n =”
environment”/>
</g o a l >
<g o a l name=”D 12a ” c o n t e n t s=”Achieve ( Brake
Force Change ) ” r e l a t i o n s h i p =”” type=”REQ
”>
<a g e n t name=”D 12a Agent ” c o n t e n t s=”
Memory ( C B F t p l u s o n e ) ” l o c a t i o n =”
system”/>
</g o a l >
</g o a l >
<g o a l name=”D 9” c o n t e n t s=”Achieve ( Brake O f f ) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”D 12b ” c o n t e n t s=”Achieve ( Brake
Force Change ) ” r e l a t i o n s h i p =”” type=”REQ
”>
<a g e n t name=”D 12b Agent ” c o n t e n t s=”
Memory ( C B F t p l u s o n e ) ” l o c a t i o n =”
system”/>
</g o a l >
<g o a l name=”D 13 ” c o n t e n t s =”(=

263

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

C B F t p l u s o n e 0 . 0 ) ” r e l a t i o n s h i p =””
type=”POST”>
<a g e n t name=”D 13 Agent ” c o n t e n t s =”
C B F t p l u s o n e Value ” l o c a t i o n =”
environment”/>
</g o a l >
<g o a l name=”D 14 ” c o n t e n t s =”(&g t ; CBF t
0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”D 14 Agent ” c o n t e n t s =”CBF
Value ” l o c a t i o n =”environment”/>
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”D 6” c o n t e n t s =”(= SS 1 . 0 ) ” r e l a t i o n s h i p
=”” type=”PRE”>
<a g e n t name=”D 6 Agent ” c o n t e n t s =”SS Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”D 7” c o n t e n t s =”Achieve ( Read SS ) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”D 7 Agent ” c o n t e n t s =” S l i p S e n s o r ”
l o c a t i o n =”system”/>
</g o a l >
</g o a l >
<g o a l name=”E” c o n t e n t s=”Achieve ( Anti−Lock Braking ) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”E 2 ” c o n t e n t s =”Achieve ( Read CBF) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”E 2 Agent ” c o n t e n t s=”Memory (CBF) ”
l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”E 3 ” c o n t e n t s =”(= C B F t p l u s o n e BF) ”
r e l a t i o n s h i p =”” type=”POST”>
<a g e n t name=”E 3 Agent ” c o n t e n t s=”BF Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”E 4 ” c o n t e n t s =”Achieve ( Read Brake Force
) ” r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”E 4 Agent ” c o n t e n t s=”Brake Pedal
S e n s o r (BF) ” l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”E 5 ” c o n t e n t s =”(&g t ; BF 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”E 5 Agent ” c o n t e n t s=”BF Value ”
l o c a t i o n =”environment”/>
</g o a l >

264

<g o a l name=”E 6 ” c o n t e n t s =”(& l t ; SS 1 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”E 6 Agent ” c o n t e n t s=”SS Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”E 7 ” c o n t e n t s =”Achieve ( Read SS ) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”E 7 Agent ” c o n t e n t s=” S l i p S e n s o r ”
l o c a t i o n =”system”/>
</g o a l >
</g o a l >
</g o a l >
</g o a l >

104
105
106
107
108

109
110
111
112
113
114
<environment/>
115 </goalmodel>

B.2

Design-Time Detection Constraints (SMT)

This section of the appendix includes the SMT constraint output for detecting feature
interactions in Chapter 6. Constraint sets are listed for each of the four features in the
braking system goal model.

B.2.1

Detection Constraints for Failure of Feature B
Listing B.4: Feature Interaction for Failure of Feature B

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

( s e t −o p t i o n : p r i n t −s u c c e s s t r u e )
( d e f i n e −fun min2 ( ( x1 Real ) ( x2 Real ) ) Real ( / (− (+ x1 x2 ) ( abs (−
x1 x2 ) ) ) 2 ) )
( d e f i n e −fun max2 ( ( x1 Real ) ( x2 Real ) ) Real ( / (+ x1 x2 ( abs (− x1
x2 ) ) ) 2 ) )
( d e c l a r e −c o n s t BF Real )
( d e c l a r e −c o n s t C B F t p l u s o n e D 1 1 Bool )
( d e c l a r e −c o n s t RF C 10 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e D 1 3 Bool )
( d e c l a r e −c o n s t CBF t D 14 Bool )
( d e c l a r e −c o n s t SF Real )
( d e c l a r e −c o n s t C B F t p l u s o n e Real )
( d e c l a r e −c o n s t BF D 3 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 8 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 7 Bool )
( d e c l a r e −c o n s t SS Real )
( d e c l a r e −c o n s t SF B 1 Bool )

265

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

( d e c l a r e −c o n s t C B F t p l u s o n e E 3 Bool )
( d e c l a r e −c o n s t SF C 5 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e B 3 Bool )
( d e c l a r e −c o n s t BF E 5 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 1 Bool )
( d e c l a r e −c o n s t CBF t D 10 Bool )
( d e c l a r e −c o n s t CBF t Real )
( d e c l a r e −c o n s t RF Real )
( d e c l a r e −c o n s t C s Bool )
( d e c l a r e −c o n s t B s Bool )
( d e c l a r e −c o n s t E s Bool )
( d e c l a r e −c o n s t D s Bool )
( d e c l a r e −c o n s t SS D 6 Bool )
( d e c l a r e −c o n s t SS E 6 Bool )
( d e f i n e −fun V SS ( ) Bool ( o r ( o r f a l s e SS D 6 ) SS E 6 ) )
( d e f i n e −fun V SF ( ) Bool ( o r ( o r f a l s e SF B 1 ) SF C 5 ) )
( d e f i n e −fun V CBF t ( ) Bool ( o r ( o r f a l s e CBF t D 10 ) CBF t D 14 ) )
( d e f i n e −fun V RF ( ) Bool ( o r f a l s e RF C 10 ) )
( d e f i n e −fun V BF ( ) Bool ( o r ( o r f a l s e BF D 3 ) BF E 5 ) )
( d e f i n e −fun V CBF t plus one ( ) Bool ( o r ( o r ( o r ( o r ( o r ( o r ( o r
f a l s e CBF t plus one B 3 ) CBF t plus one C 1 ) CBF t plus one C 7
) CBF t plus one C 8 ) CBF t plus one D 11 ) CBF t plus one D 13 )
CBF t plus one E 3 ) )
( d e f i n e −fun B 1 ( ) Bool ( and ( and (= SF C B F t p l u s o n e ) V SF )
V CBF t plus one ) )
( d e f i n e −fun B 2 ( ) Bool t r u e )
( d e f i n e −fun B 3 ( ) Bool ( and (> C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun B ( ) Bool ( and ( and ( and t r u e B 1 ) B 2 ) B 3 ) )
( d e f i n e −fun C 1 ( ) Bool ( and (> C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 5 ( ) Bool ( and ( and (= SF ( ∗ C B F t p l u s o n e 0 . 2 ) )
V SF ) V CBF t plus one ) )
( d e f i n e −fun C 6 ( ) Bool t r u e )
( d e f i n e −fun C 7 ( ) Bool ( and (> C B F t p l u s o n e 2 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 3 ( ) Bool ( and ( and ( and t r u e C 5 ) C 6 ) C 7 ) )
( d e f i n e −fun C 8 ( ) Bool ( and (< C B F t p l u s o n e 5 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 9 ( ) Bool t r u e )
( d e f i n e −fun C 10 ( ) Bool ( and ( and (= RF ( ∗ C B F t p l u s o n e 0 . 8 ) )
V RF) V CBF t plus one ) )
( d e f i n e −fun C 4 ( ) Bool ( and ( and ( and t r u e C 8 ) C 9 ) C 10 ) )
( d e f i n e −fun C 2 ( ) Bool ( o r ( o r f a l s e C 3 ) C 4 ) )
( d e f i n e −fun C ( ) Bool ( and ( and t r u e C 1 ) C 2 ) )
( d e f i n e −fun A 1 ( ) Bool ( o r ( o r f a l s e B) C) )
( d e f i n e −fun D 2 ( ) Bool t r u e )

266

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

( d e f i n e −fun D 3 ( ) Bool ( and (> BF 0 . 0 ) V BF) )
( d e f i n e −fun D 4 ( ) Bool t r u e )
( d e f i n e −fun D 10 ( ) Bool ( and (= CBF t 0 . 0 ) V CBF t ) )
( d e f i n e −fun D 11 ( ) Bool ( and ( and (= C B F t p l u s o n e BF) V BF)
V CBF t plus one ) )
( d e f i n e −fun D 12a ( ) Bool t r u e )
( d e f i n e −fun D 8 ( ) Bool ( and ( and ( and t r u e D 10 ) D 11 ) D 12a ) )
( d e f i n e −fun D 12b ( ) Bool t r u e )
( d e f i n e −fun D 13 ( ) Bool ( and (= C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun D 14 ( ) Bool ( and (> CBF t 0 . 0 ) V CBF t ) )
( d e f i n e −fun D 9 ( ) Bool ( and ( and ( and t r u e D 12b ) D 13 ) D 14 ) )
( d e f i n e −fun D 5 ( ) Bool ( o r ( o r f a l s e D 8 ) D 9 ) )
( d e f i n e −fun D 6 ( ) Bool ( and (= SS 1 . 0 ) V SS ) )
( d e f i n e −fun D 7 ( ) Bool t r u e )
( d e f i n e −fun D ( ) Bool ( and ( and ( and ( and ( and ( and t r u e D 2 ) D 3 )
D 4) D 5) D 6) D 7) )
( d e f i n e −fun E 2 ( ) Bool t r u e )
( d e f i n e −fun E 3 ( ) Bool ( and ( and (= C B F t p l u s o n e BF) V BF)
V CBF t plus one ) )
( d e f i n e −fun E 4 ( ) Bool t r u e )
( d e f i n e −fun E 5 ( ) Bool ( and (> BF 0 . 0 ) V BF) )
( d e f i n e −fun E 6 ( ) Bool ( and (< SS 1 . 0 ) V SS ) )
( d e f i n e −fun E 7 ( ) Bool t r u e )
( d e f i n e −fun E ( ) Bool ( and ( and ( and ( and ( and ( and t r u e E 2 ) E 3 )
E 4) E 5) E 6) E 7))
( d e f i n e −fun A 2 ( ) Bool ( o r ( o r f a l s e D) E) )
( d e f i n e −fun A ( ) Bool ( and ( and t r u e A 1 ) A 2 ) )
( d e f i n e −fun B P ( ) Bool ( and t r u e B 3 ) )
( d e f i n e −fun C 3 P ( ) Bool ( and t r u e C 7 ) )
( d e f i n e −fun C 4 P ( ) Bool ( and t r u e C 8 ) )
( d e f i n e −fun C 2 P ( ) Bool ( o r ( o r f a l s e C 3 P ) C 4 P ) )
( d e f i n e −fun C P ( ) Bool ( and ( and t r u e C 1 ) C 2 P ) )
( d e f i n e −fun A 1 P ( ) Bool ( o r ( o r f a l s e B P ) C P ) )
( d e f i n e −fun D 8 P ( ) Bool ( and t r u e D 10 ) )
( d e f i n e −fun D 9 P ( ) Bool ( and t r u e D 14 ) )
( d e f i n e −fun D 5 P ( ) Bool ( o r ( o r f a l s e D 8 P ) D 9 P ) )
( d e f i n e −fun D P ( ) Bool ( and ( and ( and t r u e D 3 ) D 5 P ) D 6 ) )
( d e f i n e −fun E P ( ) Bool ( and ( and t r u e E 5 ) E 6 ) )
( d e f i n e −fun A 2 P ( ) Bool ( o r ( o r f a l s e D P ) E P ) )
( d e f i n e −fun A P ( ) Bool ( and ( and t r u e A 1 P ) A 2 P ) )
( d e f i n e −fun B 1 N ( ) Bool ( and ( and ( not (= SF C B F t p l u s o n e ) )
V SF ) V CBF t plus one ) )
( d e f i n e −fun C 5 N ( ) Bool ( and ( and ( not (= SF ( ∗ C B F t p l u s o n e
0 . 2 ) ) ) V SF ) V CBF t plus one ) )
( d e f i n e −fun C 10 N ( ) Bool ( and ( and ( not (= RF ( ∗ C B F t p l u s o n e
0 . 8 ) ) ) V RF) V CBF t plus one ) )

267

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

( d e f i n e −fun
V BF) V
( d e f i n e −fun
V CBF t
( d e f i n e −fun
V BF) V
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
E 3 N)))
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun

D 11 N ( ) Bool ( and ( and ( not (= C B F t p l u s o n e BF) )
CBF t plus one ) )
D 13 N ( ) Bool ( and ( not (= C B F t p l u s o n e 0 . 0 ) )
plus one ) )
E 3 N ( ) Bool ( and ( and ( not (= C B F t p l u s o n e BF) )
CBF t plus one ) )
B PP ( ) Bool ( and ( and t r u e B 3 ) ( o r f a l s e B 1 N ) ) )
C 3 PP ( ) Bool ( and ( and t r u e C 7 ) ( o r f a l s e C 5 N ) ) )
C 4 PP ( ) Bool ( and ( and t r u e C 8 ) ( o r f a l s e C 10 N ) ) )
C 2 PP ( ) Bool ( o r ( o r f a l s e C 3 PP ) C 4 PP ) )
C PP ( ) Bool ( and ( and t r u e C 1 ) C 2 PP ) )
A 1 PP ( ) Bool ( o r ( o r f a l s e B PP ) C PP) )
D 8 PP ( ) Bool ( and ( and t r u e D 10 ) ( o r f a l s e D 11 N ) ) )
D 9 PP ( ) Bool ( and ( and t r u e D 14 ) ( o r f a l s e D 13 N ) ) )
D 5 PP ( ) Bool ( o r ( o r f a l s e D 8 PP ) D 9 PP ) )
D PP ( ) Bool ( and ( and ( and t r u e D 3 ) D 5 PP ) D 6 ) )
E PP ( ) Bool ( and ( and ( and t r u e E 5 ) E 6 ) ( o r f a l s e
A 2 PP ( ) Bool ( o r ( o r f a l s e D PP) E PP ) )
A PP ( ) Bool ( and ( and t r u e A 1 PP ) A 2 PP ) )
A C o n t r i b u t e s ( ) Bool A)
A 1 C o n t r i b u t e s ( ) Bool ( and A 1 A C o n t r i b u t e s ) )
B C o n t r i b u t e s ( ) Bool B)
B 1 C o n t r i b u t e s ( ) Bool ( and B 1 B C o n t r i b u t e s ) )
B 2 C o n t r i b u t e s ( ) Bool ( and B 2 B C o n t r i b u t e s ) )
B 3 C o n t r i b u t e s ( ) Bool ( and B 3 B C o n t r i b u t e s ) )
C C o n t r i b u t e s ( ) Bool C)
C 1 C o n t r i b u t e s ( ) Bool ( and C 1 C C o n t r i b u t e s ) )
C 2 C o n t r i b u t e s ( ) Bool ( and C 2 C C o n t r i b u t e s ) )
C 3 C o n t r i b u t e s ( ) Bool ( and C 3 C 2 C o n t r i b u t e s ) )
C 5 C o n t r i b u t e s ( ) Bool ( and C 5 C 3 C o n t r i b u t e s ) )
C 6 C o n t r i b u t e s ( ) Bool ( and C 6 C 3 C o n t r i b u t e s ) )
C 7 C o n t r i b u t e s ( ) Bool ( and C 7 C 3 C o n t r i b u t e s ) )
C 4 C o n t r i b u t e s ( ) Bool ( and C 4 C 2 C o n t r i b u t e s ) )
C 8 C o n t r i b u t e s ( ) Bool ( and C 8 C 4 C o n t r i b u t e s ) )
C 9 C o n t r i b u t e s ( ) Bool ( and C 9 C 4 C o n t r i b u t e s ) )
C 1 0 C o n t r i b u t e s ( ) Bool ( and C 10 C 4 C o n t r i b u t e s ) )
A 2 C o n t r i b u t e s ( ) Bool ( and A 2 A C o n t r i b u t e s ) )
D C o n t r i b u t e s ( ) Bool D)
D 2 C o n t r i b u t e s ( ) Bool ( and D 2 D C o n t r i b u t e s ) )
D 3 C o n t r i b u t e s ( ) Bool ( and D 3 D C o n t r i b u t e s ) )
D 4 C o n t r i b u t e s ( ) Bool ( and D 4 D C o n t r i b u t e s ) )
D 5 C o n t r i b u t e s ( ) Bool ( and D 5 D C o n t r i b u t e s ) )
D 8 C o n t r i b u t e s ( ) Bool ( and D 8 D 5 C o n t r i b u t e s ) )
D 1 0 C o n t r i b u t e s ( ) Bool ( and D 10 D 8 C o n t r i b u t e s ) )
D 1 1 C o n t r i b u t e s ( ) Bool ( and D 11 D 8 C o n t r i b u t e s ) )
D 1 2 a C o n t r i b u t e s ( ) Bool ( and D 12a D 8 C o n t r i b u t e s ) )

268

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

( d e f i n e −fun D 9 C o n t r i b u t e s ( ) Bool ( and D 9 D 5 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 2 b C o n t r i b u t e s ( ) Bool ( and D 12b D 9 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 3 C o n t r i b u t e s ( ) Bool ( and D 13 D 9 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 4 C o n t r i b u t e s ( ) Bool ( and D 14 D 9 C o n t r i b u t e s ) )
( d e f i n e −fun D 6 C o n t r i b u t e s ( ) Bool ( and D 6 D C o n t r i b u t e s ) )
( d e f i n e −fun D 7 C o n t r i b u t e s ( ) Bool ( and D 7 D C o n t r i b u t e s ) )
( d e f i n e −fun E C o n t r i b u t e s ( ) Bool E)
( d e f i n e −fun E 2 C o n t r i b u t e s ( ) Bool ( and E 2 E C o n t r i b u t e s ) )
( d e f i n e −fun E 3 C o n t r i b u t e s ( ) Bool ( and E 3 E C o n t r i b u t e s ) )
( d e f i n e −fun E 4 C o n t r i b u t e s ( ) Bool ( and E 4 E C o n t r i b u t e s ) )
( d e f i n e −fun E 5 C o n t r i b u t e s ( ) Bool ( and E 5 E C o n t r i b u t e s ) )
( d e f i n e −fun E 6 C o n t r i b u t e s ( ) Bool ( and E 6 E C o n t r i b u t e s ) )
( d e f i n e −fun E 7 C o n t r i b u t e s ( ) Bool ( and E 7 E C o n t r i b u t e s ) )
( a s s e r t ( i t e B 1 C o n t r i b u t e s (= SF B 1 t r u e ) (= SF B 1 f a l s e ) ) )
( a s s e r t ( i t e B 3 C o n t r i b u t e s (= C B F t p l u s o n e B 3 t r u e ) (=
CBF t plus one B 3 f a l s e ) ) )
( a s s e r t ( i t e C 1 C o n t r i b u t e s (= C B F t p l u s o n e C 1 t r u e ) (=
CBF t plus one C 1 f a l s e ) ) )
( a s s e r t ( i t e C 5 C o n t r i b u t e s (= SF C 5 t r u e ) (= SF C 5 f a l s e ) ) )
( a s s e r t ( i t e C 7 C o n t r i b u t e s (= C B F t p l u s o n e C 7 t r u e ) (=
CBF t plus one C 7 f a l s e ) ) )
( a s s e r t ( i t e C 8 C o n t r i b u t e s (= C B F t p l u s o n e C 8 t r u e ) (=
CBF t plus one C 8 f a l s e ) ) )
( a s s e r t ( i t e C 1 0 C o n t r i b u t e s (= RF C 10 t r u e ) (= RF C 10 f a l s e ) ) )
( a s s e r t ( i t e D 3 C o n t r i b u t e s (= BF D 3 t r u e ) (= BF D 3 f a l s e ) ) )
( a s s e r t ( i t e D 1 0 C o n t r i b u t e s (= CBF t D 10 t r u e ) (= CBF t D 10
false )))
( a s s e r t ( i t e D 1 1 C o n t r i b u t e s (= C B F t p l u s o n e D 1 1 t r u e ) (=
CBF t plus one D 11 f a l s e ) ) )
( a s s e r t ( i t e D 1 3 C o n t r i b u t e s (= C B F t p l u s o n e D 1 3 t r u e ) (=
CBF t plus one D 13 f a l s e ) ) )
( a s s e r t ( i t e D 1 4 C o n t r i b u t e s (= CBF t D 14 t r u e ) (= CBF t D 14
false )))
( a s s e r t ( i t e D 6 C o n t r i b u t e s (= SS D 6 t r u e ) (= SS D 6 f a l s e ) ) )
( a s s e r t ( i t e E 3 C o n t r i b u t e s (= C B F t p l u s o n e E 3 t r u e ) (=
CBF t plus one E 3 f a l s e ) ) )
( a s s e r t ( i t e E 5 C o n t r i b u t e s (= BF E 5 t r u e ) (= BF E 5 f a l s e ) ) )
( a s s e r t ( i t e E 6 C o n t r i b u t e s (= SS E 6 t r u e ) (= SS E 6 f a l s e ) ) )
( a s s e r t ( and ( o r B s C s ) ( o r D s E s ) ) )
( a s s e r t ( i t e C s ( o r C C P ) ( not C) ) )
( a s s e r t ( i t e D s ( o r D D P ) ( not D) ) )
( a s s e r t ( i t e E s ( o r E E P ) ( not E) ) )
( a s s e r t ( i t e B s B PP f a l s e ) )

269

B.2.2

Detection Constraints for Failure of Feature C
Listing B.5: Feature Interaction for Failure of Feature C

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

( s e t −o p t i o n : p r i n t −s u c c e s s t r u e )
( d e f i n e −fun min2 ( ( x1 Real ) ( x2 Real ) ) Real ( / (− (+ x1 x2 ) ( abs (−
x1 x2 ) ) ) 2 ) )
( d e f i n e −fun max2 ( ( x1 Real ) ( x2 Real ) ) Real ( / (+ x1 x2 ( abs (− x1
x2 ) ) ) 2 ) )
( d e c l a r e −c o n s t BF Real )
( d e c l a r e −c o n s t C B F t p l u s o n e D 1 1 Bool )
( d e c l a r e −c o n s t RF C 10 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e D 1 3 Bool )
( d e c l a r e −c o n s t CBF t D 14 Bool )
( d e c l a r e −c o n s t SF Real )
( d e c l a r e −c o n s t C B F t p l u s o n e Real )
( d e c l a r e −c o n s t BF D 3 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 8 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 7 Bool )
( d e c l a r e −c o n s t SS Real )
( d e c l a r e −c o n s t SF B 1 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e E 3 Bool )
( d e c l a r e −c o n s t SF C 5 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e B 3 Bool )
( d e c l a r e −c o n s t BF E 5 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 1 Bool )
( d e c l a r e −c o n s t CBF t D 10 Bool )
( d e c l a r e −c o n s t CBF t Real )
( d e c l a r e −c o n s t RF Real )
( d e c l a r e −c o n s t C s Bool )
( d e c l a r e −c o n s t B s Bool )
( d e c l a r e −c o n s t E s Bool )
( d e c l a r e −c o n s t D s Bool )
( d e c l a r e −c o n s t SS D 6 Bool )
( d e c l a r e −c o n s t SS E 6 Bool )
( d e f i n e −fun V SS ( ) Bool ( o r ( o r f a l s e SS D 6 ) SS E 6 ) )
( d e f i n e −fun V SF ( ) Bool ( o r ( o r f a l s e SF B 1 ) SF C 5 ) )
( d e f i n e −fun V CBF t ( ) Bool ( o r ( o r f a l s e CBF t D 10 ) CBF t D 14 ) )
( d e f i n e −fun V RF ( ) Bool ( o r f a l s e RF C 10 ) )
( d e f i n e −fun V BF ( ) Bool ( o r ( o r f a l s e BF D 3 ) BF E 5 ) )
( d e f i n e −fun V CBF t plus one ( ) Bool ( o r ( o r ( o r ( o r ( o r ( o r ( o r
f a l s e CBF t plus one B 3 ) CBF t plus one C 1 ) CBF t plus one C 7
) CBF t plus one C 8 ) CBF t plus one D 11 ) CBF t plus one D 13 )
CBF t plus one E 3 ) )
( d e f i n e −fun B 1 ( ) Bool ( and ( and (= SF C B F t p l u s o n e ) V SF )
V CBF t plus one ) )
( d e f i n e −fun B 2 ( ) Bool t r u e )

270

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

( d e f i n e −fun B 3 ( ) Bool ( and (> C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun B ( ) Bool ( and ( and ( and t r u e B 1 ) B 2 ) B 3 ) )
( d e f i n e −fun C 1 ( ) Bool ( and (> C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 5 ( ) Bool ( and ( and (= SF ( ∗ C B F t p l u s o n e 0 . 2 ) )
V SF ) V CBF t plus one ) )
( d e f i n e −fun C 6 ( ) Bool t r u e )
( d e f i n e −fun C 7 ( ) Bool ( and (> C B F t p l u s o n e 2 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 3 ( ) Bool ( and ( and ( and t r u e C 5 ) C 6 ) C 7 ) )
( d e f i n e −fun C 8 ( ) Bool ( and (< C B F t p l u s o n e 5 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 9 ( ) Bool t r u e )
( d e f i n e −fun C 10 ( ) Bool ( and ( and (= RF ( ∗ C B F t p l u s o n e 0 . 8 ) )
V RF) V CBF t plus one ) )
( d e f i n e −fun C 4 ( ) Bool ( and ( and ( and t r u e C 8 ) C 9 ) C 10 ) )
( d e f i n e −fun C 2 ( ) Bool ( o r ( o r f a l s e C 3 ) C 4 ) )
( d e f i n e −fun C ( ) Bool ( and ( and t r u e C 1 ) C 2 ) )
( d e f i n e −fun A 1 ( ) Bool ( o r ( o r f a l s e B) C) )
( d e f i n e −fun D 2 ( ) Bool t r u e )
( d e f i n e −fun D 3 ( ) Bool ( and (> BF 0 . 0 ) V BF) )
( d e f i n e −fun D 4 ( ) Bool t r u e )
( d e f i n e −fun D 10 ( ) Bool ( and (= CBF t 0 . 0 ) V CBF t ) )
( d e f i n e −fun D 11 ( ) Bool ( and ( and (= C B F t p l u s o n e BF) V BF)
V CBF t plus one ) )
( d e f i n e −fun D 12a ( ) Bool t r u e )
( d e f i n e −fun D 8 ( ) Bool ( and ( and ( and t r u e D 10 ) D 11 ) D 12a ) )
( d e f i n e −fun D 12b ( ) Bool t r u e )
( d e f i n e −fun D 13 ( ) Bool ( and (= C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun D 14 ( ) Bool ( and (> CBF t 0 . 0 ) V CBF t ) )
( d e f i n e −fun D 9 ( ) Bool ( and ( and ( and t r u e D 12b ) D 13 ) D 14 ) )
( d e f i n e −fun D 5 ( ) Bool ( o r ( o r f a l s e D 8 ) D 9 ) )
( d e f i n e −fun D 6 ( ) Bool ( and (= SS 1 . 0 ) V SS ) )
( d e f i n e −fun D 7 ( ) Bool t r u e )
( d e f i n e −fun D ( ) Bool ( and ( and ( and ( and ( and ( and t r u e D 2 ) D 3 )
D 4) D 5) D 6) D 7) )
( d e f i n e −fun E 2 ( ) Bool t r u e )
( d e f i n e −fun E 3 ( ) Bool ( and ( and (= C B F t p l u s o n e BF) V BF)
V CBF t plus one ) )
( d e f i n e −fun E 4 ( ) Bool t r u e )
( d e f i n e −fun E 5 ( ) Bool ( and (> BF 0 . 0 ) V BF) )
( d e f i n e −fun E 6 ( ) Bool ( and (< SS 1 . 0 ) V SS ) )
( d e f i n e −fun E 7 ( ) Bool t r u e )
( d e f i n e −fun E ( ) Bool ( and ( and ( and ( and ( and ( and t r u e E 2 ) E 3 )
E 4) E 5) E 6) E 7))

271

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

( d e f i n e −fun A 2 ( ) Bool ( o r ( o r f a l s e D) E) )
( d e f i n e −fun A ( ) Bool ( and ( and t r u e A 1 ) A 2 ) )
( d e f i n e −fun B P ( ) Bool ( and t r u e B 3 ) )
( d e f i n e −fun C 3 P ( ) Bool ( and t r u e C 7 ) )
( d e f i n e −fun C 4 P ( ) Bool ( and t r u e C 8 ) )
( d e f i n e −fun C 2 P ( ) Bool ( o r ( o r f a l s e C 3 P ) C 4 P ) )
( d e f i n e −fun C P ( ) Bool ( and ( and t r u e C 1 ) C 2 P ) )
( d e f i n e −fun A 1 P ( ) Bool ( o r ( o r f a l s e B P ) C P ) )
( d e f i n e −fun D 8 P ( ) Bool ( and t r u e D 10 ) )
( d e f i n e −fun D 9 P ( ) Bool ( and t r u e D 14 ) )
( d e f i n e −fun D 5 P ( ) Bool ( o r ( o r f a l s e D 8 P ) D 9 P ) )
( d e f i n e −fun D P ( ) Bool ( and ( and ( and t r u e D 3 ) D 5 P ) D 6 ) )
( d e f i n e −fun E P ( ) Bool ( and ( and t r u e E 5 ) E 6 ) )
( d e f i n e −fun A 2 P ( ) Bool ( o r ( o r f a l s e D P ) E P ) )
( d e f i n e −fun A P ( ) Bool ( and ( and t r u e A 1 P ) A 2 P ) )
( d e f i n e −fun B 1 N ( ) Bool ( and ( and ( not (= SF C B F t p l u s o n e ) )
V SF ) V CBF t plus one ) )
( d e f i n e −fun C 5 N ( ) Bool ( and ( and ( not (= SF ( ∗ C B F t p l u s o n e
0 . 2 ) ) ) V SF ) V CBF t plus one ) )
( d e f i n e −fun C 10 N ( ) Bool ( and ( and ( not (= RF ( ∗ C B F t p l u s o n e
0 . 8 ) ) ) V RF) V CBF t plus one ) )
( d e f i n e −fun D 11 N ( ) Bool ( and ( and ( not (= C B F t p l u s o n e BF) )
V BF) V CBF t plus one ) )
( d e f i n e −fun D 13 N ( ) Bool ( and ( not (= C B F t p l u s o n e 0 . 0 ) )
V CBF t plus one ) )
( d e f i n e −fun E 3 N ( ) Bool ( and ( and ( not (= C B F t p l u s o n e BF) )
V BF) V CBF t plus one ) )
( d e f i n e −fun B PP ( ) Bool ( and ( and t r u e B 3 ) ( o r f a l s e B 1 N ) ) )
( d e f i n e −fun C 3 PP ( ) Bool ( and ( and t r u e C 7 ) ( o r f a l s e C 5 N ) ) )
( d e f i n e −fun C 4 PP ( ) Bool ( and ( and t r u e C 8 ) ( o r f a l s e C 10 N ) ) )
( d e f i n e −fun C 2 PP ( ) Bool ( o r ( o r f a l s e C 3 PP ) C 4 PP ) )
( d e f i n e −fun C PP ( ) Bool ( and ( and t r u e C 1 ) C 2 PP ) )
( d e f i n e −fun A 1 PP ( ) Bool ( o r ( o r f a l s e B PP ) C PP) )
( d e f i n e −fun D 8 PP ( ) Bool ( and ( and t r u e D 10 ) ( o r f a l s e D 11 N ) ) )
( d e f i n e −fun D 9 PP ( ) Bool ( and ( and t r u e D 14 ) ( o r f a l s e D 13 N ) ) )
( d e f i n e −fun D 5 PP ( ) Bool ( o r ( o r f a l s e D 8 PP ) D 9 PP ) )
( d e f i n e −fun D PP ( ) Bool ( and ( and ( and t r u e D 3 ) D 5 PP ) D 6 ) )
( d e f i n e −fun E PP ( ) Bool ( and ( and ( and t r u e E 5 ) E 6 ) ( o r f a l s e
E 3 N)))
( d e f i n e −fun A 2 PP ( ) Bool ( o r ( o r f a l s e D PP) E PP ) )
( d e f i n e −fun A PP ( ) Bool ( and ( and t r u e A 1 PP ) A 2 PP ) )
( d e f i n e −fun A C o n t r i b u t e s ( ) Bool A)
( d e f i n e −fun A 1 C o n t r i b u t e s ( ) Bool ( and A 1 A C o n t r i b u t e s ) )
( d e f i n e −fun B C o n t r i b u t e s ( ) Bool B)
( d e f i n e −fun B 1 C o n t r i b u t e s ( ) Bool ( and B 1 B C o n t r i b u t e s ) )
( d e f i n e −fun B 2 C o n t r i b u t e s ( ) Bool ( and B 2 B C o n t r i b u t e s ) )
( d e f i n e −fun B 3 C o n t r i b u t e s ( ) Bool ( and B 3 B C o n t r i b u t e s ) )

272

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

( d e f i n e −fun C C o n t r i b u t e s ( ) Bool C)
( d e f i n e −fun C 1 C o n t r i b u t e s ( ) Bool ( and C 1 C C o n t r i b u t e s ) )
( d e f i n e −fun C 2 C o n t r i b u t e s ( ) Bool ( and C 2 C C o n t r i b u t e s ) )
( d e f i n e −fun C 3 C o n t r i b u t e s ( ) Bool ( and C 3 C 2 C o n t r i b u t e s ) )
( d e f i n e −fun C 5 C o n t r i b u t e s ( ) Bool ( and C 5 C 3 C o n t r i b u t e s ) )
( d e f i n e −fun C 6 C o n t r i b u t e s ( ) Bool ( and C 6 C 3 C o n t r i b u t e s ) )
( d e f i n e −fun C 7 C o n t r i b u t e s ( ) Bool ( and C 7 C 3 C o n t r i b u t e s ) )
( d e f i n e −fun C 4 C o n t r i b u t e s ( ) Bool ( and C 4 C 2 C o n t r i b u t e s ) )
( d e f i n e −fun C 8 C o n t r i b u t e s ( ) Bool ( and C 8 C 4 C o n t r i b u t e s ) )
( d e f i n e −fun C 9 C o n t r i b u t e s ( ) Bool ( and C 9 C 4 C o n t r i b u t e s ) )
( d e f i n e −fun C 1 0 C o n t r i b u t e s ( ) Bool ( and C 10 C 4 C o n t r i b u t e s ) )
( d e f i n e −fun A 2 C o n t r i b u t e s ( ) Bool ( and A 2 A C o n t r i b u t e s ) )
( d e f i n e −fun D C o n t r i b u t e s ( ) Bool D)
( d e f i n e −fun D 2 C o n t r i b u t e s ( ) Bool ( and D 2 D C o n t r i b u t e s ) )
( d e f i n e −fun D 3 C o n t r i b u t e s ( ) Bool ( and D 3 D C o n t r i b u t e s ) )
( d e f i n e −fun D 4 C o n t r i b u t e s ( ) Bool ( and D 4 D C o n t r i b u t e s ) )
( d e f i n e −fun D 5 C o n t r i b u t e s ( ) Bool ( and D 5 D C o n t r i b u t e s ) )
( d e f i n e −fun D 8 C o n t r i b u t e s ( ) Bool ( and D 8 D 5 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 0 C o n t r i b u t e s ( ) Bool ( and D 10 D 8 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 1 C o n t r i b u t e s ( ) Bool ( and D 11 D 8 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 2 a C o n t r i b u t e s ( ) Bool ( and D 12a D 8 C o n t r i b u t e s ) )
( d e f i n e −fun D 9 C o n t r i b u t e s ( ) Bool ( and D 9 D 5 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 2 b C o n t r i b u t e s ( ) Bool ( and D 12b D 9 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 3 C o n t r i b u t e s ( ) Bool ( and D 13 D 9 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 4 C o n t r i b u t e s ( ) Bool ( and D 14 D 9 C o n t r i b u t e s ) )
( d e f i n e −fun D 6 C o n t r i b u t e s ( ) Bool ( and D 6 D C o n t r i b u t e s ) )
( d e f i n e −fun D 7 C o n t r i b u t e s ( ) Bool ( and D 7 D C o n t r i b u t e s ) )
( d e f i n e −fun E C o n t r i b u t e s ( ) Bool E)
( d e f i n e −fun E 2 C o n t r i b u t e s ( ) Bool ( and E 2 E C o n t r i b u t e s ) )
( d e f i n e −fun E 3 C o n t r i b u t e s ( ) Bool ( and E 3 E C o n t r i b u t e s ) )
( d e f i n e −fun E 4 C o n t r i b u t e s ( ) Bool ( and E 4 E C o n t r i b u t e s ) )
( d e f i n e −fun E 5 C o n t r i b u t e s ( ) Bool ( and E 5 E C o n t r i b u t e s ) )
( d e f i n e −fun E 6 C o n t r i b u t e s ( ) Bool ( and E 6 E C o n t r i b u t e s ) )
( d e f i n e −fun E 7 C o n t r i b u t e s ( ) Bool ( and E 7 E C o n t r i b u t e s ) )
( a s s e r t ( i t e B 1 C o n t r i b u t e s (= SF B 1 t r u e ) (= SF B 1 f a l s e ) ) )
( a s s e r t ( i t e B 3 C o n t r i b u t e s (= C B F t p l u s o n e B 3 t r u e ) (=
CBF t plus one B 3 f a l s e ) ) )
( a s s e r t ( i t e C 1 C o n t r i b u t e s (= C B F t p l u s o n e C 1 t r u e ) (=
CBF t plus one C 1 f a l s e ) ) )
( a s s e r t ( i t e C 5 C o n t r i b u t e s (= SF C 5 t r u e ) (= SF C 5 f a l s e ) ) )
( a s s e r t ( i t e C 7 C o n t r i b u t e s (= C B F t p l u s o n e C 7 t r u e ) (=
CBF t plus one C 7 f a l s e ) ) )
( a s s e r t ( i t e C 8 C o n t r i b u t e s (= C B F t p l u s o n e C 8 t r u e ) (=
CBF t plus one C 8 f a l s e ) ) )
( a s s e r t ( i t e C 1 0 C o n t r i b u t e s (= RF C 10 t r u e ) (= RF C 10 f a l s e ) ) )
( a s s e r t ( i t e D 3 C o n t r i b u t e s (= BF D 3 t r u e ) (= BF D 3 f a l s e ) ) )

273

156
157
158
159
160
161
162
163
164
165
166
167
168

( a s s e r t ( i t e D 1 0 C o n t r i b u t e s (= CBF t D 10 t r u e ) (= CBF t D 10
false )))
( a s s e r t ( i t e D 1 1 C o n t r i b u t e s (= C B F t p l u s o n e D 1 1 t r u e ) (=
CBF t plus one D 11 f a l s e ) ) )
( a s s e r t ( i t e D 1 3 C o n t r i b u t e s (= C B F t p l u s o n e D 1 3 t r u e ) (=
CBF t plus one D 13 f a l s e ) ) )
( a s s e r t ( i t e D 1 4 C o n t r i b u t e s (= CBF t D 14 t r u e ) (= CBF t D 14
false )))
( a s s e r t ( i t e D 6 C o n t r i b u t e s (= SS D 6 t r u e ) (= SS D 6 f a l s e ) ) )
( a s s e r t ( i t e E 3 C o n t r i b u t e s (= C B F t p l u s o n e E 3 t r u e ) (=
CBF t plus one E 3 f a l s e ) ) )
( a s s e r t ( i t e E 5 C o n t r i b u t e s (= BF E 5 t r u e ) (= BF E 5 f a l s e ) ) )
( a s s e r t ( i t e E 6 C o n t r i b u t e s (= SS E 6 t r u e ) (= SS E 6 f a l s e ) ) )
( a s s e r t ( and ( o r B s C s ) ( o r D s E s ) ) )
( a s s e r t ( i t e B s ( o r B B P ) ( not B) ) )
( a s s e r t ( i t e D s ( o r D D P ) ( not D) ) )
( a s s e r t ( i t e E s ( o r E E P ) ( not E) ) )
( a s s e r t ( i t e C s C PP f a l s e ) )

B.2.3

Detection Constraints for Failure of Feature D
Listing B.6: Feature Interaction for Failure of Feature D

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

( s e t −o p t i o n : p r i n t −s u c c e s s t r u e )
( d e f i n e −fun min2 ( ( x1 Real ) ( x2 Real ) ) Real ( / (− (+ x1 x2 ) ( abs (−
x1 x2 ) ) ) 2 ) )
( d e f i n e −fun max2 ( ( x1 Real ) ( x2 Real ) ) Real ( / (+ x1 x2 ( abs (− x1
x2 ) ) ) 2 ) )
( d e c l a r e −c o n s t BF Real )
( d e c l a r e −c o n s t C B F t p l u s o n e D 1 1 Bool )
( d e c l a r e −c o n s t RF C 10 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e D 1 3 Bool )
( d e c l a r e −c o n s t CBF t D 14 Bool )
( d e c l a r e −c o n s t SF Real )
( d e c l a r e −c o n s t C B F t p l u s o n e Real )
( d e c l a r e −c o n s t BF D 3 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 8 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 7 Bool )
( d e c l a r e −c o n s t SS Real )
( d e c l a r e −c o n s t SF B 1 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e E 3 Bool )
( d e c l a r e −c o n s t SF C 5 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e B 3 Bool )
( d e c l a r e −c o n s t BF E 5 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 1 Bool )
( d e c l a r e −c o n s t CBF t D 10 Bool )
( d e c l a r e −c o n s t CBF t Real )

274

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

( d e c l a r e −c o n s t RF Real )
( d e c l a r e −c o n s t C s Bool )
( d e c l a r e −c o n s t B s Bool )
( d e c l a r e −c o n s t E s Bool )
( d e c l a r e −c o n s t D s Bool )
( d e c l a r e −c o n s t SS D 6 Bool )
( d e c l a r e −c o n s t SS E 6 Bool )
( d e f i n e −fun V SS ( ) Bool ( o r ( o r f a l s e SS D 6 ) SS E 6 ) )
( d e f i n e −fun V SF ( ) Bool ( o r ( o r f a l s e SF B 1 ) SF C 5 ) )
( d e f i n e −fun V CBF t ( ) Bool ( o r ( o r f a l s e CBF t D 10 ) CBF t D 14 ) )
( d e f i n e −fun V RF ( ) Bool ( o r f a l s e RF C 10 ) )
( d e f i n e −fun V BF ( ) Bool ( o r ( o r f a l s e BF D 3 ) BF E 5 ) )
( d e f i n e −fun V CBF t plus one ( ) Bool ( o r ( o r ( o r ( o r ( o r ( o r ( o r
f a l s e CBF t plus one B 3 ) CBF t plus one C 1 ) CBF t plus one C 7
) CBF t plus one C 8 ) CBF t plus one D 11 ) CBF t plus one D 13 )
CBF t plus one E 3 ) )
( d e f i n e −fun B 1 ( ) Bool ( and ( and (= SF C B F t p l u s o n e ) V SF )
V CBF t plus one ) )
( d e f i n e −fun B 2 ( ) Bool t r u e )
( d e f i n e −fun B 3 ( ) Bool ( and (> C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun B ( ) Bool ( and ( and ( and t r u e B 1 ) B 2 ) B 3 ) )
( d e f i n e −fun C 1 ( ) Bool ( and (> C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 5 ( ) Bool ( and ( and (= SF ( ∗ C B F t p l u s o n e 0 . 2 ) )
V SF ) V CBF t plus one ) )
( d e f i n e −fun C 6 ( ) Bool t r u e )
( d e f i n e −fun C 7 ( ) Bool ( and (> C B F t p l u s o n e 2 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 3 ( ) Bool ( and ( and ( and t r u e C 5 ) C 6 ) C 7 ) )
( d e f i n e −fun C 8 ( ) Bool ( and (< C B F t p l u s o n e 5 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 9 ( ) Bool t r u e )
( d e f i n e −fun C 10 ( ) Bool ( and ( and (= RF ( ∗ C B F t p l u s o n e 0 . 8 ) )
V RF) V CBF t plus one ) )
( d e f i n e −fun C 4 ( ) Bool ( and ( and ( and t r u e C 8 ) C 9 ) C 10 ) )
( d e f i n e −fun C 2 ( ) Bool ( o r ( o r f a l s e C 3 ) C 4 ) )
( d e f i n e −fun C ( ) Bool ( and ( and t r u e C 1 ) C 2 ) )
( d e f i n e −fun A 1 ( ) Bool ( o r ( o r f a l s e B) C) )
( d e f i n e −fun D 2 ( ) Bool t r u e )
( d e f i n e −fun D 3 ( ) Bool ( and (> BF 0 . 0 ) V BF) )
( d e f i n e −fun D 4 ( ) Bool t r u e )
( d e f i n e −fun D 10 ( ) Bool ( and (= CBF t 0 . 0 ) V CBF t ) )
( d e f i n e −fun D 11 ( ) Bool ( and ( and (= C B F t p l u s o n e BF) V BF)
V CBF t plus one ) )
( d e f i n e −fun D 12a ( ) Bool t r u e )
( d e f i n e −fun D 8 ( ) Bool ( and ( and ( and t r u e D 10 ) D 11 ) D 12a ) )

275

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

( d e f i n e −fun D 12b ( ) Bool t r u e )
( d e f i n e −fun D 13 ( ) Bool ( and (= C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun D 14 ( ) Bool ( and (> CBF t 0 . 0 ) V CBF t ) )
( d e f i n e −fun D 9 ( ) Bool ( and ( and ( and t r u e D 12b ) D 13 ) D 14 ) )
( d e f i n e −fun D 5 ( ) Bool ( o r ( o r f a l s e D 8 ) D 9 ) )
( d e f i n e −fun D 6 ( ) Bool ( and (= SS 1 . 0 ) V SS ) )
( d e f i n e −fun D 7 ( ) Bool t r u e )
( d e f i n e −fun D ( ) Bool ( and ( and ( and ( and ( and ( and t r u e D 2 ) D 3 )
D 4) D 5) D 6) D 7) )
( d e f i n e −fun E 2 ( ) Bool t r u e )
( d e f i n e −fun E 3 ( ) Bool ( and ( and (= C B F t p l u s o n e BF) V BF)
V CBF t plus one ) )
( d e f i n e −fun E 4 ( ) Bool t r u e )
( d e f i n e −fun E 5 ( ) Bool ( and (> BF 0 . 0 ) V BF) )
( d e f i n e −fun E 6 ( ) Bool ( and (< SS 1 . 0 ) V SS ) )
( d e f i n e −fun E 7 ( ) Bool t r u e )
( d e f i n e −fun E ( ) Bool ( and ( and ( and ( and ( and ( and t r u e E 2 ) E 3 )
E 4) E 5) E 6) E 7))
( d e f i n e −fun A 2 ( ) Bool ( o r ( o r f a l s e D) E) )
( d e f i n e −fun A ( ) Bool ( and ( and t r u e A 1 ) A 2 ) )
( d e f i n e −fun B P ( ) Bool ( and t r u e B 3 ) )
( d e f i n e −fun C 3 P ( ) Bool ( and t r u e C 7 ) )
( d e f i n e −fun C 4 P ( ) Bool ( and t r u e C 8 ) )
( d e f i n e −fun C 2 P ( ) Bool ( o r ( o r f a l s e C 3 P ) C 4 P ) )
( d e f i n e −fun C P ( ) Bool ( and ( and t r u e C 1 ) C 2 P ) )
( d e f i n e −fun A 1 P ( ) Bool ( o r ( o r f a l s e B P ) C P ) )
( d e f i n e −fun D 8 P ( ) Bool ( and t r u e D 10 ) )
( d e f i n e −fun D 9 P ( ) Bool ( and t r u e D 14 ) )
( d e f i n e −fun D 5 P ( ) Bool ( o r ( o r f a l s e D 8 P ) D 9 P ) )
( d e f i n e −fun D P ( ) Bool ( and ( and ( and t r u e D 3 ) D 5 P ) D 6 ) )
( d e f i n e −fun E P ( ) Bool ( and ( and t r u e E 5 ) E 6 ) )
( d e f i n e −fun A 2 P ( ) Bool ( o r ( o r f a l s e D P ) E P ) )
( d e f i n e −fun A P ( ) Bool ( and ( and t r u e A 1 P ) A 2 P ) )
( d e f i n e −fun B 1 N ( ) Bool ( and ( and ( not (= SF C B F t p l u s o n e ) )
V SF ) V CBF t plus one ) )
( d e f i n e −fun C 5 N ( ) Bool ( and ( and ( not (= SF ( ∗ C B F t p l u s o n e
0 . 2 ) ) ) V SF ) V CBF t plus one ) )
( d e f i n e −fun C 10 N ( ) Bool ( and ( and ( not (= RF ( ∗ C B F t p l u s o n e
0 . 8 ) ) ) V RF) V CBF t plus one ) )
( d e f i n e −fun D 11 N ( ) Bool ( and ( and ( not (= C B F t p l u s o n e BF) )
V BF) V CBF t plus one ) )
( d e f i n e −fun D 13 N ( ) Bool ( and ( not (= C B F t p l u s o n e 0 . 0 ) )
V CBF t plus one ) )
( d e f i n e −fun E 3 N ( ) Bool ( and ( and ( not (= C B F t p l u s o n e BF) )
V BF) V CBF t plus one ) )
( d e f i n e −fun B PP ( ) Bool ( and ( and t r u e B 3 ) ( o r f a l s e B 1 N ) ) )

276

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

( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
E 3 N)))
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun
( d e f i n e −fun

C 3 PP ( ) Bool ( and ( and t r u e C 7 ) ( o r f a l s e C 5 N ) ) )
C 4 PP ( ) Bool ( and ( and t r u e C 8 ) ( o r f a l s e C 10 N ) ) )
C 2 PP ( ) Bool ( o r ( o r f a l s e C 3 PP ) C 4 PP ) )
C PP ( ) Bool ( and ( and t r u e C 1 ) C 2 PP ) )
A 1 PP ( ) Bool ( o r ( o r f a l s e B PP ) C PP) )
D 8 PP ( ) Bool ( and ( and t r u e D 10 ) ( o r f a l s e D 11 N ) ) )
D 9 PP ( ) Bool ( and ( and t r u e D 14 ) ( o r f a l s e D 13 N ) ) )
D 5 PP ( ) Bool ( o r ( o r f a l s e D 8 PP ) D 9 PP ) )
D PP ( ) Bool ( and ( and ( and t r u e D 3 ) D 5 PP ) D 6 ) )
E PP ( ) Bool ( and ( and ( and t r u e E 5 ) E 6 ) ( o r f a l s e
A 2 PP ( ) Bool ( o r ( o r f a l s e D PP) E PP ) )
A PP ( ) Bool ( and ( and t r u e A 1 PP ) A 2 PP ) )
A C o n t r i b u t e s ( ) Bool A)
A 1 C o n t r i b u t e s ( ) Bool ( and A 1 A C o n t r i b u t e s ) )
B C o n t r i b u t e s ( ) Bool B)
B 1 C o n t r i b u t e s ( ) Bool ( and B 1 B C o n t r i b u t e s ) )
B 2 C o n t r i b u t e s ( ) Bool ( and B 2 B C o n t r i b u t e s ) )
B 3 C o n t r i b u t e s ( ) Bool ( and B 3 B C o n t r i b u t e s ) )
C C o n t r i b u t e s ( ) Bool C)
C 1 C o n t r i b u t e s ( ) Bool ( and C 1 C C o n t r i b u t e s ) )
C 2 C o n t r i b u t e s ( ) Bool ( and C 2 C C o n t r i b u t e s ) )
C 3 C o n t r i b u t e s ( ) Bool ( and C 3 C 2 C o n t r i b u t e s ) )
C 5 C o n t r i b u t e s ( ) Bool ( and C 5 C 3 C o n t r i b u t e s ) )
C 6 C o n t r i b u t e s ( ) Bool ( and C 6 C 3 C o n t r i b u t e s ) )
C 7 C o n t r i b u t e s ( ) Bool ( and C 7 C 3 C o n t r i b u t e s ) )
C 4 C o n t r i b u t e s ( ) Bool ( and C 4 C 2 C o n t r i b u t e s ) )
C 8 C o n t r i b u t e s ( ) Bool ( and C 8 C 4 C o n t r i b u t e s ) )
C 9 C o n t r i b u t e s ( ) Bool ( and C 9 C 4 C o n t r i b u t e s ) )
C 1 0 C o n t r i b u t e s ( ) Bool ( and C 10 C 4 C o n t r i b u t e s ) )
A 2 C o n t r i b u t e s ( ) Bool ( and A 2 A C o n t r i b u t e s ) )
D C o n t r i b u t e s ( ) Bool D)
D 2 C o n t r i b u t e s ( ) Bool ( and D 2 D C o n t r i b u t e s ) )
D 3 C o n t r i b u t e s ( ) Bool ( and D 3 D C o n t r i b u t e s ) )
D 4 C o n t r i b u t e s ( ) Bool ( and D 4 D C o n t r i b u t e s ) )
D 5 C o n t r i b u t e s ( ) Bool ( and D 5 D C o n t r i b u t e s ) )
D 8 C o n t r i b u t e s ( ) Bool ( and D 8 D 5 C o n t r i b u t e s ) )
D 1 0 C o n t r i b u t e s ( ) Bool ( and D 10 D 8 C o n t r i b u t e s ) )
D 1 1 C o n t r i b u t e s ( ) Bool ( and D 11 D 8 C o n t r i b u t e s ) )
D 1 2 a C o n t r i b u t e s ( ) Bool ( and D 12a D 8 C o n t r i b u t e s ) )
D 9 C o n t r i b u t e s ( ) Bool ( and D 9 D 5 C o n t r i b u t e s ) )
D 1 2 b C o n t r i b u t e s ( ) Bool ( and D 12b D 9 C o n t r i b u t e s ) )
D 1 3 C o n t r i b u t e s ( ) Bool ( and D 13 D 9 C o n t r i b u t e s ) )
D 1 4 C o n t r i b u t e s ( ) Bool ( and D 14 D 9 C o n t r i b u t e s ) )
D 6 C o n t r i b u t e s ( ) Bool ( and D 6 D C o n t r i b u t e s ) )
D 7 C o n t r i b u t e s ( ) Bool ( and D 7 D C o n t r i b u t e s ) )
E C o n t r i b u t e s ( ) Bool E)

277

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

( d e f i n e −fun E 2 C o n t r i b u t e s ( ) Bool ( and E 2 E C o n t r i b u t e s ) )
( d e f i n e −fun E 3 C o n t r i b u t e s ( ) Bool ( and E 3 E C o n t r i b u t e s ) )
( d e f i n e −fun E 4 C o n t r i b u t e s ( ) Bool ( and E 4 E C o n t r i b u t e s ) )
( d e f i n e −fun E 5 C o n t r i b u t e s ( ) Bool ( and E 5 E C o n t r i b u t e s ) )
( d e f i n e −fun E 6 C o n t r i b u t e s ( ) Bool ( and E 6 E C o n t r i b u t e s ) )
( d e f i n e −fun E 7 C o n t r i b u t e s ( ) Bool ( and E 7 E C o n t r i b u t e s ) )
( a s s e r t ( i t e B 1 C o n t r i b u t e s (= SF B 1 t r u e ) (= SF B 1 f a l s e ) ) )
( a s s e r t ( i t e B 3 C o n t r i b u t e s (= C B F t p l u s o n e B 3 t r u e ) (=
CBF t plus one B 3 f a l s e ) ) )
( a s s e r t ( i t e C 1 C o n t r i b u t e s (= C B F t p l u s o n e C 1 t r u e ) (=
CBF t plus one C 1 f a l s e ) ) )
( a s s e r t ( i t e C 5 C o n t r i b u t e s (= SF C 5 t r u e ) (= SF C 5 f a l s e ) ) )
( a s s e r t ( i t e C 7 C o n t r i b u t e s (= C B F t p l u s o n e C 7 t r u e ) (=
CBF t plus one C 7 f a l s e ) ) )
( a s s e r t ( i t e C 8 C o n t r i b u t e s (= C B F t p l u s o n e C 8 t r u e ) (=
CBF t plus one C 8 f a l s e ) ) )
( a s s e r t ( i t e C 1 0 C o n t r i b u t e s (= RF C 10 t r u e ) (= RF C 10 f a l s e ) ) )
( a s s e r t ( i t e D 3 C o n t r i b u t e s (= BF D 3 t r u e ) (= BF D 3 f a l s e ) ) )
( a s s e r t ( i t e D 1 0 C o n t r i b u t e s (= CBF t D 10 t r u e ) (= CBF t D 10
false )))
( a s s e r t ( i t e D 1 1 C o n t r i b u t e s (= C B F t p l u s o n e D 1 1 t r u e ) (=
CBF t plus one D 11 f a l s e ) ) )
( a s s e r t ( i t e D 1 3 C o n t r i b u t e s (= C B F t p l u s o n e D 1 3 t r u e ) (=
CBF t plus one D 13 f a l s e ) ) )
( a s s e r t ( i t e D 1 4 C o n t r i b u t e s (= CBF t D 14 t r u e ) (= CBF t D 14
false )))
( a s s e r t ( i t e D 6 C o n t r i b u t e s (= SS D 6 t r u e ) (= SS D 6 f a l s e ) ) )
( a s s e r t ( i t e E 3 C o n t r i b u t e s (= C B F t p l u s o n e E 3 t r u e ) (=
CBF t plus one E 3 f a l s e ) ) )
( a s s e r t ( i t e E 5 C o n t r i b u t e s (= BF E 5 t r u e ) (= BF E 5 f a l s e ) ) )
( a s s e r t ( i t e E 6 C o n t r i b u t e s (= SS E 6 t r u e ) (= SS E 6 f a l s e ) ) )
( a s s e r t ( and ( o r B s C s ) ( o r D s E s ) ) )
( a s s e r t ( i t e B s ( o r B B P ) ( not B) ) )
( a s s e r t ( i t e C s ( o r C C P ) ( not C) ) )
( a s s e r t ( i t e E s ( o r E E P ) ( not E) ) )
( a s s e r t ( i t e D s D PP f a l s e ) )

B.2.4

Detection Constraints for Failure of Feature E
Listing B.7: Feature Interaction for Failure of Feature E

1
2
3
4

( s e t −o p t i o n : p r i n t −s u c c e s s t r u e )
( d e f i n e −fun min2 ( ( x1 Real ) ( x2 Real ) ) Real ( / (− (+ x1 x2 ) ( abs (−
x1 x2 ) ) ) 2 ) )
( d e f i n e −fun max2 ( ( x1 Real ) ( x2 Real ) ) Real ( / (+ x1 x2 ( abs (− x1
x2 ) ) ) 2 ) )
( d e c l a r e −c o n s t BF Real )

278

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

( d e c l a r e −c o n s t C B F t p l u s o n e D 1 1 Bool )
( d e c l a r e −c o n s t RF C 10 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e D 1 3 Bool )
( d e c l a r e −c o n s t CBF t D 14 Bool )
( d e c l a r e −c o n s t SF Real )
( d e c l a r e −c o n s t C B F t p l u s o n e Real )
( d e c l a r e −c o n s t BF D 3 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 8 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 7 Bool )
( d e c l a r e −c o n s t SS Real )
( d e c l a r e −c o n s t SF B 1 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e E 3 Bool )
( d e c l a r e −c o n s t SF C 5 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e B 3 Bool )
( d e c l a r e −c o n s t BF E 5 Bool )
( d e c l a r e −c o n s t C B F t p l u s o n e C 1 Bool )
( d e c l a r e −c o n s t CBF t D 10 Bool )
( d e c l a r e −c o n s t CBF t Real )
( d e c l a r e −c o n s t RF Real )
( d e c l a r e −c o n s t C s Bool )
( d e c l a r e −c o n s t B s Bool )
( d e c l a r e −c o n s t E s Bool )
( d e c l a r e −c o n s t D s Bool )
( d e c l a r e −c o n s t SS D 6 Bool )
( d e c l a r e −c o n s t SS E 6 Bool )
( d e f i n e −fun V SS ( ) Bool ( o r ( o r f a l s e SS D 6 ) SS E 6 ) )
( d e f i n e −fun V SF ( ) Bool ( o r ( o r f a l s e SF B 1 ) SF C 5 ) )
( d e f i n e −fun V CBF t ( ) Bool ( o r ( o r f a l s e CBF t D 10 ) CBF t D 14 ) )
( d e f i n e −fun V RF ( ) Bool ( o r f a l s e RF C 10 ) )
( d e f i n e −fun V BF ( ) Bool ( o r ( o r f a l s e BF D 3 ) BF E 5 ) )
( d e f i n e −fun V CBF t plus one ( ) Bool ( o r ( o r ( o r ( o r ( o r ( o r ( o r
f a l s e CBF t plus one B 3 ) CBF t plus one C 1 ) CBF t plus one C 7
) CBF t plus one C 8 ) CBF t plus one D 11 ) CBF t plus one D 13 )
CBF t plus one E 3 ) )
( d e f i n e −fun B 1 ( ) Bool ( and ( and (= SF C B F t p l u s o n e ) V SF )
V CBF t plus one ) )
( d e f i n e −fun B 2 ( ) Bool t r u e )
( d e f i n e −fun B 3 ( ) Bool ( and (> C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun B ( ) Bool ( and ( and ( and t r u e B 1 ) B 2 ) B 3 ) )
( d e f i n e −fun C 1 ( ) Bool ( and (> C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 5 ( ) Bool ( and ( and (= SF ( ∗ C B F t p l u s o n e 0 . 2 ) )
V SF ) V CBF t plus one ) )
( d e f i n e −fun C 6 ( ) Bool t r u e )
( d e f i n e −fun C 7 ( ) Bool ( and (> C B F t p l u s o n e 2 0 . 0 )
V CBF t plus one ) )

279

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

( d e f i n e −fun C 3 ( ) Bool ( and ( and ( and t r u e C 5 ) C 6 ) C 7 ) )
( d e f i n e −fun C 8 ( ) Bool ( and (< C B F t p l u s o n e 5 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun C 9 ( ) Bool t r u e )
( d e f i n e −fun C 10 ( ) Bool ( and ( and (= RF ( ∗ C B F t p l u s o n e 0 . 8 ) )
V RF) V CBF t plus one ) )
( d e f i n e −fun C 4 ( ) Bool ( and ( and ( and t r u e C 8 ) C 9 ) C 10 ) )
( d e f i n e −fun C 2 ( ) Bool ( o r ( o r f a l s e C 3 ) C 4 ) )
( d e f i n e −fun C ( ) Bool ( and ( and t r u e C 1 ) C 2 ) )
( d e f i n e −fun A 1 ( ) Bool ( o r ( o r f a l s e B) C) )
( d e f i n e −fun D 2 ( ) Bool t r u e )
( d e f i n e −fun D 3 ( ) Bool ( and (> BF 0 . 0 ) V BF) )
( d e f i n e −fun D 4 ( ) Bool t r u e )
( d e f i n e −fun D 10 ( ) Bool ( and (= CBF t 0 . 0 ) V CBF t ) )
( d e f i n e −fun D 11 ( ) Bool ( and ( and (= C B F t p l u s o n e BF) V BF)
V CBF t plus one ) )
( d e f i n e −fun D 12a ( ) Bool t r u e )
( d e f i n e −fun D 8 ( ) Bool ( and ( and ( and t r u e D 10 ) D 11 ) D 12a ) )
( d e f i n e −fun D 12b ( ) Bool t r u e )
( d e f i n e −fun D 13 ( ) Bool ( and (= C B F t p l u s o n e 0 . 0 )
V CBF t plus one ) )
( d e f i n e −fun D 14 ( ) Bool ( and (> CBF t 0 . 0 ) V CBF t ) )
( d e f i n e −fun D 9 ( ) Bool ( and ( and ( and t r u e D 12b ) D 13 ) D 14 ) )
( d e f i n e −fun D 5 ( ) Bool ( o r ( o r f a l s e D 8 ) D 9 ) )
( d e f i n e −fun D 6 ( ) Bool ( and (= SS 1 . 0 ) V SS ) )
( d e f i n e −fun D 7 ( ) Bool t r u e )
( d e f i n e −fun D ( ) Bool ( and ( and ( and ( and ( and ( and t r u e D 2 ) D 3 )
D 4) D 5) D 6) D 7) )
( d e f i n e −fun E 2 ( ) Bool t r u e )
( d e f i n e −fun E 3 ( ) Bool ( and ( and (= C B F t p l u s o n e BF) V BF)
V CBF t plus one ) )
( d e f i n e −fun E 4 ( ) Bool t r u e )
( d e f i n e −fun E 5 ( ) Bool ( and (> BF 0 . 0 ) V BF) )
( d e f i n e −fun E 6 ( ) Bool ( and (< SS 1 . 0 ) V SS ) )
( d e f i n e −fun E 7 ( ) Bool t r u e )
( d e f i n e −fun E ( ) Bool ( and ( and ( and ( and ( and ( and t r u e E 2 ) E 3 )
E 4) E 5) E 6) E 7))
( d e f i n e −fun A 2 ( ) Bool ( o r ( o r f a l s e D) E) )
( d e f i n e −fun A ( ) Bool ( and ( and t r u e A 1 ) A 2 ) )
( d e f i n e −fun B P ( ) Bool ( and t r u e B 3 ) )
( d e f i n e −fun C 3 P ( ) Bool ( and t r u e C 7 ) )
( d e f i n e −fun C 4 P ( ) Bool ( and t r u e C 8 ) )
( d e f i n e −fun C 2 P ( ) Bool ( o r ( o r f a l s e C 3 P ) C 4 P ) )
( d e f i n e −fun C P ( ) Bool ( and ( and t r u e C 1 ) C 2 P ) )
( d e f i n e −fun A 1 P ( ) Bool ( o r ( o r f a l s e B P ) C P ) )
( d e f i n e −fun D 8 P ( ) Bool ( and t r u e D 10 ) )
( d e f i n e −fun D 9 P ( ) Bool ( and t r u e D 14 ) )

280

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

( d e f i n e −fun D 5 P ( ) Bool ( o r ( o r f a l s e D 8 P ) D 9 P ) )
( d e f i n e −fun D P ( ) Bool ( and ( and ( and t r u e D 3 ) D 5 P ) D 6 ) )
( d e f i n e −fun E P ( ) Bool ( and ( and t r u e E 5 ) E 6 ) )
( d e f i n e −fun A 2 P ( ) Bool ( o r ( o r f a l s e D P ) E P ) )
( d e f i n e −fun A P ( ) Bool ( and ( and t r u e A 1 P ) A 2 P ) )
( d e f i n e −fun B 1 N ( ) Bool ( and ( and ( not (= SF C B F t p l u s o n e ) )
V SF ) V CBF t plus one ) )
( d e f i n e −fun C 5 N ( ) Bool ( and ( and ( not (= SF ( ∗ C B F t p l u s o n e
0 . 2 ) ) ) V SF ) V CBF t plus one ) )
( d e f i n e −fun C 10 N ( ) Bool ( and ( and ( not (= RF ( ∗ C B F t p l u s o n e
0 . 8 ) ) ) V RF) V CBF t plus one ) )
( d e f i n e −fun D 11 N ( ) Bool ( and ( and ( not (= C B F t p l u s o n e BF) )
V BF) V CBF t plus one ) )
( d e f i n e −fun D 13 N ( ) Bool ( and ( not (= C B F t p l u s o n e 0 . 0 ) )
V CBF t plus one ) )
( d e f i n e −fun E 3 N ( ) Bool ( and ( and ( not (= C B F t p l u s o n e BF) )
V BF) V CBF t plus one ) )
( d e f i n e −fun B PP ( ) Bool ( and ( and t r u e B 3 ) ( o r f a l s e B 1 N ) ) )
( d e f i n e −fun C 3 PP ( ) Bool ( and ( and t r u e C 7 ) ( o r f a l s e C 5 N ) ) )
( d e f i n e −fun C 4 PP ( ) Bool ( and ( and t r u e C 8 ) ( o r f a l s e C 10 N ) ) )
( d e f i n e −fun C 2 PP ( ) Bool ( o r ( o r f a l s e C 3 PP ) C 4 PP ) )
( d e f i n e −fun C PP ( ) Bool ( and ( and t r u e C 1 ) C 2 PP ) )
( d e f i n e −fun A 1 PP ( ) Bool ( o r ( o r f a l s e B PP ) C PP) )
( d e f i n e −fun D 8 PP ( ) Bool ( and ( and t r u e D 10 ) ( o r f a l s e D 11 N ) ) )
( d e f i n e −fun D 9 PP ( ) Bool ( and ( and t r u e D 14 ) ( o r f a l s e D 13 N ) ) )
( d e f i n e −fun D 5 PP ( ) Bool ( o r ( o r f a l s e D 8 PP ) D 9 PP ) )
( d e f i n e −fun D PP ( ) Bool ( and ( and ( and t r u e D 3 ) D 5 PP ) D 6 ) )
( d e f i n e −fun E PP ( ) Bool ( and ( and ( and t r u e E 5 ) E 6 ) ( o r f a l s e
E 3 N)))
( d e f i n e −fun A 2 PP ( ) Bool ( o r ( o r f a l s e D PP) E PP ) )
( d e f i n e −fun A PP ( ) Bool ( and ( and t r u e A 1 PP ) A 2 PP ) )
( d e f i n e −fun A C o n t r i b u t e s ( ) Bool A)
( d e f i n e −fun A 1 C o n t r i b u t e s ( ) Bool ( and A 1 A C o n t r i b u t e s ) )
( d e f i n e −fun B C o n t r i b u t e s ( ) Bool B)
( d e f i n e −fun B 1 C o n t r i b u t e s ( ) Bool ( and B 1 B C o n t r i b u t e s ) )
( d e f i n e −fun B 2 C o n t r i b u t e s ( ) Bool ( and B 2 B C o n t r i b u t e s ) )
( d e f i n e −fun B 3 C o n t r i b u t e s ( ) Bool ( and B 3 B C o n t r i b u t e s ) )
( d e f i n e −fun C C o n t r i b u t e s ( ) Bool C)
( d e f i n e −fun C 1 C o n t r i b u t e s ( ) Bool ( and C 1 C C o n t r i b u t e s ) )
( d e f i n e −fun C 2 C o n t r i b u t e s ( ) Bool ( and C 2 C C o n t r i b u t e s ) )
( d e f i n e −fun C 3 C o n t r i b u t e s ( ) Bool ( and C 3 C 2 C o n t r i b u t e s ) )
( d e f i n e −fun C 5 C o n t r i b u t e s ( ) Bool ( and C 5 C 3 C o n t r i b u t e s ) )
( d e f i n e −fun C 6 C o n t r i b u t e s ( ) Bool ( and C 6 C 3 C o n t r i b u t e s ) )
( d e f i n e −fun C 7 C o n t r i b u t e s ( ) Bool ( and C 7 C 3 C o n t r i b u t e s ) )
( d e f i n e −fun C 4 C o n t r i b u t e s ( ) Bool ( and C 4 C 2 C o n t r i b u t e s ) )
( d e f i n e −fun C 8 C o n t r i b u t e s ( ) Bool ( and C 8 C 4 C o n t r i b u t e s ) )
( d e f i n e −fun C 9 C o n t r i b u t e s ( ) Bool ( and C 9 C 4 C o n t r i b u t e s ) )

281

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

( d e f i n e −fun C 1 0 C o n t r i b u t e s ( ) Bool ( and C 10 C 4 C o n t r i b u t e s ) )
( d e f i n e −fun A 2 C o n t r i b u t e s ( ) Bool ( and A 2 A C o n t r i b u t e s ) )
( d e f i n e −fun D C o n t r i b u t e s ( ) Bool D)
( d e f i n e −fun D 2 C o n t r i b u t e s ( ) Bool ( and D 2 D C o n t r i b u t e s ) )
( d e f i n e −fun D 3 C o n t r i b u t e s ( ) Bool ( and D 3 D C o n t r i b u t e s ) )
( d e f i n e −fun D 4 C o n t r i b u t e s ( ) Bool ( and D 4 D C o n t r i b u t e s ) )
( d e f i n e −fun D 5 C o n t r i b u t e s ( ) Bool ( and D 5 D C o n t r i b u t e s ) )
( d e f i n e −fun D 8 C o n t r i b u t e s ( ) Bool ( and D 8 D 5 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 0 C o n t r i b u t e s ( ) Bool ( and D 10 D 8 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 1 C o n t r i b u t e s ( ) Bool ( and D 11 D 8 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 2 a C o n t r i b u t e s ( ) Bool ( and D 12a D 8 C o n t r i b u t e s ) )
( d e f i n e −fun D 9 C o n t r i b u t e s ( ) Bool ( and D 9 D 5 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 2 b C o n t r i b u t e s ( ) Bool ( and D 12b D 9 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 3 C o n t r i b u t e s ( ) Bool ( and D 13 D 9 C o n t r i b u t e s ) )
( d e f i n e −fun D 1 4 C o n t r i b u t e s ( ) Bool ( and D 14 D 9 C o n t r i b u t e s ) )
( d e f i n e −fun D 6 C o n t r i b u t e s ( ) Bool ( and D 6 D C o n t r i b u t e s ) )
( d e f i n e −fun D 7 C o n t r i b u t e s ( ) Bool ( and D 7 D C o n t r i b u t e s ) )
( d e f i n e −fun E C o n t r i b u t e s ( ) Bool E)
( d e f i n e −fun E 2 C o n t r i b u t e s ( ) Bool ( and E 2 E C o n t r i b u t e s ) )
( d e f i n e −fun E 3 C o n t r i b u t e s ( ) Bool ( and E 3 E C o n t r i b u t e s ) )
( d e f i n e −fun E 4 C o n t r i b u t e s ( ) Bool ( and E 4 E C o n t r i b u t e s ) )
( d e f i n e −fun E 5 C o n t r i b u t e s ( ) Bool ( and E 5 E C o n t r i b u t e s ) )
( d e f i n e −fun E 6 C o n t r i b u t e s ( ) Bool ( and E 6 E C o n t r i b u t e s ) )
( d e f i n e −fun E 7 C o n t r i b u t e s ( ) Bool ( and E 7 E C o n t r i b u t e s ) )
( a s s e r t ( i t e B 1 C o n t r i b u t e s (= SF B 1 t r u e ) (= SF B 1 f a l s e ) ) )
( a s s e r t ( i t e B 3 C o n t r i b u t e s (= C B F t p l u s o n e B 3 t r u e ) (=
CBF t plus one B 3 f a l s e ) ) )
( a s s e r t ( i t e C 1 C o n t r i b u t e s (= C B F t p l u s o n e C 1 t r u e ) (=
CBF t plus one C 1 f a l s e ) ) )
( a s s e r t ( i t e C 5 C o n t r i b u t e s (= SF C 5 t r u e ) (= SF C 5 f a l s e ) ) )
( a s s e r t ( i t e C 7 C o n t r i b u t e s (= C B F t p l u s o n e C 7 t r u e ) (=
CBF t plus one C 7 f a l s e ) ) )
( a s s e r t ( i t e C 8 C o n t r i b u t e s (= C B F t p l u s o n e C 8 t r u e ) (=
CBF t plus one C 8 f a l s e ) ) )
( a s s e r t ( i t e C 1 0 C o n t r i b u t e s (= RF C 10 t r u e ) (= RF C 10 f a l s e ) ) )
( a s s e r t ( i t e D 3 C o n t r i b u t e s (= BF D 3 t r u e ) (= BF D 3 f a l s e ) ) )
( a s s e r t ( i t e D 1 0 C o n t r i b u t e s (= CBF t D 10 t r u e ) (= CBF t D 10
false )))
( a s s e r t ( i t e D 1 1 C o n t r i b u t e s (= C B F t p l u s o n e D 1 1 t r u e ) (=
CBF t plus one D 11 f a l s e ) ) )
( a s s e r t ( i t e D 1 3 C o n t r i b u t e s (= C B F t p l u s o n e D 1 3 t r u e ) (=
CBF t plus one D 13 f a l s e ) ) )
( a s s e r t ( i t e D 1 4 C o n t r i b u t e s (= CBF t D 14 t r u e ) (= CBF t D 14
false )))
( a s s e r t ( i t e D 6 C o n t r i b u t e s (= SS D 6 t r u e ) (= SS D 6 f a l s e ) ) )
( a s s e r t ( i t e E 3 C o n t r i b u t e s (= C B F t p l u s o n e E 3 t r u e ) (=
CBF t plus one E 3 f a l s e ) ) )

282

162
163
164
165
166
167
168

( assert
( assert
( assert
( assert
( assert
( assert
( assert

B.3

( ite
( ite
( and
( ite
( ite
( ite
( ite

E 5
E 6
( or
B s
C s
D s
E s

C o n t r i b u t e s (= BF E 5 t r u e ) (= BF E 5 f a l s e ) ) )
C o n t r i b u t e s (= SS E 6 t r u e ) (= SS E 6 f a l s e ) ) )
B s C s ) ( or D s E s ) ) )
( o r B B P ) ( not B) ) )
( o r C C P ) ( not C) ) )
( o r D D P ) ( not D) ) )
E PP f a l s e ) )

Run-Time Detection Code (C++)

This section of the appendix includes the C++ code output for detecting feature interactions at run time in Chapter 8. All four features in the braking system goal model are
detected with this single code listing.
Listing B.8: Feature Interaction for Failure of Feature B, C, D, and E
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

double BF ;
bool C B F t p l u s o n e D 1 1 ;
bool D p r e c o n d i t i o n ;
bool RF C 10 ;
bool C p r e c o n d i t i o n ;
bool C B F t p l u s o n e D 1 3 ;
bool E p r e c o n d i t i o n ;
bool CBF t D 14 ;
double SF ;
bool t o p L e v e l S a t i s f a t i o n ;
bool D f a i l s ;
double C B F t p l u s o n e ;
bool B f a i l s ;
bool BF D 3 ;
bool C B F t p l u s o n e C 8 ;
bool C B F t p l u s o n e C 7 ;
double SS ;
bool SF B 1 ;
bool C B F t p l u s o n e E 3 ;
bool SF C 5 ;
bool C B F t p l u s o n e B 3 ;
bool BF E 5 ;
bool C B F t p l u s o n e C 1 ;
bool E f a i l s ;
bool CBF t D 10 ;
bool C f a i l s ;
double CBF t ;
double RF;
bool B p r e c o n d i t i o n ;

283

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

bool SS D 6 ;
bool SS E 6 ;
bool V SS ( ) {
return true ;
}
bool V SF ( ) {
return true ;
}
bool V CBF t ( ) {
return true ;
}
bool V RF ( ) {
return true ;
}
bool V BF ( ) {
return true ;
}
bool V CBF t plus one ( ) {
return true ;
}
bool B 1 ( ) {
return ( ( ( s t d : : abs ( SF − C B F t p l u s o n e ) < 0 . 0 0 0 1 )
&& V SF ( ) ) && V CBF t plus one ( ) ) ;
}
bool B 2 ( ) {
return true ;
}
bool B 3 ( ) {
return ( ( C B F t p l u s o n e > 0 . 0 ) && V CBF t plus one ( ) ) ;
}
bool B( ) {
return ( ( ( true && B 1 ( ) ) && B 2 ( ) ) && B 3 ( ) ) ;
}
bool C 1 ( ) {
return ( ( C B F t p l u s o n e > 0 . 0 ) && V CBF t plus one ( ) ) ;
}
bool C 5 ( ) {
return ( ( ( s t d : : abs ( SF − ( C B F t p l u s o n e ∗ 0 . 2 ) ) < 0 . 0 0 0 1 )
&& V SF ( ) ) && V CBF t plus one ( ) ) ;
}
bool C 6 ( ) {
return true ;
}
bool C 7 ( ) {
return ( ( C B F t p l u s o n e > 0 . 2 ) && V CBF t plus one ( ) ) ;
}
bool C 3 ( ) {

284

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

return ( ( ( true && C 5 ( ) ) && C 6 ( ) ) && C 7 ( ) ) ;
}
bool C 8 ( ) {
return ( ( C B F t p l u s o n e < 0 . 5 ) && V CBF t plus one ( ) ) ;
}
bool C 9 ( ) {
return true ;
}
bool C 10 ( ) {
return ( ( ( s t d : : abs (RF − ( C B F t p l u s o n e ∗ 0 . 8 ) ) < 0 . 0 0 0 1 )
&& V RF ( ) ) && V CBF t plus one ( ) ) ;
}
bool C 4 ( ) {
return ( ( ( true && C 8 ( ) ) && C 9 ( ) ) && C 10 ( ) ) ;
}
bool C 2 ( ) {
return ( ( f a l s e | | C 3 ( ) ) | | C 4 ( ) ) ;
}
bool C( ) {
return ( ( true && C 1 ( ) ) && C 2 ( ) ) ;
}
bool A 1 ( ) {
return ( ( f a l s e | | B( ) ) | | C( ) ) ;
}
bool D 2 ( ) {
return true ;
}
bool D 3 ( ) {
return ( (BF > 0 . 0 ) && V BF ( ) ) ;
}
bool D 4 ( ) {
return true ;
}
bool D 10 ( ) {
return ( ( s t d : : abs ( CBF t − 0 . 0 ) < 0 . 0 0 0 1 ) && V CBF t ( ) ) ;
}
bool D 11 ( ) {
return ( ( ( s t d : : abs ( C B F t p l u s o n e − BF) < 0 . 0 0 0 1 )
&& V BF ( ) ) && V CBF t plus one ( ) ) ;
}
bool D 12a ( ) {
return true ;
}
bool D 8 ( ) {
return ( ( ( true && D 10 ( ) ) && D 11 ( ) ) && D 12a ( ) ) ;
}
bool D 12b ( ) {

285

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

return true ;
}
bool D 13 ( ) {
return ( ( s t d : : abs ( C B F t p l u s o n e − 0 . 0 ) < 0 . 0 0 0 1 )
&& V CBF t plus one ( ) ) ;
}
bool D 14 ( ) {
return ( ( CBF t > 0 . 0 ) && V CBF t ( ) ) ;
}
bool D 9 ( ) {
return ( ( ( true && D 12b ( ) ) && D 13 ( ) ) && D 14 ( ) ) ;
}
bool D 5 ( ) {
return ( ( f a l s e | | D 8 ( ) ) | | D 9 ( ) ) ;
}
bool D 6 ( ) {
return ( ( s t d : : abs ( SS − 1 . 0 ) < 0 . 0 0 0 1 ) && V SS ( ) ) ;
}
bool D 7 ( ) {
return true ;
}
bool D( ) {
return ( ( ( ( ( ( true && D 2 ( ) ) && D 3 ( ) ) && D 4 ( ) )
&& D 5 ( ) ) && D 6 ( ) ) && D 7 ( ) ) ;
}
bool E 2 ( ) {
return true ;
}
bool E 3 ( ) {
return ( ( ( s t d : : abs ( C B F t p l u s o n e − BF) < 0 . 0 0 0 1 )
&& V BF ( ) ) && V CBF t plus one ( ) ) ;
}
bool E 4 ( ) {
return true ;
}
bool E 5 ( ) {
return ( (BF > 0 . 0 ) && V BF ( ) ) ;
}
bool E 6 ( ) {
return ( ( SS < 1 . 0 ) && V SS ( ) ) ;
}
bool E 7 ( ) {
return true ;
}
bool E ( ) {
return ( ( ( ( ( ( true && E 2 ( ) ) && E 3 ( ) ) && E 4 ( ) )
&& E 5 ( ) ) && E 6 ( ) ) && E 7 ( ) ) ;

286

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

}
bool A 2 ( ) {
return ( ( f a l s e | | D( ) ) | | E ( ) ) ;
}
bool A( ) {
return ( ( true && A 1 ( ) ) && A 2 ( ) ) ;
}
bool B P ( ) {
return ( true && B 3 ( ) ) ;
}
bool C 3 P ( ) {
return ( true && C 7 ( ) ) ;
}
bool C 4 P ( ) {
return ( true && C 8 ( ) ) ;
}
bool C 2 P ( ) {
return ( ( f a l s e | | C 3 P ( ) ) | | C 4 P ( ) ) ;
}
bool C P ( ) {
return ( ( true && C 1 ( ) ) && C 2 P ( ) ) ;
}
bool A 1 P ( ) {
return ( ( f a l s e | | B P ( ) ) | | C P ( ) ) ;
}
bool D 8 P ( ) {
return ( true && D 10 ( ) ) ;
}
bool D 9 P ( ) {
return ( true && D 14 ( ) ) ;
}
bool D 5 P ( ) {
return ( ( f a l s e | | D 8 P ( ) ) | | D 9 P ( ) ) ;
}
bool D P ( ) {
return ( ( ( true && D 3 ( ) ) && D 5 P ( ) ) && D 6 ( ) ) ;
}
bool E P ( ) {
return ( ( true && E 5 ( ) ) && E 6 ( ) ) ;
}
bool A 2 P ( ) {
return ( ( f a l s e | | D P ( ) ) | | E P ( ) ) ;
}
bool A P ( ) {
return ( ( true && A 1 P ( ) ) && A 2 P ( ) ) ;
}
bool B 1 N ( ) {

287

218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264

return ( ( ( ! ( s t d : : abs ( SF − C B F t p l u s o n e ) < 0 . 0 0 0 1 ) )
&& V SF ( ) ) && V CBF t plus one ( ) ) ;
}
bool C 5 N ( ) {
return ( ( ( ! ( s t d : : abs ( SF − ( C B F t p l u s o n e ∗ 0 . 2 ) ) < 0 . 0 0 0 1 ) )
&& V SF ( ) ) && V CBF t plus one ( ) ) ;
}
bool C 10 N ( ) {
return ( ( ( ! ( s t d : : abs (RF − ( C B F t p l u s o n e ∗ 0 . 8 ) ) < 0 . 0 0 0 1 ) )
&& V RF ( ) ) && V CBF t plus one ( ) ) ;
}
bool D 11 N ( ) {
return ( ( ( ! ( s t d : : abs ( C B F t p l u s o n e − BF) < 0 . 0 0 0 1 ) )
&& V BF ( ) ) && V CBF t plus one ( ) ) ;
}
bool D 13 N ( ) {
return ( ( ! ( s t d : : abs ( C B F t p l u s o n e − 0 . 0 ) < 0 . 0 0 0 1 ) )
&& V CBF t plus one ( ) ) ;
}
bool E 3 N ( ) {
return ( ( ( ! ( s t d : : abs ( C B F t p l u s o n e − BF) < 0 . 0 0 0 1 ) )
&& V BF ( ) ) && V CBF t plus one ( ) ) ;
}
bool B PP ( ) {
return ( ( true && B 3 ( ) ) && ( f a l s e | | B 1 N ( ) ) ) ;
}
bool C 3 PP ( ) {
return ( ( true && C 7 ( ) ) && ( f a l s e | | C 5 N ( ) ) ) ;
}
bool C 4 PP ( ) {
return ( ( true && C 8 ( ) ) && ( f a l s e | | C 10 N ( ) ) ) ;
}
bool C 2 PP ( ) {
return ( ( f a l s e | | C 3 PP ( ) ) | | C 4 PP ( ) ) ;
}
bool C PP ( ) {
return ( ( true && C 1 ( ) ) && C 2 PP ( ) ) ;
}
bool A 1 PP ( ) {
return ( ( f a l s e | | B PP ( ) ) | | C PP ( ) ) ;
}
bool D 8 PP ( ) {
return ( ( true && D 10 ( ) ) && ( f a l s e | | D 11 N ( ) ) ) ;
}
bool D 9 PP ( ) {
return ( ( true && D 14 ( ) ) && ( f a l s e | | D 13 N ( ) ) ) ;
}

288

265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311

bool D 5 PP ( ) {
return ( ( f a l s e | | D 8 PP ( ) ) | | D 9 PP ( ) ) ;
}
bool D PP ( ) {
return ( ( ( true && D 3 ( ) ) && D 5 PP ( ) ) && D 6 ( ) ) ;
}
bool E PP ( ) {
return ( ( ( true && E 5 ( ) ) && E 6 ( ) ) && ( f a l s e | | E 3 N ( ) ) ) ;
}
bool A 2 PP ( ) {
return ( ( f a l s e | | D PP ( ) ) | | E PP ( ) ) ;
}
bool A PP ( ) {
return ( ( true && A 1 PP ( ) ) && A 2 PP ( ) ) ;
}
bool A C o n t r i b u t e s ( ) {
return A( ) ;
}
bool A 1 C o n t r i b u t e s ( ) {
return ( A 1 ( ) && A C o n t r i b u t e s ( ) ) ;
}
bool B C o n t r i b u t e s ( ) {
return (B( ) && A 1 C o n t r i b u t e s ( ) ) ;
}
bool B 1 C o n t r i b u t e s ( ) {
return ( B 1 ( ) && B C o n t r i b u t e s ( ) ) ;
}
bool B 2 C o n t r i b u t e s ( ) {
return ( B 2 ( ) && B C o n t r i b u t e s ( ) ) ;
}
bool B 3 C o n t r i b u t e s ( ) {
return ( B 3 ( ) && B C o n t r i b u t e s ( ) ) ;
}
bool C C o n t r i b u t e s ( ) {
return (C( ) && A 1 C o n t r i b u t e s ( ) ) ;
}
bool C 1 C o n t r i b u t e s ( ) {
return ( C 1 ( ) && C C o n t r i b u t e s ( ) ) ;
}
bool C 2 C o n t r i b u t e s ( ) {
return ( C 2 ( ) && C C o n t r i b u t e s ( ) ) ;
}
bool C 3 C o n t r i b u t e s ( ) {
return ( C 3 ( ) && C 2 C o n t r i b u t e s ( ) ) ;
}
bool C 5 C o n t r i b u t e s ( ) {
return ( C 5 ( ) && C 3 C o n t r i b u t e s ( ) ) ;

289

312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358

}
bool C 6 C o n t r i b u t e s ( ) {
return ( C 6 ( ) && C 3 C o n t r i b u t e s ( ) ) ;
}
bool C 7 C o n t r i b u t e s ( ) {
return ( C 7 ( ) && C 3 C o n t r i b u t e s ( ) ) ;
}
bool C 4 C o n t r i b u t e s ( ) {
return ( C 4 ( ) && C 2 C o n t r i b u t e s ( ) ) ;
}
bool C 8 C o n t r i b u t e s ( ) {
return ( C 8 ( ) && C 4 C o n t r i b u t e s ( ) ) ;
}
bool C 9 C o n t r i b u t e s ( ) {
return ( C 9 ( ) && C 4 C o n t r i b u t e s ( ) ) ;
}
bool C 1 0 C o n t r i b u t e s ( ) {
return ( C 10 ( ) && C 4 C o n t r i b u t e s ( ) ) ;
}
bool A 2 C o n t r i b u t e s ( ) {
return ( A 2 ( ) && A C o n t r i b u t e s ( ) ) ;
}
bool D C o n t r i b u t e s ( ) {
return (D( ) && A 2 C o n t r i b u t e s ( ) ) ;
}
bool D 2 C o n t r i b u t e s ( ) {
return ( D 2 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool D 3 C o n t r i b u t e s ( ) {
return ( D 3 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool D 4 C o n t r i b u t e s ( ) {
return ( D 4 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool D 5 C o n t r i b u t e s ( ) {
return ( D 5 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool D 8 C o n t r i b u t e s ( ) {
return ( D 8 ( ) && D 5 C o n t r i b u t e s ( ) ) ;
}
bool D 1 0 C o n t r i b u t e s ( ) {
return ( D 10 ( ) && D 8 C o n t r i b u t e s ( ) ) ;
}
bool D 1 1 C o n t r i b u t e s ( ) {
return ( D 11 ( ) && D 8 C o n t r i b u t e s ( ) ) ;
}
bool D 1 2 a C o n t r i b u t e s ( ) {

290

359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405

return ( D 12a ( ) && D 8 C o n t r i b u t e s ( ) ) ;
}
bool D 9 C o n t r i b u t e s ( ) {
return ( D 9 ( ) && D 5 C o n t r i b u t e s ( ) ) ;
}
bool D 1 2 b C o n t r i b u t e s ( ) {
return ( D 12b ( ) && D 9 C o n t r i b u t e s ( ) ) ;
}
bool D 1 3 C o n t r i b u t e s ( ) {
return ( D 13 ( ) && D 9 C o n t r i b u t e s ( ) ) ;
}
bool D 1 4 C o n t r i b u t e s ( ) {
return ( D 14 ( ) && D 9 C o n t r i b u t e s ( ) ) ;
}
bool D 6 C o n t r i b u t e s ( ) {
return ( D 6 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool D 7 C o n t r i b u t e s ( ) {
return ( D 7 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool E C o n t r i b u t e s ( ) {
return (E ( ) && A 2 C o n t r i b u t e s ( ) ) ;
}
bool E 2 C o n t r i b u t e s ( ) {
return ( E 2 ( ) && E C o n t r i b u t e s ( ) ) ;
}
bool E 3 C o n t r i b u t e s ( ) {
return ( E 3 ( ) && E C o n t r i b u t e s ( ) ) ;
}
bool E 4 C o n t r i b u t e s ( ) {
return ( E 4 ( ) && E C o n t r i b u t e s ( ) ) ;
}
bool E 5 C o n t r i b u t e s ( ) {
return ( E 5 ( ) && E C o n t r i b u t e s ( ) ) ;
}
bool E 6 C o n t r i b u t e s ( ) {
return ( E 6 ( ) && E C o n t r i b u t e s ( ) ) ;
}
bool E 7 C o n t r i b u t e s ( ) {
return ( E 7 ( ) && E C o n t r i b u t e s ( ) ) ;
}
void u p d a t e A s s e r t i o n s ( ) {
( B 1 C o n t r i b u t e s ( ) ? ( SF B 1 = true ) : ( SF B 1 = f a l s e ) ) ;
( B 3 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e B 3 = true ) :
( CBF t plus one B 3 = false ) ) ;
( C 1 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e C 1 = true ) :
( CBF t plus one C 1 = false ) ) ;

291

406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433 }

( C 5 C o n t r i b u t e s ( ) ? ( SF C 5 = true ) : ( SF C 5 = f a l s e ) ) ;
( C 7 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e C 7 = true ) :
( CBF t plus one C 7 = false ) ) ;
( C 8 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e C 8 = true ) :
( CBF t plus one C 8 = false ) ) ;
( C 1 0 C o n t r i b u t e s ( ) ? ( RF C 10 = true ) : ( RF C 10 = f a l s e ) ) ;
( D 3 C o n t r i b u t e s ( ) ? ( BF D 3 = true ) : ( BF D 3 = f a l s e ) ) ;
( D 1 0 C o n t r i b u t e s ( ) ? ( CBF t D 10 = true ) : ( CBF t D 10 =
false ) ) ;
( D 1 1 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e D 1 1 = true ) :
( CBF t plus one D 11 = false ) ) ;
( D 1 3 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e D 1 3 = true ) :
( CBF t plus one D 13 = false ) ) ;
( D 1 4 C o n t r i b u t e s ( ) ? ( CBF t D 14 = true ) : ( CBF t D 14 =
false ) ) ;
( D 6 C o n t r i b u t e s ( ) ? ( SS D 6 = true ) : ( SS D 6 = f a l s e ) ) ;
( E 3 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e E 3 = true ) :
( CBF t plus one E 3 = false ) ) ;
( E 5 C o n t r i b u t e s ( ) ? ( BF E 5 = true ) : ( BF E 5 = f a l s e ) ) ;
( E 6 C o n t r i b u t e s ( ) ? ( SS E 6 = true ) : ( SS E 6 = f a l s e ) ) ;
( t o p L e v e l S a t i s f a t i o n = ( (B( ) | | C( ) ) && (D( ) | | E ( ) ) ) ) ;
( B precondition = B P() ) ;
( C precondition = C P() ) ;
( D precondition = D P() ) ;
( E precondition = E P() ) ;
( B f a i l s = B PP ( ) ) ;
( C f a i l s = C PP ( ) ) ;
( D f a i l s = D PP ( ) ) ;
( E f a i l s = E PP ( ) ) ;

292

Appendix C
Non-Functional Feature Interaction
Artifacts
This appendix presents the goal model specifications as well as the satisfiability-modulo
theory (SMT) solver and code (C++) outputs from the Phorcys and Thoosa tools used by
Soter for non-functional feature interaction detection from Chapter 9.

C.1

Goal Model Specifications

This section of the appendix includes the XML schema for representing goal models in
XML, as well as XML representations of the braking system goal model use in Chapter 9.

C.1.1

Goal Model Schema
Listing C.1: XSD Goal Model XML Schema

1 <?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?>
2 <xs : schema xmlns : xs=”h t t p : / /www. w3 . o r g /2001/XMLSchema”
3
elementFormDefault=” q u a l i f i e d ”
4
xmlns : x s i =”h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ”>
5
<xs : e l e m e n t name=”g o a l m o d e l”>
6
<xs : complexType>
7
<xs : sequence >
8
<xs : e l e m e n t r e f =”g o a l ”/>
9
<xs : e l e m e n t r e f =”environment”/>
10
</xs : sequence >

293

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

</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”environment”>
<xs : complexType>
<xs : sequence >
<xs : e l e m e n t minOccurs=”0” maxOccurs=”unbounded ” r e f =”env”/>
</xs : sequence >
</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”env”>
<xs : complexType>
<xs : a t t r i b u t e name=”name” u s e=” r e q u i r e d ” type=”xs : NCName”/>
<xs : a t t r i b u t e name=” r e l a t i o n s h i p ” u s e=” r e q u i r e d ” type=”xs :
s t r i n g ”/>
</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”g o a l ”>
<xs : complexType>
<xs : c h o i c e >
<xs : e l e m e n t maxOccurs=”unbounded ” r e f =”g o a l ”/>
<xs : e l e m e n t r e f =”a g e n t ”/>
</xs : c h o i c e >
<xs : a t t r i b u t e name=”c o n t e n t s ” u s e=” r e q u i r e d ” type=”xs : s t r i n g
”/>
<xs : a t t r i b u t e name=”name” u s e=” r e q u i r e d ” type=”xs : NCName”/>
<xs : a t t r i b u t e name=” r e l a t i o n s h i p ” u s e=” r e q u i r e d ” type=”xs :
s t r i n g ”/>
<xs : a t t r i b u t e name=”type ” u s e=” r e q u i r e d ” type=”xs : NCName”/>
</xs : complexType>
</xs : element>
<xs : e l e m e n t name=”a g e n t”>
<xs : complexType>
<xs : a t t r i b u t e name=”c o n t e n t s ” u s e=” r e q u i r e d ” type=”xs : s t r i n g
”/>
<xs : a t t r i b u t e name=” l o c a t i o n ” u s e=” r e q u i r e d ” type=”xs : NCName
”/>
<xs : a t t r i b u t e name=”name” u s e=” r e q u i r e d ” type=”xs : NCName”/>
</xs : complexType>
</xs : element>
</xs : schema>

C.1.2

Goal Model for Braking System in Chapter 9
Listing C.2: Woven Braking System Goal Model in Chapter 9

1 <?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?>
2 <!−− c r e a t e d with XMLSpear −−>

294

3 <g o a l m o d e l xmlns : x s i =”h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ”
x s i : noNamespaceSchemaLocation =’ g o a l m o d e l . xsd ’>
4
5
<g o a l name=”AA” c o n t e n t s =”Woven Model ” r e l a t i o n s h i p =”” type=”
AND”>
6
7
<g o a l name=”WM” c o n t e n t s=”AND WEAK MITIGATIONS”
r e l a t i o n s h i p =”” type=”AND”>
8
<g o a l name=”WMS” c o n t e n t s =”Weak M i t i g a t i o n : Minimize
C o l l i s i o n ” r e l a t i o n s h i p =”” type=”OR”>
9
<g o a l name=”TMS” c o n t e n t s=”NA” r e l a t i o n s h i p =”” type=”
AND”>
10
<g o a l name=”TMS PT” c o n t e n t s =”NA” r e l a t i o n s h i p =””
type=”OR”>
11
<g o a l name=”TMS PT 1” c o n t e n t s =”(& l t ; FDSensor
0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
12
<a g e n t name=”TMS PT 1 Agent” c o n t e n t s =”
B a t t e r y Charge ” l o c a t i o n =”environment”/>
13
</g o a l >
14
<g o a l name=”TMS PT 2” c o n t e n t s =”(= FDSensor
0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
15
<a g e n t name=”TMS PT 2 Agent” c o n t e n t s =”
B a t t e r y Charge ” l o c a t i o n =”environment”/>
16
</g o a l >
17
</g o a l >
18
<g o a l name=”TMS M” c o n t e n t s=”M” r e l a t i o n s h i p =””
type=”AND”>
19
<g o a l name=”TMS M 1” c o n t e n t s =”(= SF 1 . 0 ) ”
r e l a t i o n s h i p =”” type=”POST”>
20
<a g e n t name=”TMS M 1 Agent” c o n t e n t s =”
Standard Brakes ” l o c a t i o n =”system”/>
21
</g o a l >
22
<g o a l name=”TMS M 2” c o n t e n t s =”(= RF 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”POST”>
23
<a g e n t name=”TMS M 2 Agent” c o n t e n t s =”Regen
Brakes ” l o c a t i o n =”system”/>
24
</g o a l >
25
</g o a l >
26
</g o a l >
27
<g o a l name=”TMS NOT PT” c o n t e n t s =”(&g t ; FDSensor 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
28
<a g e n t name=”TMS PT Agent” c o n t e n t s =”” l o c a t i o n =”
environemnt”/>
29
</g o a l >
30
</g o a l >
31

295

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

<g o a l name=”WMP” c o n t e n t s =”Weak M i t i g a t i o n : Maintain
Charge ” r e l a t i o n s h i p =”” type=”OR”>
<g o a l name=”TMP” c o n t e n t s=”T r i g g e r and M i t i g a t i o n ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”TMP PT 1” c o n t e n t s =”(& l t ; BCHARGE 0 . 5 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”TMP PT Agent” c o n t e n t s =”B a t t e r y
Charge ” l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”TMP M” c o n t e n t s =”M” r e l a t i o n s h i p =””
type=”AND”>
<g o a l name=”TMP M 1” c o n t e n t s=”Achieve ( Apply
F u l l Regen Force ) ” r e l a t i o n s h i p =”” type=”REQ
”>
<a g e n t name=”TM M 1 Agent” c o n t e n t s =”Regen
Brakes ” l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”TMP M 2” c o n t e n t s =”(= RF ( ∗
C B F t p l u s o n e 1 . 0 ) ) ” r e l a t i o n s h i p =”” type=”
POST”>
<a g e n t name=”TM M 2 Agent” c o n t e n t s =”Regen
Brakes ” l o c a t i o n =”system”/>
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”TMP NOT PT” c o n t e n t s=”NA” r e l a t i o n s h i p =””
type=”AND”>
<g o a l name=”TMP NOT PT 1” c o n t e n t s =”(&g t ; BCHARGE
0 . 5 ) ” r e l a t i o n s h i p =”” type=”POST”>
<a g e n t name=”TM NOT PT 1 Agent” c o n t e n t s=”
B a t t e r y Charge ” l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”TMP NOT PT 2” c o n t e n t s =”(= BCHARGE 0 . 5 )
” r e l a t i o n s h i p =”” type=”POST”>
<a g e n t name=”TM NOT PT 2 Agent” c o n t e n t s=”
B a t t e r y Charge ” l o c a t i o n =”environment”/>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”SMF” c o n t e n t s =”AND STRONG MITIGATIONS
FUNCTIONAL” r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”SM” c o n t e n t s=”S t r o n g M i t i g a t i o n : Maintain
S a f e Charge ” r e l a t i o n s h i p =”” type=”OR”>

59

296

60
61
62
63
64
65

<g o a l name=”TM PT” c o n t e n t s=”NA” r e l a t i o n s h i p =”” type=”
AND”>
<g o a l name=”NOT PT M” c o n t e n t s =”(& l t ; BCHARGE 1 . 0 ) ”
r e l a t i o n s h i p =”” type=”POST”>
<a g e n t name=”NOT PT M Agent” c o n t e n t s=”B a t t e r y
Charge ” l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”M” c o n t e n t s=”NA” r e l a t i o n s h i p =”” type=”
AND”>

66
67

<g o a l name=”M 1” c o n t e n t s =”(&g t ; BCHARGE 0 . 9 9 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”M 1 Agent ” c o n t e n t s=”B a t t e r y
Charge ” l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”M 2” c o n t e n t s =”NA” r e l a t i o n s h i p =””
type=”REQ”>
<a g e n t name=”M 2 Agent ” c o n t e n t s=”B a t t e r y
Charge ” l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”M 3” c o n t e n t s =”(= RF 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”POST”>
<a g e n t name=”M 3 Agent ” c o n t e n t s=”Regen
Force ” l o c a t i o n =”environment”/>
</g o a l >

68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

</g o a l >
</g o a l >
<g o a l name=”NOT PT” c o n t e n t s =”(& l t ; BCHARGE 1 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”NOT PT Agent” c o n t e n t s=”B a t t e r y Charge
” l o c a t i o n =”environment”/>
</g o a l >
</g o a l >
<g o a l name=”A” c o n t e n t s =”Maintain ( Brake System ) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”A 1” c o n t e n t s=”Maintain ( Brake Force ) ”
r e l a t i o n s h i p =”” type=”OR”>
<g o a l name=”B” c o n t e n t s=”Achieve ( Standard Force
Braking ) ” r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”B 1 ” c o n t e n t s =”(= SF C B F t p l u s o n e
) ” r e l a t i o n s h i p =”” type=”POST”>

297

90
91
92
93
94
95
96
97
98
99
100
101
102
103
104

105

106

107
108

109

110
111

112

113

<a g e n t name=”B 1 Agent ” c o n t e n t s=”H y d r a u l i c
Brake S e n s o r ” l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”B 2 ” c o n t e n t s =”Achieve ( Apply
Standard Force ) ” r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”B 2 Agent ” c o n t e n t s=”H y d r a u l i c
Brake Actuator ” l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”B 3 ” c o n t e n t s =”(&g t ; C B F t p l u s o n e
0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”B 3 Agent ” c o n t e n t s=”CBF Value
” l o c a t i o n =”environment”/>
</g o a l >
</g o a l >
<g o a l name=”C” c o n t e n t s=”Achieve ( Regen Braking ) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”C 1 ” c o n t e n t s =”(&g t ; C B F t p l u s o n e
0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”C 1 Agent ” c o n t e n t s=”CBF Value
” l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”C 2 ” c o n t e n t s=”Achieve ( Regen and
Standard Force ) ” r e l a t i o n s h i p =”” type=”OR”>
<g o a l name=”C 3 ” c o n t e n t s=”Achieve ( Standard
Force Braking ) ” r e l a t i o n s h i p =”” type=”
AND”>
<g o a l name=”C 5 ” c o n t e n t s =”(= SF ( ∗
CBF t plus one 0 . 2 ) ) ” r e l a t i o n s h i p
=”” type=”POST”>
<a g e n t name=”C 5 Agent ” c o n t e n t s=”
H y d r a u l i c Brake S e n s o r ” l o c a t i o n
=”environment”/>
</g o a l >
<g o a l name=”C 6 ” c o n t e n t s=”Achieve (
Apply Standard Force ) ” r e l a t i o n s h i p
=”” type=”REQ”>
<a g e n t name=”C 6 Agent ” c o n t e n t s=”
H y d r a u l i c Brake Actuator ”
l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”C 7 ” c o n t e n t s =”(&g t ;
C B F t p l u s o n e 0 . 2 ) ” r e l a t i o n s h i p =””
type=”PRE”>
<a g e n t name=”C 7 Agent ” c o n t e n t s=”
CBF Value ” l o c a t i o n =”environment
”/>
</g o a l >

298

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

</g o a l >
<g o a l name=”C 4 ” c o n t e n t s=”Achieve ( Regen
Force ) ” r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”C 8 ” c o n t e n t s =”(& l t ;
C B F t p l u s o n e 0 . 5 ) ” r e l a t i o n s h i p =””
type=”PRE”>
<a g e n t name=”C 7 Agent ” c o n t e n t s=”
CBF Value ” l o c a t i o n =”environment
”/>
</g o a l >
<g o a l name=”C 9 ” c o n t e n t s=”Achieve (
Apply Regen Force ) ” r e l a t i o n s h i p =””
type=”REQ”>
<a g e n t name=”C 6 Agent ” c o n t e n t s=”
R e g e n e r a t i o n Brake Actuator ”
l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”C 10 ” c o n t e n t s =”(= RF ( ∗
CBF t plus one 0 . 8 ) ) ” r e l a t i o n s h i p
=”” type=”POST”>
<a g e n t name=”C 5 Agent ” c o n t e n t s=”
R e g e n e r a t i o n Brake S e n s o r ”
l o c a t i o n =”environment”/>
</g o a l >
</g o a l >
</g o a l >
</g o a l >
</g o a l >
<g o a l name=”A 2” c o n t e n t s=”Maintain ( Brake Command) ”
r e l a t i o n s h i p =”” type=”OR”>
<g o a l name=”D” c o n t e n t s =”Achieve ( Brake−by−Wire ) ”
r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”D 2” c o n t e n t s=”Achieve ( Read CBF) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”D 2 Agent ” c o n t e n t s =”Memory (
CBF) ” l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”D 3” c o n t e n t s =”(&g t ; BF 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”D 3 Agent ” c o n t e n t s =”BF Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”D 4” c o n t e n t s=”Achieve ( Read Brake
Force ) ” r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”D 4 Agent ” c o n t e n t s =”Brake
Pedal S e n s o r (BF) ” l o c a t i o n =”system”/>

299

140
141
142
143
144

145
146

147

148
149

150

151
152
153
154

155

156
157

158

159
160
161

</g o a l >
<g o a l name=”D 5” c o n t e n t s=”Achieve ( Brake P u l s e )
” r e l a t i o n s h i p =”” type=”OR”>
<g o a l name=”D 8” c o n t e n t s=”Achieve ( Brake On
) ” r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”D 10 ” c o n t e n t s =”(= CBF t
0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”D 10 Agent ” c o n t e n t s =”
CBF Value ” l o c a t i o n =”environment
”/>
</g o a l >
<g o a l name=”D 11 ” c o n t e n t s =”(=
C B F t p l u s o n e BF) ” r e l a t i o n s h i p =””
type=”POST”>
<a g e n t name=”D 11 Agent ” c o n t e n t s =”
Brake Pedal S e n s o r (BF) ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”D 12a ” c o n t e n t s=”Achieve (
Brake Force Change ) ” r e l a t i o n s h i p =””
type=”REQ”>
<a g e n t name=”D 12a Agent ” c o n t e n t s
=”Memory ( C B F t p l u s o n e ) ”
l o c a t i o n =”system”/>
</g o a l >
</g o a l >
<g o a l name=”D 9” c o n t e n t s=”Achieve ( Brake
O f f ) ” r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”D 12b ” c o n t e n t s=”Achieve (
Brake Force Change ) ” r e l a t i o n s h i p =””
type=”REQ”>
<a g e n t name=”D 12b Agent ” c o n t e n t s
=”Memory ( C B F t p l u s o n e ) ”
l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”D 13 ” c o n t e n t s =”(=
C B F t p l u s o n e 0 . 0 ) ” r e l a t i o n s h i p =””
type=”POST”>
<a g e n t name=”D 13 Agent ” c o n t e n t s =”
C B F t p l u s o n e Value ” l o c a t i o n =”
environment”/>
</g o a l >
<g o a l name=”D 14 ” c o n t e n t s =”(&g t ; CBF t
0 . 0 ) ” r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”D 14 Agent ” c o n t e n t s =”
CBF Value ” l o c a t i o n =”environment
”/>

300

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

</g o a l >
</g o a l >
</g o a l >
<g o a l name=”D 6” c o n t e n t s =”(= SS 1 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”D 6 Agent ” c o n t e n t s =”SS Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”D 7” c o n t e n t s=”Achieve ( Read SS ) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”D 7 Agent ” c o n t e n t s =” S l i p
S e n s o r ” l o c a t i o n =”system”/>
</g o a l >
</g o a l >
<g o a l name=”E” c o n t e n t s=”Achieve ( Anti−Lock Braking )
” r e l a t i o n s h i p =”” type=”AND”>
<g o a l name=”E 2 ” c o n t e n t s =”Achieve ( Read CBF) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”E 2 Agent ” c o n t e n t s=”Memory (
CBF) ” l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”E 3 ” c o n t e n t s =”(= C B F t p l u s o n e BF
) ” r e l a t i o n s h i p =”” type=”POST”>
<a g e n t name=”E 3 Agent ” c o n t e n t s=”BF Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”E 4 ” c o n t e n t s =”Achieve ( Read Brake
Force ) ” r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”E 4 Agent ” c o n t e n t s=”Brake
Pedal S e n s o r (BF) ” l o c a t i o n =”system”/>
</g o a l >
<g o a l name=”E 5 ” c o n t e n t s =”(&g t ; BF 0 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”E 5 Agent ” c o n t e n t s=”BF Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”E 6 ” c o n t e n t s =”(& l t ; SS 1 . 0 ) ”
r e l a t i o n s h i p =”” type=”PRE”>
<a g e n t name=”E 6 Agent ” c o n t e n t s=”SS Value ”
l o c a t i o n =”environment”/>
</g o a l >
<g o a l name=”E 7 ” c o n t e n t s =”Achieve ( Read SS ) ”
r e l a t i o n s h i p =”” type=”REQ”>
<a g e n t name=”E 7 Agent ” c o n t e n t s=” S l i p
S e n s o r ” l o c a t i o n =”system”/>
</g o a l >
</g o a l >

301

192
</g o a l >
193
</g o a l >
194
</g o a l >
195
</g o a l >
196
197
<environment/>
198 </goalmodel>

C.2

Run-Time Detection Code (C++)

This section of the appendix includes the C++ code output for detecting feature interactions at run time in Chapter 8. All four features in the braking system goal model are
detected with this single code listing.
Listing C.3: Feature Interaction for Failure of Feature B, C, D, and E
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

bool WMP fails ;
double FDSensor ;
bool RF TMS M 2 ;
bool C p r e c o n d i t i o n ;
bool E p r e c o n d i t i o n ;
bool BCHARGE M 1 ;
bool WMP precondition ;
bool BCHARGE NOT PT M;
bool FDSensor TMS NOT PT ;
double C B F t p l u s o n e ;
bool B f a i l s ;
bool WMS fails ;
bool C B F t p l u s o n e C 8 ;
bool C B F t p l u s o n e C 7 ;
bool BCHARGE TMP PT 1 ;
bool SF B 1 ;
bool C B F t p l u s o n e E 3 ;
bool C B F t p l u s o n e C 1 ;
bool C f a i l s ;
double BCHARGE;
double CBF t ;
double RF;
bool B p r e c o n d i t i o n ;
bool S M p r e c o n d i t i o n ;
bool RF TMP M 2 ;
bool SS E 6 ;
bool RF M 3 ;
double BF ;
bool BCHARGE NOT PT;

302

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

bool C B F t p l u s o n e D 1 1 ;
bool D p r e c o n d i t i o n ;
bool SF TMS M 1 ;
bool RF C 10 ;
bool C B F t p l u s o n e D 1 3 ;
bool CBF t D 14 ;
double SF ;
bool t o p L e v e l S a t i s f a t i o n ;
bool D f a i l s ;
bool WMS precondition ;
bool S M f a i l s ;
bool BF D 3 ;
double SS ;
bool SF C 5 ;
bool C B F t p l u s o n e B 3 ;
bool BF E 5 ;
bool E f a i l s ;
bool CBF t D 10 ;
bool BCHARGE TMP NOT PT 1 ;
bool FDSensor TMS PT 2 ;
bool BCHARGE TMP NOT PT 2 ;
bool FDSensor TMS PT 1 ;
bool SS D 6 ;
bool V SS ( ) {
return true ;
}
bool V SF ( ) {
return true ;
}
bool V BCHARGE( ) {
return true ;
}
bool V CBF t ( ) {
return true ;
}
bool V RF ( ) {
return true ;
}
bool V BF ( ) {
return true ;
}
bool V FDSensor ( ) {
return true ;
}
bool V CBF t plus one ( ) {
return true ;
}

303

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

bool TMS PT 1 ( ) {
return ( ( FDSensor < 0 . 0 ) && V FDSensor ( ) ) ;
}
bool TMS PT 2 ( ) {
return ( ( s t d : : abs ( FDSensor − 0 . 0 ) < 0 . 0 0 0 1 ) && V FDSensor ( ) ) ;
}
bool TMS PT( ) {
return ( ( f a l s e | | TMS PT 1 ( ) ) | | TMS PT 2 ( ) ) ;
}
bool TMS M 1 ( ) {
return ( ( s t d : : abs ( SF − 1 . 0 ) < 0 . 0 0 0 1 ) && V SF ( ) ) ;
}
bool TMS M 2 ( ) {
return ( ( s t d : : abs (RF − 0 . 0 ) < 0 . 0 0 0 1 ) && V RF ( ) ) ;
}
bool TMS M( ) {
return ( ( true && TMS M 1 ( ) ) && TMS M 2 ( ) ) ;
}
bool TMS( ) {
return ( ( true && TMS PT( ) ) && TMS M( ) ) ;
}
bool TMS NOT PT( ) {
return ( ( FDSensor > 0 . 0 ) && V FDSensor ( ) ) ;
}
bool WMS( ) {
return ( ( f a l s e | | TMS( ) ) | | TMS NOT PT( ) ) ;
}
bool TMP PT 1 ( ) {
return ( (BCHARGE < 0 . 5 ) && V BCHARGE( ) ) ;
}
bool TMP M 1 ( ) {
return true ;
}
bool TMP M 2 ( ) {
return ( ( ( s t d : : abs (RF − ( C B F t p l u s o n e ∗ 1 . 0 ) ) < 0 . 0 0 0 1 ) &&
V RF ( ) ) && V CBF t plus one ( ) ) ;
}
bool TMP M( ) {
return ( ( true && TMP M 1 ( ) ) && TMP M 2 ( ) ) ;
}
bool TMP( ) {
return ( ( true && TMP PT 1 ( ) ) && TMP M( ) ) ;
}
bool TMP NOT PT 1 ( ) {
return ( (BCHARGE > 0 . 5 ) && V BCHARGE( ) ) ;
}
bool TMP NOT PT 2 ( ) {

304

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

return ( ( s t d : : abs (BCHARGE − 0 . 5 ) < 0 . 0 0 0 1 ) && V BCHARGE( ) ) ;
}
bool TMP NOT PT( ) {
return ( ( true && TMP NOT PT 1 ( ) ) && TMP NOT PT 2 ( ) ) ;
}
bool WMP( ) {
return ( ( f a l s e | | TMP( ) ) | | TMP NOT PT( ) ) ;
}
bool WM( ) {
return ( ( true && WMS( ) ) && WMP( ) ) ;
}
bool NOT PT M( ) {
return ( (BCHARGE < 1 . 0 ) && V BCHARGE( ) ) ;
}
bool M 1 ( ) {
return ( (BCHARGE > 0 . 9 9 ) && V BCHARGE( ) ) ;
}
bool M 2 ( ) {
return true ;
}
bool M 3 ( ) {
return ( ( s t d : : abs (RF − 0 . 0 ) < 0 . 0 0 0 1 ) && V RF ( ) ) ;
}
bool M( ) {
return ( ( ( true && M 1 ( ) ) && M 2 ( ) ) && M 3 ( ) ) ;
}
bool TM PT( ) {
return ( ( true && NOT PT M( ) ) && M( ) ) ;
}
bool NOT PT( ) {
return ( (BCHARGE < 1 . 0 ) && V BCHARGE( ) ) ;
}
bool SM( ) {
return ( ( f a l s e | | TM PT( ) ) | | NOT PT( ) ) ;
}
bool B 1 ( ) {
return ( ( ( s t d : : abs ( SF − C B F t p l u s o n e ) < 0 . 0 0 0 1 ) && V SF ( ) ) &&
V CBF t plus one ( ) ) ;
}
bool B 2 ( ) {
return true ;
}
bool B 3 ( ) {
return ( ( C B F t p l u s o n e > 0 . 0 ) && V CBF t plus one ( ) ) ;
}
bool B( ) {
return ( ( ( true && B 1 ( ) ) && B 2 ( ) ) && B 3 ( ) ) ;

305

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

}
bool C 1 ( ) {
return ( ( C B F t p l u s o n e > 0 . 0 ) && V CBF t plus one ( ) ) ;
}
bool C 5 ( ) {
return ( ( ( s t d : : abs ( SF − ( C B F t p l u s o n e ∗ 0 . 2 ) ) < 0 . 0 0 0 1 ) &&
V SF ( ) ) && V CBF t plus one ( ) ) ;
}
bool C 6 ( ) {
return true ;
}
bool C 7 ( ) {
return ( ( C B F t p l u s o n e > 0 . 2 ) && V CBF t plus one ( ) ) ;
}
bool C 3 ( ) {
return ( ( ( true && C 5 ( ) ) && C 6 ( ) ) && C 7 ( ) ) ;
}
bool C 8 ( ) {
return ( ( C B F t p l u s o n e < 0 . 5 ) && V CBF t plus one ( ) ) ;
}
bool C 9 ( ) {
return true ;
}
bool C 10 ( ) {
return ( ( ( s t d : : abs (RF − ( C B F t p l u s o n e ∗ 0 . 8 ) ) < 0 . 0 0 0 1 ) &&
V RF ( ) ) && V CBF t plus one ( ) ) ;
}
bool C 4 ( ) {
return ( ( ( true && C 8 ( ) ) && C 9 ( ) ) && C 10 ( ) ) ;
}
bool C 2 ( ) {
return ( ( f a l s e | | C 3 ( ) ) | | C 4 ( ) ) ;
}
bool C( ) {
return ( ( true && C 1 ( ) ) && C 2 ( ) ) ;
}
bool A 1 ( ) {
return ( ( f a l s e | | B( ) ) | | C( ) ) ;
}
bool D 2 ( ) {
return true ;
}
bool D 3 ( ) {
return ( (BF > 0 . 0 ) && V BF ( ) ) ;
}
bool D 4 ( ) {
return true ;

306

214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256

}
bool D 10 ( ) {
return ( ( s t d : : abs ( CBF t − 0 . 0 ) < 0 . 0 0 0 1 ) && V CBF t ( ) ) ;
}
bool D 11 ( ) {
return ( ( ( s t d : : abs ( C B F t p l u s o n e − BF) < 0 . 0 0 0 1 ) && V BF ( ) ) &&
V CBF t plus one ( ) ) ;
}
bool D 12a ( ) {
return true ;
}
bool D 8 ( ) {
return ( ( ( true && D 10 ( ) ) && D 11 ( ) ) && D 12a ( ) ) ;
}
bool D 12b ( ) {
return true ;
}
bool D 13 ( ) {
return ( ( s t d : : abs ( C B F t p l u s o n e − 0 . 0 ) < 0 . 0 0 0 1 ) &&
V CBF t plus one ( ) ) ;
}
bool D 14 ( ) {
return ( ( CBF t > 0 . 0 ) && V CBF t ( ) ) ;
}
bool D 9 ( ) {
return ( ( ( true && D 12b ( ) ) && D 13 ( ) ) && D 14 ( ) ) ;
}
bool D 5 ( ) {
return ( ( f a l s e | | D 8 ( ) ) | | D 9 ( ) ) ;
}
bool D 6 ( ) {
return ( ( s t d : : abs ( SS − 1 . 0 ) < 0 . 0 0 0 1 ) && V SS ( ) ) ;
}
bool D 7 ( ) {
return true ;
}
bool D( ) {
return ( ( ( ( ( ( true && D 2 ( ) ) && D 3 ( ) ) && D 4 ( ) ) && D 5 ( ) ) &&
D 6 ( ) ) && D 7 ( ) ) ;
}
bool E 2 ( ) {
return true ;
}
bool E 3 ( ) {
return ( ( ( s t d : : abs ( C B F t p l u s o n e − BF) < 0 . 0 0 0 1 ) && V BF ( ) ) &&
V CBF t plus one ( ) ) ;
}

307

257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302

bool E 4 ( ) {
return true ;
}
bool E 5 ( ) {
return ( (BF > 0 . 0 ) && V BF ( ) ) ;
}
bool E 6 ( ) {
return ( ( SS < 1 . 0 ) && V SS ( ) ) ;
}
bool E 7 ( ) {
return true ;
}
bool E ( ) {
return ( ( ( ( ( ( true && E 2 ( ) ) && E 3 ( ) ) && E 4 ( ) ) && E 5 ( ) ) &&
E 6 ( ) ) && E 7 ( ) ) ;
}
bool A 2 ( ) {
return ( ( f a l s e | | D( ) ) | | E ( ) ) ;
}
bool A( ) {
return ( ( true && A 1 ( ) ) && A 2 ( ) ) ;
}
bool SMF( ) {
return ( ( true && SM( ) ) && A( ) ) ;
}
bool AA( ) {
return ( ( true && WM( ) ) && SMF( ) ) ;
}
bool TMS PT P ( ) {
return ( ( f a l s e | | TMS PT 1 ( ) ) | | TMS PT 2 ( ) ) ;
}
bool TMS M P ( ) {
return true ;
}
bool TMS P ( ) {
return ( ( true && TMS PT P ( ) ) && TMS M P ( ) ) ;
}
bool WMS P( ) {
return ( ( f a l s e | | TMS P ( ) ) | | TMS NOT PT( ) ) ;
}
bool TMP M P( ) {
return true ;
}
bool TMP P( ) {
return ( ( true && TMP PT 1 ( ) ) && TMP M P( ) ) ;
}
bool TMP NOT PT P ( ) {

308

303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349

return true ;
}
bool WMP P( ) {
return ( ( f a l s e | | TMP P( ) ) | | TMP NOT PT P ( ) ) ;
}
bool WM P( ) {
return ( ( true && WMS P( ) ) && WMP P( ) ) ;
}
bool M P ( ) {
return ( true && M 1 ( ) ) ;
}
bool TM PT P ( ) {
return ( true && M P ( ) ) ;
}
bool SM P ( ) {
return ( ( f a l s e | | TM PT P ( ) ) | | NOT PT( ) ) ;
}
bool B P ( ) {
return ( true && B 3 ( ) ) ;
}
bool C 3 P ( ) {
return ( true && C 7 ( ) ) ;
}
bool C 4 P ( ) {
return ( true && C 8 ( ) ) ;
}
bool C 2 P ( ) {
return ( ( f a l s e | | C 3 P ( ) ) | | C 4 P ( ) ) ;
}
bool C P ( ) {
return ( ( true && C 1 ( ) ) && C 2 P ( ) ) ;
}
bool A 1 P ( ) {
return ( ( f a l s e | | B P ( ) ) | | C P ( ) ) ;
}
bool D 8 P ( ) {
return ( true && D 10 ( ) ) ;
}
bool D 9 P ( ) {
return ( true && D 14 ( ) ) ;
}
bool D 5 P ( ) {
return ( ( f a l s e | | D 8 P ( ) ) | | D 9 P ( ) ) ;
}
bool D P ( ) {
return ( ( ( true && D 3 ( ) ) && D 5 P ( ) ) && D 6 ( ) ) ;
}

309

350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392

bool E P ( ) {
return ( ( true && E 5 ( ) ) && E 6 ( ) ) ;
}
bool A 2 P ( ) {
return ( ( f a l s e | | D P ( ) ) | | E P ( ) ) ;
}
bool A P ( ) {
return ( ( true && A 1 P ( ) ) && A 2 P ( ) ) ;
}
bool SMF P ( ) {
return ( ( true && SM P ( ) ) && A P ( ) ) ;
}
bool AA P ( ) {
return ( ( true && WM P( ) ) && SMF P ( ) ) ;
}
bool TMS M 1 N ( ) {
return ( ( ! ( s t d : : abs ( SF − 1 . 0 ) < 0 . 0 0 0 1 ) ) && V SF ( ) ) ;
}
bool TMS M 2 N ( ) {
return ( ( ! ( s t d : : abs (RF − 0 . 0 ) < 0 . 0 0 0 1 ) ) && V RF ( ) ) ;
}
bool TMP M 2 N ( ) {
return ( ( ( ! ( s t d : : abs (RF − ( C B F t p l u s o n e ∗ 1 . 0 ) ) < 0 . 0 0 0 1 ) ) &&
V RF ( ) ) && V CBF t plus one ( ) ) ;
}
bool TMP NOT PT 1 N ( ) {
return ( ( ! (BCHARGE > 0 . 5 ) ) && V BCHARGE( ) ) ;
}
bool TMP NOT PT 2 N ( ) {
return ( ( ! ( s t d : : abs (BCHARGE − 0 . 5 ) < 0 . 0 0 0 1 ) ) && V BCHARGE( ) ) ;
}
bool NOT PT M N ( ) {
return ( ( ! (BCHARGE < 1 . 0 ) ) && V BCHARGE( ) ) ;
}
bool M 3 N ( ) {
return ( ( ! ( s t d : : abs (RF − 0 . 0 ) < 0 . 0 0 0 1 ) ) && V RF ( ) ) ;
}
bool B 1 N ( ) {
return ( ( ( ! ( s t d : : abs ( SF − C B F t p l u s o n e ) < 0 . 0 0 0 1 ) ) && V SF ( ) )
&& V CBF t plus one ( ) ) ;
}
bool C 5 N ( ) {
return ( ( ( ! ( s t d : : abs ( SF − ( C B F t p l u s o n e ∗ 0 . 2 ) ) < 0 . 0 0 0 1 ) ) &&
V SF ( ) ) && V CBF t plus one ( ) ) ;
}
bool C 10 N ( ) {

310

393

return ( ( ( ! ( s t d : : abs (RF − ( C B F t p l u s o n e ∗ 0 . 8 ) ) < 0 . 0 0 0 1 ) ) &&
V RF ( ) ) && V CBF t plus one ( ) ) ;

394 }
395 bool D 11 N ( ) {
396
return ( ( ( ! ( s t d : : abs ( C B F t p l u s o n e − BF) < 0 . 0 0 0 1 ) ) && V BF ( ) )
&& V CBF t plus one ( ) ) ;
397 }
398 bool D 13 N ( ) {
399
return ( ( ! ( s t d : : abs ( C B F t p l u s o n e − 0 . 0 ) < 0 . 0 0 0 1 ) ) &&
V CBF t plus one ( ) ) ;
400 }
401 bool E 3 N ( ) {
402
return ( ( ( ! ( s t d : : abs ( C B F t p l u s o n e − BF) < 0 . 0 0 0 1 ) ) && V BF ( ) )
&& V CBF t plus one ( ) ) ;
403 }
404 bool TMS PT PP ( ) {
405
return ( ( f a l s e | | TMS PT 1 ( ) ) | | TMS PT 2 ( ) ) ;
406 }
407 bool TMS M PP( ) {
408
return ( true && ( ( f a l s e | | TMS M 1 N ( ) ) | | TMS M 2 N ( ) ) ) ;
409 }
410 bool TMS PP( ) {
411
return ( ( true && TMS PT PP ( ) ) && TMS M PP( ) ) ;
412 }
413 bool WMS PP( ) {
414
return ( ( f a l s e | | TMS PP( ) ) | | TMS NOT PT( ) ) ;
415 }
416 bool TMP M PP( ) {
417
return ( true && ( f a l s e | | TMP M 2 N ( ) ) ) ;
418 }
419 bool TMP PP( ) {
420
return ( ( true && TMP PT 1 ( ) ) && TMP M PP( ) ) ;
421 }
422 bool TMP NOT PT PP( ) {
423
return ( true && ( ( f a l s e | | TMP NOT PT 1 N ( ) ) | | TMP NOT PT 2 N
() ) ) ;
424 }
425 bool WMP PP( ) {
426
return ( ( f a l s e | | TMP PP( ) ) | | TMP NOT PT PP( ) ) ;
427 }
428 bool WM PP( ) {
429
return ( ( true && WMS PP( ) ) && WMP PP( ) ) ;
430 }
431 bool M PP( ) {
432
return ( ( true && M 1 ( ) ) && ( f a l s e | | M 3 N ( ) ) ) ;
433 }
434 bool TM PT PP ( ) {

311

435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481

return ( ( true && M PP( ) ) && ( f a l s e | | NOT PT M N ( ) ) ) ;
}
bool SM PP ( ) {
return ( ( f a l s e | | TM PT PP ( ) ) | | NOT PT( ) ) ;
}
bool B PP ( ) {
return ( ( true && B 3 ( ) ) && ( f a l s e | | B 1 N ( ) ) ) ;
}
bool C 3 PP ( ) {
return ( ( true && C 7 ( ) ) && ( f a l s e | | C 5 N ( ) ) ) ;
}
bool C 4 PP ( ) {
return ( ( true && C 8 ( ) ) && ( f a l s e | | C 10 N ( ) ) ) ;
}
bool C 2 PP ( ) {
return ( ( f a l s e | | C 3 PP ( ) ) | | C 4 PP ( ) ) ;
}
bool C PP ( ) {
return ( ( true && C 1 ( ) ) && C 2 PP ( ) ) ;
}
bool A 1 PP ( ) {
return ( ( f a l s e | | B PP ( ) ) | | C PP ( ) ) ;
}
bool D 8 PP ( ) {
return ( ( true && D 10 ( ) ) && ( f a l s e | | D 11 N ( ) ) ) ;
}
bool D 9 PP ( ) {
return ( ( true && D 14 ( ) ) && ( f a l s e | | D 13 N ( ) ) ) ;
}
bool D 5 PP ( ) {
return ( ( f a l s e | | D 8 PP ( ) ) | | D 9 PP ( ) ) ;
}
bool D PP ( ) {
return ( ( ( true && D 3 ( ) ) && D 5 PP ( ) ) && D 6 ( ) ) ;
}
bool E PP ( ) {
return ( ( ( true && E 5 ( ) ) && E 6 ( ) ) && ( f a l s e | | E 3 N ( ) ) ) ;
}
bool A 2 PP ( ) {
return ( ( f a l s e | | D PP ( ) ) | | E PP ( ) ) ;
}
bool A PP ( ) {
return ( ( true && A 1 PP ( ) ) && A 2 PP ( ) ) ;
}
bool SMF PP ( ) {
return ( ( true && SM PP ( ) ) && A PP ( ) ) ;
}

312

482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528

bool AA PP ( ) {
return ( ( true && WM PP( ) ) && SMF PP ( ) ) ;
}
bool AA Contributes ( ) {
return AA( ) ;
}
bool WM Contributes ( ) {
return (WM( ) && AA Contributes ( ) ) ;
}
bool WMS Contributes ( ) {
return WMS( ) ;
}
bool TMS Contributes ( ) {
return (TMS( ) && WMS Contributes ( ) ) ;
}
bool TMS PT Contributes ( ) {
return (TMS PT( ) && TMS Contributes ( ) ) ;
}
bool TMS PT 1 Contributes ( ) {
return ( TMS PT 1 ( ) && TMS PT Contributes ( ) ) ;
}
bool TMS PT 2 Contributes ( ) {
return ( TMS PT 2 ( ) && TMS PT Contributes ( ) ) ;
}
bool TMS M Contributes ( ) {
return (TMS M( ) && TMS Contributes ( ) ) ;
}
bool TMS M 1 Contributes ( ) {
return (TMS M 1 ( ) && TMS M Contributes ( ) ) ;
}
bool TMS M 2 Contributes ( ) {
return (TMS M 2 ( ) && TMS M Contributes ( ) ) ;
}
bool TMS NOT PT Contributes ( ) {
return (TMS NOT PT( ) && WMS Contributes ( ) ) ;
}
bool WMP Contributes ( ) {
return WMP( ) ;
}
bool TMP Contributes ( ) {
return (TMP( ) && WMP Contributes ( ) ) ;
}
bool TMP PT 1 Contributes ( ) {
return (TMP PT 1 ( ) && TMP Contributes ( ) ) ;
}
bool TMP M Contributes ( ) {
return (TMP M( ) && TMP Contributes ( ) ) ;

313

529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575

}
bool TMP M 1 Contributes ( ) {
return (TMP M 1 ( ) && TMP M Contributes ( ) ) ;
}
bool TMP M 2 Contributes ( ) {
return (TMP M 2 ( ) && TMP M Contributes ( ) ) ;
}
bool TMP NOT PT Contributes ( ) {
return (TMP NOT PT( ) && WMP Contributes ( ) ) ;
}
bool TMP NOT PT 1 Contributes ( ) {
return (TMP NOT PT 1 ( ) && TMP NOT PT Contributes ( ) ) ;
}
bool TMP NOT PT 2 Contributes ( ) {
return (TMP NOT PT 2 ( ) && TMP NOT PT Contributes ( ) ) ;
}
bool SMF Contributes ( ) {
return (SMF( ) && AA Contributes ( ) ) ;
}
bool SM Contributes ( ) {
return SM( ) ;
}
bool TM PT Contributes ( ) {
return (TM PT( ) && SM Contributes ( ) ) ;
}
bool NOT PT M Contributes ( ) {
return (NOT PT M( ) && TM PT Contributes ( ) ) ;
}
bool M Contributes ( ) {
return (M( ) && TM PT Contributes ( ) ) ;
}
bool M 1 C o n t r i b u t e s ( ) {
return ( M 1 ( ) && M Contributes ( ) ) ;
}
bool M 2 C o n t r i b u t e s ( ) {
return ( M 2 ( ) && M Contributes ( ) ) ;
}
bool M 3 C o n t r i b u t e s ( ) {
return ( M 3 ( ) && M Contributes ( ) ) ;
}
bool NOT PT Contributes ( ) {
return (NOT PT( ) && SM Contributes ( ) ) ;
}
bool A C o n t r i b u t e s ( ) {
return (A( ) && SMF Contributes ( ) ) ;
}
bool A 1 C o n t r i b u t e s ( ) {

314

576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622

return ( A 1 ( ) && A C o n t r i b u t e s ( ) ) ;
}
bool B C o n t r i b u t e s ( ) {
return B( ) ;
}
bool B 1 C o n t r i b u t e s ( ) {
return ( B 1 ( ) && B C o n t r i b u t e s ( ) ) ;
}
bool B 2 C o n t r i b u t e s ( ) {
return ( B 2 ( ) && B C o n t r i b u t e s ( ) ) ;
}
bool B 3 C o n t r i b u t e s ( ) {
return ( B 3 ( ) && B C o n t r i b u t e s ( ) ) ;
}
bool C C o n t r i b u t e s ( ) {
return C( ) ;
}
bool C 1 C o n t r i b u t e s ( ) {
return ( C 1 ( ) && C C o n t r i b u t e s ( ) ) ;
}
bool C 2 C o n t r i b u t e s ( ) {
return ( C 2 ( ) && C C o n t r i b u t e s ( ) ) ;
}
bool C 3 C o n t r i b u t e s ( ) {
return ( C 3 ( ) && C 2 C o n t r i b u t e s ( ) ) ;
}
bool C 5 C o n t r i b u t e s ( ) {
return ( C 5 ( ) && C 3 C o n t r i b u t e s ( ) ) ;
}
bool C 6 C o n t r i b u t e s ( ) {
return ( C 6 ( ) && C 3 C o n t r i b u t e s ( ) ) ;
}
bool C 7 C o n t r i b u t e s ( ) {
return ( C 7 ( ) && C 3 C o n t r i b u t e s ( ) ) ;
}
bool C 4 C o n t r i b u t e s ( ) {
return ( C 4 ( ) && C 2 C o n t r i b u t e s ( ) ) ;
}
bool C 8 C o n t r i b u t e s ( ) {
return ( C 8 ( ) && C 4 C o n t r i b u t e s ( ) ) ;
}
bool C 9 C o n t r i b u t e s ( ) {
return ( C 9 ( ) && C 4 C o n t r i b u t e s ( ) ) ;
}
bool C 1 0 C o n t r i b u t e s ( ) {
return ( C 10 ( ) && C 4 C o n t r i b u t e s ( ) ) ;
}

315

623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669

bool A 2 C o n t r i b u t e s ( ) {
return ( A 2 ( ) && A C o n t r i b u t e s ( ) ) ;
}
bool D C o n t r i b u t e s ( ) {
return D( ) ;
}
bool D 2 C o n t r i b u t e s ( ) {
return ( D 2 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool D 3 C o n t r i b u t e s ( ) {
return ( D 3 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool D 4 C o n t r i b u t e s ( ) {
return ( D 4 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool D 5 C o n t r i b u t e s ( ) {
return ( D 5 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool D 8 C o n t r i b u t e s ( ) {
return ( D 8 ( ) && D 5 C o n t r i b u t e s ( ) ) ;
}
bool D 1 0 C o n t r i b u t e s ( ) {
return ( D 10 ( ) && D 8 C o n t r i b u t e s ( ) ) ;
}
bool D 1 1 C o n t r i b u t e s ( ) {
return ( D 11 ( ) && D 8 C o n t r i b u t e s ( ) ) ;
}
bool D 1 2 a C o n t r i b u t e s ( ) {
return ( D 12a ( ) && D 8 C o n t r i b u t e s ( ) ) ;
}
bool D 9 C o n t r i b u t e s ( ) {
return ( D 9 ( ) && D 5 C o n t r i b u t e s ( ) ) ;
}
bool D 1 2 b C o n t r i b u t e s ( ) {
return ( D 12b ( ) && D 9 C o n t r i b u t e s ( ) ) ;
}
bool D 1 3 C o n t r i b u t e s ( ) {
return ( D 13 ( ) && D 9 C o n t r i b u t e s ( ) ) ;
}
bool D 1 4 C o n t r i b u t e s ( ) {
return ( D 14 ( ) && D 9 C o n t r i b u t e s ( ) ) ;
}
bool D 6 C o n t r i b u t e s ( ) {
return ( D 6 ( ) && D C o n t r i b u t e s ( ) ) ;
}
bool D 7 C o n t r i b u t e s ( ) {
return ( D 7 ( ) && D C o n t r i b u t e s ( ) ) ;

316

670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704

}
bool E C o n t r i b u t e s ( ) {
return E ( ) ;
}
bool E 2 C o n t r i b u t e s ( ) {
return ( E 2 ( ) && E C o n t r i b u t e s ( ) ) ;
}
bool E 3 C o n t r i b u t e s ( ) {
return ( E 3 ( ) && E C o n t r i b u t e s ( ) ) ;
}
bool E 4 C o n t r i b u t e s ( ) {
return ( E 4 ( ) && E C o n t r i b u t e s ( ) ) ;
}
bool E 5 C o n t r i b u t e s ( ) {
return ( E 5 ( ) && E C o n t r i b u t e s ( ) ) ;
}
bool E 6 C o n t r i b u t e s ( ) {
return ( E 6 ( ) && E C o n t r i b u t e s ( ) ) ;
}
bool E 7 C o n t r i b u t e s ( ) {
return ( E 7 ( ) && E C o n t r i b u t e s ( ) ) ;
}
void u p d a t e A s s e r t i o n s ( ) {
( TMS PT 1 Contributes ( ) ? ( FDSensor TMS PT 1 = true ) : (
FDSensor TMS PT 1 = f a l s e ) ) ;
( TMS PT 2 Contributes ( ) ? ( FDSensor TMS PT 2 = true ) : (
FDSensor TMS PT 2 = f a l s e ) ) ;
( TMS M 1 Contributes ( ) ? ( SF TMS M 1 = true ) : ( SF TMS M 1 =
false ) ) ;
( TMS M 2 Contributes ( ) ? (RF TMS M 2 = true ) : ( RF TMS M 2 =
false ) ) ;
( TMS NOT PT Contributes ( ) ? ( FDSensor TMS NOT PT = true ) : (
FDSensor TMS NOT PT = f a l s e ) ) ;
( TMP PT 1 Contributes ( ) ? (BCHARGE TMP PT 1 = true ) : (
BCHARGE TMP PT 1 = f a l s e ) ) ;
( TMP M 2 Contributes ( ) ? (RF TMP M 2 = true ) : ( RF TMP M 2 =
false ) ) ;
( TMP NOT PT 1 Contributes ( ) ? (BCHARGE TMP NOT PT 1 = true ) : (
BCHARGE TMP NOT PT 1 = f a l s e ) ) ;
( TMP NOT PT 2 Contributes ( ) ? (BCHARGE TMP NOT PT 2 = true ) : (
BCHARGE TMP NOT PT 2 = f a l s e ) ) ;
( NOT PT M Contributes ( ) ? (BCHARGE NOT PT M = true ) : (
BCHARGE NOT PT M = f a l s e ) ) ;
( M 1 C o n t r i b u t e s ( ) ? (BCHARGE M 1 = true ) : ( BCHARGE M 1 = f a l s e )
);
( M 3 C o n t r i b u t e s ( ) ? ( RF M 3 = true ) : ( RF M 3 = f a l s e ) ) ;

317

705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737 }

( NOT PT Contributes ( ) ? (BCHARGE NOT PT = true ) : ( BCHARGE NOT PT
= false ) ) ;
( B 1 C o n t r i b u t e s ( ) ? ( SF B 1 = true ) : ( SF B 1 = f a l s e ) ) ;
( B 3 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e B 3 = true ) : (
CBF t plus one B 3 = false ) ) ;
( C 1 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e C 1 = true ) : (
CBF t plus one C 1 = false ) ) ;
( C 5 C o n t r i b u t e s ( ) ? ( SF C 5 = true ) : ( SF C 5 = f a l s e ) ) ;
( C 7 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e C 7 = true ) : (
CBF t plus one C 7 = false ) ) ;
( C 8 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e C 8 = true ) : (
CBF t plus one C 8 = false ) ) ;
( C 1 0 C o n t r i b u t e s ( ) ? ( RF C 10 = true ) : ( RF C 10 = f a l s e ) ) ;
( D 3 C o n t r i b u t e s ( ) ? ( BF D 3 = true ) : ( BF D 3 = f a l s e ) ) ;
( D 1 0 C o n t r i b u t e s ( ) ? ( CBF t D 10 = true ) : ( CBF t D 10 = f a l s e ) )
;
( D 1 1 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e D 1 1 = true ) : (
CBF t plus one D 11 = false ) ) ;
( D 1 3 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e D 1 3 = true ) : (
CBF t plus one D 13 = false ) ) ;
( D 1 4 C o n t r i b u t e s ( ) ? ( CBF t D 14 = true ) : ( CBF t D 14 = f a l s e ) )
;
( D 6 C o n t r i b u t e s ( ) ? ( SS D 6 = true ) : ( SS D 6 = f a l s e ) ) ;
( E 3 C o n t r i b u t e s ( ) ? ( C B F t p l u s o n e E 3 = true ) : (
CBF t plus one E 3 = false ) ) ;
( E 5 C o n t r i b u t e s ( ) ? ( BF E 5 = true ) : ( BF E 5 = f a l s e ) ) ;
( E 6 C o n t r i b u t e s ( ) ? ( SS E 6 = true ) : ( SS E 6 = f a l s e ) ) ;
( t o p L e v e l S a t i s f a t i o n = ( (WMS( ) && WMP( ) ) && (SM( ) && ( (B( ) | | C
( ) ) && (D( ) | | E ( ) ) ) ) ) ) ;
( B precondition = B P() ) ;
( C precondition = C P() ) ;
( D precondition = D P() ) ;
( E precondition = E P() ) ;
( S M p r e c o n d i t i o n = SM P ( ) ) ;
( WMP precondition = WMP P( ) ) ;
( WMS precondition = WMS P( ) ) ;
( B f a i l s = B PP ( ) ) ;
( C f a i l s = C PP ( ) ) ;
( D f a i l s = D PP ( ) ) ;
( E f a i l s = E PP ( ) ) ;
( S M f a i l s = SM PP ( ) ) ;
( WMP fails = WMP PP( ) ) ;
( WMS fails = WMS PP( ) ) ;

318

BIBLIOGRAPHY

319

BIBLIOGRAPHY
[1] Raian Ali, Fabiano Dalpiaz, and Paolo Giorgini. Requirements-driven deployment customizing the requirements model for the host environment. Software and System
Modeling, 13(1):433–456, 2014.
[2] Dalal Alrajeh, Jeff Kramer, Axel van Lamsweerde, Alessandra Russo, and Sebastian
Uchitel. Generating obstacle conditions for requirements completeness. In Proceedings
of the 34th International Conference on Software Engineering, pages 705–715. IEEE
Press, 2012.
[3] Zaid Altahat, Tzilla Elrad, Luay Tahat, and Nada Almasri. Detection of syntactic
aspect interaction in UML state diagrams using critical pair analysis in graph transformation. arXiv preprint arXiv:1312.6939, 2013.
[4] Sven Apel, Joanne M. Atlee, Luciano Baresi, and Pamela Zave. Feature Interactions:
The Next Generation (Dagstuhl Seminar 14281). Dagstuhl Reports, 4(7):1–24, 2014.
[5] Sven Apel, Sergiy Kolesnikov, Norbert Siegmund, Christian Kästner, and Brady
Garvin. Exploring feature interactions in the wild: the new feature-interaction challenge. In Proceedings of the 5th International Workshop on Feature-Oriented Software
Development, pages 1–8. ACM, 2013.
[6] Sven Apel, Hendrik Speidel, Philipp Wendler, Alexander Von Rhein, and Dirk Beyer.
Detection of feature interactions using feature-aware verification. In Proceedings of the
2011 26th IEEE/ACM International Conference on Automated Software Engineering,
pages 372–375. IEEE Computer Society, 2011.
[7] Sven Apel, Alexander Von Rhein, Thomas Thüm, and Christian Kästner. Featureinteraction detection based on feature-based specifications. Computer Networks,
57(12):2399–2409, 2013.
[8] João Araújo, Ana Moreira, Isabel Brito, and Awais Rashid. Aspect-oriented requirements with UML. In Workshop on Aspect-oriented Modeling with UML, volume 7.
Citeseer, 2002.
[9] Carlos Areces, Wiet Bouma, and Maarten de Rijke. Feature interaction as a satisfiability problem, 2000.
[10] Silky Arora, Prahladavaradan Sampath, and S Ramesh. Resolving uncertainty in automotive feature interactions. In Requirements Engineering Conference (RE), 2012
20th IEEE International, pages 21–30. IEEE, 2012.
[11] Elisa Baniassad, Paul C Clements, and João Araújo. Discovering early aspects.
320

[12] C. Barrett, A. Stump, and C. Tinelli. The smt-lib Standard: Version 2.0. In Proceedings of the 8th International Workshop on Satisfiability Modulo Theories (Edinburgh,
England), volume 13, 2010.
[13] David Benavides, Sergio Segura, and Antonio Ruiz-Cortés. Automated analysis of
feature models 20 years later: A literature review. Information Systems, 35(6):615–
636, 2010.
[14] Nikolaj Bjørner and Anh-Dung Phan. νz-maximal satisfaction with z3. In SCSS, pages
1–9, 2014.
[15] Nikolaj Bjørner, Anh-Dung Phan, and Lars Fleckenstein. νz-an optimizing smt solver.
In Tools and Algorithms for the Construction and Analysis of Systems, pages 194–199.
Springer, 2015.
[16] Johan Blom, Roland N Bol, and Lars Kempe. Automatic detection of feature interactions in temporal logic. In FIW, pages 1–19, 1995.
[17] Cecylia Bocovich and Joanne M. Atlee. Variable-specific resolutions for feature interactions. In Proceedings of the 22nd ACM SIGSOFT International Symposium on
Foundations of Software Engineering, (FSE-22), Hong Kong, China, November 16 22, 2014, pages 553–563, 2014.
[18] Thomas F Bowen, FS Dworack, Ching-Hua Chow, Nancy Griffeth, Gary E Herman,
and Y-J Lin. The feature interaction problem in telecommunications systems. In
Software Engineering for Telecommunication Switching Systems, 1989. SETSS 89.,
Seventh International Conference on, pages 59–62. IET, 1989.
[19] Isabel Sofia Brito, Ana Moreira, Rita A Ribeiro, and João Araújo. Handling conflicts in aspect-oriented requirements engineering. In Aspect-Oriented Requirements
Engineering, pages 225–241. Springer, 2013.
[20] Muffy Calder, Mario Kolberg, Evan H Magill, and Stephan Reiff-Marganiec. Feature
interaction: a critical review and considered forecast. Computer Networks, 41(1):115–
141, 2003.
[21] Muffy Calder and Alice Miller. Feature interaction detection by pairwise analysis of
ltl properties-a case study. Formal Methods in System Design, 28(3):213–261, 2006.
[22] A Chavan, L Yang, K Ramachandran, and WH Leung. Resolving feature interaction
with precedence lists in the feature language extensions. In ICFI, pages 114–128, 2007.
[23] Betty H. C. Cheng and Joanne M Atlee. Research directions in requirements engineering. In 2007 Future of Software Engineering, pages 285–303. IEEE Computer Society,
2007.
[24] Betty H. C. Cheng, Pete Sawyer, Nelly Bencomo, and Jon Whittle. A goal-based
modeling approach to develop requirements of an adaptive system with environmental
uncertainty. In Model Driven Engineering Languages and Systems, pages 468–483.
Springer, 2009.
321

[25] Ruzanna Chitchyan, Awais Rashid, Pete Sawyer, Alessandro Garcia, M Pinto Alarcon,
Jethro Bakker, Bedir Tekinerdogan, Siobhán Clarke, and Andrew Jackson. Survey of
aspect-oriented analysis and design approaches. 2015.
[26] Andreas Classen, Patrick Heymans, Pierre-Yves Schobbens, and Axel Legay. Symbolic
model checking of software product lines. In Proceedings of the 33rd International
Conference on Software Engineering, pages 321–330. ACM, 2011.
[27] David R Cok. The SMT-LIBv2 language and tools: A tutorial. Language C, pages
2010–2011, 2011.
[28] Thomas H Cormen. Introduction to algorithms. MIT press, 2009.
[29] Michael A Cusumano. Reflections on the toyota debacle. Communications of the ACM,
54(1):33–35, 2011.
[30] Fabiano Dalpiaz, Alexander Borgida, Jennifer Horkoff, and John Mylopoulos. Runtime
goal models: Keynote. In Research Challenges in Information Science (RCIS), 2013
IEEE Seventh International Conference on, pages 1–11. IEEE, 2013.
[31] Robert Darimont and Axel van Lamsweerde. Formal refinement patterns for goaldriven requirements elaboration. In ACM SIGSOFT Software Engineering Notes, volume 21, pages 179–190. ACM, 1996.
[32] Leonardo De Moura and Nikolaj Bjørner. Z3: An efficient SMT solver. In Tools and
Algorithms for the Construction and Analysis of Systems, pages 337–340. Springer,
2008.
[33] Leonardo De Moura and Nikolaj Bjørner. Satisfiability modulo theories: introduction
and applications. Communications of the ACM, 54(9):69–77, 2011.
[34] Kalyanmoy Deb. Multi-objective optimization using evolutionary algorithms. Wiley,
2005.
[35] Kalyanmoy Deb and Ram B Agrawal. Simulated binary crossover for continuous search
space. Complex Systems, 9(3):1–15, 1994.
[36] Kalyanmoy Deb, Amrit Pratap, Sameer Agarwal, and T. Meyarivan. A fast and elitist multiobjective genetic algorithm: NSGA-II. IEEE Transactions on Evolutionary
Computation, 6(2):182–197, 2002.
[37] Byron DeVries and Betty H. C. Cheng. Automatic detection of incomplete requirements via symbolic analysis. In 19th International Conference on Model Driven Engineering Languages and Systems, MODELS 2016, Proceedings, Saint-Malo, France,
October 2-7, pages 385–395. ACM, 2016.
[38] Byron DeVries and Betty H. C. Cheng. Automatic detection of incomplete requirements using symbolic analysis and evolutionary computation. In International Symposium on Search Based Software Engineering, pages 49–64. Springer, 2017.
322

[39] Byron DeVries and Betty H. C. Cheng. Using models at run time to detect incomplete
and inconsistent requirements. In Proceedings of the 21th International Workshop
on Models@run.time co-located with 20th International Conference on Model Driven
Engineering Languages and Systems (MODELS 2017), Austin, Texas, September 18,
2017.
[40] Byron DeVries and Betty H. C. Cheng. Automatic detection of feature interactions
using symbolic analysis and evolutionary computation (in review). In Submitted for
Publication, 2018.
[41] Alma L Juarez Dominguez. Detection of feature interactions in automotive active
safety features. PhD thesis, University of Waterloo, 2012.
[42] Rémi Douence, Pascal Fradet, and Mario Südholt. A framework for the detection and
resolution of aspect interactions. In International Conference on Generative Programming and Component Engineering, pages 173–188. Springer, 2002.
[43] Agoston E Eiben and James E Smith. Introduction to evolutionary computing, volume 53. Springer, 2003.
[44] Alessandro Fantechi, Stefania Gnesi, and Laura Semini. Optimizing feature interaction
detection. In Critical Systems: Formal Methods and Automated Verification, pages
201–216. Springer, 2017.
[45] Martin S Feather, Stephen Fickas, Axel van Lamsweerde, and Cristophe Ponsard.
Reconciling system requirements and runtime behavior. In Proceedings of the 9th
international workshop on Software specification and design, page 50. IEEE Computer
Society, 1998.
[46] Alessio Ferrari, Felice dell’Orletta, Giorgio Oronzo Spagnolo, and Stefania Gnesi. Measuring and improving the completeness of natural language requirements. In Requirements Engineering: Foundation for Software Quality, pages 23–38. Springer, 2014.
[47] Stephen Fickas and Martin S Feather. Requirements monitoring in dynamic environments. In Requirements Engineering, Proceedings of the Second IEEE International
Symposium on, pages 140–147. IEEE, 1995.
[48] Erik M Fredericks, Byron DeVries, and Betty H. C. Cheng. Towards run-time adaptation of test cases for self-adaptive systems in the face of uncertainty. In Proceedings
of the 9th International Symposium on Software Engineering for Adaptive and SelfManaging Systems, pages 17–26. ACM, 2014.
[49] Erik M Fredericks, Byron DeVries, and Betty HC Cheng. Autorelax: automatically relaxing a goal model to address uncertainty. Empirical Software Engineering,
19(5):1466–1501, 2014.
[50] David Garlan, S-W Cheng, A-C Huang, Bradley Schmerl, and Peter Steenkiste.
Rainbow: Architecture-based self-adaptation with reusable infrastructure. Computer,
37(10):46–54, 2004.
323

[51] DE Goldberg. Genetic algorithms in search, optimization, and machine learning,
addison-wesley, reading, ma, 1989.
[52] Heather J Goldsby and Betty H. C. Cheng. Automatically discovering properties that
specify the latent behavior of UML models. In Model Driven Engineering Languages
and Systems, pages 316–330. Springer, 2010.
[53] Nancy D Griffeth and Hugo Velthuijsen. The negotiating agents approach to runtime
feature interaction resolution. In FIW, pages 217–235, 1994.
[54] Mark Harman, S Afshin Mansouri, and Yuanyuan Zhang. Search-based software engineering: Trends, techniques and applications. ACM Computing Surveys (CSUR),
45(1):11, 2012.
[55] Jonathan D. Hay and Joanne M. Atlee. Composing features and resolving interactions.
In Proceedings of the 8th ACM SIGSOFT International Symposium on Foundations of
Software Engineering: Twenty-first Century Applications, SIGSOFT ’00/FSE-8, pages
110–119, New York, NY, USA, 2000. ACM.
[56] Mats PE Heimdahl and Nancy G Leveson. Completeness and consistency in hierarchical state-based requirements. Software Engineering, IEEE Transactions on, 22(6):363–
377, 1996.
[57] Russell Impagliazzo and Ramamohan Paturi. Complexity of k-sat. In Computational
Complexity, 1999. Proceedings. Fourteenth Annual IEEE Conference on, pages 237–
240. IEEE, 1999.
[58] Michael Jackson and Pamela Zave. Distributed feature composition: A virtual architecture for telecommunications services. IEEE Trans. Softw. Eng., 24(10):831–847,
October 1998.
[59] Praveen Jayaraman, Jon Whittle, Ahmed M Elkhodary, and Hassan Gomaa. Model
composition in product lines and feature interaction detection using critical pair analysis. In Model Driven Engineering Languages and Systems, pages 151–165. Springer,
2007.
[60] Adam C Jensen, Betty H. C. Cheng, Heather J Goldsby, and Edward C Nelson. A
toolchain for the detection of structural and behavioral latent system properties. In
Model Driven Engineering Languages and Systems, pages 683–698. Springer, 2011.
[61] Martin Fagereng Johansen, Øystein Haugen, Franck Fleurey, Erik Carlson, Jan Endresen, and Tormod Wien. A technique for agile and automatic interaction testing for
product lines. In Testing Software and Systems, pages 39–54. Springer, 2012.
[62] Richard M Karp. Reducibility among combinatorial problems. Springer, 1972.
[63] Phil Koopman. A case study of Toyota unintended acceleration and software safety.
Presentation. Sept, 2014.
324

[64] Alexei Lapouchnian and John Mylopoulos. Modeling domain variability in requirements engineering with contexts. In International Conference on Conceptual Modeling,
pages 115–130. Springer, 2009.
[65] Edward A Lee. Cyber physical systems: Design challenges. In Object oriented realtime distributed computing (isorc), 2008 11th ieee international symposium on, pages
363–369. IEEE, 2008.
[66] Joel Lehman and Kenneth O Stanley. Abandoning objectives: Evolution through the
search for novelty alone. Evolutionary computation, 19(2):189–223, 2011.
[67] Nancy Leveson. Completeness in formal specification language design for processcontrol systems. In Proceedings of the Third Workshop on Formal methods in software
practice, pages 75–87. ACM, 2000.
[68] Marcilio Mendonca, Andrzej Wąsowski, and Krzysztof Czarnecki. Sat-based analysis
of feature models is easy. In Proceedings of the 13th International Software Product
Line Conference, pages 231–240. Carnegie Mellon University, 2009.
[69] Igor Menzel, Mark Mueller, Anne Gross, and Joerg Doerr. An experimental comparison
regarding the completeness of functional requirements specifications. In Requirements
Engineering Conference (RE), 2010 18th IEEE International, pages 15–24. IEEE, 2010.
[70] Melanie Mitchell. An introduction to genetic algorithms. MIT press, 1998.
[71] Gunter Mussbacher, Jon Whittle, and Daniel Amyot. Towards semantic-based aspect
interaction detection. 1st Intl. Wksh. on Non-functional System Properties in Domain
Specific Modeling Languages (NFPinDSML2008), 2008.
[72] Gunter Mussbacher, Jon Whittle, and Daniel Amyot. Semantic-based interaction detection in aspect-oriented scenarios. In 2009 17th IEEE International Requirements
Engineering Conference, pages 203–212. IEEE, 2009.
[73] Gunter Mussbacher, Jon Whittle, and Daniel Amyot. Modeling and detecting semanticbased interactions in aspect-oriented scenarios. Requirements Engineering, 15(2):197–
214, 2010.
[74] M Nakamura and S Reiff-Marganiec. Semantic-based aspect interaction detection with
goal models (position paper). Feature Interactions in Software and Communication
Systems X, page 176, 2009.
[75] Andres J Ramirez and Betty H. C. Cheng. Automatic derivation of utility functions
for monitoring software requirements. In Model Driven Engineering Languages and
Systems, pages 501–516. Springer, 2011.
[76] Silvio Ranise and Cesare Tinelli. The SMT-LIB standard: Version 1.2. Technical
report, Technical report, Department of Computer Science, The University of Iowa,
2006. Available at www. SMT-LIB. org, 2006.
325

[77] Awais Rashid, Peter Sawyer, Ana Moreira, and João Araújo. Early aspects: A model
for aspect-oriented requirements engineering. In Requirements Engineering, 2002. Proceedings. IEEE Joint International Conference on, pages 199–202. IEEE, 2002.
[78] William N Robinson. Monitoring software requirements using instrumented code. In
System Sciences, 2002. HICSS. Proceedings of the 35th Annual Hawaii International
Conference on, pages 3967–3976. IEEE, 2002.
[79] Américo Sampaio, Ruzanna Chitchyan, Awais Rashid, and Paul Rayson. Ea-miner: a
tool for automating aspect-oriented requirements identification. In Proceedings of the
20th IEEE/ACM international Conference on Automated software engineering, pages
352–355. ACM, 2005.
[80] Alberto Sardinha, Ruzanna Chitchyan, João Araújo, Ana Moreira, and Awais Rashid.
Conflict identification with ea-analyzer. In Aspect-Oriented Requirements Engineering,
pages 209–224. Springer, 2013.
[81] VĹ́tor E Silva Souza, Alexei Lapouchnian, William N Robinson, and John Mylopoulos.
Awareness requirements for adaptive systems. In Proceedings of the 6th international
symposium on Software engineering for adaptive and self-managing systems, pages 60–
69. ACM, 2011.
[82] Jean Souyris, Virginie Wiels, David Delmas, and Hervé Delseny. Formal verification
of avionics software products. In International Symposium on Formal Methods, pages
532–546. Springer, 2009.
[83] VĹ́tor E Silva Souza, Alexei Lapouchnian, William N Robinson, and John Mylopoulos.
Awareness requirements. In Software Engineering for Self-Adaptive Systems II, pages
133–161. Springer, 2013.
[84] Sahil Thaker, Don Batory, David Kitchin, and William Cook. Safe composition of
product lines. In Proceedings of the 6th international conference on Generative programming and component engineering, pages 95–104. ACM, 2007.
[85] Sebastian Uchitel and Marsha Chechik. Merging partial behavioural models. In ACM
SIGSOFT Software Engineering Notes, volume 29, pages 43–52. ACM, 2004.
[86] Rob van der Linden. Using an architecture to help beat feature interaction. In FIW,
pages 24–35, 1994.
[87] Axel van Lamsweerde et al. Requirements engineering: from system goals to UML
models to software specifications. Wiley, 2009.
[88] John Viega and Jeffrey Voas. Can aspect-oriented programming lead to more reliable
software? IEEE Software, 17(6):19, 2000.
[89] William E Walsh, Gerald Tesauro, Jeffrey O Kephart, and Rajarshi Das. Utility functions in autonomic systems. In Proceedings of the International Conference on Autonomic Computing, pages 70–77. IEEE, 2004.
326

[90] Nathan Weston, Francois Taiani, and Awais Rashid. Interaction analysis for faulttolerance in aspect-oriented programming. 2007.
[91] Jon Whittle and Praveen Jayaraman. Mata: A tool for aspect-oriented modeling based
on graph transformation. In International Conference on Model Driven Engineering
Languages and Systems, pages 16–27. Springer, 2007.
[92] Jon Whittle, Pete Sawyer, Nelly Bencomo, and Betty H. C. Cheng. A language for
self-adaptive system requirements. In Service-Oriented Computing: Consequences for
Engineering Requirements, 2008. SOCCER’08. International Workshop on, pages 24–
29. IEEE, 2008.
[93] Jon Whittle, Pete Sawyer, Nelly Bencomo, Betty H. C. Cheng, and Jean-Michel Bruel.
Relax: a language to address uncertainty in self-adaptive systems requirement. Requirements Engineering, 15(2):177–196, 2010.
[94] Jon Whittle, Pete Sawyer, Nelly Bencomo, Betty HC Cheng, and Jean-Michel Bruel.
Relax: Incorporating uncertainty into the specification of self-adaptive systems. In
Requirements Engineering Conference, 2009. RE’09. 17th IEEE International, pages
79–88. IEEE, 2009.
[95] Eric Yu. Modelling strategic relationships for process reengineering. Social Modeling
for Requirements Engineering, 11:2011, 2011.
[96] Eric SK Yu. Towards modelling and reasoning support for early-phase requirements
engineering. In Requirements Engineering, 1997., Proceedings of the Third IEEE International Symposium on, pages 226–235. IEEE, 1997.
[97] Yijun Yu, Julio CSP Leite, and John Mylopoulos. From goals to aspects: discovering
aspects from requirements goal models. In Requirements Engineering Conference, 2004.
Proceedings. 12th IEEE International, pages 38–47. IEEE, 2004.
[98] Marina MN Zenun and Geilson Loureiro. A framework for dependability and completeness in requirements engineering. In Latin American Symposium on Dependable
Computing, pages 1–4, 2013.
[99] Yuanyuan Zhang, Anthony Finkelstein, and Mark Harman. Search based requirements
optimisation: Existing work and challenges. In International Working Conference on
Requirements Engineering: Foundation for Software Quality, pages 88–94, 2008.
[100] M Hadi Zibaeenejad, Chi Zhang, and Joanne M Atlee. Continuous variable-specific
resolutions of feature interactions. In Proceedings of the 2017 11th Joint Meeting on
Foundations of Software Engineering, ESEC/FSE, pages 408–418. ACM, 2017.

327