Visit ebookball.

com to download the full version and

explore more ebook or textbook

Requirements Engineering for Safety Critical

Systems 1st Edition by Luiz Eduardo G Martins ISBN
1000795969 9781000795967

_____ Click the link below to download _____

https://ebookball.com/product/requirements-engineering-for-
safety-critical-systems-1st-edition-by-luiz-eduardo-g-
martins-isbn-1000795969-9781000795967-16012/

Explore and download more ebook or textbook at ebookball.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Handling Safety Critical Requirements in System

Engineering Using the B Formal Method 1st Edition by
Didier Essame ISBN 9783540301387
https://ebookball.com/product/handling-safety-critical-requirements-
in-system-engineering-using-the-b-formal-method-1st-edition-by-didier-
essame-isbn-9783540301387-11130/

A Formal Approach for User Interaction Reconfiguration of

Safety Critical Interactive Systems 1st edition by David
Navarre, Philippe Palanque, Sandra Basnyat ISBN 3540876977
9783540876977
https://ebookball.com/product/a-formal-approach-for-user-interaction-
reconfiguration-of-safety-critical-interactive-systems-1st-edition-by-
david-navarre-philippe-palanque-sandra-basnyat-
isbn-3540876977-9783540876977-11314/

Benefits Realization Management Strategic Value from

Portfolios Programs and Projects 1st Edition by Carlos
Eduardo Martins Serra 1032477164 9781032477169
https://ebookball.com/product/benefits-realization-management-
strategic-value-from-portfolios-programs-and-projects-1st-edition-by-
carlos-eduardo-martins-serra-1032477164-9781032477169-20924/

Modelling Support for Design of Safety-Critical Automotive

Embedded Systems 1st edition by DeJiu Chen, Rolf
Johansson, Henrik Lonn, Yiannis Papadopoulos, Anders
Sandberg, Fredrik Torner, Martin Torngren ISBN 3540876977
https://ebookball.com/product/modelling-support-for-design-of-safety-
9783540876977
critical-automotive-embedded-systems-1st-edition-by-dejiu-chen-rolf-
johansson-henrik-lonn-yiannis-papadopoulos-anders-sandberg-fredrik-
torner-martin-torngren-isb/
Safety and Security of Cyber Physical Systems Engineering
dependable Software using Principle based Development 1st
Edition by Frank Furrer ISBN 9783658371821 365837182X
https://ebookball.com/product/safety-and-security-of-cyber-physical-
systems-engineering-dependable-software-using-principle-based-
development-1st-edition-by-frank-furrer-
isbn-9783658371821-365837182x-20088/

LNCS 2784 Basic User Requirements for Mobile Work Support

Systems Three Easy Steps 1st Edition by Asbjorn Folstad,
Odd Wiking Rahlff ISBN 3540452753 9783540452751
https://ebookball.com/product/lncs-2784-basic-user-requirements-for-
mobile-work-support-systems-three-easy-steps-1st-edition-by-asbjorn-
folstad-odd-wiking-rahlff-isbn-3540452753-9783540452751-13518/

State Event Fault Trees A Safety Analysis Model for

Software Controlled Systems 1st Edition by Bernhard
Kaiser, Catharina Gramlich ISBN 9783540301387
https://ebookball.com/product/state-event-fault-trees-a-safety-
analysis-model-for-software-controlled-systems-1st-edition-by-
bernhard-kaiser-catharina-gramlich-isbn-9783540301387-13110/

Software Engineering for Real Time Systems 1st Edition by

Jim Cooling ISBN 0201596202 9780201596205

https://ebookball.com/product/software-engineering-for-real-time-
systems-1st-edition-by-jim-cooling-
isbn-0201596202-9780201596205-15548/

Strategic Safety Management in Construction and

Engineering 1st edition by Patrick Zou ISBN 1118839374
978-1118839379
https://ebookball.com/product/strategic-safety-management-in-
construction-and-engineering-1st-edition-by-patrick-zou-
isbn-1118839374-978-1118839379-20764/
Requirements Engineering for
Safety-Critical Systems
RIVER PUBLISHERS SERIES IN SOFTWARE
ENGINEERING

The “River Publishers Series in Software Engineering” is a series of

comprehensive academic and professional books which focus on the theory
and applications of Computer Science in general, and more specifically
Programming Languages, Software Development and Software Engineering.
Books published in the series include research monographs, edited
volumes, handbooks and textbooks. The books provide professionals,
researchers, educators, and advanced students in the field with an invaluable
insight into the latest research and developments.
Topics covered in the series include, but are by no means restricted to the
following:

• Software Engineering
• Software Development
• Programming Languages
• Computer Science
• Automation Engineering
• Research Informatics
• Information Modelling
• Software Maintenance

For a list of other books in this series, visit www.riverpublishers.com

Requirements Engineering for
Safety-Critical Systems

Editors

Luiz Eduardo G. Martins

Federal University of São Paulo, Brazil

Tony Gorschek
Blekinge Institute of Technology, Sweden

River Publishers
Published, sold and distributed by:
River Publishers
Alsbjergvej 10
9260 Gistrup
Denmark

www.riverpublishers.com

ISBN: 978-87-7022-427-7 (Hardback)

978-87-7022-426-0 (Ebook)

©2021 River Publishers

All rights reserved. No part of this publication may be reproduced, stored in

a retrieval system, or transmitted in any form or by any means, mechanical,
photocopying, recording or otherwise, without prior written permission of
the publishers.
 Contents

Preface xi

Acknowledgments xiii

List of Figures xv

List of Tables xix

List of Abbreviations xxi

1 Introduction 1

2 The Role of the Safety and Hazard Analysis 5

Jéssyka Vilela 5
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Foundations of Safety Engineering . . . . . . . . . . . . . . 6
2.2.1 The Threats: Faults, Errors, and Failures . . . . . . . 6
2.2.2 Safety Concepts . . . . . . . . . . . . . . . . . . . 7
2.3 A Method for Safety and Hazard Analysis . . . . . . . . . . 9
2.3.1 Step 1: Hazards Identification . . . . . . . . . . . . 9
2.3.2 Fault-Tree Analysis (FTA) . . . . . . . . . . . . . . 10
2.3.3 HAZOP . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4 STAMP/STPA . . . . . . . . . . . . . . . . . . . . 13
2.4 Step 2: Hazards Evaluation . . . . . . . . . . . . . . . . . . 14
2.4.1 Step 3: Risk Analysis . . . . . . . . . . . . . . . . . 15
2.5 Safety-related Requirements Specification . . . . . . . . . . 16
2.5.1 The Means to Obtain Safety . . . . . . . . . . . . . 17
2.5.2 Model-driven Approaches . . . . . . . . . . . . . . 18

v
vi Contents

2.5.3 Textual-driven Approaches . . . . . . . . . . . . . . 18

2.5.4 Model-driven Approaches Combined with Natural
Language Specification . . . . . . . . . . . . . . . . 19
2.5.5 Ontological Approach to Elicit Safety
Requirements . . . . . . . . . . . . . . . . . . . . . 19
2.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Integrating New and Traditional Approaches of Safety

Analysis 23
L. E. G. Martins 23
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Background and Related Work . . . . . . . . . . . . . . . . 24
3.2.1 Background . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Related Work . . . . . . . . . . . . . . . . . . . . . 25
3.3 Traditional Approaches . . . . . . . . . . . . . . . . . . . . 26
3.3.1 FMEA: Failure Mode and Effect Analysis . . . . . . 26
3.3.2 FTA: Fault Tree Analysis . . . . . . . . . . . . . . . 28
3.4 New Approaches . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.1 STAMP . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2 STPA . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 Integration Between New and Traditional Approaches . . . . 32
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Agile Requirements Engineering 37

Jéssyka Vilela 37
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Agile Methods . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.2 XP . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Agile Requirements Engineering in SCS . . . . . . . . . . . 42
4.3.1 Requirements Elicitation . . . . . . . . . . . . . . . 42
4.3.2 Requirements Analysis & Negotiation . . . . . . . . 43
4.3.3 Requirements Specification . . . . . . . . . . . . . 44
4.3.4 Requirements Validation . . . . . . . . . . . . . . . 45
4.3.5 Requirements Management . . . . . . . . . . . . . 46
4.4 Traditional x Agile Requirements Engineering . . . . . . . . 47
4.5 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5.1 Pharmaceutical Company . . . . . . . . . . . . . . 49
4.5.2 Avionics Company . . . . . . . . . . . . . . . . . . 50
 Contents vii

4.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 A Comparative Study of Requirements-Based Testing

Approaches 55
J. Santos and L. E. G. Martins 55
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2 Background and Related Work . . . . . . . . . . . . . . . . 56
5.3 Experiment Design . . . . . . . . . . . . . . . . . . . . . . 59
5.4 Results and Discussion . . . . . . . . . . . . . . . . . . . . 66
5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.6 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6 Requirements Engineering in Aircraft Systems, Hardware,

Software, and Database Development 85
J. C. Marques, S. H. M. Yelisetty and L. M. S. Barros 85
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.2 Aviation Standards . . . . . . . . . . . . . . . . . . . . . . 86
6.2.1 SAE ARP 4754A . . . . . . . . . . . . . . . . . . . 87
6.2.2 RTCA DO-297 . . . . . . . . . . . . . . . . . . . . 87
6.2.3 RTCA DO-178C . . . . . . . . . . . . . . . . . . . 89
6.2.4 RTCA DO-254 . . . . . . . . . . . . . . . . . . . . 91
6.2.5 RTCA DO-200B . . . . . . . . . . . . . . . . . . . 92
6.3 Requirements Engineering in Aviation . . . . . . . . . . . . 94
6.3.1 Certification Requirements . . . . . . . . . . . . . . 95
6.3.2 Aircraft and System Requirements . . . . . . . . . . 96
6.4 Software Requirements . . . . . . . . . . . . . . . . . . . . 98
6.4.1 Model-Based Software Requirements . . . . . . . . 99
6.4.2 Software Requirements Using Object-Oriented
Technology . . . . . . . . . . . . . . . . . . . . . . 100
6.4.3 Software Requirements Using Formal Methods . . . 101
6.5 Hardware Requirements . . . . . . . . . . . . . . . . . . . 102
6.5.1 Onboard Database Requirements . . . . . . . . . . . 103
6.5.2 Parameter Data Items . . . . . . . . . . . . . . . . . 103
6.5.3 Aeronautical Databases . . . . . . . . . . . . . . . . 104
6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7 Generating Safety Requirements for Medical Equipment 109

A. Martinazzo, L.E.G. Martins and T.S. Cunha 109
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 110
viii Contents

7.2 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.3 Framework for Integration of Risk Management Process . . 112
7.3.1 Risk Management Process According to ISO 14971 . 112
7.3.2 Framework Description. . . . . . . . . . . . . . . . 113
7.3.2.1 Equipment Functions . . . . . . . . . . . 114
7.3.2.2 Hazardous Situations Level 1 . . . . . . . 114
7.3.2.3 Equipment Architecture . . . . . . . . . . 117
7.3.2.4 Risk Evaluation and Control Level 1 . . . 117
7.3.2.5 Development of Components . . . . . . . 120
7.3.2.6 Hazardous Situations Level 2 Evaluation
and Risk Control . . . . . . . . . . . . . . 120
7.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 122

8 Meta-Requirements for Space Systems 125

C. H. N. Lahoz 125
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.2 Requirements Engineering in Space Systems . . . . . . . . . 126
8.2.1 Requirements in Space Systems . . . . . . . . . . . 126
8.2.2 Meta-Requirements in Space Systems . . . . . . . . 127
8.2.3 Requirement Engineering Process in Space Systems 128
8.3 Meta-requirements Selected to Space Systems . . . . . . . . 129
8.3.1 Accuracy . . . . . . . . . . . . . . . . . . . . . . . 130
8.3.2 Availability . . . . . . . . . . . . . . . . . . . . . . 130
8.3.3 Completeness . . . . . . . . . . . . . . . . . . . . . 131
8.3.4 Consistency . . . . . . . . . . . . . . . . . . . . . . 131
8.3.5 Correctness . . . . . . . . . . . . . . . . . . . . . . 132
8.3.6 Efficiency . . . . . . . . . . . . . . . . . . . . . . . 132
8.3.7 Failure Tolerance . . . . . . . . . . . . . . . . . . . 133
8.3.8 Maintainability . . . . . . . . . . . . . . . . . . . . 134
8.3.9 Modularity . . . . . . . . . . . . . . . . . . . . . . 135
8.3.10 Portability . . . . . . . . . . . . . . . . . . . . . . . 135
8.3.11 Reliability . . . . . . . . . . . . . . . . . . . . . . . 135
8.3.12 Recoverability . . . . . . . . . . . . . . . . . . . . 136
8.3.13 Robustness . . . . . . . . . . . . . . . . . . . . . . 137
8.3.14 Safety . . . . . . . . . . . . . . . . . . . . . . . . . 137
8.3.15 Security . . . . . . . . . . . . . . . . . . . . . . . . 138
8.3.16 Self-description . . . . . . . . . . . . . . . . . . . . 139
8.3.17 Simplicity . . . . . . . . . . . . . . . . . . . . . . . 139
8.3.18 Stability . . . . . . . . . . . . . . . . . . . . . . . . 139
 Contents ix

8.3.19 Survivability . . . . . . . . . . . . . . . . . . . . . 140

8.3.20 Testability . . . . . . . . . . . . . . . . . . . . . . . 140
8.3.21 Traceability . . . . . . . . . . . . . . . . . . . . . . 141
8.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 141

9 The Role of Requirements Engineering in Safety Cases 145

