Fakultät II
Department für Informatik
Eingebettete Hardware-/Software Systeme

A Linear Scaling Change Impact Analysis
Based on a Formal Safety Model for
Automotive Embedded Systems

Von der Fakultät für Informatik, Wirtschafts und
Rechtswissenschaften der Carl von Ossietzky Universität Oldenburg
zur Erlangung des Grades und Titels eines
Doktors der Ingenieurswissenschaften (Dr.-Ing.)
angenommene Dissertation von
Dipl. Inf. Markus Oertel
geboren am 11.05.1984 in Bielefeld

Gutachter:
Prof. Dr. Achim Rettberg

Weitere Gutachter:
Prof. Dr. Bernhard Josko
Prof. Dr. Marcelo Götz

Tag der Disputation: 2. September 2016©
B

2016 by Markus Oertel
markus@bauoer.deZusammenfassung
Die Kosten für Verifikations- und Validierungsaktivitäten eines sicherheitskritischen
eingebetteten Systems können bis zu 70% der gesamten Entwicklungskosten betragen.
Da Systeme in der Automobilbranche selten von Grund auf neu entwickelt werden,
sondern bestehende Systeme modifiziert und erweitert werden, ist es nachteilig, dass die
Auswirkungen von Änderungen auf die Sicherheit des Systems nicht präzise identifiziert
werden können. Aus diesem Grund ist häufig eine erneute Verifikation des gesamten
Systems notwendig, selbst bei minimalen Änderungen. Weitere Anpassungen, die zusätzlich zur initialen Modifikation durchgeführt werden müssen, um ein operables undsicheres System zu erhalten, sind verantwortlich für diese teure Verifikationsstrategie.
Impact-Analyse-Techniken existieren für Software oder im Bereich der Avionik, welche
jedoch nicht auf die Automobilbranche übertragbar sind, entweder, weil die Systeme zum
Zeitpunkt der Erstellung der Sicherheitskonzepte noch nicht implementiert sind, oder weil
die in der Luftfahrtbranche üblichen Isolationsmechanismen und zunächst überdimensionierten Ressourcen fehlen. In dieser Arbeit wird eine neue Impact Analyse vorgestellt,
die einen linearen Zusammenhang zwischen dem Verifikationsaufwand und der Größe derÄnderung herstellt wobei die Sicherheit des Systems weiterhin garantiert werden kann.
Darüberhinaus kann der Ansatz den Entwickler bei der Auswahl weiterer Komponenten
zur Kompensation einer Änderung unterstützen. In einigen Situationen können potenzielleÄnderungen an einer Implementation durch eine oder mehrere Änderungen an Anforderungen ersetzt werden, um so Kosten einzusparen. Die Impact-Analyse basiert auf einem
formalen Sicherheitsmodell, welches Contracts benutzt um das Fehlerfortpflanzungsverhalten und die Sicherheitsmechanismen zu beschreiben. Die Beschreibungssprache wurde
konform zu den Anforderungen der ISO 26262, dem aktuellen funktionalen Sicherheitsstandard der Automobilbranche, entwickelt. Im Gegensatz zu existierenden Ansätzen ist
ein Abstraktionsmechanismus integriert, welcher eine Top-Down-Entwicklung des Systems
ermöglicht. So behalten die bereits erzielten Verifikationsergebnisse ihre Gültigkeit, selbst
wenn die Spezifikation und die Architektur im Verlauf der Entwicklung verfeinert werden.
Um die Benutzung der Sprache zu vereinfachen werden Templates für die gängigen Sicherheitsmechanismen bereitgestellt und ein Anwendungsleitfaden angeboten. Die Semantik
der Sprache ist formal definiert um automatische Analysen zu ermöglichen. Es wird beschrieben, wie die Korrektheit einer Anforderungsverfeinerung sichergestellt werden kann,und wie analysiert wird, ob eine Implementation den Sicherheitsanforderungen entspricht.
Die Impact-Analyse wird anhand einer Fallstudie evaluiert um die Ausdrucksstärke undAnwendbarkeit des Ansatzes zu demonstrieren. Damit die Effektivität der neuen Impact
Analyse mit dem aktuell praktizierten Ansatz der kompletten Neuverifikation quantitativ
verglichen werden kann wurde ein stochastisches Simulationsframework entwickelt. In
dieser Simulation werden beide Methoden im Hinblick auf verschiedene Parameter wie die
Größe des Systems, die Größe der Änderung, die Genauigkeit der Verifikationsaktivität
sowie der resultierende Verifikationsaufwand verglichen. So kann eine präzise Bestimmung des optimalen Wirkungsbereichs durchgeführt werden. Darüber hinaus wird eine
Integration der Impact-Analyse in ein verteiltes Entwicklungsszenario präsentiert.

iii

Abstract
The effort for verification and validation activities of safety critical embedded systems
may consume up to 70% of the total development costs. Since automotive systems are
rarely developed from scratch, but are based on existing systems that are modified, it isunfortunate that the impact of changes on the safety of the system cannot precisely be
determined. Therefore, a re-verification of the whole system might be necessary even incase of small changes. Change propagation (i.e., additional necessary modifications tomaintain an operable and safe system) that might occur at even distinct parts of theitem are responsible for this expensive verification strategy. Impact analysis techniques
exist for software or avionic systems but cannot be applied to automotive safety concepts.
Either the system is not yet implemented at the safety concept level or the systems
components do not provide a sufficient degree of isolation and slack. A new impact
analysis is presented in this work that provides a linear relation between the re-verification
effort and the size of the change by still guaranteeing the safety of the device. Furthermore
the developer is supported in the decisions how to compensate a change by modifying
a set of requirements instead of needing to change an implementation. The impact
analysis is based on a formal safety model using contracts to express fault containment
properties and safety mechanisms. The specification means in this model have beendeveloped to cover the needs from functional safety concepts as stated by the current
automotive safety standard ISO 26262. In contrast to other safety specifications weprovide an abstraction technique, which allows the development of a system in a topdown manner. Hence, already performed verification results remain valid even if thespecification and the architecture of the components are refined. To ease the applicabilityof the safety specification language, we provide templates for the most common typesof safety mechanisms as well as application guidelines. The semantics of the language
are formally defined to allow automatic analyses. Therefore, the refinement of safety
requirements can be checked as well as the correctness of an implementation with respect
to the safety specification. We evaluate the impact analysis on a case study to demonstrate
the expressiveness and applicability. To quantify the effectiveness of the new approachcompared with the currently used “re-verify all” technique, a stochastic simulation
framework has been developed. In the simulation both approaches are compared using
multiple parameters such as the size of the system, the size of the change, the accuracy ofthe verification activities or the resulting verification effort. Hence, a precise determinationof the circumstances in which the approach performs best can be determined. In addition
we provide an integration of the change impact analysis in an distributed development
environment.

v

Authors Declaration
Material presented within this thesis has previously been published in the following
articles:• Oertel, M. & Rettberg, A. (2013). Reducing re-verification effort by requirementbased change management. In G. Schirner, M. Götz, A. Rettberg, M. Zanella, &F. Rammig (Eds.), Embedded systems: design, analysis and verification (Vol. 403,
pp. 104–115). IFIP Advances in Information and Communication Technology.
Springer Berlin Heidelberg• Oertel, M., Mahdi, A., Böde, E., & Rettberg, A. (2014). Contract-based safety:
specification and application guidelines. In Proceedings of the 1st international
workshop on emerging ideas and trends in engineering of cyber-physical systems(eitec 2014)• Oertel, M., Gerwinn, S., & Rettberg, A. (2014, July). Simulative evaluation ofcontract-based change management. In Industrial informatics (indin), 2014 12th
ieee international conference on (pp. 16–21)• Oertel, M. & Josko, B. (2012). Interoperable requirements engineering: tool
independent specification, validation and impact analysis. In Artemis technology
conference 2012
• Oertel, M., Kacimi, O., & Böde, E. (2014). Proving compliance of implementation
models to safety specifications. In A. Bondavalli, A. Ceccarelli, & F. Ortmeier(Eds.), Computer safety, reliability, and security (Vol. 8696, pp. 97–107). Lecture
Notes in Computer Science. Springer International Publishing• Oertel, M., Malot, M., Baumgart, A., Becker, J., Bogusch, R., Farfeleder, S., . . .
& Rehkop, P. (2013). Requirements engineering. In A. Rajan & T. Wahl (Eds.),
Cesar - cost-efficient methods and processes for safety-relevant embedded systems(pp. 69–143). Springer Vienna• Oertel, M., Battram, P., Kacimi, O., Gerwinn, S., & Rettberg, A. (2015). A
compositional safety specification using a contract-based design methodology. In
W. Leister & N. Regnesentral (Eds.), Pesaro 2015: the fifth international conferenceon performance, safety and robustness in complex systems and applications (pp. 1–7). IARIA(Best Paper Award Winner)
All the work contained within this thesis represents the original contribution of the author
and only the indicated resources have been used.

vii

Contents
1 Introduction
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Scientific Question and Success Criteria . . . . . . . . . . . . . . . . . . .
1.3 Basic Idea and Contribution . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Assumptions and Scope of the Work . . . . . . . . . . . . . . . . . . . . .
1.5 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1 Embedded Systems, Models and Safety . . . . . . . . . . . . . . .
1.5.2 Fault, Error and Failure . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3 Fault Avoidance, Fault Removal and Fault Tolerance . . . . . . . .
1.5.4 Verification and Validation . . . . . . . . . . . . . . . . . . . . . .
1.5.5 Change and Configuration Management . . . . . . . . . . . . . . .
1.6 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
2
3
4
4
6
6
7
8
8
9
9

2 Fundamentals
2.1 Contract-based Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Trace Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Contract Relations and Operators . . . . . . . . . . . . . . . . . .
2.1.4 Theorems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.5 Contracts in Formulas . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 System Design using Aspects and Perspectives . . . . . . . . . . . . . . .
2.2.1 Structural Organization of the System . . . . . . . . . . . . . . . .
2.2.2 Classification of Dynamic Behavior . . . . . . . . . . . . . . . . . .
2.3 ISO 26262 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Item Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Hazard Analysis and Risk Assessment . . . . . . . . . . . . . . . .
2.3.3 Functional Safety Concept . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 Technical Safety Concept . . . . . . . . . . . . . . . . . . . . . . .

11
11
12
13
13
15
16
17
18
21
23
25
25
26
27

3 Development of a Semantic-based Impact Analysis
29
3.1 Related Work on Impact Analysis Techniques . . . . . . . . . . . . . . . . 31
3.1.1 Impact Analysis without Tracing . . . . . . . . . . . . . . . . . . . 33

ix

Contents

3.2
3.3

3.4
3.5

3.1.2 Explicit Traceability Impact . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Implicit Traceability Impact Analysis . . . . . . . . . . . . . . . .
3.1.4 Impact Analyses using Change Histories . . . . . . . . . . . . . . .
3.1.5 Impact Analyses Avoiding Recertification . . . . . . . . . . . . . .
Gap Identification and Goals for Impact Analysis . . . . . . . . . . . . . .
Impact Analysis on Contract-based System . . . . . . . . . . . . . . . . .
3.3.1 System Representation . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Correctness as a Target for Impact Analysis . . . . . . . . . . . . .
3.3.3 Change Operations . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4 Impact Analysis Process . . . . . . . . . . . . . . . . . . . . . . . .
3.3.5 Supporting the Compensation Candidate Selection . . . . . . . . .
Requirements on a Modular Safety View . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35
38
43
47
50
51
51
58
59
62
68
70
71

4 Development of a Compositional Safety View
75
4.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1.1 Failure Logic Modeling . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1.2 Safety Case Structuring . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.3 Previous work on safety contracts . . . . . . . . . . . . . . . . . . 85
4.2 Gap Analysis and Requirements . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.1 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.2 Specification Needs from ISO 26262 . . . . . . . . . . . . . . . . . 91
4.2.3 Requirement Summary . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.3 A Specification Language Supporting Impact Analysis . . . . . . . . . . . 93
4.3.1 Expressing Assertions using Safety Patterns . . . . . . . . . . . . . 94
4.3.2 Expressing Safety Contracts . . . . . . . . . . . . . . . . . . . . . . 97
4.3.3 Abstract Safety Specifications . . . . . . . . . . . . . . . . . . . . . 102
4.4 Process Guidance on Creating an Initial Architecture . . . . . . . . . . . . 107
4.5 Analysis of Safety Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.5.1 Refinement Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.5.2 Satisfaction Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5 Evaluation
119
5.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.1.1 Specification and Design of the Initial System . . . . . . . . . . . . 120
5.1.2 Changing the System . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.2 Simulative Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.2.1 Simulative Setup for Comparison . . . . . . . . . . . . . . . . . . . 135
5.2.2 Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

x

Contents

6 Prototype Implementations
149
6.1 A Change Impact Analysis Service for Distributed Development Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.1.1 RTP Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6.1.2 Algorithmic Changes for Distributed Development Environments . 152
6.1.3 Change Request Representation . . . . . . . . . . . . . . . . . . . . 154
6.1.4 Using the Change Impact Service . . . . . . . . . . . . . . . . . . . 154
6.2 Checking Safety Contracts with Divine . . . . . . . . . . . . . . . . . . . . 155
6.3 Satisfaction Check of Safety Contracts . . . . . . . . . . . . . . . . . . . . 159
7 Conclusion
163
7.1 Summary of Obtained Results . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.2 Evaluation of Success Criteria . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.3 Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7.4 Future Research Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Bibliography

169

xi

List of Tables
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
4.1
4.2

Traceability matrix to represent the dependencies between requirements.
Source: Sommerville and Sawyer (1997) . . . . . . . . . . . . . . . . . . .
The atomic changes for object oriented call graph based impact analysis
of software. Source: Ryder and Tip (2001) . . . . . . . . . . . . . . . . . .
Notation for inheritance relations. Source: Ryder and Tip (2001) . . . . .
Abstract entities used in the impact analysis process . . . . . . . . . . . .
Tracelinks necessary for our impact analysis . . . . . . . . . . . . . . . . .
Change operations overview. For some operation and target combinations
multiple integration scenarios exist . . . . . . . . . . . . . . . . . . . . . .
Verification activities to be restarted based on the type of change. Additional changes according to Table 3.6 are marked with +/- signs . . . . .
Which elements are considered as compensation candidates . . . . . . . .

35
40
40
53
54
61
64
66

4.3
4.4

Examples for safety requirements in the functional aspect . . . . . . . . . 86
Overview of the four safety patterns as presented in Oertel, Mahdi, Böde,
and Rettberg (2014) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Safety patterns attributes (Oertel, Mahdi, Böde, & Rettberg, 2014) . . . . 90
Description of the malfunction of the component depicted in Figure 4.19 . 114

5.1
5.2
5.3

Malfunctions and functional requirements of the automatic light manager 123
Verification Activities that have to be Re-Run after the initial change . . 128
Verification Activities that have to be Re-Run after the second change . . 131

xiii

List of Figures
1.1

2.1

2.2
2.3
2.4

Relation between the size of the change and the certification effort, according to Fenn et al. (2007) . . . . . . . . . . . . . . . . . . . . . . . . .
Structural organization of the system in perspectives on the example of anaerospace system. Based on Baumgart et al. (2011) and Rajan and Wahl
(2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Classification of dynamic behavior of the system using aspects. . . . . . .
The main development part of the ISO 26262 V-process model. Source:
ISO 26262 (2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relation between the three classification factors resulting in the ASIL of ahazardous event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

19
22
24
26

3.1
3.2

Impact analysis as a discipline within change management . . . . . . . . . 30
Process how to handle inconsistencies according to (Nuseibeh, Easterbrook,& Russo, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Impact analysis process as suggested by Bohner (1996) . . . . . . . . . . . 37
3.4 Impact analysis as provided by current industrial traceability tools . . . . 39
3.5 Definition of lookup and LC. Source: Ryder and Tip (2001) . . . . . . . . 41
3.6 Definition of the affected test drivers TA given a set of change A . . . . . 41
3.7 A graphical product risk matrix. Source: Clarkson, Simons, and Eckert(2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.8 A case risk plot. Source: Clarkson, Simons, and Eckert (2004) . . . . . . . 45
3.9 Influence of sureness and cautious probabilities on total propagation probability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.10 Process of using recovery actions to show equivalence of the new safetyargumentation compared with the one prior to the change, according toNicholson, Conmy, Bate, and McDermid (2000) . . . . . . . . . . . . . . . 49
3.11 A very generic, recursive process of conduction of the impact analysis
within an IMS, according to Nicholson, Conmy, Bate, and McDermid (2000) 49
3.12 Relations between entities involved in the impact analysis . . . . . . . . . 51
3.13 Overview of the System Artifacts and Tracelinks repected by the Impact
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

xv

List of Figures

3.14 Faulty connectors between ports . . . . . . . . . . . . . . . . . . . . . . .
3.15 The verification activities used in the impact analysis process . . . . . . .
3.16 Basic process for handling change requests . . . . . . . . . . . . . . . . . .
3.17 Illustration of the possible change propagation paths, according to theused verification activities Vs , Vi , Vr . . . . . . . . . . . . . . . . . . . . . .
3.18 Slack introduced intentionally (ECU1) and unintentionally (ECU2) asa resource. The values indicate the percentage used of the available
ressources one level above. . . . . . . . . . . . . . . . . . . . . . . . . . . .

56
57
62
67

69

4.1

Example component and failure logic table. Source: Papadopoulos andMaruhn (2001) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2 Relation of hierarchical models and HAZOP analyses with generated fault
trees. Source: Papadopoulos and Maruhn (2001) . . . . . . . . . . . . . . 78
4.3 Basic fault transformation rules in FPTC. Source: Wallace (2005) . . . . 79
4.4 Transformation rules in FPTC for multiple ports. Source: Wallace (2005) 80
4.5 Multiple componenet fault trees combined to a system . . . . . . . . . . . 81
4.6 Principal element of the goal structure notation according to GSN Community Standard (2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.7 Links in the goal structure notation according to GSN Community Standard (2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.8 Overview of hierarchical claim structure (Bishop & Bloomfield, 1997) . . . 84
4.9 Model of system failure behavior (Bishop & Bloomfield, 1997) . . . . . . . 85
4.10 Ontology representing the chosen abstraction for describing safety concepts. 92
4.11 Extension of the existing safety pattern grammar with “combination” and“not” operator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.12 Triple modular redundancy (TMR) as an example for a nondegrading
safety mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.13 Immediately degrading safety mechanisms implemented by two redundant
channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.14 Watchdog as an example for a delayed degrading safety mechanism . . . . 101
4.15 All internal faults were “externalized” using fault activation ports . . . . . 103
4.16 Count ports are introduced and fault-splitter components ensure that no
more faults are passed to internal components than specified . . . . . . . 104
4.17 Explicitly represent the counting with boolean logic for LTL implementation. In this example a fault port with the value 2 is represented. . . . . . 107
4.18 Relation of a safety contract to the FTA results of the implementation of
the component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.19 A adder with limited fault tolerance capabilities . . . . . . . . . . . . . . . 113
4.20 Extending the system model to represent input malfunctions . . . . . . . 115
4.21 Automaton for Perm with a given Bound . . . . . . . . . . . . . . . . . . 116
5.1

xvi

Architecture of a temperature sensor required to be robust against singlepoints of failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

List of Figures

5.2

A previously unknown common cause faults damaging both A/D converters
has been identified. To still maintain the safety properties a consistency
check has been integrated. . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.3 Matlab Stateflow implementation of the OVERRIDE Component (bottom
right). To represent the injected input faults additional components havebeen introduced that handle the injection of faults at the input. The input
malfunctions are activated by the corresponding malfunction ports. . . . . 134
5.4 Requirements and implementations are attached to connected components
5.4a and the graph-based representation used in the simulation, wherecomponents are neglected 5.4b . . . . . . . . . . . . . . . . . . . . . . . . 136
5.5 Probability Density Diestribution for the Branching Factor of the generation of the Requirements structure. µ = 3, 5 and σ = 0, 8 . . . . . . . . . . 137
5.6 width=7cm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.7 Effort as a function of the accuracy of the test used. The higher theaccuracy, the higher the associated effort according to equation (5.1) . . . 142
5.8 Results of system consisting 231 requirements and 22 implementations,while changing 13 elements of the system. The sample-size is 1000 . . . . 143
5.9 Difference of detection rates (in %) between the component based approachand the standard approach . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.10 Effort of both approaches at detecting rate 98% (300 Samples). The
contract-based approach is displayed in blue, while the state-of-the-art
approach is depicted in green. . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.11 Comparison of the results for systems of different magnitude. The identified
relative break even point is independent of the absolute system size. The
plots for the break even points are scaled to the relative system size in %. 146
6.1
6.2
6.3
6.4

Overview of the available services in the used RTP instance . . . . . . . . 150
Meta-Model used in the RTP instance . . . . . . . . . . . . . . . . . . . . 151
Overview of the available services in the used RTP instance . . . . . . . . 152
Representation of the current change request in the change impact client
ReMain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.5 Component architecture used as the example to illustrate the refinement
analysis process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.6 Simple example input file stating the top level contract and the subcontracts.156
6.7 Grammar of the safety pattern . . . . . . . . . . . . . . . . . . . . . . . . 157
6.8 One example process from the random model. The input ports (infail inthis case) can be switched at any time. . . . . . . . . . . . . . . . . . . . . 158
6.9 Configuration interface of the MBSA integrated in the SAFE tool platform161
6.10 Configuration of malfunctions using the FailureModeEditor . . . . . . . . 162
6.11 Observer to specify the top level funtional requirement directly in theStateflow model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

xvii

List of Symbols
⊗


|=
←
−
I
→
−
I

Φ

F
→
−
P
←
−
P
p

=
2

[[]]

binary contract parallel composition operator
contract refinement: contract c1 refines c2 iff [[c1 ]] ⊆[[c2 ]]
contract not refinement: contract c1 does not refine
c2 iff [[c1 ]] * [[c2 ]]binary satisfaction operator
Implemented by: returns the implementation for aprovided component
Implements: returns the component that a implementation is connected toFunction returning the functional deviation represented by the expression in the promise of a safetycontract
Function returning the description associated to a
malfunction identifierpart of: function returning the parent component fora provided component
parts: function returning the child component for aprovided component
Port Equivalence: binary relation between ports andsignals matching type and namePorts: Function returning the ports including their
type (if available) for a given implementation or component
Set of traces for a given specification or implementationxix

List of Symbols
←
−
R
→
−
R

→
−
S
←
−
S
S

Vi

Vr

Vs

xx

Refinees: returns the requirements that a given requirement r refined. These are the child requirementsin the requirements-breakdown structure
Refines: returns the requirement that a given requirement r is refining. This is the parent requirement in
the requirements-breakdown structure
Satisfies: returns all requirements that are satisfied
by a given component c
Satisfied by: returns the component that is allocatedto a given requirement r
Signals: Function returning the signals used in arequirement
Interface Analysis: function returning the result of
the interface check, given two argument combinations,a component and a requirement or a component andan implementation
Refinement Analysis: function returning the result of
the refinement check, given two arguments, the toplevel requirements and the set of refined requirements
Satisfaction Analysis: function returning the resultof the satisfaction check, given two arguments, therequirements and the implementation

It is not the strongest of the species
that survive, nor the most intelligent, but the one most responsive tochange.
Charles Darwin

CHAPTER

Introduction
Multiple times a day we put our lives in the hands of computers that control mechanicalor electrical appliances around us. Malfunctions in these embedded systems (Lee & Seshia,2010) introduce risks that are not always obvious. Examples of easily identifiable risks
that appeared in recent media are failures in the control software of a plane engine (Kelion,2015), a car suddenly accelerating at full power (Barr, 2013) or burning batteries ofelectric vehicles (Madslien, 2011). In contrast, the awareness of the potential danger ofan airbag system in a road vehicle is comparatively low, since it is especially designed toprevent harm during a crash. Nevertheless, the unintended deployment of an airbag caneasily lead to a loss of control of the car and potentially to the driver’s death. Special carehas to be taken while designing such safety critical systems (Bozzano & Villafiorita, 2011;
Storey, 1996) to prevent situations in which individuals could be harmed. It can neverbe ensured that a system is safe under all circumstances, but multiple techniques exist
to establish a certain degree of confidence in the safety of a device. One major aspectis an intensive analysis and testing procedure of the system, also in the final context ofuse, to ensure, that the systems (and also its components) behave exactly as specified.
Furthermore, since even the best quality assurance process cannot guarantee absenceof problems in design or material of system elements, the potential malfunctions of theused components need to be taken into account while designing the system (Ye & Kelly,2004). Hence, strategies to detect and react to these malfunctions need to be integrated
into the system. Safety standards like ISO 26262 (2011) require these considerations to
be noted down in a safety concept, which needs to be analyzed with respect to various
properties like completeness, consistency and the ability to prevent harm to involved
individuals. The most common techniques are summarized in safety standards, which
are often domain specific, such as the DO 178C (2011) as well as ARP 4761 (1996) for
the avionic domain or EN 50129 (2003) for rail. The standards recommend applicableanalysis methods, testing techniques and development processes. Although the individual
requirements differ from domain to domain, they all seek to drastically increase the effort

11

1 Introduction

spent on analysis and testing the more critical a potential harm is classified.

1.1 Motivation
The effort for verification and validation (V&V) of safety critical systems can consume
more than 75% (Laprie, 1994) of the whole development costs. Therefore, special
care has to be taken to avoid individual V&V activities being executed multiple times.
Nevertheless, changes to requirements occur frequently (Terwiesch & Loch, 1999; Fricke,
Gebhard, Negele, & Igenbergs, 2000) during the development of a system. One type ofchanges affects the current running development resulting from requests of the customer,
technological evolution or competitors (Fricke et al., 2000). The other type of changes
stems from the fact that system are very seldom developed from scratch and instead
existing products are modified or parts are re-used. These changes are an importantfactor for the overall verification and validation effort, since after changes often the wholesystem needs to be re-verified (Nicholson, Conmy, Bate, & McDermid, 2000; Fenn et al.,2007). This observation holds even though studies have shown that most companies have
implemented dedicated change management processes (Huang & Mak, 1999). Since it
is common for some subdomain of the automotive industry to change only 10% of thefunctionality from one generation to its next (Broy, 2006), this complete re-verification
results in tremendously high costs and suggests therefore a high potential of savings inverification effort.
Still, this effort currently seems necessary since a change in a system very often
requires additional changes to maintain an operational item. This effect is called change
propagation (Eckert, Clarkson, & Zanker, 2004; Dick, 2005) or ripple effect (Bohner,
2002; Bohner, 1996) or also a change snowball-effect (Terwiesch & Loch, 1999). The main
reason for a full re-verification of the whole system is, that even for experienced engineers
it is impossible to be sure that after performing the initial change and a set or corrective
measures, that none of the other components of the system is affected (Clarkson, Simons,& Eckert, 2004). Studies have also shown (Ciolkowski, Laitenberger, & Biffl, 2003) that
reviews are often not performed in a systematic way and design faults and associatednecessary changes are not identified.
This re-verification of the whole system has been illustrated by Fenn et al. (2007)
in Figure 1.1. The verification activities necessary for the certification of a system iscurrently independent from the size of the change. A linear relation between the size ofthe change and the verification effort is the goal to be reached in the future.
Also Espinoza, Ruiz, Sabetzadeh, and Panaroni (2011) discovered that the monolithic
and process oriented structure of the safety cases required by nearly all domain-specificsafety standards may require an entire re-certification of the system after changes. Hence,
two mostly separately discussed activities, namely Impact Analysis Techniques andModular System Specifications need to be integrated. Impact analysis techniques (Arnold& Bohner, 1993; Lehnert, 2011) are meant to identify the affected changes or give an
estimate of the adaptation costs before the change is actually implemented. Various
solution proposals for source code changes (Ryder & Tip, 2001; Gallagher & Lyle, 1991;

2

1.2 Scientific Question and Success Criteria(a) Current practice(b) Goal for the future

Figure 1.1 – Relation between the size of the change and the certification effort, according
to Fenn et al. (2007)

Law & Rothermel, 2003), avionic architectures (Nicholson et al., 2000) or generic systemmodels (Lock & Kotonya, 1999) exist. However, none of the existing techniques could beapplied to identify change effects in automotive safety concepts.
It is the focus of this thesis to overcome these shortcomings, as will be detailed in thenext section.

1.2 Scientific Question and Success Criteria
In contrast to the existing technologies, a solution to the following research question shallbe developed:
How to achieve a linear relation between the size of thechange and the re-verification effort while still guaranteeing
the overall safety of the system?
Based on the scientific question the following success criteria have been defined:
1. The effort to determine that a system is still safe after a change is incorporated hasa linear relation to the number of development artifacts that have been changed.
2. The confidence in the safety of the system after the change is incorporated is
identical or higher compared with the current practiced approach.
3. The support of the engineer during the adaptation of the system as well as all used
analysis techniques are fully automated.
4. The developed impact analysis approach is easy to apply in practice. In particular
guidance for the engineers is available.
5. The approach is in line with the current automotive safety standard ISO 26262.

3

1 Introduction

1.3 Basic Idea and Contribution
The need for a complete re-certification after changes on safety critical systems stems
from the inability to precisely predict the effects of changes on the rest of the system.
Multiple types of impact analyzes exist that try to identify a set of affected components.
Two basic problems prevent this information from being used efficiently in the recertification process of safety critical automotive systems: First, the set of affectedcomponents has a magnitude of the size of the whole system. This is mainly caused by
the use of tracelinks to determine dependencies between system artifacts. Hence, theresulting set is an over-approximation of the really affected system elements. The second
problem refers to approaches that try to limit the set of components that need to be
re-verified. Either the probability of false negatives is too high to argue that the system
is sufficiently safe if only the detected elements are considered for re-verification, or, thetechniques are just applicable for source-code and address compilability instead of correct
execution.
To overcome these limitations we developed an impact analysis that is based on thesemantics of formalized requirements. I.e., the intended behavior of a component indicates
if a change propagates to other components, rather than predefined information suchas tracelinks or data flow. To argue on the safety of the system, the fault propagation
behavior is captured in a formal notation. Contracts, an assume-guarantee approach, isused as an underlying theory for compositionality. In this thesis algorithms for detectingchange propagation using contract theory are presented together with optimization
strategies to reduce verification effort during the selection of compensation candidates.
Furthermore, existing formal languages for the description of failure propagation are
analyzed and extended to the needs of the impact analysis. This extension resultsin the first safety specification language providing means for abstraction, allowing arefinement of requirements without the problem of invalidating already gained verification
results. Guidelines and contract templates to describe safety concepts are presented toenable engineers to specify systems in an ISO 26262 compliant way without detailed
knowledge of formal methods. Analysis techniques have been developed that automate
the verification activities performed during the impact analysis process. This encompasses
the analysis of refinement properties and the compliance of an implementation to its
requirements. A Prototype tooling is presented. The evaluation of the approach has been
performed in an probabilistic simulation environment identifying the relevant parameters
and their value range in which the approach outperforms the state of the art technique.
Furthermore the impact analysis has been integrated in an OSLC-based tool landscapeto demonstrate how an automated change impact analysis can be used in distributed
development environments.

1.4 Assumptions and Scope of the WorkTo develop an impact analysis applicable for all development stages of safety criticalsystems exceeds by far the scope of a single dissertation. Therefore, the scope has been4

1.4 Assumptions and Scope of the Worklimited to a well defined subset.
This work employs a system structure based on Perspectives and Aspects (see fundamentals in Section 2.2). This structure is particularly useful to determine the assumptions
and the scope this work. Perspectives represent different structural stages of a system that
correspond to individual engineering challenges. For instance, there exists a functional
perspective a technical perspective or a geometrical perspective. Aspects represent thedifferent behavioral views, such as safety, timing, functional behavior or heat.
The scope of this thesis is confined to the safety aspect with an established link to thefunctional behavior aspect. Hence, the impact within the safety aspect only is calculated,while detailing the interface to the functional behavior aspect of the system. Since many
more aspects might be relevant for a system, it is the assumption that they can be alsomodeled in a way compatible with the safety specification. Since we choose contracts as
the most suitable specification mechanism to support impact analyses (see Section 3.1),
compatibility is in this case given as a formal, contract-based aspect definition. Currently
many different aspects are being developed in such a manner: the real-time aspect has
been extensively worked on by Reinkemeier, Stierand, Rehkop, and Henkler (2011) as
well as Gezgin, Weber, and Oertel (2014) providing a specification language integrated
in contracts to express timing requirements. Power aspects of a system, detailing theenergy consumption and leakage of components have been presented recently by Nitsche,
Gruttner, and Nebel (2013). However, the research focused in the last years on functional
requirements, stating the dependencies and values of signals in a system, for example, by
Rajan and Wahl (2013) or Mitschke et al. (2010). Additional aspects, such as geometricinstallations (Baumgart, 2013) and electro magnetic interference (Baumgart, Hörmaier,& Deuter, 2014), have started to be investigated. Still, the safety aspect is not yet
developed at a stage that it could be used for conducting a change impact analysis (forexisting techniques see Section 4.1.3). To be able to analyze safety critical systems, thesafety aspect is detailed in this work with all necessary requirements to be usable for achange impact analysis. Nevertheless, not all aspects are relevant for all systems. For
example, it is not necessary to consider the heat aspect for non-actuating low powerdevices like rain sensors. Hence, the assumption that all relevant aspects of a system canbe represented using contracts seems valid for the future, even if at the current point intime some aspects are still not fully elaborated.
The perspective has been limited to the logical one. In this perspective it is notdistinguished between hardware and software, the system is developed conceptuallyand higher level requirements are stated. Nevertheless, from the view of current safety
standards (see introduction to ISO 26262 in Section 2.3) this system representation isessential for the safe operation of a system, since the functional safety concept expressed inthis perspective defines the system-wide fault mitigation and degradation concepts. Sinceat this time implementation dependent aspects like heat, electro magnetic compatibility(EMC) or geometric installation are not relevant the system can be fully described by
the already well-defined aspects. Therefore, within the defined scope, the change impact
analysis will deliver a semantically accurate determination of all development artifacts
affected by a change. The application of the approach for technical perspectives is5

1 Introduction

dependent upon the used aspects and can therefore not be answered in general.
To support the engineer in reacting faster and more accurately on changes in requirements or implementations it is essential to give feedback to the user in a reasonable
time frame. Hence, automation of the identification of the affected elements that needadditional corrective measures is necessary. Still, since all of the automated analyses
we provide are based on model checking technology (Baier & Katoen, 2008; Clarke,
Grumberg, & Peled, 1999), there might be situations in which the analysis is running fora very long time. However, as many researchers are exclusively working on improving
model checkers, this task was intentionally excluded from this thesis.
Since there exist various ways to approach changes in systems (see Section 3.1) it is worth
mentioning that this work does not aim to improve the extendability or maintainability ofa system. Also, it is the goal to develop an online approach detecting impacts of changes,
we do not want to estimate the effort for a change in advance to any engineering activity.

1.5 Terms and Definitions
This thesis connects multiple research and application areas such as systems engineering,
requirements engineering, formal methods and also application of safety standards. Sincemany terms are used differently among these domains, we briefly introduce the mostimportant terms and topics:

1.5.1 Embedded Systems, Models and Safety
This thesis deals with changes in embedded systems, which are defined by Marwedel andWehmeyer (2007) as “information processing systems that are embedded into a larger
product.” While this larger product is rather unspecific, Lee and Seshia (2010) clarify that“embedded computers and networks monitor and control the physical process, usuallywith feedback loops where physical processes affect computations and vice versa.” By
the coupling to physical processes embedded systems have an immediate impact on theenvironment and are therefore often considered as safety-critical systems (Marwedel &Wehmeyer, 2007). Hence, the property safety, “the degree to which accidental harmis prevented, detected and reacted to” (Firesmith, 2003), is a strong influencing factorof the systems design. This definition, as it is formulated similarly by Storey (1996),
Avizienis, Laprie, Randell, and Landwehr (2004) or Nancy (1995), extends the definition
by Lamport (1977) and Alpern and Schneider (1985), defining a safety property by aset of states of a system that shall not occur. Domain specific safety standards like theISO 26262 (2011) (for an introduction see Section 2.3), ARP 4761 1996 or DO178c 2011
give guidance on how to analyze the potential risks of a system and how to prevent them.
To avoid faults in the design of safety critical systems it is helpful to use models
to structure the system for a better understanding and avoid ambiguities in natural
language descriptions (Pohl, Hönninger, Achatz, & Broy, 2012). This type of systems
development is called a model-based design process. The models can have well-definedsemantics, and code generators can exist to produce the code based on the model. The

6

1.5 Terms and Definitions

models are described by so-called meta-models that describe the language, that is, the“building blocks,” that can be used in the model (Atkinson & Kühne, 2001). Thereexist meta-models for various aspects of the system design, ranging from high-levelsystem description languages like SySML (OMG SysML, 2012) to low-level control loop
descriptions like Targetlink1 . Models that are capable of describing the actual behavior of
a component are called behavioral models (DoDAF/DM2 2.02, 2010). Structural models
represent the structure and system without detailing the explicit behavior. Schaetz
classifies these models as product models (Schätz, Pretschner, Huber, & Philipps, 2002),
since they describe entities of the item to be developed or its environment. In contrast,
process models describe the development process and contain the activities and work
products that need to be produced. The benefits of using models in the dvelopment
process is to gain tool support while generating code, generating test cases, performing
early verification and validation activities or virtual integration testing (Baumgart et al.,2011).

1.5.2 Fault, Error and Failure
All three terms describe conditions of a system that are not intended. A fault is definedby the ISO 26262 as an “abnormal condition that can cause an element or an item tofail” (ISO 26262, 2011). Bozzano states this abnormal condition more precisely as “adefect or an anomaly in an item or a system” (Bozzano & Villafiorita, 2011). Faults
can occur during design time, by making a mistake in the development of hardware orsoftware components. These faults are called systematic faults (Storey, 1996). Faults canalso occur during the operation of the system, if a hardware component stops working
as expected. These random faults may have various reasons, such as aging or material
defects. Multiple safety standards agree, that random faults may only occur in hardware
components (Baufreton et al., 2010). Faults can be further classified according to their
persistence (Avizienis et al., 2004): A fault is considered as permanent if its presence iscontinuous in time, a fault is considered as transient if its presence is bounded in time,that is, the fault occurs and disappears. If the fault occurs and disappears frequently,
the fault is called intermittent (ISO 26262, 2011). Koren and Krishna (2007) calls thisbehavior oscillation of a fault. A typical example is a loose electrical connection.
A fault may become apparent by leading to an error, the “discrepancy between acomputed, observed or measured value or condition, and the true, specified or theoreticallycorrect value or condition”(ISO 26262, 2011). For example, a software bug in a rarely
used routine could be in the system for a very long time (potentially for the whole lifetimeof the system) until that software part is executed and a wrong value is calculated (Storey,1996).
This deviation from the intended behavior could lead to a failure, namely the “inability
to perform its intended function” (Bozzano & Villafiorita, 2011). Nevertheless, an error
does not necessarily lead to a failure, since the fault could be detected (see Section 1.5.3)
and appropriate countermeasures could be started. A mechanism to prevent an error
1

https://www.dspace.com

7

1 Introduction

from becoming a failure is redundancy.

1.5.3 Fault Avoidance, Fault Removal and Fault Tolerance
It is unavoidable that systematic or random faults are present in the system. Hence,techniques are needed to handle faults during design time or during run time. Storey(1996) and Bozzano and Villafiorita (2011) identified four different types of techniques:fault avoidance, fault removal, fault detection and fault tolerance. Although newer
classifications exist (Avizienis et al., 2004) that define fault detection and fault correction
as subactivities of fault tolerance, we stick to Storey’s classification since the ISO 26262
explicitly distinguishes between fault detection and fault tolerance.
Fault avoidance techniques try to improve the quality of the development process toprevent faults from being introduced by, for example, usage of model-based techniques orformal system specification, and thereby avoid ambiguities of natural language descriptions.
These techniques are called fault prevention by Avizienis et al. (2004). Fault removal
techniques are still applied at design time, but try to identify faults in the system (e.g., by
testing or formal verification) and then remove the faults from the design. In contrast tofault removal techniques, which target only systematic faults in the design of the system,
fault detection techniques also allow identification of random faults during runtime of thesystem to activate appropriate countermeasures in order to avoid failures. Classical fault
detection techniques include memory checks, consistency checks or watchdogs. Fault
tolerance mechanisms keep the system correctly working, even in case of faults that
occur (Avizienis et al., 2004). Fault tolerance mechanisms have a hypothesis under whicha mechanism is able to handle a fault correctly. Examples for this hypothesis are theassumption of a maximum number of simultaneous occurring faults in the system or
the assumption that some components, like the voting component, do not fail at all.
Frequently, both assumptions are used in combination (Bozzano & Villafiorita, 2011).
Fault tolerance mechanisms often rely on detection techniques to, for example, switch toanother channel and deactivate the defective one. A typical fault tolerance mechanism istriple modular redundancy (TMR) (Von Neumann, 1956; Moore & Shannon, 1956).

1.5.4 Verification and Validation“Verification is the process of determining that a system, or module, meets its specificationand validation is the process of determining that a system is appropriate for its purpose”(Storey, 1996). Verification and validation techniques can be categorized by multiple
criteria. Static analysis methods analyze the system without executing it. Classicalwalk-throughs or reviews, which can be used both for validation and verification, as well
as automated techniques such as static-code analysis to determine execution times (Shaw,
1989; Gustafsson, Ermedahl, Sandberg, & Lisper, 2006) belong to this class of analyses.
Another popular static analysis method for verification is model checking (Clarke et al.,
1999; Baier & Katoen, 2008), which uses a model of the system, typically represented asa state-machine or even JAVA-code (Visser, Havelund, Brat, Park, & Lerda, 2003), toprove that a property (for example, a requirement) holds. Dynamic analysis methods8

1.6 Outline

execute the system, or parts of it, to judge the correctness of the results to given stimuli.
If stimuli are passed to the final system or system part, this activity is called testing. If a
model of the system is used, the activity is called simulation (Bozzano & Villafiorita,2011).

1.5.5 Change and Configuration Management
Change management is applied in many domains to implement new processes andstructures in a company or react to new or changing market situations. This work isconcerned with engineering change, “an alteration made to parts, drawings or softwarethat have already been released during the product design process” (Jarratt, Eckert,
Caldwell, & Clarkson, 2011). Although some authors disagree (Wright, 1997), we
understand the release in the development process as an agreement to having a design
stage complete to continue with the preceding ones, rather than a release for production.
In particular, we assume that a release of one design stage, for example, completingthe functional safety concept (see Section 2.3), includes the successful completion of all
verification and validation activities required for that particular stage.
The activities of handling changes are subsumed under the term configuration management and detailed in standards like ISO 10007 (2003) (Guidelines for configuration
management) or ISO/IEC 12207 (2008) (Software life cycle processes). A Configuration
item is “an aggregation of work products that is designated for configuration management
and treated as a single entity in the configuration management process” (CMMI Product
Team, 2010). Hence, it is the objective of configuration management to identify anddescribe the configuration items, to control changes that are performed to the configuration items, to “record and report change processing and implementation status, andverify compliance with specified requirements” (CMMI Product Team, 2010). It is an
essential result of a configuration management process to define baselines. A basline
is a “specification or product that has been formally reviewed and agreed upon, that
thereafter serves as the basis for further development, and that can be changed only
through formal change control procedures” (ISO/IEC 12207, 2008). Often a baseline
is considered as the configuration information at a specific time. Before implementing
a change an impact analysis shall be carried out, to assess the potential conflicts withother configuration items (CMMI Product Team, 2010; ISO 26262, 2011). In this work
the term impact analysis is extended from an analysis that is carried out before thechange is implemented to an analysis that is performed constantly during the change
implementation process to identify only the affected verification and validation activities.

1.6 Outline
A more in-depth overview of the fundamental theories will be given in Chapter 2.
In particular, this includes the principles of designing a system by contracts, using
perspectives and aspects, as well as the fundamentals of the higher level parts of the ISO
26262.

9

1 Introduction

We chose a two-stage approach for the development of the new impact analysis. First,
we review the existing impact analysis techniques and determine the shortcomings thatprevent them from being used for automotive safety concepts in Chapter 3. Based on
this analysis a new change impact process is developed that is able to scale linearly withthe size of the change. Furthermore, we describe how the engineers applying the new
approach can be supported by the analysis in finding efficient ways to deal with change
propagation, which were very difficult to detect without automation support. Based on
this process we state requirements on a formal system model that need to be fulfilled inorder to support the change impact process.
In the second stage, this formal model capturing the safety concept is described in
Chapter 4. After analyzing the existing safety modeling approaches we select the mostappropriate technique and extend it with the still missing features. In particular, this is
the introduction of abstraction techniques to safety specifications, to support bottom-up
as well as top-down design processes, and support for multiple possible malfunctions onfunctional signals. Furthermore we present solutions of how to automatically perform theneeded automatic analysis techniques evaluating refinement and satisfaction properties ofthe safety model. Furthermore, specification templates and guidelines for building thesemodels are provided.
In Chapter 5 we evaluate the approach in two different ways. First, the approach
is applied to its full extend to an real-life example. In this example the specification
mechanisms and change procedures are demonstrated. Second, to allow a quantitative
comparison to the current state of the art technique, a simulation framework has beendeveloped to prove the gain in efficiency of the new approach. Furthermore, multiple tools
have been developed to prove the applicability and implement ability of the previously
theoretically described approach. These tools are discussed briefly in Chapter 6. It is
not the intention to elaborate on the development of the tools, rather on the application
scenarios and discovered challenges while deploying a change impact analysis service ina distributed development environment. Final conclusions and impact of the presented
results are discussed in Chapter 7.

10

CHAPTER

Fundamentals
This work does rely on some fundamental concepts and theories. Some specification
concepts and the operators for composition are based on the contract-based designprinciple. Therefore, the basic concepts and definitions of contracts are introduced in
section 2.1. Contracts are strongly connected with a structuring of the system in socalled perspectives and aspects. In this work we focus on one particular aspect, namely
safety, and the logical perspective. Hence, it is necessary to understand this structure,
which is described in section 2.2. The targeted application of the presented specification
mechanisms in Chapter 4 is a formalization of the functional safety concept of the ISO
26262. Therefore, a short overview of this automotive functional safety standard is given
in section 2.3 with a focus on the requirements regarding the safety concepts.

2.1 Contract-based Design
Compositional reasoning strives for structuring and simplifying verification efforts by
exploiting the particular structure of the system under verification, as given by thefunctional architecture and its different components forming the building block of acomplex system. The analysis of such an integration of system components has become
ever more complicated, caused by a development shift in the supply chains from an
integration on element level by the OEM towards an integration of whole systems. To
tackle this problem, structured specifications of the components to be integrated arenecessary.
Contracts provide such structure by providing dedicated component specifications
separating requirements into an assumption, which describes the expected properties ofthe environment, and a guarantee, which describes the desired behavior of the component
under analysis should the assumption be met by the operational context, i.e., the environment. This separation allows the building of a sound theory that enables reasoning
in a formal way about the composition of systems. Contracts, belonging to the class of112

2 Fundamentals

assume-guarantee reasoning techniques (Henzinger, Qadeer, & Rajamani, 1998), are awidely adopted approach for compositional verification (de Roever, 1998; Peng & Tahar,
1998).
The origin of such modular, contract-like specifications can be traced all the way
back to pre- and post-conditions of sequential program snippets, such as Hoare triplets(Hoare, 1969), yet the most influential step towards their adoption as design contracts
in software engineering can be found in Bertrand Meyer’s work (Mandrioli & Meyer,
1992; Meyer, 1992) related to the programming language Eiffel. Driven by European
projects like SPEEDS1 , the focus of contracts has recently shifted from the descriptionof pure software systems to a holistic systems engineering approach (Benveniste et al.,2008; Damm, 2005). Many different specializations and extensions have been presented,
for example, probabilistic contracts (Delahaye, Caillaud, & Legay, 2011) or contracts forhybrid systems (Damm, Dierks, Oehlerking, & Pnueli, 2010).
To illustrate the underlying principles, however, we will skip over these specialized
theories and instead focus on the standard literature (Benveniste et al., 2012; Baumgart
et al., 2011; Hungar, 2011b) introducing the basic formalism and definitions together
with the most commonly used theorems.

2.1.1 Trace Semantics
Contract semantics for reactive and embedded systems are defined over traces of asystem (Hungar, 2011b; Baumgart et al., 2011). Components, in the following denotedwith M, are characterized by ports (P ), that are either defined as input or as output ports.
Note, that in contrast to the SPEEDS meta-model (SPEEDS, 2007), we do not further
refine a port into multiple flows. A trace assigns a value V out of the value domain V toeach of the ports at any given point in time t ∈ T . Therefore, a trace is of the form:[T → [P → V]]
The traces of a component M are denoted [[M]]. This set comprises all possible behaviors
of a component (implementation), even in case of unacceptable inputs due to a general
requirement of input openness, i.e., requiring systems to never confine or otherwise refuse
input. The (semantically concurrent) composition of multiple subcomponents M1 . . . Mn to
a component M then is defined (Baumgart et al., 2011) as the set of traces acceptable by
all components:""##n[[M]] =

×M =
i

i=1

n
\

[[Mi ]]

i=1

For the sake of simplicity port renaming in assembly- and delegation-connectors are
neglected, therefore identity between connected input and output ports is assumed.
1

http://www.speeds.eu.com/

122.1 Contract-based Design

2.1.2 Contracts
A contract is a tuple C = (A, G) describing a set of traces using the assumption A andthe guarantee G:[[C]] = [[A]]−1 ∪ [[G]]with (.)−1 denoting the complement of a set. Although not formally required by thedefinition of contracts, assumptions typically only specify constraints on the input,
whereas guarantees reflect the input output relation and therefore contain restrictionsof allowed outputs while being input-open. We assume all contracts to be stated in the
canonical form (Benveniste et al., 2008) which allows some simplifications in the following
definitions of the operators and relations. A contract is said so be in canonical form if[[G]] at least contains [[A]]−1 . Note that this implies that the traces [[G]] associated withthe guarantee G and the traces [[C]] of the whole contract C = (A, G) do agree; yet thecontract C syntactically is a pair (A, G) explicitly distinguishing the roles of assumptions
and guarantees, which is instrumental to the pragmatics of contract-based design.
Some sources in the pertinent literature additionally distinguish the concept of a
“Strong Assumption” and “Weak Assumption” (e.g., Damm, Hungar, Josko, Peikenkamp,
and Stierand (2011) and Baumgart et al. (2011)). Strong assumptions are meant toexpress the overall “operational envelope” for a component, for example, the conditions
that need to be fulfilled to perform any meaningful operation. The weak assumption
allows the specification of different guarantees of a component for multiple different
environmental situations, thus permitting case-based definition of desired behavior. Since
the safety specifications used in this work consider only the latter, we will not further
elaborate on strong assumptions.

2.1.3 Contract Relations and Operators
In order to reason about the correctness of the composition of a system, a set of basic
relations and operators need to be defined on contracts and implementations.
Definition 1 (Satisfaction). The satisfaction relation defines when the component
complies to its contract. A component M satisfies a contract C = (A, G), denoted
M |= (A, G), iff all its traces are permitted by the contract, i.e., [[M]] ⊆ [[C]], and its inputs
and outputs coincide to those underlying the contract. Consequently,
M |= (A, G) ⇔ [[M]] ∩ [[A]] ⊆ [[G]]This definition is non-controversial in literature (Baumgart et al., 2011; Delahaye etal., 2011; Benveniste et al., 2008).
Definition 2 (Refinement). Refinement is a relation between two contracts, statingthat the refined contract is a valid concretion of the other, i.e., the refining contract is avalid replacement in all possible operational contexts satisfying all (and maybe more)
requirements satisfied by the refined contract. According to Benveniste et al. (2012) and13

2 Fundamentals

Delahaye et al. (2011) a contract C1 refines C2 if it has the same signature, i.e., same
input and output ports, yet imposes relaxed assumptions and more precise guarantees:
C 1  C 2 ⇔ A1 ⊇ A2 ∧ G 1 ⊆ G 2
Baumgart et al. (2011) and Damm et al. (2011) call this relation dominance. Also Benveniste et al. (2008) use the term dominance, since they use the term refinement todenote a relation between different implementations.
Definition 3 (Parallel Composition). For two contracts C1 and C2 , the parallel composition C1 ⊗ C2 is defined as:((A1 ∩ A2 ) ∪ ¬(G1 ∩ G2 ), (G1 ∩ G2 ))Parallel composition (⊗) is used to combine multiple contracts into a new contractthat represents the intended behavior of an ensemble of components individually satisfying these contracts. In contrast to conjunction (see below), the operator is used to
combine contracts applying to different components at the same hierarchy level in thearchitecture. The operator creates a new contract with an assumption and a guarantee.
This composition is typically used to combine all contracts of the subcomponents toperform a virtual integration test.
To be composable contracts need to be compatible, that is, their variable types matchand an environment exists in which the two contracts interact properly in terms ofappropriately connected ports (Benveniste et al., 2012).
This definition is equivalently stated by Delahaye et al. (2011) and Benveniste etal. (2008), who also claim to be in line with Henzingers definition used for Interface
Automatons (De Alfaro & Henzinger, 2001). The parallel composition preserves canonicity(Delahaye et al., 2011). Hungar (Hungar, 2011a) defines the parallel composition as:
!
\
i

Ai ∪

[

Ai ∩ G−1
i

i

 \

,

!

Gi

i

This notation is equivalent to the above-mentioned one, considering that Hungar is
not using a canonical form. Therefore his observation regarding the intersection of thecomplete trace-sets is also valid:[[kni=1 (Ai , Gi )]] =n\[[(Ai , Gi )]]i=1

Definition 4 (Conjunction). Conjunction is an operator used to combine multiple
contracts that are associated to one component:
C1 ∧ C2 = (A1 ∪ A2 , G1 ∩ G2 )Conjunction may be necessary if for different environmental situations a separate
behavior shall be described or different viewpoints are used (Benveniste et al., 2008)14

2.1 Contract-based Design(there called greatest lower bound). The given definition is identical to Delahaye et al.
(2011) and Benveniste et al. (2012). The result of a conjunction is still a contract incanonical form (Benveniste et al., 2008).

2.1.4 Theorems
Compositional verification refers to deducing the correctness of a global system byobserving its atomic components only (Hungar, 2011b). This property is deduced by
the following theorems which are equivalently stated in literature (Delahaye et al., 2011;
Hungar, 2011a; Baumgart et al., 2011; Benveniste et al., 2008; Benveniste et al., 2012):
Theorem 1. If a model M satisfies a contract C1 , it also satisfies all contracts that C1 isrefining:
M |= C1 ∧ C1  C2 → M |= C2
Theorem 2. If the compliance of the models M1 and M2 have been shown to theirrespective contracts C1 and C2 , the composition of the models satisfies the parallel
composition of the contracts:
M1 |= C1 ∧ M2 |= C2 → (M1 × M2 ) |= (C1 ⊗ C2 )From the theorems it is directly following:
Corollary 1 (Virtual Integration). According to (Damm et al., 2011; Baumgart et al.,2011; Gezgin et al., 2014; Hungar, 2011a) virtual integration is given iff all subcomponents
Mi of component M satisfy their respective contracts and the parallel composition of thesecontracts refine the top-level contract C then the top-level contract is satisfied by M:" n^

Mi |= Ci ∧

i=1

n
O

!

Ci

#

 C → M |= C

i=1

Hence, it is sufficient to prove the compliance of the parts to their specification toprove the complete design, if refinement of the contracts to the system specification is
given.
For the sake of completeness it has to be stated that in case of the usage of strong
assumptions additionally a condition has to hold to establish virtual integration:
n
O
i=1

!

Ci ∧ (A) ⇒

n
^

Ai

i=1

It needs to be ensured that strong assumptions are not violated, either because thestrong assumption of the top-level component already requires that property, or theguarantees of the subcomponents establish them.

15

2 Fundamentals

2.1.5 Contracts in Formulas
A contract can be represented as a formula if the selected logic supports negation or
implication (Baumgart et al., 2011; Hungar, 2011a; Damm et al., 2011; Benveniste et al.,2012):
form((A, G)) = A ⇒ G
The parallel composition of contracts (A, G) ⊗ (B, H) can be expressed as one of thefollowing (Baumgart et al., 2011):((A ∧ ¬G) ∨ (B ∧ ¬H), f alse)(2.1)((A ∧ B) ∨ (A ∧ ¬G) ∨ (B ∧ ¬H), G ∧ H)

(2.2)

(A ∨ B, (¬A ∧ H) ∨ (¬B ∧ G) ∨ (G ∧ H))(2.3)(true, ¬(A ∧ B) ∨ (¬A ∧ H) ∨ (¬B ∧ G) ∨ (G ∧ H))(2.4)

The differences to the definition 3 can be compensated by using the canonical form.
Therefore, ((A ∧ B) ∨ ¬(G ∧ H), G ∧ H) is valid for contracts in canonical form.
Refinement can be expressed as:
C 0  C, if A0 ⇐ A and G0 ⇒ G
Virtual integration in formulas first expressed by Damm et al. (2011) and Hungar(2011a) as:
" n
^

#

(Mi |= Ci ) ∧

i=1

"

n
^

!

Ci

#

⇒ C ⇒ M |= C

i=1

This definition is not in line with the virtual integration definition given for trace
semantics in this work. This is caused since Hungar and Damm specify refinement
for non-canonical contracts and require strengthening of assumptions only for strong
assumptions. They used the following refinement definition:
C 0  C, if C 0 ⇒ Cconsequently for trace sets:
C 0  C, if [[C 0 ]] ⊆ [[C]]To adapt virtual integration to the definition of refinement for canonical contracts it
needs to be slightly modified:
Given M with associated contract Cg = (Ag , Gg ) and subparts Mi each connected witha contract Ci (which is the conjunction of all contracts connected to Mi ) the parallel
composition of the Ci is given:16

2.2 System Design using Aspects and PerspectivesnOCi = (Ap , Gp )i=1

Virtual integration is defined as:
" n
^

#

(Mi |= Ci ) ∧ [Ag ⇒ Ap ∧ Gg ⇐ Gp ] ⇒ M |= C

i=1

2.2 System Design using Aspects and Perspectives
One of the most important approaches to understanding, developing and maintaining
complex system is the introduction of structure (Baumgart et al., 2011; Storey, 1996).
For computing systems the usage of so-called, modules dates back to the mid 1960s(Baldwin & Clark, 2000), first introduced with the IBM system 360. The goal of thisstructure was to enable a development of the system by different specialist teams in an
independent manner (Baldwin & Clark, 2000). It is still an important requirement forsystem structures to ease the collaboration among many development parties. Whilemodules are considered to be a vertical structure (Benveniste et al., 2012; Damm, 2005)(i.e., a separation of functions at the same level of abstraction), Neumann (Neumann,1986) introduced in 1986 a horizontal structure that he called layered architectures. Higher
levels of software use the underlying layers to accomplish their tasks, and calls fromlower-level software to higher-level software can be avoided. Layering is still a commonlyused architectural pattern (Fowler, 2002) with popular specializations, such as the modelview-controller pattern (Krasner, Pope, et al., 1988) used e.g., in the AUTOSAR software
stack (AUTOSAR GbR, 2014). This structure allows the focus to be on the user-centric
functionality first and the necessary services later on. Hence, this software structure isalready going in the direction of a concept of multiple layers of abstraction in which
the lower levels refine the entities on higher abstraction levels (Sage & Rouse, 2009;
Sommerville, 2010). Nevertheless, there is a fundamental difference between the early
concept of layered software and abstraction techniques. In a layered software architectureeach component in a layer fulfills a special unique functionality, but uses other functions,that are described in lower levels. Hence, one component can only be found in exactly one
layer of the software. If abstraction levels are used, the components on lower abstractionlevels inherit the requirements of the higher layers, since the lower layers describe theidentical entity already described in higher layers, but with more details.
With the frequently used model-based design principle, structure is not only a means toorganize implementations, but also a central aspect of systems design. Structure is createdfirst, functionality is added afterwards. Model-based languages and tools exist for manydifferent engineering activities like controller design (SIMULINK), automotive softwarearchitectures (AUTOSAR) or GSN (goal structure notation) for representing safety cases(Kelly, 1999). But even the development processes themselves have become so complex
that guidance by additional structures are welcome. One of the most frequently used17

2 Fundamentals

process models is the V-model (Dröschel & Wiemers, 1999) or V-model XT (Friedrich,Hammerschall, Kuhrmann, & Sihling, 2009).
Nevertheless, all mentioned techniques and models are either technology, domain or
abstraction level dependent. A system-wide structure to integrate the different existingarchitectural, behavioral and process models was missing. Approaches from the military
domain, such as the Department of Defence Architectural Framework (DoDAF/DM2
2.02, 2010), have not gained much attention in other domains (Rajan & Wahl, 2013)
because of their very domain specific nature. To develop a cross-domain usable system
structure, the goals for structure need to be kept in mind, namely to provide support for
distributed development and to better understand a system by a separation of concerns.
Hence, a modern top level structure of the system is driven by the different development
disciplines and experts groups involved in todays system’s development. To identify themost important structural elements, intensive discussions with the projects partners frommultiple engineering disciplines, such as aerospace, automotive and rail, has been held in
the projects SPES2020 (Pohl et al., 2012) and CESAR (Rajan & Wahl, 2013), partly
re-using outcomes from the project SPEEDS (Enzmann, Döhmen, Andersson, & Härdt,2008). The result was a structure of the system that introduced to the abstraction levels
two further concepts called perspectives (see Section 2.2.1) to refine structural levels of
the system and aspects (see Section 2.2.2) to further classify behavioral descriptions.
These concepts have also been taken up in the projects MBAT and SPES XT. Besides
the already mentioned goals special attention was given to the traceability between
development steps, requirements and development artifacts.

2.2.1 Structural Organization of the System
To separate the concerns of different stakeholders, the IEEE 1471 (2000) suggests using
views and viewpoints. While a view is marking a concrete part of a system, a viewpointis the convention of how to construct and use a view. To be able to cover the completeengineering space, from the initial description of the problem to concrete technicalcomponents, the framework developed in SPES and CESAR combines abstraction levels
and structural viewpoints of the system into a two-dimensional space (see Figure 2.1).
The structural viewpoints, called perspectives, describe the subsequent stages of a systemseparated by the types of structures used. The first two perspectives, the operational
perspective and the functional perspective are problem oriented and, describe the intended
use-cases of the element to be developed and derive, based on these scenarios, the items
functions. The other perspectives (logical, technical, geometric) focus on the design ofthe solution.
The perspectives have been chosen to be able to map the V-process model to theresulting two-dimensional engineering space. The left “development side” of the V isgoing diagonally from the top left corner to the bottom right corner. This diagonality canbe considered more as a “rule of thumb” than a necessary requirement, since operationaldescriptions typically do not cover very low abstraction levels (e.g., a circuit level).
Furthermore, the technical level is frequently started at an intermediate abstractionlevel, where a refined logical architecture is mapped to a technical element, and not18

2.2 System Design using Aspects and Perspectives

Functional
Perspective

LogicalPerspective

Technical
Perspective

Geometric
Perspective

Vehiclecoarser

Operational
Perspective

Powertrain

ECU

finer

ECU

Levels of Abstraction

Body

System Development Perspectives

Figure 2.1 – Structural organization of the system in perspectives on the example of anaerospace system. Based on Baumgart et al. (2011) and Rajan and Wahl
(2013)

reconstructed on the layers above. Nevertheless, the logical perspective is likely to bepresent on all higher abstraction levels up to a certain level, where the switch to thetechnical perspective occurs.
The relations between the different abstraction levels and perspectives are represented
by two tracelinks (Baumgart et al., 2010; Baumgart et al., 2013) (see Figure 2.1), therealize and the allocate link. The realize links indicates that a component is refinedby another component. The equivalent link between requirements is called refine. The
realization can be expressed by a state-machine that creates the relation between theevents in the refined and more abstract model (Baumgart et al., 2010). The allocation
link indicates that a component or port is mapped to a more technical perspective. This
mapping can also be expressed by a state-machine. This state-machine expresses thesemantics of the mapping, since e.g., a logical value in a port needs to be converted in adefined manner to a signal on hardware pins.
In the following the usage and the elements of the five perspectives are presented:

19

2 Fundamentals

Operational Perspective We take the name operational perspective from the CESAR(Rajan & Wahl, 2013) project, while in SPES2020 (Pohl et al., 2012) this perspective iscalled the requirements viewpoint. Nevertheless, the intended use of the perspective ismostly identical. The item to be developed is considered as a black box and scenarios
are described how the potential users shall interact with the system. Hence, it is also
necessary to describe the environment in which the system shall operate. This perspective
is used to analyze the customer needs and elicit the capabilities and activities of thesystem (Baumgart et al., 2013) as well as the goals of the stakeholders (Rajan & Wahl,2013).
Additionally, in the SPES2020 requirements perspective, requirements for technicalelements can be expressed, which is not the intention of the CESAR and MBAT models.
Therefore, we consider the operational perspective in the meaning of CESAR and MBAT,
since technical requirements in the operational perspective would break the idea of keeping
the first two perspectives problem oriented, without performing a design of the solution.
This approach fits better the requirements of safety standards like the ISO 26262 (2011)(see also section 2.3) in which the initial description of the system, which is used for thehazard analysis, should be performed without any technical assumptions on the system.
Functional Perspective In the functional perspective a hierarchical structure of functions is built. The top-level functions are called user functions (Pohl et al., 2012), andthese functions can be defined using input from the user and an expected output fromthe system. The user functions can be refined in functions in a so-called whitebox modelof the functional perspective. Hence, the functions represent the summarized capabilities
and scenarios from the operational perspective (Rajan & Wahl, 2013). The here defined
functions shall be independent of any architectural assumptions, if possible (Baumgart
et al., 2011). Furthermore, constraints and restrictions to the functions can be stated(Baumgart et al., 2013). This could be mapping constraints, that two functions shallbe mapped to an identical technical target, or be at least “close” together, because of
performance reasons. Vice versa, independence constraints, requiring a different allocation
target, could result from safety considerations (Ellen, Etzien, & Oertel, 2012).
Logical Perspective In contrast to the operational and functional perspective, thelogical perspective is not problem but solution oriented. Hence, the actual design of theitem is described. Therefore, components and their part relations describe the hierarchyof system elements. This representation does not yet distinguish between software or
hardware components and considers them in an equal, logical, manner (Rajan & Wahl,2013). Furthermore the interface of the top level component, characterizing the system’sboundary, details the interaction with the environment (Baumgart et al., 2011). The
functions modeled in the functional perspective are allocated to the components of thesystem. This allocation should be performed only within the same abstraction levels
and should respect the constraints given in the functional perspective. The separationof the system into multiple logical parts is a means to start early with a distributed
development process. In addition, costs can be saved by grouping functions, which are20

2.2 System Design using Aspects and Perspectives

reused by multiple user functions (Pohl et al., 2012).
Technical Perspective The technical perspective describes the physical architectureof the system (Pohl et al., 2012). Hence, components are either hardware- or softwarecomponents. It is the goal to describe the different ECUs of the target system with their
peripherals and the communication infrastructure. Also the allocation of software tasks
to hardware elements and their intended interface is specified. The technical perspective
is much more detailed than the logical to support more specific analyses. To be able toperform, for example, a timing analysis, the scheduler, resources and task parameters alsoneed to be specified (Pohl et al., 2012; Baumgart et al., 2011). Considering that the lowest
abstraction level of the technical viewpoint is intended to act as the implementation
specification of the atomic components, the degree of details does not come as a surprise(Rajan & Wahl, 2013). Hence, many domain specific meta-models exist to describe
parts of the technical perspective, such as AUTOSAR (AUTOSAR GbR, 2014) in theautomotive domain, or IMA (integrated modular avionics) (Prisaznuk, 1992) in theavionics domain.
Although the projects deal with E/E systems to a great extent, the hardware parts
are not limited to electronic components but can also contain mechanical systems likecams, shafts and switches or hydraulic elements like valves and cylinders (Baumgart etal., 2011).
Geometrical Perspective The geometrical perspective is not mentioned in SPES2020
but exists in the CESAR framework, the Architecture Modelling technical report (Baumgart et al., 2011) and publications of the MBAT Project (Baumgart et al., 2013). In
CESAR this perspective is marked as experimental, and, although current research stilltries to elaborate on this perspective (Baumgart, 2013), we only briefly introduce thisperspective, for the sake of completeness.
It is the intention of the perspective to cover the physical installation properties ofthe system and their spatial dimensions. This covers the placement of components, therouting of cables and size limitations (Baumgart et al., 2011). The elements inside thegeometric perspective can be based on CAD models e.g., from CATIA or AUTOCAD.
Since the geometric properties are closely connected to the technical realizations of thecomponents, it is expected that the technical and geometrical perspective will be jointly
developed.

2.2.2 Classification of Dynamic Behavior
Orthogonal to the perspective describing the structure based on their “technicality” astructure called aspects is introduced to describe multiple behavioral concerns of thesystem. These aspects are oriented on the various analysis techniques, which are typically
performed by different expert teams. In the SPEEDS project, the aspects safety, real-timeand functional behavior have been defined (Böde, Gebhardt, & Peikenkamp, 2010). This
selection is identical to the architecture modeling technical report (Baumgart et al., 2011).

21

2 Fundamentals

In addition, in the CESAR book (Rajan & Wahl, 2013) the aspects performance, interface
and product line are mentioned. This already indicates that the aspects, in contrast
to the perspectives, are not predefined and vary from product to product. Research iscurrently being performed in the direction of further aspects such as power (Nitsche etal., 2013) or EMC (Baumgart et al., 2014).
Dimension:
Abstraction Levels

otherAspectSafetyView

Real-Timetion

Functional
Behavior

rac
Abst

Abs
trac
tion

Dimension:
Perspectives

ModelReal World

SystemFigure 2.2 – Classification of dynamic behavior of the system using aspects.

The aspects comprise a structure that is set on top of the two-dimensional engineering
space given by the abstraction levels and perspectives (see Figure 2.2). Hence, they
use the same structural component model but describe different properties providing a
structure to the requirements. Not all aspects are relevant in all perspectives (Baumgart
et al., 2010) (e.g., a real-time aspect would not be used in the geometrical perspective)
nor it is unlikely that the aspect for electromagnetic compatibility would be consideredin the operational perspective, unless the device is expected to control radiation by itself.
A good intuition of how the requirements within the different aspects may look is givenby the requirements specification language (RSL) (Reinkemeier et al., 2011; Mitschke etal., 2010; Baumgart et al., 2011) developed in the CESAR Project. This RSL provides
requirement templates, called patterns, for selected aspects.
Functional Behavior Requirements assigned to the aspect functional behavior define
the order and values of events or conditions on ports of the architectural components. It
is also possible to define intervals in which events are expected. These intervals might be
expressed by conditions, or by time. If timing information is used in these requirements222.3 ISO 26262

they are likely to be present in both aspects, functional behavior and timing.
Real-Time Requirements assigned to the real-time aspect describe the timing behaviorof events or conditions. Patterns exist to describe properties like the period of periodic
events, the minimum inter-arrival time of sporadic events or the jitter of task activations.
Also, properties like the maximum distance between two events can be specified.
Safety Requirements assigned to the safety aspect describe the relation between faults,
failures and functions. Also hazards and the criticality of failures can be specified. A
major part of this thesis (see chapter 4) is detailing the safety view by providing extended
specification concepts and analysis methods.

2.3 ISO 26262
The ISO 26262 (2011) is the standard for the development of E/E (electrical/electronic)
automotive systems for vehicles below 3.5t of weight. With this standard the automotive
industry aimed at a summary of the current state-of-the-art techniques for developing
safety critical automotive systems to give a legal border in case of claim for damages.
Therefore, there is no need for certification, as it is the current practice in the avionics
domain, but it is the decision of the individual companies if they want to perform aqualification of their item, which needs to be performed by a sufficiently independent
assessor. The ISO 26262 standard consists of ten parts; the first nine are normative andthe last one is informative, containing explanatory texts, examples and guidelines. Eachpart consists of multiple clauses representing process steps that contain the requirements
and have defined input and output workproducts.
Parts 3–7 describe the main elements of the underlying V-Process-Model (Dröschel &Wiemers, 1999; Friedrich et al., 2009) (see Figure 2.3) proposing a top-down approach.
Parts 1, 2, 8 and 9 are applicable in parallel to the other parts, covering general techniquesapplicable in multiple phases of the V-model. Part 3 is the first item-related part in the
V-model of the ISO 26262 and subsumes the requirements concerned with the descriptionof the item, how risks are identified and classified, as well as how it is planned to react tothe risks and build a safe item. The clauses of this part are described in more detail in thefollowing sections. Part 4, covering the system level, is separated into two phases. Clauses
4-5 to 4-7 shall be performed before the development of hard- and software components
and result in a description of the system, while clauses 4-8 to 4-11 are performed after theitem has been built and include requirements for the final safety assessment and systemlevel tests. Parts 5 and 6 can be executed in parallel and includes the requirements forthe development of hardware and software elements.
It is the main idea of this standard to start the development process with an analysis of
the risks of the item and then derive and refine requirements that state how to avoid theserisks. Hence, the safety case (the argument that an item is sufficiently safe) is focused on acorrect refinement of the safety requirements and the correct implementation of the mostdetailed requirements in hardware and software. Therefore, it is essential to establish and232 Fundamentals
1. Vocabulary
2. Management of functional safety
2-6 Safety management during the concept phaseand the product development

2-5 Overall safety management

4. Product development at the system level

3. Concept phase
3-5 Item definition
3-6 Initiation of the safety lifecycle
3-7 Hazard analysis and risk
assessment
3-8 Functional safetyconcept

2-7 Safety management after the item´s releasefor production

4-5 Initiation of productdevelopment at the system level4-11 Release for production
4-10 Functional safety assessment

4-6 Specification of the technicalsafety requirements

4-9 Safety validation

4-7 System design

4-8 Item integration and testing

5. Product development at the
hardware level

6. Product development at thesoftware level

5-5 Initiation of productdevelopment at the hardware level
5-6 Specification of hardware
safety requirements
5-7 Hardware design

6-5 Initiation of productdevelopment at the software level

5-8 Evaluation of the hardware
architectural metrics

6-8 Software unit design andimplementation

5-9 Evaluation of the safety goal
violations due to random hardware
failures5-10 Hardware integration andtesting

7. Production and operation
7-5 Production
7-6 Operation, service(maintenance and repair), anddecommissioning

6-7 Software architectural design

6-9 Software unit testing
6-10 Software integration andtesting
6-11 Verification of software safety
requirements

8. Supporting processes
8-5 Interfaces within distributed developments
8-6 Specification and management of safety requirements
8-7 Configuration management
8-8 Change management
8-9 Verification

8-10 Documentation
8-11 Confidence in the use of software tools
8-12 Qualification of software components
8-13 Qualification of hardware components
8-14 Proven in use argument

9. ASIL-oriented and safety-oriented analyses
9-5 Requirements decomposition with respect to ASIL tailoring
9-6 Criteria for coexistence of elements

9-7 Analysis of dependent failures
9-8 Safety analyses

10. Guideline on ISO 26262

Figure 2.3 – The main development part of the ISO 26262 V-process model. Source: ISO
26262 (2011)

maintain the traceability between all safety requirements, the safety goals and the design
artifacts. To ease the traceability between artifacts and create a consistent system view,model-based approaches are considered the state of the art development approach in theautomotive industry (Armengaud et al., 2012; Born, Favaro, & Kath, 2010; Biehl, DeJiu,& Törngren, 2010; Armengaud, Bourrouilh, Griessnig, Martin, & Reichenpfader, 2012) aswell in the avionics industry (Peikenkamp et al., 2006). Even though tools exist (ikv++
technologies ag, 2010; Büchner, Glöe, & Mainka, 2003; MathWorks, 2011) to ease thehandling of traceability links and guide the engineer though the development process,most of the validation and verification tasks are solved using reviews or manual analyses.
The literature extensively covers all parts of this safety standard either for engineers(Ross, 2014) or for academics (Gebhardt, Rieger, Mottok, & Gießelbach, 2013). Instead,we will focus on part 3 of the ISO 26262.

24

2.3 ISO 26262

2.3.1 Item Definition
The Item Definition is a clause and a work-product containing the description of theitem in a high-level way. The basic functions are described along with the assumptions
on the environment. The environment description comprises the functional interfaceof the component like buses with their messages and also information regarding thenonfunctional environment like maximum operating temperature, humidity or physicalshock. Furthermore, references to similar, already built, systems shall be given together
with all already known requirements from the customer. The item definition is the basefor all the succeeding phases of the ISO 26262.

2.3.2 Hazard Analysis and Risk Assessment
A principle of the risk-based approach is to determine early how malfunctions in the system
could harm humans. These potential sources of harm are called hazards. This analysis isperformed in the “Hazard and Risk Analysis” (HARA) based on the item definition. This
analysis is therefore intentionally performed without knowledge of the implementationof the system, but purely on the intended functionality. This is an important factor in
the argument about the safety of the system, since on the functional level a complete
analysis can be performed, which is much more difficult on the implementation level.
Hence, for each function of the item, the potential malfunctions are described andclassified. The classification is based on three parameters: Severity, Exposure andControllability. The severity classifies the potential damage of a malfunction in terms of
the harm to persons affected by the item ranging from no injuries to possible death. The
exposure classifies the likeliness of the situation in which the hazard could occur. This isdifferent from the likeliness of the hazard to occur. For example, if the hazard can occur
only during highway driving, the probability of driving on a highway is considered to begreater than 10% of the average operating time. For multiple driving situations example
values are given in the standard. The last parameter of the classification of a hazard isgiven by the controllability of the hazard. This value reflects how well the driver or otheraffected persons can react to the hazard.
Resulting from the individual values for severity, exposure and controllability an ASIL
(automtotive safety integrity level) is calculated. This ASIL indicates how “critical” ahazard is. The ASIL ranges from A to D, where A is the lowest criticality and D is themost critical one. For hazards with a higher criticality more and also stricter requirements
apply than for lower classified hazards. There is a fifth classification, QM, which is evenlower than ASIL A and indicates, that the normal quality management is sufficient forthis kind of hazard. Figure 2.4 depicts the relation between the classifiers. The more
severe the consequences of a hazard may be, the more effort needs to be invested in thedevelopment process of the item to ensure that the hazard does not occur. This effort
can be reduced if the situation occurs seldom or a good controllability is given. The
resulting effort is represented by the ASIL.
If all hazards are classified, they are formulated as a requirement, typically that thehazard shall not occur, with the identified ASIL as a parameter of this high level safety25

2 Fundamentals

1

To
ler
ab
le

Controllability

Occurence Probability

Exposure

Severity

Ris
k

ASIL

0

ResidualRisknegligible

Severity

catastrophic

Figure 2.4 – Relation between the three classification factors resulting in the ASIL of ahazardous event.

requirement. These requirements are called safety goals and are the resulting workproductof the hazard analysis and risk assessment phase.

2.3.3 Functional Safety Concept
The ISO 26262 requires that proof be given how the safety goals shall be fulfilled.
The functional safety concept (FSC) is a functional, high level description of how toachieve this. The FSC consists of a first draft of the architecture of the system, called
preliminary architecture, and requirements that refine the safety goals, the functionalsafety requirements. The functional safety requirements shall cover (ISO 26262, 2011):• Fault detection and failure mitigation requirements: This implies thatfaults and failures are identified in the requirements and the architectural description.
The malfunctions described in the safety goals can be used as the failures of the top
level component. The faults are still on a functional level (e.g., that a calculationis performed incorrectly) rather than, for example, a broken hardware device orsoftware bug. Furthermore, it needs to be described which component is able todetect faults and how to react to them. Hence, failure mitigation is here understoodas graceful degradation.
• Transition to a safe state: One possible failure mitigation strategy is to switch
to a safe state after detecting a fault. This action is considered as a degrading fault
tolerance mechanism, that is, the functionality of the system is reduced while still
being safe. The degree of the inability to perform its intended operation may vary
(e.g., from only limiting the maximum performance to a complete shut down of26

2.3 ISO 26262

the system). Since each hazardous event has its own safe state(s), each has to be
noted and the components that perform a potential switch to a safe state need to
be clearly identifiable.
• Fault tolerance mechanisms: All fault tolerance mechanisms (i.e., componentsthat stop a fault from propagating in its original from) need to be identifiable in thearchitecture of the functional safety concept. According to Bozzano and Villafiorita(2003) and Storey (1996), a fault tolerance mechanism has a hypothesis stating a
set of assumptions when the fault tolerance mechanism is working correctly andwhen it fails. Such assumptions are, for example, the freedom from faults of thevoting component or the independence of the involved components.
• Fault detection and driver warning: If a fault cannot be mitigated and thefault tolerance time interval allows a late removal, it is a valid technique to alert
the driver about the fault and request a repair.
• Arbitration logic: Between multiple events, that are generated by components
simultaneously and shall describe the same property, a decision needs to be madeas to which values shall be processed and which discarded. Hence, arbitration isoften used in voting components to select which value of the multiple channels shallbe passed on.
The FSC needs to be verified with respect to two goals: The consistency and compliancewith the safety goals and the ability to mitigate or avoid the hazardous events.

2.3.4 Technical Safety Concept
The distinction between the functional and the technical safety concept not only is an
essential aspect of the ISO26262 but also is reflected in many development methodologies.
See, for example, the distinction between Virtual Function Bus view (AUTOSAR GbR,
2010) and Basic Software View in AUTOSAR, or in the integrated modular avionics
approach (Prisaznuk, 1992) from the avionic domain. The basic idea behind this approachis to provide an early statement about how to establish a safe system without considering
the actual implementation. This opens up the possibility of detecting design errors
impacting safety at a early stage of the development process and avoiding having to“add” safety to the product after the technical specification of the system functions iscompleted or parts of the system have already been built. This modus operandi directly
implies strict consistency and completeness rules that have to be applied to the mappingof functional to technical elements.

27

CHAPTER

Development of a
Semantic-based Impact Analysis
Changes are an inevitable part of today’s system engineering practice. Changes are
discussed in a very controversial way, from being the main driver of innovation (Eckert etal., 2004) to being considered as “the real killers” (Standish Group, 1995). Nevertheless,
it is common sense that changes are a main factor in a system’s overall costs. Fricke
et al. (2000) argues that, according to his case studies, about 30% of the work effort
is due to changes. This is not surprising, since changes can result from many different
sources (Eckert et al., 2004; Eckert, Weck, Keller, & Clarkson, 2009): changes onrequirements introduced by the customer, changes in standards relevant for certification,
adaptation to newly emerging technologies or even detected problems in the design.
Additionally, new systems are rarely built from scratch, but rely on modifications of
already existing ones. Hence, the management of changes has long been considered as arequirements and systems engineering subdiscipline (Sage & Rouse, 2009; Sommerville& Sawyer, 1997; Robertson & Robertson, 1999). Since an imprudent acceptance ofa change can easily cause a whole project to fail, “all possible implications should beconsidered before accepting or rejecting the proposal” (Kidd & Thompson, 2000). In thecurrently available literature, change management is mostly (Kidd & Thompson, 2000;
Jarratt et al., 2011; CMMI Product Team, 2010; ISO 10007, 2003; Lock & Kotonya, 1999)
approached from a process perspective. Figure 3.1 depicts two representative change
management processes that are very similar. After having received a change request,
the impact of the change is analyzed, then the changes are implemented, and then an
assessment of the implementation is performed. In none of these process models is theimpact analysis coupled with the implementation task.
This coupling becomes more important if the challenges of impact analyses are considered. Arnold and Bohner (1993) defined an impact analysis as “the activity of identifying
what to modify to accomplish a change, or of identifying the potential consequences of a29

3

3 Semantic Impact Analysis

Identification of
possible solution(s) tochange request

Before ApprovalEngineering change
request raised

Reject request

Change request
creation

Impact analysis

System releaseplanning

Delay request

Change trigger

Revise request

Old system

Risk / impact
assessment ofsolution(s)Implementation ofsolution

Review of particularchange process

After Approval

Selection and approvalof solution by change
board

During Approval

Implement changes(a) Change Management Process according
to Jarratt (2004)

Test & verify changes

System release &integration

New system(b) Change Management Process according
to Lock and Kotonya (1999)

Figure 3.1 – Impact analysis as a discipline within change management30

3.1 Related Work on Impact Analysis Techniqueschange.” Hence, he already mentions the two targets of impact analysis: being able toestimate cost and time, and correctly implementing a change.
The correctness of implementing a change is especially challenging, since nearly allchanges require further modification in the system to be implementable. A single change
to a requirement or an implementation will most likely create an inconsistency in thesystem, for example, a conflict with other requirements, an exceedance of resource usage
or simply the violation of cost restrictions. These further adaptations in the system arecalled change propagation (Eckert et al., 2004; Dick, 2005) or ripple effects (Bohner, 2002;
Bohner, 1996) or also a change snowball-effect (Terwiesch & Loch, 1999). These effects
have been investigated by researchers across the globe on various targets, like softwareor complete systems, including requirements or model artifacts. A summary of existing
impact analysis techniques dealing with change propagation are presented in Section 3.1.
In the context of safety critical embedded system, impact analyses become even more
important. These systems are subject to a strict quality assurance process guided bydomain specific standards like ISO 26262 (2011) (automotive) or ARP 4761 (1996)(aerospace). These standards aim to reduce the risk of harming people by a systematic
hazard analysis and structured breakdown of safety requirements and system design aswell as extensive analysis and testing of the system. Hence, the verification activities build
a major fraction of the total development costs of a system. The literature approximatesthis fraction at about 50% (Terwiesch & Loch, 1999) or even 75% of the costs for safety
critical systems (Laprie, 1994). Huge effort can be saved, if a determination of the systemparts that need to be re-verified is possible. While this can be achieved for some limitedchanges in software (refactoring) or upgrades of aircrafts that are especially designed to bemodified during their lifetime, none of the currently existing impact analysis techniques
is applicable for automotive safety concepts (see gap analysis in section 3.2).
In section 3.3 we present a novel impact analysis technique that is providing accurate
results, that enables a re-certification process and is based on a subset of verificationand validation activities. Hence, our impact analysis technique ensures to identify all
verification and validation activities that are affected by the change and not more. To
achieve this, the approach is based on the semantics of system requirements rather thanrelying on interconnections of components only. Based on this impact analysis process westate a set of requirements on the concrete language, which is used to express the safetyconcept of the system, in section 3.4. We conclude the results gained in section 3.5.

3.1 Related Work on Impact Analysis Techniques
Extensive comparison of impact analysis approaches have been performed in the last few
years.
Jarratt et al. (2011) summarize existing approaches to deal with engineering change
in their literature survey. They define an engineering change as an “[. . . ] alteration
made to parts, drawings or software that have already been released during the productdesign process. The change can be of any size or type; the change can involve any
number of people and take any length of time.” They categorize the existing literature31

3 Semantic Impact Analysis

in three categories of approaches. Techniques in the first category focus on the process,such as research related to change propagation. The second category is populated withapproaches that focus on tools to support changes in products. Finally, product oriented
approaches handle engineering change by developing systems that are easier to change.
The last category is not in the scope of this thesis.
In the field of software impact analysis a survey has been written in 2011 by Lehnert
and published as a technical report (Lehnert, 2011) summarizing more than 150 different
approaches. He classified the approaches with respect to the number of supported system
artifact types, like code, architectural components, documentation or requirements. He
discovered that only 13% of the available impact analysis techniques are concerned withmultiple artifact types (e.g., dealing with implementations and architectures at the sametime). Of these 13% only 17% have been evaluated. Hence, very little information about
the performance of impact analyses for complete systems is available.
Kilpinen (2008) analyzed in 2008 impact analysis techniques using the classification of
Bohner (1996), namely traceability based impact analysis and dependency based analysis.
While the first approaches are based on manually created tracelinks between system
artifacts, the approaches in the second category use more detailed information within
the system, like source code, to extract relations. Such relations can be established by,for example, usage of variables or functions. Kilpinen extends these categories with theclass of experience-based impact analysis approaches such as reviews, walk-throughs orinspections. These can be applied even if no traceability information is available, but
depend on skilled engineers.
Similar to Kilpinen and Bohner, Dick (2005) distinguished between explicit traceability(e.g., a satisfaction relation between requirements—in this thesis called refinement),
which is especially created for documenting the relation between artifacts, and implicit
traceability, given if there is another primary reason for establishing a relationship, suchas the assignment of code artifacts to a task.
Nearly all of the existing impact analysis techniques focus on improving the detectionof influences of changes on other system elements. But there remain two basic problems:missing a potential impact and highlighting too many possible candidates. Both problems
are equally important and can result in significant development costs due to unnecessary
verification activities or reduced quality of the system caused by missed ripple effects.
Also, both factors influence each other. If the set of possible candidates is too large,
the accuracy of detecting the real propagation candidates decreases and therefore theprobability of missing a necessary change increases. For safety critical systems it istherefore important to prune candidates as much as possible while still avoiding missed
propagations. Hence, in this thesis we use a classification of impact analysis approaches
that is different from the already existing ones, oriented on the accuracy of the approaches.
This classification is influenced to a great extent by the degree of available semantic
knowledge used in the relations between system artifacts.
Hence, we distinguish between approaches not being dependent on any tracebility
information (Section 3.1.1), approaches that use manually created traceability information (Section 3.1.2), approaches that extract traceability information out of behavioral

323.1 Related Work on Impact Analysis Techniquesmodels (Section 3.1.3), approaches that use probabilitic techniques to extract traceability
information out of previous changes (Section 3.1.4) and finally approaches that ensure
the identification of all candidates (Section3.1.5). Based on this classification we evaluate
academic approaches as well as commercial tools.

3.1.1 Impact Analysis without Tracing
Kilpinen (2008) identified a field of impact analysis that she calls “Experiental Impact
Analysis.” Approaches in this category do not use any form a traceability but relycompletely on the skill of the involved engineers. She argues that reviews or discussions
in the development team can reveal relations between artifacts that are not covered bytraceability. Ambler (2002) goes a step further and warns readers of his book on agile
developments techniques that the costs of traceability do not pay off. He argues thatin his experience companies do invest too much time in updating and maintaining thetraceability matrix. Hence, it is easier to ask one or two of the skilled engineers, who
know the system well. Similarly, Graaf, Lormans, and Toetenel (2003) mention that thetraceability is often not maintained because of insufficient tool support and untrained
personnel.
This approach is currently being practiced especially in small companies. The numbers
mentioned by Ambler—one or two very skilled developers who know the system well per
project—indicate that Ambler is not addressing big projects, in which it is unlikely thata single person is able to estimate the changes in all existing components.
Nuseibeh, Easterbrook, and Russo (2000) describe the problem of maintaining consistency among different design artifacts in the development process, like specifications, testplans, source code or change requests. While doing so, they provide a justification forAmbler’s statement. The relations between the mentioned development artifacts are thetypical targets for traceability management. They define inconsistency in this context
to “denote any situation in which a set of descriptions does not obey some relationshipthat should hold between them.” As an example they state a consistency rule: “In adata flow diagram, if a process is decomposed in a separate diagram, the input flows to
the parent process must be the same as the input flows to the child dataflow diagram.”
This is a possible consistency rule for a decomposition traceability link in data flow
diagrams. They argue that for large systems it is infeasible to maintain the consistencyof this traceability information since different developers update or construct elements or
relations. They reported from a use case in which it was not possible to perform formal
analyses on a software because the system changed to such a great extent during the
preparation of the analysis, that the results would have been worthless by the time theywould be available. While local consistency criteria might be possible to establish, they
do not guarantee global consistency. Since inconsistencies are unavoidable they suggest
using it as a tool to identify areas of the product that require more attention during thedesign. They propose an iterative change process for handling traceability inconsistencies
as depicted in Figure 3.2.
They do not intend to fix all inconsistencies, but intentionally foresee whether toignore or tolerate them. They consider inconsistencies as a risk and try to determine how

33

Measure
inconsistency

Defer

Tolerate

Circumvent

Resolve

Ameliorate

Monitor consequences ofhandling actions

IgnoreInconsistencies handledClassify

Apply rules

Refine rules

Refine rules
Identify

HandleInconsistencies characterized

Inconsistencies detected

Monitor for inconsistencies

Diagnose

LocateApply rules

Consistency
checking rules

Apply rules

Apply rules

3 Semantic Impact Analysis

Analyze impact
and risk

Figure 3.2 – Process how to handle inconsistencies according to (Nuseibeh, Easterbrook, &Russo, 2000)

expensive a problem this inconsistency could become. If the costs of such inconsistencies
are less than the effort of fixing them, the inconsistency is not resolved. With theeffort to maintain a consistent traceability and the therefore high associated costs, it isunderstandable that other, potentially cheaper, solutions are targeted.
Also Humphrey (2000) highlights the importance of reviews to identify faults. In
contrast to Ambler, his argumentation is based on the quality of reviews compared withtests. He has counted the keystroke errors he made while entering data or typing code.
He identified 28 keystroke errors on 1000 lines of code, from which 9.4% have not been
flagged by the compiler, leaving 2 to 3 random errors per 1000 lines of code. He argues
that the test coverage needs to be extremely high to identify all of these errors, since theyaffect the result in only a few situations. Hence, following traceability and re-running
the test associated with the components might not discover these faults; reviews are amuch better approach, in his opinion.
Still, especially for safety critical systems it is required by most of the safety standards
to perform tracing between system artifacts and keeping this traceability consistent.

34

3.1 Related Work on Impact Analysis Techniques

R1

R2

R1
R2

R4

X

X

X

R3
R4

R3

X
X

Table 3.1 – Traceability matrix to represent the dependencies between requirements. Source:
Sommerville and Sawyer (1997)

Hence, the large effort for maintaining traceability is not a valid argument for theseapproaches in this case.

3.1.2 Explicit Traceability Impact
While the opponents of traceability form a minority across the group of practitioners andresearchers in the field of system design, it is a common recommendation to establish andmaintain traceability between system artifacts (Gotel & Finkelstein, 1994; Robertson& Robertson, 1999; Ramesh, Powers, Stubbs, & Edwards, 1995). Also standards like
CMMI-DEV (CMMI Product Team, 2010) highlight the importance of traceability as
a discipline within requirements management. More specialized standards like the ISO
10007 (2003), which focuses on configuration management, states that traceability is oneof the key requirements for an effective change control.
Sommerville and Sawyer (1997) distinguish between six types of traceability links. These
links connect requirements on the one side to source code, rationals, other requirements,
architecture components, design components and interfaces on the other side. Whilesources, rationals and other requirements are self-explanatory, They classify architecturalcomponents on logical level as architecture, while calling components that are alreadyseparated into hardware and software, as design components. Interface requirements are
requirements on external elements to the system and considered as assumptions in thisthesis. In literature, the traceability between verification activities and requirements or
implementations, as well as documentation (Rajan & Wahl, 2013) is frequently missing.
Sommerville highlights the simplest representation of a relationship between requirements
in a traceability matrix (see Table 3.1).
Traceability matrices, representing directed dependencies, can be easily extended towards multiple dependency types such as refinement or satisfaction. This kind of traceability management is typically supported by tools such as IBM Rational DOORS (Software,2015) or Dassaults Reqtify (Dassault Systems, 2012), which additionally provide a more
integrated view on traceability in the system.
According to Leveson and Weiss (2004) traceability is considered as a fundamental
technique to build safe systems. They do not restrict traceability to relations between
requirements and software modules, but suggest extending the term to design feature35

3 Semantic Impact Analysis

and decisions. Especially if components are reused in another system this extended
traceability allows the use of stated assumptions to decide if a component fits in a different
context. In a contract-based design approach every requirement features an assumption
for exactly that purpose (see Section 2.1).
Also Dick (2005) and Robertson and Robertson (1999) highlight the importance oftraceability between design artifacts and design layers for change management of complex
systems such as aircrafts or weapon systems. Dick states two main benefits of traceability:
first, the understanding of the system is improved. Questions like “What is the roleof this component?” can easily answered. Second, and more important for this thesis,
traceability enables a semi-automatic impact analysis. Assuming that a proper tool
support is given, the relationships between requirements, software and hardware artifacts,
as well as documentation elements help to identify potentially affected entities. In contrast
to Ambler (2002), Dick is confident that the investment in traceability pays off. Dicksuggests a process for using traceability to conduct changes in a system. After creating a
traceability tree with all the linked elements connected to the changed one, pruning of
branches has to be performed by engineers since the existence of a link does not necessary
mean that a change propagates. Finally, changes are planned and applied in all affected
system layers.
A similar process is presented by Bohner (1996) introducing the term Software Change
Impact Analysis which he defines as “The determination of potential effects to a subject
system resulting from a proposed software change.” The process is depicted in Figure 3.3.
The Starting Impact Set (SIS) includes the initially changed elements as requested by
the change specification. The Candidate Impact Set (CIS) is the set of system elementsthat are potentially affected by the change. This information is based on the traceability
links established in the system. Bohner (1996) distinguishes between directly impacted
elements in the system and indirectly impacted ones. An element, he uses the term
software life-cycle objects (SLOs), is potentially directly impacted if there is a direct
traceability relation in the traceability matrix (see Figure 3.3). Bohner defines an SLO
as any artifact such as variables or requirements. Because the traceability does notnecessarily mean that the change propagates to that component, he introduces the set of
False Positive Impacts (FPIS), and creates loops in the process causing the Discovered
Impact Set (DIS) to grow over time. In addition, he mentions that even if a reachability
graph is generated starting from the changed element, in most software projects the wholesystem is connected. To deal with this problem he describes two approaches, a structural
one and a semantical one. The structural approach creates a distance matrix between
one SLO and the other elements in the system. He suggests investing more effort in theanalysis of closely related components, because, he argues, the probability of a change
propagation is dependent upon the distance of two elements. To reduce the number offalse positives any further, Bohner recommends including more semantic informationin the impact analysis process. With this semantic information he refers to the type of
relationship between SLOs (e.g., a variable defined within a class or a decomposition
relationship between requirements). He does not provide any further details on how to
use this information. Approaches using the semantics of software can be found in the36

3.1 Related Work on Impact Analysis Techniques

Software Change
Proposals

SoftwareExamineSoftware andChangeSpeciifcation

Starting Impact
Set (SIS)

Trace Potential
Impacts

Candidate Impact
Set (CIS)

SLO0
SLO9

SLO1

False Positive
Impact Set (FPIS)
Perform
Software
ChangeActual Impact
Set (AIS)

SLO8

SLO2

SLO7

SLO3

SLO4

SLO6

Discovered Impact
Set (DIS)AIS = CIS + DIS FPIS(a) The Impact Analysis Process

SLO5(b) Traceability between Software LifeCycle Objects (SLOs)

Figure 3.3 – Impact analysis process as suggested by Bohner (1996)

next section.
Sommerville and Sawyer (1997) mention a similar idea to improve the quality of
explicit traceability impact analysis. They advise using a Data Dictionary that includes
information about all names used in a system (such as a description of the element),
where it is defined and used, who defined the name and when. This can apply to different
types of entities, such as objects, process elements, attributes. Without explicitly namingit, he introduces design ontologies for software components. The process of maintaining
this data dictionary is mainly manual as is the usage for conducting an impact analysis
based on it. Still, he mentions that computer-aided software engineering (CASE) tools,
can support the generation of parts of the data dictionary.
Current change management tools used in a systems engineering context like Reqtify(Dassault Systems, 2012), IBM Rational Change (IBM, 2012) or Atego Workbench (Atego,2012) focus also on the traceability between requirements and/or system artifacts toperform impact analyses. If changes occur, these tools highlight the system artifacts

37

3 Semantic Impact Analysis

directly or indirectly connected by tracelinks to a changed element. Figure 3.4 shows theanalysis view of IBM Reqtify and Atego Workbench.
All the approaches presented in this section share the common problem that manuallycreated traceability is not sufficient to clearly identify system elements that need to bechanged from the system elements that are potentially affected by a change (Nuseibeh &Easterbrook, 2000). Therefore, it is still a manual and fault prone process to track thechanges across the chain of traceability. The idea of using the distance in a traceability
graph to prune results assumes that the change propagates in a breadth-first manner.
Hence it would make sense to limit the investigation of elements this way. Still, fromthe experience of the author, the propagation behavior is nearly the opposite. If arequirement is changed, it is not necessary to change multiple or even all subrequirements
to compensate for the created inconsistencies, but a single or very few requirements
are selected. Taking the example of resource consumption, this behavior is based on
the assumption that it is cheaper to save a greater amount of resources in a single
subcomponent, than reducing the resource consumption of every subcomponent to asmall degree. Furthermore, if there is no slack initially foreseen in the specification, thechange needs to propagate either to the top level, to change the expected behavior of
the system, or to propagate to an implementation, requiring modifications in hardware
or software. That pure traceability based impact analyses do not perform well (e.g.,
in contrast to approaches based on changes histories) has also been identified by otherresearchers (Hassan & Holt, 2004). Nevertheless, it is a factor that improves quality if
used together with other change propagation indicators (Lock & Kotonya, 1999).
However, approaches are needed that use more information than the manually createdtraceability to automatically and reliably prune the space of possible impact propagation
candidates.

3.1.3 Implicit Traceability Impact Analysis
Implicit traceability impact analysis approaches are typically applied to software (Bohner,
1996). Podgurski and Clarke (1990) identified two types of relationships that can beextracted and then used for impact analysis: control dependence and data-flow dependence.
The first type uses the call structure of programs. In this category we present call-graphanalysis and path based impact analysis in this section. The later category analyzes theuse of variables within the program, such as the program slicing technique.
Ryder and Tip (2001) presented a change impact analysis for object oriented software
based on call graphs. A call graph (Ryder, 1979) for Program P consists of the nodes
that represent methods or procedures and edges that represent call relationships between
them. Algorithms exist (Tip & Palsberg, 2000) that are able to compute a call graph forvarious programming languages. Their change impact analysis is based on eight atomic
changes, that are listed in Table 3.2. While most of the changes are self-explanatory,
the LC changes related to dynamic method binding (method dispatching) of object
oriented programs. To tackle the problem of inheritance she extends classical call graphswith an additional lookup table to store how calls to objects resolve, depending on
their runtime type. The triples in the table are of the form 〈runtimeReceiverType,38

3.1 Related Work on Impact Analysis Techniques(a) Impact analysis view of IBM Reqtify, for each element upstream anddownstream impact is highlighted(b) The impact analysis within Artego Workbench provides a traceability viewof elements to a specified trace depth, 4 in this picture.

Figure 3.4 – Impact analysis as provided by current industrial traceability tools39

3 Semantic Impact Analysis

Abbrev.

DescriptionAC

Add an empty class

DC

Delete an empty classAM

Add an empty method

DM

Delete an empty method

CM

Change body of method

LC

Change virtual method lookup

AF

Add a field

DF

Delete a field

Table 3.2 – The atomic changes for object oriented call graph based impact analysis ofsoftware. Source: Ryder and Tip (2001)

Operator

Description

A<B

A is a direct descendent of B

A≤B

A is a direct descendent of B, or A = B

A ≤∗ B

B is an ancestor of A, or A = B

A <∗ B

B is an ancestor of A, but B 6= A

Table 3.3 – Notation for inheritance relations. Source: Ryder and Tip (2001)

staticMethodSignature, actualMethodBound〉. The formal definition is given in Figure 3.5
based on the inheritance notation depicted in Table 3.3.
Based on these change types the impact analysis is performed to determine which test
drivers are impacted by a change. Ryder defines test drivers as classes that exercise partsof the program and are used for regression testing. The first operation of the impact
analysis is to determine the changes in the code (e.g., by using a tool like diff ) and split
them up into partial ordered atomic changes. Ryder claims that all changes can be split
up using their selection of atomic changes.
Then, for a given set of test drivers T = {t1 , . . . tn } the methods tested by ti aredenoted N (P, ti ) (nodes in the call graph) and the relations respectively E(P, ti ) (edges)
and, hence, form the call graph for ti . The affected tests (TA ) by a set of changes A are
the tests that refer to a changed or deleted method (CM ∪ DM ), or are affected by achange in the dynamic binding of methods (virtual dispatch). The formal definition of
TA is given in figure 3.6.
Compared with the manually created traceability approaches, the call graph based
approach is much more detailed, and the relations (i.e., the calls between methods) are
extracted automatically, limiting the probability of failures in the traceability matrix.

40

3.1 Related Work on Impact Analysis Techniques

Lookup = {〈C, A.m, B.m〉|class A contains virtual method m, C ≤∗ B ≤∗ A,
class B contains virtual nethod m,there is no class B 0 that contains method m such that C ≤∗ B 0 <∗ B}
LC = {〈a, b〉}|〈a, b, c〉 ∈ {(Lookupold − Lookupnew ) ∪ (Lookupnew − Lookupold )}Figure 3.5 – Definition of lookup and LC. Source: Ryder and Tip (2001)

TA = {ti |ti ∈ T, N (P, ti ) ∩ (CM ∪ DM ) 6= ∅} ∪{ti |ti ∈ T, n ∈ N (P, ti ), b →B A.m ∈ E(P, ti ), 〈B, X.m〉 ∈ LC, B <∗ A ≤∗ X}
Figure 3.6 – Definition of the affected test drivers TA given a set of change A

The presented approach is only usable for a syntactic impact analysis. The test that are
not part of TA are sure to compile, but it cannot be claimed that the behavior of thesystem is still correct or not. Changes in the behavior can possibly propagate further
through the system, which is not covered by the analysis. Still, compared with classicaltraceability based impact analyses, some changes can be identified as nondestructive,
such as adding an empty class. The most frequent use of an impact analysis is the change
of a methods body. All tests that are called from within this body are considered to
be potentially impacted (see Figure 3.6). This overestimation is similar to the analyses
presented in Section 3.1.2.
Another technique to conduct change impact analysis on software is program slicing.
Program slicing has been introduced by Weiser (1981), when he defines this approach as“a method used by experienced computer programmers for abstracting from programs.
Starting from a subset of a program’s behavior, slicing reduces that program to a minimal
form that still produces that behavior. The reduced program, called a ‘slice,’ is anindependent program guaranteed to faithfully represent the original program within thedomain of the specified subset of behavior.” Hence, a slice S(v, n) of program P , with v
being a set of variables and n a statement in P is called a slicing criteria. Slicing tools,
both academic and commercial, are available; an overview of some of them can be foundin (Korpi & Koskinen, 2007).
Gallagher and Lyle (1991) presented an approach to use these program slices fora software change impact analysis. They introduce a new type of slice, a so-called
decomposition slice S(v), which includes all the statements of program P which are in theslices of S(v, n), where n are all statements where v is part of an output (output(P, v))
or the last statement (last) in P .
S(v) =[

S(v, n)|N = {output(P, n) ∪ last}

n∈N

41

3 Semantic Impact Analysis

Furthermore, they define output-restricted slices, as slices where all output operations
are removed. Two output restricted decomposition slices S(v) and S(w) are considered
independent if S(v) ∩ S(w) = ∅. In addition, if v 6= w and S(v) ⊂ S(w) the slice S(v) isdefined as strongly dependent on S(w). An output restricted slice that is not strongly
dependent on any other slice is called a maximal slice. If S(v) and S(w) are outputrestricted decomposition slices of Program P , statement in S(v) ∩ S(w) are considered
as slice dependent statement.
Based on these definitions they built a framework that considers changes in a decomposition slice. They consider only two types of changes in programs, deletions and additions.
A change of an existing line is handled as both, first a deletion, then an addition. They
provide four rules of how to deal with changes:• Independent Statements may be deleted from a decomposition slide, because they
do not affect the computation of the complement.
• Assignment statements that target independent variables may be added anywhere
in a decomposition slice, since they are unknown to the complement.
• Logical expressions and output statements may be added anywhere in the decomposition slice, since they do not even affect the computation of the changed
slice.
• New Control statements that surround any dependent statement will cause thecomplement to change.
Furthermore, if the complement is affected, Gallagher and Lyle also provide an algorithm
for how to support the developer in incorporating the change.
They elaborate extensively on the properties of decomposition slices, but could be
more precise with respect to the changes. They provide specific rules like adding an
assignment statement or changing the control structure. It is hard to judge if their chosenclassification is complete. Although there exist extensions to slicing, like the integrationof macros in C/C++ (Vidács, Beszédes, & Ferenc, 2007), it is an assumption of all slicing
approaches that the developer is maintaining the complete code base. The decomposition
slices introduced by Gallagher and Lyle separate the code on a per-line basis, which isan unsuitable separation for allowing shared work across multiple developers. Hence,
the approach is not applicable for compositional impact analysis. Still, it simplifies thehandling of changes for the individual developers, since they can implement the changes
on a much smaller program, which increases the overview and hence reduces faults.
The problem of both approaches, call graph analysis and static program slicing, isthat the result presented to the developer is much bigger than is actually needed. To
reduce the unnecessarily identified elements Law and Rothermel (2003) introduced a new
approach called path based impact analysis. The idea of that technique is to consider
only those procedures that are on the execution path of a changed procedure P . That is,
the affected procedures are either still on the program call-stack after P returns or are
called after P and potentially use values returned by it.

42

3.1 Related Work on Impact Analysis Techniques

They instrument binaries to get call traces based on real executions of the program.
Since it is possible to instrument binary code it is not necessary for their approach tohave the source code of the program available. A trace they consider might look like this:M BrACDrErrrrx
Capital letters represent calls to procedures, lower case r represents a return of aprocedure and the x represents the end of the trace. The analysis is based on searches onthese traces. They distinguish between forward and backward searches in the trace. With
forward searches they can determine which functions are called directly or indirectly
by P . These are important since they might use values that have a different meaning
after the changes in P and consequently produce a wrong output. The same applies
for procedures that are called after P has returned. With backward searches they candetermine the procedures in which P returns into and, hence, use data that has beenaltered and requires further adaptations.
This technique is a dynamic technique, therefore highly dependent upon the testcases used to generate the traces. Even though they reduce the set of possible affected
procedures, they introduce the risk of missing important propagations, because there
was no test-case that has the needed behavior. Therefore the approach is not suitable
for safety critical systems because the probability of missing relations is currently notprecisely explored.

3.1.4 Impact Analyses using Change Histories
Most of the implicit traceability impact analysis techniques are only applicable forsoftware and it is currently not possible to judge the accuracy of the approaches. Hence,
multiple different probabilistic techniques have been proposed that rely on previous
changes on the current or similar systems and try to quantify the reliability of the impact
determination.
Clarkson et al. (2004) have proposed a technique based on a Design Structure Matrix (Steward, 1981). This Matrix is very similar to a traceability matrix as presented bySommerville and Sawyer (1997) (see Table 3.1). In addition, the design structure matrix
may also be used to represent relations between design tasks.
Before the impact of a change can be determined, it is necessary to perform an initial
analysis of the current and similar older systems. This initial analysis is separated into
three stages. In the first stage a product model is created. This activity is basicallyconcerned with creating a decomposition of the system into smaller subsystems, encapsulating parts of the functionality. Clarkson et al. recommend using not more than 50
subcomponents for a system.
In the second stage the likelihood of a change propagation and the degree of impact
is estimated and entered in a design structure matrix (DSM) (see Figure 3.1). The
likelihood of change propagation is defined as the average probability that a change
in a component leads to a change in another component. The impact is the average
proportion of work that needs to be re-done if the change occurs. These matrices are43

3 Semantic Impact Analysis

L

a

b

c

a

-

0.6 0.1

b

0.8

-

0.8

c

0.9 0.4

-

I

a

b

c

a

Likelihood
b
I

a

b

c

a

-

0.6 0.1

b

0.2

-

0.9

c

0.4 0.2-

Impact

I
c

Risk

L

Figure 3.7 – A graphical product risk matrix. Source: Clarkson, Simons, and Eckert (2004)

filled based on data that has been collected during previous builds of similar systems orexpert knowledge.
Changes can propagate directly to another component or indirectly across multiple
other components. Hence, in the third stage of the initial phase the different paths
are evaluated on which a change may propagate between components. As a result, therisk matrix is updated according to the possible propagation paths. The combined risk
matrix may be represented in a graphical form (see Figure 3.7) so that the influences oflikelihood and impact can still be identified.
After this initial phase, the effect of incoming changes can be estimated. After
identifying the component that needs to be changed, the possible impacts can be seen in
the product risk matrix. To better display the different affected components Clarkson etal. suggest a logarithmic case plot, which also represents the affected systems, but has
the benefit that components with an equal risk are located on a straight line (see Figure
3.8)
Clarkson et al. evaluated the approach on various changes applied to a helicopter from
GKN Westland Helicopters and had predicted the changes in a reasonably good way.
Still, the main contribution of this approach is the visualization of risks and impacts. The
critical input are the design structure matrix and the estimates for likelihood and impactthat are extracted from already performed changes. Hence, the quality of the approach
does depend mostly on the quality of the collected data and the experts involved in theprocess.
Another probabilistic approach has been developed by Lock and Kotonya (1999), who
address the problem of identifying the relevant propagation path from the huge set of
possible paths, which are identified using various traceability techniques. In the first44

3.1 Related Work on Impact Analysis Techniques
1

high

X
X

X
0
0

Risk

Combined Impact

X

X

Combined Likelihoodlow1

Figure 3.8 – A case risk plot. Source: Clarkson, Simons, and Eckert (2004)

step of their approach, they collect traceability information of the system from multiple
sources.
The first source is pre-recorded traceability information. This source refers to theexplicit traceability presented in Section 3.1.2 of this thesis, which is the class of manuallycreated traceability links by the developers. The second source is a dependency extraction
from behavioral models (see Section 3.1.3), which use forward and backward search of
calling relationships to extract possible propagation paths. The third source is called
plain experience analysis. This source uses the recorded data of previous changes to thesystem. Each change and its recorded impacts provides a small fraction of the traceability
relation. The source is called “plain,” since the identified impact paths are used as is;similarities between the paths are not evaluated. In contrast to the first two sources, theresults of the experience analysis may already contain probabilistic information. The
fourth source of traceability information is a new technique developed by the authors
called extrapolation analysis. This analysis uses a partial set of direct impacts, as collectedby the plain experience analysis, and tries to calculate the direct and indirect impacts
for the whole system. The main idea is to identify previous changes that are similar
to the current change based on the directly impacted elements. Hence, it is likely thatthe indirect impacts will also be similar. The last source of information is a so-calledcertainty analysis. The certainty analysis captures the belief of the developers as to how
accurate a specification element is. This completeness is expressed within two values.
First, the degree of definition (DoD), which is a value between 0 and 1 indicating how
complete the element is defined. Second, the certainty of definition(CoD), is definedas the confidence that the entered information is correct. The resulting total certainty
is defined as Ctotal = DoD · CoD. This information, representing the reliability of an
possibly impacted element, is an indicator which impact prediction is more likely to becorrect.
The proposed integrated framework uses all the above mentioned information to selectthe most probable impacts from the set of candidates. Hence, all traceability informationis combined into a traceability structure. A probability Ppath is assigned to each of the
propagation paths. If multiple relationships exist between entities (e.g., pre-coded and45

3 Semantic Impact Analysis

Cautious Prob.

1.0

Median Prob.
Sureness Prob.
Probability of Impact

0.8

0.6

0.4

0.2

1

2
Impactable Depth

3

Figure 3.9 – Influence of sureness and cautious probabilities on total propagation probability

extracted from behavioral models) the probability will increase. The probabilities gained
from previous experience can be used identically. To the values gained from this approachan adjustment is proposed using the collected certainty values. Two probability values
are derived using the certainty:• The sureness probability is the likelihood for a change to propagate based on theinformation available. The sureness probability Psure is hence defined as Ppath ·Cpath .
That is, if the information of an element is not reliable, this will reduce the pathprobability.
• The cautious probability is representing the risk of impact based on the information
available. The cautious probability is defined as ¬Pcautious = ¬Ppath · Cpath .
Figure 3.9 highlights how these values can be used to characterize the probabilities ofimpacted elements. In addition the authors describe in detail how to combine the resultsfrom the various sources, how to resolve duplicates and how to represent the cyclic natureof change propagation. Also, they present a variety of techniques for pruning the spaceof possibly affected components (e.g., by imposing a probability cut-off or focusing on a
special behavioral aspect of the system).
The approach integrates many of the available data in a common model to assess theprobability of a change impact propagation. Unfortunately they have not provided any
evaluation results. Nevertheless, many of the used data are still dependent upon the
judgment of experienced engineers.

46

3.1 Related Work on Impact Analysis Techniques

Hassan and Holt (2004) analyzed different change propagation heuristics for software.
They distinguished between the data source heuristics of how to identify change relations
between entities and pruning techniques that help to select the most appropriate candidates from a set of potentially impacted elements. They analyzed the typical sources,
such as call dependencies between methods, but also had a closer look at uncommon
techniques such as historical co-change (elements that are changed frequently at thesame time), developer data (code that is frequently edited by the same developer) or codelayout (entities that are encapsulated together, e.g., in a directory in the file-system ora class). They discovered based on an analysis of large open source software projects,
that the historical co-relation between changes, and the structural grouping of elementsin the same file-system directory or file are much more accurate than call dependencies
between software methods. However, the idea of using the developer as an indicator forchanges, that is, that files edited by the same person are related and therefore it is likelythat change propagates, has been proven false. They built a hybrid heuristic using thegained results that performed well in comparison with the single parameter heuristics.
More probabilistic approaches exist, such as an extension to program slicing developedby Santelices and Harrold (2010). Nevertheless, the drawback of all of these approaches is
the remaining probability, that a propagated change is missed. If the impact analysis shallbe used in a certification process to determine which verification and validation activities
need to be re-run, the probability for remaining effects needs to be at least as high as if
all tests of the system have been re-run. Nevertheless, to achieve a similar probability forthe overall system, the impact detection probability needs to be significantly larger thanthe probability for each individual test in the system. (On this topic see the evaluation
results in Section 5.) Still, the best hybrid approach evaluated by Hassan and Holt
(2004) featured a recall of ≈ 0.5 and a precision of ≈ 0.5, that is, they suggest halfof the actual impacts and that half of their suggestions are correct. This accuracy issimilar to testing and review methods, which ranges between 40% and 60% detection
accuracy (Runeson, Andersson, Thelin, Andrews, & Berling, 2006; Boehm & Basili, 2005)
and can be significantly increased by automated testing techniques such as requirements
based testing. Hence, the accuracy of the impact detection approaches is not sufficientfor pruning verification and validation activities in a change management process.

3.1.5 Impact Analyses Avoiding Recertification
There are only very few approaches available to avoid a complete re-certification ofa system after changes. Buckley, Mens, Zenger, Rashid, and Kniesel (2005) as wellas Kilpinen (2008) mention refactoring (Mens & Tourwe, 2004; Fowler, Beck, Brant,
Opdyke, & Roberts, 1999) as an impact analysis technique to fully automatically deal
with changes in software. Opdyke (1992) defines refactoring as “reorganization plansthat support change [...] [and] do not change the behavior of a program; that is, if the
program is called twice (before and after a refactoring) with the same set of inputs, theresulting set of output values will be the same.” With refactoring some changes can be
implemented automatically (Casais, 1994), like replacing library calls to optimize thememory usage (Buckley et al., 2005).

47

3 Semantic Impact Analysis

Still, the types of operations are limited. Opdyke (1992) lists eight types of refactorings
that have been identified while analyzing the evolution of a complex software over two
years:• defining an abstract superclass of one or more existing classes• specializing a class by defining subclasses, and using subclassing to eliminate
conditional tests• changing how the whole/part association between classes is modeled, from using
inheritance to using an instance hierarchy of aggregates and their components• moving a class within and among inheritance hierarchies• moving member variables and functions• replacing a code segment with a function call
• changing the names of classes, variables and functions• replacing unrestricted access to member variables with a more abstract interface
This list, using C++ terminology, indicates that the possibilities applying refactoring
are limited. Still, to implement more complex changes the application of refactoring
techniques might be part of the whole process and reduce the introduction of faults inthe software.
Another approach to avoid full re-certification has been presented by Nicholson etal. (2000) addressing explicitly safety critical systems. They distinguish between two
types of systems. First, Federated Systems, where each function or application is hosted
on separate hardware units, that communicate with each other. Still, these units are
considered independent from the point of view of certification. Second, Integrated Modular
Systems (IMS) are especially built to allow an easy update of the system and reduce thecosts of re-certification later on. Their re-certification approach is based on the use of an
IMS. Nicholson represented the safety case in the goal structuring notation (see Section
4.1.2). They presented eight different types of changes (e.g., a change of an application
where the effects are contained within a single partition or changes to the underlying
hardware platform). For each of these change classes a process and change recovery
actions need to be defined, which are part of the initial certification of the product.
The concept underlying this approach is the use of equivalence, that is, the certificationof “families” of variants. The recovery actions shall prove that the modified systems
argumentation is equivalent to the old argument. This process is depicted in Figure 3.10.
To identify to which category a particular change belongs, they propose a recursive,
three phase impact analysis (see Figure 3.11). In this very generic process the potentially
impacted elements are identified according to rules. However, these rules are not further
detailed. In a second step the actual impact needs to be determined, which is also notdescribed in any more detail. Still, the basis for the impact analysis is the availability

48

3.1 Related Work on Impact Analysis Techniques

Damage to System

Recovery of System

Step 1

Step 2

Step 3

Step 4

Proposemodification &develop to
appropriate DAL

Identify impact
paths ofmodifications

Decide on
certificationargument
recovery action

Provide evidenceof recovery ofaffected argument

Figure 3.10 – Process of using recovery actions to show equivalence of the new safetyargumentation compared with the one prior to the change, according toNicholson, Conmy, Bate, and McDermid (2000)(i) Identify
potential Impact(ii) Identify actual
Impact(iii) execute step(i) for all impacted
items

Figure 3.11 – A very generic, recursive process of conduction of the impact analysis within
an IMS, according to Nicholson, Conmy, Bate, and McDermid (2000)

of slack in the system. This stems from the fact that IMS are built to be extended andmodified after production, hence the available resources are not used until a criticallimit has been reached. This means that, for example, the memory or the processing
power of the underlying hardware, is over-dimensioned at the point of initial release. By
the consequent use of service oriented interfaces and hardware abstraction layers it ispossible to contain the change within a partition without complicated techniques. Still,for example, in the case of the change of timing requirements, it needs to be proved thatthe slack is sufficient to cover the needs of the change.
Although the approach of Nicholson is applicable for avionic systems, it cannot betransferred to the automotive domain. While the presented approach deals with the
problem of altering a released system, that is especially built for later updates, in theautomotive domain later changes to a released system are rare and not part of there-qualification. The problem in the automotive domain stems from the evolution of one
series to another, hence slack is non-existent in a very competitive market. Furthermore,
the supporting techniques to separate functions are not always available.

49

3 Semantic Impact Analysis

3.2 Gap Identification and Goals for Impact Analysis
From the various impact analysis techniques presented in the previous section none
is suited to exclude unaffected verification activities in a functional automotive safetyconcept from being re-executed. Pure traceability based approaches are not able todetermine a stop criterion and overestimate the change in a magnitude comparable tothe complete system. Although being able to restrict the changes with a stop criterion,
software based impact analyses are not suited for two reasons. First, logical systemdescriptions are not necessarily fully implemented in software, and second, the approaches
target compilability and are not able to reason on the semantically correct behavior.
Probabilistic impact analysis approaches are able to give estimates of how likely apropagation will occur, but the precision of these approaches is not sufficient to establish
the same level of confidence for the whole system as if all verification activities were
executed again. To achieve this, the results need to be significantly more precise than the
average probability of a system or integration test to miss a fault. Since these approaches
are based on the existing changes performed to the same or similar system, the size ofthe available data history is a critical factor for the accuracy of the impact prediction.
It is very unlikely that the available data will drastically increase, since most systems
will not be produced long enough, before they are be replaced by a new development.
The impact analysis presented for integrated modular systems is not restricted by thealready mentioned flaws. It is applicable for systems, does provide a stop criterion
and targets correctness of the system. Still, it is based on existing slack and isolation
mechanisms between components in the system. For avionic systems it is likely that
extensive modification will be performed to an aircraft, the lifetime of which is typicallymore than 30 years (Jiang, 2013). Hence, the manufacturers anticipate the need for
additional space for later added upgrades in the system that can be used. For automotive
systems this is currently not the case. Although, software updates are becoming more
and more important since bugs in the recent past have led to accidents (CBSNEWS,2010), only rarely will new features be added after production. Hence, the new impact
analysis approach needs to be able to contain changes without the existence of extensive
slack.
As a result, four main technical requirements need to be fulfilled:• The new impact analysis shall provide a stop criterion for change propagation in
the system.
• The new impact analysis shall be able to detect impacts on logical architectures.
• The new impact analysis shall use the semantical correctness of the system as thetarget for impact detection.
• The new impact analysis shall be able to contain changes with very little slack
available in the system.

50

3.3 Impact Analysis on Contract-based System

introduce

Design Rules

Requirements

Represented asContracts

is based on
semantics ofapply toSystem Artifacts

Tracelinks

Implementations

VV Activities

Architecture

Relation between
Correctness

Maintains

Impact Process

executesFigure 3.12 – Relations between entities involved in the impact analysis

3.3 Impact Analysis on Contract-based System
In this section a novel impact analysis approach is presented, to implement the requirements stated in section 3.2. Here, the process and necessary verification activities aredetailed, while in chapter 4 the concrete language to express safety concepts is elaborated.
Figure 3.12 depicts the relations between the elements involved in the process. The
impact analysis process is based on an abstract system representation detailed in section
3.3.1 encompassing e.g. the requirements, expressed as contracts, the implementations
and the architecture. Also the design rules of how to apply contract based design are
described. The correctness criterion, which is the property that shall be maintained by
the impact analysis is described in section 3.3.2.

3.3.1 System Representation
Lehnert (2011) used the set of supported design artifacts as a classification of impact
analysis approaches. According to him only 13% of the approaches support multiple typesof artifacts, like code, structural models, requirements or documentation. In our approach
we want to support all relevant artifacts necessary to describe and analyze functionalsafety concepts. Hence we integrate behavioral, structural and process artifacts.
An overview of the artifacts is shown in figure 3.13, which are explained in detail in
the following two sections.
The analysis process itself is not limited to specific languages or representation formats,therefore we base our approach on a abstract system model. The selection of theelements within this model is based on research performed to identify the common systemengineering artifacts used for safety critical systems (Rajan & Wahl, 2013; Baumgart et51

3 Semantic Impact Analysis

R1

C1

refinessatisfiespart of

R2

R4

R3

R5

R6

C2

R7

implements

C3

C4

C5

C6

C7

I1

I2

I3

I4

Figure 3.13 – Overview of the System Artifacts and Tracelinks repected by the Impact
Analysisal., 2011). In addition, the needs of the ISO 26262 (see Section 2.3) had to be considered.
We chose to make the system representation as generic as possible, to allow an applicationin many scenarios that are potentially more specific.
System Entities
We identified three main types of artifacts to describe functional safety concepts (see Table
3.4). A structural model, sometimes also called architectural model (Baumgart et al.,2011). Typical structural models in the automotive domain are AUTOSAR (AUTOSAR
GbR, 2014), EAST-ADL (ATESST2 Consortium, 2010) or SysML (OMG SysML, 2012).
The most generic common element in these models is a component identifying a systempart (or even the system in total). These components are de-composable, that is, they
can be divided into subcomponents. Components have associated ports that represent the
input and output values. The components are therefore used to describe the interface ofthe elements of a system. This system description is called the preliminary architecture in
the ISO 26262 (see Section 2.3). The second main type is the description of the behavior
of components. This description may have two different representations. On higher
abstraction levels the behavior is represented as requirements, describing the intended
behavior of the components. If the system is broken down to a sufficient degree thebehavior can implemented. This implementation itself can have various forms, like source
code, an executable model, or even a mechanical prototype. The concrete characteristics
are not important for our approach. While the ISO 26262 explicitly forces the use of arequirements breakdown structure, it does not directly require the existence of behavioral
models for the functional safety concept. Nevertheless, the ability to avoid hazardous
events needs to be shown, and the standard provides an example note stating that “the52

3.3 Impact Analysis on Contract-based System

EntityDescription

Component

Decomposable, model-based representation of
the interface of a system or system part. A
component consists of ports that represent the
inputs and outputs

Requirement

Requirements represent functionality or properties that the component it is attached to shallfulfill

Implementation

Implementations represent the concrete, executable behavior of a component. This might besoftware (code or functional model) or a hardware implementation.

Table 3.4 – Abstract entities used in the impact analysis process

ability to mitigate or to avoid a hazardous event can be evaluated by tests, trials or
expert judgment; with prototypes, studies, subject tests, or simulations” (ISO 26262,
2011). Hence, executable models are needed to perform tests or simulations.
System Relations
As indicated by various authors (Ramesh et al., 1995; Ambler, 2002; Nuseibeh et al.,2000) the traceability in a complex system is very expensive to maintain. Hence, it is
one of our goals to reduce the needed links between the system artifacts to a minimum.
We base the impact analysis on three traceability links, as depicted in Table 3.5. These
links exist in most of the analyzed system models (ATESST2 Consortium, 2010; OMG
SysML, 2012; Baumgart et al., 2011) and represent the most basic relations in a system.
Furthermore, the chosen tracelinks cover the relations defined between contracts (seeSection 2.1.3). In addition, all the presented links are required by the ISO 26262 andtherefore do not provide any additional effort.
The satisfy link establishes a connection between a requirement and a component.
It indicates that a component shall have the behavior described by a requirement. It
does not indicate that the component is actually fulfilling that requirement. This isindicated by a test case that proves the correct relationship between a component, therequirement and the implementation of the component. The refine link is created between
requirements on different decomposition levels. It indicates that a requirement is broken
down into finer granular requirements that cover in total the source of the link. Again,
this relation indicates only that this relation shall exist; a V&V case needs to provethe correctness of this link. The implementation link connects a component with its
implementation. In the current process we assume that there is a single implementation
for a component. This is a realistic assumption, since the interface of the implementation53

3 Semantic Impact Analysis

Tracelink

Description

Satisfy

RefineSourceTargetCardinalities

Connects a requirement Comp.
with a model component.

Req.

1,1..*A requirement is decom- Req.
posed into multiple more
concrete requirements.

Req.

1,1..*

Comp.

1,0..1

Implementation Connects an implemen- Impl.
tation to a component.

Table 3.5 – Tracelinks necessary for our impact analysis

needs to fit to the interface of the component. Internally, the implementation might
consist out of many submodels, or source code files, which is in this representation
abstracted towards a single implementation. Each implementation needs to have one
associated component, while not every component is expected to have an implementation.
The source and target types are introduced in Table 3.5 to define the semantics of thelink, in the actual impact analysis process the links are expected to be traversed in both
directions.
We use the following notation for traversing links in this work. Each link can betraversed in both directions, each direction is indicated by an arrow above the function→−
name. We define the function S (c) to return all requirements connected to a component←−c. The function S (r) returns the component a requirement is attached to. A requirement
can only be attached to a single component. The refinement relation can be traversed
→
−
←
−
→
−
←
−
using R (r) and R (r). R () returns the refined requirement, while R () returns the refinees.
→−
Similarly the function I (i) returns the component that is connected to implementation←−i and I (c) returns the implementation that is connected to component c.
Using Contracts
Contracts provide a semantic framework to reason on relations between requirements
and implementations (see Section 2.1 for an introduction into contract semantics). One
essential relation is refinement (), which is a binary relation between requirements thatindicates that one requirement is a correct specialization of another. Together with theparallel composition (⊗) virtual integration testing (VIT) can be performed. While using
VIT, real integration testing can be completely omitted in favor of a set of refinement
and satisfaction analyses. For the system represented in Figure 3.13, this means, that if
is has been shown that implementation I1 to I4 are correctly representing the behavior
expressed by the requirements R1 to R4 , and all requirements refinement relations arecorrect, then it follows that the system composed from the implementations fulfills allstated requirements.

543.3 Impact Analysis on Contract-based System

Hence, contracts are the favorable form to represent the systems requirements R. In
order to use contracts in the development process a few constraints need to be complied
to. Most of all, a structured handling of requirements is needed. All requirements need
to be organized in a requirements breakdown structure established by refine links:
Structural Constraint 1. Each Requirement r needs to be either a top-level requirement←−←−of the system or it refines exactly one requirement q: r ∈ R (q) → ∀s∈R|s6=q : r ∈/ R (s)Although the requirements break-down is often not obeyed completely in practice (Gotel& Finkelstein, 1994), the ISO 26262 requires this kind of tracing anyway by proposing
a “hierarchical approach by which the safety goals are determined as a result of thehazard analysis and risk assessment. The functional safety requirements are then refinedfrom the safety goals” (ISO 26262, 2011). Nevertheless, as an additional constraint, thisrefinement needs to be represented in the architecture of the system as well:←−
Structural Constraint 2. For two Requirement r and r0 for which holds that r0 ∈ R (r)it needs to follow that there is a direct part relation between the associated components:
←
−
←
−←
−
S (r0 ) ∈ P ( S (r)). This property also holds vice versa.
There are also constraints on how the requirements need to be formulated. As statedin section 2.1, contracts are defined over the interface of a component. Based on aassumption on the input, a guarantee of the value of the outputs is given. This restricts
the requirements to mention only values that are provided by the ports, directly connected
to a component.
Structural Constraint 3. The mentioned values S(r) in a requirement r are available←−
on the components interface 2( S (r)):←−
ps ∈ S(r) → ∃p ∈ 2( S (r)) : p = s
This kind of specification is advised by many practitioners (see Sommerville and
Sawyer (1997) or Oertel et al. (2013)) as well as requirements and system engineering
standards (ISO/IEC, 2011; ISO/IEC 12207, 2008). Black box specifications ensure
the writing of implementation free requirements, since it is not possible to name or
describe internal elements of the component. The ISO/IEC 29148 (ISO/IEC, 2011)
states the absence of implementation information as one of the main properties: “Therequirement, while addressing what is necessary and sufficient in the system, avoids
placing unnecessary constraints on the architectural design. The objective is to be
implementation-independent. The requirement states what is required, not how therequirement should be met.” Another benefit of the interface based specification is the
avoidance of overlaps in the scopes of requirements. Hence, it is not possible that arequirement assumes properties in a distinct part of the system. Such requirements bear
the danger of being not correctly assigned to the architecture.
In addition to the constraints on the requirements, there are also constraints on thearchitecture. We assume all components to be well connected. Although this is a typical55

3 Semantic Impact Analysis
Singlecomponent loops
Component A
Ports having
two directions

Multiple values
at a single port
Component B

Component C
Unconnected
Ports

Connecting two
inputs/outputs

Figure 3.14 – Faulty connectors between ports

constraint for all port based specification languages, there are some special restrictions
that apply only in the context of contracts.
Figure 3.14 depicts incorrectly connected ports. Connections between two input ports,
using a port simultaneously as an input and an output as well as not connected ports are
generally considered as faults in the design. Loops on a single component and multiple
connections to a single port are contract specific problems. A loop on a single component
does not provide any benefit, since time can only evolve inside a component and theconnections are transferring the data immediately, the information at the output and the
input would always be identical. Hence, this way of modeling is not applicable to design
control loops. If time shall evolve while sending a signal between components (e.g., byusing a bus), the channel needs to be explicitly modeled using a dedicated component.
This component may then introduce a delay. The argumentation for prohibiting multiple
connections to an output port is very similar. Since the values are expected to be identical
if they are connected, there are no semantics defined to “over-ride” a value if multiple
ports are connected to one output. If such a behavior is needed, the overruling strategy
needs to be specified for a dedicated component that has multiple input and one output
port. On the other hand it is not a problem to connect an input port to multiple inputs.
To avoid the necessity for a separate check of the connections, we define the values inthe system only over its name. A direction is therefore also only assigned once, for bothconnected ports. Hence, we assume identity between ports having the same value.
Structural Constraint 4. Two ports p1 and p2 on components c1 and c2 that areconnected by a delegation or assembly connector, need to be named identical and have thesame direction.
Using this design rule, we avoid having to state further rules for the connectors between
ports and can simply rely on the port names.
Verification Activities
Resulting from the set of tracelinks and the relations used between contracts, a set ofverification activities can be selected, that allows analysis of the existing relations, so that56

3.3 Impact Analysis on Contract-based System

R1
R1
Vr

R2

R3

R4

R1

C1

R1

Vs

(a) Refinement Analysis Vr

I1(b) Satisfaction Analysis Vs

Vi

R1

C1

refinesRn

Requirement

satisfies

Cn

Component

part of

In

Implementation

implements

Vn

Verification Activity

I1Vievaluates(c) Interface Analysis Vi(d) Link and Component Type Overview

Figure 3.15 – The verification activities used in the impact analysis process

the impact analysis process specified in section 3.3.4 is able to make use of them. These
are the necessary verification activities for the process to ensure system consistency. Whilein this section the verification activities are presented, the systems consistency criterion
is described in section 3.3.2. Additionally to the here shown verification activities, there
might be additional ones, like tests or reviews, that are linked to the elements. However,
only the here mentioned V&V cases are used for the change propagation detection.
The refinement analysis proves the correctness of the split up of requirements. This
analysis refers directly to the refinement relation on contracts described in section 2.1.3.
Since refinement is defined on two requirements only, the refinement analysis is building
the parallel composition Rp of the subrequirements R1 . . . Rn with:Rp (R) =

O

x

x∈R

The parallel composition needs to specify at least one possible solution, otherwise
refinement is considered as failed, too. The result of Vr (rtop , R) is defined as:(

Vr (rtop , R) =10

if Rp (R)  rtop ∧ [[Rp (R)]] 6= ∅if Rp (R)  rtop

The satisfaction analysis indicates if an implementation M implements the behavior
required by requirement r. This analysis directly refers to the satisfaction operator

57

3 Semantic Impact Analysis

defined in Section 2.1. Hence, the analysis is defined as:(Vs (M, r) =1
0

if M |= r
if M 6|= r

Since the satisfaction analysis is based on requirements and implementations, it does
not rely on components. The relation between the component c and its ports 2(c) andthe signals S(r) mentioned in the requirement r as well as the relation between thecomponents ports and the implementation ports 2(i) need to be checked separately. To
avoid a re-mapping of names, we define two ports pa , pb or signals as port-equivalentp(=) if the name and type (if available) match. This interface check is performed by theInterface analysis Vi (r, c):(

Vi (r, c) =10p

if ∀s ∈ S(r) : ∃p ∈ 2(c) : s = ppif ∃s ∈ S(r) : @p ∈ 2(c) : s = p

Furthermore, the interface check can be applied to components and implementations
as well:(

Vi (c, i) =

1
0

p

p

if ∀s ∈ P (i) : ∃p ∈ P (c) : s = p ∧ ∀p ∈ P (c) : ∃s ∈ P (i) : s = pppif ∃s ∈ P (i) : @p ∈ P (c) : s = p ∨ ∃p ∈ P (c) : @s ∈ P (i) : s = p

3.3.2 Correctness as a Target for Impact Analysis
Impact analyses have different targets as seen in the related work section. For example,
Ryder and Tip (2001) used a call-graph analysis to detect impacts that could compromise
the compilability of source code. Nicholson et al. (2000) wants to detect impacts on
resource usage like memory consumption, execution time or bus occupation. In contrast
to these single property oriented impact analyses, we want to guarantee the correct
semantic behavior of the total system with respect to all stated requirements. Correctnessof requirements was extensively analyzed in the CESAR Project (Rajan & Wahl, 2013).
A set of requirements A0 is correct if “requirements in A0 allow us to reach goal g(A),i.e.: in a given context Γ if the requirements are all satisfied the goal g(A) will also besatisfied. On the contrary, if one cannot prove that g(A) is satisfied when A0 is complete,then we can conclude that there are errors in A0 . Consequently, if A0 is not correctwith respect to A then at least one requirement raises a problem in A0 . In other words,
this requirement cannot be satisfied in the context Γ for one of several reasons: it isfalse or its realization is unfeasible [...].” (Benveniste et al., 2011). Correctness requires
completeness, which is given if there are sufficient requirements in A0 to prove that thegoal g(A) can be deduced from A0 .
In the context of this work, we can translate this definition to:
Definition 5 (System Correctness). A structural consistent system consisting of a set

58

3.3 Impact Analysis on Contract-based Systemof requirements R, a set of components C and a set of Implementations I is correct if:←−∀r∈R : Vi (r, S (r)) = 1 ∧→−∀i∈I : Vi ( I (i), i) = 1 ∧←−−∀r∈R|←: Vr (r, R (r)) = 1 ∧R (r)6=∅→−∀i∈I : Vs (i, I (i)) = 1
Hence, the three verification activities (Refinement Analysis, Satisfaction Analysis andInterface Analysis) build the base for the correctness criterion of the system. We consider
each tracelink an analysis target. The correctness criterion of the CESAR project can beestablished using our definition and the virtual integration corollary (see Section 2.1.4).
For all subrequirements Ri of R, with their implementations Mi , composed to M, it holds:
" n
^
i=1

Vs (Mi , Ri ) ∧ Vr

n
O
i=1

!

Ri , R ∧n^#

Vi (Ri , Mi ) → Vs (M, R) = 1 ∧ Vi (R, M)

i=1

If the implementations correctly implement the behavior of the subrequirements andthe subrequirements are a correct refinement of the top-level requirement it directly
follows that the composition of the implementations (M) satisfies the behavior requiredby R. Note that the definition of satisfaction (see Section 2.1) requires the contracts
and the components inputs and outputs to coincide. Hence, Vi has to hold for all
subcomponents Mi and their connected Requirements Ri . To conclude that Vi also holds
for R and M, the subelements Mi need to be properly connected to each other and to M.
These structural constraints have been detailed in section 3.3.1. We consider components
to be the implementation resulting from the composition of the subcomponents or
implementations.
This relation can be applied recursively within the requirements breakdown structure
to show the correct implementation of all requirements.
It needs to be mentioned, that virtual integration checking of the relations can only
be performed if requirements are stated in a precise way. Hence, the semantics ofthe requirements need to be unambiguous. The formal language needed to represent
requirements in a functional safety concept, is described in chapter 4. Also the concrete
realization of the verification activities Vs and Vr are described in that chapter in thesections 4.5.2 and 4.5.1.

3.3.3 Change Operations
Eckert (Eckert et al., 2004) distinguishes between initiated changes and emergent changes.
While changes in the first category have a cause outside of the system, such as a customer
requirement change, emergent changes are necessary because of problems that have been
identified during the development process. In this thesis we start with initiated changes
and detect the emergent changes, which cause the change propagation. This implies, that
we are starting from a consistent system, modify parts and want to establish a consistent59

3 Semantic Impact Analysis

system again.
The atomic elements that can be changed are requirements, implementations andcomponents. Verification activities are represented as own entities in the implementation(see Section 6.1) but are in this section considered as the formal representation of systemproperties. Hence, they are part of the argumentation but cannot be modified by theuser.
To maintain the system in a structural consistent state, we define the change operations
in a preserving way. That is, that the structural consistency cannot be violated by
performing changes to the system. Hence, many typical change operations, like deletinga requirement or adding a component, cannot be executed alone, but require further
modifications, either on other system elements or on the traceability structure. Thechange operations and the additionally necessary actions on elements and traceability
are listed in Table 3.6. The selected change operations are a subset of more possible
operations, but are sufficient to create all structural consistent systems.
The modification of existing elements is a very common change in the evolution ofexisting systems. These types of changes do not alter the structural consistency of thesystem, hence no additional modifications to system elements and traceability links arenecessary.
In contrast, adding a single element would taint the structural consistency of a system.
If a requirement is added to the system, two different scenarios are possible. Either therequirement is added to an atomic component, or the requirement is added higher in thehierarchy of the requirements break-down structure. In the first case only the traceability
needs to be corrected, by creating the needed refinement link to the corresponding toplevel requirement and a link to the component that shall fulfill the new requirement. If arequirement is added higher in the hierarchy of the system, additional requirements need
to be added along the refinement chain and linked to the corresponding component, until
the lowest level of components is reached and an implementation is directly connectedto that component. This is necessary to avoid requirements continuing to exist in thesystem that are not refined.
There are also two cases of how to add a component to the system. If a component is
added to one of the atomic components in the architecture, the implementation of theextended component needs to be removed and an implementation needs to be added to
the newly added component. Also a requirement needs to be created and linked to theadded component. If a component is added on higher levels of the system hierarchy, a newrequirement shall be created and linked to the new component. Also the refinement link
to a requirement one level higher in the refinement structure needs to added. Furthermore,
an implementation shall be added and linked to the new component. In both cases it
needs to be noted, that a problem in identifying a proper top-level requirement for the
newly added requirement indicates that the feature is added at the wrong position in thesystem hierarchy.
Adding an implementation is not necessary. Since there is only one implementation
allowed for each atomic component, the structure of the system is modified by modifying
the components. This is an operation that is needed in any practical scenario, but would60

3.3 Impact Analysis on Contract-based System

Operation

TargetElement Updates

Traceability Updates

ModifyRequirement

none

none

Implementation none

none

Component

none

none

Requirement(atomic)none

add link to existing component, add link to existing top-level requirement

Requirement(intermediate)

add at least one requirement for each level ofcomponents below the initially assigned component

link all requirement tocomponents, update refinement links between requirements

Component(atomic)

delete implementation ofextended component, add
implementation, add atleast one requirement

create part link, link implementation to component, link requirement tocomponent, create refine
link for requirement(s).

Component(intermediate)

add implementation, add
at least one requirementlink implementation, linkrequirement(s), link component

Requirement

delete all subrequire- delete all tracelinks conments,
deleteall nected to deleted elecomponents and im- ments
plementation that do
not have associatedrequirements

Component(with siblings)

delete subcomponents, delete all tracelinks todelete connected im- deleted elements
plementation,
deleteconnected requirements,

Component(w/o siblings)

delete all subcomponents,
delete all requirements,
delete connected implementation(s), add new
implementation

Add

Deletedelete all tracelinks todeleted elements, add
tracelink to newly created
implementation

Table 3.6 – Change operations overview. For some operation and target combinations
multiple integration scenarios exist61

3 Semantic Impact Analysis

cause redundant description in this thesis.
Deleting elements also requires corrective measures to preserve the structural consistency of the system. If a requirement is deleted all refined requirements need to be deleted
as well. In addition, the components and implementations that do not have associatedrequirements need to be removed. The tracelinks connected to deleted elements need to
be deleted as well. To delete a component, also all subcomponents and their connected
requirements need to be deleted. If there are sibling components to the deleted component
a new implementation needs to be created to avoid atomic components existing without
an implementation.
The selection of change operations is complete in a sense that all possible correct
systems can be built using this operation, starting from an already existing correct system.
Modifications to the existing component structure are performed by adding or removing
requirements and the structure is modified by adding or deleting components.
Although changes in tracelinks are a possible change scenario, we do not explicitly
address these changes. Each re-link of a tracelink can be represented as a removal andan addition of the connected system artifacts. In the following we use the term change
to encompass modification, addition and deletion.

3.3.4 Impact Analysis Process
To establish a linear relation between the size of the change and the effort to re-verify
the system, it is necessary to identify precisely which verification activities are affectedby a change. The process of identifying these verification activities and establishing aconsistent state of the system after changes is depicted in Figure 3.16.

Baseline

ChangeSelectCompensation
Candidates
Engineeryes

Re-runVerification
Activities

FailedVerification
Activities?

noBaseline

Figure 3.16 – Basic process for handling change requests

Starting from a correct system an initial modification of the system is performed. As

62

3.3 Impact Analysis on Contract-based System

extensively discussed in the related work section (see Section 3.1) this change might
propagate and cause further changes to become necessary. To identify the affected
elements by this change, the verification activities related to the changed element need
to be re-executed. Table 3.7 lists the verification activities to be re-executed based on
the element type that has been changed and the change operation. The verification
activities are selected under the principle that all tracelinks connected to a changed
element need to be re-evaluated. The supported types of changes, and their additional
modifications of the system to maintain the structural consistency are listed in Table
3.6. These additional changes for an operation are marked in Table 3.7 with a plus-sign,
indicating the added elements, and a minus-sign indicating removed elements.

Operation

Element

ModifyRequirement r

Add

Activities to Execute
→
−
←
−→
−
Vr ( R (r), R ( R (r)))←−
Vr (r, R (r))←−
Vi (r, S (r))←−←−
Vs (r, I ( S (r)))

Implementation i→−
Vi ( I (i), i)
→ −
→
∀r∈−
: Vs (r, i)
S ( I (i))

Component c←−
Vi (c, I (c))
→ ←
−
∀r∈−
V (r, c)S ( I (c)) i

Requirement r(atomic)←−←−
Vs (r, I ( S (r)))←−
Vi (r, S (r))
→
−
←
−→
−
Vr ( R (r), R ( R (r)))

Requirement ri(intermediate)+ requirements Rc←−←−∀r∈Rc : Vs (r, I ( S (r)))←−∀r∈Rc : Vi (r, S (r))
→
−
←
−→
−
∀r∈Rc : Vr ( R (r), R ( R (r)))

Component c (atomic)- implementation id+ implementation ia+ requirement r

Vi (c, ia )Vi (r, c)
→
−
←
−→
−
Vr ( R (r), R ( R (r)))
Vs (r, ia )Component c (intermediate)+ requirement r+ implementation i

Vi (c, ia )Vi (r, c)
→
−
←
−→
−
Vr ( R (r), R ( R (r)))
Vs (r, ia )63

3 Semantic Impact Analysis

Operation

Element

DeleteRequirement-requirement Rr
Component c(with siblings)- Requirement r- subcomponents Cs- implementations Is- subrequirements Rs
Component c(w/o siblings)- requirement r- subrequirements R- subcomponents C- implementation I+ implementation (id )Activities to Execute
→
−
←
−→
−
Vr ( R (r), R ( R (r))) 1
→
−
←
−→
−
Vr ( R (r), R ( R (r)))→−
Vs ( R (r), id )
→
−
←
−→
−
Vr ( R (r), R ( R (r)))

Table 3.7 – Verification activities to be restarted based on the type of change. Additionalchanges according to Table 3.6 are marked with +/- signs

If requirements are changed, it is essential to check the effects on the existing refinement
→
−
←
−→
−
relations towards the top level (Vr ( R (r), R ( R (r)))) and towards the implementation←−level (Vr (r, R (r))). This allows semantical identification if there is a change propagation
towards the top-level or the implementation-level in the requirements breakdown structureof the system. Hence, based on the semantics of the requirements a criterion exists tostop the change propagation in the system. This is not possible in pure traceability based
impact analyses. Even impact analyses based on source code are not capable of analyzing
effects on the semantic behavior.
In addition to the refinement check the compatibility with the component needs to←−be analyzed (Vi (r, S (r))). And, for the lowest level of requirements it also needs to be←−←−checked if they are still compliant to the implementation (Vs (r, I ( S (r)))).
If implementations are changed, the relations are simpler than in the case of requirements. It needs to be ensured that there is no impact on the linked requirements. In
case of performance optimization in the implementation it can be expected that therequirements are still met. Nevertheless, for each requirement connected a proof is1

If no requirements remain for a component the component needs to be deleted. By this operation
additional verification need to be performed.

643.3 Impact Analysis on Contract-based System→ −→needed, that is: ∀r∈−
: Vs (r, i). Furthermore, the compliance of the interface
S ( I (i))
of the implementation to the interface of the components needs to be analyzed again→−(Vi ( I (i), i)).
Modifications to components result only in interface checks. Nevertheless, the change
might propagate further to requirements and implementations as well. The interface checks
←
−
→ ←
−
whether the implementation Vi (c, I (c)) and all connected requirements ∀r∈−
V (r, c)S ( I (c)) ineed to be re-evaluated.
Requirements added to atomic components need to be checked against the implementa←−←−←−tion (Vs (r, I ( S (r)))) and the interface of the component (Vi (r, S (r))). Also the refine→−←−→−ment relation to the higher-level requirement needs to be evaluated: Vr ( R (r), R ( R (r))).
If the requirement is added higher in the hierarchy of the system, additional requirements
need to be created that refine the added requirement until the implementation level isreached. Hence, all interface, refine and satisfy analyses need to be executed for all therequirements.
Components added at the lowest level of refinement requires the current implementation
to be removed, and an implementation needs to be added on the new component. Hence,
also a requirement needs to be created for the newly added component. The verification
activities linked to all of these elements need to be re-executed. While adding anintermediate component there is no need to remove an implementation, but the set ofverification activities is identical to the case of an atomic component.
Deleting a requirement will also force the removal of all subrequirements. Nevertheless,only the refinement relation that had the changed requirement in its set of refining
→
−
←
−→
−
requirements needs to be re-verified: Vr ( R (r), R ( R (r))). Since removing a requirementfrom a component will not affect any satisfy or interface relations, no further analyses
need to be performed. It needs to be noted that components that do not have associatedrequirements need to be deleted. We do not include this deletion of components in thechange operation of the requirement. These deletions start a new operation, that requires
the re-validation of further system components.
There are two delete operations for components defined. Either there exist no siblingcomponents on the same level, in which case an implementation needs to be created,or there exists at least one sibling, in which case it is not necessary to create any
additional implementations. Therefore, since the requirements of the components are
→
−
←
−→
−
deleted, the refinement relation needs to be re-verified (Vr ( R (r), R ( R (r)))) as does thesatisfaction relation between the newly introduced implementation and its requirements→−
for components with no siblings (Vs ( R (r), id )).
As the next step in the process, for all failed verification activities, further actions
are required. If all performed tests have been run successfully, a new consistent stateof the system has been reached. We show this property later in this section. For eachfailed verification activity, at least one modification in the set of compensation candidates
is necessary. The potential candidates for additional changes directly follow from theinvolved elements in the individual verification activities. A comprehensive list of thecompensation candidates is depicted in Table 3.8. It is possible that a single change

653 Semantic Impact Analysis

Verification Activity

Compensation Candidates

Vr (r, R)

modify r or p ∈ R
add requirement(s) to R
delete requirement(s) from R

Vi (r, c)modify r or c

Vi (c, i)modify c or iVs (r, c)modify r or cTable 3.8 – Which elements are considered as compensation candidates

resolves multiple failed verification activities.
The modification on the system, again, needs to be evaluated. This cycle of verification
activities and modification is repeated, until all verification activities are successful.
To show that this approach contains a change in the identified region, and there is nochange effect outside the identified system elements, we need to show that:• There is no impact on any system element on abstraction levels higher than thelast changed, but successful refinement activity.
• There is no impact on lower abstraction levels in the system if the refinement
activity on requirements has a positive outcome.
• Implementation and interface checks are already contained in the requirements
refinement structure.
Requirements build the backbone for change propagation in the presented impact
analysis approach. Figure 3.17 indicates the possible paths of change propagation in asystem. The connections refer directly to the verification activities that are executed after
changed as described in Table 3.7. It needs to be noted that the part relations between
components are not used for change propagation. Instead, if the interface of components→−
c is changed, first the relation to the requirements R = S (c) is checked. If there arechanges in the requirements needed, also changes in the set of refining requirements
S
←
−
←
−
→
Rr = r∈−R (r) are needed. These will then influence the components P (c).
S (c)Following this observation it needs to be shown that the refinement relations of requirements are able to contain the changes: If the refinement relation that includes a changed
→
−
←
−→
−
requirement r0 in the set of subrequirements (Vr ( R (r0 ), R ( R (r0 )))) delivers a positive
test result the traces described by the parallel composition of the new subrequirements
N
− −
→
[[ ←
]] is a subset of the set of traces of requirement [[r0 ]], as by the definition of
R ( R (r0 ))refinement. Hence, both the new set and the old set of refined requirements correctly
refine the higher-level requirement. As a consequence, all refine relations that make useof the higher-level requirement r are not affected by the change. The same principle
applies for the refinement relation that uses the changed requirement as a top-level663.3 Impact Analysis on Contract-based System

R1

C1

R2

R4

R3

R5

C2

R6

R7

I1

C4

I2

I3

C3

C5

C6

C7

I4

Figure 3.17 – Illustration of the possible change propagation paths, according to the usedverification activities Vs , Vi , Vr

requirement. If this relation is still correct, the set of refining requirements is still a subset
N←−−of the changed requirement Vr (r0 , R (r0 )) = 1 ⇔ [[ ←]] ⊆ [[r0 ]]. Hence, the refining
R (r0 )
requirements do not need to be modified and all lower refinement relations are still valid.
Hence, we have shown that a semantic impact analysis is possible using the systems
requirements. It is determined on the behavior of system elements if a change propagatesto a different component, we can directly exclude elements from the set of possibly
impacted elements even if they are connected by a tracelink. The engineers of the system
are still in full control over their changes, since they select the component from the set ofcompensation candidates manually. This is the preferred way, since the experience of theengineers enables them to quickly select good compensation candidates. A time intensive
design space exploration would require much time and is potentially even more faulty.
The here proposed change impact process focuses on the needed verification properties
in the system. But other tests and or reviews are very likely to be performed to gain
certification for the applicable engineering and safety standards. These tests can beconnected to elements in the system they are evaluating. If it has been discovered that
there is no impact on the elements they are connected to, the result of the additional
test/verification activity is not affected. Examples for such activities could be reviews
or field tests. Again, the same restriction applies here as for the whole process. The
tests are not affected only if all relevant aspects of the system are modeled. Therefore,
requirements need to exist that state the expected results of the test.

67

3 Semantic Impact Analysis

3.3.5 Supporting the Compensation Candidate Selection
In contrast to impact analysis approaches that fully automatically implement a change
in the system, for example, by predefined rules (Lehnert, Farooq, & Riebisch, 2013),
our experience with engineers conducting impact analysis indicates that approaches arefavored in which the control of the applied changes is still in the hands of the engineer.
Also Ambler (Ambler, 2002) and Humphrey (Humphrey, 2000) indicate that experienced
developers are able to give good estimates of how a change needs to be implemented.
Still, in addition to the identification of affected V&V activities, a guidance in theimpact process is appreciated by the developers (de la Vara, Borg, Wnuk, & Moonen,2014). Hence, we provide an approach that helps the developers in selecting suitablecompensation candidates. Nevertheless, this is not possible and needed in every case,but there exist situations, in which a change can be implemented in a cost-efficient way
which is hard to recognize by the developer. These cases are best suited for automatedguidance.
The system situation in which we want to support the engineer is characterized by
the availability of slack. Slack is defined by Nicholson et al. (2000) as the budget oftime or space, that is not yet used by any system component. These margins exist often,
either intentionally or unintentionally in systems. Nicholson mentions the intentionallyintroduced slack, which is used to improve the maintainability of a device for later
upgrades. Unintentionally introduced slack results from uncertainty in the development
process with respect to the later used hardware or software solution. That is, that at
the beginning of the development process it might not be obvious how much resources
the realization of a function might consume. Hence, the resource consumption needs
to be conservatively over-approximated. If it turns out later, that a solution needs lessresources, the slack is present in the refinement structure of the requirements. This slackis used to compensate changes. Eckert et al. (2004) is calling these elements absorbers in
the design space.
Intentionally introduced slack (see Figure 3.18 ECU1) is typically larger, than unintentionally introduced slack, as seen on ECU2. This results from competitive markets,
in which slack is an avoidable cost. Furthermore, unintentionally introduced slack is
not present only on the lowest levels of decomposition in the systems architecture. It
is possible that slack is available on higher levels of refinement/decomposition. This
results from requirements that do not use all the available resources since it is alreadyknown that they are not necessary. This situation can occur if complete branches ofrequirements and implementations are transferred between projects.
In the automotive domain, slack in not introduced intentionally, hence, the buffers
available for changes are extremely small. Nevertheless, even in this scenario we are able
to shift slack to compensate changes. With respect to the scenario in Figure 3.18, achange in Task1 could lead to a violation of the resources assigned to ECU1. In case of theexisting impact techniques, this would require changes in the implementation of Task2
to meet the resource limit of Task1. Still, if the limit of ECU1 is only slightly exceeded,
we could increase also the resource limit of ECU1, by reducing the resource limit of ECU2.
The limit of ECU2 can be reduced to the sum of resources consumed by Task3 and Task4.

68

3.3 Impact Analysis on Contract-based System

SystemResource (100%)

Intentional Slack

Unintentional Slack

ECU 1

ECU 2

Resource (30%)

Resource (70%)

Task 1

Task 2

Task 3

Task 4

Resource (40%)

Resource (20%)

Resource (65%)

Resource (30%)

Figure 3.18 – Slack introduced intentionally (ECU1) and unintentionally (ECU2) as aresource. The values indicate the percentage used of the available ressources
one level above.

Hence, a change in Task1 can be compensated by a chain of resource shifts, without theneed to change a single further implementation. In case of a complex system, it is nearly
impossible even for a skilled developer to discover this compensation possibility, hence
an automated technique to identify the compensation strategy is needed.
In terms of trace semantics and contracts the slack between requirement rtop and a setof subrequirements R is given by:∆T = [[rtop ]]\[[

O

]]

r∈R

N

If the refinement relation between rtop and r∈R is given, rtop can be safely replacedNby r∈R since the set of traces of rtop is only reduced, and no additional traces outside
the set of [[rtop ]] are added. That is, none of the already verified properties is tainted.
We describe the shifting process using two algorithms (see Algorithm 1 and Algorithm2). We define the drain function that replaces a requirement with the composition of its
subrequirements recursively in Algorithm 1. The worst-case running time of the DRAIN
function depends on the number of requirements |R| in the system and the running timeof the parallel composition T (⊗) which might differ between different representations ofrequirements. Hence, an asymptotic upper bound of O(|R|) · T (⊗) exists. The algorithm
obviously terminates.
Using the drain function we can try to prevent a change in a requirement rc topropagate towards the implementation, avoiding costly changes on hard- or software.

69

3 Semantic Impact Analysis
Algorithm 1 recursive procedure to retrieve a set of traces of a subtree of the requirements break-down structure without slack
Require: r
1: procedure drain(r)←−2:
if R (r) = ∅ then3:
return r
4:
else
←
−
5:
R = R (r)6:
Rnew = ∅7:
for all q ∈ R do
8:
Rnew = Rnew ∪ drain(q)9:
end for10:
return ⊗r∈Rnew
11:
end if
12: end procedure

Hence, the starting point is a failed verification activity Vr (rtop , R), with rc ∈ R, withrc denoting the changed requirement. In terms of Figure 3.18 this could result from atask, that cannot meet its expected resource constraints, and therefore the corresponding
requirement stating the guaranteed resources is changed. The algorithm to check if it
is possible to compensate the change by relaxing the resource constraints higher in therequirements break-down structure is depicted in Algorithm 2. The algorithm proceeds
iteratively to increase the included part of the system in the analysis. Hence, first only
one refinement level above rtop will be considered, then two levels, and so on, until the
top-level requirement of the system is reached. The check returns if such a compensation
by draining slack is possible and indicates to which level changes in the requirements
would be necessary. Based on this information the developer can decide if he wants toadapt the resource usage in the requirements, which is potentially much cheaper, or
wants to modify implementations.
In the worst-case the Algorithm 2 needs to iterate over all levels of the requirements
structure without finding a successful refinement. Hence, the DRAIN function is called ina magnitude of |R| resulting in an overall asymptotic upper bound of O(|R|2 ) ∗ T (⊗).
The running time can be reduced to O(|R|) ∗ T (⊗) by caching the results of the DRAIN
function, instead of calculating them in each level of iteration again. This has beenskipped in favor of a better readability. The algorithm obviously terminates.

3.4 Requirements on a Modular Safety View
The process and algorithms in this chapter are based on an abstract system representation
using trace semantics and contracts. Hence, to be able to use the technique on a realsystem, we need to provide a specification language, that is able to represent functionalsafety concepts and is still suited for the presented change impact analysis approach.

70

3.5 Conclusion
Algorithm 2 procedure to iteratively test the requirements of a system if compensationis possible by draining slack
Require: rc ∈ R, Vr (rt op, R) = 0
1: procedure SlackAvailable(rtop , R, rc )2:
i Initializing variables
3:
level = 14:
start = rc
5:
i extend scope of requirements towards top level→−6:
while R (start) 6= ∅ do→−7:start = R (start)
8:
i now, perform draining at new start node←−9:
Rl = R (start)
10:
Rnew = {}11:
for all r ∈ Rl do
12:
i Rnew is the set of all drained requirements
13:
Rnew ∪ drain(r)14:
end for15:
i Check if refinement is given for drained requirements
16:
if Vr (start, Rnew ) = 1 then17:
return (TRUE, level)
18:
else
19:
level++
20:
end if21:
end while22:
i Top level requirement has been reached, but refinement not given
23:
return (FALSE, level)
24: end procedure

Therefore, the following requirements on a system safety model exist:• Requirements shall be represented as contracts• The refinement property of the requirements shall be automatically analyzable.
• The compliance of the requirements to implementations shall be automaticallyanalyzable.
Based on these requirements a formal specification language is developed in chapter 4.

3.5 Conclusion
Changes propagate in a system from one component to related components. These
relations are typically expressed by tracelinks for HW/SW systems or also by call71

3 Semantic Impact Analysis

relations and variable usage for pure software systems. Different targets exist for the useof impact analyses ranging from an initial estimate of costs to the reduction of faults
introduced in changed systems by giving hints which other elements are most likely tobe affected. We want to use a change impact analysis in the context of safety criticalembedded systems to reduce the re-certification effort. In fact, a linear relation between
the size of the changes performed to the system and the needed verification activities shallbe established, eliminating the need to re-certify the whole system. Our investigationof the existing techniques has shown that none of them is suited to be applicable forfunctional safety concepts of safety critical automotive systems. The gap analysis hasrevealed four requirements on the impact analysis:• The new impact analysis shall use the semantical correctness of the system as thetarget for impact detection.
A change impact analysis has been presented that is capable of identifying theaffected elements within a system on a semantic base (see Section 3.3). It is uniqueto our approach to reason on the actual required behavior of a component, expressed
as contracts, instead of the syntax of source code or predefined tracelinks. Since
contracts provide separation between an assumption, describing the context, and aguarantee, describing the provided behavior of a component, the refinement relation
indicates if a changed context is still suitable for a component. This ensures, that
there are no further changes necessary in a part of the system if the change iscontained by successful refinement checks.
• The new impact analysis shall provide a stop criterion for change propagation in
the system.
The impact analysis process (see Section 3.3.4) determines affected system elements
using the refinement, satisfaction and interface relations. Although a changed
component indicates, that all directly connected elements are potentially affected,
all relations can be assessed using the semantics given by the specified contracts.
Therefore, the change propagation can be stopped.
• The new impact analysis shall be able to contain changes with very little slack
available in the system.
No overestimation in resources or behavior is required by the process (see Section
3.3.5) as a barrier for change propagation. The system can be arbitrarily modified.
However, if there is slack available in the system specification, the engineer performing the analysis can be notified that cost efficient modification alternatives
exist. In particular, we offer a set of requirements to be changed instead of an
implementation. Since automotive devices are not intended to be modified after
production, the slack is typically very minimal between directly refined requirements
and, hence, a combination of slack in different parts of the system is necessary. To
compensate a failed refinement analysis, the scope of the identification of slack isconsecutively extended until finally the total system is analyzed to guarantee thesmallest possible chain of changes.

72

3.5 Conclusion• The new impact analysis shall be able to detect impacts on logical architectures. In
this chapter we did not introduced any restrictions on the language used to express
the contracts assertions but relied on abstract trace semantics.
The concrete language, meeting the requirements stated in section 3.4 to perform
an impact analysis on functional safety concepts, is presented in the following chapter.
Furthermore, the claim that the verification effort scales linearly with the size of thechange is evaluated in chapter 5.

73

CHAPTER

Development of a
Compositional Safety View
Safety critical systems are characterized by a high amount of required verification andvalidation activities necessary for qualification or certification. Changes in the system
often cause a tremendous re-verification effort. Fenn et al. (2007) described the experienceof industrial partners in which the costs for re-certification are related to the size of thesystem and not to the size of the change. Also Espinoza et al. (2011) discovered thatthe monolithic and process oriented structure of the safety cases required by nearly all
domain-specific safety standards may require an entire re-certification of the system after
changes. This stems from the inability of the impact analysis techniques to encapsulate
propagating changes.
To overcome the re-certification problem a contract-based change impact process
has been developed in chapter 3. This process is based on an abstract contract-based
specification. Since the impact analysis shall be applied for automotive functional safetyconcepts a concrete specification language needs to be developed. The specification
language shall describe the fault propagation and mitigation properties of a component.
This includes degradation of the system as well as fault tolerance mechanisms.
Existing approaches to specifying safety properties in a modular way (see Section 4.1
for an overview) lack either expressiveness or compositionality, limiting the ability tocontain changes. Compositionality is defined by Hungar (2011b) as well as Peng andTahar (1998) as: “there exists a separation between the specification of a component andits actual behavior. If a component is replaced by another component meeting its original
specification, the correct functional behavior of the composed system is maintained.”
It is a design goal of our approach to change existing industrial design processes as
little as possible. We annotate existing design models with a formal, textual specificationthat can be stored in typical requirements engineering tools like IBM Rational DOORS.
Therefore, no changes in the existing design process are necessary. The safety specifi-

75

4

4 Compositional Safety View

cation can be used directly as a requirement or a property in the development process.
The distinction between requirement and property is process oriented. The presented
formalization approach remains identical.

4.1 Related Work
Modular safety cases are highly desired in systems engineering. Hence, many different
modeling approaches exist to represent safety properties and systems. In this work wefocus on approaches that can be used in combination with typical engineering models
like SIMULINK, AUTOSAR or SysML. Therefore, we do not investigate approaches that
require special analysis models like “function-structure-models” (Echtle, 1990), which aregraph structures with components as nodes and functions as edges, or models based on
Lamport’s process and channel notation (Lamport & Merz, 1994). In addition, we focus
on approaches that claim to be re-useable and modular, that is, that components can be
put in a different context and can be characterized by their interface.
The safety modeling technique presented in this thesis falls into the category of failure
logic modeling approaches. We briefly introduce the topic and present the limitationsof three popular specification notations to demonstrate the need for a contract-based
approach. Furthermore, graph based structuring approaches for safety cases have gained
popularity and are introduced in section 4.1.2. Since the goals are very similar to what
we want to achieve we describe two common approaches for safety case structuring andrelate them to the contribution in this thesis. Finally, we detail the already existing workon safety contracts that has been published and that we build upon.

4.1.1 Failure Logic Modeling
Failure Logic Modeling (FLM) approaches (Lisagor, 2010; Lisagor, McDermid, & Pumfrey,2006) describe the failure behavior on the output of a component in terms of input andinternal faults. Fault trees or FMEA (Failure Mode and Effect) tables can then be derived
from such specifications.
Hip-Hops
Hip-Hops (Pasquini, Papadopoulos, & McDermid, 1999) is a failure logic modeling-based
approach that aims at automating the generation of safety analysis artifacts such as
Fault Trees and FMEA tables. To this end, design models, for example, SIMULINK
models (Papadopoulos & Maruhn, 2001), are annotated with a fault propagation specification that states for a component possible input and internal faults as well as how they
influence the output. In Figure 4.1 an example component is depicted together with its
local safety analysis in the form of a table. The local analysis results are the possible
failure modes that might occur at the output of the component. These output deviations
can be caused by internal malfunctions of the component or by incorrect inputs. It is also
possible to state the probability of occurrence (failure rate) of the internal malfunctions.

76

4.1 Related Work

The failure rates can be used along the structure of the generated fault tree to calculate
the overall probability of a failure at top level.

input_1
outputinput_2

Output Fail- Description
ure Mode

Input Devia- Component Mal- λ(f /h)tion Logic
function Logic

Omissionoutput

The component
fails to generate
the output

Omissioninput_1 AND
Omissioninput_2

Wrong-output

thecomponent
generates wrong
outputWrongBiased
input_1
ORWronginput_2

5 · 10−8

Early-output

Early output

...

...

JammedOR
Short_circuited...

5·10−7 ,
6 · 10−6

Figure 4.1 – Example component and failure logic table. Source: Papadopoulos and Maruhn(2001)The deviations from the nominal behavior on the output considered by Hip-Hops follow
HAZOP (Gould, Glossop, & Ioannides, 2000; McDermid & Pumfrey, 1994) guidelines
and are structured in three categories. The first category is service provision failure,
such as no service at request (omission) or unintended service (commission). The second
category summarized failures related to the value domain (e.g., a value being out ofrange, stuck, biased or simply wrong. Timing failures, such as a too late or too earlyoccurrence of an event, belong to the third category.
These safety analyses are performed for all components in the system hierarchy (seeFigure 4.2). Therefore consistency checks can be performed if top level components
analysis results fit to their implementation. Furthermore, fault trees can be generated
for the functional failures on top level components. Together with the failure rates of
the atomic faults it is possible to determine the probability of a system function failure.
This fault tree generation can be performed iteratively during the development process
to improve the systems design.
The basic approach has been extended by introducing negations (Sharvia & Papadopoulos, 2008) or temporal properties (Walker & Papadopoulos, 2008, 2009).
Hip-Hops is aiming for providing a hierarchical safety analysis approach. Still, our774 Compositional Safety View

Safety Analysis

Automatic Synthesis

Fault
Tree Synthesis
Algorithm

Sub-Systems

High Level System
Architecture

System Model

Automatically generated
Fault Trees for thesystemHAZOP style analysis ofcomposite and basic
elements in the Model

Figure 4.2 – Relation of hierarchical models and HAZOP analyses with generated fault
trees. Source: Papadopoulos and Maruhn (2001)

approach is more requirement oriented. We directly formalize safety requirements andaddress the correctness of their refinement by using abstraction techniques. Hence, we
are able to state top-level requirements like the absence of single point faults, and later
refine the implementation, without compromising the validity of the previously gained
results. This means, we fully support a top down oriented design approach, without theneed to already know the atomic faults of the implementation components. Although thestated fault propagation relationships are similar, there is no need to manually interpretthe generated fault trees while using safety contracts.
Fault Propagation and Transformation Calculus
The fault propagation and transformation calculus (FPTC) (Wallace, 2005) addresses
the problem of a modular safety specification. The architectural design is expressedusing Real-Time Networks (RTN) (Paynter, Armstrong, & Haveman, 2000) to model
the communication channels. In an RTN the communication protocol can be specified
in terms of destructive or nondestructive read and write operations. The calculus itself

78

4.1 Related Workis based on direct propagation notations using failure modes in accordance to HAZOP
guidewords. In Figure 4.3 the four basic types of propagations are depicted, using theasterisk sign (*) as a symbol for correct value. A component in an RTN is considereda source for a failure if a correct value is passed to the component and an internalfault causes the result to be wrong. In this example the deviation is a timing violation,late. Similarly, a component is called a sink if it can correct wrong input values. Most
components that do not implement any special safety mechanisms will propagate a failure,that is, the deviation on the input will also be visible at the output. Many such rules
can be defined for a component. Instead of stating all necessary rules, a default behavior
is assumed, which is propagation. A transformation of failure occurs, if the failure at the
input is different from the failure at the output, caused by the wrong input.
∗

→

late

(source)

early

→

*

(sink)

ommision→

ommision(propagation)

late

→

value

(transf ormation)

Figure 4.3 – Basic fault transformation rules in FPTC. Source: Wallace (2005)

The examples in Figure 4.3 apply only for components with one input and one output
port. For multiple ports a more complex notation needs to be chosen, as indicatedin Figure 4.4. If multiple output connections are used the outputs can be referenced
using tuples, where each position in the tuple relates to a defined connection. The tuple
approach is also applied to inputs. Nevertheless, the number of potential combinations
grows exponentially with the number of input connections. Therefore, two additional
notations are introduced. The underscore symbol (_) indicates a “don’t care.” Hence,the second rule in Figure 4.3 indicates that as soon as there is a failure of type late on
the first input port, the outputs will be affected by a value and also a timing failure,
regardless of the status of the second input port. The second mechanism reducing thenumber of input combinations is the usage of functions. These functions have a similar
meaning as the underscore, but bind a value to them, to be used on the right-hand sideof the rule. Hence, the third rule defines a propagation of failures, where a late failure on
the first input propagates to a late failure on the second output, and all possible other
input failures on the second port will propagate identically to the first output port.
The approach provides a fixed-point algorithm to calculate the set of all possible
occurring input and output faults for every component in the system. The algorithm
starts with an in-set and an out-set for each component that includes only the normal
behavior symbol, then the rules are applied until a fixed-point is reached. This algorithm
is used to detect if changes in the architecture have an impact on the safety of the device.
If the set of possible failures deviates, there is an impact from the change.
The FPTC approach tries to solve the same problem that is addressed by this thesis,
namely the reduction of costs caused by changes in safety critical systems. Nevertheless,79

4 Compositional Safety View

late

→

(value,*,late)(multiple output)(late,_)→(value,late)(multiple in- and output)(late,f )→(f,late)(usage of variable)

Figure 4.4 – Transformation rules in FPTC for multiple ports. Source: Wallace (2005)

the approach still has some flaws. In contrast to the solution presented in this thesis,
the FPTC approach does not provide any support for multiple abstraction levels, i.e.,
specifying a component, then designing the subcomponents and proving the correctness of
the refinement. Additionally, within FPTC it is not possible to state temporal properties
in the propagation of faults (e.g., that a fault is going to be detected after some amountof time). Furthermore, in case of multiple input and output ports, the notation of positive
propagation is more complicated than the negative fault containment properties statedwithin safety contracts. Also, the order of the evaluation of the FPTC requirements
matters, which is not the case for the invariant safety patterns. The readability isfurther impacted by overlapping rules, where more concrete rules overwrite more generalrules. The determination of the “concreteness” of a rule might itself be a difficult task.
Furthermore, the used fixed-point algorithm calculates the set of possible failures, but thecausality of the resulting failures is lost. Therefore the set of failures might be identical,
but since the same failures might be caused by multiple inputs, the failure might occur
much more frequently and the system is less safe, but according to the approach there is
no change detected. A minor drawback of FPTC is also the necessity of an RTN model,
while safety contracts can be attached to any port-based component model.
Compositional Fault Trees
Mäckel and Rothfelder (2001) identified two concrete flaws in classical fault trees. First,
the difficult handling of events, that are used multiple times on different nodes, but aresemantically identical. These repeated events are tagged in existing fault trees but stillseparate entities in the tree. Second, the limitation of fault trees to a single top level
event. This limits the ability to represent relations between different top level failuremodes. Hence, an extension of fault trees is proposed, called cause effect graphs (CEGs).
Repeated events are represented as a single node having multiple edges. The readability
is furthermore improved since CEGs can now also be read in a bottom-up fashion. In
addition, multiple top level events can be represented that use a shared set of intermediate
and basic events. That way faults can be identified that can lead to multiple top level
events, which is a good starting point for architecture improvements.
Kaiser, Liggesmeyer, and Mäckel (2003) address the problem that the typical structureof a fault tree is related to the hierarchy of failures, but not to the hierarchy of thesystem. It was their goal to extend CEGs to be stated for architectural components thatcan be composed, aligning fault tree and architectural elements. To achieve this they80

4.1 Related Work

System Down
Controller System&

Main Controller

Aux Controller

>=1

>=1

Main CPUDown

Aux CPU
Down

Power Unit Down

Figure 4.5 – Multiple componenet fault trees combined to a system

added directed ports to the fault tree, representing possible input- or output-failures of acomponent (see Figure 4.5). Hence, fault tree parts represent the failure propagation
behavior of individual system components. As an additional benefit, the component
fault trees are re-usable, if a component is instantiated multiple times in the architecture.
Proposals exist to integrate compositional fault trees in UML (Adler et al., 2011).
With their extension of CEGs to compositional fault trees Kaiser et al. (2003) defined afailure logic modeling language, that resolves the architecture alignment problem of fault
trees. Still, using FT-syntax the expressiveness of the failure propagation is limited tological boolean operators and prohibits the use of timing information. Furthermore, theassumption, that component internal faults are independent from the rest of the system
is in some cases to restrictive. If a component is instantiated twice, a systematic fault in
the component is a common cause fault for both instances, but handled independently by
default. The quantitative analysis is restricted to systems that do not rely on any inputs,
which is uncommon for automotive systems. However, it seems that this restriction
could be bypassed if the input failures are represented as internal faults of the first81

4 Compositional Safety View

subcomponent processing them, or introducing a new input subcomponent for this fault.
Compositionality and re-usability is addressed in the approach, but means for abstraction
are still missing. That is, at the time of the analysis the model still needs to be complete
and cannot be refined later without the need of a full re-evaluation.

4.1.2 Safety Case Structuring
A safety case is defined as “a documented body of evidence that provides a convincing
and valid argument that a system is adequately safe for a given application in a given
environment” (Bishop & Bloomfield, 1997). Most safety standards require a safety caseto be delivered to the assessing authorities to evaluate the developed device. Hence, many
approaches have been developed lately to structure the safety case in a readable and easy
to understand way. In this chapter of the thesis a specification for safety properties shallbe developed that is easy to apply and allows reasoning about the fulfillment of safety
requirements. Looking at these shared goals, we describe two popular approaches forsafety case structuring and relate them to the contribution of this thesis.
Goal Structure Notation
The Goal Structure Notation (GSN) is a graphical notation to document arguments interms of, for example, claims, evidences and contextual information. Although GSN
can be applied to various argumentations for systems, services or organizations (GSN
Community Standard, 2011), it is most frequently applied to represent safety cases forsafety critical systems (Kelly & Weaver, 2004). The approach in its current form has beendeveloped by Kelly in 1999 (Kelly, 1999) and is currently being adopted to a community
standard (GSN Community Standard, 2011) published by Origin Consulting in York.
We refer here to the notation of the community standard.
{Goal Identifier}<Goal Statement>{Context
Identifier}<Context
Statement>{Justification Identifier}<Justification Statement>
J{Strategy
Identifier}<Strategy
Statement>{Solution
Identifier}<Solution
Statement>{Undeveloped
Goal Identifier}{Assumption Identifier}<Goal Statement><Assumption Statement>
A

Figure 4.6 – Principal element of the goal structure notation according to GSN Community
Standard (2011)

The main elements are represented in Figure 4.6. The goal represents the claim, which
is a part of the argument. Typical goals are the absence of catastrophic single point824.1 Related Work

SupportedBy

InContextOf

Figure 4.7 – Links in the goal structure notation according to GSN Community Standard(2011)

faults or that the system is reasonably safe to operate in a defined environment. Goals
can be decomposed. The top level goal is fulfilled if all its subgoals are fulfilled. If more
complex relations between the goals and the corresponding subgoals exist, strategies canbe used to describe the inference mechanism in more detail. Such strategy could be theomission of all identified failures, which are listed as subgoals. Finally the decompositionof goals should be terminated by a solution that represents the reference to evidence
items. Such evidence can be test or analysis results, as well as performed reviews. If
there is no solution available yet for a goal or subgoal, this branch is terminated by an
undeveloped goal, indicating that a refinement or a solution is still in development tofinish the argument. This undeveloped symbol can be applied with identical semantics
to strategies. Goals, strategies and solutions can be valid only in a particular context,that is, one which describes, for example, a specific safety standard. As another example,
a strategy that argues over all hazards is valid in the context of a particular hazard
and risk analysis. A justifaction is a statement of rationale for choosing a strategy or
the presentation of a goal. If statements are used that are intentionally unproved, anassumption can be connected to a goal or strategy.
GSN provides two types of links between elements, SupportedBy and InContextOf(see Figure 4.7). The SupportedBy relation is used to indicate inferential or evidential
relationship, and is therefore used to point from top-level goals to subgoals or strategies.
Also Solutions are connected to goals via this link. The InContextOf link indicates theuse of elements that limit the scope of an argument, for example, the use of contexts,
assumptions and justifications. Therefore, these elements are connected to goals andstrategies via this relation.
In addition to the graphical notation a method has been developed describing how to
use the notation in a documentation scenario (Kelly, 1997). The method consists of six
steps:• Step 1 - Identify goals to be supported• Step 2 - Define basis on which goals stated• Step 3 - Identify strategy to support goals• Step 4 - Define basis on which strategy stated• Step 5 - Elaborate strategy (and proceed to identify new goals – back to Step 1)OR83

4 Compositional Safety View

• Step 6 - Identify basic solution
This recursive process can be followed to create a safety documentation in a top-downmanner.
GSN is a notation to structure the information in the safety case. It is the main idea torepresent goals and their breakdown structure until a refinement level is reached, where
the subgoals can be proven by a given solution. This idea of decompositionality is very
similar to the principles behind contracts. A specification is broken down into finer parts,and the refined specifications are checked against the implementations. Nevertheless,
GSN does not provide any support for analyzing or formalizing statements. Still, resultsfrom contract analyses can be used as subgoals or strategies in a GSN argument structure
and can therefore contribute to the top-level goal of providing a reasonable safe system.
SHIP Safety Case
SHIP was a EU project with the objective to “assure plant safety in the presence of design
faults.” To argue on the safety of the system a structure for safety cases is proposed(Bishop & Bloomfield, 1997). This hierarchical structure is represented in Figure 4.8
consisting of four main elements. A claim is a systems property that may directly or
indirectly state safe operation. Evidences are used as the base for a safety argumentation,
they typically represent special qualities of the development process or actions to deal
with erroneous situations. This kind of evidence is called a fact (see Figure 4.8). Other
types of evidence are assumptions, which are defined as conditions, which are necessary
for the safety argumentation but not always given, or subclaims. The link between theevidence and the claim is called argument which uses inference rules to “relate” thedifferent evidences.
References

Fact

References

Assumption

Prob. of
Violation

Sub-Claim

Claim

Evidence
Evidence

SubClaim

Evidence

Figure 4.8 – Overview of hierarchical claim structure (Bishop & Bloomfield, 1997)

Depending on the type of the arguments the inference rules look different. For
deterministic arguments the inference rules might be predicate logic to relate statements.

844.1 Related Work

Fault Removal

Perfect
State

Error Correction

OK State

Fault Introduced

Error ActivatedErroneous
State

re
ailu
eF
f
a
S
Dan
ger
ous

Safe
State

Fai
lure
Dangerous State

Figure 4.9 – Model of system failure behavior (Bishop & Bloomfield, 1997)

For probabilistic arguments the inference structure can be a markov process. There is athird type of argument mentioned, the qualitative argument, which, for example, can be
the compliance to standards or guidelines.
To structure the arguments, a simple transition system is presented, that relates fivedifferent behavioral states of a system (see Figure 4.9). If the system is running undernominal conditions without faults, the perfect state is active. As soon as a fault occurs
the system switches to the OK state, meaning that the fault is present but is not yet
triggered. If an input is sent to the system that uses the faulty elements, the system is in
the erroneous state. Whether there is immediately a dangerous situation depends upon
the error. It is also possible to detect the failure and go to a safe state or correct theerror and go back to the OK state. Arguments can reference transitions of this model, toargue why a special evidence helps to build a safe system.
Bishop and Bloomfield (1997) provide a table with possible evidences that help avoid
or explicitly take transitions in the model. These evidences have three main sources, thedevelopment process, the system design or field experience. The arguments are proposed
to be represented in a tabular form to state the causes (faults) and safeguards for thedifferent transitions.
The SHIP approach has been taken up and extended in the Adelard (1998). The
manual proposes a process of how to develop a valid safety case and provides checklists
and examples for various stages in the process.
The presented approach can be extended with formal specifications to describe evidences
and claims and, for example, trace semantics as inference rules. The SHIP approach does
not provide any analysis capabilities itself, therefore the contributions of this thesis areon a much lower abstraction level, describing the fault propagation together with thepossibility of automatic analyses, that can be used as an argument in a SHIP structure.

4.1.3 Previous work on safety contracts
Contract-based specification approaches have recently gained a lot of attention. Hence,
the term safety contracts or formalized safety requirements is used differently by many85

4 Compositional Safety View

Ex. 1

"if the braking command signal is not provided within
9 ms from the receipt of the pedal signals, thenactivate emergency brake within 1 ms" (Sljivo, Jaradat,
Bate, & Graydon, 2015)

Ex. 2"always (((NewDataAvailable and ValidCRC and 1 <=DeltaCounter and DeltaCounter <= MaxDeltaCounter)and previously in the past (NewDataAvailable andValidCRC)) implies (then status_ok(Status)));"(Arts,
Dorigatti, & Tonetta, 2014)

Ex. 3"If the derivative of actualFuelVolume[%] is lessthan 0, indicatedFuelVolume[%], shown by the fuelgauge, shall be less than actualFuelVolume[%]; orindicatedLowFuelLevelWarning[Bool] shall be active(true) when the actualFuelVolume[%] is below 10%; orindicatedFuelVolume[%], shown by the fuel gauge, shallshow a value below 0%." (Westman, Nyberg, & Törngren,
2013)

Table 4.1 – Examples for safety requirements in the functional aspectresearchers. We have identified two basic meanings of safety contracts, which can beseparated by the aspects (views) introduced in Section 2.2.2. There exist approaches
which use contracts for requirements that are associated with the functional aspectaccording to the design space structure defined by Pohl et al. (2012) as well as Rajan and
Wahl (2013). In terms of ISO 26262 such requirements are considered safety requirements.
In that sense the term safety contract is not wrong, but we stick to a stricter separation.
Others try to specify pure conceptual safety properties as suggested by the various failure
logic modeling approaches (see Section 4.1.1).
Three examples for safety requirements in the functional aspect are depicted in Table
4.1. The first example states a relation between functional ports. It requires a dependency
between the braking command, the pedal signals and the emergency braking. Clearly,
emergency braking is a safety relevant operation, but this requirement states the technicalrealization of a detection of a fault and a reaction to it. Nevertheless, from this requirement
the safety concept can only be guessed, there seem to be faults that cause the braking
command not to occur in a defined time frame after the pedal signal and a stoppage
seems to be the safe state. In this thesis we propose a strict separation between thesafety concept with respect to failures and their propagation and the implementationof the safety concept in terms of detection techniques and reactions. The goal is tosupport the engineers in achieving a more complete specification. The second example
describes also a requirement for safe communication using check sums and message counter.
Although being on a technically lower level, this is not considered a safety contract in our864.1 Related Work

understanding, but a functional refinement of a conceptual safety requirement. Although
the third requirement still describes functional relationships, it includes an interesting
artifact missing in the first two examples. In this requirement the measured values forfuel volume are compared to the actual fuel volume. With this comparison there are
failure modes implicitly introduced that would typically indicate that a value is wrong(i.e., different to the real value). Nevertheless, this kind of specification is not totallycompositional, since failure propagation is difficult to be expressed. This can be simply
explained by the reference to ports way outside the scope of the component, in this casethe real environmental value. Hence, Westman, Nyberg, and Törngren (2013) modified
the contract approach defined in the SPEEDS project (Enzmann et al., 2008) to deviate
from strict interface oriented black box specifications. This deviation is not necessary
using the safety contracts presented in this work.
The second identified category of safety contracts are specifying safety properties
in a failure logic modeling way. Damm, Josko, and Peikenkamp (2009) proposed that
contracts and Heterogeneous Rich Components (HRC), the component model developedin SPEEDS, can be used in the context of the ISO 26262 to state safety requirements. The
usage of contracts to express failure propagation is mentioned as a possible application
scenario, without detailing a concrete notation. Damm et al. (2009) suggest dominancechecking (in this thesis called refinement, see Section 2.1) as a suitable verification
technique to ensure a correct reaction to faults in the system. Furthermore, different
techniques are mentioned to verify the implementation with respect to stated contracts.
These techniques encompass test case generation based on contracts as well as fault
injection. Nevertheless, none of these techniques is detailed. However, the work of Dammet al. (2009) confirms that further research in this direction, in particular in languages
that express safety properties in contracts, is necessary.
Based on these ideas, Böde et al. (2010) presented an approach for hierarchical safety
specifications using safety contracts. They introduced patterns to describe the hierarchyof faults, the hierarchy of functions, and the relation between faults and functions, aswell as the assignment of a criticality to failures. For example:• function <function-name> can be impacted by <failure-list>.
• failure <failure-name> is realized by <failure-expr>[except when <failure-expr>]• failure <failure-name> is <criticality-level>[during <phase>] [in <mode>] [under <condition>]
Although the approach is based on contracts, the stated patterns do not fully exploit
the contract notation as assumptions are neglected, a major principle of contracts.
Furthermore the semantics of the patterns are not defined in a formal way. In addition,a suitable mapping of the approach to an interface of the component is missing (e.g., toports representing faults).
In 2011 a pattern based requirements specification language (RSL) was presented(Reinkemeier et al., 2011; Baumgart et al., 2011) that encompasses formalization means87

4 Compositional Safety View

for functional, architectural, real-time and safety requirements. The safety patterns are
influenced by the formalization approach presented by Böde et al., but they include
additional patterns, building a set of 12 requirement templates. For example:• Function shall only fail if failure_list• Failure shall be detected with probability p• Failure shall not be caused by n independent failures• hazard Hazard shall not occur with density higher thann per reference
The first pattern is clearly related to previous work (Böde et al., 2010). The introductionof probabilities, independence constraints and hazards remains unique for the RSL. Still,
precise semantics of the patterns have not been defined. Also guidance for applying thepatterns is missing.
Oertel et al. (2014) presented an approach for expressing safety requirements optimizing
and condensing previously gained results. The amount of patterns was significantly
reduced from 12 patterns to only four. Furthermore, a linear temporal logic (LTL)
based semantic definition was provided (Pnueli, 1977) (see Table 4.2 for overview ofpresented pattern). The patterns use a cut-set semantic for the expression set. Thatis, the occurrences of the faults or failures are not timed. Hence, it does not matter if
the faults occur at the same time or in a special order, a cut-set defines all the traces inwhich the defined faults/failures occurred. Table 4.3 highlights how the expression sets
can be specified inside a pattern. Each expression set consists of modes and fault/failures
or sets of them. The operator perm can be applied to individual expressions, stating thatsome fault, failure or mode is permanently valid. Since the pattern itself negates theexpression sets, that is, requires that these combinations of modes and fault/failures do
not occur, the perm operator defines, used within the negation, that an expression shallbe invalidated at some point in the future. The presented approach, however, does notconsider abstraction techniques to refine safety concepts suitable for a top-down design.
Also guidance of how to apply the patterns is missing. Nevertheless, in this thesis webuild upon the notion and semantics presented by Oertel et al. (2014).

88see pattern 1(G¬e1 ∨ G¬e2 )(G¬e3 ∨ G¬e4 ).

LTL expression

G(e1 → (e1 We2 )).

Correct_mode
onlyfollowedby
Incorrect_mode.
Anevolution of the system
where Correct_mode always holds, is acceptedby the pattern. Whenever the Correct_mode
switches to be false,then the next state of
the system has to be
Incorrect_mode.

¬e1 ∧ G((Xe1 ) → (e1 ∨e2 ))Detected_Mode
only
after
Undetected_mode. A traceof the system where
Detected_Mode neveroccurs is accepted by
the pattern. A traceof the system where
Undetected_mode
always holds is acceptedby the pattern. Whenever Detected_mode
holds, it means that thedirect previous state is
Undetected_mode.

The evolution of a system is accepted, iff any
uninterrupted sequenceof expr1 always occurs
as a direct follower of
expr2.

expr1 only after expr2

Pattern 4

Table 4.2 – Overview of the four safety patterns as presented in Oertel, Mahdi, Böde, and Rettberg (2014)∧see pattern 1

noneof{{e1 , e2 }, {e3 , e4 }}occurs.
Any evolution of thesystem containing e1and e2 (or containing
e3 and e4 ) violates thepattern. Any evolutionof the system containing
e1 and e3 , but neither
e2 nor e4 (or containing
e1 and e4 , but neither
e2 nor e3 , or containing...), is accepted by thepattern.

ExampleThe traces of the system
are accepted, iff either
expr1 holds forever or
each expr1 is followed by
expr2 or expr1 does notoccur.

Derived from pattern 1,
where only one expr-set
is used. Semantics are
identical. Introduced forconvenience

The pattern described
all traces of a systemthat do not contain any
complete expr-set element.

Intuition

Pattern 3

none of {expr-set1, expr-set does not oc- expr1 only followed
cur.
by expr2
expr-set2,...} occurs

Pattern 2

Structure

Pattern 1

4.1 Related Work89

4 Compositional Safety View

Attribute/Operator

Description

Fault/Failure

Is the event of a internal malfunction or an signalmalfunction occurrence in a certain part of the system.

Mode

Both, degradation modes and detection modes, can be used
to refer to a certain state of the system (e.g., status ofdetection or limp-home mode).

Expression (expr)

An expression can be a malfunction or a mode.

Expression Set (expr-set)

Is a set of expressions that do not necessarily occur at thesame time. Similar to the concept of a cut-set.

Perm

It is an unary predicate that is applied to an expression.
When we apply it to such an expression, e.g., perm(expr1),
it means that this expression holds for all coming statesof the system. In LTL terms perm(expr) is equivalent toG(expr)Table 4.3 – Safety patterns attributes (Oertel, Mahdi, Böde, & Rettberg, 2014)

4.2 Gap Analysis and Requirements
There are three main sources for the requirements on the modular safety view, whichis to be developed in this chapter. First, the requirements directly resulting from theimpact analysis process, which are summarized in section 3.4. On the other hand, theanalysis of the existing safety modeling approaches revealed some missing features or
combinations of features that are necessary in order to be usable in an impact analysis.
In addition to these technological aspects, the ISO 26262 (2011) has requirements on thecontent of the functional safety concept, which is the target of the specification. The last
two aspects are detailed in this section.

4.2.1 Gap Analysis
During the analysis of the existing safety modeling approaches it has been observed, thatnone of the techniques suited the needs of a change impact analysis. Some approaches
like GSN (Kelly & Weaver, 2004) or SHIP safety cases (Bishop & Bloomfield, 1997),
do not provide the needed degree of formalization. Hence they are suited to statea safety argumentation, but automated analyses, as required by the change impact
analysis (see Section 3.4), are not possible to realize. Approaches using formal languages
as presented by Sljivo, Jaradat, Bate, and Graydon (2015) or Arts, Dorigatti, andTonetta (2014) provide the possibility for automated processing of requirements, but
do not allow for specifying requirements in the safety aspect (see Section 2.2.2). Safety
patterns that allow a formal specification of properties assigned to the safety aspect90

4.2 Gap Analysis and Requirements

have been introduced by Damm et al. (2009) or Böde et al. (2010) as well as Oertel
et al. (2014). Although the approaches differ from each other, none of them is able tosupport abstraction techniques in their specification language. Other approaches like
Hip-Hops (Pasquini et al., 1999) or FPTC (Wallace, 2005) at least claim to support
modularization. However, modularization does not imply that an abstraction mechanism
is available. While modularization describes a logical partitioning, abstraction describes
the same element in less detail, over-approximating the behavior.
The safety concepts of the ISO 26262 are described in a top-down process, startingwith very abstract requirements that are refined together with the structural architecture.
Thus, refinement of requirements is an essential aspect of the change impact analysis andnone of the analyzed safety modeling approaches can be applied without. Nevertheless,safety patterns provide the largest set of needed properties. Hence, they have been chosen
to be extended with the missing features.

4.2.2 Specification Needs from ISO 26262
To be able to express functional safety concepts according to the ISO 26262 a detailed
analysis of the stated requirements is necessary. The ontology depicted in Figure 4.10
represents the summary of the identified concepts and relations, that are relevant for
expressing functional safety concepts.
The functional safety concept consists of the preliminary architectural assumptions
and the functional safety requirements, which describe the intended functionality of thecomponents inside of the architecture.
The preliminary architectural assumptions consist of hierarchical composed components.
The intended behavior of the components is expressed in terms of safety requirements.
In contrast to the strict separation between functional and safety requirements in the
SPES and CESAR design methodology (see Section 2.2.2). the ISO 26262 considers all
requirements as safety relevant as long as they describe a function that is considered atleast ASIL A. The main objective of the functional safety concept is to describe howfaults are detected and failure mitigated. Hence, safety requirements may be violated if
too many faults or failures are present in the system. This can be only one fault (whichis after the analysis considered as a single point fault) or cut-sets with multiple faults.
In this context we do not need to further distinguish between faults and failures (seedefinitions in Section 1.5 and an additional explanation in section 4.3.1). Nevertheless,the differences in the structural location of the occurrence of the unintended deviation,
which is often considered as a main difference between fault and failure, needs to bestated. Hence, deviations on signals and deviations on the internals of a component
are separated. As a result, a component can be specified according to the input andoutput signal deviations, as well as internal deviations, which is compliant to the failure
logic modeling approaches (see Section 4.1.1). In addition to the structural occurence offaults and failures, the ISO 26262 distinguished between permanent faults and transient
faults. Permanent faults are always existent in the system once they occurred, whiletransient faults may disappear and occur again, even with very high frequencies. The
ISO 26262 provides multiple other fault classifications that are not considered here. For91

4 Compositional Safety View
end of interval
intended deviationfrom nominal behavior
as reaction to faults
may runin different

Safe State

FTTI

switching towithinis aOperating Modes
is a
Driver Warning

Can beSafety Mechanism

Can detect

bevavior may deviate
from nominal behavior

shall satisfy

Degrading
Immediate
DegradingNon Degrading

Component

composed

DelayedDegradingstart of interval
Deviation on
SignalStructural Types
Deviation
insideFault / Failure
Permament
Deviation

SafetyRequirement

may lead toviolation ofTiming Types
Transient
Deviation

Figure 4.10 – Ontology representing the chosen abstraction for describing safety concepts.

example, the distinction between single-point or multi-point faults is not represented in
the overview, since these classifications are analysis results with respect to the effect ofthe malfunction on the system. The same applies to the subclassifications of them, suchas safe faults, residual faults or latent faults. In contrast, the properties permanent andtransient describe the nature of a fault and a static property, respectively.
The ISO 26262 foresees multiple possibilities for how to deal with detected faults andfailures in the system. These activities are executed by components that implement safetymechanisms, and hence, are directly influencing the fault propagation behavior. The first
technique mentioned by the ISO 26262 is the degradation of a system, by switching it
to a so-called safe state. This safe state provides a reduced functionality of the device,
but is safe with respect to the risk identified with the detected fault. As an example, alight sensor of a car can switch the light of the vehicle permanently on if there is a fault
or failure in the system detected. Hence, the function is degraded, since the automatic
light feature is disabled, but the risk of a sudden loss of main light during driving in thedark is reduced. As a second possibility to deal with occurring faults, fault tolerance

924.3 A Specification Language Supporting Impact Analysis

mechanisms are suggested. Safety mechanisms using fault tolerance techniques, suchas multi-channel architectures, keeping the system functional, even in the presence of adefined set of faults. For these elements the arbitration logic shall also be specified, forexample, how to select a signal from simultaneously generated ones.
The functional safety requirements shall further consider the possibly existing operating
modes of the system. These could be special driving modes like "sport" or "eco" or alsocountry specific modes for light and speed management. We also consider the safe-state
or a "limp-home" mode as operating modes of the components. In addition the fault
tolerance time interval (FTTI) needs to be specified for components that shall perform
error detection or mitigation. The FTTI is the time from the occurence of the fault until
it is mitigated or a safe state has been reached. Hence, the FTTI is only relevant forsafety mechanisms that do not immediately perform a correcting measure and have adelay between the fault occurance and the detection or mitigation. A typical example forsuch delayed safety mechanisms are watchdogs, which can detect a fault only after theirmonitoring period has been exceeded. Conceptually, the emergency operation interval,
which defines the time until an emergency operation shall be executed if a safe statecannot be reached, can be identically handled as the FTTI.
In addition to correcting faults or degrading the system, the ISO 26262 also foresees
the possibility of warning the driver with, for example, a malfunction indication lamp, if
the type of the fault allows such a strategy. Similarly to the safe-state the driver warnings
can be represented using operating modes. Furthermore, if assumptions on the behaviorof the driver or external measures are made, they need to be stated.

4.2.3 Requirement Summary
The requirements on the modular safety view from Section 3.4, Section 4.2.1 and Section
4.2.2 are:• Requirements shall be represented as contracts.
• The refinement property of the requirements shall be automatically analyzable.
• The compliance of the requirements to implementations shall be automaticallyanalyzable.
• The concepts used in the development of functional safety concepts according toISO 26262 shall be represented, as described by Figure 4.10.
• The language to express the requirements shall provide means for abstraction.

4.3 A Specification Language Supporting Impact Analysis
Having specified the requirements on the compositional safety model, we are developing
the concrete specification language in this section. First, we are adapting the language
for the individual assertions in Section 4.3.1 and integrate them later on in contracts93

4 Compositional Safety View

(see Section 4.3.2). We then present an abstraction technique in section 4.5.1 anddemonstrate how to automatically analyze refinement and satisfaction properties in
Section 4.5. Furthermore, guidelines on how to build an initial architecture are given in
section 4.4.

4.3.1 Expressing Assertions using Safety Patterns
From the analyzed specification mechanisms in section 4.1 the safety patterns (Oertel
et al., 2014) suit the needs for a semantic impact analysis best. They provide definedsemantics in LTL and can therefore be easily integrated in a contract-based approach.
They already provide means to represent cut-sets and argue about faults and failures.
Furthermore, the defined modifiers, such as perm, distinguish between delayed andnondelaying safety mechanisms as well as permanent and intermittent faults. Still, two
modifications are needed to use safety patterns to perform impact analysis in automotivefunctional safety concepts. In hierarchical systems the notion of fault and failures need
to be adapted (see Section 4.3.1), and multiple failure modes need to be specifiable to beable to represent safe states (see Section 4.3.1).
Making Safety Patterns Hierarchy Ready
The existing safety patterns (Mitschke et al., 2010; Oertel et al., 2014) distinguishbetween faults and failures in their expression sets. The faults represent the causesthat result in defined combinations in a failure on an output port of the respective
component. This distinction is suited only for nonhierarchical systems. A failure of one
component might be a fault to a connected component (see ISO 26262 (2011) Part 10, p.6,
Figure 5). Therefore, this classification is not suited for a static model and the abstract
concept malfunction has been chosen. This design decision is similar to the “fault/failure”
element in EAST-ADL. The ISO 26262 uses the term malfunctioning behavior. The maindifference to classical fault and failure notions is the focus on the location of deviation.
Hence, the malfunction within one component is called internal malfunction and canpotentially propagate to another component in the form of signal malfunctions. The
signal malfunctions can be used to “connect” the fault propagation between different
components, while the internal malfunctions can be used for abstraction and refinement
techniques (see Section 4.3.3). Still, it is not necessary to refine every internal malfunction.
At the lowest level of refinement they can be used as atomic malfunctions.
The malfunctions need to be described in detail. This concrete deviation of the signal
to its intended value (sometimes called failure mode) can be described in various ways.
McDermid (McDermid & Pumfrey, 1994) suggests, for example, considering failuremodes like “ommision” and “commision”, which indicate that a signal has not been sent
or was sent unintended. There are also classifications (Bondavalli & Simoncini, 1990)
that basically concentrate on distinguishing between “correct” and “incorrect” values.
The choice of a fitting level of abstraction depends upon the use-case and the state ofdevelopment. In the early phases of the development lifecycle the detailed malfunctions
might be unknown, and more abstract models are more practical.

944.3 A Specification Language Supporting Impact Analysis

The concept of malfunctions does not cover the concept of an error that does notappear as a separate concept in the ontology (see Figure 4.10) either. The error describes
the component’s internal incorrect state, which might manifest in a signal malfunction
when the component is used. Since we are concerned about the safety concept, thedescription of the interface is in the focus. The implementation, which is typicallynot available at that point in time of the development cycle, is not important for theconcept. Nevertheless, if the implementation is available it is essential to ensure that therequirements resulting from the safety concepts are correctly implemented. A techniqueto ensure this relation is presented in section 4.5.2. Since this analysis is based on
existing fault injection techniques, the separation of fault and failures is relevant again.
Nevertheless, to support analyses that are using this classification, the information is still
extractable from the model. Signal malfunctions on input ports and internal malfunctions
can be considered faults, and signal malfunctions on output ports can be considered as
the failure.
Introducing Multiple Deviations per Function
An essential capability of the functional safety concept is to express the degradation
behavior of the system. In this so-called degradation concept, the safe-state represents
a deviation from the nominal intended behavior, but keeps the system in an operating
mode, that is still safe for driver and environment. Hence, the safe-state can technicallybe considered a malfunction of the system as well. In contrast to malfunctions that
describe, for example, a too high value or a too late execution, the value of a safe-state isprecisely defined. It is therefore not a representation of a “safe” deviation range, but theestablishment of a well-defined state.
It is the goal to state a safety requirement that the system shall be working correctly
or at least safe, if only a limited amount of malfunctions are present in the system. Thismeans, that a relation between two failure modes for the same functional port need to
be specified.
The currently existing safety patterns (Mitschke et al., 2010; Oertel et al., 2014) use
a cut-set representation for faults and failures. An example pattern stating that the
combination of malfunctions m1 , m2 and m1 , m3 are not permitted, looks like:none of{{m1 , m2 }, {m1 , m3 }}occurs.
The cut-set indicates that these combinations of malfunctions are not permitted on
any trace of the system, but there is no information about the time of the occurrence ofthe malfunctions included. The LTL representation of the patterns is:(G¬m1 ∨ G¬m2 ) ∧ (G¬m1 ∨ G¬m3 )Hence, any trace on which the malfunctions m1 and m2 or m1 and m3 are present are
not accepted. If requirements of a safety mechanisms shall be stated that degrades thesystem by switching to a safe-state, cut-sets are not sufficient anymore since a temporal95

4 Compositional Safety View

hmalfunctioni ::= handExpri | hsingleMalfunctioni;
hnoti ::= ’!’;
hsingleMalfunctioni ::= [hnoti], ALPHA, {(ALPHA | ‘_’)};
handExpri ::= hsingleMalfunctioni, ‘and’ , hsingleMalfunctioni;
Figure 4.11 – Extension of the existing safety pattern grammar with “combination” and“not” operator.

relation between malfunctions needs to be expressed. Only the traces are accepted where
the system is either safe or correct. In LTL terms:
G(signalsaf e ∨!signalf ail )To integrate this concept in the existing grammar of the safety patterns the existing
rules to write elements of the cut-set can be used if we bring the above statement in theform:G¬(¬signalsaf e ∧ signalf ail )Hence, the new operators and and not can be added in the grammar that refines theconcept malfunction (see Figure 4.11).
The andExpr m1 and m2 simply translates to:
m1 ∧ m2
The not expression simply translates to the negation symbol ‘!’
Hence, the contract:{{signalf ail and !signalsaf e }}does not occur.
translates to:G¬(signalf ail ∧ ¬signalsaf e )Using multiple malfunctions per functional port, we need to extend the structural
constraints on valid architectures stated in section 3.3.1.
Structural Constraint 5. If multiple malfunctions are assigned to a functional port,
the components using the functional value need to be connected to all stated deviations of
the signal.

96

4.3 A Specification Language Supporting Impact Analysis

4.3.2 Expressing Safety Contracts
Contracts, as introduced in Section 2.1, provide a formal semantics to define refinement
and composition operators, by separating a requirement into an assumption and aguarantee. The modified safety patterns presented in the previous section fulfill therequirements to state functional safety assertions as required by the ISO 26262. Thatis, they are able to address all relevant entities. Still, to express the relations between
the elements, we need to embed the pattern in a contract. Hence, to be able to perform
virtual integration testing later on, it is important to state the right assumptions and rightpromises. In current evaluations of contracts for automotive systems, the uncertainty
in stating the right assumptions is a major cause for restrained use of contracts in thatdomain (Föster, 2012). As a result, strong emphasis needs to be put on the activities tosupport the engineer in specifying the safety contracts, in particular the assumptions. We
provide four basic contract templates, which are directly related to the classification ofsafety mechanisms as presented in Figure 4.10. Hence, the degradation capabilities andthe timing behavior of the detection are the main distinctions between the here provided
templates.
Template for Nonsafety Mechanisms
Components that do not implement safety mechanisms propagate all incoming malfunctions to the output ports. For each output port, contract C1 is considered as atemplate.
C1

A:
G:

none of { Ma ⊆ {{m}|m ∈ MC }} occurs.
{output_mf} does not occur.

The set Ma is a subset of all malfunctions of the component C, either on input ports orinternal ones (MC ). In Ma all the malfunctions shall be listed that can potentially cause
the output-malfunction to occur. Since no safety mechanisms shall be implemented bycomponent C, all input malfunctions assigned to ports that are needed to create theoutput, are part of Ma . In addition all internal malfunctions that can cause the output
malfunction to occur. Not necessarily all internal malfunctions need to cause an output
to fail. E.g., an internal malfunction that causes AD-conversion to be less accurate will
not affect output ports, which results do not rely on any analog signals.
Such a contract needs to be stated for all possible malfunctions on the output ports ofa component.
Template for Nondegrading Safety Mechanisms
A safety mechanism is responsible for detecting or mitigating an unwanted system state.
In contrast to the previously stated contract template, a safety mechanism is able tolimit the possible malfunction combinations that lead to unwanted situations. Thereis no special representation of a safety mechanism needed in the architecture, but it is97

4 Compositional Safety View

in1

Channel 1

in2

Channel 2

in3

Channel 3

c1_outc2_out2 oo 3Voterout

c3_outFigure 4.12 – Triple modular redundancy (TMR) as an example for a nondegrading safetymechanisms

advised to introduce one for clarity.
Figure 4.12 depicts a triple modular redundancy (Moore & Shannon, 1956) safetymechanism, which is one of the most common nondegrading safety mechanisms. Threechannels implement redundantly the calculation of the output, and pass their results toa voting component. The voting component compares the results and outputs the value,
which is identically calculated by at least two channels. Obviously, this approach can
only guarantee a correct result if at most one channel fails. Hence, the contract templatefor nondegrading safety mechanisms looks like:

C2

A:
G:

none of { Ma ⊆ P(MC )} occurs.
{output_mf} does not occur.

The set of malfunction combinations Ma in the contract template is a subset of thepowerset of all existing malfunctions MC on component C. In Ma all combinations ofmalfunctions are defined, that may potentially cause the output malfunction output_mf
to occur.
In contrast to components that do not implement safety mechanisms the size of the
cut-sets can be larger than one. In the above stated example of the TMR module, one
failed channel may not harm the correctness of the output. Hence, the cut-sets of thisexample safety mechanisms will contain only two elements. Assuming there is an input
malfunction for each input and an internal malfunction for each channel, the Ma wouldbe:98

4.3 A Specification Language Supporting Impact Analysis{{in1_f ail, channel2_f ail},{in1_f ail, channel3_f ail},{in2_f ail, channel1_f ail},{in2_f ail, channel3_f ail},{in3_f ail, channel1_f ail},{in3_f ail, channel2_f ail},{channel1_f ail, channel2_f ail},{channel2_f ail, channel3_f ail},{channel1_f ail, channel3_f ail},{in1_f ail, in2_f ail},{in2_f ail, in3_f ail},{in1_f ail, in3_f ail}}
Note, the combinations of input malfunction at the same failed channel are notconsidered here. In this architecture the combination of these faults would not leadto wrong output singal, since two correctly working channels exist. Furthermore, wehave not assigned an internal malfunction to the voting component. This is a common
principle in the design of safety critical systems (Bozzano & Villafiorita, 2011). The voting
component is a single-point of failure. The only way to prevent this is an architecturethat uses three voters and all functions of a system are implemented three times (VonNeumann, 1956; Moore & Shannon, 1956). This architecture is typically used in airplanes
but not in automotive systems. Still, the ISO 26262 requires the freedom of single point
faults “This requirement applies to ASIL (B), C, and D of the safety goal. Evidence ofthe effectiveness of safety mechanisms to avoid single-point faults shall be made available.”(ISO 26262 (2011), Part 5, Req. 7.4.3.3). To be able to meet this requirement, the voting
component is being designed in a more robust way than the other parts of the system.
This includes techniques such as formal verification of the voting logic, which is feasable
in short time because of the low complexity of the arbitration logic. Furthermore, theISO 26262 does not consider faults resulting from defects in the execution platform as
single-point of failures if at least one safety mechanism exists to monitor the platform: “Ifa hardware part has at least one safety mechanism (e.g. a watchdog for a microcontroller),then none of the faults of that part are classified as a single-point faults. The faults forwhich the safety mechanisms do not prevent the violation of the safety goal are classified
as residual faults.”
Template for Immediate Degrading Safety Mechanisms
In many cases it is not possible to implement nondegrading safety mechanisms, because
either the necessary redundancy is too costly or other constraints, such as available spaceor computing resources, prevent such an approach. Hence, degrading safety mechanisms

99

4 Compositional Safety View

c1_outin1

Channel 1
Overridein2

Channel 2c2_outout

Figure 4.13 – Immediately degrading safety mechanisms implemented by two redundant
channels

provide a cheaper possibility for switching to a safe-state after detecting malfunctions inthe system. This degradation may happen immediately after the fault occurs or sometime after.
Figure 4.13 depicts a two-channel voting architecture as an example for an immediately
degrading safety mechanism. Both channels implement a functionality redundantly andthe voter compares the signal. In contrast to the nondegrading safety mechanism thevoter is not able to determine which is the correct signal, but is only able to detect a
deviation in the signals. Hence, switching to a safe state is the only possible action tooperate the system safely.
Contract C3 depicts the template for the immediate degrading safety mechanism.
C3

A:
G:

none of { Ma ⊆ P(MC )} occurs.
{output_mf and !output_safe} does not occur.

The guarantee of this contract deviates from the promises in the previous two templates.
The safety mechanism is able to guarantee that the system is correct OR at least safe
even considering cut-sets of size > 1. This is expressed by two separate malfunctions of
the output port. The malfunction fail simply indicates that the output is different thanspecified in case the system is working correctly and the malfunction safe indicates thatthe system is in its safe state. The safe state can be observed at the output easily, since
the safe state is a known value (like light on, in case of the light sensor). With respect tothe example in Figure 4.13 Ma is given as:{{in1_f ail, channel2_f ail},{in2_f ail, channel1_f ail},{in1_f ail, in2_f ail},{channel1_f ail, channel2_f ail}}
The handling of the voting component needs to be identical as in case of the nondegrading safety mechanism.
In addition to the stated contract C3 an additional contract needs to be stated that
requires the correct signal in case of no malfunctions in the system (see Contract C4 ).

100

4.3 A Specification Language Supporting Impact Analysis

brokenWatchdog

Override
reset

c_out
out

in2

Controller

Figure 4.14 – Watchdog as an example for a delayed degrading safety mechanism

Therefore, the assumption lists all malfunctions, and the guarantee lists the output
malfunction. We call this contract also a performance safety contract, since it is notnecessary for the safety analysis. Without this contract it would be a valid behaviorof the system to always remain in the safe state. This is safe, but obviously does notcomply with the expectation of the customer to receive an operational item.
C4

A:
G:

none of {Ma ⊆ P(MC )} occurs.
{output_mf} does not occur.

The safety mechanism with two redundant channels is only an example of many othertechniques in this category. Still, the architecture will mostly look identical, though thedegree of the redundancy differs. For example, a consistency check, which validates theresult with respect to an estimate or defined bounds, does not need to fully implement
the monitored function. A less precise calculation can be sufficient to identify wrong
results. Similarly failed CRCs in transferred messages use information redundancy to beable to detect a well-defined type of signal malfunction.
Template for Delayed Degrading Safety Mechanisms
In some cases it is not possible to create any redundancy that is suitable for a safetymechanism. One typical example is the microcontroller itself. Although some more
expensive devices provide lock-stepping of two redundant cores (Functional lockstep
arrangement for redundant processors, 1993), the majority of systems is using watchdogs
to detect faults in the hardware platform. As depicted in Figure 4.14, the controller
needs to re-set the watchdog-timer on a regular time base. If this re-set is not performed,
the watchdog assumes that the controller is malfunctioning and can switch the system
to a safe-state. Hence, the time between the occurring malfunction and the detectionof it is defined by the re-set interval of the watchdog. During the occurrence of themalfunction and the detection, the component is producing wrong results. Depending
upon the function the system is implementing, this behavior is acceptable as long as themalfunction will be detected within some appropriate time period (the FTTI).
Contract C5 can be used as a template to describe delayed degrading safety mechanisms.

101

4 Compositional Safety View

C5

A:
G:

none of { Ma ⊆ P(MC )} occurs.
{perm(output_mf and !output_safe)} does not occur.

While the handling of the assumption is identical to the immediately degrading safetymechanism, the guarantee is using the perm operator to relax the guarantee. Hence, thecontract guarantees that the situation in which the output delivers a wrong result andno safe-state has been established, is not permanent. In terms of LTL, the perm operator
translates to globally. Hence, the promise of contract C5 translates to:G(¬G(output_f ail ∧ ¬output_saf e))⇔G(F (¬output_f ail ∨ output_saf e))Hence, at each time in the trace there must exist a point in the future where the system
is either safe or correct.
Again, it is advised to state also a performance safety contract as depicted in Contract C4 .

4.3.3 Abstract Safety Specifications
Following the templates given in section 4.3.2 we are able to specify a functional safetyconcept on one level of abstraction. We have not yet considered how specification on
multiple component levels (nested components) need to be formulated.
The approach, which is taken by the existing safety specification, is based on modularization rather on abstraction. Approaches like Hip-Hops or Pasquini et al. (1999) or
Wallace (2005) compose the already existing properties of a set of subcomponents to asingle larger component.
This means that fault propagations are described on the component level and canbe modularized to larger components, but the composed specification is still using theconstructs of the subcomponents. As an example in Oertel et al. (2014) the top levelsafety contract is using all non-desired atomic malfunction combinations in its assumption,even if the atomic malfunctions correspond to components of a more detailed abstractionlevel. Figure 4.15 illustrates that all faults in the most detailed (lowest abstractionlevel) components need to be made available to the containing components by use of
fault ports. Hence, these specific malfunctions are “externalized” to the surrounding
components. This approach is not compositional, since changes on internal components
necessarily causes re-verification effort on the containing component. Furthermore, a
top-down design is impossible, since it is assumed that all components and their faults
are known in advance.
This problem is directly related to the identified gap on the current existing safety
specifications (see Section 4.1 and 4.2.1), that is, the lack of abstraction possibilities.
These techniques are necessary in order to support the top-down process of the ISO 26262.
The main argumentation path of the ISO 26262 is to identify early the possible hazards
that a system might produce and try to prevent them in the functional safety concept.

102

4.3 A Specification Language Supporting Impact Analysis
c1.1_failc1.2_failc2_fail

Ctop
C1

C2

in1
C1.1
in1_fail
out2_fail

out1

out2
in2

out
C1.2

in2_fail

out2_fail
out_fail
out_safe

Figure 4.15 – All internal faults were “externalized” using fault activation ports

After the verification of the functional safety concept. The requirements are further
refined towards technical safety requirements. Hence, the malfunctions at the lowest levelof abstraction are not yet known. And even in the FSC, refinement is extensively used.
Bottom-up techniques would invalidate all gained verification results, because they are
not mappable to the existing verification results (see also Figure 4.15).
To enable a top-down design, the specification needs to be designed in a way, that theearly gained analysis results still maintain their validity even if new subcomponents are
introduced. The use of contracts does not provide this property as is. Hence, a fault
abstraction concept needs to be introduced. Looking at figure 4.15 it can be observed,that the malfunctions on the input and output ports are handled correctly. This means,that the contract describing the top level component does not need any externalized
malfunctions on input and output ports. Each component has its own input and output
malfunction ports, which are local to the component. Nevertheless, to handle internal
malfunctions, a new approach is needed.
A Fault Abstracting Specification
To identify a suitable solution the actual goals of the assumptions have to be identified.
According to the templates provided in Section 4.3.2, the assumption states all combinations of malfunctions that can potentially cause an output to fail. Still, the important
information is the minimal size of the cut-sets, which represents if the component does
provide a certain level of fault tolerance. Hence, instead of specifying the concrete set ofinternal malfunctions it is sufficient to specify the minimal size of the cut-sets. This gives103

4 Compositional Safety View

the engineers freedom in how to implement the component. Using this technique we arestill able to express the absence of single-points of failure, as required by the ISO 26262,
but do not need to state all particular faults individually. Thereby this generalization
enables a top-down design approach.
#ctop_malfunctios
Ctop

Splitter#c2_malfunctions#c1_malfunctions
C1

C2

Splitter

C1.1_failC1.2_failin1
C1.1
in1_fail
out2_fail

out1

out2
in2

out
C1.2

in2_fail

out_fail
out2_failout_safe

Figure 4.16 – Count ports are introduced and fault-splitter components ensure that no
more faults are passed to internal components than specified

Still, an technical solution is needed, that integrates with the contract-based designprinciples and is still compatible with the defined contract templates and other identified
requirements on the safety specification.
Therefore, since contracts are defined over traces on values of ports, we introduce
malfunction count ports representing how many internal malfunctions are present in
a component (see Figure 4.16). Only at the most detailed abstraction level (i.e., theimplementation) do the particular malfunctions that might occur in a component need
to be specified. The fault count ports are of type Integer and belong to the safety aspect104

4.3 A Specification Language Supporting Impact Analysis

of a system only. As for the fault ports, these ports are virtual and do not occur inany generated or manually produced implementation. The malfunction count ports canbe used as placeholders in the cut-sets specified in the assumptions to represent any
combination of internal malfunctions of the given size. Hence, the malfunction countports cannot be simply connected to the subcomponents, but additional constraints need
to be fulfilled. Since only components can be associated with a specification and not thesignals by themselves, we need to introduce virtual splitter components to distribute themaximum number of malfunctions of the surrounding component to its subcomponents.
The splitters are necessary to allow only traces that do respect the number of malfunctions,while still leaving open the choice of how to distribute them across the subcomponents(see Figure 4.16). For n subcomponents the contract associated to the splitter component
can also be characterized by the following contract:

C6

A:
G:

true
out1 + ...

+ outn = #internal_mf

The guarantee creates a relation between the input port of the splitter (#internal_mf)
and the output ports (outn ). If a cut-set in the assumption includes an internal malfunction count of x, this contract ensures that exactly x faults are activated on thesubcomponents.
This approach is still compliant to the contract-based design principles, since all statedcontracts only refer to its input and output ports. Hence, all defined relations andoperators, like refinement and composition, are still applicable.
Intermediate and top level component’s safety requirements can be specified using the
malfunction count ports. The most common usage for the top level assumption is tostate that only one or two faults occur in the system to express that there shall be nosingle or double faults in the system. For example, a specification of the component C_1
in Figure 4.16 could be stated as follows:
A:
C7
G:

none of {{in1_fail, in2_fail},{C_1_#internal_faults=1, in1_fail},{C_1_#internal_faults=1, in2_fail},{C_1_#internal_faults=2} } occurs.
{out2_fail AND !out2_safe} does not occur.

This specification defines, that the component shall be robust against one arbitrary
malfunction, which may occur at one of the inputs or internally. Another useful scenario
is that the inputs are assumed to be correct and only internal faults are considered. Sucha contract can now be stated in a very short way:

C8

A:
G:

none of {{C_1_#internal_faults=2} } occurs.
{out2_fail AND !out2_safe} does not occur.

105

4 Compositional Safety View

The specification of an atomic component (like C_1.2 in Figure 4.16), for which
the internal malfunctions are known, uses these atomic internal malfunctions, since noabstraction by using a fault count is necessary. The internal faults are represented as
individual fault ports (see C_1.2_fault on component C_1.2 in Figure 4.16) and are
directly connected to the splitter components. This ensures, that the specification of theatomic component can still be done accordingly to the guidelines presented in section
4.3.2 however one can additionally restrict the total number of different individual faults
occurring simultaneously (in the same trace) on a more abstract and simpler level.
Semantics and Verification of Malfunction Abstraction
After having described the main idea and usage of the fault abstraction technique, theprecise semantics need to be defined in order to be able develop an automatic analysis
framework. The safety pattern semantics are defined using LTL (Pnueli, 1977). Since
fast LTL model checkers are available, the development of a new semantic base should be
avoided. Furthermore, the fault count ports should be defined using LTL. Nevertheless,since LTL does not provide a representation of integer values, a mapping to boolean logic
needs to be created. Still, from a user’s perspective the workflow does not change. The
specification should be written using the integer fault ports, and the mapping performed
completely automatically.
Since all malfunction count numbers are explicitly stated, and we do not consider
unbounded variables, the integer ports can be expressed in a combinatorial fashion.
Hence, a malfunction count port is split up in individual boolean ports (explicit fault
count ports) representing each a valid value of this port (see Figure 4.17). If a contract
assumes that n malfunctions do not occur in the system, all numbers of faults smaller
than n are valid values. It needs to be stated that only one of these ports can be activeat a time.
A:
G:
C9

true
none of {{0_faults_Ctop, 1_faults_Ctop},{1_faults_Ctop, 2_faults_Ctop},{0_faults_Ctop, 2_faults_Ctop}} occurs.

Furthermore, we need a separate splitter component for each explicit fault number port.
These splitters allow all logical combinations of ports that sum up to the defined numberof faults. For n internal faults and m subcomponents the splitter contract restricts the setof all possible occurring malfunctions M = P({X0 _f aults_C0, . . . , Xn _f aults_Cm})
to Mf :
C10

106

A:
G:

true
none of {Mf } occurs.

4.4 Process Guidance on Creating an Initial Architecture
C_0_mf

C_1_mfC_2_mfSplitter

Splitter

SplitterC

C1_0_mf C1_1_mf C1_2_mf

C2_0_mf C2_1_mf C2_2_mf

C1

C2

Figure 4.17 – Explicitly represent the counting with boolean logic for LTL implementation.
In this example a fault port with the value 2 is represented.
P(n+1)·m

with Mf = {{xi _f aults_Cy } ⊆ M : i=1
xi ≥ n}.
Nevertheless, for the purpose of a single refinement analysis we can simplify thetranslation, since at analysis time splitters are not needed and can be replaced by all
combinations of faults of the subcomponents directly. For a given set of internal faults I
the malfunction-count port #internal_faults=n in the assumption resolves to all sets
of faults of length n of the powerset P(I). The refinement check is then implemented asa satisfaction check on the LTL formulas of the contracts (see Section 2.1.5). Rozier andVardi (2007) as well as Li, Pu, Zhang, Vardi, and He (2014) suggested using a genericmodel, allowing all possible behavior, to check the property against reducing the problem
to a classical model checking problem.

4.4 Process Guidance on Creating an Initial Architecture
In addition to the defined templates for contracts, the process of how to create a safety
specification can be guided with a few practices. This is a guideline for describing thesafety concept, not for developing the safety concept itself. These guidelines suggest asuitable process, however, other solutions are not excluded.
Design Practice 1. The architecture and the specification, as well as the functional
and the safety aspect shall be defined for one abstraction level in parallel.
The parallelism of architecture and requirement design is necessary to comply withthe structural consistency criterion of contact based design on the one hand (see Section
3.3.1), and to comply with the ISO 26262 process on the other hand. The functional
and the safety aspect (see Section 2.2.2) are also typically designed in parallel. This107

4 Compositional Safety View

stems from the simple fact that the safety concept shall ensure the safe execution of
the behavior defined in the functional aspect. Hence, the number of components andtheir interconnections are mostly given by the functionality of the component. Even
though the malfunctions are defined for the functional ports of the component, theactivities of designing the functional and safety specification are interwoven. Although
the functional architecture is the base for the first iteration of the safety concept, it is likelythat additional components for voters or redundant channels need to be added. These
components also fulfill a functionality, and hence, in addition to the safety requirementsthat state the malfunction propagation, functional requirements also need to be added.
For example, the functional requirement for the voter in Figure 4.13 could be:
C11

A:
G:

true
in1 = in2 → out = in1 ∧ in1 6= in2 → out = 255

If the inputs deviate the output is set to 255, if the inputs are identical, this value ispassed through. Hence, in the functional requirement the safe state is not mentioned,
but the functional value, 255 in this case, is used. As a result, at least one iteration of
the functional and the safety aspect needs to be performed to check the modificationon the component structure, which is necessary to implement the safety mechanism andstate the missing functional requirements, if possible. It could also be a result of theanalysis of the functional aspect that the functions cannot be implemented correctly inthe presence of the added safety mechanisms. Possible reasons could be the exceeding ofresource constraints like space or timing. Hence, to avoid unnecessary iterations, bothaspects should be designed commonly.
Design Practice 2. Top level safety specifications represent the negated hazards. Thesemay include already inhibition keywords that shall be used for the malfunction mode. Use
safe-states if identified in HARA.
Starting with the top-level component the main functional and safety requirements
need to be specified. While the functional requirements typically results directly fromthe item definition (see introduction to ISO 26262 in Section 2.3), the safety goals are
typically the negation of the identified hazards. Since the hazard identification also uses
function modifier keywords for the identification of hazards, like “wrong function,” “toomuch function” or “too early function” these keywords can directly be used to define theavoided output malfunction. Identified safe-states need to be stated: “If a safety goal
can be achieved by transitioning to, or by maintaining, one or more safe states, then thecorresponding safe state(s) shall be specified” (ISO 26262, 2011).
Design Practice 3. Describe malfunctions on signals and atomic malfunctions detailed
in a table. The focus shall be on how and how much the value may deviate from theintended one if the malfunction is present.
Although the identifier of the malfunction is sufficient to analyze the refinement of
the safety specification, the satisfaction analysis (see Section 4.5.2) needs a detailed108

4.4 Process Guidance on Creating an Initial Architecture

description of the effect of a malfunction on the corresponding signal. Still, even if it
is not planned to run automated satisfaction checks, the description is useful for thedesigners of the lower levels in the component structure, since the choice of the proper
safety mechanism heavily depends upon the concrete malfunction.
Design Practice 4. If a fault tolerance time interval is defined for the hazard a delay
shall be specified for the corresponding malfunction.
The decision whether an immediate degrading or delayed degrading specification should
be chosen for the top level safety contracts depends upon the existence of a FTTI for therespective hazard. For the safety specification we do not state the concrete time, but use
the perm operator instead (as indicated in contract template C5 ). The verification of theconcrete timing properties is part of the timing aspect. For this aspect formal languaages
and virtual integration techniques exist that can be used to validate the correct break
down of timing requirements such as presented by Damm et al. (2011) as well as Gezgin
et al. (2014).
Design Practice 5. If no further requirements to the degree of fault tolerace exists,
assume only one fault within the item.
As has already been discussed, the freedom from malfunctions on a particular output
port of the system can only be guaranteed under special circumstances. Any system,
even the most carefully developed ones, may fail if the number of faults exceeds a certain
threshold. Hence, the assumptions on top level are critical to the further developmentof the system. These assumptions of the top level safety contracts are dependent on
the malfunctions on inputs that are needed to produce the considered output and theinternal malfunctions. If not stated otherwise in the requirements on the item it isa good starting point to avoid single point failures in the system: “Evidence of theeffectiveness of safety mechanisms to avoid single-point faults shall be made available[...] [to show] the ability of the safety mechanisms to maintain a safe state, or to switch
safely into a safe state” (ISO 26262, 2011). Although this requirement is stated for the
hardware design only, a dependent failure analysis to identify these faults is required forthe whole system: “The analysis of dependent failures aims to identify the single events
or single causes that could bypass or invalidate a required independence or freedom frominterference between given elements and violate a safety requirement or a safety goal.”Hence, the minimal size of the cut-sets shall be at least two in the assumption. Internalfaults are only referenced by malfunction count ports. While developing a system in a
distributed manner, cut-sets with single sized elements may occur. This is acceptable if
the component shall be implemented by a different supplier, which shall not take care ofthis individual malfunction, because it might be handled by a different component.
Design Practice 6. For refined components the higher level component is the context.
If the top-level component is refined, the context for the specification of the subrequirements is the top-level component. Hence, the malfunction on the output is alreadydefined and all input malfunctions are known. The actual engineering of the solution to109

4 Compositional Safety View

the stated problem is starting at that point. It is not in the scope of this thesis to give
guidance on how to build good safety concepts; this remains the responsibility of theinvolved developers. Still, their decisions are documented in the form of safety contracts.
On the refined levels the templates can be used as well to describe the requirements on
the various components in the architecture.
Design Practice 7. Virtual integration checks shall be applied for any component
refinement to detect design faults in the architecture.
The automation of the refinement and satisfaction analysis is in particular necessary
to provide an automatic impact analysis. Nevertheless, during the development of theinitial architecture, the virtual integration check indicates at early design stages thatthe developed solution for the context defined by the top-level component or anotherhigher-level component, does not cover the needs expressed by this context.

4.5 Analysis of Safety Contracts
To cover the requirements identified during the gap analysis (see Section 4.2.1) for change
impact approaches, the specification language for functional safety concepts has to be
automatically analyzable with respect to refinement and satisfaction.

4.5.1 Refinement Analysis
To perform a refinement analysis on safety contracts it is not necessary to develop a newtechnique. Since the properties are strictly defined in LTL the theorems presented in
Section 2.1 are sufficient to prove virtual integration.
A technical solution based on these theorems is presented in Section 6.2.

4.5.2 Satisfaction Analysis
As indicated by Figure 3.13, only the lowest abstraction levels of components will be
implemented, and the compliance of the system with the requirements will be proven by
virtual integration checks once it has been shown that the implementations satisfy thestated requirements on the associated component.
This analysis is typically performed by reviews or testing (Ellims, Bridges, & Ince, 2006).
Although advances have been made in the field of automatic testcase generation, testing
techniques suffer from their incompleteness, since only a selection of all possible test
vectors are applied to the system. As an alternative technique to test safety properties,
fault injection (Arlat et al., 1990; Svenningsson, Vinter, Eriksson, & Törngren, 2010) canbe used. Still, relying on simulative or experimental approaches, most fault injection
approaches do not deliver complete results. To gain completeness, several fault injection
analyses that rely on model checking such as (Bozzano & Villafiorita, 2003) and (Joshi &Heimdahl, 2005) have been presented. Another possibility consists in comparing existingfault tree analyses (FTA) or failure modes and effects analyses (FMEA) with the safety1104.5 Analysis of Safety Contracts

specifications (Schäfer, 2003). Again, this is a manual and error prone process. We built
upon a formal, model checking-based fault injection technique (Peikenkamp et al., 2006),(Kacimi, Ellen, Oertel, & Sojka, 2014)
Fault Injection
A technique to verify fault tolerance mechanisms is fault-injection. It is defined by Arlat
et al. (1990) as “the deliberate introduction of faults into a system.” In order to executea fault injection four inputs are needed. The set of faults F , which is typically describedby Poisson processes, and the set of activation A, which can be either represented as
stochastic processes or test data patterns. The results of one of the fault-injection
experiments is extracted from the set of readouts R. The measures M can only beobtained experimentally and represent the findings of the fault-injection test sequence,for example, a MTBF or a boolean variable that indicated the removal of a fault.
While performing fault injection using a formal model (Peikenkamp et al., 2006) the
set of activations is complete with respect to all input combinations and does not need
to be specified.
Hence, we refer to a fault-injection as a function F I with three arguments: an
Implementation I and a set of faults F and the functional requirement r, representing
the measure, that the system shall implement. Each fault f ∈ F has a formal description
F(f ) of the functional deviation if the fault is present. The result is a set C of fault
combinations leading to the violation of r.
FI(r, I, F ) = C ⊆ P(F ),with P denoting the powerset.
Analyzing Safety Contracts using Fault-Injection
The fault injection technique uses function properties as a target for verification. These
functional requirements are concerned about the occurrence, order or value of signals. In
contrast, we want to analyze safety contracts that specify the propagation of faults inthe system, addressing the correctness of a signal. The safety ports, which represent thestatus of a signal are not available in the implementation. These ports are virtual and used
for specification purposes only. Still, although safety and functional analyses are mostly
performed separated from each other, there is a relation between them, which needs to bedetailed, in order to provide the desired satisfaction analysis of safety contracts. Hence,
the functional deviation described by the guarantee of the safety contract needs to be
determined. This functional deviation is used in the fault injection analysis as a target.
All combinations of malfunctions that lead to this deviation need to be identified.
To specify a functional requirement for the FI analysis the definitions of the malfunctions
can be used. Nevertheless, the description of the malfunctions are not necessarily
completely functional. That is, they may contain a reference to the correct value ofa signal. Some examples of formal descriptions of malfunctions can be seen in Table
4.4. We will later detail why these references do not need to be resolved. Given the111

4 Compositional Safety View

set of cut-sets of the guarantee Cp of the safety contract and the specification of themalfunction m ∈ M as F(m), the functional requirement can be expressed as Φ(Cp , F)with:
Φ(Cp , F) =

^ _

¬F(c)

C∈Cp c∈C

To validate if an implementation correctly implements the fault propagation specification given by a safety contract (e.g., C13 ), we need to identify which combinations ofmalfunctions cause the behavior given by Φ({{c_wrong}}, F), where F is defined by
Table 4.4. Figure 4.18 describes the principal relation between a safety contract, themalfunctions of a system and the result of a fault injection analysis.
Safety Contract

Definition of Malfunctions (F)A: none of {Mf} does occur.
P: {out_fail} does not occur.

out_fail <=> out != ...

Top Level Event? (out_fail,F)

Component

Input Malfunctions

Output Malfunctions
Internal Malfunctions= Mf

Figure 4.18 – Relation of a safety contract to the FTA results of the implementation of thecomponent

The assumption of a safety contract specifies the combination of malfunctions that
potentially leads to a wrong output, which is described in the guarantee. If the output of
a component C is prone to a malfunction m, this means that the functional requirement
rf describing the expected value is violated, and instead F(m) is holding at the output.
To verify the safety contract we need to know which malfunction combinations of internal
and input malfunctions lead to this deviation on the output. Hence, ¬F(m) is passed
to the fault-injection analysis, together with all definitions of the malfunctions m ∈ M
that might occur in a component. The created minimal cut-sets generated by the fault
injection analysis represent all combinations of malfunctions that lead to the specified
output deviation. Hence, to verify if the implementation does correctly implement the112

4.5 Analysis of Safety Contracts

a_outofboundsca_toolowc_toolowac_wrongbc_safeb_wrong

int_stuck_a

Figure 4.19 – A adder with limited fault tolerance capabilities

defined malfunction propagation behavior, the resulting cut-sets of the fault-injection
analysis need to be a subset of the malfunction combinations Mf specified in the safetycontract:
F I(r, I, F ) F Mf

where X F Y iff ∀x ∈ X : ∃y ∈ Y : ∀yi ∈ y : ∃xi ∈ x. This relation requires X and Y
to be a set of sets.
We illustrate the approach on a small example. Figure 4.19 depicts a component, that
calculates the sum of two input signals. Hence, the functional requirement rf of Csum isgiven as:
C12

A:
G:

always(a ≤ 10 ∧ b ≤ 10)
always(c = a + b)

One of the safety contracts is given as:
A:
C13
G:

none of {{a_toolow},{b_wrong},{int_stuck_a}}occurs.
{c_wrong} does not occur.

Looking at the safety contract C13 , the guarantee ensures that the output malfunction
c_wrong may only occur under a limited set of internal and input malfunctions. The
behavior of the components in case of this output malfunction is given as F(c_wrong) =c 6= a + b. Hence, the functional requirement for the fault-injection analysis is given as:Φ({{c_wrong}}, F) =0 c = a + b0
Table 4.4 depicts a full list of the malfunctions and the resulting formalization F.
It can be observed that internal malfunctions and violations of assumptions on the
input ports are easily described. Internal malfunctions refer only to input or output
values and directly describe the deviation to the intended functional variables. Similarly113

4 Compositional Safety View

Malfunction m

Description

Formalized

a_outofbounds

the input exceeds the expectedbounda > 10a_toolow

the input is within the bound, a < a_correct
but larger than it should beb_wrong

the input is wrong compared tocorrectly working systemc_toolow

the output is lower than ex- c < a_correct + b_correct
pectedc_wrong

the output is wrong

c 6= a_correct + b_correctc_safethe output might be wrong but
in a safe-satec = 20

int_a_stuck

hardware defect of the addercausing value a to be stuck at 0a=0

b 6= b_correct

Table 4.4 – Description of the malfunction of the component depicted in Figure 4.19

the a_outofbounds malfunctions directly describe the values of the input that are notexpected. The other output and input malfunctions refer to the correct values. For
example, the malfunction a_toolow indicates that a is smaller than the correct value.
The classifier a_correct is handled as any other malfunction in the system since it
represents a nonexisting deviation of the value of the corresponding signal. It refers to
the intended value of the system, which is operating without any present malfunction.
Nevertheless, this kind of specification is necessary since the safety contracts describechange propagation and on the output of the top level component a judgment of the overallcorrectness of the signal needs to be made. Hence, the input and output malfunctions
are the main transport element to propagate deviations of signals from one part of thesystem to another.
However, for analyzing the fault containment properties of an individual component,
it is not necessary for the components themselves to judge about the correctness of the
input signals. Any possible input could be correct or incorrect, depending upon the stateof the system in which the component is embedded. Therefore, we extend the modelwith an additional component that simulates the input malfunction (see Figure 4.20).
The correct value is provided at the input of the extended component and the output of
the component is either identical to the input value if no malfunction is present, or, if
the malfunction is present, the value is modified according to the description of the input
malfunction. Hence, in this additional component, the input malfunction is represented
as an internal malfunction. The functional requirement erf for the extended component
is given as:114

4.5 Analysis of Safety Contracts

C14

A:
G:

true
always(in_correct = in)

In case of a malfunction, for example, in_fail the deviation Φ{{in_correct_toolow}, F}
results in “in 6= in_correct.” Furthermore, although the analysis is performed locally, we
can still reason on the global correctness of output signals if the system is composed ofmultiple components.
C
in
out

in_correct
Coriginal

Cextended

out_fail

in_correct_fail
in_failFigure 4.20 – Extending the system model to represent input malfunctions

Safety contracts describing safety mechanisms (see Contract C15 ) and including areference to the safe-state of the system can be handled identically. For the function
F we assume that it handles composite cut-set elements such as output_fail and!output_safe as well. It holds that F(m1 and m2 ) ⇒ (F(m1 ) ∧ F(m2 )).
C15

A:
G:

none of {{Mf }} occurs.
{out_fail and !out_safe} does not occur.

Assuming that out_safe is given as out = 20 and out_fail as out =6 in_correct + 2:
Φ({{out_f ailand!out_saf e}}, F) = (out = in_correct + 2) ∨ (out = 20)
In contrast to the already presented creations of fault-injection tasks for safety contracts,
the template for delayed degrading safety mechanisms needs to be handled differently.
Contract C16 uses the perm operator to indicate that finally the wrong output will be
detected and a safe-state will be established.

C16

A:
G:

none of {{Mf }} occurs.
{perm(output_fail and !output_safe)} does notoccur.

It may be sufficient for an abstract safety concept to specify that the wrong result is
not permanently in the system, however, for a concrete implementation it is necessary
to specify a time bound. This time bound, the Fault Tolerant Time Interval specifies
the maximum time between the occurrence of the fault and the attainability of thesafe-state. Hence, the requirement statement to be checked by the fault-injection analysis
is, informally:
whenever failure occurs then (safestate or !failure)115

4 Compositional Safety View

occurs within the FTTI
Since this requirement cannot be expressed with propositional logic, we need to integrate
it directly in the behavioral model of the implementation as an observer (see Figure 4.21).
Instead of the requirement we run the fault-injection analysis with a reference to thefail state, which shall not be reached:G(¬f ail)!(out_fail & !out_safe)

out_fail & !out_safe /cnt++

out_fail & !out_safe /cnt := 001cnt=FTTI

fail!(out_fail & !out_safe)

Figure 4.21 – Automaton for Perm with a given Bound

4.6 Conclusion
In this chapter a compositional safety view has been developed to reduce re-verification
costs by enabling a determination of the area of the system affected by the incorporatedchanges. Furthermore, parts of a system can be re-used in other products. We havestated five requirements on the safety specification:• Requirements shall be represented as contracts.
We presented an approach to enable black-box safety specifications using safetycontracts. Safety contracts use existing work, such as the formal safety pattern,but extend them e.g. with capabilities to specify multiple failure modes for one
functional signal to represent also safe states of the system (see Section 4.3.1).
• The concepts used in the development of functional safety concepts according toISO 26262 shall be represented, as described by Figure 4.10.
We provided guidelines in the form of contract templates, which cover the needs ofthe functional safety concept of the ISO 26262. These contract templates can beused to specify the commonly used conceptual elements such as nondegrading safetymechanisms or delayed degrading safety mechanisms. Furthermore, we presented
design guidelines how to develop a specification for a safety concept from scratch.
This model can be used as a starting point for the impact analysis techniquepresented in Chapter 3.

116

4.6 Conclusion• The language to express the requirements shall provide means for abstraction.
In contrast to other safety specification approaches safety contracts provide ameans of abstraction (see Section 4.3.3), thereby allowing the development of asystem in a top-down manner, that is, to refine the specification by introducing thepossible architecture of the subcomponents at a later point in time. We gained thisproperty by developing a new fault abstraction technique for contracts using fault
count ports and splitter components. In addition, this specification is closer to therequirements of current safety standards, and industrial needs often requiring theabsence of single-point-failures without detailing the specific faults. Furthermore, it
can be guaranteed that verification results gained in early stages of the development
process do not get invalidated by refining the system.
• The refinement property of the requirements shall be automatically analyzable.
The semantics of safety pattern are based on LTL, which allows to use the existing
formulas for refinement as stated in literature (see Section 4.5.1)• The compliance of the requirements to implementations shall be automatically analyzable.
To be able to prove that an implementation correctly implements the fault propagation behavior specified by a safety contract, we based our approach on a fault
injection technique. The relation between functional and safety specifications
needed to be detailed to determine the functional deviation of a signal in the presence of a malfunction. Finally, we are able to locally analyze the fault propagationof a component while being able to use the result in the context of the wholesystem. This refers to the challenge that typically only malfunctions on the top
level component are interesting for integrators or customers. Hence, the output
malfunctions need to represent the “global truth” of the corresponding signals.
Hence, malfunctions are described as deviations to a system without any present
input or internal fault.
Using our specification and analysis technique it is now possible to judge the correctnessof the output signals if all atomic components adhere to their specifications, and allrefinement analyses of the components are successful. Hence, a virtual integration of
the safety aspect is now possible. Impacts of changes in functional safety concepts are
now identifiable. This means, if only parts of the safety specification have been changed,
then only parts need to be re-verified. Other refinement and satisfaction analysis results
are still valid without being re-calculated. Still, we need to evaluate if this approach isdelivering the expected linear performance between the size of the change and the effort
to re-verify the system.

117

CHAPTER

Evaluation
To evaluate the presented change impact analysis process and the developed formalism
for safety concepts, two different techniques are used. To demonstrate the applicabilityof the proposed safety contracts and contract templates for safety concepts as well as
the different analysis techniques, we provide an example in section 5.1, detailing thearchitecture, the safety requirements and also the functional requirements for a failsafe temperature sensor. The use-case is intentionally kept simple to still be able toprovide a complete system specification. Afterwards the system is modified, and the
proposed change management process instantiated and the required analyses and results
are presented. Nevertheless, this example does not give any quantification of the benefitof this approach compared with the current state of the art. This would require many
real-size systems, fully specified, and many different engineers involved, to get reliable
data. Hence, we have chosen to develop a simulation environment (see Section 5.2) togenerate architectures, perform changes and implement the engineers and automatic
analyses as stochastic processes. This approach has even some advantages over theevaluation using real system data: It is possible to directly compare how the different
parameters like size of the system, detection probabilities of the tests, the quality of theengineers or the number of requirements in a system influences the overall verification
effort. Hence, the circumstances in which the approach performs best are precisely
identifiable.

5.1 Example
In this example we step-by-step develop a functional and a safety specification for atemperature sensor. After this a change is introduced and the impact analysis process isused to determine in which region of the system the change is contained. This example
shall apply the presented specification and analysis approaches. The example does notintend to quantify the approach or compare the development to other approaches. This119

5

5 Evaluation

TemperatureSensor
Logic

env_temp

Override

temp1_out
ad1_out
temp1_out_fail
ad1_out_fail
TempSensor 1

AD1#sensor_mf

out
temp1_fail
Splitter
temp2_fail#logic_mf

ad1_fail
Splitterad2_fail

out_fail
out_warn

TempSensor 2AD2ad2_out

temp2_out
ad2_out_fail
temp2_out_fail
env_temp

Figure 5.1 – Architecture of a temperature sensor required to be robust against single-pointsof failure

quantitative analysis is performed in section 5.2.

5.1.1 Specification and Design of the Initial System
We built a fail-safe temperature sensor in a top-down design process. The temperature
sensor shall be used in the cooling system of the vehicle engine. The hazard analysis
revealed that measuring a value which is lower than the actual value could cause ahazardous situation and hence a safety requirement exists, such that the sensor shall
operate safely even in the presence of one fault. The safety contract describing that thesystem shall produce a correct, or at least safe, result in case of one fault, is:
C17

A:
G:

none of {{#internal_mf=2}} occurs.
{temp_out_fail AND !temp_out_safe} does not occur.

The complete architecture of the sensor is depicted in Figure 5.1. The function of
the temperature sensor shall be to deliver the value of the environmental temperature
with an accuracy of +/- 1◦ C. The environmental temperature is expected to be between−50◦ C and 200◦ C:

120

5.1 Example

C18

A:
G:

-50 ≤ env_temp ≤ 200((env_temp − 1) ≤ temp_out ≤ (env_temp + 1))

The safe-state of the temperature sensor is to output 200◦ C, the maximum temperature.
Note, that contract C17 and C18 alone do not specify the behavior correctly. Following
these requirements, a behavior that constantly outputs 200◦ C would be correct andit would be safe, but it is not desirable to build a device that does not measure thetemperature correctly. To exclude the unintended permanently safe-state behavior
we need to state an additional safety contract, which requires a correct output if nomalfunction is present in the component:
C19

A:
G:

none of {{#internal_mf=1}} occurs.
{temp_out_fail} does not occur.

These are the requirements that a company building temperature sensors may havereceived from an OEM that develops the whole cooling system for the engine. Still, if
they need to develop a new system because no existing sensor fulfills these requirements,
they need to refine the specification and the design.
A realization of these requirements on the next abstraction level can be a design
with two simple but redundant analog temperature sensors in addition to a logic which
provides the AD-conversion and a voting mechanism. The functional requirement of thetemperature sensors is to output the environmental temperature in the range of -50 to
200 as a linear voltage between 0 and 5V with an accuracy of 1◦ C:
C20

A:
G:

-50 ≤ env_temp ≤ 200(env_temp−1)+51≤ temp1_out ≤ (env_temp+1)+51
51
51

The functional contract for TempSensor2 is similarly:
C21

A:
G:

-50 ≤ env_temp ≤ 200(env_temp−1)+51≤ temp2_out ≤ (env_temp+1)+51
51
51

The sensors themselves do not provide any safety mechanisms and hence can failimmediately as a result of a single internal failure. Therefore, the safety contract for
TempSensor1 is:
C22

A:
G:

{temp1_fail} does not occur.
{temp1_out_fail} does not occur.

TempSensor2 is specified in an identical manner:
C23

A:
G:

{temp2_fail} does not occur.
{temp2_out_fail} does not occur.

121

5 Evaluation

The malfunction temp1_fail is defined as a generic internal failure of the component that leads to a random measurement and finally may cause a wrong value(temp1_out_fail) at the output (see Table 5.1). Note, that there are no input malfunctions defined for the environmental temperature, since this value is correct by definition.
Hence, we can replace env_temp_correct with the environmental temperature env_temp.
This behavior can be observed on all systems, that are specified in a way that the inputsof the system are expected to be correct. This allows to always find a functional representation for the correct signals at the input of components. Still, this is not the case for all
systems and not necessary for the approach, but since it increases the comprehensibility
the example has been chosen to provide this property.
Malfunction

Description

temp1_failThe sensing function temp1_out ∈ [−50, 200]
does not work properly,
no guarantee of the measures value within thetemperature range canbe given

temp2_failThe sensing function temp2_out ∈ [−50, 200]
does not work properly,
no guarantee of the measures value within thetemperature range canbe given

temp1_out_fail

temp1_out does not re- (temp1_out
flect the environmental (env_temp_correct−1)+51)
51
temperature within is ac- (temp1_out(env_temp_correct+1)+51
curacy range)

temp2_out_fail

temp2_out does not re- (temp2_out
flect the enironmental (env_temp_correct−1)+51)
51
temperature within is ac- (temp2_out(env_temp_correct+1)+51
curacy range)

122

Formalization

≤
∨
≥
⇔
51
(env_temp−1)+51(temp1_out ≤) ∨51(env_temp+1)+51(temp1_out ≥
)
51
≤
∨
≥
⇔
51
(env_temp−1)+51(temp2_out ≤) ∨51(env_temp+1)+51(temp2_out ≥)51

5.1 Example

Malfunction

Description

ad1_fail

The AD-conversion is (ad1_out 6= ((temp1_out · 51) − 51)) ∧not performed correctly, (ad1_out ∈ [0, 5])
no guarantee of the output can be given, except
of staying in the defined
limits of the output voltage

ad2_fail

The AD-conversion is (ad2_out 6= ((temp2_out · 51) − 51)) ∧not performed correctly, (ad2_out ∈ [0, 5])
no guarantee of the output can be given, except
of staying in the defined
limits of the output voltage

ad1_out_failThe output of the
AD-conversion does notreflect the correct value
within its accuracy
range

ad1_out 6= ((temp1_out_correct ·51) − 51) ⇔ (ad1_out ≤ env_temp −1) ∨ (ad1_out ≥ env_temp + 1)

ad2_out_failThe output of the
AD-conversion does notreflect the correct value
within its accuracy
range

ad2_out 6= ((temp2_out_correct ·51) − 51) ⇔ (ad2_out ≤ env_temp −1) ∨ (ad2_out ≥ env_temp + 1)

out_fail

The temperature sensor (out ≤ (env_temp − 1)) ∨ (out ≥does not output to cor- (env_temp+1)) ⇔ out 6= ad1_correct
rect environmental temperature within its defined accuracy range

out_safe

The safe-state is the
maximum temperature
the sensor is capable tomeasureFormalizationout = 200

Table 5.1 – Malfunctions and functional requirements of the automatic light manager

The logic component shall react to possible malfunctions in the temperature sensors.
As the internal structure has not yet been decided, the requirement states that even if
one of the inputs receives a wrong value or an internal fault occurs the result should atleast be safe (temp_out_safe). This requirement is expressed using a safety contract:123

5 Evaluation
A:

C24

G:

none of {{temp1_out_fail, temp2_out_fail},{#logic_mf=1, temp1_out_fail},{#logic_mf=1, temp2_out_fail},{#logic_mf=2}} occurs.
{temp_out_fail AND !temp_out_safe} does not occur.

The functional requirement of the logic component is to convert the signal to a digital
representation in ◦ C if both input signals are identical, otherwise output the maximum
value 200.
A:
C25 G:(0 ≤ temp1_out ≤ 5) ∧ (0 ≤ temp2_out ≤ 5)
(temp1_out = temp2_out) → temp_out = ((temp1_out · 51) −51) ∧ (temp1_out! = temp2_out) → temp_out = 200

Note, that in this refinement step also the splitter component is automatically generated
to split up the number of total malfunctions in the system onto the three components on
this abstraction level.
Again to force correct behavior in case of no malfunction, we state the following safetycontract:
A:
C26
G:

none of {{#logic_mf=1},{temp1_out_fail},{temp2_out_fail}} occurs.
{temp_out_fail} does not occur.

Compared to contract C19 also the internal malfunctions are considered here, whichwere not present at the TempSensor1 component.
In the refinement step of the Logic component two independent analog/digital converters are used to digitize the temperature signal. Both converters do not provide
safety mechanisms and fail immediately if the input is incorrect or the generic internal
malfunction ad1_fail occurs.
C27

A:
G:

none of {{ad1_fail},{temp1_out_fail}} occurs.
{ad1_out_fail} does not occur.

The functional conversion is described as:
C28

A:
G:

(0 ≤ temp1_out ≤ 5) ∧ (0 ≤ temp2_out ≤ 5)
ad1_out = ((temp1_out · 51) − 51)

Ad2 is specified similarly:1245.1 Example

C29

A:
G:

none of {{ad1_fail},{temp1_out_fail}} occurs.
{ad1_out_fail} does not occur.

A:G:(0 ≤ temp1_out ≤ 5) ∧ (0 ≤ temp2_out ≤ 5)
ad1_out = ((temp1_out · 51) − 51)

and
C30

On the AD-converters the difference between the internal malfunctions and the output
malfunction can be seen (Table 5.1). The internal malfunction ad1_fail directly violates
the functional requirement of the AD-converter. The component is defective and it
cannot perform as specified anymore. Hence, a functional deviation can be stated. Since
the output malfunctions ad1_out_fail also considers input malfunctions, and hence
describes the global correctness of the output port, the functional description needs torefer to the correct input signal temp1_out_correct. In this case, the correct signal canbe determined, since the top level component does not suffer from input malfunction.
Hence, the output malfunction at the ADC indicates, that the value does not reflectcorrectly the environmental temperature with an accuracy of 1◦ C. Again, the second
converter is specified similarly.
The signals of the AD-converters are processed by an Overwrite component which
compares the results and sets the safe-state if the values differ. The override component is
not expected to fail in the lifetime of the device. This is a common assumption in voting
architectures to leave over a very small functionality to a component that is formallyverified and produced in a more robust way than the rest of the system or replaced ina regular manner during service intervals (Bozzano & Villafiorita, 2011). The safetycontract therefore considers only input faults:
C31

A:
G:

none of {{ad1_out_fail, ad2_out_fail}} occurs.
{temp_out_fail AND !temp_out_safe} does not occur.

A:G:

none of {{ad1_out_fail}, {ad2_out_fail}} occurs.
{temp_out_fail} does not occur.

and:
C32

the functional contract for the Override component is given as:
A:
C33 G:-50 ≤ env_temp ≤ 200(temp1_out = temp2_out) → temp_out = ((temp1_out · 51) −51) ∧ (temp1_out! = temp2_out) → temp_out = 200

These contracts provide us an additional definition of the out_fail malfunction asout =6 ad1_out_correct. Since the output port does belong in an identical manner to125

5 Evaluation

multiple components (they are connected using delegation connectors) it is not surprising,that multiple definitions exist. Nevertheless, these are equivalent!

out 6= ad1_out_correct⇔out = ¬ad1_out_correct⇔out = ad1_out_f ail⇔ out = (ad1_out ≤ env_temp − 1) ∨ (ad1_out ≥ env_temp + 1)⇔

(out ≤ env_temp − 1) ∨ (out ≥ env_temp + 1)⇔

out_f ail

The Splitter component in the Logic component, the connection of the splitter tothe faults of the subcomponents as well as the contract for the splitter component are,again, generated automatically and do not need to be specified separately.
Refinement can now be checked on both levels of abstraction.
(C7 ⊗ C8 ⊗ C9 )  C6
as well as(C10 ⊗ C11 ⊗ C12 )  C9
For an exemplary performed refinement analysis refer to Section 6.2.

5.1.2 Changing the System
Similar to the design steps in the previous section, we assume a fictional but realistic
event that causes the design to change. While performing field tests with the build device,it has been observed, that the description of the failure modes of the AD-converters were
not complete. In case of a physical shock, both AD-converters may fail and the device
delivers constantly −50◦ C as the measured temperature. The device is not operating
inside its requirements, since it is vulnerable to a single fault. The design needs to be
updated with respect to the newly discovered malfunction and additional changes arenecessary to provide a safe system again. Hence, the additional malfunction needs tobe added to the component as a new safety port, and the safety requirement of the AD
converters is changed to reflect the new malfunction to:
A:
C34
G:
and for AD2:

126

none of {{ad1_fail},{temp1_out_fail},{phys_dem}}
occurs.
{ad1_out_fail} does not occur.

5.1 Example

TemperatureSensor
Logic

env_temp
TempSensor 1

AD1
ad1_out

temp1_out

ad1_out_fail

temp1_out_fail

ad1_out_drop

Override
out
out_fail

temp2_fail#logic_mf

ad1_fail
Splitterad2_fail

TempSensor 2AD2ad2_out

temp2_out

ad2_out_fail

temp2_out_fail

ad2_out_drop

dam_detSplitterdam_det_fail

temp1_failphys_dam#sensor_mf

out_safe

Plausibility
Check

env_temp

Figure 5.2 – A previously unknown common cause faults damaging both A/D converters
has been identified. To still maintain the safety properties a consistency checkhas been integrated.

A:
C35
G:

none of {{ad2_fail},{temp2_out_fail},{phys_dem}}
occurs.
{ad2_out_fail} does not occur.

These changes represent the initial set of changes. According to Table 3.6 the verification
activities depicted in Table 5.2 have to be re-run. The results of the activities are alsopresented in this table.
Surprisingly many verification activities are still successful. Although the specification
has been changed, which respects now the newly identified malfunction, it is still compliant
with the implementation. Since the fault injection analysis, which is used to determine
if the behavior under malfunctions is as specified, does rely on the completeness of theidentified malfunctions, the shock malfunction has not been tested. Still, the safety
manuals describing the failure modes of the components are typically expected to becomplete. Since the component and the specification have been modified (the malfunction
ports have been added to the component), the interface checks are all successful.

127

5 Evaluation

Verification Activity

Description

Vr (C24 , {C34 , C35 , C31 , C32 }) Refinement Analysis to verify if contracts of subcomponents correctly refine the specification of the logic component←−Vs (C34 , I (AD1))
Satisfaction analysis to check the compliance of the implementation of AD1
to its specification←−
Vs (C35 , I (AD2))
Satisfaction analysis to check the compliance of the implementation of AD2
to its specification
Vi (C34 , AD1)
Interface analysis to check complianceof ports and data-types between thesafety specification of AD1 and its interface represented by the component←−
Vi (AD1, I (AD1))
Interface analysis to check complianceof the interface of AD1, given by its
component, and the implementation of
AD1
Vi (C35 , AD2)
Interface analysis to check complianceof ports and data-types between thesafety specification of AD2 and its interface represented by the component←−
Interface analysis to check compliance
Vi (AD2, I (AD2))of the interface of AD2, given by its
component, and the implementation of
AD2

Resultfailedsuccessful

successful

successful

successful

successful

successful

Table 5.2 – Verification Activities that have to be Re-Run after the initial change

The failed refinement analysis indicates that the requirement of the Logic component,
to be safe in case of one malfunction, is not fulfilled by the requirements assigned to thesubcomponents. This is not surprising, since a common cause failure (phys_dem) causes
both AD-converters to fail and the override is not able to detect the malfunction andoutputs a wrong value.
As the table for the identification of compensation candidates (Table 3.8) indicates,
we could change the contract of the logic component or change the design inside. Since
we want to limit the change propagation as much as possible, we will add an additional
component inside the Logic component to handle the additional malfunction. The
new Plausibility Check component detects the physical damage by monitoring thetemperature over time. The plausibility check is based on the assumption that a huge
drop of the temperature is not possible between two measurement intervals. Hence, both128

5.1 Example

sensors are monitored and a detection signal is sent to the override component, that asudden drop has been detected.
To be able to detect the sudden temperature drop by the plausibility check, themalfunctions on the AD-converters need to be made available separately by adding a
new safety port. That way it is possible to refer separately to the different malfunctions.
Note, the malfunctions are still bound to one functional signal, and all components that
use the functional signal are prone to all malfunctions associated to the signal. Still, thedetection of the malfunction may be handled by a distinct set of components. The newsafety contract for the AD-converters is:
C36

A:
G:

none of {{phys_dem}} occurs.
{ad1_out_drop} does not occur.

and for AD2:
C37

A:
G:

none of {{phys_dem}} occurs.
{ad2_out_drop} does not occur.

Contract C34 remains valid, since the physical damage of the device also causes awrong signal. But the signal malfunction ad1_out_drop is only caused by the physicaldamage internal malfunction. This malfunction indicates that the signal drops to −50◦ C
and keeps this value. The other malfunctions are of a random nature and may change its
value at all times. Hence, the behavior on the output are different.
The complete architecture that integrates the plausibility check is depicted in Figure5.2. The functional requirement for the plausibility check is given as:
A:
C38 G:(−50 ≤ ad1_out ≤ 200) ∧ (−50 ≤ ad2_out ≤ 200)((ad1_out0 < 2)∧(ad2_out0 < 2)∧(ad1_out0 == ad2_out0 )) →(phys_det == 1)

It checks if the temperature drops faster than physically possible. The safety contract
is given as:
A:
C39
G:

none of {{ad1_out_fail AND !ad1_out_drop,
ad2_out_fail AND !ad2_out_drop}} occurs.
{dem_det_fail} does not occur.

The safety contract states when the detection signal might be wrong. The detection of
the physical damage is only incorrect if there is a malfunction in the ADC, either on its
inputs or internally, that on both channels the temperature is dropping fast at the samerate but no physical damage has happened. The gradient check is only correctly working
if we assume that the operating temperature of the device is higher than −48◦ C, sinceotherwise the drop would be in the physically possible gradient range.

129

5 Evaluation

Also the override component needs to be modified. The additional ports need to be
added and the functional as well as the safety contract needs to be updated:
A:
C40
G:

none of {{ad1_out_fail, ad2_out_fail},{ad1_out_drop,
ad2_out_drop, dem_det_fail}} occurs.
{temp_out_fail AND !temp_out_warn} does not occur.

It can be observed, that the cut-set of {ad1_out_drop, ad2_out_drop} alone does
not lead to a violation of the guarantee. This is crucial, since ad1_out_drop and
ad2_out_drop would be caused by one single malfunction, the physical damage. Only ifthere is also a problem with the detection signal can all three malfunctions together leadto a wrong output of the temperature sensor that is not safe. In contrast to that, thecorrect behavior is influenced by all the single malfunctions, hence:
A:
C41
G:

none of {{ad1_out_fail}, {ad2_out_fail},{dam_det_fail},{ad1_out_drop},{ad2_out_drop}} occurs.
{temp_out_fail} does not occur.

Also the functional contract of the override component needs to be adapted withrespect to the new detection port:

C42

A:
G:

TRUE
(((ad1_out == ad2_out) ∧ dem_det == 0) → (out ==ad1_out))∧(((ad1_out! = ad2_out)∨dem_det == 1) → out =200)

Now, a couple of verification activities need to be executed. These activities and theirresults are displayed in Table 5.3.
Verification Activity

Description

Vr (C24 , {C34 , C35 , C36 , C37 ,C40 , C41 C39 })Refinement analysis to verify if contracts successfulof subcomponents correctly refine the specification of the logic component←−Vs (C36 , I (AD1))←−
Vs (C37 , I (AD2))

130

ResultSatisfaction analysis to check the compli- successful
ance of the implementation of AD1 to its
newly added specification
Satisfaction analysis to check the compli- successful
ance of the implementation of AD2 to its
newly added specification

5.1 Example

Verification Activity

Description

Vi (C36 , AD1)

Interface analysis to check compliance of successful
ports and data-types between the safety
specification of AD1 and its interface represented by the component←−
Vi (AD1, I (AD1))

Vi (C37 , AD2)←−
Vi (AD2, I (AD2))

ResultInterface analysis to check compliance of successful
the interface of AD1, given by its component, and the implementation of AD1
Interface analysis to check compliance of successful
ports and data-types between the safety
specification of AD2 and its interface represented by the component
Interface analysis to check compliance of successful
the interface of AD2, given by its component, and the implementation of AD2

Vi (C40 , Override)

Interface analysis to check compliance ofports and data-types between the safety
specification of Override and its interface
represented by the component

successful

Vi (C41 , Override)

Interface analysis to check compliance ofports and data-types between the safety
specification of Override and its interface
represented by the component

successful

Interface analysis to check compliance of
the interface of Override, given by its
component, and the implementation ofOverride

successful←−
Vi (Override, I (Override))

Vi (C39 , PlausibilityCheck) Interface analysis to check compliance of successful
ports and data-types between the safety
specification of the PlausibilityCheckand its interface represented by the component←−
Vi ( I (PlausibilityCheck), Interface analysis to check compliance successful
PlausibilityCheck)of the interface of PlausibilityCheck,given by its component, and the implementation of PlausibilityCheck
Table 5.3 – Verification Activities that have to be Re-Run after the second change

Since all verification activities are successful, the change is contained in the logic131

5 Evaluation

component, that is, there are no other effects of this change outside this component
and all other stated requirements are still valid. In this example the savings are rather
small, since only the temperature sensors do not need to be re-verified. But in systems
where the ratio of the changes system parts to the not changes system parts is small, thesavings grow rapidly. To measure this effect in a quantitative way, a simulation of theapproach has been developed, results of which are described in Section 5.2.
Nevertheless, none of the satisfaction analyses have been considered in detail yet.
Exemplary for the other components we are going to analyze if the Override component
correctly implements its specifications.
The implementation of the Override component is depicted in Figure 5.3 in MATLABStateflow syntax. It consists of two states override-active and override-inactive.
In the inactive state, both input signals match and no physical damage has been detectedby the plausibility check. Hence, the identical value of the AD-converters is put on the
output. If there is either a deviation in the signal of the AD-converters or the fault
detection signal of the plausibility check is active, then the override component switches
to the active state and the value 200 is returned.
Also the implementations of the input malfunctions are depicted in the figure. These
implementations have the correct value as an input (e.g., ad1_out_correct) and may
enable a malfunction to deviate from this signal. The override component is operatingon the output of the additionally generated components that enable the processing of
input malfunctions.
Two safety contracts (C40 , C41 ) are assigned to the Override component and shallbe checked against the implementation individually. Contract C40 requests the signal
to be safe or correct in case of one malfunction in the system or its inputs. Hence, thefunctional representation of the guarantee of the safety contract is:
rf 1 = “out = ad1_correct ∨ out = 20000
Looking at the implementation of the input malfunctions in Figure 5.3, the usage of
ad1_correct is possible in the requirement, since this is the name of the input signal
before the deviation is performed.
Running the fault injection analysis, we obtain the following results:←−
MBSA(rf 1 , I (Override),{ad1_out_fail, ad2_out_fail, ad1_out_drop, ad2_out_drop, dem_det_fail})= {{ad1_out_f ail, ad2_out_f ail},{ad1_out_drop, ad2_out_drop, dem_det_f ail}}
The resulting cut-sets are identical to the assumption of contract C42 , the implementation is compliant with the contract.
Similarly, we analyze the second safety contract C41 . The functional representation of
the guaranteed out_fail that shall not occur is:132

5.1 Example

rf 2 = “out = ad1_correct00
The cut-sets are again identical.
←−
MBSA(rf 1 , I (Override),{ad1_out_fail, ad2_out_fail, ad1_out_drop, ad2_out_drop, dem_det_fail})= {{ad1_out_f ail}, {ad2_out_f ail}, {dam_det_f ail},{ad1_out_drop}, {ad2_out_drop}}
Hence, the compliance of the implementation to the stated safety contracts has beenshown.

133

5 Evaluation

AD1_OUT_FAIL[ad1_out_fail == 1]

AD1-Correct
Entry: ad1_out =ad1_out_correct;

AD1-Fail
Entry: ad1_out =ml('randi([-50,200],1,1)');

AD1_OUT_DROP[ad1_out_drop == 1]

AD1-Correct
Entry: ad1_out =ad1_out_correct;

AD1-Drop
Entry: ad1_out = -50;

[ad1_out_fail == 0][ad1_out_drop == 0]

AD2_OUT_FAIL

AD2_OUT_DROP[ad2_out_fail == 1]

AD1-Correct
Entry: ad2_out =ad2_out_correct;

AD1-Fail
Entry: ad2_out =ml('randi([-50,200],1,1)');[ad2_out_fail == 0][ad2_out_drop == 1]

AD1-Correct
Entry: ad2_out =ad2_out_correct;[ad2_out_drop == 0]

DEM_DET_FAIL[dem_det_fail == 1]

DEM-DET-Correct
Entry: dem_det =dem_det_correct;

DEM-DET-Fail
Entry: dem_det =ml('randi([-50,200],1,1)');

AD1-Drop
Entry: ad2_out = -50;

OVERRIDE[(ad1_out != ad2_out) OR dem_det==1)]

AD1-NORMAL

AD1-SAFE

Entry: out = ad1_out;

Entry: out = 200;

[dem_det_fail == 0][(ad1_out == ad2_out) AND dem_det==0]

Figure 5.3 – Matlab Stateflow implementation of the OVERRIDE Component (bottom
right). To represent the injected input faults additional components havebeen introduced that handle the injection of faults at the input. The input
malfunctions are activated by the corresponding malfunction ports.

134

5.2 Simulative Evaluation

5.2 Simulative Evaluation
While the example gave an overview of the capabilities of the developed safety specificationand how it is used in a top down development process, it was not able to give an estimateof how much effort can be saved while using a contract-based change impact analysis
compared to the currently used “re-verify all” approach. Hence, in this section we areinvestigating the effectiveness of the presented modular verification approach by meansof simulation. We compare both approaches across generated systems. We are aware of
the situation, that “everything” can under some circumstances be limited to a subsystem
or module that is sufficiently independent from the rest of the system. In that sense thegenerated system refers to these modules. Furthermore, we want to evaluate how theaccuracy of tests and analyses, and therefore also the needed degree of formalism affects
the effectiveness of both approaches. We simulate multiple change and system sizes tofurther narrow down the situations in which either approach performs optimally.

5.2.1 Simulative Setup for Comparison
The system design guidelines of the presented specification approach (see Section 4.4)
assume a view consisting of requirements that are linked to components. These components may have an attached implementation which satisfy the requirements (an example
is depicted in Figure 5.4a). In a contract-based design scenario these components areconnected via ports and the requirements specify the behavior of a component in a
black-box manner based on the existing ports. While measuring the performance of both
impact analysis techniques, we focus on the refinement and satisfaction analyses, since theinterface checks can easily be automated and consume no significant computational effort.
Hence, for the simulation we have chosen a graph based representation (see Figure 5.4b)of the system, that is limited to requirements and implementations. Still, all refinement
and satisfaction analyses are represented by the edges in the graph. As indicated by
Figure 3.17 the components are only connected to interface analyses and can therefore
be neglected in the simulation. In Figure 5.4b, requirements are linked to their refinedrequirements and also to the implementations that shall implement the requirement.
These links represent a verification or validation activity aiming at guaranteeing a correctrefinement or satisfaction relation. A refinement analysis is in this case represented by
the top level requirement and all directly refined ones.
In contrast, the current state of the art approach for handling changes in a module is
to let an engineer fix the system elements which are likely to be affected by the initialchange, and then run all tests and analyses again. If problems have been detected, theengineer will change the corresponding components. This procedure, will be iterated
until no further problems have been detected by the performed test and hence all V&V
tasks are successfully re-run.
Ideally, we would like to compare the effectiveness of the contract-based change
management process with the more standard change management process of complete
re-validation (within the considered module) on a large number of real-world architecturesin which changes have to be handled with an appropriate process. However, as we do not1355 Evaluation

Component

Component

satisfy
implements

Component

satisfysatisfy
implements

Req.

Req.

refinesrefines

Implement.

Req.
refinesrefines

Req.

Req.

implements

implements

Imp.

Imp.

Req.

Implement.

(a) Component View(b) Simulation View

Figure 5.4 – Requirements and implementations are attached to connected components 5.4aand the graph-based representation used in the simulation, where components
are neglected 5.4b

have access to a sufficiently large data base, we use generated architectures. Also, insteadof letting an engineer select which system elements need to be changed, if inconsistencies
are detected, we define all necessary changes in advance in the architecture which haveto be identified with either impact analysis process. Such random generation acts as aproxy to estimate the effectiveness on a real world architecture. A further need for thispre-selection of changes is to ensure that in both approaches the human engineer (whichis then replaced by the simulation) in both cases takes identical decisions which elementsof the architecture are changed when confronted with the same possible set of elements
to change. Therefore, to generate architectures and potential changes as realistic as
possible, we tried to incorporate experience from real case studies. We identified that arequirement is refined into one to six subrequirements where three and four are the mostfrequent cases. Hence, we generated the requirements structure based on the normal
distribution given in Figure 5.5.
Furthermore the implementations are generated based on the subrequirements of thesecond to last level R. The leave notes l(r) of the elements r ∈ R are distributed across 1
to |l(r)| implementations in a uniform distributed way.
Based on these numbers we generate architectures, depicted in Figure 5.6, which aresimilar to Figure 3.17, in which only the atomic requirements are implemented. In the
figure, the requirements and implementations that need to be changed are highlighted ingreen. The set of necessary changes is generated randomly.
We start the algorithms for both approaches on these systems. We assign a detection
accuracy in form of the probability Pacc to the performed refinement and satisfaction
analyses. The implementations of both approaches for the simulation are depicted1365.2 Simulative Evaluation

0.5

ϕµ,σ2 (BranchingV alue)

0.4

0.3

0.2

0.1

0.0

0

1

2

3
4
BranchingV alue

5

6

7

Figure 5.5 – Probability Density Diestribution for the Branching Factor of the generationof the Requirements structure. µ = 3, 5 and σ = 0, 8

in Algorithm 3 for the contract-based approach and in Algorithm 4 for the standard
approach. The simulation code varies only slightly from the presented impact analysis
process described in Section 3.3.4 as we assume that the engineer directly fixes theinconsistent requirements or implementations as soon as the analysis has detected the
problem. Although this is a rather optimistic assumption, this affects both approaches
in the same way, thereby not favoring any one algorithm in particular.
The recursive contract-based realization depicted in Algorithm 3 is based upon alist of already processed system elements Φ. The procedure CBA_SIM(G,n) is at the
beginning called with n as the initial change. It is the principle of the algorithm tocount the number of necessary analyses for each changed element, and then identify,
based on the test accuracy Pacc if the analyses detect the necessary changes. If a change
was detected the procedure is called again on the changed node(s). Note, that C, theset of necessary changes, is used to simulate the decision of the engineer, which would
normally select the components that need to be modified. All types of connected links
need to be processed separately. Therefore, lines 10 – 18 handle the refinement links
pointing from a requirement to a more concrete requirements, lines 20 – 28 handle therefinement links pointing to a more abstract requirement down to n (also pointing to thesiblings of n). One refinement link is meant here as a link from one requirement to one
or multiple refining ones. In lines 30 – 38 all satisfy links are counted individually. Since
we are assuming that the change we made to a component is already correct at the firstmodification, we do not modify an element twice; this exit is handled in lines 4 – 8.
The state of the art approach is depicted in Algorithm 4.
At first, all system elements from the necessary change will be detected with probability
Peng . This probability corresponds to the skill of the engineer in expecting changes
correctly and correcting them. In this phase (lines 4 – 9) no analyses are performed.

137

5 Evaluationi0_r_0_2

r_0_2_1_1

r_0_2_1_0

r_0_2_0_0
r_0_1_0_2
r_0_1_0_1

r_0_2_1_3

r_0_0_1_3

i1_r_0_0
i0_r_0_0
r_0_0_1_1

r_0_0_2_1
r_0_2_3_0
r_0_2_3_2

r_0_0_2_2

r_0_0_0_2

r_0_2_3_1

r_0_2_0_2

r_0_2_2_0

r_0_1_1

r_1_3_1_0

r_1_3_0_1

r_1_3_0_0

i0_r_1_3
r_1_3_1_1

r_1
r

r_1_2_0_2

r_1_2_0_0

r_1_2_1_2
r_1_2_1_1

r_1_2_0_1

r_1_2_3_2

r_1_0_1

r_1_2_4
r_1_2_2

r_1_1_0

r_1_1_3

r_2_2

r_2_0

r_1_2_3_1

r_1_1_2

r_1_2_1_3

i0_r_1_2

r_1_2_4_0

r_1_2_4_3

r_1_2_1_0

r_1_2_4_1

r_1_2_2_1

r_1_2_2_0
r_1_2_2_2
r_1_0_1_1

r_1_2_4_2

r_1_0_1_0

r_1_0_0_0

r_2_2_1_1

r_2_0_3_2

r_1_0_0_3

r_1_0_0_1

r_2_0_2_2

i1_r_2_2i0_r_1_0

r_1_0_0_2

r_2_2_0_0

r_2_2_0_2

r_2_2_0_1

r_2_2_0_3

r_2_0_2_0

r_2_0_2_3

r_2_0_0_1

i0_r_2_0

r_2_0_0_2

i0_r_1_1

r_2_0_2_1

r_2_2_2_0

r_2_0_0_3

r_2_0_0_0

r_2_0_3_3

r_2_2_2_2

r_1_1_1_0

r_1_1_2_0

r_1_1_0_0
r_1_1_2_2

r_2_1_2_3

r_2_0_0_4

r_2_0_1_2

r_2_2_1_2

r_2_0_3_0

r_2_2_1_0

r_2_2_2_1

r_1_1_1_1

r_1_1_0_1

r_1_0_1_2

r_1_1_1_2

r_2_1_3_1

r_2_1_2_0

r_2_1_2_2

r_2_1_2_4

r_2_0_4_2

r_2_0_3_1

r_2_0_1_0

r_2_2_0

r_1_1_3_0

r_1_1_2_1
r_1_1_3_2
r_1_1_3_1

r_2_2_2

r_2_0_2

r_2_0_1_1

r_2_0_4_0
r_2_0_4_1
r_2_1_3_2

i0_r_2_1

r_2_1_2_1

r_2_1_3_0

r_2_2_1

r_1_0_0

r_1_1_1

r_2_0_1

r_2_0_3

r_2_0_0

r_2_1_0_0

r_2_1_3_3

r_2_1_2

r_2_0_4
r_2_1_3

r_2_1_1_2

r_3_1_1_0

r_2_1_0_1

r_2_1

r_2

r_1_0

r_1_2_1

r_1_2_3_0

r_1_2_0

r_1_1

r_1_2

r_1_2_3

r_1_3

r_0_3_2

r_3_1

r_2_1_0_2

r_2_1_1

r_2_1_0i0_r_3_1

r_3_1_1_1

r_3_1_1_2

r_2_1_1_0

r_2_1_1_1

r_1_3_1_2

r_1_3_0_2

r_1_3_1

r_1_3_0

r_0_0

r_0

r_3
r_3_2

r_3_0

r_3_2_1

r_3_2_0

r_3_1_0_1

r_3_1_1_3

r_3_1_1

r_0_3

r_0_2

r_0_0_0

r_0_0_0_0

r_0_0_2_0

r_1_3_1_3

r_0_0_0_3

r_0_0_2

r_0_2_3

r_0_1

r_0_3_1

r_0_3_0

r_0_3_2_0

r_3_1_0i5_r_3_0

r_3_0_0_4

r_3_1_0_2

r_3_1_0_0

r_3_2_0_1

r_3_0_0

r_0_3_2_1

r_0_3_3

r_0_1_3

r_0_2_2

r_0_0_1_2

i2_r_0_0

r_0_0_1_0

r_0_0_0_1

r_0_0_1
r_0_2_1

r_0_1_2

r_0_2_0

r_0_1_0

r_0_3_0_0

r_0_3_0_2
r_3_0_2
r_0_3_1_4

r_3_0_0_1

r_3_2_1_0

r_3_2_0_2

r_3_0_1

r_0_3_0_1

r_3_2_1_1

r_3_0_0_2

i2_r_3_0

r_3_0_0_0

r_0_3_1_2

r_0_3_1_1

r_0_1_3_1

r_3_0_0_3

r_3_0_1_0

r_3_2_0_0

r_0_3_1_3

r_0_3_3_0

r_0_1_3_2

r_0_1_3_0

r_0_1_2_3

r_0_2_0_3

r_0_1_2_1

r_0_2_2_1

r_0_2_1_2

r_0_2_3_3
r_0_2_0_1

r_0_1_2_2

r_0_3_3_2

r_0_3_1_0

i0_r_3_2

r_3_0_2_0

r_0_3_3_1
i0_r_0_3

r_3_0_1_1

r_3_0_1_3

r_0_1_2_0

r_0_1_1_0

r_3_0_1_2

r_3_0_2_2

r_3_0_2_1

r_0_1_1_3

r_0_1_1_4

r_0_1_1_2

r_0_1_0_3
r_0_1_0_0

i0_r_0_1

r_0_1_1_5

r_0_1_1_1

i0_r_3_0i3_r_3_0
i1_r_3_0i4_r_3_0i0_r_2_2

Figure 5.6 – A generated architecture with 231 requirements (blue), 22 implementation (red). Thirteen elements have been selected
to be changed (green) which is about 3% of the whole architecture. The initial change is marked with a diamondshape. The simulation results depicted in Figure 5.8 are based on this architecture.

138

5.2 Simulative Evaluation

Algorithm 3 Contract-based realization for the simulation
Require: C: set of nodes n in the necessary change
1: Φ = ∅2: numAna = 0
3: procedure cba_sim(G,n)
4:
if n ∈ Φ then5:
return
6:
else
7:
Φ=Φ∪n
8:
end if
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:

∆ = p∈G.nodes() : isRefineDown(n, p) ∧ (n, p) ∈ G.edges()if ∆ 6= ∅ thennumAna++if ∃δ ∈ ∆ : δ ∈ C thenif random() ≤ Pacc then
cba_sim(G,δ)
end ifend ifend if
S

19:
20:
21:
22:
23:
24:
25:
26:
27:
28:

Υ = p∈G.nodes() : isRefineUp(p, n) ∧ (p, n) ∈ G.edges()if Υ 6= ∅ thennumAna++if ∃υ ∈ Υ : υ ∈ C thenif random() ≤ Pacc then
cba_sim(G,υ)
end ifend ifend if
S

29:
30:
31:
32:
33:
34:
35:
36:
37:
38:

Σ = p∈G.nodes() : isSatisfy(p, n) ∧ (p, n) ∈ G.edges()for σ ∈ Σ do
numAna++if ∃σ ∈ C thenif random() ≤ Pacc then
cba_sim(G,σ)
end ifend ifend forS

39:
40: end procedure139

5 Evaluation

Algorithm 4 State-of-the-art approach in simulation
Require: C: set of necessary changes
1: Φ = ∅2: numAna = 0
3: procedure sota_sim(G,i)
4:for n ∈ C do
5:
if random() ≤ Peng then
6:
Φ=Φ∪n
7:
end if
8:
end for9:

repeatΦinit = Φ12:
for e ∈ G.edges() do
13:
if isDeriveUp(e) || isDeriveDown(e) then
14:
numAna ++15:
E = getParallelEdges(e)16:if ∃(n1 , n2 ) ∈ E : n1 ∈ C\Φ ∨ n2 ∈ C\Φ then17:
if random() ≤ Pacc then
18:
Φ=Φ∪E
19:
end if20:
end if21:
end if22:
if isSatisfy(e) then
23:
numAna ++24:
if ∃e = (n1 , n2 ) : n1 ∈ C\Φ ∨ n2 ∈ C\Φ then25:
if random() ≤ Pacc then
26:
Φ=Φ∪e
27:
end if28:
end if29:
end if
30:
end for31:
until Φinit == Φ
32: end procedure
10:
11:

140

5.2 Simulative Evaluation

Then, all edges in the system graph are inspected and the analyses are counted. This
corresponds to the execution of all analyses and tests. Again, the set of necessary changes
C identifies the system elements that need to be detected by the verification or validation
activity using probability Pacc . For refineUp and refineDown edges all parallel edged,
belonging to the same refinement analysis are processed together (lines 13 – 21). The
satisfy links are counted each (lines 22 – 29). If changes have been identified during theanalysis of all edges of the system, the whole system is analyzed again (line 31).
The running time of both algorithms has an upper bound of O(|G.nodes()|), thenumber of node, i.e. the number of requirements in the system. For Algorithm 3 thisbound can easily be identified, since the set Φ ensures that the algorithm is called oneach node only once. For Algorithm 4 this is less obvious. The running time depends onthe detection probabilities Peng and Pacc . If Peng = 1 the running time is only bound by
the size of C. Small values for Peng do not influence the running time significantly as
long as Pacc > 0 holds. In that case the worst case probability for each run of the loop toterminate is |C| · (1 − Pacc )2 . Although this probability is decreasing with each run ofthe loop this value is constant in the size of the number of requirements. Hence, the sizeof the loop determine the upper bound, resulting in SOTA_SIM(G,i) = O(G.nodes()).
The loop probability directly infers that the algorithm does not terminate for Pacc = 0.
Hence, Pacc is simulated between 1% and 96%. Still, the simulation running time is not
the important value that needs to be evaluated. The simulation target is to identify how
many changes in C get identified with varying test accuracy Pacc .
To be able to compare both algorithms detection rate in relation to the individual
accuracy of the refinement analyzes, we need a notion of effort. The effort to re-verify asystem stems from the amount of verification activities as well as the used accuracy. A
less accurate test (i.e., a test with a low detection probability Pacc ) should have lower
associated effort compared with a test with high accuracy. To account for such effects,
we associate to a test having a probability of detection Pacc and which was performed ntimes the following effort:

E(n, Pacc ) = − log(1 − Pacc ) · n(5.1)

Instead of testing a V&V task with a test of probability p, we could alternatively test
this task k times with a test with probability 1 − (1 − p)k . Having this equivalence in
mind, directly motivates the definition of effort above (by taking the log of the probabilityof the equivalent test). Therefore, the y-axis in Figure 5.7 can also be seen as the average
number of re-runs of a test with 0.5 probability of detection to achieve the same accuracy.
To reach detection rates near 100% a tremendous amount of test-effort has to be
spent, while reaching 100% is impossible. This is even true for a formal setting, since
specification errors, that is, errors in the model checking engine or wrong application ofthese methods can never be excluded. It needs to be said that the formalization effort isalready included in this approximation. Formal analyses are more accurate but more
effort needs to be invested, including the formalization. Similarly a manually performed
test could gain a high accuracy if it is performed by many different tests independently.

141

Effort

5 Evaluation

Accuracy of a test Pacc

Figure 5.7 – Effort as a function of the accuracy of the test used. The higher the accuracy,
the higher the associated effort according to equation (5.1)

This approximation of effort is still pessimistic, since in practice the effort for a formal
solution is bounded.

5.2.2 Evaluation Results
Using the generation of architectures and the set of necessary changes we compared theeffectiveness of the contract-based approach with the state of the art approach.
Figure 5.8 depicts the results of the simulation of a system depicted in Figure 5.6 with
231 requirements and 22 implementation components. The size of the necessary change,that needs to be performed to reach a consistent state again, is 13. Each dot represents theaverage results across simulations with 1000 samples for a given probability of detection
set for each test which corresponds to a V& V task. The considered probabilities areevenly spaced in steps of 5 between 1 and 96%. The functions plotted in Figure 5.8 show
the increasing effort to detect more percent of the necessary changes when increasing theaccuracy of the tests used for both change processes, contract-based and state-of-the-art.
As the dots in the upper panel only show the average performance of a setting, weplotted the variability within a setting in the lower panel represented by the corresponding
standard deviation.
It can be observed that the contract-based approach reaches an acceptable detection
rate near 100% much earlier than the state of the art approach. Nevertheless, the needed
accuracy of the single verification and validation activities needs to be very high (thehighest accuracy is 0.95 in this figure). The state of the art approach needs much lessaccuracy to reach a similar detection rate, but since more analyses are executed theoverall effort is bigger. In addition to the component based approach and the state of theart approach, the green values represent the execution of all V&V cases in the systemonce with the given accuracy, to get a better understanding of magnitude of the effort.
Furthermore, it can be observed that the distribution of the samples around themean-value decreases in both cases for higher test accuracy. As expected, the deviation1425.2 Simulative Evaluation
Pacc from 1% - 96%

Detection rate (in %)

120
100
80
60
40

Contract Based Approach
State of the Art
All Tests executed 1x

20
0
20
500

0

500

1000
Verification Effort

2000

2500

Standard Deviation120
Detection rate (in %)

1500

100
80
60
40
20
0

0

200

400

600

800
1000
Verification Effort

1200

1400

1600

Figure 5.8 – Results of system consisting 231 requirements and 22 implementations, whilechanging 13 elements of the system. The sample-size is 1000

is bigger using the contract-based approach compared with the identical test accuracy ofthe standard approach. This is caused by analyses that do not detect problems in thesystem caused by previous changes. In that case the propagation stops at this branch andthe system is not further investigated. This does not happen, for the standard approach,where the analyses will be executed regardless of the position in the system.
Interestingly, after approximately 60% analysis accuracy the standard approach only
deviates in the effort spent, reaching nearly 100% detection rate. To some extent thiswas expected, but the extraordinarily good results are mainly caused by the assumed
independence between two consecutive runs of the same analysis and hence increasing
the accuracy exponentially. In practice, it is unlikely that a problem that has not been
detected the first time will be detected by running the exact test again. Still, this might
not hold for activities like reviews, tests with random inputs or tests executed by different
persons. Nevertheless, this independence favors the state of the art approach as every
violation of this independence assumption will decrease the performance.
Figure 5.8 displays the results for one change size only. We have run the simulation

143

80

0.70

70

0.50

60

0.30

50

0.10

40

0.05

30

0.00

20

0.10

10

0.30

0

0

100

200

300

400

500

Difference in Detection Rate

Number of Changes

5 Evaluation

0.50

Verification Effort

Figure 5.9 – Difference of detection rates (in %) between the component based approachand the standard approachfor various change sizes and visualized the differences in detection rates for given effort.
The result is displayed in Figure 5.9.
It can be observed that the contract-based approach is creating a much higher detection
rate if there are only a few changes (below 41 absolute changes ≈ 16.2% of the systemsize) and the effort is very limited (below 300). As already indicated in Figure 5.8 both
approaches perform similarly if the available effort for the re-verification of the system
is increasing. After passing the border of 41 changes, the standard approach performs
better in all cases.
This is mainly caused by the iterative nature of the contract-based approach. The
algorithm analyzes the requirements and implementations in the direct neighborhood of
the changed element and aborts if no further change seem necessary (see e.g. lines 10 –18 in Algorithm 3 for RefineDown links). If this decision is wrong, what might happen
with a low test accuracy, the algorithm will abort too early and many necessary changes
are not detected. Hence, to gain a high detection rate, the individual test accuracy needs

144

5.2 Simulative Evaluation

to be also very high (see Figure 5.8). The simulation revealed, that the resulting effort
grows faster than the size of the system, and hence allowing the standard approach to be
more efficient for large changes.
In addition to these results the simulation provided evidence that the effort for acontract-based approach scales linearly with the size of the change. Figure 5.10 displays
the effort needed by both approaches to reach a detection rate of 98%. Also the break-evenpoint at approximately 40 changes is clearly visible.
2000

Verification Effort

1500

1000

500

0
0

20

40

60

80
100
120
Number of Changes

140

160

180

Figure 5.10 – Effort of both approaches at detecting rate 98% (300 Samples). The contractbased approach is displayed in blue, while the state-of-the-art approach is
depicted in green.

The figure looks similar for all other detection rates. It can be observed that the effort
for the standard approach stays constant, while the effort of the contract-based approachincreases linearly.
We evaluated the break even point also for systems of different sizes (see Figure 5.11). It
can be observed that the break even point is not influenced by the size of the system. All
simulated system sizes (71, 240, 771 and 1600 elements) indicate that the contract-based
approach is beneficial until a relative change size of the system of 15% to 16% has beenreached.
The break even analysis gives also evidence of how much costs could be saved by thecontract-based approach. For small changes, that are below 7% of the total system size
over 50% of the verification costs could be saves. For changes below 5% of the systemsize the saving is even more than 75%.

145

5 Evaluation

0.70

25

0.30
0.10

20

0.05
15
0.00
10
0.10
5

500
Verification Effort

0.50
Deviation in Detection Rate

Number of Changes

600
30

50

100
150
Verification Effort

200

300

200

100

0.30

0
0

400

0
0

0.50

(a) #R=61, #I=10

10

20
30
40
50
Change size in % of Total System Size

60(b) Break even at 16%

Number of Changes

0.30
0.10

150

0.05
100

0.00

1500
Verification Effort

0.50
200

Difference in Detection Rate

0.70

1000

500

0.10
50
0.30
0
0

200

400

600
800 1000
Verification Effort

1200

1400

0
0

0.50

(c) #R=648, #I=87

5
10
15
Change size in % of Total System Size

20(d) Break even at 15%
0.70

Number of Changes

400

0.30
0.10

300
0.05
200

0.00
0.10

1500

Verification Effort

0.50

Difference in Detection Rate

500

1000

500

100
0.30
0
0

500

1000
Verification Effort

1500(e) #R=1414, #I=229

0.50

0
0

5

10
15
Change size in % of Total System Size

20(f) Break even at 16% (70% detection rate)

Figure 5.11 – Comparison of the results for systems of different magnitude. The identified
relative break even point is independent of the absolute system size. The
plots for the break even points are scaled to the relative system size in %.

146

5.3 Conclusion

5.3 Conclusion
We have investigated the benefits and limitations of a localized change impact analysis
process compared with a more standard process of complete re-verification of all elements
within the systems design.
While we find the localized approach to be more effective for small proportion ofnecessary changes (compared with the system size) such localized approach performs
less well in situations in which larger parts of the system need to be changed. Within
the scope of our applied system parameters we discovered a border of ≈15% changesof the whole system, after which the standard approach is more efficient in terms ofverification effort spend. This stems from the fact that the contract-based approachaborts the analysis process if one refinement analysis is successful. If this happens at
one of the first analyzes, only a faction of the system gets analyzed and multiple changes
have not been considered. For large changes, the individual accuracy of each refinement
analysis needs to be extremely high, in order to be sure to detect the changes correctly,
resulting in an extreme effort for huge systems if the detection rate shall remain identical.
Still, the abortion of the process if one refinement analysis is successful is not always
necessary. In the example presented in section 5.1, we perform multiple changes at atime and the re-verify in one chunk. If skilled engineers perform changes to a system
this is a valid and effort-saving approach. Hence, the discovered border of 15% can beconsidered as a save worst case estimate. Looking at the possible savings in effort we cangive evidence that for small changes, that are below 7% of the total system size, over
50% of the verification costs could be saved. For changes below 5% of the system size
the savings is even more than 75%.
The simulation results also indicate that the use of formalized requirements andautomated verification activities is highly recommended within the contract-based change
management approach, since a high test-accuracy is necessary in order to obtain useful
results. Yet, the standard approach does not benefit from the use of a high test accuracy.
The detection rates are nearly identical with a test accuracy ≥ 60%. Only the overall
effort increases, therefore the additional effort in formalizing requirements and performing
computationally intensive analyses is not well spent.
However, it is worth noting that our simulation setup favors the process for complete revalidation since we assumed the tests and analyses results to be independent between two
consecutive runs of the same test. Also, we assumed the same accuracy of implementation
tests, as well as the entailment analyses.

147

CHAPTER

Prototype Implementations
In this chapter we are going to present briefly the different prototypes that have beendeveloped for this thesis. The main purpose of this chapter is to demonstrate how thechange impact analysis can be integrated in a distributed development environment.
Multiple tools have been developed for this. Even though the simulation frameworkused in Section 5.2 has a huge code base, we will focus on the user oriented software
only. Hence, two tools and a tool setup are presented. In Section 6.1 we describe how animpact analysis service can be integrated in a distributed working environment using
various development tools and formats like AUTOSAR, EAST-ADL, Simulink, IBM
DOORS or MS Excel. In this prototype we implemented to process of verification activity
invalidation as well as their re-run and a graphical system representation that allows toview the current change request and its status. In Section 6.2 we present the refinement
analysis for formalized safety contracts. Finally, we give a short overview in section 6.3
of how to perform the satisfaction analysis of safety contracts using a fault injection tool.

6.1 A Change Impact Analysis Service for Distributed
Development Environments
The Reference Technology Platform (RTP) is a tool interaction platform based on the
OSLC communication principle (“OSLC: Open Services for Lifecycle Collaboration,”2012), that connects various development tools via HTTP connected services that sharea basic common meta-model, which can be seamlessly extended by the users. The first
prototype of the RTP was built in the European integration project CESAR (Rajan& Wahl, 2013). Having access to all distributed development artifacts over a single
interface makes it possible to develop a central impact analysis service that highlights
the affected verification activities by a change and supports the developers by displaying
the compensation candidates.

149

6

6 Prototype Implementations

Model Service:

Model Service:

MATLAB/Stateflow

EAST-ADL

Implementations

Components

Model Service:
V&V Repository

Model Service:
Components

V&V Activities

OSLC

AUTOSAR

Requirements
Requirements

Link Service:
Links
Link Repository

Requirements
Service:Requirements
Service:
IBM DOORSMS ExcelFigure 6.1 – Overview of the available services in the used RTP instance

6.1.1 RTP Setup
The services integrated in the used RTP instance are depicted in Figure 6.1. Components
are provided by an EAST-ADL and an AUTOSAR service, Requirements are provided by
IBM DOORS and MS Excel and implementations are provided by a MATLAB/Stateflow
service. This RTP instance features a dedicated link repository which stores the refine,satisfy and implementation links. This separate repository allows to perform queries
related to links at a central point in the system. The verification and validation activities
are represented by separate model entities and are served as an additional service. The
service for the V&V activities had to be newly developed since no process enactment
tool was connected to the RTP at the time of writing this thesis.
The simplified meta-model used in the RTP instance is depicted in Figure 6.2. In
addition to the already introduced tracelinks an Evaluate link is used to connect theverification activities to the tracelinks they shall verify. The verification activities
themselves can be of kind refine or satisfy and include a log, where the status of each run
is stored. Implementations and components are both represented as RichComponents
which is a concept that has been taken over from HRC (Enzmann et al., 2008). The part
relations of components are realized by a Type-Prototype concept as it is used in an
identical manner in AUTOSAR.
Since the OSLC configuration management specification1 is, at the time of writing
this thesis, still in a phase of frequent and extensive changes, we implemented a change1

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=oslc-ccm

150

6.1 Impact Analysis Service

Element

Requirement1..*<<enumeration>>
VVStatus

RichComponent

1

1

1

1

satisfies

type

1

0..*

RichComponent
Property1

refinedBy

VVCaserefinedReq
component

0..*suspect
success
failpendingerror
inconclusive0..*

Implementation
component
0..*
0..*

Satisfy

Implements

0..*
Refine1..* +type:VVTypeevaluatedByCase+kind:VVKind
0..*
Evaluatelog

VVLogEntry0..*+date:EString+status:VVStatus+output:EString
Tracelinkevaluates

1..*(a) General System Elements
Element
0..*

1

1

old

new

0..*
ChangeRequest+creationDate:
ETime

0..*
ReplaceElement

1

0..*

elements

0..*Baseline+vnumber:EInt(b) Impact Analysis Specific Model Elemenents

Figure 6.2 – Meta-Model used in the RTP instance151

6 Prototype Implementations
Points to Versions of Data Elements
Model Data
BackendElement X
Modification
Event

Model Service

V1
V2

Baselines

V3
Change Impact
ServiceOSLC
V&V Data
Backend

ChangeRequests

Element X
V&V Service
displays
Change Impact
ClientV1
V2

Invalidates Verification Activity Representation
V3

Figure 6.3 – Overview of the available services in the used RTP instancehandling mechanisms based on change events especially for this scenario. Figure 6.3
depicts the basic mechanism. As a prerequisite, each data repository needs to be able
to version its elements. This is a typical requirement such as requested in ISO 10007(2003). These elements are also exposed over the service and referenced by a uniqueaddress. In addition we require also tracelinks to be versioned and pointing to versioned
elements. This is necessary since the semantics of a link may not be applied for a changed
element, at least not without an additional analysis. For example, a component covers a
special requirement, but after changing the requirement it has to be considered again
whether the attached component is still the best to implement this requirement. The
link is only valid for a special version of a requirement. Whenever an element is changedin the repository, the service sends a notification in the form of a change event to thechange impact service. The change causes a new version of the element to be created.
Furthermore, after the impact analysis service receives the change event, the connectedverification and validation activities are invalidated, by setting the appropriate status in
the V&V model elements. Baselines are also created by the change impact service. They
refer to the specific version of the included elements.

6.1.2 Algorithmic Changes for Distributed Development Environments
The change impact process presented in section 3.3 assumes that only one person is
performing a change to the system. Since the verification activities might run for a152

6.1 Impact Analysis Service
Algorithm 5 Contract-based approach
Require: Ψ = ∅1: procedure CBA(i)2:V = connected_VV(i)3:
setSuspect(V )
4:
Ψ=Ψ∪V
5:
while Ψ 6= ∅ do6:v ∈ Ψ, Ψ = Ψ\{v}
7:
if isSuspect(v) then8:run(v)
9:
if isFailed(v) then10:
Ψ = Ψ ∪ {v}
11:
end if12:
end if13:
if isFailed(v) then14:
T = targets(v)15:
for t ∈ T do
16:
if suitableForChange(t) then17:
modify(t)18:
V 2 = connected_VV(t)19:
setSuspect(V 2)20:
Ψ=Ψ∪V221:
end if
22:
end for23:
end if24:
end while
25: end proceduresignificant amount of time, it cannot be expected that the results are available immediately.
To prevent a wrong status of the verification activities between the start of the analysis
and the result, two additional stati suspect and processing have been introduced. A
suspect status is set as soon as a verification activity has been identified to be affectedby a change. If the analysis is finally running, the status is changed to processing. The
suspect status allows a slightly simpler algorithm to handle the verification activities (seeAlgorithm 5)
The process starts with a given initial change i. As the component that is changed islinked to several other components and requirements, various verification and validation
activities have to be addressed. In case the changed element is a requirement, theverification activities that have to be addressed are two entailment checks, one where
i is the top-level requirement, and the other, where i is a subrequirement. Also, atleast one satisfaction analysis to check if the implementation fulfills the requirements
has to be performed. All the previous results of these analyses and tests are not valid

153

6 Prototype Implementations

anymore since the requirement has been altered. The status of these verification andvalidation activities is therefore set to suspect, indicating that a re-run is necessary. If
the analysis fails, it is added to the list of V&V activities (Ψ) linked to components inwhich an additional change might be needed to guarantee an overall consistent state.
From the elements that are linked from the failed V&V activity (targets), the engineer
selects further system elements and modifies them. The modification, again, leads to theinvalidation of previous gained analysis results. The suspicious activities will be added
to the set of verification and validation activities Ψ, that still need to be processed. The
algorithm terminates if Ψ is empty. This indicates that all activities have been performed
again, with an successful result.
In contrast to the algorithms used for the simulation (see Section 5.2), where theexpected change was pre-calculated, this decision is given to the engineer in Algorithm
5. Hence, the algorithm might not terminate if two system elements are continuously
changed after another. Nevertheless, this behavior is not expected in practice. Since
the introduction of suspect flags does not alter the detection rate and test accuracy
identified in Chapter 5 the gained results still remains valid. However, the running timein a real world scenario highly depends upon the running time of the chosen verification
technology. The running time may vary between constant grows for manual review or
exponential grows for model checking based analyses.

6.1.3 Change Request Representation
The central point of user interaction with the change impact service is the change impact
client ReMain. ReMain displays the changes in the current change request to the user
and indicates which verification activities are affected. Furthermore, status lights behindthe verification activities show the status of the activity. Yellow for suspect verification
activities, green for successful ones and red for activities that failed. The components
and requirements displayed in the change request view are selected only to be visible
if they are either a potential compensation candidate of a failed verification activity(highlighted by a blue name), or have been so. The full architecture with all components,
requirements and implementations can be browsed in the left view of the client, where
all connected services are listed in a browsable fashion.

6.1.4 Using the Change Impact Service
If the impact analysis service is used while developing a system, each developer who is
working on the project is running an instance of the change management client. Startingfrom a specified baseline the changes made by all developers are visible in the client. In
fact, only the latest changes are visible, if an element is changed multiple times. Thisdecision is based on the need of the developers to identify the parts of the system thathave been changed in a simple way. Highlighting multiple version would have complicatedthe now simple interface with no additional benefit. Now, if an element has been changed
by a developer, all other developers are able to detect possible influences to elements154

6.2 Checking Safety Contracts with Divine

Figure 6.4 – Representation of the current change request in the change impact client
ReMainmaintained by them. The indicators allow judging if further changes might be necessaryor the change is already contained in the highlighted region.

6.2 Checking Safety Contracts with Divine
DIVINE (Barnat et al., 2013) is an explicit state LTL model checker that is used as
the backend for analyzing safety contracts. This thesis does not focus on providing thefastest possible analysis of LTL properties, hence performance was not a concern for
selecting a suitable checker. Divine has been chosen since it provides a simple integrated
language to describe systems by means of processes.
To analyze the refinement of contracts, the virtual integration condition of their
LTL formulas needs to evaluate to true. This satisfiability check on LTL formulas
can be transformed to a classical model checking problem as described by Rozier andVardi (Rozier & Vardi, 2007) as well as Li et al. (Li et al., 2014) using a generic model,
allowing all possible behavior, to check the property against.
Hence, the analysis prototype is performing three process steps:
1. Parse the input contracts
2. Generate LTL expressions for contracts
3. Generate the Random model155

6 Prototype Implementations

4. Generate the refinement condition(s)5. start the checker
We use a very simple example to still create formulas that are comprehensible without
tools. The component architecture is depicted in figure 6.5.
C
con
in

out
C1

con_failC2

in_fail

out_fail

c2_internal_failFigure 6.5 – Component architecture used as the example to illustrate the refinement
analysis process.

To be able to easily integrate the refinement analysis in various toolchains, the contracts
are provided by a simple text file. An example of a very simple input file is depicted in
Figure 6.6. The top level contract is marked with an additional “t” after the assumption
marker “A” and the guarantee marker “G.” The complete grammar for the syntax of thesafety contracts is listed in Figure 6.7.
/* This is the top-level contract */At: none of {{in_fail},{c2_internal_fail}} occurs.
Gt: {out_fail} does not occur.
// contract for C1
A: {in_fail} does not occur.
G: {con_fail} does not occur.
//Contract for C2
A: none of {{con_fail},{c2_internal_fail}} occurs.
G: {out_fail} does not occur.

Figure 6.6 – Simple example input file stating the top level contract and the subcontracts.

The random model, which is used to check the generated LTL property against, needs
to be able to perform any change of the used ports at any time. Hence, for each port a
process is created using the build in language DVE of DIVINE. An example process forthe input malfunction port in_fail is depicted in Figure 6.8.
The generation of the LTL property is based on the virtual integration condition on
formulas, as presented in Section 2.1.5.

156

6.2 Checking Safety Contracts with Divine

hassumptionTopi ::= ’At:’ , hsafetypatterni;
hpromiseTopi ::= ’Pt:’ , hsafetypatterni;
hassumptioni ::= ’A:’ , hsafetypatterni;
hpromisei ::= ’P:’ , hsafetypatterni;
hsafetypatterni ::= hp1 i | hp2 i | hp3 i | hp4 i;

hp1 i ::= ’none of’, hexprseti, ’occurs’, [’.’];
hp2 i ::= hexpri, ’does’, ’not’, ’occur’, [’.’];
hp3 i ::= hmodei, ’only’, ’followed’, ’by’, hmodei;
hp4 i ::= hmodei, ’only’, ’after’, hmodei;

hexprseti ::= ’{’, hexpri , {’,’, hexpri }, ’}’;
hexpri ::= ’{’, hmalfunctioni, {’,’, hmalfunctioni}, ’}’;

hmalfunctioni ::= handExpri | hsingleMalfunctioni | hmfCountPorti;
hnoti ::= ’!’;
hsingleMalfunctioni ::= [hnoti], ALPHA, {(ALPHA | ‘_’)};
handExpri ::= hsingleMalfunctioni, ‘and’ , hsingleMalfunctioni;
hmfCountPorti ::= hcountNamei, ’=’, hcountValuei;
hcountNamei ::= ALPHA, {(ALPHA | ‘_’)};
hcountValuei ::= NUM, {NUM};
Figure 6.7 – Grammar of the safety pattern

157

6 Prototype Implementations
process in_fail_switch {state in_fail0, in_fail1;
init in_fail0;
transin_fail0 -> in_fail1 {effect in_fail=1;},
in_fail1 -> in_fail0 {effect in_fail=0;},
in_fail0 -> in_fail0 {guard in_fail==0;},
in_fail1 -> in_fail1 {guard in_fail==1;};}
Figure 6.8 – One example process from the random model. The input ports (infail in thiscase) can be switched at any time.

Since safety contracts are not in canonical form, we use the parallel composition definedby Hugar:
!
^

Ai ∨

_

i

Ai ∧ G−1
i

i

 ^

,

!

Gi

i

A contract C = (A, G) is refining contract D = (B, H) given not in canonical form
iff B → A and C → D. Hence, the virtual integration condition for a top level contract
C = (A, G) and Ci subcontracts is:
"

A→

^
i

Ai ∨

_

Ai ∧ G−1
i



!#

"
^

∧

i

Ai ∨

i

_

Ai ∧ G−1
i



i

!

!

→

^

Gi

#

→ (A → G)iThis expression can be simplified to:!
^iAi ∧ G ∨_(Ai ∧ ¬Gi ) ∨ ¬Ai

For the example above the generated formula is:(((G(!(in_fail==1)))) && (((G(!(con_fail==1))) &&(G(!(c2_internal_fail==1))))) && ((G(!(out_fail==1))))) ||(((G(!(in_fail==1)))) && !((G(!(con_fail==1))))) ||((((G(!(con_fail==1))) && (G(!(c2_internal_fail==1))))) &&!((G(!(out_fail==1)))))|| !(((G(!(in_fail==1))) &&(G(!(c2_internal_fail==1)))))The output of DIVINE is that the property holds, that is, refinement is given. If we
modify the assumption of the top level contract that the malfunction c2_internal_failis not present, refinement is not given anymore and the model checker creates a counterexample, which is:158

6.3 Satisfaction Check of Safety Contracts

c2_internal_fail = 1, con_fail = 0, in_fail = 0, out_fail = 0
Hence, the occurrence of a single internal malfunction on C2 will cause the property to
fail. This counter example gives evidence that the architecture is not safe with respect tothe given assumptions and that additional measures are necessary to handle the internal
malfunction.

6.3 Satisfaction Check of Safety Contracts
To perform the satisfaction check on safety contracts we use a fault injection tool called
MBSA (Peikenkamp et al., 2006). We had not yet automated the process of creating allnecessary MBSA inputs from the safety specification, but perform these steps manually.
We use the MBSA prototype, which has been developed for the European project SAFE2 .
In that project the MBSA has been integrated in an eclipse platform which is capable tohandle EAST-ADL and AUTOSAR files. In this section we briefly introduce which steps
are necessary to run a satisfaction analysis and how to perform them.
The MBSA (Peikenkamp et al., 2006) performs fault injection in a model of thesystem’s nominal behavior. The correctness of this model can be checked with model
checking techniques against the functional requirements. The MBSA can be used toautomatically assess which combinations of malfunctions lead to the violation of a selectedfunctional requirement. The resulting cut-sets (of malfunctions) can be represented as afault-tree. A cut-set is said to be minimal if no event can be removed from the set andthe combination of malfunctions still leads to a failure (Kececioglu, 1991). The analysis
currently supports nominal behavioral models formalized in MATLAB/Stateflow3 while
requirements are provided in a formal language called RSL (Baumgart et al., 2011) toenable automatic processing.
We need the following prerequisites to perform the analysis:• EAST-ADL or AUTOSAR model to represent the component architecture• Safety contracts describing the fault propagation behavior, that shall be analyzed• MATLAB Stateflow implementation of the component that shall be analyzed• A set of malfunctions that shall be injected
First, the top level requirement needs to be stated. This requirement needs to be thefunctional representation of the safety contract that shall be analyzed. How to formulate
the functional representation is described in detail in section 4.5.2.
The functional part of the RSL (Mitschke et al., 2010) is used to describe the top level
event. Some frequently used patterns are:2
3

http://www.safe-project.eu/
http://www.mathworks.de/products/simulink/159

6 Prototype Implementations• always(CONDITION)
specification of an invariant condition for the system.
• Whenever EVENT1 occurs EVENT2 occurs during [INTERVAL].
After the occurence of EVENT1 an instance of EVENT2 needs to occur in thedefined interval.
• Whenever EVENT occurs CONDITION holds during [INTERVAL].
After the occurence of EVENT the condition has to hold at every time of thespecified interval.
An event is specified using a variable name and a value and is triggered as soon as the
specified value is assigned to the variable. Conditions can be stated in C-Syntax.
The top level requirement can be stored in one of the loaded models, for example, in a
SAFE-Extension to an AUTOSAR file. In the SAFE meta-model the description of themalfunctions is performed in a model element malfunction. These descriptions can beselected using the configuration interface of the MBSA (see Figure 6.9). Hence, not all
malfunctions need to be injected, but the analysis can also perform a partial injection
analysis. Next, the Simulink model needs to be selected. The model can be either locatedin the workspace of the eclipse platform or in the filesystem of the host.
Next, the malfunctions need to be configured for the implementation model. An
additional tool, the failure mode editor is used for this. In this tool (see Figure 6.10) for
each malfunction of the corresponding deviation in the implementation model can be
configured. To achieve this, there are two different possibilities: first a pre-defined fault
behavior from a library can be selected. This library defines the deviation of a variable in
the implementation model from its intended value. Currently supported deviations are:
Stuck-at: this pattern describes the case in which an internal variable of the systemmodel is stuck at an erroneous value.
Random: this pattern is used to describe cases in which random changes to the valueof an internal variable occur.
The second possibility is to use a user defined malfunction behavior. This approach isused in case the desired fault behavior cannot be modeled using the fault library. The
user defined mode allows the custom modeling of this fault behavior in the same languageof the implementation model. Accordingly, the fault is not injected later in the process inthe nominal model but it is embedded in the nominal model. Additional input variables
are then added to the model to control the activation of the injected fault.
As with the user define fault behavior the top level event (top level requirement) canbe specified directly inside the model. A state-flow block can be used as an observer todefine the behavior, and variables can be set that indicate, for example, the entry of afail state (see Figure 6.11). The functional requirement is then referencing this variable:
always(!F ailB rakef orce)
After configuring the malfunctions the analysis can be started. The current implementation supports two analysis engines as a backend. The first one is based on the VIS160

6.3 Satisfaction Check of Safety Contracts

Figure 6.9 – Configuration interface of the MBSA integrated in the SAFE tool platform

model checker 4 . The VIS based backend guarantees complete results since the full state
space is checked. The monte-carlo simulation based engine can be used to cope withmodels that are more challenging in terms of the state space size. In this case, however,the completeness is not guaranteed anymore. In the present work, we use the VIS basedengine.
At run-time, the Stateflow model is transformed into the input language of the model
checker. This nominal model is extended (injected) with the faults. Additionally, anobserver automaton for the analyzed requirement is generated and injected in the model
if an RSL expression is used in the functional requirement. The resulting overall model
is finally passed to the VIS model checker. The analysis identifies all state sequencesleading from the set of initial system states over the activation of faults to the observationof the violation of the functional requirement. These paths are the basis for computing
4

http://vlsi.colorado.edu/~vis/161

6 Prototype Implementations

Figure 6.10 – Configuration of malfunctions using the FailureModeEditor
FailureObserver1

OK[(env_brakepedal) && (!out_brakeforce) && (!env_slip)]/
Fail_Brakeforce = true;

Fail

Figure 6.11 – Observer to specify the top level funtional requirement directly in the Stateflow model

the set of minimal cut-sets leading to the failure.
The identified cut-sets are displayed in the MBSA integration interface.

162

CHAPTER

Conclusion
Certification costs consume a major part of the total development budget of safety
critical embedded systems. These costs consist to a great extent of the verification andvalidation activities, which guarantee the compliance of the system to its requirements andsafety standards. Systems are rarely developed from scratch, but are built upon existingproducts that are modified to various degrees. Hence, it is unfavorable that even in case ofsmall changes the safety case, that is, the argumentation why a system is sufficiently safe,
needs to be revised. In many cases the verification and validation activities need to be
re-executed for the whole system. This is mainly caused by the inability to determine thepossible side-effects of a change. This problem is caused by changes that might “propagate”
and cause undesirable behavior in even distinct components of the system. Current
impact analysis techniques are not suited to limiting the resulting re-verification effort
since the set of verification activities affected by a change cannot be determined precisely
enough. Furthermore, impact analyses developed for software cannot be transferred tological system descriptions, which are not yet implemented. In this thesis a new impact
analysis technique for functional safety concepts has been developed, which offer a linear
relation between the size of the change and the re-verification effort using a new concept
of detecting change propagation and a modular system safety specification.

7.1 Summary of Obtained Results
We evaluated the existing change impact analyses (see Section 3.1) that are suited forembedded systems and identified two main issues: First, the set of possibly affected
system elements is too large and no exact pruning strategy exists to select the actuallyaffected elements from the set of potentially affected ones. Second, if approaches limit
the set of possibly affected system elements in a probabilistic setting, mostly basedon experience from previously built systems, the confidence in the correctness of thisselection is not sufficient for qualification or certification purposes. Hence, a new impact

163

7

7 Conclusion

analysis technique based on contracts was developed (see Section 3.3.4). The approachhas the benefit of exactly determining if a component is affected by a change. This feature
is founded on the semantics of the specified requirements of the system, representing
one of the main differences from the other existing approaches that are either based on
traceability links or predefined dependencies. Even if these dependencies are extracted
from behavioral models such as source code, they focus only on selected properties such as
variable usage or call relations and represent therefore a sub-set of the intended behavior.
Furthermore, using the semantic relationship between requirements we provide a decision
support for the engineer. It is possible to identify whether a change can be compensatedby modifying a set of requirements rather than modifying an implementation. In addition,
to avoid costly implementation tasks we can guarantee that the changes in requirements
preserve the current status of the verification activities. Hence, no further re-verificationis needed (see Section 3.3.5). This decision support system is using the slack in system.
Since slack in automotive applications is not included intentionally, it is typically very
little. Hence, slack is identified in the complete system and a shift of it is calculated.
Since, many requirements in distinct parts of the system might be modified, this task isvery unlikely to be performed correctly by a human on a large scale system.
To enable an automatic processing of requirements, the impact analysis techniquerequires a formal system specification. After analyzing the existing safety specification
techniques that provide means for modularization (see Section 4.1), we selected formal
safety patterns as a base for our extensions. Several arguments back this decision:
First, safety patterns have defined semantics in LTL, which integrate well with thecontract-based approach that is needed for the impact analysis. Second, although theytranslate into a formal specification, the pattern itself are easy to understand phrases
that do not require special training in, for example, propositional logic. Third, since thesafety specification is based on written text, rather than the currently popular graphbased structures like GSN or SHIP, all existing requirements management tools in thecompanies can continue to be used without the need of any modifications. Still, theexisting safety patterns were not sufficient to express functional safety concepts as itis needed to comply with such safety standards as the ISO 26262. To this end, thelanguage needed to be extended to support multiple failure modes, in particular theconcept of safe states (see Section 4.3.1). Then, to support easy specification of safetymechanism, contract templates have been defined to cover the most common elementsof safety concepts (see Section 4.3.2). One of the major contribution of this work is theintroduction of an abstraction mechanisms in safety contracts to allow a top down designof the systems specification using refinement. This abstraction is based on the idea ofspecifying the number of potential malfunctions in a part of the system without detailingthe underlying faults (see Section 4.3.3). The concrete faults in a system are defined on
the lowest level of decomposition only. This new abstraction technique has the benefit ofpreserving the already verified properties even if the system is further refined. This typeof specification is not only necessary to be modular in a way that the impact analysis candetermine the correct affected regions, but also reflects much better the needs from safety
standards and industry, which typically require avoiding single or double faults, without1647.1 Summary of Obtained Results

specifying further the details of the faults. In fact, the atomic faults of a system are
not known at the time of building a functional safety concept. Furthermore, an analysis
had to be developed to check the compliance of an implementation to the given safety
specification. Even though we used existing fault-injection technologies, the relation
between the safety specification and the functional requirements of the system had to bedetailed. Finally, we are able to fully represent safety contracts as a functional deviationfrom the intended behavior usable in a functional injection analysis (see Section 4.5.2).
Having developed a combination of a change impact analysis and a safety specification
mechanism able to perform an impact determination with a linear relation between theverification effort and the size of the change, we needed to collect evidence to support
this claim. First, we fully specified a case-study in safety and functional terms andapplied changes to it, to demonstrate the potentials of the impact analysis as well as
the safety specification (see Section 5.1). Although a significant savings was achieved
within the example model, this approach could not be used to show the efficiency of
the approach in general. Because of the lack of multiple sufficiently large models andrealistic changes, we developed a stochastic simulation framework that acts as a proxy
to compare the developed impact analysis approach with the current state-of-the-art
approach of re-verifying the complete system (see Section 5.2). The simulation approachhas the advantage over the analysis of real user models that results are not distorted bymultiple involved engineers. In the simulation we can guarantee that the engineers takeidentical decisions in both approaches. In addition, the key properties of the approaches
such as the size of the system, the size of the change or the accuracy of the conductedverification activities could be easily adapted using a stochastic technique. Within thissimulation framework, we found indeed a linear relationship between the size of thechange and the re-verification effort. Surprisingly, the contract-based approach performs
better for changes below 15% of the total system size, independent of the size of thesystem. This rather low threshold is a pessimistic assessment, since the simulation
calculated the status of the verification activities after each change performed to anelement to always determine the exact propagation of a change. In a real-life situation
multiple changes would be conducted in one chunk before running the analysis again.
Still, even in this setting, the contract-based approach could save more than 70% of
the effort compared with the standard approach. Another interesting result of theevaluation is the fact that the approaches demand a different quality of the verification
activities. While the contract-based approach requires formal methods to reach a very
high confidence in the results of the verification activities, the standard approach does
not benefit from an increased accuracy of the tests. The increase in the overall detection
rate is diminished substantially beyond an individual test accuracy of 60%. On the other
hand, the contract-based approach delivers poor results if the verification accuracy is
below 90%.
Furthermore, in extent to the theoretical achievements we have implemented prototypes
to evaluate how a change impact analysis service could be integrated in modern distributed
development environments, synchronizing huge numbers of developers (see Section 6.1).
Our prototype is based on a reference technology platform (RTP) which uses an OSLC

165

7 Conclusion

compliant data exchange mechanism. We extended this RTP towards change management
capabilities and tested the handling of such a service with positive results.

7.2 Evaluation of Success Criteria
Five success criteria were defined in Section 1.2 detailing the scientific question of thethesis:1. The effort to determine that a system is still safe after a change is incorporated hasa linear relation to the number of development artifacts that have been changed.
Within the stochastic simulation framework we found a linear relation between thesize of the change and the re-verification effort.
2. The confidence in the safety of the system after the change is incorporated is
identical or higher compared with the current practiced approach.
The evaluation has shown that the detection rate of the newly developed change
impact approach is higher than the currently used technique of a complete reverification of the system, if not more than 15% of the whole system have beenchanged. Still, this value is a pessimistic-bound and may be significantly larger inpractice.
3. The support of the engineer during the adaptation of the system as well as all used
analysis techniques are fully automated.
We have demonstrated that all necessary verification activities needed for the
impact analysis can be automated. The refinement analysis for the new safetycontracts is implemented, and for the satisfaction analysis all needed automation
steps are described, though not completely implemented. Still, a framework to
perform satisfaction testing manually exists. Furthermore, the impact process itself
is implemented and evaluated in an automatic prototype.
4. The developed impact analysis approach is easy to apply in practice. In particular,
guidance for the engineers is available.
We evaluated the applicability for all elements of the approach that are directly
used by the engineers. The interface to the process support (the ReMain tool)
allows a simple and intuitive representation of the affected system elements. The
used specification mechanism uses natural language phrasing and the provided
templates allow a specification of safety concepts without a long training period.
In addition we have provided design guidelines on how to build an initial system
suitable for a contract-based change impact analysis.
5. The approach is in line with the current automotive safety standard ISO 26262.
The selection of the capabilities that are integrated in the safety contracts were
especially developed to support the functional safety concept of the ISO 26262. An
ontology with the needs of the FSC has been created and fully implemented in thesystem specification language.

166

7.3 Weaknesses

7.3 Weaknesses
The developed change impact analysis approach was explicitly designed to be applied
to functional safety concepts. In this application area the approach performs well andall claimed properties hold. Still, extending the approach towards technical systemdescriptions will introduce new assumptions. The approach can contain changes since
all design aspects (see Section 2.2.2) are modeled. For these aspects side effects can becalculated and detected. It is necessary to know all relevant aspects to completely designa perspective. For logical system descriptions the needed aspects are typically easy todetermine, in most cases the aspects functional, safety and timing are sufficient. For
some technical systems it is also possible to exclude some aspects. For example, heatproblems typically do not occur in low-power devices. But this assumption introduces anadditional risk. Furthermore, for many of these aspects no contract-based description
language is available, like electromagnetic interference. Hence, it is unlikely that theapproach can be applied to non-logical descriptions in the near future.
Furthermore, the approach suffers as do nearly all formal verification approaches, froma limitation in the size of problems able to be analyzed. Still, the modularization in theapproach reduces this problem, since only fractions of the system are analyzed, in contrast
to many other approaches (see Section 4.1). However, a large branching factor of therequirements will potentially lead to reaching the computational limits of the refinement
analysis. Since we did not focus on providing a very performant check, we cannot quantify
this limit yet. Nevertheless, we could compute refinements with a branching factor of 9within seconds. With a more optimized refinement analysis, problems of realistic size arefeasible.

7.4 Future Research Topics
There are still open research topics, which were excluded by the scope of this thesis
defined in Section 1.4. One of the limitations already mentioned in the previous sectionis the performance of the refinement analysis. The currently chosen approach of classicalmodel-checking using an LTL formula was easy to implement and delivered the needed
results, but other more powerful techniques will most likely increase the performance
drastically. Bounded model checking approaches seem most promising, since it is likely
to determine a safe upper bound, which is given by the FTTI.
Furthermore, the safety-contract-based specification can be extended towards probabilistic malfunction definitions. This would allow to define a distribution for the occurenceof the malfunctions and quantify the correctness of the results on the output ports.
Also the evaluating simulation can be extended in multiple ways. First, it could
be evaluated how different test accuracies used for the refinement and the satisfaction
analysis influence the results. Second, based on industrial example data the forming ofregions which are simultaneously modified could be integrated to evaluate the shift inthe break-even point. Third, if the performance of the analyses has been identified in
more detail, an estimation about run-times and computational effort with more accurate167

7 Conclusion

units of measure can be possible. In addition, it could be evaluated if it is beneficial forthe overall detection rate of the impact analysis approach to vary the test accuracy overtime. Especially for the contract-based approach, it is promising to start with higher test
accuracy and decrease it at elements distinct to the origin of the change.

168

Bibliography
Adelard. (1998). Adelard safety case development manual. Northampton Square, London.
Adler, R., Domis, D., Höfig, K., Kemmann, S., Kuhn, T., Schwinn, J.-P., & Trapp, M.
(2011). Integration of component fault trees into the uml. In J. Dingel & A. Solberg(Eds.), Models in software engineering (Vol. 6627, pp. 312–327). Lecture Notes in
Computer Science. Springer Berlin Heidelberg
Alpern, B. & Schneider, F. B. (1985). Defining liveness. Information processing letters,
21 (4), 181–185.
Ambler, S. W. (2002). Agile modeling: effective practices for extreme programming andthe unified process. John Wiley & Sons.
Arlat, J., Aguera, M., Amat, L., Crouzet, Y., Fabre, J.-C., Laprie, J.-C., . . . Powell, D.
(1990, February). Fault injection for dependability validation: a methodology andsome applications. IEEE Transactions on Software Engineering, 16 (2), 166–182.
Armengaud, E., Bourrouilh, Q., Griessnig, G., Martin, H., & Reichenpfader, P. (2012).
Using the cesar safety framework for functional safety management in the context
of iso 26262. ERTS.
Armengaud, E., Biehl, M., Bourrouilh, Q., Breunig, M., Farfeleder, S., Hein, C., . . . Zoier,
M. (2012). Integrated tool-chain for improving traceability during the developmentof automotive systems. In Proceedings of the 2012 embedded real time software andsystems conference.
Arnold, R. & Bohner, S. (1993, September). Impact analysis-towards a framework forcomparison. In Proceedings of the conference on software maintenance 1993 (csm-93)(pp. 292–301).
ARP 4761. (1996). Guidelines and methods for conducting the safety assessment process
on civil airborne systems and equipment. Aerospace Recommended Practice.
Arts, T., Dorigatti, M., & Tonetta, S. (2014). Making implicit safety requirements explicit.
In A. Bondavalli & F. Di Giandomenico (Eds.), Computer safety, reliability, and169

Bibliography

security (Vol. 8666, pp. 81–92). Lecture Notes in Computer Science. Springer
International Publishing
Atego. (2012, November). Atego workbench. http://www.atego.com/products/ategoworkbench/.
ATESST2 Consortium. (2010, June). East-adl domain model specification (tech. rep.
No. Version 2.1 RC3).
Atkinson, C. & Kühne, T. (2001). The essence of multilevel metamodeling. In M. Gogolla& C. Kobryn (Eds.), Uml 2001 – the unified modeling language. modeling languages,
concepts, and tools (Vol. 2185, pp. 19–33). Lecture Notes in Computer Science.
Springer Berlin Heidelberg
AUTOSAR GbR. (2010). Specification of the virtual functional bus. Version 1.0.1.
AUTOSAR GbR. (2014). Layered software architecture. Release 4.2.1.
Avizienis, A., Laprie, J.-C., Randell, B., & Landwehr, C. (2004). Basic concepts andtaxonomy of dependable and secure computing. IEEE Transactions on Dependable
and Secure Computing, 1, 11–33.
Baier, C. & Katoen, J.-P. (2008). Principle of model checking. The MIT Press.
Baldwin, C. Y. & Clark, K. B. (2000). Design rules: the power of modularity. MIT press.
Barnat, J., Brim, L., Havel, V., Havlíček, J., Kriho, J., Lenčo, M., . . . Weiser, J. (2013).
DiVinE 3.0 – An Explicit-State Model Checker for Multithreaded C & C++
Programs. In Computer Aided Verification (CAV 2013) (Vol. 8044, pp. 863–868).
LNCS. Springer.
Barr, M. (2013, October). Bookout v. toyota: 2005 camry l4 software analysis.
Baufreton, P., Blanquart, J., Boulanger, J., Delseny, H., Derrien, J., Gassino, J., . . .
Ricque, B. (2010). Multi-domain comparison of safety standards. In Proceedings ofthe 2010 embedded real time software and systems conference.
Baumgart, A. (2013, April). A contract-based installation methodology for safety–related
automotive systems. In Technical papers presented at sae 2013 world congress &exhibition. SAE
Baumgart, A., Böde, E., Büker, M., Damm, W., Ehmen, G., Gezgin, T., . . . Weber, R.
(2011, March). Architecture modeling. OFFIS. Retrieved from http://ses.informatik.
uni-oldenburg.de/download/bib/paper/OFFIS-TR2011_ArchitectureModeling.
pdf

170

Bibliography

Baumgart, A., Böde, E., Ellen, C., Peikenkamp, T., Sieverding, S., Sordon, N., . . . Tiran,S. (2013, July). Mbat deliverable d_wp3.1_1_3: meta models for rtp v2. Projectinternal Deliverable.
Baumgart, A., Hörmaier, K., & Deuter, G. (2014, October). Model-based method toachieve EMC for distributed safety-relevant automotive systems. In Proceedings ofthe simul 2014, the sixth international conference on advances in system simulation(pp. 263–270).
Baumgart, A., Reinkemeier, P., Rettberg, A., Stierand, I., Thaden, E., & Weber, R.
(2010, October). A model-based design methodology with contracts to enhance thedevelopment process of safety-critical systems. In S. L. Min, R. Pettit, P. Puschner,& T. Ungerer (Eds.), Software technologies for embedded and ubiquitous systems
8th ifip wg 10.2 international workshop, seus 2010, waidhofen/ybbs, austria, october
2010, proceedings (pp. 59–70). LNCS 6399. Springer.
Benveniste, A., Caillaud, B., Malot, M., Adedjouma, M., Bogush, R., Velu, J.-P., . . . Sinha,
R. (2011, November). Completeness/consistency/correctness d_sp2_r3.3_m3_vol4.
http://cesarproject.eu/fileadmin/user_upload/CESAR_D_SP2_R3.3_M3_
Vol4_v1.000_PU.pdf.
Benveniste, A., Caillaud, B., Ferrari, A., Mangeruca, L., Passerone, R., & Sofronis, C.
(2008). Multiple viewpoint contract-based specification and design. In F. de Boer,
M. Bonsangue, S. Graf, & W.-P. de Roever (Eds.), Formal methods for components
and objects (Vol. 5382, pp. 200–225). Lecture Notes in Computer Science. Springer
Berlin Heidelberg
Benveniste, A., Caillaud, B., Nickovic, D., Passerone, R., Raclet, J.-B., Reinkemeier, P.,. . . Larsen, K. (2012). Contracts for systems design. Research Centre Rennes Bretagne Atlantique.
Biehl, M., DeJiu, C., & Törngren, M. (2010). Integrating safety analysis into the modelbased development toolchain of automotive embedded systems.
Bishop, P. & Bloomfield, R. (1997). The ship safety case approach: a combination ofsystem and software methods. In R. Shaw (Ed.), Safety and reliability of software
based systems (pp. 107–121). Springer London
Böde, E., Gebhardt, S., & Peikenkamp, T. (2010). Contract based assessment of safety
critical systems. In Proceeding of the 7th european systems engineering conference(eusec 2010).
Boehm, B. & Basili, V. R. (2005). Software defect reduction top 10 list. Foundations ofempirical software engineering: the legacy of Victor R. Basili, 426.

171

Bibliography

Bohner, S. (2002, December). Extending software change impact analysis into cots
components. In Software engineering workshop, 2002. proceedings. 27th annual nasa
goddard/ieee (pp. 175–182).
Bohner, S. A. (1996). Software change impact analysis. IEEE Computer Society.
Bondavalli, A. & Simoncini, L. (1990). Failure classification with respect to detection. In
Distributed computing systems, 1990. proceedings., second ieee workshop on future
trends of (pp. 47–53).
Born, M., Favaro, J., & Kath, O. (2010). Application of iso dis 26262 in practice. In
Proceedings of the 1st workshop on critical automotive applications: robustness&#38; safety (pp. 3–6). CARS ’10. Valencia, Spain: ACM
Bozzano, M. & Villafiorita, A. (2003). Improving system reliability via model checking:the fsap/nusmv-sa safety analysis platform. In Computer safety, reliability, andsecurity. Springer Berlin Heidelberg.
Bozzano, M. & Villafiorita, A. (2011). Design and safety assesment of critical systems.
Auerbach Publications.
Broy, M. (2006). Challenges in automotive software engineering. In Proceedings of the
28th international conference on software engineering (pp. 33–42). ACM.
Büchner, F., Glöe, D. G., & Mainka, E.-U. (2003, January). Hitex white paper: using
riskcat to cope with iec 61508. Hitex Developent Tool GmbH.
Buckley, J., Mens, T., Zenger, M., Rashid, A., & Kniesel, G. (2005, September). Towards
a taxonomy of software change: research articles. Journal of Software Maintenanceand Evolution: Reserach and Practice, 17 (5), 309–332
Casais, E. (1994). The automatic reorganization of object oriented hierarchies - a casestudy.
CBSNEWS. (2010, May). Toyota "unintended acceleration"has killed 89. Retrieved from
%5Curl%7Bhttp://www.cbsnews.com/news/toyota-unintended-acceleration-haskilled-89/%7D
Ciolkowski, M., Laitenberger, O., & Biffl, S. (2003, November). Software reviews: thestate of the practice. IEEE Software, 20 (6), 46–51
Clarke, E. M., Grumberg, O., & Peled, D. A. (1999). Model checking. MIT Press.
Clarkson, P., Simons, C., & Eckert, C. (2004). Predicting change propagation in complex
design. Journal of Mechanical Design (Transactions of the ASME), 126 (5), 788–797.

172

Bibliography

CMMI Product Team. (2010, November). Cmmi for development, version 1.3: improving
processes for developing better products and services. http://www.sei.cmu.edu/
reports/10tr033.pdf.
Damm, W. (2005, June). Controlling speculative design processes using rich component
models. In Application of concurrency to system design, 2005. acsd 2005. fifthinternational conference on (pp. 118–119).
Damm, W., Dierks, H., Oehlerking, J., & Pnueli, A. (2010). Towards component based
design of hybrid systems: safety and stability. In Z. Manna & D. Peled (Eds.),
Time for verification (Vol. 6200, pp. 96–143). Lecture Notes in Computer Science.
Springer Berlin Heidelberg
Damm, W., Hungar, H., Josko, B., Peikenkamp, T., & Stierand, I. (2011, March).
Using contract-based component specifications for virtual integration testing andarchitecture design. In Design, automation test in europe conference exhibition(DATE), 2011 (pp. 1–6).
Damm, W., Josko, B., & Peikenkamp, T. (2009). Contract based iso cd 26262 safety
analysis. SAE Technical Paper.
Dassault Systems. (2012, November). Reqtify. http://www.3ds.com/products/catia/
portfolio/geensoft/reqtify/.
De Alfaro, L. & Henzinger, T. A. (2001). Interface automata. ACM SIGSOFT Software
Engineering Notes, 26 (5), 109–120.
de la Vara, J. L., Borg, M., Wnuk, K., & Moonen, L. (2014). Survey on safety evidence change impact analysis in practice: detailed description and analysis. Simula
Research Laboratory. Simula Research Laboratory.
de Roever, W.-P. (1998). The need for compositional proof systems: a survey. In Compositionality: the significant difference (pp. 1–22). Springer.
Delahaye, B., Caillaud, B., & Legay, A. (2011). Probabilistic contracts: a compositional
reasoning methodology for the design of systems with stochastic and/or nondeterministic aspects. Formal Methods in System Design, 38 (1), 1–32
Dick, J. (2005, November). Design traceability. Software, IEEE, 22 (6), 14–16.
DO 178C. (2011, December). Software considerations in airborne systems and equipment
certification. RTCA, Inc.
DoDAF/DM2 2.02. (2010, August). The dodaf architecture framework version 2.02. U.S.
Department of Defence.
Dröschel, W. & Wiemers, M. (1999). Das v-modell 97. Oldenbourg.

173

Bibliography

Echtle, K. (1990). Fehlertoleranzverfahren. Springer-Verlag.
Eckert, C., Clarkson, P., & Zanker, W. (2004). Change and customisation in complex
engineering domains. Research in Engineering Design, 15, 1–21
Eckert, C., Weck, O., Keller, R., & Clarkson, P. J. (2009). Engineering change: drivers,
sources, and approaches in industry. In International conference on engineering
design, iced’09.
Ellen, C., Etzien, C., & Oertel, M. (2012). Integration of automatic allocation solving
in a perspective oriented systems design process. In Proceedings of the date 2012conference.
Ellims, M., Bridges, J., & Ince, D. (2006). The economics of unit testing. Empirical
Software Engineering, 11 (1), 5–31
EN 50129. (2003). Railway applications – Communication, signalling and processing
systems – Safety related electronic systems for signalling. European Commitee forElectrotechnical Standardization.
Enzmann, M., Döhmen, G., Andersson, H., & Härdt, C. (2008, April). Speeds methodology- a white paper.
Espinoza, H., Ruiz, A., Sabetzadeh, M., & Panaroni, P. (2011). Challenges for an open
and evolutionary approach to safety assurance and certification of safety-criticalsystems. In Software certification (wosocer), 2011 first international workshop on(pp. 1–6). IEEE.
Fenn, J., Hawkins, R., Williams, P., Kelly, T., Banner, M., & Oakshott, Y. (2007). The
who, where, how, why and when of modular and incremental certification. In Systemsafety, 2007 2nd institution of engineering and technology international conferenceon (pp. 135–140). IET.
Firesmith, D. G. (2003). Common concepts underlying safety, security, and survivability
engineering. Carnegie Mellon University.
Föster, M. (2012, Oktober). Dependable reuse & guarded integration of automotive
software components (tech. rep. No. ESL-2012/FAT-P). RWTH Embedded software
laboratory.
Fowler, M. (2002, November). Patterns of enterprise application architecture. Boston,
MA, USA: Addison Wesley.
Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (1999). Refactoring: improving
the design of existing code. Boston, MA, USA: Addison-Wesley Longman Publishing.
Fricke, E., Gebhard, B., Negele, H., & Igenbergs, E. (2000). Coping with changes: causes,
findings, and strategies. Systems Engineering, 3 (4), 169–179.

174

BibliographyFriedrich, J., Hammerschall, U., Kuhrmann, M., & Sihling, M. (2009). Das v-modell xt.
In Das v-modell xt (pp. 1–32). Informatik im Fokus. Springer Berlin Heidelberg
Gallagher, K. & Lyle, J. (1991, August). Using program slicing in software maintenance.
Software Engineering, IEEE Transactions on, 17 (8), 751–761.
Gebhardt, V., Rieger, G. M., Mottok, J., & Gießelbach, C. (2013). Funktionale sicherheit
nach iso 26262: ein praxisleitfaden zur umsetzung. dpunkt.verlag GmbH.
Gezgin, T., Weber, R., & Oertel, M. (2014). Multi-aspect virtual integration approachfor real-time and safety properties. In Proceedings of the international workshop on
design and implementation of formal tools and systems 2014.
Gotel, O. & Finkelstein, C. (1994, April). An analysis of the requirements traceability
problem. In Requirements engineering, 1994, proceedings of the first international
conference on (pp. 94–101).
Gould, J., Glossop, M., & Ioannides, A. (2000). Review of hazard identification techniques.
Health and Safety Laboratory.
Graaf, B., Lormans, M., & Toetenel, H. (2003). Embedded software engineering: thestate of the practice. IEEE Software, 20 (6), 61–69.
GSN Community Standard. (2011, November). Version 1. Origin Consulting Limited.
Gustafsson, J., Ermedahl, A., Sandberg, C., & Lisper, B. (2006, December). Automatic
derivation of loop bounds and infeasible paths for wcet analysis using abstract
execution. In Real-time systems symposium, 2006. rtss ’06. 27th ieee international(pp. 57–66).
Hassan, A. & Holt, R. (2004, September). Predicting change propagation in software systems. In Software maintenance, 2004. proceedings. 20th ieee international conferenceon (pp. 284–293).
Henzinger, T., Qadeer, S., & Rajamani, S. (1998). You assume, we guarantee: methodology
and case studies. In A. Hu & M. Vardi (Eds.), Computer aided verification (Vol. 1427,
pp. 440–451). Lecture Notes in Computer Science. Springer Berlin Heidelberg
Hoare, C. A. R. (1969). An axiomatic basis for computer programming. Commun. ACM,
12 (10), 576–580.
Huang, G. & Mak, K. (1999). Current practices of engineering change management in
uk manufacturing industries. International Journal of Operations & Production
Management, 19 (1), 21–37. eprint: http://dx.doi.org/10.1108/01443579910244205
Humphrey, W. S. (2000). Introduction to the team software process (sm). Addison-Wesley
Professional.

175

Bibliography

Hungar, H. (2011a, September). Components and contracts: a semantical foundation forcompositional refinement.
Hungar, H. (2011b, November). Compositionality with strong assumptions. In Nordic
workshop on programming theory (pp. 11–13). Mälardalen Real–Time ResearchCenter.
IBM. (2012, November). Rational change. http://www-01.ibm.com/software/awdtools/change/.
IEEE 1471. (2000). Recommended practice for architectural description of softwareintensive systems. Institute of Electrical and Electronics Engineers.
ikv++ technologies ag. (2010, May). Medinitm analyze: functional safety analysis for
iso 26262. http://www.ikv.de/index.php?option=com_ docman&task=doc_
download&gid=41.
ISO 10007. (2003, June). Quality management systems – guidelines for configuration
management. International Organization for Standardization.
ISO 26262. (2011, November). Road vehicles – functional safety. International Organization for Standardization.
ISO/IEC. (2011, November). Iso/iec 29148: systems and software engineering - life cycle
processes - requirements engineering.
ISO/IEC 12207. (2008, February). Systems and software engineering – software life cycle
processes. International Organization for Standardization.
Jarratt, T., Eckert, C., Caldwell, N., & Clarkson, P. (2011). Engineering change: an
overview and perspective on the literature. Research in Engineering Design, 22,
103–124
Jarratt, T. A. W. (2004). A model-based approach to support the management of engineering change (Doctoral dissertation, Cambridge University Engineering Department).
Jiang, H. (2013). Key findings on airplane economic life. Boeing Commercial Airplanes.
Retrieved from %5Curl%7Bhttp://www.boeing.com/assets/pdf/commercial/
aircraft_economic_life_whitepaper.pdf%7D
Joshi, A. & Heimdahl, M. P. E. (2005). Model-based safety analysis of simulink models
using scade design verifier. In Proceedings of the 24th international conference on
computer safety, reliability, and security. SAFECOMP’05. Fredrikstad, Norway.
Kacimi, O., Ellen, C., Oertel, M., & Sojka, D. (2014, January). Creating a reference technology platform:performing model-based safety analysis in a heterogeneous development environment. In Proceedings of modelsward 2014 (pp. 645–652). SCITEPRESS.

176

Bibliography

Kaiser, B., Liggesmeyer, P., & Mäckel, O. (2003). A new component concept for fault
trees. In Proceedings of the 8th australian workshop on safety critical systems andsoftware - volume 33. SCS ’03. Canberra, Australia: Australian Computer Society.
Kececioglu, D. (1991). Reliability engineering handbook: volume i. PTR Prentice Hall,Englewood Cliffs, New Jersey.
Kelion, L. (2015, May). Airbus a400m plane crash linked to software fault.
Kelly, T. & Weaver, R. (2004). The goal structuring notation–a safety argument notation.
In Proceedings of the dependable systems and networks 2004 workshop on assurance
cases. Citeseer.
Kelly, T. (1999). Arguing safety: a systematic approach to managing safety cases (Doctoral
dissertation, University of York).
Kelly, T. (1997). A six-step method for the development of goal structures. York Software
Engineering, Flixborough, UK.
Kidd, M. & Thompson, G. (2000). Engineering design change management. Integrated
Manufacturing Systems, 11 (1), 74–77.
Kilpinen, M. S. (2008). The emergence of change at the systems engineering and software
design interface (Doctoral dissertation, University of Cambridge).
Klug, K. & Tugenberg, S. (1993). Functional lockstep arrangement for redundant processors. 5,226,152. Google Patents. Retrieved from %5Curl%7Bhttps://www.google.
com/patents/US5226152%7D
Koren, I. & Krishna, C. M. (2007). Fault-tolerant systems. Elsevier, Morgan Kaufmann.
Korpi, J. & Koskinen, J. (2007). Supporting impact analysis by program dependence graphbased forward slicing. In K. Elleithy (Ed.), Advances and innovations in systems,
computing sciences and software engineering (pp. 197–202). Springer Netherlands
Krasner, G. E., Pope, S. T. et al. (1988). A description of the model-view-controller
user interface paradigm in the smalltalk-80 system. Journal of object oriented
programming, 1 (3), 26–49.
Lamport, L. (1977). Proving the correctness of multiprocess programs. Software Engineering, IEEE Transactions on, (2), 125–143.
Lamport, L. & Merz, S. (1994). Specifying and verifying fault-tolerant systems. In Formal
techniques in real-time and fault-tolerant systems (pp. 41–76). Springer.
Laprie, J.-C. (1994). Dependability: the challenge for the future of computing andcommunication technologies. In Dependable computing - edcc-1 (pp. 405–408).
Springer.

177

Bibliography

Law, J. & Rothermel, G. (2003). Whole program path-based dynamic impact analysis. In
Proceedings of the 25th international conference on software engineering (pp. 308–
318). ICSE ’03. Portland, Oregon: IEEE Computer Society. Retrieved from http://dl.acm.org/citation.cfm?id=776816.776854
Lee, E. A. & Seshia, S. A. (2010). Introduction to embedded systems - a cyber-physicalsystems approach (1st ed.). Lee and Seshia. Retrieved from http://chess.eecs.
berkeley.edu/pubs/794.html
Lehnert, S. (2011). A review of software change impact analysis. Ilmenau University ofTechnology.
Lehnert, S., Farooq, Q., & Riebisch, M. (2013). Rule-based impact analysis for heterogeneous software artifacts. In Software maintenance and reengineering (csmr), 2013
17th european conference on (pp. 209–218). IEEE.
Leveson, N. G. & Weiss, K. A. (2004). Making embedded software reuse practical andsafe. In Proceedings of the 12th acm sigsoft twelfth international symposium onfoundations of software engineering (pp. 171–178). SIGSOFT ’04/FSE-12. Newport
Beach, CA, USA: ACM
Li, J., Pu, G., Zhang, L., Vardi, M. Y., & He, J. (2014). Fast ltl satisfiability checking by
sat solvers. CoRR, abs/1401.5677.
Lisagor, O., McDermid, J., & Pumfrey, D. (2006). Towards a practicable process forautomated safety analysis. In 24th international system safety conference (pp. 596–
607). Citeseer.
Lisagor, O. (2010). Failure logic modelling: a pragmatic approach (Doctoral dissertation,
University of York).
Lock, S. & Kotonya, G. (1999). An integrated, probabilistic framework for requirement change impact analysis. Australasian Journal of Information Systems, 6 (2).
Retrieved from http://journal.acs.org.au/index.php/ajis/article/view/292
Mäckel, O. & Rothfelder, M. (2001). Challenges and solutions for fault tree analysis
arising from automatic fault tree generation: some milestones on the way. In
Proceedings of the world multiconference on systemics, cybernetics and informatics:
information systems development-volume i - volume i (pp. 583–588). ISAS-SCI ’01.
IIIS. Retrieved from http://dl.acm.org/citation.cfm?id=646789.704234
Madslien, J. (2011, December). Gm chevrolet volt: buyers spooked by electric car fires.
Mandrioli, D. & Meyer, B. (Eds.). (1992). Advances in object-oriented software engineering.
Upper Saddle River, NJ, USA: Prentice-Hall.
Marwedel, P. & Wehmeyer, L. (2007). Eingebettete systeme. Springer London. Retrieved
from http://books.google.de/books?id=94L961HZ5lYC

178

Bibliography

MathWorks. (2011, December). Iec certification kit for iso 26262 and iec 61508. Retrieved
from %5Curl%7Bhttp://www.mathworks.de/products/iec-61508/index.html%7D
McDermid, J. & Pumfrey, D. (1994, June). A development of hazard analysis to aid
software design. In Computer assurance, 1994. compass ’94 safety, reliability, fault
tolerance, concurrency and real time, security. proceedings of the ninth annual
conference on (pp. 17–25).
Mens, T. & Tourwe, T. (2004, February). A survey of software refactoring. Software
Engineering, IEEE Transactions on, 30 (2), 126–139.
Meyer, B. (1992). Applying design by contract. IEEE Computer, 25, 40–51.
Mitschke, A., Loughran, N., Josko, B., Oertel, M., Rehkop, P., Häusler, S., & Benveniste,
A. (2010). RE Language Definitions to formalize multi-criteria requirements V2.
The CESAR Consortium. Retrieved from http://cesarproject.eu/fileadmin/user%
5C_upload/CESAR%5C_D%5C_SP2%5C_%20R2.2%5C_M2%5C_v1.000.pdf
Moore, E. & Shannon, C. (1956). Reliable circuits using less reliable relays. Journal of
the Franklin Institute, 262 (3), 191–208
Nancy. (1995). Safeware (H. Goldstein, Ed.). Addison-Wesley.
Neumann, P. (1986, September). On hierarchical design of computer systems for criticalapplications. Software Engineering, IEEE Transactions on, SE-12 (9), 905–920.
Nicholson, M., Conmy, P., Bate, I., & McDermid, J. (2000). Generating and maintaining
a safety argument for integrated modular systems. In Adelard for the health andsafety executive, hse books, isbn 0-7176-2010-7, and contract research.
Nitsche, G., Gruttner, K., & Nebel, W. (2013, September). Power contracts: a formal way
towards power-closure?! In Power and timing modeling, optimization and simulation(patmos), 2013 23rd international workshop on (pp. 59–66).
Nuseibeh, B., Easterbrook, S., & Russo, A. (2000, April). Leveraging inconsistency insoftware development. Computer, 33 (4), 24–29.
Nuseibeh, B. & Easterbrook, S. (2000). Requirements engineering: a roadmap. In Proceedings of the conference on the future of software engineering (pp. 35–46). ICSE
’00. Limerick, Ireland: ACM
Oertel, M., Battram, P., Kacimi, O., Gerwinn, S., & Rettberg, A. (2015). A compositionalsafety specification using a contract-based design methodology. In W. Leister & N.
Regnesentral (Eds.), Pesaro 2015: the fifth international conference on performance,
safety and robustness in complex systems and applications (pp. 1–7). IARIA.

179

Bibliography

Oertel, M., Gerwinn, S., & Rettberg, A. (2014, July). Simulative evaluation of contractbased change management. In Industrial informatics (indin), 2014 12th ieee international conference on (pp. 16–21).
Oertel, M. & Josko, B. (2012). Interoperable requirements engineering: tool independent
specification, validation and impact analysis. In Artemis technology conference
2012.
Oertel, M., Kacimi, O., & Böde, E. (2014). Proving compliance of implementation models
to safety specifications. In A. Bondavalli, A. Ceccarelli, & F. Ortmeier (Eds.),
Computer safety, reliability, and security (Vol. 8696, pp. 97–107). Lecture Notes in
Computer Science. Springer International Publishing
Oertel, M., Mahdi, A., Böde, E., & Rettberg, A. (2014). Contract-based safety: specification and application guidelines. In Proceedings of the 1st international workshop on
emerging ideas and trends in engineering of cyber-physical systems (eitec 2014).
Oertel, M., Malot, M., Baumgart, A., Becker, J., Bogusch, R., Farfeleder, S., . . . Rehkop,
P. (2013). Requirements engineering. In A. Rajan & T. Wahl (Eds.), Cesar - costefficient methods and processes for safety-relevant embedded systems (pp. 69–143).
Springer Vienna
Oertel, M. & Rettberg, A. (2013). Reducing re-verification effort by requirement-basedchange management. In G. Schirner, M. Götz, A. Rettberg, M. Zanella, & F. Rammig(Eds.), Embedded systems: design, analysis and verification (Vol. 403, pp. 104–115).
IFIP Advances in Information and Communication Technology. Springer Berlin
Heidelberg
OMG SysML. (2012). OMG Systems Modeling Language, Version 1.3. Object Management
Group. Retrieved from http://www.omg.org/spec/SysML/1.3/
Opdyke, W. F. (1992). Refactoring object-oriented frameworks (Doctoral dissertation,
University of Illinois at Urbana-Champaign).
OSLC: Open Services for Lifecycle Collaboration. (2012, December). http : / / open services.net/.
Papadopoulos, Y. & Maruhn, M. (2001, July). Model-based synthesis of fault trees frommatlab-simulink models. In Dependable systems and networks, 2001. dsn 2001.
international conference on (pp. 77–82).
Pasquini, A., Papadopoulos, Y., & McDermid, J. (1999). Hierarchically performed hazard
origin and propagation studies. In K. Kanoun (Ed.), Computer safety, reliability andsecurity (Vol. 1698, pp. 688–688). Lecture Notes in Computer Science. 10.1007/3540-48249-0_13. Springer Berlin / Heidelberg. Retrieved from http://dx.doi.org/
10.1007/3-540-48249-0%5C_13

180Bibliography

Paynter, S., Armstrong, J., & Haveman, J. (2000). Adl: an activity description language
for real-time networks. Formal Aspects of Computing, 12 (2), 120–144
Peikenkamp, T., Cavallo, A., Valacca, L., Bödede, E., Pretzer, M., & Hahn, E. M. (2006).
Towards a unified model-based safety assessment. In Proceedings of safecomp(pp. 275–288).
Peng, H. & Tahar, S. (1998). A survey on compositional verification.
Pnueli, A. (1977). The temporal logic of programs. In Foundations of computer science,
1977., 18th annual symposium on (pp. 46–57). IEEE.
Podgurski, A. & Clarke, L. (1990, September). A formal model of program dependences
and its implications for software testing, debugging, and maintenance. Software
Engineering, IEEE Transactions on, 16 (9), 965–979.
Pohl, K., Hönninger, H., Achatz, R., & Broy, M. (Eds.). (2012). Model-based engineeringof embedded systems: the spes 2020 methodology. Springer-Verlag Berlin Heidleberg.
Prisaznuk, P. (1992, May). Integrated modular avionics. In Aerospace and electronics
conference, 1992. naecon 1992., proceedings of the ieee 1992 national (39–45 vol.1).
Rajan, A. & Wahl, T. (Eds.). (2013). Cesar - cost-efficient methods and processes forsafety-relevant embedded systems. Springer Vienna.
Ramesh, B., Powers, T., Stubbs, C., & Edwards, M. (1995, March). Implementing requirements traceability: a case study. In Requirements engineering, 1995., proceedingsof the second ieee international symposium on (pp. 89–95).
Reinkemeier, P., Stierand, I., Rehkop, P., & Henkler, S. (2011). A pattern-based requirement specification language: mapping automotive specific timing requirements.
In R. Reussner, A. Pretschner, & S. Jähnichen (Eds.), Software engineering 2011
workshopband (pp. 99–108). Gesellschaft für Informatik e.V. (GI).
Robertson, S. & Robertson, J. (1999). Mastering the requirements process. Addison
Wesley.
Ross, H.-L. (2014). Funktionale sicherheit im automobil: iso 26262, systemengineering
auf basis eines sicherheitslebenszyklus und bewährten managementsystemen. Carl
Hanser Verlag GmbH & Co. KG.
Rozier, K. Y. & Vardi, M. Y. (2007). Ltl satisfiability checking. In D. Bosnacki & S.
Edelkamp (Eds.), Spin (Vol. 4595, pp. 149–167). Lecture Notes in Computer Science.
Springer.
Runeson, P., Andersson, C., Thelin, T., Andrews, A., & Berling, T. (2006, May). What
do we know about defect detection methods? [software testing]. Software, IEEE,
23 (3), 82–90.

181

Bibliography

Ryder, B. G. & Tip, F. (2001). Change impact analysis for object-oriented programs.
In Proceedings of the 2001 acm sigplan-sigsoft workshop on program analysis forsoftware tools and engineering (pp. 46–53). Snowbird, Utah, USA
Ryder, B. (1979, May). Constructing the call graph of a program. Software Engineering,IEEE Transactions on, SE-5 (3), 216–226.
Sage, A. P. & Rouse, W. B. (2009). Handbook of systems engineering and management(2nd Edition). John Wiley & Sons.
Santelices, R. & Harrold, M. J. (2010). Probabilistic slicing for predictive impact analysis.
Georgia Institute of Technology.
Schäfer, A. (2003). Combining real-time model-checking and fault tree analysis. In Fme
2003: formal methods. Springer Berlin Heidelberg.
Schätz, B., Pretschner, A., Huber, F., & Philipps, J. (2002). Model-based developmentof embedded systems. In J.-M. Bruel & Z. Bellahsene (Eds.), Advances in objectoriented information systems (Vol. 2426, pp. 298–311). Lecture Notes in Computer
Science. Springer Berlin Heidelberg
Sharvia, S. & Papadopoulos, Y. (2008). Non-coherent modelling in compositional fault
tree analysis. The International Federation of Automatic Control, Seoul, 6–11.
Shaw, A. (1989, July). Reasoning about time in higher-level language software. Software
Engineering, IEEE Transactions on, 15 (7), 875–889.
Sljivo, I., Jaradat, O., Bate, I., & Graydon, P. (2015, January). Deriving safety contracts
to support architecture design of safety critical systems. In 16th ieee international
symposium on high assurance systems engineering (pp. 126–133). IEEE. Retrieved
from http://www.es.mdh.se/publications/3763Software, I. R. (2015). Doors. http://www-03.ibm.com/software/products/de/ratidoor.
Sommerville, I. (2010). Software engineering (9th ed.). Harlow, England, UK: AddisonWesley.
Sommerville, I. & Sawyer, P. (1997). Requirements engineering: a good practice guide.
John Wiley & Sons, Inc.
SPEEDS. (2007). SPEEDS core meta-model syntax and draft semantics. SPEEDS D.2.1.c.
Standish Group. (1995). The standish group report: CHAOS. http://www.projectsmart.
co.uk/docs/chaos-report.pdf.
Steward, D. V. (1981). The design structure system: a method for managing the designof complex systems. IEEE transactions on Engineering Management, (EM-28).
Storey, N. (1996). Safety-critical computer systems. Addison-Wesley.

182

Bibliography

Svenningsson, R., Vinter, J., Eriksson, H., & Törngren, M. (2010). Modifi: a modelimplemented fault injection tool. In Computer safety, reliability, and security.
Springer Berlin Heidelberg.
Terwiesch, C. & Loch, C. H. (1999). Managing the process of engineering change orders:the case of the climate control system in automobile development. Journal of
Product Innovation Management, 16 (2), 160–172.
Tip, F. & Palsberg, J. (2000). Scalable propagation-based call graph construction algorithms. In Proceedings of the 15th acm sigplan conference on object-oriented
programming, systems, languages, and applications (pp. 281–293). OOPSLA ’00.
Minneapolis, MN, USA: ACM
Vidács, L., Beszédes, Á., & Ferenc, R. (2007). Macro impact analysis using macro slicing.
In Icsoft (se) (pp. 230–235).
Visser, W., Havelund, K., Brat, G., Park, S., & Lerda, F. (2003). Model checking programs.
Automated Software Engineering, 10 (2), 203–232
Von Neumann, J. (1956). Probabilistic logics and the synthesis of reliable organisms fromunreliable components. Automata Studies, 34, 43–98.
Walker, M. & Papadopoulos, Y. (2008). Synthesis and analysis of temporal fault trees
with pandora: the time of priority and gates. Nonlinear Analysis: Hybrid Systems,
2 (2), 368–382.
Walker, M. & Papadopoulos, Y. (2009). Qualitative temporal analysis: towards a full
implementation of the fault tree handbook. Control Engineering Practice, 17 (10),1115–1125.
Wallace, M. (2005). Modular architectural representation and analysis of fault propagationand transformation. Electronic Notes in Theoretical Computer Science, 141 (3),53–71.
Weiser, M. (1981). Program slicing. In Proceedings of the 5th international conference on
software engineering (pp. 439–449). ICSE ’81. San Diego, CA, USA: IEEE Press.
Retrieved from http://dl.acm.org/citation.cfm?id=800078.802557
Westman, J., Nyberg, M., & Törngren, M. (2013). Structuring safety requirements in
iso 26262 using contract theory. In F. Bitsch, J. Guiochet, & M. Kaâniche (Eds.),
Computer safety, reliability, and security (Vol. 8153, pp. 166–177). Lecture Notes
in Computer Science. Springer Berlin Heidelberg
Wright, I. (1997). A review of research into engineering change management: implications
for product design. Design Studies, 18 (1), 33–42.

183

Bibliography

Ye, F. & Kelly, T. (2004, September). Component failure mitigation according to failure
type. In Computer software and applications conference, 2004. compsac 2004.
proceedings of the 28th annual international (pp. 258–264).

184