Camilo Almendra and Carla Silva 145
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.2 Safety Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . 146
9.2.2 Example . . . . . . . . . . . . . . . . . . . . . . . 147
9.2.3 Development . . . . . . . . . . . . . . . . . . . . . 149
9.3 Requirements Artefacts and Safety Cases . . . . . . . . . . 151
9.3.1 Safety Requirements . . . . . . . . . . . . . . . . . 151
9.3.2 Argumentation patterns . . . . . . . . . . . . . . . . 157
9.4 Safety Case Development and Requirements Processes . . . 161
9.4.1 Joint development . . . . . . . . . . . . . . . . . . 161
9.4.2 Traceability . . . . . . . . . . . . . . . . . . . . . . 162
9.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 163

10 Safety and Security Requirements

Working Together 167
C. Santos 167
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.2 Approaching Safety and Security Requirements . . . . . . . 168
10.2.1 Understanding the Stuxnet . . . . . . . . . . . . . . 168
10.2.2 May Stuxnet Similar Case Also Happen in Aircraft? 169
10.2.3 But are the authorities doing something in this new
scenario? . . . . . . . . . . . . . . . . . . . . . . . 169
10.2.4 Understanding the DO-326A/ED-202A Airworthiness
Security Process Specification . . . . . . . . . . . . 170
10.2.5 Why Do We Need Specific Guidelines for Security
Requirements? . . . . . . . . . . . . . . . . . . . . 171
10.2.6 A Practical Example of a Possible Back Door for an
Attacker . . . . . . . . . . . . . . . . . . . . . . . . 171
10.2.7 Considering Security Aspects During the Aircraft
Development Lifecycle . . . . . . . . . . . . . . . . 173
10.2.8 Defining Security Treat Conditions . . . . . . . . . 175
10.2.9 Security Measures . . . . . . . . . . . . . . . . . . 176
x Contents

10.2.10 Developing Security Requirements . . . . . . . . . 177

10.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 179

11 Requirements Engineering Maturity Model for Safety-Critical

Systems 183
Jéssyka Vilela 183
11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 184
11.2 A Maturity Model for Safety-Critical Systems . . . . . . . . 186
11.2.1 Process Area View . . . . . . . . . . . . . . . . . . 187
11.2.2 Maturity Level View . . . . . . . . . . . . . . . . . 188
11.3 Evaluating the safety processes . . . . . . . . . . . . . . . . 191
11.3.1 Assessment Instrument and Tool . . . . . . . . . . . 191
11.3.2 Results of a Safety Maturity Assessment . . . . . . . 192
11.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Index 199

About Editors and Authors 201

 Preface

Requirements in safety-critical systems play a central role. Not only they

specify how the system can safely interact with its environment but they play
a fundamental role in the verification and validation of such system’s safety.
They are also fundamental to certification processes, which cannot be carried
out without complete and precise requirements.
Though there exist several books on requirements engineering, this book
focuses on aspects that are specific to safety-critical contexts. It addresses
complementary issues including the interface of requirements engineering
with hazard and safety analysis, certification based on safety cases, and
automated testing. It also covers practices in several key application domains
such as aerospace and medical equipment, as well as the dependency between
security and safety.
Because its material is rooted into practice and its focus is on safety-
critical aspects, I recommend this book to both practitioners and researchers
who would like to gain a good understanding of both the state of the art and
advanced practices in the context of safety-critical systems.

Lionel Briand
Professor, Canada Research Chair, IEEE and ACM fellow.
University of Ottawa and University of Luxembourg

xi
 Acknowledgments

The KKS Research Profile SERT (Software Engineering ReThought) at

SERL, Sweden, Blekinge Institute of Technology, was a partner in research
contributing to this book. For more information see rethought.se

xiii
 List of Figures

Figure 2.1 The causal chain of threats (adapted from [4]). . . . 7

Figure 2.2 Elementary fault classes (adapted from [3]). . . . . 7
Figure 2.3 Main steps of safety analysis. . . . . . . . . . . . . 9
Figure 2.4 Fault tree for the “insulin overdose” hazard with
classification tags [8]. . . . . . . . . . . . . . . . . 12
Figure 2.5 Example of a HAZOP worksheet. . . . . . . . . . 13
Figure 2.6 Risk Analysis Matrix. . . . . . . . . . . . . . . . . 16
Figure 2.7 Failure detection description template of generic
safety requirements [17]. . . . . . . . . . . . . . . 19
Figure 3.1 Main types of FMEA and their relationships. . . . . 28
Figure 3.2 Main standard symbols used to build a fault tree
(extracted from [1]). . . . . . . . . . . . . . . . . . 29
Figure 3.3 Control structure for insulin infusion pump (partial
representation). . . . . . . . . . . . . . . . . . . . 32
Figure 5.1 Insulin Pump Components [12] . . . . . . . . . . . 61
Figure 5.2 Context model of the insulin infusion pump [12] . . 62
Figure 5.3 Insulin infusion pump requirements expressed in the
use case diagram. . . . . . . . . . . . . . . . . . . 64
Figure 5.4 Graphical representation of time effort spent on
requirements modeling. . . . . . . . . . . . . . . . 69
Figure 5.5 Graphical representation of time effort spent on test
design . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 5.6 Function Probability Density Student t of H01 . . . 76
Figure 5.7 Function Probability Density Student t of H02 . . . . 77
Figure 6.1 Relationship among Aviation Standards . . . . . . 87
Figure 6.2 SAE ARP 4754A Processes Organization . . . . . 88
Figure 6.3 Levels of IMA Approval . . . . . . . . . . . . . . 88
Figure 6.4 Relationship among Tables (Processes) of DO-
178C [5] . . . . . . . . . . . . . . . . . . . . . . 91
Figure 6.5 RTCA DO-254 Processes Organization [19] . . . . 92
Figure 6.6 Aeronautical Data Process [20] . . . . . . . . . . . 93

xv
xvi List of Figures

Figure 6.7 Types of Aircraft Parts . . . . . . . . . . . . . . . 95

Figure 6.8 Aircraft Function Implementation Process [7] . . . 97
Figure 6.9 Some Possibilities of Use of Model-Based
Development . . . . . . . . . . . . . . . . . . . . 100
Figure 6.10 Use of OOT in Requirements Specification . . . . . 101
Figure 6.11 Examples of Formal Models . . . . . . . . . . . . 102
Figure 6.12 PDI Process in DO-178C [29] . . . . . . . . . . . 104
Figure 7.1 Overview of risk management process according to
ISO 14971 (adapted from [7]). . . . . . . . . . . . 113
Figure 7.2 Framework to integrate risk management and
equipment development (based on [11]). . . . . . . 114
Figure 7.3 Redundancy and independence (based on [14]). . . 119
Figure 8.1 Requirement engineering process. . . . . . . . . . 128
Figure 8.2 Meta-requirements tree (based on [10]). . . . . . . 129
Figure 9.1 Safety argument structure (adapted from [3]). . . . 147
Figure 9.2 Safety argument example in the GSN notation
(adapted from [9]). . . . . . . . . . . . . . . . . . 148
Figure 9.3 Safety case development methodologies (adapted
from [4, 9, 14]). . . . . . . . . . . . . . . . . . . . 150
Figure 9.4 Type of safety requirements (adapted from [17]). . 152
Figure 9.5 Top-level goals in a safety case (adapted from [15]). 153
Figure 9.6 Goal decomposition into arguments and evidence
(adapted from [15]). . . . . . . . . . . . . . . . . . 153
Figure 9.7 Goal decomposition and derivation of new hazards
(adapted from [16]). . . . . . . . . . . . . . . . . . 154
Figure 9.8 Safety constraints (adapted from [16]). . . . . . . . 155
Figure 9.9 Requirements for hazard mitigation and the
rationale (adapted from [15]). . . . . . . . . . . . . 155
Figure 9.10 Justification and assumption related to PCA pump
performs intended function (adapted from [15]). . . 156
Figure 9.11 Functional decomposition pattern (adapted from [4]). 158
Figure 9.12 Component contributions to system hazards pattern
(adapted from [9]). . . . . . . . . . . . . . . . . . 159
Figure 9.13 Control system architecture breakdown pattern
(adapted from [4]). . . . . . . . . . . . . . . . . . 159
Figure 9.14 Software safety requirement identification pattern
(adapted from [18]). . . . . . . . . . . . . . . . . . 160
Figure 10.1 EDS system interfaces. . . . . . . . . . . . . . . . 172
Figure 10.2 Defining the Security Perimeter. . . . . . . . . . . 173
 List of Figures xvii

Figure 10.3 Security activities in the ARP-4754 aircraft development

process. . . . . . . . . . . . . . . . . . . . . . . . 174
Figure 10.4 Security threat scenarios. . . . . . . . . . . . . . . 175
Figure 10.5 Security measure adoption. . . . . . . . . . . . . . 177
Figure 11.1 Safety module and its relationship with Uni-REPM
[2]. . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Figure 11.2 Example of Uni-REPM Safety module action [2]. . 191
Figure 11.3 Comparison of the total number of actions of all
MPAs of the evaluated project. . . . . . . . . . . . 193
Figure 11.4 Comparison of the total number of actions of all
SPAs of the evaluated project. . . . . . . . . . . . . 194
Figure 11.5 Latency by maturity level of the evaluated project. . 195
Figure 11.6 Example of maturity model usage for continuous
improvement. . . . . . . . . . . . . . . . . . . . . 196
 List of Tables

Table 2.1 Characteristics of the dependability analysis techniques

(adapted from [4]). . . . . . . . . . . . . . . . . . . . 11
Table 2.2 Main constructs of Fault Trees (adapted from [4]). . . 11
Table 2.3 Examples of deviations and their associated guidewords
(adapted from [11]). . . . . . . . . . . . . . . . . . . 13
Table 2.4 An example of a template to document hazard
analysis. . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 2.5 A partial view of safety functional requirements in
should/should not style [8]. . . . . . . . . . . . . . . 20
Table 3.1 Identification of the potential for inadequate control
(step I of STPA). . . . . . . . . . . . . . . . . . . . . 32
Table 3.2 Mapping of the analysis steps for FMEA and
STPA [20]. . . . . . . . . . . . . . . . . . . . . . . . 33
Table 5.1 The objective of the experiment . . . . . . . . . . . . 60
Table 5.2 Requirements . . . . . . . . . . . . . . . . . . . . . 66
Table 5.3 Description of dependency between requirements. . . 68
Table 5.4 Effort in time employed in applying the approaches (in
minutes). . . . . . . . . . . . . . . . . . . . . . . . . 74
Table 5.5 Approaches application time metrics (in minutes). . . 74
Table 6.1 RTCA DO-178C Software Levels and Number of
Required Objectives [13] . . . . . . . . . . . . . . . 90
Table 6.2 DO-178C Tables and Number of Objectives [13] . . . 91
Table 6.3 Failure Condition Categories and Associated
DPAL [10] . . . . . . . . . . . . . . . . . . . . . . . 93
Table 6.4 Categories (PART) and Scope of Certification . . . . 96
Table 6.5 Advisory Circulars and Standards Recognized . . . . 96
Table 7.1 Severity classification of hazardous situations [10]. . . 115
Table 7.2 Software safety classification [10]. . . . . . . . . . . 117
Table 9.1 Benefits of SCD alongside RE activities. . . . . . . . 162
Table 10.1 Security Requirements. . . . . . . . . . . . . . . . . 179
Table 10.2 Test Scenarios for the Security Requirements. . . . . 180

xix
xx List of Tables

Table 11.1 Overview of Uni-REPM SCS safety

subprocesses. . . . . . . . . . . . . . . . . . . . . . . 190
Table 11.2 Overview of Uni-REPM SCS safety
subprocesses. . . . . . . . . . . . . . . . . . . . . . . 194
Table 11.3 Overview of Uni-REPM SCS safety
subprocesses. . . . . . . . . . . . . . . . . . . . . . . 195
 List of Abbreviations

AC Advisory circular
AD Acitvity diagram
ALARP As low as reasonably practical
ARP Aerospace recommended practice
ASCAD Adelard safety case development
BML Behavior model language
BMP Behavior modeling processes
BT Behavior tree
CAE Claim-argument-evidence
CASE Computer-aided software engineering
ConOps Concept of operations
CPU Central processing unit
CSW Components of software
DPAL Data process assurance level
DQR Data quality requirements
DRM Design reference missions
DSML Domain-specific modelling language
DSN Deep space network
EASA European aviation safety agency
EDAC Error detection and correction
EMC Electromagnetic compatibility
EMI Electromagnetic interference
ESA European space agency
FAA Federal aviation administration
FDA Food and drug administration
F-E-F Faults, errors, and failures
FTA Fault-tree analysis
GLCD Graphic liquid crystal display
GPS Global positioning system
GSN Goal structuring notation
HA Hazard analysis

xxi
xxii List of Abbreviations

HAZOP HAZard and OPerability study

HLA High level architecture
HLR High-level requirements
ICSW Item configuration of software
IEC International electrotechnical commission
IEEE Institute of electrical and electronics engineers
IIP Insulin infusion pump system
IMA Integrated modular avionics
IP Internet protocol
ISO International organization for standardization
IV&V Independent verification and validation
JPL Jet propulsion lab
LCD Liquid crystal display
LLR Low-level requirements
MBD Model-based development
MBT Model-based testing
MCO Mars climate orbiter
MDD model-driven development
MHRA Medicine and health regulatory authority
MPA Main process area
MPL Mars polar lander
MTTF Mean time to failure
MTTR Mean time to repair
NASA National aeronautics and space administration
NEAR Near earth asteroid rendezvous
NFR Non-functional requirements
NFR Non-functional requirements
OAO Orbiting astronomical observatory
PDI Parameter data item
POFOD Probability of failure on demand
QFD Quality function deployment
RAD Requirement activity diagram
RBT Requirement based testing
RE Requirements engineering
RF Radio frequency
ROCOF Rate of occurrence of failures
RQ Research question
RTCA Radio technical commission for aeronautics
SACM Structured assurance case metamodel
 List of Abbreviations xxiii

SAE Society of automotive engineers

SC Safety cases
SCD Safety case development
SCS Safety-critical systems
SEU Single-event upset
SIL Safety integrity level
SLR Systematic literature review
SPA Sub-process area
SPI Software process improvement
SRSt Software requirements standards
STAMP Systems-theoretic accident model and processes
STAR Self-testing-and-repairing
STPA Systems-theoretic process analysis
SW Software
SysML Systems modeling language
TBT Test behavior tree
TC Test case
TDD Test-driven development
TMR Triple modular redundancy
UML Unified modeling language
UNIFESP Federal university of são paulo
Uni-REPM Unified requirements engineering process maturity model
Uni-REPM SCS Uni-REPM for safety-critical systems
USW Unit of software
XP eXtreme programming
 1
Introduction

Safety-critical systems (SCS) have gone mainstream. In essence, most people

today are dependent on, use, and are enabled by, SCS. Traditionally SCS
were seen as separate and special, demanding rigorous conceptualization,
engineering, and quality control, as the implications of failure were severe
resulting in harm, loss, or significant detriment. However, the evolutionand
saturation of use, of all manners of software intensive products and services
(SIPS) has changed the landscape. Today, most systems can be seen not
as optional or addons, but rather as utilities. Mobile phones, networks,
and services are one such example that might be obvious todaybut were
considered a side-note 25 years ago. The same is true for communication
apps, productivity systems, and access to online services. This smudging of
boundaries, where a consumer smartwatch in essence complements, or even
supplements, medical equipment is omnipresent as technology and access
pushes the traditional categorization.
This evolution has implications, which we will discuss shortly, but more
importantly it has potential and benefits. The ability for invention and
innovation is accelerating and far outweighs any detrimental effects. For
example, linking a smartwatch to an app that tracks health stats, and through
cloud-based big data analytics using narrow AI and machine learning predicts
a heart attack. The rigor of such “consumer” SCS is less, however, the
level of access to a wide range of users has enormous potential for good.
Functionality traditionally associated with medical domain grade systems in
this case has moved to the public domain. Further, the interaction between
benign parts networked can result in critical functional combinations. The
interaction and functional networking of multiple independent systems, such
as third-generation collision avoidance, combined with route planning and
mobile positioning to offer safer and more economical routes to a driver.
These are two small examples of when the boundary of critical and consumer
based systems blur.

1
2 Introduction

There are two main implications to this. First, many companies and the
SIPS they supply are not considered to be in the category of SCS. These
companies do not have the tradition of SCS engineering, nor are regulated as
such. Second, many companies that are considered to supply critical systems
will be subject to competition (alternatives), but more importantly functional
networking of offerings, where their products will be one part of a chain, will
impact their offering and ability for quality assurance. This might present the
instinct to introduce more regulation and control, which might be a part of the
future, however, a better and more mutually beneficial approach would be to
improve the overall engineering in all cases. Companies and organizations
with critical systems expertise can both learn and share experience and
knowledge.
This book presents an important step in the evolution, but also sharing,
of critical systems engineering knowledge, and starts at the logical and
important knowledge area of requirements engineering - figuring out what to
include in a software intensive product or service, and to what level of quality.
There are countless examples of the importance of requirements engineering
as a knowledge area that is inherent in all of the parts of the engineering
chain - from the inception, planning, design, realization, and verification and
validation and evolution of a system. Thus we will not motivate it further
here, but rather focus on the development of the area in the context of this
book.
In the fast-moving pace of (traditionally non-SCS) SIPS we see that
good-enough requirements engineering and the use of iterative continuous
engineering and delivery mechanisms utilized as a part of “agile” or “lean”
practices and principles are outpacing more plan-driven approaches. The
motto “fail fast, fail often” is a good summary of trying out solutions instead
of focusing on catching the requirements “correctly” and validating them.
This way of thinking is rather contrary to more rigid engineering approaches
where formalism is dependent on “getting it right” and validating correctness
before committing to development. One could argue for both approaches, and
try to force one over the other - however, both are a reality. Both have benefits.
Good-enough approaches focus on end results pace and offer the realization
that resources and time-to-market are critical for success. Rigid approaches
focus on avoiding the potential detrimental effects of making mistakes, which
in certain applications take precedence.
However, since critical and non-critical SIPS get more and more
indistinguishable, there is a need to evolve the respective engineering
practices. This book offers an important part of this continuous journey.
 Introduction 3

But it is done in a responsible and useful way. It takes the deep and
significant tradition of critical systems engineering and elaborates towards
today’s organizations developing SIPS by making it more available outside of
the traditional fields of SCS. The book also looks at opportunities to introduce
new and improved practices and “good-enough” perspectives to the SCS
community by bringing ideas and concepts from requirements engineering to
the table in a manner compliant with standards, regulations, and principles.
The second part of the book offers important application examples in various
domains of application that anchors the book beyond theory and generic
standards. The book is also significantly based on recent research into the
field of requirements engineering for SCS.
We would recommend this book to three categories of professionals and
students. If you are active in the SCS category of SIPS the book offers you
insights into requirements engineering as an enabler to improve practices
and principles already in placeand offers a bridge between rigid and more
continuous engineering. If you are working in a non-SCS application area,
you can learn a lot from SCS engineering, and most likely the future will
necessitate this knowledge. If you are in between, a life-long student of
new ways of combining good ideas from different outlooks, you might find
synthesis and inspiration to fill your engineering toolbox.
 2
The Role of the Safety and Hazard Analysis

Jéssyka Vilela

Universidade Federal de Pernambuco, Brazil

E-mail: [email protected]

Abstract
The complexity introduced using software to control hardware components
leads to accidents and safety incidents caused by requirements problems.
This chapter explores the role and influence of safety and hazard analysis
in the safety requirements definition. The relationship between safety/hazard
analysis and requirements engineering is explored by defining safety and
hazard analysis methods, which results in safety requirements that should be
specified early in the software development process to develop safer systems.

Keywords: Safety Analysis, Hazard Analysis, Safety Requirements

Definition, Requirements Engineering, Dependability.

2.1 Introduction
Companies have produced even more highly evolved computing systems used
in people’s daily lives, requiring high reliance [1][3]. For instance, to provide
a set of cash dispensers, control a satellite constellation, an airplane, a nuclear
plant, o a radiation therapy device, or to maintain a sensitive database’s
confidentiality. In this type of computing s, called Safety-Critical Systems
(SCS), failures (events that occur when the delivered service deviates from its
specification) could cause accidents resulting in damage to the environment,
financial losses, injury to people, or even the loss of lives [1][2].
Accordingly, these safety-critical systems should support the dependability
property, which corresponds to the ability to deliver services that can

5
6 The Role of the Safety and Hazard Analysis

justifiably be trusted [3][4] as well as analyze and specify safety requirements

correctly [2]. Dependability is usually decomposed into six attributes [3]:
• Availability: the ratio of time a system is ready for use.
• Reliability: the probability of absence of failure in software operation
for a determined time in a defined environment.
• Safety: the absence of severe consequences to users and the environment
due to system usage.
• Confidentiality: the lack of unauthorized disclosure of information.
• Integrity: The level at which a system or component hampers
unauthorized access to, or modification of, computer programs or data.
• Maintainability: the ability of systems to be subjected to modifications
and repairs.
The intended purpose for the system will direct the emphasis considered
in each attribute [3]. This chapter emphasizes the safety attribute aiming to
increase the ability to avoid failures that could be catastrophic to users or
the system’s environment [3]. In the following sections, we establish the
foundations of safety engineering by describing the safety-related concepts
involved in hazard analysis and safety requirements specification.

2.2 Foundations of Safety Engineering

A system may fail because it does not comply with the specification or
because it did not adequately describe its function [1][3]. A causal chain -
Faults, Errors, and Failures (F-E-F) - threatens the dependability of a system
in the sense that the chain completion leads the system to a state that reports
incorrect service or outage [4]. This causal chain, described in the next
section, is of fundamental importance for applying safety and hazard analysis
techniques discussed in Section 2.3.

2.2.1 The Threats: Faults, Errors, and Failures

In the F-E-F chain, illustrated in Figure 2.1, a fault is the cause of an error,
a state of the system that may lead to failure. In this causal view, an error
is seen as an intermediate stage between fault and failure. However, it is
essential to note that a fault does not necessarily lead to an error, which does
not necessarily lead to failure.
A fault is the adjudged or hypothesized cause of an error. A fault is
active when it produces an error; otherwise, it is dormant [3]. We can
 2.2 Foundations of Safety Engineering 7

Figure 2.1 The causal chain of threats (adapted from [4]).

cite a physical defect that occurs within hardware components and design
faults/implementation mistakes as examples of faults. Avizienis et al. [3]
provide a very rich and precise taxonomy of sources of faults, presented in
Figure 2.2.
The erroneous behavior characterizes error states for components,
connectors, and services due to fault occurrences [4]. Sometimes a
component raises an error that does not reach the system boundaries, meaning
it does not cause a failure. This occurs when the service delivered by the
component is not in the system interface. However, such a component may
offer its service to another internal component, leading to error propagation
between components [4]. At some point, this error will lead to the occurrence
of a failure. Finally, failure is a deviation from the system’s specification
resulting in incorrect behavior regarding expected correct operation.
For safety-critical systems, fault, error, and failure concepts are
complemented with safety-related concepts such as hazards [4] described in
the next section.

2.2.2 Safety Concepts

The specification of a safety-critical system involves the analysis and
documentation of safety-related concepts. In a previous work [10], we present
Safe-RE, a safety requirements metamodel elaborated based on industry
safety standards, whose aim is to support the specification of safety-related
concepts in the RE process. Safe-RE consists of entities and relationships

Figure 2.2 Elementary fault classes (adapted from [3]).

8 The Role of the Safety and Hazard Analysis

that represent concepts common to different safety standards from other

domains. The Safe-RE metamodel contains information that must be recorded
regardless of the safety standard being followed [10].
Safety analysis aims to identify, analyze, and specify the safety-related
concepts and demonstrate that the developed system is safe. The main
concepts [10] are defined below and illustrated considering an Insulin
Infusion Pump system (IIP) [8] [9]:

• Accident: it is an undesired and unplanned (but not necessarily

unexpected) event that results in (at least) a specified level of loss. Some
accidents can occur due to the use of the IIP, such as user receives
incorrect treatment, user infection, electrical shock, and environmental
pollution.
• Safety Incident: It is an event that involves no loss (or only minor
loss) but with the potential for the loss under different circumstances.
On the other hand, harm can occur to assets of the system or the
Mission.
• Hazard: it is a system state that might, under certain environmental
or operational conditions (context), lead to different consequences:
accident, safety incident, or cause harm. It is associated with
Functional Requirements and has a severity degree and likelihood.
Several hazards can occur in the IIP, such as Overdose: the user
receives more insulin than required; Underdose: the user gets less
insulin than needed; Excessive thermal energy generation by the pump;
Excessive sound frequencies generated by the pump; and Excessive
pump vibration.
• Risk: it is a combination of consequence (hazard severity) and
probability of the hazard, i.e., risk = hazard probability x hazard
severity. The probability of sensor failure in IIP that may result in
an insulin overdose is Occasional. Therefore, the risk of an insulin
overdose is probably medium to low.
• Safety Functional Requirement: It should be implemented to avoid the
occurrence of hazards or to mitigate them. For example, considering the
insulin overdose hazard and one of its causes is the free flow. Some
safety functional requirements to mitigate them can be the operation
of the pump within a temperature between 25 ◦ C and 37 ◦ C; and, manage
of reservoir volume.
 2.3 A Method for Safety and Hazard Analysis 9

2.3 A Method for Safety and Hazard Analysis

Considering that Safety-Critical Systems (SCS) are usually submitted to
safety certification processes, in their development, an in-depth Hazard
Analysis (HA) is required to ensure that the system is safe and the hazards of
the system were appropriately mitigated.
Safety engineers have used several techniques in safety analysis during
the last decades. Safety analysis aims to identify safety needs that ensure
or mitigate that system failures do not cause injury, death, or environmental
damage. We can consider four main steps to be conducted during the safety
analysis, illustrated in Figure 2.3 and explained in the following sections.

2.3.1 Step 1: Hazards Identification

The hazards identification step consists of performing the hazard analysis in
which experienced stakeholders, working with engineers, safety experts, and
professional safety consultants, identify hazards according to their experience
and from an application domain analysis. Many techniques could be used
at this stage as recommended by the international standard IEC-60300-3-1.
Some criteria may be considered for technique selection since there is no
best technique for all systems. The technique selection depends on the needs
of the company and the system. Some criteria that could be used are presented
by Bernardi et al. (2003) [4]:
• Applicability in the Life Cycle: The early stages techniques are used
in the requirement analysis or when the design process starts; The

Figure 2.3 Main steps of safety analysis.

10 The Role of the Safety and Hazard Analysis

late stages techniques are used when the detailed design specification
becomes available. Finally, techniques can be used across different
stages: initial models are constructed during the requirement analysis
and, then, refined to a more detailed level as data become available to
make decisions and trade-offs.
• Aim of the Analysis: It can be either qualitative (used to the
identification of the component failure modes, their consequences
at a system level, and the cause-effect paths, as well as the
determination of possible repair/recovery strategies) or quantitative
(used to define numerical reference data to be used as input parameters
of reliability/availability models).
• Bottom-Up/Top-Down: Bottom-up methods mainly deal with the
effects of single faults, and the starting point of the analysis is the
identification of the faults at the component level. Top-down methods,
on the other hand, enable analyzing the effects of multiple faults.
• Cause-Effect Relationships Exploration: deductive techniques start
from known effects to seek unknown causes; inductive techniques start
from known causes to forecast unknown effects. In contrast, exploratory
techniques relate unknown causes to unknown effects.
Table 2.1 summarizes the characteristics of the dependability analysis
techniques according to the criteria mentioned above: the applicability in
the lifecycle (second column); the aim (third column), i.e., qualitative
(ql.) vs/quantitative (qn.); bottom-up vs/ top-down (fourth column); and,
finally, the type of exploration of the cause-effect relationship (fifth
column).
In this chapter, we discuss three techniques used for hazard analysis: (1)
Fault-Tree Analysis (FTA): across, qualitative and quantitative, top-down,
deductive; (2) HAZOP: early, qualitative, bottom-up, exploratory; (3)
STAMP/STPA: across, qualitative, top-down/bottom-up, inductive/deductive
technique.

2.3.2 Fault-Tree Analysis (FTA)

A Fault Tree comprises logic gates (AND, OR, K-of-M) and external nodes
corresponding to component/subsystem faults [4] illustrated in Table 2.2.
This technique allows representing and analyzing the component faults
whose combined occurrence produces a system failure. It is a top-down
technique; accordingly, the representation of a fault tree initiates by selecting
a system failure mode (the top event). It ends when either the basic events
 2.3 A Method for Safety and Hazard Analysis 11

Table 2.1 Characteristics of the dependability analysis techniques (adapted from [4]).
Technique Lifecycle Aim Bottom-up/ Cause-effect
Top-down relationship
exploration
ETA across ql./ qn bottom-up inductive
FMEA across ql bottom-up inductive
FMECA across qn bottom-up inductive
FTA across ql./ qn top-down deductive
FFA early ql bottom-up deductive
HAZOP early ql bottom-up exploratory
Markov analysis late qn top-down not applicable
PN late ql./ qn top-down inductive
PHA early ql bottom-up exploratory
RBD across ql./ qn top-down inductive
Truth table late ql./ qn not applicable inductive
STAMP/ across ql top- inductive/ deductive
STPA down/bottom-
up

Table 2.2 Main constructs of fault trees (adapted from [4]).

Symbol Name Description
Event A fault event that happens as a result of
the logical combination of other events.

AND Gate The output event occurs only if ALL

input events occur.

OR Gate The output event occurs only if (at least)

one or more input events occur.

K-of-M gate Output event that happens if K or more

of the M input events occur.

that trigger such a failure are all identifiedor the desired level of detail is
achieved [4]. Therefore, they are suitable for constructing models following a
hierarchical approach that contributes to improving the model readability and
reusability.
An example of a fault tree, which is a partial view of the “insulin
overdose” hazard [8], is illustrated in Figure 2.4. The top event (Insulin
overdose) is caused by one of the events at the lower level, which are then
connected with an OR gate. To improve the FTA understanding, Martins
and Oliveira [8] put tags near the fault tree leaves. These tags identify if the
12 The Role of the Safety and Hazard Analysis

Figure 2.4 Fault tree for the “insulin overdose” hazard with classification tags [8].

failure cause is a software cause (S), an electronic cause (E), or a mechanical

cause (M).

2.3.3 HAZOP
HAZard and OPerability study (HAZOP) is a qualitative technique based
on guidewords (e.g., none, more of, less of, part of, more than, other) that
represent a possible deviation from the normally expected characteristic of
a system [4]. Table 2.3 presents some examples of guidewords and their
meaning presented in IEC 61882 [11], describing a flow chart of the HAZOP
examination procedure.
Driven by the guidewords, the causes of failures and their effects are
listed. Each effect is then considered, and actions must be proposed to
mitigate it or decrease the probability of the failure cause. The information
elicited with HAZOP is represented in a tabular form, such as the worksheet
in Figure 2.5.
A multidisciplinary team often carries out HAZOP during the early stages
of the system life cycle (i.e., requirement analysis, high-level design) to
anticipate hazards [4]. Moreover, it can be used in conjunction with other
dependability analysis methods such as fault tree analysis explained in the
previous section.
 2.3 A Method for Safety and Hazard Analysis 13

Table 2.3 Examples of deviations and their associated guidewords (adapted from [11]).
Deviation type Guideword Example interpretation for process
industry
Negative NO No part of the intention is satisfied,
e.g., no flow.
MORE A quantitative increase, e.g. higher
Quantitative
temperature.
modification
LESS A quantitative decrease e.g. lower
temperature.
AS WELL AS Execution of steps at the same time.
Quantitative
PART OF Only some intention is achieved, i.e.,
modification
only part of an intended fluid transfer
occurs.
REVERSE Covers reverse flow in pipes and
Substitution reverse chemical reactions.
OTHER THAN A result other than the original goal is
achieved, i.e., transfer of wrong
material.
EARLY Something occurs early relative to
Time clock time, e.g., cooling or filtration.
LATE Something takes place late relative to
clock time, e.g., cooling or filtration.
Order BEFORE Something occurs too early in a
or sequence, e.g., mixing or heating.
sequence AFTER Something happens too late in a
sequence, e.g., mixing or heating.

Figure 2.5 Example of a HAZOP worksheet.

2.3.4 STAMP/STPA
STAMP is a causality model proposed by Nancy Leveson [1] that relies on
three main concepts: safety constraints, safety hierarchical control structures,
and process models. Hence, instead of defining safety management in
preventing component failures, STAMP proposes creating a safety control
14 The Role of the Safety and Hazard Analysis

structure that will enforce the behavioral safety constraints and ensure their
continued effectiveness as changes and adaptations occur over time [1]. STPA
[1] is an approach to hazard analysis that can be used at any stage of the
system life cycle, and it defines two main steps [1]:
Step 1: Identify the potential for inadequate control of the system that
could lead to a hazardous state.
Step 2: Determine how each potentially hazardous control action
identified in step 1 could occur.
The information provided in the first step of STPA can be used to detect
the necessary constraints on component behavior to avoid the identified
system hazards, which are specified as safety requirements. In the second
step, the information required by the component to properly implement the
constraint is identified, and additional safety constraints and information
necessary to eliminate or control the hazards in the design or properly design
the system in the first place [1]. According to Leveson [1], a table or other
types of representation may be used to record the HA results.

2.4 Step 2: Hazards Evaluation

In the hazards evaluation step, it is estimated the probability of the
identified hazards and their severity. Usually, it is not possible to perform
this accurately due to the absence of enough quantitative data available for
statistical analysis. In this context, common qualitative values are used for
the severity:
• Not Significant: Minor injuries or discomfort. No medical treatment or
measurable physical effects;
• Minor: Injuries or illnesses requiring medical treatment. Temporary
impairment;
• Moderate: Injuries or illness requiring hospital admission;
• Major: Injury or illness resulting in permanent impairment;
• Severe: Fatality.
Common qualitative values used for probability are:
• Almost Certain: Expected to occur regularly under normal circumstances;
• Likely: Expected to happen at some time;
• Possible: May occur at some time;
• Unlikely: Not likely to occur in regular circumstances;
• Rare: It could happen, but probably never will.
 2.5 Safety-related Requirements Specification 15

Table 2.4 An example of a template to document hazard analysis.

Hazard analysis Page of
Company Date: __/__/__
System
Number Hazard Cause Probability Severity Risk Aceitability

An example of a template that could be used to document the hazard

analysis is presented in Table 2.4.
The values of risk and aceitability are defined after performing the risk
analysis described in the next step.

2.4.1 Step 3: Risk Analysis

The risk analysis step determines the risk of each identified hazard
considering the combination of the probability and the severity. This analysis
is performed considering a risk analysis matrix, such as the one illustrated in
Figure 2.6. After the determination of the risks, we should determine their
Aceitability. According to the literature, we can categorize them as:
• Intolerable: These are those that threaten human life and should never
arise or result in an accident. In the case of the insulin pump, an
unacceptable risk is an insulin overdose.
• Tolerated (as low as reasonably practical – ALARP): Those whose
consequences are less severe or severe but have a very low probability
of occurrence. They should be mitigated unless risk reduction is
impracticable or excessively costly. An ALARP risk for an insulin pump
may be hardware monitoring system failure. The consequences are, at
worst, short-term insulin underdose. This is a situation that would not
cause a severe accident.
• Acceptable: These are those in which the associated accidents usually
result in minor damage. The risk consequences are acceptable and
should be made at no additional cost to reduce the probability of risks.
An acceptable risk in an insulin pump may be the risk of an allergic
reaction arising in the user; This usually only causes skin irritation. It
would not be worth using more expensive special materials on the device
to reduce this risk.
In the next section, we detail the last step performed in safety analysis: the
specification of safety requirements.
 11
16 The Role of the Safety and Hazard Analysis

Severity

Minor Injuries or Injuries or Injury or Fatality

injuries or illnesses illness illness
discomfort. requiring requiring resulting in
No medical medical hospital permanent
treatment or treatment. admission. impairment.
measurable Temporary
physical impairment.
effects

Not Minor Moderate Major Severe

Significant

Expected to Almost Medium High Very High Very High Very

occur regularly Certain High
under normal
circumstances.

Expected to Likely Medium High High Very High Very

occur at some High
time.
Probability

May occur at Possible Low Medium High High Very

some time. High

Not likely to Unlikely Low Low Medium Medium High

occur in
normal
circumstances.

Could happen, Rare Low Low Low Low Medium

but probably
never will.

Figure 2.6
Figure 2.6. Risk
RiskAnalysis
analysisMatrix.
matrix.
In the next section, we detail the last step performed in safety analysis: the specification of
safety requirements.
2.5 Safety-related Requirements Specification
2.5purpose
The SAFETYof -RELATED REQUIREMENTS
the safety-related SPECIFICATION
requirements specification is to identify the
Safety-Related Requirements
The purpose of the safety-related that determine
requirements how risks
specification is toshould
identifybethemanaged
Safety-
and ensure no accidents/incidents occur. According to Firesmith [12], no
Related Requirements that determine how risks should be managed and ensure the
accidents/incidents occur. According to Firesmith [12], the requirements can be classified
requirements can be classified as:
as:
• Safety Requirements: is a combination of a safety criterion and a
 Safety Requirements: is a combination of a safety criterion and a minimum
minimum
thresholdthreshold
on a safetyon a safety
measure. Theymeasure. They system
directly specify directly specify
safety, system
and they are
safety, and they
considered a kindare considered
of quality a kind
requirement of quality
[12]. Examples: requirement
at the insulin pump,[12].
the
Examples: at the insulin pump, the difference between the scheduled
 2.5 Safety-related Requirements Specification 17

infusion and the delivered infusion should not exceed 0.5%; The system
should not cause more than 5 accidental damages per year;
• Safety-Significant Requirements: they are non-safety primary mission
requirements with significant safety ramifications. They can be classified
as a subset of non-safety requirements: Functional Requirements,
Data Requirements, Interface Requirements, Non-safety Quality
Requirements, and Constraints [12]. Examples of such requirements are
“Requirements for controlling elevator doors such as Keep doors closed
when moving”; and “Not crush passengers.”
• Safety System Requirements or Safety Functional Requirements:
These are requirements for safety systems or subsystems. An example of
such requirements is “The Fire Detection, and Suppression System shall
detect smoke above X ppm in the weapons bay within 5 seconds” [12].
• Safety Constraints: they are any constraint primarily intended to ensure
a minimum level of safety. For example: “Oils and hydraulic fluids shall
be flame retardant, except as required for normal lubrication” [12].
The determination of such requirements relies on the techniques to obtain
safety described in the next section.

2.5.1 The Means to Obtain Safety

After identifying the hazards and the associated risks, we must specify the
safety requirements aiming to eliminate or prevent hazards [1]. The technique
being used depends on the hazard aceitability previously documented and the
number of resources available. The safety requirements can be derived from
the following set of four risk reduction strategies [3]:
1. Fault avoidance: it consists of using techniques to prevent, by
construction, the occurrence of faults. Therefore, the system is designed
so that hazards cannot occur.
2. Fault detection and removal aim to minimize, using verification and
validation techniques, the presence of faults. Hence, the system is
designed to detect and neutralize hazards before they result in an
accident. In this strategy, static and dynamic analysis can be performed
as well as fault injection.
3. Fault-tolerance: it has the goal of providing, for redundancy,
specification-compliant service even in the presence of hazards. Fault
tolerance does not eliminate the need for using avoidance or removal
techniques.
18 The Role of the Safety and Hazard Analysis

4. Fault forecasting: it involves minimizing, by qualitative or quantitative

evaluations or using estimates, the presence, future incidence, and the
likely consequences of faults.
Usually, a combination of risk reduction strategies is used. For example, in
a chemical plant control system, the system will include sensors to detect
and correct excess pressure in the reactor. However, it will also include
an independent safety system, which opens a relief valve if the risk of
dangerously high pressure is detected. In the following sections, we describe
some safety requirements specification techniques.

2.5.2 Model-driven Approaches

Model-driven development (MDD) is defined as the use of models for
developing software [4]. A model-driven approach to conducting hazard
analysis on use cases [6] requirements representations is described by
Allenby and Kelly [5]. Using the approach, it is possible to specify safety
requirements from use cases. Their approach consists of three main steps:
1. Representation of core functionality by the identification of core use
cases; 2. Identification and documentation of the scenarios for each core use
case; 3. Decomposition and allocation of functionality across communicating
subsystems. In the end, functional requirements at each development level
under consideration will be represented in use case diagrams.
Thramboulidis and Scholz [16] present an approach to integrate safety
analysis with the 3+1 SysML view model, a SysML-based architectural
approach for mechatronic system development. The first activity is to
apply Hazard Analysis based on the requirements composed of SysML
requirements diagrams and essential use cases. In the second phase of safety
analysis, a solution-dependent hazard analysis that results, among others, in
defining required Safety Integrity Levels (SILs) for the system components
and their assigned functions is performed.

2.5.3 Textual-driven Approaches

Safety requirements documentation can also use the textual format. Fu,
Bao e Zhao [17] define embedded software generic safety requirements
description templates to perform safety analysis based on controlled natural
language and requirements description templates. An example of a failure
detection description template is presented in Figure 2.7.
 2.5 Safety-related Requirements Specification 19

Figure 2.7 Failure detection description template of generic safety requirements [17].

The templates include safety requirements structural elements description

templates and safety requirements sentence pattern description templates
based on obtained structural elements, failure modes, safety strategies.

2.5.4 Model-driven Approaches Combined with Natural

Language Specification
The combination of model-based safety analysis and text expressed by natural
language is also adopted by the literature to improve the understandability
and result in more detailed safety requirements. Martins and Oliveira [8]
proposed a protocol to help requirements engineers to derive safety functional
requirements from FTA. The requirements are expressed in the style “Should”
and “Should Not” Requirements. Columns (3) and (4) in Table 2.5 present
some “should” and “should not” requirements obtained from the fault tree of
Figure 2.4.

2.5.5 Ontological Approach to Elicit Safety Requirements

Ontologies have been used for requirement elicitation [13] as well as
for safety requirements elicitation [14][15]. Provenzano et al. define a
heuristic Safety Requirements Elicitation (SARE) approach to elicit safety
requirements considering knowledge obtained in the previous safety analysis.
This knowledge comprehends the causes, sources, and consequences of
hazards. Their approach consists of three activities: (1) overcome an
object’s weakness; (2) change, add or remove an object’s role; (3) cut
off existing relation; and it relies on a hazard ontology to guide to
derive the safety requirements more appropriate to mitigate the associated
hazards.
The work of Zhou et al. [15] uses conceptual ontologies to 1)
systematically organize the knowledge of the system operating environment
and 2) simplify the elicitation of environmental safety requirements.
The ontologies organize the environment knowledge in terms of relevant
environment concepts, relations among them, and axioms in their approach.
Environmental assumptions are captured by instantiating the environment
ontology. The approach consists of four steps: (1) Preparation, (2) Ontology
20 The Role of the Safety and Hazard Analysis

Table 2.5 A partial view of safety functional requirements in should/should not style [8].
Safety Functional Requirements
(1) Safety (2) Failure (3) “Should” Requirements (4)
Requirements causes “Should
Not”
Requirements
Incorrect Failure in 1. The system should delimit 1. The system should not
input user the insulin value range during allow the user to choose
of interface the specification of basal insulin value out of the
insulin (S) infusion profile. safety specified range for
value 2. The input of insulin value basal infusion profile.
to basal infusion profile
specification should be done
using up and down buttons.
Failure in 3. The system should store at
data storing least 3 basal infusion profiles,
(S) each one specifying 24 insulin
values (one by hour).

Definition, (3) Rule Definition, and (4) Safety Requirements Elicitation.

Finally, an ontological reasoning mechanism is also provided to support the
elicitation of safety requirements from the captured assumptions.

2.6 Conclusions
Safety is a system property representing its ability to avoid failures
that could be catastrophic to users or the system’s environment. In this
chapter, we discussed the foundations of safety engineering by explained
the F-E-F (faults, errors, and failures) chain and safety-related concepts
such as Accident, Safety Incident, Hazard, Environmental or operational
conditions (Context), Harm, Hazard Severity, and Probability, Risk, and
Safety Functional Requirement.
We also presented the safety and hazard analysis method, which has four
steps: 1- Hazards Identification, 2- Hazards Evaluation, 3- Risk Analysis,
and 4- Safety-Related Requirements Specification by presenting examples
of methods and techniques that could be used in these steps.
From the safety analysis results, safety requirements are derived, and
they should be incorporated in the system design before implementation,
aiming to develop safer systems by reducing the occurrence of hazards from
the beginning of the system development process. Such an approach of
integrating requirements and safety engineering highlights the relationship
between these two areas.
 References 21

Acknowledgments
We would like to thank Universidade Federal of Pernambuco (UFPE), Brazil.

References
[1] N. Leveson. Engineering a safer world: Systems thinking applied to
safety. Mit Press, 2011.
[2] J. Vilela, J. Castro, L. E. G. Martins, T. Gorschek. Safety Practices
in Requirements Engineering: The Uni-REPM Safety Module. IEEE
Transactions on Software Engineering, 2018.
[3] A. Avizienis, J. C. Laprie, B. Randell. Fundamental concepts of
dependability. University of Newcastle upon Tyne, Computing Science,
2001, pp. 7-12.
[4] S. Bernardi, J. Merseguer, and D. Petriu. Model-driven dependability
assessment of software systems. Heidelberg: Springer, 2013.
[5] K. Allenby, T. Kelly. Deriving safety requirements using scenarios.
In: Proceedings Fifth IEEE International Symposium on Requirements
Engineering, 2001, pp. 228-235.
[6] G. Booch. The unified modeling language user guide. Pearson
Education India, 2005.
[7] J. Vilela, J. Castro, L. E. G. Martins, T. Gorschek, C. Silva. Specifying
Safety Requirements with GORE languages. In: Proceedings of the 31st
Brazilian Symposium on Software Engineering, 2017, pp. 154-163.
[8] L. E. G Martins, T. A. Oliveira. A case study using a protocol to derive
safety functional requirements from fault tree analysis. In: International
Requirements Engineering Conference (RE), 2014, pp. 412-419.
[9] I. Sommerville. Software engineering 9th Edition, 2011.
[10] J. Vilela, J. Castro, L. E. G. Martins, T. Gorschek Safe-RE: a
safety requirements metamodel based on industry safety standards.
In: Proceedings of the XXXII Brazilian Symposium on Software
Engineering, 2018, pp. 196-201.
[11] IEC-International Electrotechnical Commission. IEC 61882, 2001.
[12] D. Firesmith. Engineering safety-related requirements for software-
intensive systems. In Proceedings of 27th International Conference on
Software Engineering, 2005, pp. 720-721.
[13] D. Dermeval, J. Vilela, I. I. Bittencourt, J. Castro, S. Isotani, P.
Brito, and A. Silva; Applications of ontologies in requirements
engineering: a systematic review of the literature. In:Requirements
Engineering Journal, 21(4), 2016, pp.405-437.
22 The Role of the Safety and Hazard Analysis

[14] L. Provenzano, K. Hänninen, J. Zhou, and K. Lundqvist. An Ontological

Approach to Elicit Safety Requirements. In: 24th Asia-Pacific Software
Engineering Conference (APSEC), 2017, pp. 713-718.
[15] J. Zhou, K. Hänninen, K. Lundqvist, Y. Lu, L. Provenzano,
and K. Forsberg. An environment-driven ontological approach to
requirements elicitation for safety-critical systems. In 23rd International
Requirements Engineering Conference (RE), 2015, pp. 247-251.
[16] K. Thramboulidis and S. Scholz. Integrating the 3+ 1 SysML view
model with safety engineering. In 2010 IEEE 15th Conference on
Emerging Technologies & Factory Automation (ETFA 2010), pp. 1-8.
[17] R. Fu, X. Bao, and T. Zhao. Generic safety requirements description
templates for the embedded software. In 2017 IEEE 9th International
Conference on Communication Software and Networks (ICCSN), 2017,
pp. 1477-1481.
 3
Integrating New and Traditional Approaches
of Safety Analysis

L. E. G. Martins

Department of Science and Technology, Federal University of São Paulo, São

José dos Campos, Brazil
E-mail: [email protected]

Abstract
Traditional approaches as FMEA and FTA still are very used during
the process of safety analysis. Practitioners are used with them, and
they are resistant to move to new approaches. However, traditional
approaches are no longer sufficient to deal with the increasing complexity
of safety-critical systems. New approaches are needed; STAMP/STPA is
emerging as a promising approach. In this chapter, we discuss integration
possibilities between new and traditional safety analysis approaches. We
briefly present FMEA and FTA as representative of traditional approaches;
and STAMP/STPA as representative of a new safety analysis approach. We do
an exercise of mapping FMEA and STPA steps and try to identify possibilities
to use both approaches in a complementary way.

Keywords: Safety Analysis, Safety Requirements, FMEA, STAMP.

3.1 Introduction
Safety-Critical Systems (SCS) are increasingly present in the daily lives of
modern societies, which are becoming heavily dependent on these systems.
SCS are technology-based man-made systems where any defects or failures
may lead to accidents that endanger human life or damage the environment

23
24 Integrating New and Traditional Approaches of Safety Analysis

or property [9–11]. SCS are present in avionic systems, automotive systems,

industrial plant control (chemical, oil & gas, nuclear), medical devices,
railroad control, defense, and aerospace systems, among others [10, 12].
In this chapter, we discuss integration possibilities between new and
traditional safety analysis approaches. We briefly present FMEA and FTA as
representative of traditional approaches; and STAMP/STPA as representative
of a new safety analysis approach. This chapter is organized as follows:
Section 3.2 presents background and related work, in section 3.3 we briefly
describe FMEA and FTA, in section 3.4 we briefly describe STAMP/STPA,
in section 3.5 we present some ideas of how FMEA and STPA may be used
in an integrated way, and in section 3.6 we conclude the chapter.

3.2 Background and Related Work

In this section, we present a background related to safety analysis. To help
the reader, we provide definitions for some terms and expressions used along
with this chapter. A brief discussion of related work to the integration of new
and traditional approaches of safety analysis is provided in section 2.2.

3.2.1 Background
In order to help the reader better understand the discussion along with this
chapter and make clear the adopted terms, we provide definitions for some
terms and expressions related to safety analysis in the context of requirements
engineering and safety-critical systems. We present the following definitions
[8], organized in alphabetical order:
• Accident. An undesirable (negative) event involving damage, loss,
suffering, or death [5, 6].
• Approach. In the context of this chapter, we are interested in the
following types of approaches: technique, model, framework, method,
process, methodology, or tool to elicit, model, specify or validate
hazards and safety requirements for safety-critical systems.
• Functional Safety Requirement. The requirement to prevent or
mitigate the effects of failures identified in safety analysis [4].
• Hazard. A system state that might, under certain environmental
conditions, lead to a mishap. Hence, a hazard is a potentially dangerous
situation that may lead to an accident [2, 5].
• Safety. Firesmith defines safety as “the degree to which accidental
harm is properly addressed (e.g., prevented, identified, reacted to, and
 3.2 Background and Related Work 25

adapted to)” [3]. According to Leveson, “safety must be defined in terms

of hazards or states of the system that when combined with certain
environmental conditions could lead to a mishap.” [5, 7]
• Safety Analysis. A systematic analysis of the architecture, design,
installation, and operation of the system to ensure that safety
requirements are met. During this analysis process, all hazards and their
effects on the system should be addressed [18].
• Safety Requirement. A requirement that describes the constraints
or actions to support and improve system safety. Firesmith defines
the safety requirement as “any quality requirement that specifies a
minimum, mandatory amount of safety in terms of a system-specific
quality criterion and a minimum level of an associated metric.” [3]
• Safety-Critical. According to Medikonda and Panchumarthy, “those
software or system operations that, if not performed, performed out
of sequence, or performed incorrectly could result in improper control
functions, or lack of control functions required for proper system
operation, that could directly or indirectly cause or allow a hazardous
condition to exist” [3].

3.2.2 Related Work

Sulaman et al. [20] performed a case study making a qualitative comparison
between FMEA and STPA. Both methods were applied to the same forward
collision avoidance system to compare the effectiveness of the methods and
to investigate what are the main differences between them. The main results
from this case study are the following [20]:
• Almost all types of hazards that were identified in the study were found
by both methods;
• Both methods found hazards classified as component interaction,
software, component failure, and system type;
• With regard to component failure hazards, FMEA identified more
component failure hazards than STPA;
• With regard to software error type hazards, STPA found more hazards
than FMEA unique hazards;
• With regard to component interaction error type hazards, STPA found
some hazards; however, FMEA did not find any unique hazards;
• With regard to system type error hazards, FMEA found slightly more
hazards than STPA;
Other documents randomly have
different content
aimée, par un personnage, sans doute un peu nouveau, mais dont le
monde déjà semblait subir l'ascendant et présager les hautes
destinées.
Elle voulait exhiber à ses rivales son amoureux Bonaparte,
comme une parure inédite, comme un bijou un peu sauvage, mais
précieux, et il ne lui déplaisait pas de dire à Barras, en feignant de le
consulter, que son collègue au commandement de l'armée intérieure,
son second dans la journée de vendémiaire, dont l'épée victorieuse
pouvait peser autant que son sabre de parade dans la balance de
l'avenir, la trouvait adorable et n'avait pas la sottise de lui préférer
quelque impure aux charmes avilis.
Était-ce coquetterie, regrets ou ironie? Joséphine n'a pas été
historiquement la maîtresse de Barras. Elle fut dans la réalité des
boudoirs restaurés, dans le décor poétique des sylphides et des
nymphes diaphanes peintes par Prud'hon, la sultane d'une heure de
Barras, démocrate pacha à la face brutale de soudard, aux
prétentions élégantes d'un roué de la Régence.
Aucune femme ne lui résistait, à ce casse-cœur qui était un
casse-cou. Sa vie avait été pleine d'aventures amoureuses. Ce
révolutionnaire était un aristocrate de naissance, talon et bonnet
rouges, le comte Paul de Barras, s'il vous plaît! Méridional, cela va
sans dire, étant né à Fox-Emphoux, dans le Var, capitaine aux
armées du roi, membre de la Convention, régicide, président de la
redoutable assemblée, investi du commandement suprême au 9
thermidor et au 13 vendémiaire, il avait été élu membre du
Directoire, le dernier par 129 voix sur 218 votants. On sait que le
Directoire était composé de 5 membres nommés par le Conseil des
Anciens sur une liste de 50 membres présentés par l'Assemblée des
Cinq-Cents. Ses collègues étaient Larévellière-Lépeaux, élu par 216
voix, Rewbell, Letourneur et Carnot. Le dernier de tous, Barras,
s'était imposé et gouvernait réellement le Directoire. Il était grand,
robuste, avec l'aspect d'un Fanfan-la-Tulipe parvenu aux honneurs; il
conservait, sous le fastueux manteau directorial, ses mœurs et ses
allures de don Juan de caserne. Ses collègues laborieux comme
Letourneur, austères comme Carnot et Rewbell, enthousiastes,
honnêtes, mais peu décoratifs comme le difforme Larévellière-
Lépeaux, ne représentaient pas le pouvoir brillant, théâtral, cabotin
même, si l'on peut employer ce vocable alors inconnu, tel que le
voulaient les Français de l'an III, las de la liberté, regrettant les
plaisirs, l'insouciance, le laisser-aller des mœurs et la pompeuse
allure de l'ancien régime.
Barras, par sa prestance, par la façon dont il portait la tête au
milieu des solliciteurs de tout rang et de toute origine, par le geste
dont il soulevait son chapeau à triple plume blanche, par la
soldatesque nonchalance avec laquelle il laissait traîner sur les
parquets du Luxembourg son sabre courbé au fourreau de vermeil,
personnifiait admirablement, pour la foule redevenue servile, la
majesté royale rétablie sans la monarchie. Ce Louis XIV de corps de
garde était le roi de la République. Tout le servait. Ses vices surtout.
Ses maîtresses formaient la garde de son pouvoir joyeux. Il rassurait
par les fêtes qu'il donnait. Le peuple ne songeait pas à reprocher à
ce jouisseur ses jouissances. On sortait d'une bataille terrible, d'un
carême effrayant: à tous les rangs de la société, un seul régime
apparaissait désirable, celui qui permettrait de vivre en paix et de
faire tous les jours Mardi-Gras.
La guillotine, les fêtes affreuses de la rue, les hommes en bonnet
rouge et en carmagnole, les furies de la guillotine coiffées du madras
évoquant la face hideuse de Marat, le luxe proscrit, l'amour suspect,
l'art réfugié à l'étranger, tout cela n'était plus qu'un cauchemar. On
s'éveillait dans la joie, dans l'ivresse; on se reprenait à des plaisirs
brusquement ranimés, on se retrouvait à table entre échappés de la
charrette. Les dîners, les parties de campagne, les vins débouchés
au milieu de gais compagnons et de jolies filles décolletées, les roses
dont on jonchait les nappes et les surtouts, les équipages qui
semblaient revenir des écuries de Pluton, les convives dont
beaucoup, comme Lazare, sortaient réellement du tombeau,
donnaient à cette époque étrange, bigarrée, puissante, une couleur
et une outrance que jamais plus les âges pacifiés ne reverront.
 Il la personnifiait superbement dans ses folies, dans ses passions,
dans ses forces aussi, cette transitoire période du Directoire, le
voluptueux et intelligent Barras.
Il avait rétabli l'ordre dans la rue, et le plaisir dans la société.
Quoi d'étonnant que toutes les femmes fussent folles de lui? Avec
cela, très dépensier: comme il jetait l'or sur les tables de brelan du
Palais-Royal, il lançait par poignées les louis aux jeunes beautés
attirées, phalènes vénales, par le flamboiement de cet astre
nouveau. La Cabarrus était l'odalisque favorite. Cette intrigante
courtisane qui repoussa, n'ayant plus besoin de lui, l'odieux Tallien,
n'est pas seulement maîtresse en titre, elle est aussi la complice de
Barras. C'est elle le grand agent de corruption sociale. Son rôle est
celui d'une magnifique proxénète. Elle aide le sybarite directeur à
enterrer la Révolution sous les fleurs et à faire succéder l'orgie
crapuleuse à la débauche sanglante. La Révolution, où les frères
s'entre-dévorèrent, fut un repas des Atrides: la Cabarrus avec Barras
en fit un festin de Trimalcion.
Une soirée chez Barras rassemblait tout ce que la société d'alors
comportait d'élégances, de distinction, de vice, de vertu, de gloire.
Les jeunes généraux, les vieux parlementaires, les femmes qui
portaient en breloques une boucle de leur fiancé, de leurs frères, ou
de leur premier amant, coupée sur la tête chérie au moment où
Samson allait s'en emparer, les fournisseurs plus cousus d'or que les
fermiers généraux de jadis, les muscadins aux amples cravates de
mousseline, les madame Angot toutes ruisselantes de bijouterie, les
savants, les écrivains Monge, Laplace, Volney, se pressaient dans les
salons du Luxembourg, heureux de survivre, désireux de rattraper
les heures perdues, insoucieux de l'avenir, se disant avec un sourire
sceptique: «Pourvu que ça dure!» Dans l'ombre Talleyrand, revenu
d'Amérique, ricanait et couvait cette société en décomposition,
comme un vautour planant sur un charnier.
Quand Joséphine eut fait prévenir Barras quelle désirait
l'entretenir en particulier, on la conduisit dans un petit salon attenant
au cabinet du directeur.
 Elle attendit quelques instants. La cloison était légère: un bruit de
voix s'élevait de la pièce voisine; elle entendit la fin d'une discussion.
—Pourquoi soupçonnes-tu Bonaparte? disait Barras dont
Joséphine reconnut le verbe sonore, c'est un homme pur d'argent,
comme il nous en faut...
—Je le crois ambitieux, répondit la personne avec qui
s'entretenait Barras.
—Ne l'es-tu pas, toi, Carnot? reprit le directeur... Sois donc franc:
tu es jaloux de Bonaparte! les plans qu'il a combinés pour l'armée
d'Italie, tu les as anéantis sans les soumettre au Directoire, craignant
que la gloire t'échappât du triomphe de nos armes!
—Je n'ai pas connu ces plans, répondit le directeur Carnot. Je les
ignorais... Je jure que cela n'est pas vrai...
—Ne lève pas la main! dit brutalement Barras. Il en dégoutterait
du sang!...
—Tu me reproches, toi aussi, dit Carnot avec âpreté, d'avoir signé
des arrêts de mort?
—Tous les arrêts de mort... oui, tu les as tous signés avec
Robespierre...
—Je les ai signés sans les lire, comme Robespierre signait mes
plans d'attaque sans même y jeter les yeux... nous avons servi la
Révolution chacun de notre côté... la postérité nous jugera!...
—Va-t'en, buveur de sang! cria Barras.
—Adieu, toi qui te grises d'or et de volupté! répondit Carnot. Je
te le répète: je crains l'ambition de Bonaparte, mais je ne m'oppose
nullement à ce que tu le nommes général en Italie!... Après tout, lui
aussi fut un terroriste, un protégé des Jacobins, un régicide comme
toi et moi... récompense-le, c'est ton affaire! Mais ne crois pas qu'il
ait d'aussi vertueux desseins que tu le supposes... Le 13
vendémiaire, ce n'est pas Rome qu'il a sauvée, c'est Byzance!...
 Et l'ancien membre du Comité de Salut public sortit en faisant
claquer la porte avec violence.
Barras, soulevant une portière, se présenta souriant à Joséphine
et lui dit:
—Quelle heureuse circonstance vous fait, belle vicomtesse, vous
tenir à l'écart de la fête, et qui me vaut l'agréable surprise de cet
entretien particulier?
Barras, au fond, était inquiet. Il n'avait pas dédaigné les faveurs
passagères de la séduisante créole, mais il ne tenait nullement à
renouer des relations qui, de part et d'autre, n'avaient eu qu'un
caractère occasionnel et capricieux. Joséphine, très à court d'argent,
sans appui, sans relations, avait été heureuse de s'attacher un
instant l'homme qui avait vaincu Thermidor, un ci-devant noble,
généreux, aimable, et qui pouvait lui servir, sinon de protecteur en
titre, du moins de caution dans les circonstances difficiles. Lui, de
son côté, impatient de renouer les traditions de l'ancien régime,
avait été flatté d'une conquête d'origine aristocratique, la veuve d'un
président de la Constituante, général en chef de la glorieuse armée
du Rhin. Mais il n'était resté entre eux que des souvenirs d'une
liaison agréable, et la saveur de voluptés rapidement écoulées.
Joséphine, un peu troublée, lui confessa l'objet de ses
démarches:
—On veut que je me remarie, mon cher directeur... Qu'en
pensez-vous?
—Mais je pense que vous ferez un heureux... Puis-je savoir quel
est l'homme sur lequel vous avez jeté les yeux?
—Vous le connaissez, Barras!... c'est le général Vendémiaire, dit
en souriant Joséphine.
—Bonaparte? Un garçon d'avenir... un artilleur de premier ordre...
Si vous l'aviez vu comme moi à cheval, dans le cul-de-sac Dauphin,
braquant ses canons contre les sectionnaires sur les marches de
Saint-Roch, vous seriez persuadée qu'un homme aussi brave ne peut
faire qu'un excellent mari... Oh! il est intrépide!... j'étais à côté de
lui, et les sectionnaires faisaient un feu du diable, dit Barras en
manière d'aparté.
—Il est bon, fit Joséphine... Il veut servir de père aux orphelins
d'Alexandre de Beauharnais et de mari à sa veuve.
—C'est très louable, mais l'aimez-vous?
—Je serai franche avec vous, Barras; non, je ne l'aime pas...
d'amour...
—Auriez-vous de l'éloignement pour lui?... Dame, il ne paie pas
de mine...
—Je n'ai pour lui ni répugnance, ni désir... je me trouve dans un
état de tiédeur qui me déplaît... C'est ce que les dévots,—vous savez
qu'à la Martinique, mon pays, on est fort attaché à la religion,—
trouvent l'état le plus fâcheux pour l'âme...
—Il s'agit aussi du corps, lorsqu'on parle du mariage...
—L'amour est un culte aussi, Barras! Il exige la foi... on a besoin
de conseils, d'exhortations pour croire, pour être fervente... voilà
pourquoi je réclame vos conseils. Prendre une résolution a toujours
paru fatigant à ma nature nonchalante... J'ai, toute ma vie, trouvé
plus commode de suivre la volonté des autres...
—Alors, il faut que je vous ordonne d'épouser le général?
—Conseillez-le-moi seulement... J'admire le courage de
Bonaparte... Il a sauvé la société au 13 vendémiaire...
—Il a protégé la Convention, abattu les factieux qui voulaient
renverser la République et gagné à lui seul, dans Paris, une bataille
de rues qui vaut toutes les batailles rangées...
—C'est un homme supérieur... J'apprécie l'étendue de ses
connaissances en toutes choses dont il parle généralement bien, la
vivacité de son esprit qui lui fait comprendre la pensée des autres
presque avant qu'elle ait été exprimée; mais je suis effrayée, je
l'avoue, de l'empire qu'il semble vouloir exercer sur tout ce qui
l'entoure...
—Il a l'œil dominateur, en effet! La première fois que je l'ai vu,
dit Barras avec gravité, je fus étrangement surpris à son aspect.
J'aperçus un homme au-dessous de la taille ordinaire, d'une extrême
maigreur... On aurait dit un ascète échappé des solitudes... ses
cheveux coupés d'une façon particulière, encadrant ses oreilles,
tombaient sur ses épaules... Oh! ce n'est pas un de nos muguets de
la jeunesse dorée! Il était vêtu d'un habit droit, boutonné jusqu'en
haut, orné d'une petite broderie en or très étroite; il portait à son
chapeau une plume tricolore... Au premier abord, sa figure ne me
parut pas belle, mais des traits prononcés, un œil vif et fouilleur, un
geste animé et brusque décelaient une âme ardente; son front large
et soucieux indiquait le penseur profond... Son parler était bref; il
s'exprime assez incorrectement... mais, s'il ne cherche la correction,
à tous moments il trouve le sublime... C'est un homme, Joséphine!
un homme intègre, un vaillant qui sera peut-être demain un héros!...
Puisqu'il veut de vous, prenez-le... C'est un conseil d'ami que je vous
donne... de bon ami, croyez-le!...
—Alors, vous m'engagez à devenir sa femme...
—Oui... et, avec le temps, vous l'aimerez...
—Vous croyez?... J'ai un peu peur de lui....
—Vous n'êtes pas la seule!... tous mes collègues le redoutent...
Carnot, un terroriste, un buveur de sang, un complice de
Robespierre pourtant, le déteste, parce qu'il en est jaloux et qu'il le
craint...
—S'il intimide les directeurs, jugez l'impression qu'il doit faire sur
une femme!...
—Vous vous y habituerez... d'ailleurs, il vous aime, m'avez-vous
dit?...
—Je crois qu'il est fort amoureux de moi, mais, Barras, entre
amis, on peut se faire de telles confidences, ayant passé la première
jeunesse, puis-je espérer conserver longtemps cette tendresse
violente qui, chez le général, ressemble à un accès de délire!...
—Ne vous inquiétez pas de l'avenir...
—Si, lorsque nous serons unis, il venait à cesser de m'aimer, ne
me reprochera-t-il pas sa faiblesse, son abandon?... Il se repentira
de l'illusion subie. Il cuvera l'amertume de l'ivresse dissipée. Ne
regrettera-t-il pas un mariage plus brillant, avec une femme plus
jeune, qu'il aurait pu contracter! Que répondrai-je alors? que ferai-
je?... je pleurerai... Autant m'éviter les larmes...
—Ne prévoyez donc pas ainsi les malheurs... On souffre à
devancer les misères!... Bonaparte est un gaillard voué au bonheur...
Êtes-vous superstitieuse? Il m'a confié qu'il avait une étoile, et qu'il y
croyait...
—Moi, à la Martinique, une négresse qui pratiquait les
enchantements, et dont les prophéties locales se sont toutes
réalisées, m'a prédit que je porterais un jour une couronne de
reine... Je ne vois pas bien Bonaparte roi et moi partageant son
trône...
—Vous pourrez partager avec lui la gloire qui couronnera le
commandant en chef de la plus belle armée de la République.
—Que voulez-vous dire, mon cher Barras? demanda Joséphine
surprise, se souvenant de l'altercation avec Carnot qu'elle avait
entendue, et dont le général Bonaparte faisait l'objet.
—Je veux dire que vous serez la plus heureuse des femmes,
comme vous êtes l'une des plus belles reines de beauté de notre
République, si vous épousez Bonaparte... et comme cadeau de
noces, moi, votre vieil ami, reconnaissant aussi envers le général qui
m'a si bien mitraillé les insurgés des sections, je mettrai dans votre
corbeille un joli bijou...
—Vraiment!... quoi donc? une agrafe d'or avec des diamants,
comme en porte la belle madame Tallien?...
 —Mieux que cela... le commandement en chef de l'armée
d'Italie!... Mais on doit s'étonner de mon absence de la fête, dit
Barras jouissant de l'étonnement de Joséphine, prenez mon bras et
rentrons dans les salons... Je veux être le premier à féliciter
Bonaparte sur son mariage et sur son nouveau commandement!...
Et, entraînant la veuve Beauharnais, tout étonnée de la décision
qui lui était imposée et de la faveur inestimable que le tout-puissant
directeur accordait à son futur époux, Barras fit sa rentrée
majestueuse dans les salons ruisselants de lumières, de fleurs, de
femmes, au bras de son ancienne maîtresse qui allait s'appeler
madame Bonaparte.

XXV

LE SABRE DES PYRAMIDES

Bonaparte fut nommé, le 23 février 1796, général en chef de

l'armée d'Italie. Carnot s'était rallié à l'avis de Barras. Rewbell seul y
fit opposition, mais ses collègues passèrent outre.
Le 9 mars, c'est-à-dire quelques jours après, le mariage du
général et de la veuve Beauharnais fut célébré.
Il est à présumer qu'il avait été consommé auparavant.
Toute cette période de la vie de Bonaparte n'est qu'une fièvre
d'amour.
On le vit littéralement à l'adoration de sa Joséphine. Prosterné,
extasié, anéanti devant la crèche comme un carmélite, en face de ce
saint-sacrement.
Il l'accablait de ses caresses, il l'étreignait furieusement, il se
ruait sur elle et l'emportait, comme un fauve sa proie, dans l'alcôve
saccagée. Tel qu'un barbare au pillage, il se jetait sur ces voiles
légers dont Joséphine, en souvenir des tropicales soirées, se plaisait
à envelopper ses charmes. Il arrachait, déchirait, décousait, mettait
en lambeaux tout ce qui faisait obstacle à l'impétuosité de ses mains
frémissantes, de ses lèvres avides. Toute l'exubérance de sa nature
exceptionnelle éclatait dans cette prise de possession brutale comme
une charge de cavalerie. Il aimait, il prenait une femme pour la
première fois, ou à peu près, et ses réserves de passions
accumulées dévalaient comme un torrent, se précipitaient avec la
violence d'un fleuve longtemps retenu, les vannes levées. Dans cette
expansion vigoureuse, dans cet assouvissement de la chair à jeun,
dans cette jouissance double où l'amour-propre satisfait, la vanité
flattée, la joie du but atteint, le rêve accompli mêlaient leurs
ivresses, Bonaparte en oubliait le rut de la guerre, de la gloire, de la
puissance dont ses nerfs furent toute sa vie surexcités. Ce n'était
plus le même homme. Il tremblait, il balbutiait, il riait, il pleurait. Il y
eut dans cette prise de possession de Joséphine de la folie et de
l'intoxication.
La célébration du mariage fut la fin de cette lune de miel si
courte.
Deux jours après la cérémonie officielle, il se mettait en route
pour l'Italie. Il était désormais sur la route de la gloire et ne
s'arrêterait plus à l'hôtellerie de l'amour, qu'en passant, entre deux
victoires, jusqu'au jour où la fatalité le ferait trébucher contre le lit
éblouissant de l'archiduchesse Marie-Louise d'Autriche.
Dans l'acte de mariage, Bonaparte par galanterie, pour
rapprocher les distances d'âge, s'était vieilli de deux ans, et, par
coquetterie, Joséphine, par un certificat de nativité, à défaut d'acte
de naissance régulier, s'était rajeunie de quatre ans. Cette
supercherie d'une jolie femme, désireuse de ne pas paraître trop
âgée auprès d'un jeune époux, devait avoir de terribles
conséquences pour Joséphine, à l'époque du divorce, au moins sous
le rapport de la légalité de cette procédure.
 Bonaparte emporta sa fièvre passionnelle en courant vers cette
Italie, où les triomphes les plus prodigieux l'attendaient.
Il ne laissait passer aucune journée sans adresser à sa Joséphine
des épîtres amoureuses, un peu emphatiques de ton, où l'on
retrouvait l'éloquence et la pompe de Saint-Preux écrivant à Julie.
Harassé de travaux, las de veiller, à peine descendu de cheval après
avoir parcouru les positions où le lendemain il battrait l'ennemi, le
jeune général, au milieu de préoccupations et de dangers qui se
multipliaient, ne manquait jamais de jeter sur le papier des phrases
embrasées, témoignant de l'intensité de son amour, qu'un courrier,
galopant nuit et jour, portait aussitôt à Paris avec le bulletin de la
bataille gagnée la veille et l'annonce des drapeaux pris à l'ennemi
qu'un aide de camp déposerait sur l'autel de la Patrie, dans une
cérémonie magnifique présidée par les directeurs.
Et cette fête de la Victoire qu'il organisait de sa tente dressée sur
le plateau de Rivoli, cette journée de patriotiques réjouissances qu'il
donnait à Paris, quand son ami Junot se présenta à la Convention
porteur des étendards autrichiens, c'était pour sa Joséphine que
l'idée, un peu théâtrale, lui en était venue.
Elle fut la reine de la France, ce jour-là, l'insignifiante et sensuelle
créole. Devant les troupes, en face de tout le peuple rassemblé, au
son du canon et des cloches, clamant à la cité en liesse l'alleluia de
la victoire, elle parada au bras de Junot, en qui l'on saluait le
représentant, l'ami, le compagnon du héros dont le nom montait
vers le ciel, proféré par cent mille bouches en délire.
Carnot debout, au centre de l'autel du Champ de Mars,
prononçait une harangue où le jeune général victorieux était
comparé à Epaminondas et à Miltiade. Lebrun, poète officiel,
dirigeait un chœur chantant cet hymne de circonstance:
Enivrons-nous, amis, aux coupes de la gloire.
Sous des lauriers, que Bacchus a d'attraits!
Buvons, buvons à la victoire,
Fidèle amante des Français!
 Tout Paris se montrait alors la citoyenne Bonaparte et son époux,
à distance, en donnant l'ordre de marcher sur Mantoue et de la
prendre, jouissait du triomphe qu'il lui avait préparé.
Joséphine cependant, le soir même de cette apothéose où elle
avait figuré en déesse, ayant congédié un acteur subalterne qui
l'occupait depuis quelque temps, couchait avec un joli sous-
lieutenant de hussards, M. Charles, auquel elle donnait ce que les
fournisseurs, les usuriers, les marchandes à la toilette, lui laissaient
de l'argent, qu'en se privant, lui envoyait Bonaparte. C'était sa façon
à elle de récompenser l'armée.
Non seulement Joséphine trompait ce jeune mari si ardent, si
glorieux, si convoité par toutes les femmes, qu'elle n'aimait pas,
mais elle ne feignait même pas d'avoir pour lui les égards que la
simple convenance exigeait. Elle se refusa longtemps à se rendre en
Italie où il l'appelait de tous ses désirs. Bonaparte, à la pensée
surexcitée par la privation, en arrivait aux plus folles divagations: il
parlait d'abandonner son commandement, de donner sa démission
et d'accourir à Paris, auprès de sa Joséphine, si elle ne se décidait à
venir le rejoindre.
Elle consentit enfin, le cœur gros, à quitter ce Paris qui lui tenait
tant au cœur, et à se mettre en route. Dans ses bagages, elle
emmenait le beau Charles.
Lorsque, dans la suite de ce récit (La Maréchale), nous parlerons
du divorce de Napoléon, nous reviendrons sur ces épisodes de la
trahison continuelle de cette gourgandine couronnée sur laquelle
romanciers, dramaturges, poètes, trompant la postérité, ont apitoyé
l'âme populaire.
Napoléon n'a pas été trahi que par les maréchaux qu'il avait
gorgés d'honneurs, engraissés de dotations. Les deux femmes qu'il
avait appelées à partager la gloire de son nom, furent deux infâmes
coquines; même la bestiale fille d'empereur, cette Marie-Louise,
archiduchesse toujours en chasse, est-elle plus excusable? Elle
n'était pas tirée des boudoirs équivoques de la galanterie
directoriale, et l'on ne pouvait exiger d'elle de la reconnaissance pour
le soldat couronné qui l'avait conquise l'épée à la main, et était entré
dans son lit en vainqueur, comme dans une capitale rendue.
Après la campagne d'Italie, les préliminaires de Léoben, le traité
de Campo-Formio, Bonaparte, à la fois triomphateur et pacificateur,
se retrouva hanté des visions de l'Orient.
Ce n'était plus alors l'aiguillon de la misère, l'ambition, la vague
convoitise d'une femme ardente et cupide de tout ce qui pouvait
s'acquérir, se prendre, se tenir dans des mains rapaces et solides
comme des serres, dont il se sentait pressé. L'Orient n'était pas
seulement pour lui un paradis de conquêtes et de gloire qu'il
entrevoyait dans les fumées de son rêve éveillé. C'était aussi un
port, un abri.
Revenu à Paris le 5 décembre 1797, après les ratifications du
traité de Campo-Formio, et la signature de la convention militaire qui
remettait à la France Mayence et Manheim, c'est-à-dire le Rhin, il
n'avait pas tardé, dans son petit hôtel de la rue Chantereine,
flatteusement débaptisée et devenue rue de la Victoire, à connaître
les dangers de la popularité et les périls d'une situation
exceptionnelle dans la République.
Il dut tout d'abord assister à des fêtes célébrées en l'honneur des
armées victorieuses. Il en fut le héros. On ne voyait que lui parmi
l'éclat frissonnant des drapeaux, et son nom résonnait dans toutes
les bouches. Barras, Talleyrand, qui déjà s'essayait au métier de
traître, le louangèrent solennellement. Bonaparte répondit en termes
vagues. De son remerciement une seule phrase sortait claire,
presque menaçante: «Lorsque le bonheur du peuple français sera
assis sur de meilleures lois organiques, l'Europe entière deviendra
libre» dit-il avec énergie. Un orage était ainsi prophétisé. Le coup de
foudre du 18 brumaire s'annonçait sourdement, sous cette phrase
grosse de tempêtes.
Bonaparte cherchait alors à se dérober aux ovations qui le
poursuivaient. Carnot, proscrit après Fructidor, avait laissé une place
vacante à l'Institut. Elle lui fut offerte et depuis, dans les cérémonies
publiques, il affecta de se montrer vêtu du modeste habit à palmes
vertes. Sous cette livrée de la science, il semblait moins un soldat
vainqueur, qu'un laborieux serviteur de l'idée.
On avait proposé de lui donner le château de Chambord, cette
merveille de l'art de la Renaissance, à titre de donation nationale. Il
refusa. Il déclina également toutes distinctions qui lui furent offertes.
Il ne voulut accepter que le titre de général en chef de l'armée
d'Angleterre.
Il préparait avec certain fracas un projet de descente en Grande-
Bretagne. En réalité, il étudiait le moyen de frapper l'implacable
ennemi de la France et de la Révolution, là où surtout elle était
vulnérable: dans ses colonies. L'Egypte le tentait. Il résolut d'y
entraîner ses compagnons d'armes. Il y avait sur les bords du Nil des
lauriers inattendus à récolter. Il reviendrait de ce fabuleux pays avec
un prestige éblouissant. Le plan gigantesque et chimérique se
développait dans son cerveau bouillonnant de conquérir non
seulement l'Egypte, mais la Syrie, la Palestine, la Turquie, d'entrer,
comme un chef de croisés, dans Constantinople, et là, de prendre
l'Europe à revers, poussant les vagues de son armée, grossies de
fellahs, de Bédouins, de Druses, de Turcs et des peuplades attirées
de l'Asie Mineure; il battait toutes les armes, il reformait la carte du
monde et sous son épée triomphale courbait tous les souverains et
toutes les nations.
Bonaparte s'emballait ainsi, devant les plans et les cartes
concernant l'Egypte, dans ses fantastiques rêveries d'immense
empire occidental. En même temps, sa froide raison lui conseillait
une absence. Il n'était pas fâché de prouver que, lui parti, le
Directoire ne pouvait commettre que des fautes, les généraux ne
connaître que les défaites. Son besoin d'activité le stimulait à
chercher de nouvelles occasions de gloire. Il se rendait compte aussi
que le peuple est mobile, et qu'il se lasse bien vite d'encenser une
idole: «On ne m'aura pas vu trois fois en spectacle, disait-il, qu'on ne
me regardera plus.»
 Une sourde conspiration le décida à brusquer son départ. La
jalousie des directeurs s'était allumée. Déjà Rewbell, un honnête
homme mais un parfait imbécile, lui avait tendu la plume, un jour
qu'il parlait de donner sa démission, pour qu'il la signât. On
cherchait vaguement à le mettre en accusation sous un prétexte de
concussion, à propos de sommes touchées en Italie. Le Directoire
feignait d'oublier qu'il avait poussé le général à tirer de l'Italie des
sommes en argent, des tableaux, des statues, du butin de toute
nature, et que chaque mois le victorieux Bonaparte faisait passer à
Moreau et à ses autres collègues moins heureux de l'armée du Rhin,
des subsides leur servant à régler les soldes en retard.
Le 19 mai 1798, il s'embarquait à Toulon. Avant de prendre la
mer, il adressa à ses troupes une proclamation vibrante d'espoir, où
miroitait la splendeur de la terre promise:
«Soldats, apprenez que vous n'avez pas encore assez fait pour la
patrie, et que la patrie n'a pas encore assez fait pour vous. Je vais
vous mener dans un pays où, par vos exploits futurs, vous
surpasserez ceux qui étonnent aujourd'hui vos admirateurs, et
rendrez à la patrie les services qu'elle a droit d'attendre d'une armée
d'invincibles. Je promets à chaque soldat, qu'au retour de cette
expédition, il aura à sa disposition de quoi acheter six arpents de
terre.»
La campagne d'Egypte, avec ses légendaires étapes,—les soldats
plaisamment demandèrent en foulant les sables du désert de Giseh
si c'était là que le général voulait leur distribuer les arpents de terre
promis,—ses victoires invraisemblables, ses désastres maritimes, sa
revanche terrestre d'Aboukir, furent comme un conte des Mille et une
Nuits dont le sultan public demeura charmé, impatient d'apprendre
la suite.
Le 15 octobre 1799, grande nouvelle: Bonaparte est débarqué à
Fréjus. Il se dirige vers Paris, escorté de l'acclamation des foules. Il
est le héros, le sauveur, le dieu. La France se donne à lui, dans un
rut formidable, comme une gouge pâmée tombant aux bras d'un
premier rôle, dans l'entr'acte du drame palpitant.
 Avait-il, en revenant ainsi précipitamment, le projet préconçu de
renverser le gouvernement et de substituer sa volonté à la
Constitution existante? Nullement. C'était un grand rêveur, Napoléon
Bonaparte. Il avait entrevu la possibilité d'un changement de régime
comme l'hypothèse de la reconstitution d'un empire carlovingien. Il
subordonnait aux événements la réalisation de ces utopiques
conceptions.
Le 18 brumaire a été commandé par l'opinion, exécuté par
Bonaparte. Le Directoire était discrédité; la France, lasse de cette
dictature de l'incapacité. Elle ne savait pas ce qu'elle voulait, mais
elle le voulait absolument. Si Bonaparte n'eût pas tenté le coup de
Brumaire, Augereau, Bernadotte ou Moreau l'eussent essayé.
Bonaparte avait groupé autour de lui tout un état-major brillant
et valeureux: Lannes, Murat, Berthier, Marmont, puis des légistes,
inclinant la jurisprudence devant la force comme Cambacérès, des
pêcheurs en eaux troubles comme Fouché et Talleyrand. Ses deux
frères, Lucien et Joseph, travaillaient activement pour lui, Lucien
surtout qui était membre des Cinq-Cents.
Le complot s'organisa sans grandes précautions.
Tout le monde en était, ou à peu près.
Le 18 brumaire,—9 novembre 1799,—à six heures du matin, tous
les généraux et officiers supérieurs, convoqués par Bonaparte, se
trouvaient rassemblés dans son hôtel de la rue de la Victoire, sous le
prétexte d'une revue à passer. Il y avait les six adjudants de la garde
nationale, et, à leur tête, Moreau, Macdonald, Murat, Sérurier,
Andréassy, Berthier, plus le prudent Bernadotte, seul en civil.
Un seul général important manquait. Bonaparte en fit la
remarque avec inquiétude:
—Où donc est Lefebvre? demanda-t-il à Marmont. Lefebvre ne
serait-il pas avec nous?...
Au même instant, on annonça le général Lefebvre.
Il avait fait du chemin, le mari de la Sans-Gêne.
 L'ancien garde-française, le lieutenant de la milice, le capitaine de
Verdun à l'armée du Nord, était devenu le général commandant la
17e division militaire, c'est-à-dire le gouverneur de Paris.
De capitaine au 13e d'infanterie légère à Jemmapes, il avait été
nommé chef de bataillon, chef de demi-brigade, puis général de
brigade à l'armée de la Moselle, sous les ordres de son ami Hoche.
Le 10 janvier 1794, il était promu général de division et
commandait l'immortelle armée de Sambre-et-Meuse, à la mort de
Hoche. A Fleurus, à Altenkirchen, il s'était comporté en héros.
Après avoir commandé l'armée du Danube, il avait été candidat
au Directoire, mais écarté à raison de ses opinions très républicaines
et de sa qualité de militaire.
Nommé au commandement en chef de l'armée de Paris, Lefebvre
était peut-être le général dont le concours se trouvait le plus
indispensable à la réussite des desseins de Bonaparte.
Il n'avait pas été averti des projets du futur maître de la France.
A minuit, ayant appris que des mouvements de troupes
s'opéraient, il était monté à cheval et avait parcouru la ville.
Surpris de voir sans son ordre de la cavalerie prête à se mettre
en route pour une destination inconnue, il avait interrogé
sévèrement le commandant: Sébastiani. Celui-ci l'avait renvoyé à
Bonaparte.
Lefebvre arrivait donc de fort méchante humeur chez le général.
Bonaparte, l'apercevant, courut à lui, les bras ouverts:
—Eh bien, mon vieux Lefebvre, lui cria-t-il familièrement,
comment cela va-t-il?... Et ta femme, la bonne Catherine? Toujours
le cœur sur la main et la réplique alerte, je suppose?... Madame
Bonaparte se plaint de ne pas la voir assez souvent...
—Ma femme se porte fort bien, je vous remercie, général, dit
Lefebvre, très froid, mais il ne s'agit pas d'elle pour le moment...
Bonaparte l'interrompit.
 —Voyons, Lefebvre, mon cher camarade, dit-il avec le ton
affectueux et l'air bon garçon qu'il savait prendre à l'occasion, vous,
l'un des soutiens de la République, la laisserez-vous périr entre les
mains de ces avocats?... Tenez, voilà le sabre que je portais aux
Pyramides, je vous le donne comme un gage de mon estime et de
ma confiance...
Et il tendit à Lefebvre, hésitant et flatté, un magnifique sabre, à
poignée ornée de pierreries, le cimeterre de Mourad-bey.
—Vous avez raison, dit Lefebvre subitement calmé, jetons les
avocats à la rivière!...
Et il ceignit le sabre des Pyramides.
Le 18 brumaire était accompli.
Le soir de cette journée décisive, qui changeait encore une fois la
destinée de la France, Lefebvre, embrassant Catherine, lui dit, tirant
à demi du fourreau le don de Bonaparte:
—Ça, vois-tu, femme, c'est un sabre de Turc, ce n'est bon qu'à la
parade ou à taper du plat dans le dos des avocats... nous le
laisserons au fourreau... il nous rappellera seulement l'amitié du
général Bonaparte... un parvenu comme nous, ma Catherine!...
—Tu ne t'en serviras pas de ce beau sabre? demanda la Sans-
Gêne.
—Non... pour défendre la patrie... pour taper sur les Autrichiens,
les Anglais, les Prussiens, partout où Bonaparte voudra nous
conduire, fût-ce au tonnerre de Dieu, j'ai le mien, femme, mon sabre
de Sambre-et-Meuse, il me suffit!...
Et le général Lefebvre, attirant à lui sa bonne épouse, qu'il aimait
toujours comme au 10 août, déposa sur ses grosses joues un long
baiser, franc et pur comme son sabre de combat.

FIN DE LA DEUXIÈME PARTIE[1]

 [1] L'épisode qui complète l'ouvrage a pour titre: Madame Sans-
Gêne, la Maréchale, et paraîtra à la fin du mois de mai prochain.
 TABLE DES MATIÈRES

PREMIÈRE PARTIE
LA BLANCHISSEUSE

I.— La fricassée 1
II.— La prédiction 10
III.— La dernière nuit de la royauté 20
IV.— Un chevalier du poignard 31
V.— La chambre de Catherine 50
VI.— Le petit Henriot 56
VII.— Le locataire de l'hôtel de Metz 71
VIII.— Le joli sergent 85
IX.— Le serment sous les peupliers 95
X.— L'enrôlement involontaire 114
XI.— La créance de madame Sans-Gêne 129

DEUXIÈME PARTIE
LA CANTINIÈRE

I.— En chaise de poste 138

II.— Chez la fruitière 147
 III.— La demoiselle de Saint-Cyr 158
IV.— Première défaite de Bonaparte 169
V.— Le siège de Verdun 174
VI.— A l'étape 179
VII.— L'abandonnée 193
VIII.— L'arrivée des volontaires 203
IX.— L'envoyé de Brunswick 210
X.— Le serment de Beaurepaire 217
XI.— La mission de Léonard 228
XII.— Le camp des émigrés 233
XIII.— Le second enfant de Catherine 246
XIV.— La fin d'un héros 253
XV.— Au bord du néant 265
XVI.— Jemmapes 273
XVII.— La messe de mariage 289
XVIII.— Dette de reconnaissance 306
XIX.— Avant l'attaque 321
XX.— La victoire en chantant... 332
XXI.— L'étoile 343
XXII.— Yeyette 353
XXIII.— Madame Bonaparte 370
XXIV.— Chez Barras 377
XXV.— Le sabre des Pyramides 391

ÉMILE COLIN—IMPRIMERIE DE LAGNY

*** END OF THE PROJECT GUTENBERG EBOOK MADAME SANS-
GÊNE, TOME 1 ***

Updated editions will replace the previous one—the old editions

will be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States
copyright in these works, so the Foundation (and you!) can copy
and distribute it in the United States without permission and
without paying copyright royalties. Special rules, set forth in the
General Terms of Use part of this license, apply to copying and
distributing Project Gutenberg™ electronic works to protect the
PROJECT GUTENBERG™ concept and trademark. Project
Gutenberg is a registered trademark, and may not be used if
you charge for an eBook, except by following the terms of the
trademark license, including paying royalties for use of the
Project Gutenberg trademark. If you do not charge anything for
copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such
as creation of derivative works, reports, performances and
research. Project Gutenberg eBooks may be modified and
printed and given away—you may do practically ANYTHING in
the United States with eBooks not protected by U.S. copyright
law. Redistribution is subject to the trademark license, especially
commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the

free distribution of electronic works, by using or distributing this
work (or any other work associated in any way with the phrase
“Project Gutenberg”), you agree to comply with all the terms of
the Full Project Gutenberg™ License available with this file or
online at www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand,
agree to and accept all the terms of this license and intellectual
property (trademark/copyright) agreement. If you do not agree
to abide by all the terms of this agreement, you must cease
using and return or destroy all copies of Project Gutenberg™
electronic works in your possession. If you paid a fee for
obtaining a copy of or access to a Project Gutenberg™
electronic work and you do not agree to be bound by the terms
of this agreement, you may obtain a refund from the person or
entity to whom you paid the fee as set forth in paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only

be used on or associated in any way with an electronic work by
people who agree to be bound by the terms of this agreement.
There are a few things that you can do with most Project
Gutenberg™ electronic works even without complying with the
full terms of this agreement. See paragraph 1.C below. There
are a lot of things you can do with Project Gutenberg™
electronic works if you follow the terms of this agreement and
help preserve free future access to Project Gutenberg™
electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright
law in the United States and you are located in the United
States, we do not claim a right to prevent you from copying,
distributing, performing, displaying or creating derivative works
based on the work as long as all references to Project
Gutenberg are removed. Of course, we hope that you will
support the Project Gutenberg™ mission of promoting free
access to electronic works by freely sharing Project Gutenberg™
works in compliance with the terms of this agreement for
keeping the Project Gutenberg™ name associated with the
work. You can easily comply with the terms of this agreement
by keeping this work in the same format with its attached full
Project Gutenberg™ License when you share it without charge
with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside
the United States, check the laws of your country in addition to
the terms of this agreement before downloading, copying,
displaying, performing, distributing or creating derivative works
based on this work or any other Project Gutenberg™ work. The
Foundation makes no representations concerning the copyright
status of any work in any country other than the United States.

1.E. Unless you have removed all references to Project

Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project
Gutenberg™ work (any work on which the phrase “Project
Gutenberg” appears, or with which the phrase “Project
Gutenberg” is associated) is accessed, displayed, performed,
viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United

States and most other parts of the world at no cost and
with almost no restrictions whatsoever. You may copy it,
give it away or re-use it under the terms of the Project
Gutenberg License included with this eBook or online at
www.gutenberg.org. If you are not located in the United
States, you will have to check the laws of the country
where you are located before using this eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is

derived from texts not protected by U.S. copyright law (does not
contain a notice indicating that it is posted with permission of
the copyright holder), the work can be copied and distributed to
anyone in the United States without paying any fees or charges.
If you are redistributing or providing access to a work with the
phrase “Project Gutenberg” associated with or appearing on the
work, you must comply either with the requirements of
paragraphs 1.E.1 through 1.E.7 or obtain permission for the use
of the work and the Project Gutenberg™ trademark as set forth
in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is

posted with the permission of the copyright holder, your use and
distribution must comply with both paragraphs 1.E.1 through
1.E.7 and any additional terms imposed by the copyright holder.
Additional terms will be linked to the Project Gutenberg™
License for all works posted with the permission of the copyright
holder found at the beginning of this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookball.com