Active System Control Design of System Resilience

Igor Schagaev · Brian Robinson Kirk
Active
System
Control
Design of System Resilience
Active System Control
Igor Schagaev • Brian Robinson Kirk
Active System Control

Design of System Resilience
Igor Schagaev Brian Robinson Kirk
Director Research Director
IT-ACS Ltd Robinson Systems Engineering Ltd
Stevenage SG1 1RR Painswick GL6 6QJ
Hertfordshire, UK Gloucestershire, UK
ISBN 978-3-319-46812-9 ISBN 978-3-319-46813-6 (eBook)

DOI 10.1007/978-3-319-46813-6
Library of Congress Control Number: 2017945950
© Springer International Publishing AG 2018

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of
the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or
dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publication does not imply, even in the absence of a specific statement, that such names are exempt
from the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authors or the editors give a warranty, express or implied, with respect to the material contained
herein or for any errors or omissions that may have been made. The publisher remains neutral with
regard to jurisdictional claims in published maps and institutional affiliations.
Printed on acid-free paper
This Springer imprint is published by Springer Nature

The registered company is Springer International Publishing AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Preface
We used the word active in the title of our book, Active System Control, because
we are actively trying to predict the future behaviour of the system, and react
accordingly in order to manage the safety and continue the operation of the system
being controlled.
We used the word system because we create a model of a system, based on an
aggregate of models of its elements. It is used to try to predict the parameters of the
system’s behaviour.
We use the word control because we continually monitor the current situation
and adapt the control of the system to make the best of the circumstances.
Therefore, Active System Control is the right title, and the abbreviation ASC will
be used in the text.
In this book we briefly analyse what is required from on-board devices in order
to support active system control, that is, what must be done to sustain everyday safe
operation and summarise the requirements for this class of devices.
We also introduce the new concept of a safety device—the “active black box”—
which might be used for aviation, transport, and nuclear and chemical plants. In the
coming age of “driverless” transport, it is particularly relevant to the automotive
sector to monitor the behaviour of semi-autonomous and fully autonomous vehicles
carrying passengers.
Separately, and briefly, we describe the regulations in transport segments rele-
vant to the application of existing and proposed devices. We start with an analysis
of air transport because this is a well-established and reasonably well-understood
domain with a relatively mature safety culture.
Stevenage, UK Igor Schagaev

Painswick, UK Brian Robinson Kirk
v
Acknowledgements
This book includes efforts from quite a number of people. Dr. Felix Friedrich, ETH
(Zurich), Dr. Florian Negele and Dr. Thomas Kaegi were involved in the develop-
ment of flight mode algorithms, as well as the system architecture and design
required to implement the concept of active system control in the general aviation
aircraft application domain.
Engineer Alex Schagaev (IT-ACS LTD) developed and tested various flight
scenarios to detect conditions of flight mode changes, and verified fight mode
changes using two flight simulators—X-plane and Microsoft—in preparation for
field trials using general aviation aircraft. This enabled us to improve our under-
standing of the conditions for flight mode changes, which were not known before,
and to refine the flight mode model.
Several consultants from the areas of aircraft design, testing and simulations
were invited and contributed in various chapters: Dr. S. Plyaskota was fully
involved in the development of the classification of aviation and analysis of the
market domains. His efforts are highly regarded and appreciated. Dr. V Bukov
consulted in the “algebraic” description of our graph logic model (GLM) represen-
tation. Along with his colleagues, he was involved in modelling and simulating the
trial aircraft air pressure system.
Dr. Kai Goebel (NASA) made contributions to the prognostic aspects of our
approach and the role of active system control in the whole book, especially in
Chap. 10.
We sincerely appreciate help of our colleagues and friends and offer our heartfelt
thanks.
vii
Contents
1 Aviation: Landscape, Classification, Risk Data . . . . . . . . . . . . . . . . 1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Survey of the Aviation Application Domain . . . . . . . . . . . . . . . . . . . . 4
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Classification of Aviation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
The Aircraft Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Safety and Risk of Flight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Aviation Safety in Commercial Aviation . . . . . . . . . . . . . . . . . . . . . 24
Main Risk Agents and Their Contribution . . . . . . . . . . . . . . . . . . . . 26
Risk Factors and Flight Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Risk and Safety in General Aviation . . . . . . . . . . . . . . . . . . . . . . . . . 30
Accident Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Flight Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
First Occurrences and Sequence of Events . . . . . . . . . . . . . . . . . . . . 35
Causes and Factors of Accidents . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Safety Management Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Insurance, Regulation and Aviation Safety . . . . . . . . . . . . . . . . . . . . 39
Flight Safety and Safety Control Cycles
in Aviation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Constraints and Failures of Safety Management . . . . . . . . . . . . . . . . 41
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2 Active System Control and Safety Approach, and Regulation
in Other Application Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Approach to Safety in Critical Systems . . . . . . . . . . . . . . . . . . . . . . . 45
Safety Approach in Industrial Systems and Machinery . . . . . . . . . . . . 46
Approach to Safety in Process Plants . . . . . . . . . . . . . . . . . . . . . . . . 46
Approach to Safety in Small Industrial Systems . . . . . . . . . . . . . . . . 47
ix
x Contents
Safety Approach in the Automotive Industry . . . . . . . . . . . . . . . . . . . 49

Current On-Board Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Physical Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Route Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Driving Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Driver Safety Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Safety Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Operational Safety Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Future Safety Systems in the Automotive Industry . . . . . . . . . . . . . . 53
Safety Approach in the Rail Industry . . . . . . . . . . . . . . . . . . . . . . . . . 54
Current On-Board Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Physical Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Route Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Driving Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Driver Safety Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Safety Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Operational Safety Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Future Safety Systems in the Rail Domain . . . . . . . . . . . . . . . . . . . . 59
Safety Approach in the Space Domain . . . . . . . . . . . . . . . . . . . . . . . . 60
Existing Standardisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Standards in the Industrial Domain . . . . . . . . . . . . . . . . . . . . . . . . . 62
Safety Definitions of IEC 61508 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Functional Safety Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Standards in the Rail Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
The Safety Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Development Life-Cycle for Safety-Related Systems . . . . . . . . . . . . . 65
Safety Integrity Levels (SILs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Standards in the Space Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Functional Safety Standards Based Upon IEC 61508 . . . . . . . . . . . . . 69
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3 Aircraft Flight Reliability and the Safety Landscape
of Aircraft Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
An Operational Reliability Model for Aircraft . . . . . . . . . . . . . . . . . . 74
Reliability Model of a Flight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Operational Reliability Model: Equations . . . . . . . . . . . . . . . . . . . . . . 76
Measures of System Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
The Safety Maintenance Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Developments in Modern Aviation and Safety . . . . . . . . . . . . . . . . . 80
Developments in Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Chain Mode Flights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Latency of Fault and Safety Monitoring . . . . . . . . . . . . . . . . . . . . . . 84
Contents xi
The Safety Maintenance Landscape: Commercial

Aviation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
On-Ground Management of Safety . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Timing for Safety Management between Flights . . . . . . . . . . . . . . . . 89
Social, Political and Commercial Aspects
of Aviation Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Flight Safety Versus Risk and Statistics:
Flight Data Paradox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Risk and Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
External and Internal Aspects of Aircraft Safety . . . . . . . . . . . . . . . . 94
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4 Active Safety Relative to Existing Devices . . . . . . . . . . . . . . . . . . . . 99
Active System Control and System Safety Versus
Aircraft Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Safety Tools and Supportive Devices . . . . . . . . . . . . . . . . . . . . . . . . . 101
Safety Devices: Brief History and Evolution . . . . . . . . . . . . . . . . . . . 101
Existing Flight Data Recording Devices . . . . . . . . . . . . . . . . . . . . . . . 105
Military Flight Data Recording Devices and Testing
Recorders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Requirements for New Flight Data Recording
and Processing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Flight Data Processing System Post-flight Analysis . . . . . . . . . . . . . . . 110
Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
The Nature of Devices for Future Aircraft . . . . . . . . . . . . . . . . . . . . . 114
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5 Principle of Active System Control (Theory) . . . . . . . . . . . . . . . . . 121
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
The Goals, Role and Structure
of the Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Active System Control Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Defining and Implementing the PASC . . . . . . . . . . . . . . . . . . . . . . . . 126
Structure of Research of Active System Control . . . . . . . . . . . . . . . . 128
Principle of Active System Control . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Factors to Take into Account Making
Active System Control Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Definition of the PASC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
PASC and Elements of Redundancy Theory . . . . . . . . . . . . . . . . . . . 134
The PASC Algorithm in More Detail . . . . . . . . . . . . . . . . . . . . . . . . 137
PASC: Dependability and Fault Tolerance . . . . . . . . . . . . . . . . . . . . 139
xii Contents
Improving the Control and Safety of a System . . . . . . . . . . . . . . . . . 140

A Generalised Information Model for Active System Control . . . . . . 143
On Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6 Principle of Active System Control:
Aspects of Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Implementation of PASC in-the-Medium . . . . . . . . . . . . . . . . . . . . . . 149
The PASC for General Aviation:
The Cycle of Operational Management . . . . . . . . . . . . . . . . . . . . . . 150
Process-Oriented Informational Model . . . . . . . . . . . . . . . . . . . . . . . 152
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
7 Active System Control: And Its Impact on Mission Reliability . . . . 189
Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Preventive and Conditional Maintenance Versus
Active System Control: A Semantic Difference . . . . . . . . . . . . . . . . . 191
Reliability Gains: Conditional Maintenance Versus Active System
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Preventive Maintenance with Implementation
of Active System Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
The Real-Time Reliability Corridor:
Introduction and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Conditional Maintenance Versus Active System Control . . . . . . . . . . . 205
Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
8 Flight Mode Concept and Realisation . . . . . . . . . . . . . . . . . . . . . . . 209
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Goals and Objectives of the Chapter . . . . . . . . . . . . . . . . . . . . . . . . 210
The Objectives of Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 212
The Flight Mode Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Flight Mode Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
The Flight Mode Detection Algorithms . . . . . . . . . . . . . . . . . . . . . . 217
Visualisation of Flight Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Presentation of Advice to the Flight Crew . . . . . . . . . . . . . . . . . . . . 220
Information Processing of Flight Data Including
Flight Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Flight Mode Detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Real-Time Diagnosis and Prognosis . . . . . . . . . . . . . . . . . . . . . . . . . 223
Determination of Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Configurability of the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Contents xiii
A Trial Architecture for Flight Mode Detection . . . . . . . . . . . . . . . . . 224

The Avionics System: System Block Diagram . . . . . . . . . . . . . . . . . 225
Flight Data Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Software Architecture and Partitioning . . . . . . . . . . . . . . . . . . . . . . . 227
Using Flight Modes to Tune Flight Performance
and Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Further Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Appendix: Flight Mode Model: XML Specification . . . . . . . . . . . . . . 232
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
9 Active System Control: Realisation . . . . . . . . . . . . . . . . . . . . . . . . . 241
Introduction: The Safety Aspects of Active
System Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Objectives of the Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
The Active System Control for Safety:
Theoretical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Fault Detection and Handling: Algorithms and Procedures . . . . . . . . 243
The Theory: Based on Applied Graph Logic . . . . . . . . . . . . . . . . . . . 244
The Algorithms of Fault Localisation . . . . . . . . . . . . . . . . . . . . . . . . 253
The Application Example: Air Pressure System . . . . . . . . . . . . . . . . 256
Summary and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
10 Active System Control: Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Igor Schagaev, Brian Robinson Kirk, and Kai Goebel
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Classification of Aircraft: Reiterated . . . . . . . . . . . . . . . . . . . . . . . . . 270
What Else Can Active System Control Do? . . . . . . . . . . . . . . . . . . . . 272
Active System Control: Life-Cycle of Design and Manufacturing . . . . 273
Active System Control: Life-Cycle of Aircraft Application . . . . . . . . . 273
Active System Control: Risk Information
Paradox: RIP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Active System Control in Almost One Page,
“During” and “After” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Active System Control Dependency Matrixes:
Who Is Doing What . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
The Impact of Prognostics on Active System Control . . . . . . . . . . . . . 282
Embedding Active System Control into Aircraft . . . . . . . . . . . . . . . . . 283
Software Organisation of Active System Control . . . . . . . . . . . . . . . . 284
Active System Control Essential Device:
Active Black Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Summary and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Author Biographies
Professor Igor Schagaev is the Director of IT-ACS

Ltd. Stevenage, UK. He received his Ph.D. in Com-
puter Science in 1983 from the Russian Academy of
Sciences, Institute of Problem of Control; Certificate in
Business Organization of International Research Pro-
gram Management, TACIS (EC) 1996; Certificate in
Learning and Teaching in Higher Education, Univer-
sity of North London 2001. He has been Fellow of the
Institute of Analysts and Programmers (UK) since
1992 and Fellow of British Computer Society since
2013. Igor has previously worked as an Electromechanical Engineer at the Smo-
lensk aviation factory, USSR; a Senior Programmer and Design Engineer at the
Institute of Advanced Computations, Central Statistical Bureau of USSR; and as
Head of the Fault-Tolerant System Branch at the Institute of Control Sciences. The
latter was combined with work as Senior Design Engineer and System Programmer
for Avionics at Sukhoi Design Bureau. Since 1992, Igor has been Director of
ATLAB Ltd. Bristol (now converged into IT-ACS Ltd.). Since 1983, Igor has
published internationally 70+ papers in journals and conferences, and seven
books. Igor has been a keynote speaker at world conferences in the UK, China
and the USA, and has provided consultancy for the Financial Times, Sunday Times,
Boston Facultimedia and Swedish government, all on the subject of ICT, avionics
and aerospace domains. Igor has been honoured with several industry awards,
achievements and grants. He is author of the Springer titles: V Castano and I
Schagaev, Resilient Computer System Design; and Schagaev I, Kaegi T, Software
Design for Resilient Computer Systems. Since 2007, together with Dr. Brian Kirk
and Alex Schagaev, Igor has held a patent on the Method and Apparatus for Active
System Safety, GB 2448351.
xv
xvi Author Biographies
Dr. Brian Robinson Kirk is the founder and Director

of Robinson Systems Engineering Ltd. in the UK,
which has specialised in designing and building
safety-related computing and control systems for over
40 years. He received his Ph.D. in Methods of Active
System Safety in 2007, formerly attaining an M.Sc. in
Industrial Electronics from Imperial College and a B.-
Sc. (Hons) in Electronics from Salford University in
the 1960s. He worked on early graphics-based CAD
and simulators for microchip design with Marconi
Research Labs. In the 1970s, he worked as design manager for microprocessors
and memories at General Instrument Corp. There, he worked on custom IC design
and early 1-, 4-, 8-and 16-bit processors, including the PIC series, the Sinclair
calculators and early TV games (such as Pong). After working for Mergenthaler
Linotype on system designs during the phototypesetting revolution, he founded
Robinson Systems Engineering Ltd. He has presented many papers linking theory
to practical applications at conferences around the world and collaborated with
Professors’ Wirth and Gutknecht’s group at ETH Zurich for over 20 years,
co-authoring the Zonnon Language Report. As joint author of the book Program-
ming Oberon in Windows, he released Robinson’s Oberon compiler for Windows as
part of the Programmers Oberon Workbench as freeware, inspired by the usability
and ubiquity of Borland Pascal. More recently he has provided technical advice to
US legal teams on the causes of sudden unintended acceleration in vehicles that
contributed to a billion-dollar settlement in a single case and contributed to Tom
Murray’s book Deadly by Design. As a Chartered Engineer he is currently working
with the Institute of Engineering and Technology (UK) and IEEE (USA) on
guidance for improving the Electromagnetic Resilience of Systems. He is a member
of the British Computer Society, Institute of Directors, and a life member of the
ACM (USA) and the International Society of Bassists, being an enthusiastic
double-bass player in various jazz bands.
Chapter 1
Aviation: Landscape, Classification, Risk Data
Introduction
The idea of improving systems, making them more efficient, reliable and better
designed, has been around since humankind has existed. In the aerospace domain,
both reliability and efficiency are crucial, as human life is at stake. Thus, this work
investigates how to make new systems and aircraft while taking into account the
following:
– Estimation of market volume
– Systematic classification of aviation, aiming to create a “portrait” of aircraft as a
“safety object”
– Analysis of aviation safety and reliability statistics
– Analysis of features and requirements for new designs for aviation and
aerospace
– A “rich picture” of efficiency, safety and reliability required for further model-
ling and prototyping
Our aim is to propose, analyse and develop a new Principle for Active System
Control (PASC) and apply it, as an example, to aviation. Just recording data during
an aircraft’s flight or vehicle’s mission in order to allow analysis after a crash is no
longer adequate or acceptable. PASC proposes the analysis of available data in real
time during the flight and reacting to that information with the aim of preventing
accidents. The concept of active safety, initially called dynamic safety, was intro-
duced initially during 1994–1995 meetings at Filton Bristol with specialists from
British Aerospace, later presented at [1, 2] and further developed in [3]. That was
the starting point for the present work. These kinds of systems are currently referred
to in the aerospace industry as health monitoring systems.
In later chapters we will develop the following:
– The theoretical principles of active system control
– A flight safety (risk) model
© Springer International Publishing AG 2018 1

I. Schagaev, B.R. Kirk, Active System Control, DOI 10.1007/978-3-319-46813-6_1
2 1 Aviation: Landscape, Classification, Risk Data
– An information flow model

– A control system model
Analysis of the dependencies within and between the models will define the
features, functions and structures of the aircraft, including its onboard architecture
of software (SW) and hardware (HW). A comparison between the existing and the
proposed system structures in terms of achievable aviation safety, condition mon-
itoring and efficiency will be presented, namely:
– Further theoretical and conceptual development of the Active System Control
(ASC) principles
– Formation of theoretical models to analyse the limits of ASC applicability
– Development of a working ASC prototype for aircraft
– Research and development of hardware (HW) and system SW elements for the
on-board part of ASC
In terms of system SW, the main characteristics of ASC implementation include
extremely high reliability, fault-tolerant concurrency, ability to recover processed
data, support mechanisms for real-time fault detection, system reconfiguration in
case of HW fault or degradation, high performance and real-time scheduling. In
terms of system HW the main characteristics of ASC include the highest possible
reliability, recoverability, fault tolerance, thermal and vibration resistance and
survivability as well as support for graceful mechanical degradation.
The main goal of our work as it is presented in this book is implementation of
PASC in the air and on the ground—making all efforts “in concert” before, during
and after flight to aim for unprecedented efficiency of aerospace systems and the
flights that rely on them.
Modern aircraft and spacecraft are not well supported by on-ground mainte-
nance. Recent accidents and launch delays, world press coverage about the cracked
wings of A380 aircraft, the June 2009 crash of an Air France A330, as well as a
rather steady stream of sad statistics regarding aircraft crashes worldwide (http://
planecrashinfo.com) all indicate the need to implement PASC, which aims to
monitor and predict the condition of aircraft, including structure, engines, avionics
and pilot behaviour in order to avoid accidents, or at least reduce the level of
possible harm. PASC involves continuous real-time analysis of flight data and data
accumulated from an aircraft’s previous flights (Fig. 1.1).
Potential beneficiaries of implementing ASC include:
– USA, Europe and Asia at large, by using and transferring results to other
transport segments and implementing them in the USA, European and Asian
markets
– Citizens: aircraft owners and users based on efficiency and safety
– Main regulatory bodies such as the FAA, Eurocontrol, EASA and ACARE, as
they will be able to introduce new progressive regulations that are easier to
implement and maintain
– USA, European and Asian industries involved in aircraft and avionics
manufacturing
Introduction 3
Fig. 1.1 Scope of the work

Object: aviation
Proposed approach:
Active System
Control
Analysed feature:
safety
Existing methods
and technologies
– Insurance companies, as ASC will help to create the basis for new insurance
schemes and a market for aviation, transport and aerospace policies that simply
does not exist at the moment
The book is organised as follows. The aviation market as a whole is briefly
analysed, and trends and challenges in aviation, both conceptual and technological,
are discussed, including cross-segment and segment-specific topics. A new classi-
fication of aircraft is introduced, aimed at the future analysis of key features,
technologies and aspects of aircraft efficiency. New approaches and technologies
(such as the free-flight approach, information technology and information
processing, as well as GPS and automatic air traffic control) are reviewed again
to assess their suitability for use during implementation of PASC.
Aerospace has its own specific risks and efficiency factors, and one of the goals
is to reduce the former and to promote the latter. Of course, regulations and
definitions currently exist, and wherever possible the approach has been to conform
with or complement them, at least “in spirit,” aiming to create common ground with
the various aviation administrators and regulators by implementing ASC while also
taking account of current developments, tools, programmes and standards. Risk
profiles are also analysed across all flight phases, taking account of the key external
and internal risk factors.
A special section of the ASC programme will deal with aerospace vehicles,
specifically in terms of life-cycle efficiency, reliability and safety. To achieve
improvements and “real-time-ness” of data processing and analysis, both historic
and flight/mission information will be used and the required format of flight data
will be analysed. Existing and potential devices for implementing ASC will be
discussed, with the aim of making flight more efficient and improving the quality of
aircraft maintenance.
The main risk factors will be discussed and methods and solutions to reduce risk
will be analysed. Technological requirements and feasibility aspects will also be
Fig. 1.2 Structure of the

work Review of aviation, and aerospace
Market analysis, classification, regulations, requirements
Key features of aircraft and spacecraft
Technological profile of design, maintenance and safety
Principle of Active System Control (PASC)
Theory and methods of implementation
considered in a special part of this work because the success of an effective ASC
implementation depends on their further development (Fig. 1.2).
Survey of the Aviation Application Domain
Terminology
We first introduce some definitions and terminology required to classify aircraft and
active safety. Later sections present the classification of aircraft. Features of the
aviation market according to aircraft classifications are discussed in section “Clas-
sification of Aviation”.
A glossary of terms that are essential for reading this work is provided in the
appendix. The terminology used for active safety is briefly introduced here:
– Object of danger (OD): given the right conditions, ODs can cause hazards and
increase the risk of a dangerous event or accident that can cause harm.
– Objects of safety (OSs): these are the subjects of harm, such as people, animals,
plants, property and the environment.
Survey of the Aviation Application Domain 5
Each object of danger has one or a number of factors of danger or so-called

hazards, i.e., the physical phenomena manifested when an OD and an OS interact.
For example, in a nuclear power plant a hazard might be a nuclear explosion
resulting in harm from the shock wave, blinding light flash, long-term intense
radiation, or the electromagnetic impulse.
In these tense times, when acts of terrorism know no bounds, it is not beyond
possibility that an aircraft crashed into a nuclear power plant might trigger such an
event.
Many practical air safety guidelines are formulated on the basis of estimates
(either experimental or modelled) of the characteristics of OD and OS based on the
likelihood of hazards occurring.
Classification of Aviation
A defining (or “principal”) attribute is that attribute of a substance which distinguishes it

from any other type of substance, and thus without which that substance could not be
conceived.
Descartes, (Principles, part one, §53, I, 210–1)
There are at least three main reasons to classify aircraft or spacecraft. The first
reason is the need for a proper definition of the terms “business,” “commercial,”
and “general aviation” as well as of autonomous and piloted vehicles. For the scope
of this book a classification of aviation enables us at first to:
– Define domains of aviation and clarify terminology
– Extract the main features of each domain in terms of application and
maintenance
– Define limits and describe differences between various types of aircraft
– Evaluate, initially qualitatively and where possible quantitatively, the applica-
bility of the proposed active system control
Secondly, it becomes possible to identify the class of required features for
system elements that are relevant for active system control.
Thirdly, classification helps to unify implementation solutions for various types
of aircraft and spacecraft using a two-tier system with basic and specific parts. The
basic part is common to all ASC implementations, while the specific part serves as
an interface between the main system and specific types of aircraft or spacecraft.
Previously, aircraft classification was generally based on four aspects:
– The particular mission, based on its purpose (sector of aviation)
– The type of aircraft or the principle of creation of lift (method of propulsion)
– Technical features (and technical data)
– State of development of the aircraft (status and operational maturity)
In some publications, classification by type of propulsion has been used; how-
ever, for ASC purposes, this can be considered to be one of the consumer properties
(such as the type of a wing, the shape of a wing, the type of a landing gear and so
forth). Another classification might be airworthiness, but this is just a measure of
the quality, safety and readiness of all the aspects of a plane for flight, rather than a
classification.
International and regional aviation organisations define various sets of standards
and rules based on their classification systems. In the following sections the
standards are related to the classifications outlined above.
Classification of Aircraft by Mission
According to generally accepted standards (e.g., Federal Aviation Require-

ments FAR, Joint Aviation Requirements JAR, etc.) and the general approach of
the main players (e.g., International Civil Aviation Organization ICAO, Federal
Aviation Authority FAA, European Community Aeronautics Research ECARE,
etc.), aircraft for a particular mission can be subdivided into two larger groups:
military and civil. There is a possibility that a particular model will be dual-purpose,
that is, useful for both military and civil segments, for example, large cargo planes
used for disaster relief.
The particular mission of an aircraft affects key properties, altering the meaning
of words used in that context (e.g., efficiency, safety, maintenance) and, thus,
requires a different classification to make sense of general and specific property-
wise procedures and gains: efficiency, safety, maintenance, etc. Here a brief and
incomplete survey of safety schemes is presented for military aircraft as some
features may migrate to commercial and general aviation.
Military aircraft can be defined by mission or purpose. For military aircraft, the
presence of their own and their enemies’ armaments are a specific danger. Extreme
conditions of operation such as very high altitude or high levels of acceleration
present additional dangers. This may require special additional equipment for life
support. In addition, all of the objects of safety for a military aircraft also exist in
civil aircraft, but to a lesser degree, matching the less stringent requirements.
To achieve the required level of risk reduction in military aircraft, specified
resources are required to protect the crew (e.g., armoured cabins, ejector seats, etc.).
Note that life insurance and the health of members of crews of military aircraft are
the same as in general practice with other military personnel, even though their life-
chances are clearly impaired.
Legally, once at war all are equal, and for military personnel the risk of perishing
onboard an aircraft (or helicopter) is equated with the risk of perishing on the front
line. Although hardly any data are available from the military for the sake of
generalisation, we assume that safety standards for military crews are similar to
those established by internal standards of the countries in which they operate.
The astronomical costs of modern military aircraft should assure society that
their design and maintenance is intended to make them as safe as possible. But
unfortunately such high costs do not guarantee the quality required!
Fighter jets and special military aircraft are equipped with standard “Systems of
Objective Checking” (SOC), and various kinds of onboard data storage devices for
flight data are intended primarily to ease problem solving in the combat training of
crews, e.g., for the control and analysis of fulfilment of a mission.
Independent experts investigate accidents and other abnormal events for both
military and civil aviation and have access to the information stored during a flight.
Most ASC principles are applicable for both military and commercial aviation.
However, ASC is not generally targeted for the military market for the following
reasons:
– Equipment on military aircraft where PASC should be implemented is already
certified and would need adaptations to both its HW and corresponding SW
– The specific problems facing various military aircraft do not allow a standard
solution
– Safety supportive schemes are hard to analyse because they may contain sensi-
tive military data
– Maintenance for military aircraft tends to be rather conservative and again
difficult to assess
Within civil aviation in the UK and USA (FAR rules), civil aviation is
subdivided between commercial (CA) and a general-purpose aviation (GA). Com-
mercial aircraft (CA) is defined as “any aircraft carrying more than 30 passengers or
a minimum actual load of 7500 pounds (or more), transporting passengers and/or
freight for payment.” Such aircraft are regulated by the International Civil Aviation
Organization (ICAO) and used to provide air transport services.
Although the term “general-purpose aviation” (GA) is widely used, it is in fact
quite poorly defined. For example, the Federal Aviation Administration’s (FAA)
definition embraces a very broad range of aircraft. The General Aviation Manufac-
turers Association (GAMA) [4] uses a similar catchall definition:
GA constitutes all aviation, except commercial and military.
Though this definition is similar to the FAA’s, GAMA does not define the scope
of commercial aviation. In turn, the Aircraft Owners and Pilots Association
(AOPA) uses its own classification of aircraft. AOPA classifies aircraft according
to the FAR Part 135, including short-haul airlines.
Nevertheless, this exclusion is too strict, as it would exclude air-taxis from the
scope of our research. Operators of air-taxis are allowed to operate without regis-
tration according to FAR Part 135. Also helicopters, generally not intended for
hiring, can also be considered to be part of the GA market.
General-purpose aviation includes various kinds of aircraft application: admin-
istrative, business, air-taxi, tourism, medical, life-saving, agricultural, prospecting,
sporting, training, experimental. Users of GA aircraft, in turn, can be private and
corporate owners as well as state and local administrative bodies such as police or
fire departments.
Classification of aircraft by mission is shown in Fig. 1.3. The majority of
indicated kinds of aviation fall into more than one classification; for example,
some military aircraft are used to carry passengers, or as an air-taxi.
Agricultural
Geological
CIVIL
Sport
General Aviation
Medical
Administrative (Public)
Commercial Air Taxi
Passenger
Cargo
Research
Multiple
Search & Rescue

DUAL-PURPOSE
Training
Multitask
Reconnaissance
Drone
MILITARY
Patrol
Observation
Anti-submarine
Low Temp. Operation
Tanker
Fighter
Special Elec. Equipment
Direction
Attack
Fig. 1.3 Classification of aircraft by primary mission

LIGHTER THAN AIR
Balloon
Airship / Zeppelin
Combined
HEAVIER THAN AIR
Wingless
Backpack
Rocket
Combined
Winged
Immobile Wing
Soft Wing Paraglider

Paraplane
Rigid Wing Plane
Glider
Ground-effect
Plane
Semi-rigid Kite
Wing Deltaplane
Mobile Wing
Rotorcraft Helicopter
Gyroplane
Gyrodyne
Flap-hinged
Combination
Vertical
Takeoff
Plane
Fig. 1.4 Classification by the type of aircraft

Classification by Type of Aircraft or Method of Operation
The type of an aircraft is defined by its construction and method of operation

(glider, balloon, blimp/dirigible, fixed-wing or rotorcraft). Classification by type
is illustrated in Fig. 1.4. This approach is in general agreement with existing
documents, but has some distinctive features:
– The classification is based only on basic flight characteristics without specifics of
construction features (e.g., a power unit).
– The classification has a hierarchy structure with several levels of branching.
There are five levels of branching based on:

1. Means of creating lift, generally divided into two categories: lighter-than-air and
heavier-than-air.
2. Presence of the wing, heavier-than-air aircraft can be subdivided into winged
and wingless.
3. Wing mobility, creating two alternate categories, with fixed-wing and
mobile wing.
4. Wing construction; main constructional aspects are wing rigidity (soft, semi-
rigid, rigid) and type of wing movement (spinning, alternating motion).
5. Technique of lift implementation.
The first three levels of hierarchy present a combination of classification features
that help to analyse aircraft that use vertical takeoff and landing.
The definitions of different types of aircraft operated under FAR are provided in
Appendix I. Note again the lack of a systematic classification scheme in these FAA
definitions. Other approaches to classify aircraft by type depend on the aims of the
classification. For example, the US Air Force uses the following codes for various
aircraft types
– G Glider
– H Helicopter
– V Vertical takeoff plane
– Z Balloon/Zeppelin
It is generally assumed that aircraft with rigid immobile wings are aircraft, but
there are also other possibilities including aircraft with:
– Flexible wings(s) such as para-planes or monoplanes
– Semi-rigid wings such as kites or delta-winged planes
– Rigid-wing planes depending on the ground effect, so- called “ground-effect”
planes or hovercrafts
– Rotor-based planes, without motors
– Flap-winged planes, a helicopter/aircraft hybrid
– Backpack wingless planes, e.g., rocket- propelled
– Other micro-light-based configurations
Classification by Technical Specifications
Aircraft can be defined by their consumer features and technical specifications.

Selection of particular properties depends on the intended use. For example, in the
USA the FAA uses two main sets of technical data for classification: the aircraft’s
landing (approach)—speed and wing span.
According to FAA Advisory Circular (AC) 150/5300-13, on Airport Design,
airports (and by inference the aircraft that use them) are subdivided into five classes
based on the aircraft type they are designed to accommodate.
Ordering of features and consumer properties of aircraft enable us to define the
following groups:
– General characteristics
– Engine characteristics
– Design features
The first group refers to maximum takeoff weight of aircraft, overall dimensions
(wing span), number of passengers, approach speed, cruising speed and other
characteristics.
The second group relates to the number and type of engines.
The third group refers to distinctive structural attributes/features of airframe
design, flight control type and configuration; landing gear type and configuration;
design features of instrumentation; fuel system configuration and electrical system
configuration.
Figure 1.5 illustrates the classification of aircraft by technical features; alterna-
tive values of classification attributes are shown by yellow shading. And elements
of the indicated systems of the aircraft are shown in pale blue.
Classification by State of Development
Another important classification group for aircraft is their state of development.

This group is rather important for future aviation projects when taking into consid-
eration the possibility of using new engineering technologies and methods, includ-
ing application of active safety principles.
During the design and testing of new aircraft it is important to consider the
analysis of aircraft data, information flows and later flight and monitoring infor-
mational support.
Here the proposed principle of active system safety and evaluation of its possible
implementation might be extremely productive, as there is an opportunity to
integrate PASC during the design process. As a result, new aircraft could become
much safer than existing ones.
On the other hand, complex flight data processing may exceed the duration of
experiments where the measurement of technical characteristics and parameters
Flight Weight (Take-off) Super-light Light Middle Large
Approach Speed (Knots) < 91 B. 91 - 121 121 - 141 141 - 166 166+
< 49 49 - 79 79 – 118 118 – 171 171 – 214 214+

Aircraft Wingspan (Ft)
(15 m) (15 - 24m) (24 – 36m) (36 - 52m) (52 - 65m) (65+ m)
Unmanned Single- Multi-
Number of Seats
seated seated
Cruising (Air) Speed Subsonic Supersonic Transonic
Power Plant Characteristics
None Single Double /

Number of Engines
Multiple
Type of Engine Piston Turbo-prop Rocket
Coaxial Reblade Straight Multi (N)

Type of Propellers
Blade blade
Design Features
No wheels 2-wheeled 3-wheeled Multi-wheeled
Landing Gear Configuration
(Bicycle) (Bicycle) (Polycycle)
Type and
Configuration Gear Type
Flight Control Rudder Type

Type and
Configuration Aileron Type
Trim Type
Flap Type
Elevator Type
Airframe Scheme Monocoque Classic Canard

Design
Fuselage Narrow Wide Single- Double-
aisled aisled
Wings Monoplane Biplane Strait Delta
Empennage
CIS Design Cockpit Instruments
Alternator
Antennas
Pilot Static System
Other Onboard Systems
Fuel System Configuration
Electrical System Configuration
Fig. 1.5 Classification by technical specification
took place. Some examples include aerodynamics parameters, and take-off and
landing speeds.
In this case, the performance of the PASC HW and algorithms needs to be
estimated so that the technology used to implement the algorithms can more
than keep pace with the real-time control requirements of actual flight.
The application of new systems of active safety during development trials and
the subsequent experimental improvement of the aircraft design can result in a
significant saving of time and resources allocated to development and to the
introduction of new aircraft models into series production. This was successfully
proven by the Concord project in which flight data processing took place before,
during and after flights in special ground-based centres using flight data transmis-
sion equipment.
Specially trained and dedicated personnel supported every flight of every Con-
cord aircraft. The main problems in this scheme of safety management were that
both on-ground and on-board personnel needed to collaborate in an extremely
stable, intensive and expensive way.
But worse still, the flight data at that time could only be processed in batch mode
after each flight, not in real time during flight. With modern satellite-based com-
munication systems, data can now be monitored in real time by a ground-based data
centre. This approach is now used, for example, by Rolls Royce to monitor the
performance and condition of jet engines during flight.
Conclusion
The classifications presented here are not claimed in any way to be complete. The
intention has been to focus on classification principles which are useful to define the
features of aircraft that should be taken into account in the design of the next
generation of aircraft and their systems to promote the separation of general and
domain-specific solutions.
To make the application of PASC effective, classification can be used to identify
and “localise” specific features that depend on aircraft types and other differences
defined by the classification used. The classifications briefly presented here tend to
relate at least statically, a “portrait of aircraft” with the “portrait” of requirements
for PASC implementation schemes. These relationships will be analysed further to
enable the future design-efficient technological solutions.
The Aircraft Market
This section analyses the features and size of the existing aircraft market including
military, commercial and general aviation. Analysis of the size and share of each
segment will indicate the likelihood of success for implementing PASC. With this
goal in mind, the aircraft market is analysed in more detail for segments where
PASC can have the biggest impact—general aviation and UAV. The statistical data
in the text is used to indicate trends and proportions, and source attributions are
provided where possible. Please note that current data values are published each
year by the Boeing analytic group as well as by Flightglobal and other bodies such
as EASA and the NTSB.
$60,000
$50,000
Millions of US Dollars
$40,000
$30,000
$20,000
Civil
Military
$10,000
Polynomial trend of Civil
Polynomial trend of Military
$0
1990 1995 2000 2005
Year
Fig. 1.6 Sales of military and civil aircrafts
Military
According to analysts, despite some stabilisation of deliveries of military aircraft in

2002–2006 (see Fig. 1.6), sales of military and civil aircraft.
During the last 20 years the number of fighter aircraft purchased has reduced, as
shown in Fig. 1.7. This trend has resulted in the increased the use of drones
(remotely or autonomously piloted) to replace conventional fighter aircraft.
Figure 1.7 illustrates the quantitative growth of aircraft fleets at the expense of
purchases by a number of countries, mainly in the Near East and Asian–Pacific
region, i.e., the additional number of 4th- and 5th-generation fighters. Probably the
most important reasons for this are strategic military, commercial and
technological:
1. Strategic
• The Cold War is over and there is no enemy on Earth with a serious air force
to intercept where fighters will be required.
• New forms of air operations, shown in Iraq (2003 onwards) and Syria (2013
onwards), require multipurpose aircraft.
2. Commercial
• Growth of the cost of new aircraft
• Growth of service life of military aircraft at the expense of their
modernisation
• Extending the practice of short-term leasing of fighters
Europe &
Equtorial & South Latin America CIS Canada
Africa 8% 2% 21%
3%
Near East & China South Asia

South-East Asia
South Africa 11% 14%
19%
22%
Fig. 1.7 Export market for military aircrafts
3. Technological
• Development of pilotless combat aircraft, UAV and drones
• New, more efficient air defence systems
• Rapid change of related technologies increases the risk of obsolescence for
expensive vehicles
There are three main approaches in the fighters and basic trainers market:
• Further modernisation of existing aircraft to expand their multifunctionality
• Increasing technical flight resources to extend operational lifespan, for example,
improvement of aircraft, weapon systems, mission and navigational equipment,
and other airborne systems related to our work
• Replacement of physically obsolete aircraft with more modern ones, such as:
– Fighters: American F-16 and F/A-18, French Mirage-2000, Swedish JAS-39,
Russian Су-30 and MiG-29, and possibly EF 2000, F-22, Rafale, F/A-18E/F,
JSF, F-2, F-10, FC-1, LCA and others
– Trainer aircraft: Italian MB-339FD, Czech L-159, South Korean КТХ-2,
Brazilian ЕМВ-312Н
– Super Tucano: the planned joint development by Germany, South Korea and
South Africa of the AT 2000, Indian НТТ-35, Russian MiG-AT and Як-130
– Strike helicopters: Italian C-129 Mangust, ex-German RAN-2 Tiger, Amer-
ican AН-64A Apache and AH-64D Longbow, Russian Ка-50, Ка-52 and
Mi-28.
– Drone-based surveillance and attack aircraft
Commercial Aviation
Commercial aviation (CA) is the largest aviation sector with service and operation
in more than 200 countries. At the end of 2006, the CA network included 800+
airlines, 5,000 users, 1,350 large and 10,000 small airports, 16,000 aircraft, 150,000
air pilots and 240,000 maintenance staff. According to long-term forecasts, the
global CA capacity still has room for significant growth.
CA here will be briefly analysed with an emphasis on several aspects: long-
distance and short-distance aircraft, wide-body and narrow-fuselage aircraft,
European-made and US-made. These aspects are discussed separately because
future ASC systems may be applicable for CA. In turn, ASC results for US- and
European-made aircraft may be a subject for collaboration and further work. In
turn, manufacturers and owners of US-made business aircraft can be considered as
future prime customers of ASC solutions, devices and systems.
Europe
The current European fleet is about 3900 aircraft; see Fig. 1.8. Around 67% of the
fleet is narrow-fuselage aircraft. By 2025, the number of narrow-fuselage aircraft
will be almost doubled, and their deliveries will continue to grow at a high rate. The
European airlines will need almost 6200 new jet aircraft at a total cost of $480
billion. Seventy-five percent of them will be narrow-fuselage and used regionally.
The other 1562 or so aircraft will be wide-fuselage, with an estimated cost of
about $206 billion. Aircraft such as the Boeing 747 and other so-called Super
Jumbos will support the market for long-distance routes. In total, about 200 aircraft
of this class will be required.
The majority of aviation companies in Europe will also require medium-sized
wide-fuselage aircraft. As competition in international markets intensifies, aircraft
with smaller numbers of seats and cheaper operating costs will allow airlines to
introduce new routes, and create new markets with reduced risk. Medium-sized
wide-fuselage aircraft are needed by European airlines to decrease their operating
and maintenance costs and to create new international nonstop routes.
The overall forecast of CA development for European aviation manufacturers is
consistent and positive; see Fig. 1.9. By 2022, Airbus expects a threefold growth in
passenger traffic. Assuming a mean annual increment of passenger traffic of 5.3%
in two decades it will require 16,600 new 100-seated aircraft. Higher requirements
for fuel-efficient aircraft also highlight the need to replace 9200 narrow-body
aircraft. From an economic viewpoint, this is a good outlook.
In support of the EU forecast, Boeing forecasts that the largest part of deliveries
will be narrow-fuselage aircraft—13,650 units. The share of lighter regional jet
aircraft will increase by 4300 units. Regional airlines in the USA maintain lighter
jet aircraft for new nonstop trips. Regional jet aircraft increase geographical limits
for large nodal airports, expand use of heavier jet aircraft at nonpeak hours, replace
them on the unstressed routes and are used instead of turbo-prop aircraft.
Accordingly, Boeing airlines will use narrow-fuselage aircraft together with
regional jet aircraft to increase the frequency of internal and short international
2002 2022
European market
Number % Number %
Regional jet aircraft 468 12 979 13
Narrow-fuselage aircraft 2,613 67 5,608 63
Wide-fuselage aircraft 585 15 1,869 21
747 and heavier aircraft 234 6 267 3
Total 3,900 100 8,900 100
Source: Boeing
Fig. 1.8 European aircraft market forecast
% of %
Class of aircraft Number total number total cost
Regional jet aircraft 4,374 18 5
Narrow-fuselage aircraft 13,608 56 39
Wide-fuselage aircraft 5,346 22 45
747 and heavier 972 4 11
Total 24,300 100 100
Fig. 1.9 Market demand for new aircraft
trips. Additionally, airlines will increase their fleets of wide-fuselage aircraft

(5340 units), 45% of all such investments will go to medium-wide-fuselage aircraft.
They will be used in long-distance transportation markets, for example, crossing the
Atlantic or Pacific, and also on intense short-distance routes, for example, in Asia.
Such aircraft as the B747 and A380 will make up only 4% of all deliveries during
2003–2022, and their number will not exceed 900 units.
An estimation of CA market expansion is $1.9 billion, and narrow- and wide-
fuselage aircraft make up about 85% of this figure. Market expansion in the next
20 years will add approximately 3000 aircraft to the freight aircraft fleet; see
Fig. 1.10. Almost three-quarters of them will be converted from passenger and
mixed versions. And almost half will be wide-fuselage aircraft.
Though new freight aircraft will not make up a large part of the global fleet by
2022, many airlines nevertheless may prefer their technical advantages of reliability
and fuel efficiency. Half of these new deliveries will be for heavy freight aircraft.
Note here that the importance of the active system safety for this segment of CA is
quite high as freight aircraft are not the best served and maintained in CA. In this
sector, safety management schemes clearly restrict the profits of aviation compa-
nies and aircraft owners. The cost of all newly delivered freight aircraft is evaluated
at $132 billion at current rates.
2002 2022
Class of aircraft
Number % Number %
Light (< 30 t) 578 33 1,330 38
Middle narrow-fuselage (30 − 50 t) 192 11 735 21
Middle wide-fuselage (40 − 65 t) 490 28 630 18
Heavy (> 65 t) 490 28 805 23
Total 1,750 100 3,500 100
Fig. 1.10 Aircraft cargo fleet analysis
General Aviation
General aviation (GA is one of the most important parts of aviation globally. In fact,
in the United States alone, GA flight hours exceed 60% of all flight duration. As
previously mentioned, GA includes a range of aircraft starting from small,
propeller-driven aircraft to quite large jet aircraft that perform nonscheduled com-
mercial flights, corporate flights, and the top end of private aviation.
European GA sometimes is considered as a part of civil aviation except for air
carrier operations. The variety of GA usage is very wide:
– Law enforcement
– Forest fire fighting
– Air ambulance
– Logging
– Fish and wildlife spotting
– Passenger traffic including corporate, business and leisure travel
– Highway traffic management
– Search and rescue
– Surveying, mapping, observation, photography and logging
– Agriculture, fish and wildlife monitoring
– Smuggling of people, drugs, munitions, etc.
– Covert operations (more recently)
– Pilot training
The most common European GA use includes aerial work operations,
non-scheduled operations for remuneration or hire and sailplanes (gliders). GA
accident rates have always been higher than in CA. This is caused by marked
differences and wider variety of types of flying. The following highlights some of
the important distinctions between GA and CA:
Regulation Aspects
– GA pilots are involved in a wide range of operations.
– There is a wide variance in pilot qualifications and experience levels.
– Pilot certificates range from Airline Transport Pilot (ATP) to student pilot
with similar variability in flight hours, whereas all airline flights are crewed
by at least one ATP.
– GA aircraft owners and pilots are individually responsible for the safety of a
flight. CA and the military aviation have specially trained personnel to
perform maintenance and safety.
Technological Support
– GA aircraft have fewer cockpit resources.
– Airports and landing fields for GA have poorer facilities than CA: runways,
approach lighting systems, and the advanced services similar to airline-served
airports.
– CA requires at least two pilots; GA operations are predominantly single pilot.
– More facilities: in the USA, GA flies to nearly 14,000 airports.
Wider Risk
– Many operations of GA, such as aerial application, external loads, and banner
towing, have special mission-related risks.
– There are more takeoffs and landings—the highest risk phases of any flight.
On a per-hour basis, GA has many more takeoffs and landings than either air
carriers or the military.
– GA flights are shorter, but as flights increase, the rate of take-off and landing
grows too.
Effect of Weather
GA aircraft are more weather dependent, they usually fly through the weather
instead of avoiding it, or may not have systems to avoid or cope with adverse
conditions.
At the same time, GA is relatively flexible regarding decisions about flight. In
contracts, CA follows the schedule. GA operations such as recreational flying may
choose not to fly in poor weather conditions.
Although GA operations are different from air carrier operations, pilots who
actively manage risk can significantly improve their respective safety records.
Distribution of General Aviation
As mentioned above, the definition of GA varies in different countries, and also by

various bodies. The bodies conducting GA surveys often experience difficulties in
accumulating valid data. Some countries do not have an up-to-date register of their
GA aircraft; some might not even have a designated authority for maintaining such
records. As a result, the figures provided will be approximations or estimates.
An initial review of the above data confirms that biggest market for GA is the
USA (about 67% of the global GA fleet). The only other significant market shares
are those corresponding to Canada, Germany, Australia, Brazil and the UK; see
CIS Near East & South Africa

2% 22 %
Equitorial & South Africa

3%
Latin America
8%
China
11 % Europe & Canada
21 %
South Asia South-East Asia

14 % 19 %
Fig. 1.11 GA distribution in the world (Source: FAA, [8]2004)
Fig. 1.11. Research into GA figures for this book has shown that although extensive
data is available for the USA, very limited data is available for Europe.
Recent FAA studies have shown steady growth of GA numbers in the USA. GA
growth is the result of new production. Reduction of aircraft numbers is caused by
the retirement of aircraft and write-offs. These two processes have opposite effects;
therefore, the net balance—expected average growth in production of GA air-
craft—is slightly larger than the rate of decline.
The annual grow in GA is expected to be 1.2% over the 13-year forecast period,
rising from 211,244 in 2002 to 246,415 in 2015.
This growth includes the addition of a new aircraft category—the light sport
aircraft—that was added to the active fleet in 2004 and to account for 20,915
aircraft by 2015. In addition, it is assumed that approximately 330–500 newly
manufactured light sport aircraft will annually enter the fleet in 2006 and following
years.
Distribution of models and relative shares of GA aircraft by type is shown by
Fig. 1.12.
Features of General Aviation
General aviation aircraft have the widest variety of applications due to the follow-
ing factors:
– Low operational costs (mostly attributable to scalability factors with respect to
civil aviation)
– Shorter take-off and landing distances
– Flexibility in terms of operational altitude
– Flexibility in regulations
– Easier access to GA airports, etc.
Beech 23 Cessna 170/172

Cessna 310
Cessna 206
Piper PA24
Cessna 177 Piper PA28*/PA32
Beech 55/58
Cessna 210
Piper J3/PA18 Cessna 180/182
Mooney M20
Beech 33/35/36 Cessna 150
Fig. 1.12 GA distribution in the USA over the last 30 years (Source: FAA [8])
Through the years, the use of general aviation aircraft has further increased to
include medical emergency and similar services. The main use of GA aircraft is for
leisure/private, while pilot training is the second largest category.
A further important aspect with respect to GA is the age of the aircraft. Although
sales of new general aviation aircraft increased after the mid-1990s, most GA
aircraft in use in 2000 in the USA were more than 25 years old. US manufacturers
delivered 2816 new aircraft in 2000. Note the market size of GA in the USA:
213,500 aircraft.
Amongst all GA aircraft categories, the single-engine piston aircraft category
currently has the highest average age of all, while at the same time it accounts for
the largest percentage of the GA fleet in the USA. The oldest aircraft is single-
engine piston aircraft with 8+ seats; this type of aircraft has an average age of about
43 years.
The average age of the GA fleet in the USA in 2000 was 27 years. A report
compiled by NASA in 1999 defined some further typical features of GA aircraft
drawing on data from the USA. These features are summarised in Figs. 1.13 and
1.14.
Helicopters
Another segment of GA that recently has had a period of stable growth is helicop-
ters. Sales and volume of production has grown considerably, increasing from $4
billion dollars in 1996 up to $6.7 billion in 2001.
According to R. Aboulafia, vice-president of analysis in the Teal Group, short-
term prospects for this market remain favourable. Accordingly, in 2001–2010,
forecasts of 9503 helicopters will be produced with a total production value
exceeding $75,9 billion. Compare that to 1991–2000 when 7963 helicopters were
produced with a value $52.7 billion.
Different segments of the helicopter market are growing at different speeds. For
the ASC, the market of civil and business helicopters is the most interesting.
Characteristics of Typical GA Aircraft Typical GA Aircraft

Number of seats 4
Number of engines 1
Type of engine Horizontally opposed, 4 or 6 cylinder piston
Landing Gear Type and Configuration Fixed Tricycle
Airframe Construction Aluminium frame, Aluminium skin, steel engine
mount
Flight Control Type and Configuration Mainly cable operated utilizing bell cranks and
push-pull rods
Fig. 1.13 Typical GA aircraft characteristics (Source: NASA 1999)
Electrical
Power Plant CIS* Aircraft Control Airframe
System
Engine System Cockpit Instruments Flight Control Empennage Lighting System

Fuel System Vacuum System Rudder System Fuselage Source & Dist.
Propeller System Pilot Static System Aileron System Tail
Heating/Ventilation Alternator Elevator System Wings
Antennas Trim System
Flap System
Ground Control
Landing Gear
Fig. 1.14 Typical GA aircraft (Source: NASA 1999)
The volume of new deliveries of civil helicopters has reached $1.2 billion. It is
expected that in the period between 2001 and 2010 about 819 civil helicopters with
a value of $12.43 billion will be produced. During 1991–2000 the volume of this
market was $11.2 billion.
The cost of annual deliveries of civil helicopters is between 1/3 and 1/7 of the
respective military helicopter market. Demand for civil helicopters is rather stable,
whereas military sales are more variable.
Fuel prices have been the main factor in slowing down the growth of the civil
helicopters segment. At the same time, the market for corporate and administrative
helicopters is booming, with growth increasing almost four times during the years
1995–2000.
Busy and impatient business executives are creating stable growth for this
segment of GA either by buying or hiring helicopters since their use is no longer
considered to be prohibitively expensive. Recent years have shown growth in joint
ownership of helicopters, and this has become the key factor in the increase in the
demand.
Manufacturers have offered sharing schemes, such as “HeliFlight.” But overall
the concept of shared ownership of helicopter fleets will be limited due to their
flight range; however, the practical area for effective sharing does have its merits.
Corporate helicopters at the moment represent only a small share of the civil
helicopters market, which according to experts comprise only 2% of all civil
helicopters. The operating companies’ share of profit from helicopters is about 4%.
Nevertheless, this sector of the market still promotes sales of one or two
expensive models of corporate helicopters. The leader here is Bell/Agusta ВA609
helicopter with variable tilt rotor blades. Not surprisingly, manufacturers have
made serious investments in the development of new models for this segment of
the market. The Sikorsky S-76 has been modified to produce a new version (S-76C
+) which is priced at about $7 million.
Sikorsky boasts that the S-76 is used by more CEOs in the Fortune Top
100 largest companies than all others taken together, and since 1997 the members
of the British Royal Family have also been using it. If this company becomes
successful with promoting the scheme of shared ownership, then the market for the
S-76 will prosper.
In parallel, the Eurocopter Consortium has expressed a strong interest in the
business helicopter market and is offering the EC 155. This is not a newcomer, but
an improved version of the Dauphin helicopter.
Conclusion
A short overview of the market shows clearly that the numbers for aircraft in service
worldwide will continue to increase, leading to increasing challenges in air traffic
control and aviation safety. The GA segment shows steady growth, too.
The trend to more intensive use of aircraft puts pressure on safety management
schemes, most of them affecting the main interest of aviation companies—profits.
For example, narrow-bodied aircraft will be used for longer flights and without any
possibility to check their condition and detect potential safety threats in between
flights. A typical flight “turnaround” time for a budget airline is down from about
60 minutes to only 20 minutes! As Boeing proudly declares:
our aircraft only make money when they are flying
This intensification of aircraft use has led to increasing concerns about safety:
– The intensive use of aircraft creates problems for the implementation of safety
management schemes.
– Long-haul flights relentlessly stress the engines and airframe.
– Narrow-bodied aircraft are used for longer flights without the possibility to
check their conditions and potential safety vulnerabilities.
– Wide-bodied aircraft are used in both ways: similar to narrow-bodied aircraft
and for shorter flights with intensive use and frequent taking off and landing—
the most risky phases of flight.
– Highly manoeuvrable GA aircraft and helicopters are creating a concern for
safety management due to their wider risk distribution.
– The use of GA with less-qualified pilots and insufficient maintenance may create
even more serious safety problems
The overview further shows that GA aircraft have a significantly higher share of
the overall aircraft market. It is clear that the aviation market is suffering from
pressure in two conflicting directions:
1. An increase in the volume of flight operations in CA and GA, exposing an
increasing number of passengers to operational risk
2. An increasing level of safety risk due to faster turnaround of CA flights and poor
maintenance facilities for GA aircraft
Safety issues are becoming more and more important while at the same time
being “squeezed” at the operational level. This makes the use of both on-board
monitoring and on-ground detection more and more essential for control and
monitoring of aircraft conditions, and also makes the development of ASC for
safety a critically important priority.
Safety and Risk of Flight
This section provides an overview of existing flight risk, its profile and statistics.
Various types of flight risk are reviewed and a brief summary of the current aviation
safety landscape is presented, including GA safety.
Aviation Safety in Commercial Aviation
Statistically, during last 40 years aviation safety in CA has been improving. The
number of accidents has been reduced to about 1 per 5 per million departures
(Fig. 1.15) (Weener E., Boeing) [4].
In contrast, GA is far less safe than CA as will be shown by detailed data
presented here. It might be expected that new aircraft will be more reliable, and
that as their share of the whole fleet grows the safety of the aviation should be
improved. However, there are some doubts here. The trends in aviation safety
management are rather similar between sectors and unfortunately not very effec-
tive. In operation, new aircraft have a similar reliability to older aircraft.
The factors that influence risk and its profile are almost identical for aviation
across the board and are influenced by human factors (e.g., operator, flight crew,
maintenance, ATC personnel), equipment-related factors (e.g., airport, aircraft) and
external factors such as the weather and security; see Fig. 1.16. The recent delays
with the delivery of the Airbus A380 have been attributed to serious safety
problems.
Safety and Risk of Flight 25
30
Hull Loss Accidents
25
Worldwide Commercial Aviation − All Aircraft (Boeing)
20
15
10
Fig. 1.15 Accident statistics per million departures 1960–2000
Fig. 1.16 Main causes of Aircraft

aviation accidents (Source: 18 %
Weener E., Boeing)
Environment Personnel
27.6 % 54.4 %
Various organisations and bodies share responsibility for safety in aviation.

Firstly, manufacturers should design safer aircraft by developing and using
safety-enhanced technologies; and secondly, management of aircraft flight should
include effective schemes for safety, maintenance and operations, and provide the
most efficient documentation, training and support.
The common function of aircraft manufacturer and aviation companies should
be safety-related analysis and unconditional support of safety-driven initiatives.
In turn, operators should develop and follow a reliable operation policy, provide
clear and safe procedures, and publish and use training materials with aircraft
details to make them available for pilots and crew. They should also develop
maintenance programmes and follow maintenance policy and procedures, update
maintenance publications, develop a safety programme and provide the required
high-quality training.
Finally, government bodies and ATC should develop efficient rules and regula-
tions, develop and modernise navigation facilities, maintain operations, inspect and
modernise airport facilities and unify and improve air traffic control services within
each country as well as internationally. This understanding of aviation safety area is
accepted in both the USA and Europe. There is still much to be done, as presented
by E. Weener in 1998 [4]:
There are opportunities for preventing accidents in all segments of the air transport system.
However, we do not have an understanding of which segments offer the opportunities for
greatest leverage.
Only by analysing accident/incident data and applying judgment about future trends can
we determine which actions will be most effective.
The first sentence of this statement implies that a general model of aircraft safety
did not exist at that time. The second sentence indicates that safety management
will be based on after-flight analysis. It is also evident that the current practice of
basing safety management schemes solely on sporadic after-flight analysis is
doomed to failure, due to the current trends and commercial pressures already
mentioned. So, we need to analyse both of these aspects in order to improve flight
safety.
Main Risk Agents and Their Contribution
A review of the published statistics in US GAO (General Accounting Office),

GAO-01-916, “General Aviation Status of the Industry, Related Infrastructure,
and Safety Issues”, 2001, between 1988 and 1997, has shown that the main risk
makers were loss of control in flight, control flight in terrain (CFIT), sabotage,
mechanical malfunctions, etc.
These incidents include 618 fatalities where the cause was unknown (Fig. 1.17).
This shows that even when the flight information exists, it still isn’t always being
used effectively. Safety in CA and other segments of aviation can be improved by
focusing on these risk areas.
Many aviation accidents in the past have been attributable to the unexpected
malfunction of HW, e.g., sensors, engines, aircraft body, etc. In most cases,
however, though the root cause is once more attributable to human factors (52%
of all accidents) and more specifically to management failures, including the
absence of maintenance actions or the use of incorrect or inadequate maintenance
and parts.
In addition to US safety analysis, recent 2003–2005 European data of aircraft
accidents and incidents have highlighted the main categories of accidents and their
reasons. A special column is introduced to show potential for improving safety
using active system control techniques on-board the aircraft.
Figure 1.18 provides an analysis and summary of some aviation accidents and
incidents over a 2-year period (source: German “Bundesamt für
Unfalluntersuchung,” the federal office for accident investigation) (http://www.
bfu-web.de/berichte/index.htm).
The contents of the table indicate that if the principle of active system control
were applied to the aircraft safety systems, then the majority of accidents and
incidents in European aviation could be averted, and this offers an excellent
opportunity for further safety improvement.
2000
1827
1667 Worldwide Airline Fatalities

Classified by Type of Aircraft 1988 - 1997
1500
Number of Fatalities
1180
1000
820
Total fatalities – 7,966
618
506
500
372
238 203
134
127 121 91 58
4
0
Loss of CFIT Sabo-tage/ Mech- Un- Mid- In- Fuel Misc. Ice/ Other Fuel Wind- Runway Loss of
control hostile anical known air flight tank accident snow environ- starva- shear incursion ground
in flight action* Malfunc- collision fire explosion mental tion control
tion
Number
of fatal
32 21 15 17 12 2 3 2 20 4 8 7 2 11 2
accidents
(158)
Note : • Includes multiple non-onboard fatalities * Exceptions to statistical accident definition

Single fatality, non-onboard accidents are excluded
• (except King Air runway incursion 1/18/90)
CFIT = Controlled Flight Into Terrain
Fig. 1.17 Boeing statistics of world accident fatalities (Source: Weener E., Boeing)
Risk Factors and Flight Phases
The lifecycle of flight can be split into five phases: taxi-out, climbing, in-flight,
descent, taxi-in. These phases are characterised as follows:
1. Taxi-out phase: from the parking position to the runway
2. Climbing phase: acceleration on the runway, taking off; ends at cruising altitude
3. In-flight phase: at cruising altitude; ends when aircraft starts descent
4. Descent phase: includes descending and landing on the runway
5. Taxi-in phase: from the runway to the respective parking position
Figure 1.19 illustrates the proposed classification of flight phases. Theoretically,
the most risky phases of flight are taking off and landing. Initially, aircraft operates
in two dimensions and on take-off it operates in three dimensions, when the speed
of an aircraft Va exceeds the take-off threshold speed Vto: Va > Vto.
In turn, landing—transitioning from three-dimensional movement to
two-dimensional movement—is even more dangerous because this phase requires
much more precise speed control. The landing speed must be within a small
window between the recommended landing speed, for example, 240 km/h for
some CA, and the maximum allowed landing speed, for example, 280 km/h. The
values vary for various aircraft, and critical here is not a concrete value but
requirements for speed to be within recommended limits.
The risk of each phase of flight is illustrated by statistics given in Fig. 1.20,
where
Date Place Aircraft Damage Reason Prevention
wrong departure heading;

21- Socata TB-20 Trin-
CZ – Brno Crash excessive demands on pilot when trying to Yes
12-02 idad
change the heading manually
17- D – Hahn Cessna 414A Crash after insufficient and mistakable communication
12-02 touching tree between cockpit crew and ATC
tops - insufficient meteorological and navigational Yes
preparations according to bad weather
conditions
03- D - Munich Airbus A300-600 Serious mal- - software error
12-02 function of - insufficient maintenance works Yes
autopilot - lack in certification procedure of Yes
EUROCAE
29- D – Dortmund Boeing B737-800 Tail touched - aircraft was operated within eligible balance
11-02 runway point position Yes
divergences in the standards used
20- D Walden- Christen Industries Crash aircraft overloaded Yes

10-02 burg- Pitts S-2B overestimation of pilot’s capabilities N/A
Sailach
16- D – Pader- Fairchild Dornier Serious inci- coverage of yaw rudder torn Yes
10-02 born- DO 228-200 dent non-following to safety procedures Yes
Lippstadt
29- CH – Basel Cessna C551 Ground con- - non-adherence to regulations by the crew
N/A
09-02 tact before - bad weather conditions
runway - crew was not qualified to CAT III landings
- aircraft was not applicable for CAT III
N/A
- no certification of airline for CATIII
01- D - Über- Boeing B757-200 Collision - wrong orders from ATC N/A
07-02 lingen /Tupolew TU 154M during flight - cockpitcrew followed the wrong orders of Yes
ATC instead of the advices of the TCAS
24- D – Stuttgart Cessna 172P / Collision on - insufficient communication between Cessna

N/A
06-02 Boeing B717 ground and ATC concerning other traffic
- insufficient caution in both aircraft for the
Yes
other traffic when taxiing to the runway
- non-adherence to standard procedures Yes
28- DK – Jord- Cessna A185 E Crash during - pilot did not pay attention to instruments
Yes
05-02 sans Skywagon water landing alert, that landing gear was still down
Flak
05- D – Dresden Aerospatiale ATR Aircraft de- - cockpit crew mistook runway border
03-02 72-212 stroys illumination for the runway center N/A
runway illumination
illumination
28- D – Aichach Beech Aircraft Crash - bad weather cond-s N/A

11-01 B95A - stall because of frosted wings Yes
08- I – Milano Cessna 524A / Collision on - bad weather cond-s CAT III N/A
10-01 McDonald MD 87 ground - airport apron correlating ICAO standards N/A
- inadvertent runway incursion by Cessna N/A
- ATC did not remark collision risk Yes
18- D – Ober- H. K. Aircraft Crash - overestimation of pilots capabilities N/A

09-01 mehler Techn. AG/Wega - loss of aircraft control Yes
100
13- D – Stade Piper PA-28-161 Collision with - pilot didn’t notice contact wires Yes
08-01 a contact - reaction time too short Yes
wire
05- DK – Narsar- Dassault Falcon 20 Crash - CFIT accident Yes

08-01 suaq (Green- - Flight crew was no aware of proximity to Yes
land) mountainous terrain
- Flight crew did not follow SOPs N/A
- GPWS was inoperative Yes
- Flight crew was exposed to peak fatigue Yes
- Absence of CRM N/A
Fig. 1.18 Possible prevention of accidents if ASC were implemented

a. Taxi-out b. Climbing c. In-flight d. Descent e. Taxi-in

phase phase phase phase phase
Fig. 1.19 Typical flight phases
Vlmin < Va < Vlmax
Unfortunately, the statistics support the hypothesis that take-off and landing are
the most risky flight phases, in spite of their relatively short duration in comparison
to the other phases.
The crew, during take-off and landing, must control the aircraft, change altitude
and speed, communicate with air traffic control (ATC) and/or other aircraft, and
maintain separation from obstacles and other aircraft.
Aircraft systems are also stressed during these phases due to simultaneous
changes to engine power settings, the possible operation of retractable landing
gear, flaps, slats, and spoilers, and changes in cabin pressurisation.
Wind and weather conditions are also much more dangerous at low altitudes.
The landing-related phases of flight have the largest percentage of total acci-
dents: landing (27.3%), manoeuvring (14.8%), approach (11%), descent and
go-around all create danger (57.8%).
The statistics will obviously vary for different aircraft types due to different
amount of time spent in each phase and particular hazards associated with the
aircraft and the type of operational use. Even so, the risk profile will generally be
similar to the data presented in the table in Fig. 1.20.
Some risks are aircraft specific, for example, with helicopters the most danger-
ous phase is manoeuvring during hover 36% and carrying external loads. In
contrast, the largest percentage of accidents involving single- and multi-engine
piston aircraft occurs during landing.
Taxi Takeoff Climb Cruise Descent Manoeuvre Approach Go Landing

or Hover Around
4.1% 19.6% 3.6% 14.9% 2.7% 14.8% 11.0% 2.0% 27.3%
Fig. 1.20 Distribution of aircraft accidents by flight phase (Source: NTSB 2004)
Risk and Safety in General Aviation
The risk and safety aspects of general aviation are similar to other aviation
segments, although the size of GA aircraft and their equipment and management
schemes are different from CA. This section defines specific safety features in GA.
Accident Statistics
The main risk agents in GA are the same as for the majority of aviation, though
there are specific features due to the nature and environment of GA operations. The
GA accident data used in this analysis has been accumulated from US, Australian
and UK sources, which includes the vast majority of global GA applications.
US GA Accidents
FAA data (US GAO 01-916,” 2001) about accidents in GA (1996–2003) shows no
substantial improvement in safety and GA. At 1.36 accidents per 100,000 h the rate
is certainly the “poor relative” in comparison with CA where the number of
accidents is estimated to be 4.8 per million departures; see Fig. 1.21. Human factors
and performance dominate GA accident statistics as the major cause in the USA. Of
the 1468 accidents that were related to human factors in 2000, the most frequently
cited cause/factors were aircraft handling and control (65.6%), followed by plan-
ning and decision-making (41.1%) and use of aircraft equipment (12.2%). Issues
related to personnel qualification were cited in almost half of the 209 accidents with
underlying explanatory factors related to human performance. Examples of quali-
fication issues that were cited in the year 2000 accident records include lack of total
experience, lack of recent experience and inadequate training.
The annual review of US GA accident data, compiled by the NTSB, highlights
the following:
– The fatal accident rate in the USA for personal flying remained the highest of all
GA categories (for the year 2000), with 1.61 fatal accidents per 100,000 hours
flown.
– In contrast, the corresponding fatal accident rate for instructional flights was
0.63 fatal accidents per 100,000 hours. Instructional flights included an experi-
enced pilot, the instructor, in addition to the student.
Risk and Safety in General Aviation 31
Year Total Fatal Fatalities Hours Accident Fatal

Accidents Accidents Flown Rate Accident Rate
(per 100,000 (per 100,000
flight hours) flight hours)
2003 1,732 351 626 25,800,000 6.71 1.36
2002 1,713 345 581 25,545,000 6.71 1.35
2001 1,726 325 562 25,431,000 6.79 1.28
2000 1,837 345 596 27,838,000 6.60 1.24
1999 1,905 340 619 29,246,000 6.51 1.16
1998 1,904 364 624 25,518,000 7.46 1.43
1997 1,845 350 631 25,591,000 7.21 1.37
1996 1,908 361 636 24,881,000 7.67 1.45
Fig. 1.21 US GA accidents, fatalities and rates until 2003 (Source: FAA GAO-01-916)
– In GA accidents in the USA in 2000, for which pilot total flight experience data
about the pilot are available, 46.6% involved pilots with a total flight time of
1000 hours or less. The largest percentage of accident pilots in this group had
200 hours or less of total flight time.
– Of the 1527 accidents in 2000, 82.4% involved pilots with 1000 hours or less of
time in the accident aircraft make and model, or less.
– Most accident pilots in this group (68.2%) had less than 200 h of total flight time
in the accident aircraft type.
– Night-time fatal accidents were more than two-and-a-half times more likely than
daylight ones.
– Weather-related accidents and accidents at night are more likely to involve
disorientation, loss of control, and/or collision with objects or terrain that result
in higher levels of injury.
Australian GA Accidents
Comprehensive statistics on GA accident and fatality rates were obtained from the
Australian Transport Safety Bureau (Figs. 1.22 and 1.23) (ATSB, Australian
Transport Safety Bureau website, 2005).
Clearly, GA private, business and agricultural operations give rise to the highest
rate of accidents and fatalities. The accident rate of GA in Australia is almost
double that of GA in the USA, whereas the fatal accident rate is nearly the same (per
100,000 flight hours). This may be due to different use, traffic density and terrain in
the two countries.
Analysis of the statistics shows the following:
– Of all types of use for GA aircraft, GA private/business and agricultural oper-
ations give rise to the highest rate of accidents and fatalities.
Accident rate
1991 1992 1993 1994 1995 1996 1997 1998 1999 2000
(per 100,000 hours)
GA Charter 8.26 9.09 11.10 11.47 8.96 7.03 10.07 8.24 4.13 5.33
GA Agricultural 22.69 31.24 24.50 18.41 28.10 26.28 24.83 23.73 17.83 18.03
GA Flying Training 6.54 5.85 8.13 6.32 8.25 5.77 8.35 4.96 7.04 9.59
GA Other Aerial Work 12.07 12.12 12.23 8.75 6.13 9.23 10.80 5.32 5.74 9.85
GA Private/Business 27.24 24.01 24.34 18.77 20.31 18.56 16.60 21.18 16.43 21.4
Total 14.81 14.11 15.02 12.07 12.26 11.28 12.45 11.08 9.01 11.67
Fig. 1.22 Australian GA accidents 1991–2000 (Source: ATSB 2004)
Fatal Accident Rate

1991 1992 1993 1994 1995 1996 1997 1998 1999 2000
(per 100,000 hours)
GA Charter 0.52 0.49 1.01 1.40 0.64 1.24 0.82 0.40 0.59 0.62
GA Agricultural 0.91 3.36 1.02 4.60 1.94 3.19 3.65 1.36 0.00 2.58
GA Flying Training 0.65 0.23 0.00 0.47 0.23 0.00 0.00 0.21 0.22 0.00
GA Other Aerial Work 0.34 0.38 1.05 1.30 1.29 1.37 0.32 0.63 0.31 0.73
GA Private/Business 2.78 3.89 2.91 1.96 2.71 2.01 1.57 3.72 3.70 2.17
Total 1.20 1.51 1.29 1.47 1.25 1.28 0.92 1.22 1.13 1.00
Fig. 1.23 Australian GA fatalities 1991–2000 (Source: ATSB, 2004)
– The accident rate of GA in Australia is almost double that of GA in the USA,

whereas the fatal accident rate is nearly the same (per 100,000 hours of flight)
UK GA Accidents
Similarly to the US NTSB, the UK Civil Aviation Authority (CAA) provides a

substantial analysis of accident statistics in GA. The difference here is that in the
UK the CAA investigates GA accidents aiming to classify the most dangerous types
and accident causes and addresses them as a priority.
The data below covers period 1985–1994. The UK CAA highlights four types of
GA accidents: control flight in terrain (CFIT), loss of control in visual meteorolog-
ical conditions (LOC VMC), low flying/aerobatics (LOW/AERO) and loss of
control in instrument meteorological conditions (LOC IMC). The total share of
these four types of exceeds 67.5% of all GA accidents over the specified period in
the UK as shown below in Fig. 1.24.
Loss of control was the predominant factor, occurring in several types of
accidents, e.g., loss of control in visual meteorological conditions, instrument
meteorological conditions and in aerobatics/low-flying events. Other causal factors
of fatal accidents include:
Risk and Safety in General Aviation 33
Unknown
5% CFIT
21 %
Other
9%
Propeller
3%
Performance
3%
Mid Air LOC VMC
4% 20 %
Technical
8%
LOC IMC LOC / AERO
8% 19 %
Fig. 1.24 UK GA accident types 1985–1994, 2000 (Source: CAA 1997)
– Illegality: In 21% of fatal GA accidents, an “illegal” factor was identified. In

many cases the circumstances suggested that pilots were knowingly breaking the
law. Education is likely to be more effective than further legislation or stricter
enforcement.
– Poor Clarity/Availability of Information: For a flight to be legally and safely
conducted, article 38(a) of the Air Navigation Order (ANO) of the UK requires
the commander to take into account the latest information on the route, aero-
dromes, weather, etc. Lack of appropriate information was a factor in a number
of accidents. Although the availability of weather information is much
improved, Notices to Airmen (NOTAMs) are frequently criticised by GA pilots
on the grounds of availability, level of clarity and presentation. A pilot needs to
be able to readily find in the NOTAMs the relevant information for his or her
flight.
– Human Factors: the majority of causal factors had a human factors element
either in terms of pilot or maintenance actions.
In a review of flight phases, statistics in UK 1994–1996 (UK CAA, Safety
Regulation Group, 1997), (UK CAA, Safety Regulation Group, “CAP 667—
Review of General Aviation Fatal Accidents 1985–1994,” 1997) and similar
CAA/NTSB data show that the vast majority of GA accidents occur during the
landing phase (~53%) while the most fatal accidents (64%) are related to the initial
climb and cruise phases (Fig. 1.25).
Among other fatal GA accidents the most frequently cited reason is weather. GA
aircraft are much more affected by weather, e.g., when conditions reduce or block
visibility. These conditions are usually called: “low ceiling,” “fog” and “cloud.”
Accidents under conditions of low visibility typically involve either loss of aircraft
control and/or collision with obstacles or terrain, both of which are likely to result in
severe injuries, fatalities and aircraft damage.
350
Reportable
295
300
Fatal
Number of Accidents
250
200
150
100
73
53
50 37
27 33
7 8 4 1 17 5 2 4 3 10 1 6 3 2
0
Parked Taxi Take - Initial Climb Cruise Descent Approach Landing Circuit Aerobat Unknown
off Climb / flight / other
Flight Phase
Fig. 1.25 UK GA fatal accidents per flight phase 1994–1996 (Source: CAA 1997)
Flight Risk Analysis
[Reason] must approach nature in order to be taught by it. It must not, however, do so in the
character of a pupil who listens to everything that the teacher chooses to say, but of an
appointed judge who compels the witnesses to answer questions, which he has himself
formulated. Kant, Critique of Pure Reason (Bxiii)
Accident investigators and safety researchers try to determine the causes of

accidents. There is a common understanding that the vast majority of accidents
are caused by a sequence of causal events rather than being the result of random
events. In the literature and corporate research, the most widely used technique to
capture these causal links is called fault tree analysis. The most comprehensive
forum in this area is the annual International System Safety Conference (ISSC).
The majority of aviation accidents, including the GA sector, are associated with
flight phases. By following the structure of the fault tree, an analyst can investigate
possible sequences of events with the objective of improving safety for similar
aircraft. Knowing the profile of risk occurrence makes it possible to concentrate on
accidents/sequences of events of a particular type.
Boeing studies of transporter aircraft accidents [4] found that most accidents
result from a sequence of events rather than a single catastrophic event. Research
identified as many as 20 events in a single flight that directly influenced the flight
and culminated in an accident.
NTSB uses a similar method to break down each accident into
“occurrences”(NTSB, 2000). The objective of such studies is to prevent future
accidents by learning from the past.
Flight Risk Analysis 35
First Occurrences and Sequence of Events
An accident’s first occurrence and the phase of flight during that occurrence
indicates how and when an accident starts. An accident can also be viewed as a
chain of all the relevant accident occurrences cited in the order in which they
happen. Accident events may include a combination of multiple occurrences, with
many possible combinations. From available data in 1822 GA accidents that
occurred during 2000 in the USA, 407 unique combinations of accident occurrences
were cited.
NTSB accident reports document the circumstances of an accident as “accident
occurrences” and the “sequence of events.” Occurrence data can be defined as what
happened during the accident. A total of 54 occurrence codes are available for
NTSB reports to describe the events for any given accident. Because aviation
accidents are rarely limited to a single occurrence, each occurrence is coded as
part of a sequence, with as many as five different occurrence codes in one accident.
For accidents that involve more than one aircraft, the list of occurrences may be
different for each aircraft.
Occurrence data do not include specific information about why an accident may
have happened. Among the eight major categories of first occurrences, the largest
percentage of accidents (26.4%) included occurrences related to aircraft power.
Among the individual occurrences, the most common involved a loss of control
either in flight (14.4%) or on the ground (12.3%). Although occurrences involving
loss of aircraft control on the ground resulted in only 1 fatal accident in year 2000,
loss-of-control occurrences in flight resulted in a total of 110 fatal accidents—
nearly one-third of all fatal accidents and more than twice that of any other single
occurrence.
Figure 1.26 displays the percentage of accidents for aircraft in each phase of
flight at the time of first occurrence, as per the NTSB records for the year 2000 in
the USA. The phase of flight can be defined as when, during the operation of the
aircraft, the first occurrence took place. The upper set of numbers in the figure
represent the percentage of all accidents that occurred in each phase, and the
numbers in parentheses indicate the percentage of all accidents that were fatal.
The landing phase has the largest percentage of total accident first occurrences
(27.3%), but only 2.9% of fatal accident first occurrences. The largest percentage of
fatal accident first occurrences (33.4%) occurred during the manoeuvring phase of
flight, but only 14.8% of all accident first occurrences occurred during this phase.
Accidents that occur during cruise and manoeuvring are more likely to result in
higher levels of injury and aircraft damage due to the higher speeds and altitudes
associated with these phases of flight.
Standing Takeoff Climb Cruise Descent Maneuver Approach Go- Landing

Taxi / Other / Hover Around
4.1% 19.6% 3.6% 14.9 % 2.7% 14.8% 11.0% 2.0% 27.3%
(0.6%) (15.6%) (6.1%) (22.3%) (3.8%) (33.4 %) (14.3 %) (1.0 %) (2.9 %)
Fig. 1.26 First occurrence and flight phase accident statistics
Causes and Factors of Accidents
In addition to coding accident occurrences in the USA, the NTSB makes a deter-
mination of probable cause. The objective of the probable cause statement is to
define the cause-and-effect relationships in the accident sequence. The probable
cause could be described as a determination of why the accident happened. In
determining probable cause, the NTSB considers the facts, conditions and circum-
stances of the event.
Within each accident occurrence, any information that helps to explain why that
event happened is identified as a “finding” and may be further designated as either a
“cause” or “factor.” The term “factor” is used to describe situations or circum-
stances that contributed to the accident cause.
The details of probable cause are coded as the combination of all causes, factors,
and findings associated with the accident. Just as accidents often include a series of
events, the reason why those events led to an accident reflects a combination of
multiple causes and factors.
An accident sequence may begin with an explosion in the engine compartment
of a single-engine aircraft due to, say, a fuel leak. Because of the explosion, the
aircraft engine may then experience a complete mechanical failure and the pilot
may make a forced landing. In these circumstances the pilot may not be able to
control the aircraft and so impact with trees during landing. The fuel leak and
resulting explosion may be cited as causes in the findings of this accident.
Smoke in the cabin, and the pilot’s resulting reduced visibility, may also be cited
as factors. An oil leak, oil exhaustion, over-heated engine bearings, fractured
connecting rods and a fractured crankcase have all also been cited in the findings,
but were not identified as causes or factors. The various causes and their sequence
are usually analysed and documented using fault tree analysis.
To simplify the presentation of probable cause information in most cases, the
hundreds of unique codes used by investigators to identify the probable cause are
grouped into broad cause/factor categories.
This broad cause/factor classification provides an overview of fundamental
accident origins by dividing all accident causes and factors into three groups:
aircraft, environment and personnel. Personnel-related causes or factors were cited

in 89% of the 1758 GA accident reports for 2000 in the USA, for which cause/factor
data were available.
Environmental causes/factors were cited in 45% of these accident reports, and
aircraft-related causes/factors were cited in 29%. In the year 2000, only 74 of
792 environmental citations (9.3% of all environmental causes/factors) were listed.
For example, rough terrain might be cited as a contributing factor, but not a cause,
to explain why an aircraft was damaged during a forced landing due to engine
failure. In that case, the origin(s) of the engine failure would be cited as “cause,” but
the terrain would be cited as a factor because it contributed to the accident outcome.
A further common cause or factor of GA accidents is the weather. Because GA
aircraft are smaller, slower and more limited in maximum altitude and range than
CA aircraft, they can be more vulnerable than larger aircraft to hazards posed by
weather.
Smaller aircraft are affected to a greater degree by adverse wind conditions, and
precipitation, icing and convective weather have a greater effect on aircraft that
lack the speed, altitude and/or range capabilities to avoid those conditions.
Weather conditions cited most often as a cause or factor in GA accidents are
related to winds, including “crosswind,” “gusts” and “tailwind.” Of the top five
environmental causes/factors cited in GA accidents in the year 2000 in the USA,
three were related to wind. The effects of wind during take-offs and landings are the
most severe for GA.
Conclusion
Statistics of accidents show that existing risk analysis is based on after-flight

procedures and data processing. So a number of conclusions can be drawn:
– The main techniques used to determine possible causes of an accident are fault
tree analysis and the analysis of the sequence of events/factors leading up to the
accident.
– Unfortunately, the approaches to safety management and above-mentioned
techniques are conservative in nature and do not lead to any immediate improve-
ment of flight safety. These approaches are derived from existing safety envi-
ronment and management approaches which are based on more static, rather
than dynamic, ways to improve safety.
– A new approach to safety management and modelling accident analysis/preven-
tion is required which takes account of the varying risks during the different
phases of flight and dynamically adapts the safety strategy accordingly.
U.S. Safety Environment

Accidents
and
Public Incidents
Congress
NTSB NASA
Media
FAA
Engine Unions
Manufacturers
ATA
Airframe
Manufacturers Airlines
3/11/98 STR-034Wa
Fig. 1.27 Safety management infrastructure in the USA
Safety Management Scheme
The process of safety management has two main aspects focused on the develop-
ment of new regulations and administration of flight operations, e.g., promoting
best existing practices, training pilots, licensing airports and assuring of airworthi-
ness of aircraft.
Aviation safety is becoming more and more complex. The safety management
infrastructure in the USA is the best developed so far; this reflects its market
domination over several decades. Its general organisation is illustrated in
Fig. 1.27 from [4].
When an accident occurs, the NTSB makes an investigation, and then based on
those findings the NTSB, FAA and NASA provide objective analysis and recom-
mendations (so-called X blue lines Y) for the consideration of engine manufac-
turers, airframe manufacturers and airlines. In turn, they then respond to requests by
proposing practical actions to avoid similar accidents in the future.
Recently, Europe has centralised and improved its safety management by
expanding the number of bodies and organisations involved in safety regulations
and initiatives. The 2002 European Parliament Directive on “Occurrence Reporting
in Civil Aviation” established an aviation safety management regime similar to that
in the USA.
The leading European organisation in air traffic management is Eurocontrol,
which during 2002–2004 delegated most of its functions related to aviation safety to
new organisations such as EASA and EUROCAE. All three bodies are funded by
both the EU and national regulatory authorities, and work in collaboration with the
main European transport regulatory and funding bodies such as DG TREN (www.
tren.eu.int).
In practice, EU initiatives in aviation safety have been concerned mainly with
human factors, for example, training and inspections, and sadly have failed gener-
ally to increase safety levels for CA or other types of aviation.
In fact, initiatives in both the USA and EU have had only a small impact on
aircraft safety in terms of real-time of flight, that is, when safety is most relevant, as
shown in Fig. 1.27 based on figures from Boeing. They have targeted mainly
strategic schemes, improving aviation safety mostly in principle but not in practice.
Initiatives to determine the technologies and requirements for safety systems
have led to various worldwide safety programs discussed at symposia and aviation
forums. Two the most representative ones are the International System Safety
Society Conference (USA) and Jane’s ATC Annual Symposium (Maastricht).
The most important fact of modern development of safety management schemes
is recognition of requirements for a consistent and robust scheme of flight safety
management, as pointed out at the Arlington Symposium [5]. Whether or not the
aircraft hits the ground should ideally not change the philosophy to determine what,
why and how to prevent an accident.
Insurance, Regulation and Aviation Safety
The most common types of policy for insuring aircraft operations are:
1. Aircraft physical damage coverage, which covers the risk of potential damage to
the aircraft itself and/or the associated equipment
2. Aircraft liability, which covers the risk of potential damage to third parties, i.e.,
damage to passengers, crew or other persons and/or their property
It is only possible to purchase an aircraft physical damage coverage insurance
policy when purchasing an aircraft liability insurance policy.
Each insurance policy is provided on an agreed-value basis, that is, the insurance
company and the customer agree (before a loss) on the insured value of the aircraft.
In an aircraft policy, a so-called replacement value does not exist.
For that reason, when negotiating the policy terms (or the renewal), the customer
should insist on a value limit, which would allow the replacement of the aircraft in
today’s market. Liability coverage limits are provided in $5 million increments. In
operation of corporate jets, the typical limits are considered to be at about $5
million per seat. In the USA, it is quite common for a corporate operator of an
eight-seat jet to carry about $100–200 million in liability coverage.
Good aviation insurance policies cover a substantial range of cases. For exam-
ple, coverage of physical damage is valid for all cases, except intentional damage or
nuclear war. Typical exclusions for wear and tear are tire wear and compressor
blade erosion.
Liability coverage should protect the customer from most lawsuits relating to
their aviation operations by employees. For these kinds of claims, a special scheme
of workers compensation insurance has become available.
Insurance involvement in CA and BA is well established because of the tight
regulations that are enforced, while GA is in a rudimentary phase. Two main
reasons are that GA has a much riskier and less predictable accident rate than any
other segment of aviation, and also the weakness of its safety management schemes
and regulation. To attract insurance companies to the GA market segment will
require tighter regulation and more rigorous enforcement. This has already hap-
pened in other transport sectors: cars (annual safety tests) and trucks, buses and
trains (tachograph and random weight and driver tests).
Flight Safety and Safety Control Cycles in Aviation
The previous sections have shown the role and importance of recording flight data
for further analysis of flight conditions. The need for understanding the reasons
behind accidents is widely recognised.
However, the existing schemes of safety management are oriented mostly on
post-flight analysis and cannot be used for real-time safety monitoring and control
of flight safety. In general, flight recorder information is overwritten during the next
flight and so data for longer-term analysis is lost.
A typical cycle of safety management for an aircraft is shown in Fig. 1.28. Flight
data from the aircraft are downloaded and transported on the ground using a
portable carrier such as a tape cassette or solid-state memory. More recently, the
introduction of satellite facilities has provided an opportunity to download flight
information in real time via a satellite. Flight data can then be stored and analysed at
a ground data centre to evaluate the safety aspects of the flight, possibly in real time.
At the end of each flight the data can be processed to evaluate flight conditions in
order to diagnose faults in the aircraft’s HW and systems to make recommendations
for aircraft maintenance. A licensed engineer then makes the decision as to whether
the aircraft is airworthy.
Sometimes, if the facility is available, the engineer may call for information
from the flight data recorder to be evaluated, for example, to determine whether a
heavy landing is likely to have done some physical damage. For long-term analysis,
processed flight data can be stored in a centralised data repository where it can be
analysed for safety trends over several flights or even the lifespan of the aircraft.
The media used to record flight data include various types of data cassettes and
portable devices such as autonomous hard disks, and more recently solid-state flash
memories [6].
In general, the cycle is designed to assess and improve safety during flight using
data analysis after the flight. If an accident has happened, then a more formal
scheme for flight data processing is used. Government accident investigators
GPS
• data recording
• archiving
• monitoring of hardware
• control
• registration
• checking of pilot
• analysis
• control
• decision
• express analysis
• checking the transporting of:
• hardware, • data processing
hardware
• data, • analysis
• diagnosis
• repair of • instruments
hardware
Fig. 1.28 Conventional cycle of information processing of flight information
become involved so the investigation and its results are incorporated into wider
safety management schemes.
Constraints and Failures of Safety Management
Although flight safety has improved significantly over the past 50 years, the ever-
increasing volume of air traffic is causing the number of accidents to rise. This is
especially true for GA and private pilots who often have a lax approach to safety
and consider regulations to be intrusive, particularly in the USA.
Therefore, any newly proposed system, such as active safety, must offer an
unobtrusive yet unprecedented improvement in flight safety if it is to be welcomed
and used by them. The costs associated with flight safety equipment are already
seen as “overhead.”
Even though there are about 300,000 GA aircraft in the world, GA is still
considered to be the poor relative by avionics companies. A major problem is the
sheer variability between aircraft even of the same type, as well as the need to
produce equipment for GA with a much lower purchase cost than for CA.
Furthermore, GA safety checks tend to be limited as normally there is no flight
data recorder and so safety management is based on the experience and visual
checking of the mechanics, engineers and pilots involved. The safety cost of this is
reflected in the accident statistics: human factors account for some ~53% of the
primary cause of GA accidents. The “soft” regulation of GA and the lack of strict
enforcement also constrain improvements in safety management.
Fig. 1.29 Failures of safety

management Safety Management Failings by Cause %
Airframe and Power Plants 32.90

Pilot/Owner and operator licensing 12.97
Past overhaul time 3.78
Past or no 100 hour inspection 3.24
Past or no annual inspection 1.62
Safety critical negligence issues include the use of incorrect or substandard

and/or improperly installed parts, missing parts or failure to follow airworthiness
directives (ADs) (CFR 1998). In addition, poor maintenance of the airframe and
power plant (A&P) by mechanics (regulated by CFR Part 43) is a major safety
issue.
Many GA pilots, owners or operators fail to adhere to the required 100-hour
inspections and even annual inspections and service overhauls.
The actual percentages of failures in the practice of safety management [7] are
listed in Fig. 1.29, which
Figure 1.29 confirms that GA safety needs to be managed in a different way, but
not necessarily by means of installations of the sophisticated and expensive flight
data recorders favoured by avionics manufacturers—nor by means of new regula-
tions and penalties favoured by the FAA, NTSB, EAA and EASA.
The first option is considered as unacceptable in GA due to its initial costs,
installation and maintenance expenses. The second option is considered as unac-
ceptable due to the difficulty of implementation as more than half of GA pilots/
users/owners use their aircraft in remote areas. In the USA, there are more than
19,000 landing fields for GA, many of them barely more than fuel refilling points.
The tracking of aircraft and flight maintenance by regulators is practically
impossible. So, the old approach continues: with the only really objective informa-
tion related to the safety of aircraft recorded by flight data recorders and thorough
analysis of the data usually post-accident. Even worse, the vast majority of GA
aircraft do not have a flight data recorder at all.
Conclusions
A classification system for aircraft has been proposed with the aim of capturing a
technical portrait of a typical GA aircraft including design, technological and
management features. The CA and GA often overlap, and CA has by far the best
safety record in aviation. It is likely that the GA flight data recording and safety
management will follow the direction of CA in the future.
Analysis of the aviation market shows steady growth both in volume and price of
aircraft in all segments. As the complexity of new aircraft grows, the cost of
maintenance will inevitably follow. This is creating a challenge for safety
management, making it essential to search for improvement of existing safety

management schemes.
Existing schemes of safety management in aviation are mostly focussed on after-
flight analysis (CA, military) or are rather weak (GA). All these schemes are easily
avoidable by GA aircraft owners and users; the “human” factor being the weakest
link in the chain. The situation gets progressively worse as the complexity of
aircraft increases and as they are used more intensively.
Unfortunately, in the present situation safety management vies with the com-
mercial interests of owners and operating companies involved. Safety margins are
being eroded in CA and BA due to tighter turnaround times and lower budgets.
In GA, new aircraft are safer than ever, within their class, but new aircraft are
becoming popular, for example, personal and business jets, and the operation of
these introduces new hazards and requires tighter regulation. So far, strategic
management of safety has not achieved its target. A typical snapshot from the
FAA’s February 2005 data is shown in Fig. 1.30 [8]. Even the CA sector suffers
from significant incidents, but the GA sector (shaded) has most of the fatal accidents.
So far, it seems to be clear that operating within the current regulatory frame-
work for safety and merely collecting flight data is not leading to any overall safety
improvement. A new, proactive safety management scheme for aviation at large,
and GA in particular, is required. It is also clear that the level and nature of risk
varies according to different operational phases of flight and are major factors that
need to be taken into account.
Improved regulation and mandatory insurance can contribute to improved safety
in GA. Based on this analysis, it is fair to say that there is a need for a method and
equipment to improve flight safety. In particular, some low-cost means of flight data
recording and assessment of operational safety in real time is needed.
Topic Number of Aviation Incidents

FAA Accident Category 25 24 23 22 21 18 17 16 15 14
All Aircraft Events 3 5 11 29 0 8 7 6 6 19
Fatal Accidents 0 0 2 2 0 1 1 1 2 1
Experimental/Homebuilt 0 0 1 1 0 0 1 2 1 4
FIXED WING
Airbus 0 0 0 2 0 0 0 0 0 0
Boeing 0 1 1 5 0 0 1 0 0 1
Beech 1 1 1 1 0 1 1 2 2 1
Cessna 2 2 2 4 0 2 1 1 2 4
Piper 0 0 3 6 0 1 1 0 0 3
Other Fixed Wing 0 1 2 8 0 3 2 1 0 5
ROTORCRAFT
Bell 0 0 0 2 0 0 0 0 0 0
Other Rotorcraft 0 0 1 0 0 1 0 0 1 1
Fig. 1.30 Aviation incident analysis

References
1. Schagaev I (1998) The concept of dynamic safety. In: Proceedings of international system
safety society conference, Sept, Seattle. https://www.academia.edu/7119860/The_Concept_of_
Dynamic_Safety
2. Overtoon E, Schagaev I, Miloslavin S (1999) Active safety system for general aviation. In:
Proceedings of 17th international system safety conference. Orlando, FL. http://www.system-
safety.org/Conference99/Orlando99.htm
3. Schagaev I (2001) Concept of active system safety. In: Proceedings of 15th IFAC symposium
on automatic control in aerospace, Bologna
4. Weener E (1998) Aviation safety. Keynote speech at ISSC, Seattle
5. International symposium on transportation recorders, 3–5 May 1999, Arlington
6. Schagaev I, Kaegi T (2015) System software design for resilient computers. Springer, Newyork
7. National Transportation Safety Board: summary of accident statistics. http://www.ntsb.gov/
aviation/Stats.htm. Accessed Oct 2016
8. FAA Statistics Home Page. http://www.faa.gov/data_statistics/. Accessed 29 Jan 2016
Chapter 2
Active System Control and Safety Approach,
and Regulation in Other Application Domains
Approach to Safety in Critical Systems
This chapter aims to analyse the currently available safety systems both in aviation
and other fields where safety is considered to be a critical aspect.
In addition, this section reviews the currently available aircraft safety systems
for general aviation (GA) operations and aspects affecting their design (including
the associated economics).
Drawing on an analysis of these safety systems—their deficiencies as well as
innovative concepts from fields other than aviation—a comprehensive basis for
specification and a practical and more effective approach for the future is proposed.
Safety systems are already well established in other transport domains that share
many characteristics with the GA domain. In this section, current approaches and
trends in the automotive, space and railway domains are surveyed, particularly for
on-board safety systems. The term “vehicle” is used to refer to a car/truck, space-
craft, train or plane, across all domains.
For a number of decades, the emphasis on safety systems in various fields of
application has been “passive”, for example, protective bars in a car’s frame and
data recorders for post-accident analysis. Increasing efforts have recently been
made to introduce systems that will react in the event of an accident/incident, or
the impending possibility of one, with the aim of minimising the effects of such an
undesirable situation in terms of both human and material losses.
Although these systems are classed as “active” by each related industry, they are
lacking in terms of both scope of application and capabilities when compared to the
principles introduced for active safety. For example, a car’s airbag might be
activated to minimise injury, but the vehicle immediately becomes undriveable. If
the activation is erroneous, then the consequences can be disastrous.

46 2 Active System Control and Safety Approach, and Regulation in Other. . .
Safety Approach in Industrial Systems and Machinery
Industrial systems span a wide spectrum of applications and sizes. From a safety
management viewpoint they fall into two main areas: (1) systems that protect
individuals from injury in the workplace and (2) systems that control dangerous
processes that could cause serious loss of life and/or environmental damage. As
with rail, space and aviation, major public accidents usually highlight the risks and
harms; these have led to regulations being put in place, for example:
• Chemical process plant, Bhopal, India: a huge chemical explosion followed by a
poison gas cloud drifting over a large city and its surrounding area. Hundreds
were killed and thousands injured at the time, followed by years of blight on the
local community and continuing environmental damage.
• Nuclear process plant, Chernobyl, Russia: nuclear reactor explosion and melt-
down. Safety system overridden by operators for experimental purposes.
Nuclear explosion and core meltdown, contamination over a wide area, thou-
sands of casualties and continuing long-term environmental danger.
• Concorde, Paris, France: rupture of fuel tank from runway debris, leading to a
crash and fire in a built-up area.
• Space shuttle, Florida, USA: launch attempted with rocket fuel seals below the
recommended temperature, leading to a cataclysmic explosion of the vehicle in
flight, killing the astronauts aboard.
• High-speed train, Eschede, Germany: a high-speed train derailed and crashed
into a road bridge. A total of 101 people died and around a hundred were injured.
The crash was caused by a single fatigued crack in one wheel, which, when it
failed, caused the train to derail at a set of points (switch).
Approach to Safety in Process Plants
High-profile accidents have gradually led to a much tighter definition of responsi-

bility for safety and also mandatory use of safety analysis and design techniques to
prevent, avoid and/or mitigate harm. Typically, in safety-critical process control
applications (e.g., chemical, nuclear) highly available systems are needed to sup-
port continuous (i.e., uninterrupted) operation of the plant.
This is often achieved by duplicated or triplicated systems, with voting being
used to compare the results of each control channel, to guard against through-life
software and hardware failures. Sometimes diversity of implementation of the
control system is also used in an attempt to avoid common-mode failures (and to
improve veracity rather than availability). However, a lack of clarity often exists on
how these techniques are used, particularly when hardware design techniques (used
to mitigate against random physical failures) are applied to software design. A
system view of hardware and software together is required, because both suffer
from errors of implementation, but only hardware suffers from random failures.
Safety Approach in Industrial Systems and Machinery 47
However, this may also affect software, for example, by radiation corrupting a
value stored in a memory chip.
The Importance of Human Factors
Unfortunately, aspects of the human factor are less than adequately addressed in
many systems. The classic example is the Three Mile Island nuclear plant accident
in Pennsylvania (USA) in 1979, where over 50 sirens were simultaneously sound-
ing in the control room—making it impossible for the staff to understand the
significance of each siren or to concentrate on what to do next to mitigate the harm.
Three Mile Island is also a good example of added complexity inducing failure.
The incident was triggered by a sensor, which was added to an existing safety
sensor to check it, that is, with an intention to improve safety. The check sensor
incorrectly indicated a fault in the main sensor, resulting in “preventative and
corrective actions” by the control system and the control staff, which resulted in a
cascade of errors—all predicated on the initial false indication. See the excellent
book by John Gall (Systematics).
The Safety Lifecycle and Trends
Modern plants are now designed with safety in mind, rather than as an afterthought.
The safety case for any new plant covers the operational process safety, the safety
credentials of each piece of equipment and their interoperation as a whole control
system. All phases of the plant lifecycle are covered including specification, design,
construction, proving, operation, shutdown and decommissioning. It is conven-
tional in safety critical plants to physically record a wide variety of significant
operational data on a continuous basis—the “wall of chart recorders” being a
familiar sight in production plants (e.g., chemical, oil, nuclear). Of course, these
chart recorders are now being superseded by the equivalent of aviation’s black box
recorder, which also has the advantage that it can be remote from the plant being
monitored.
Approach to Safety in Small Industrial Systems
In small industrial systems, improvement has been driven by stringent workplace

regulation and also the threat of litigation. All machinery that could cause injury to
its operator, or to people working adjacently, must be designed to be safe. The
normal reaction of such systems is to bring the machine to a safe state and/or
disallow access to the operator in a particular area. The concept of “safety inter-
locks” is similar to that used in the rail sector, where all relevant preconditions need
to be in an appropriate state before a potentially unsafe action is allowed to occur.
Most small systems (e.g., a lathe) do not keep through-life records of safety
incidents or operational data. However, it is quite common now for larger automa-
tion systems to retain this data, which is then analysed to support “preventative
maintenance” and recalibration at some convenient time.
The Trend to Design Standardisation
Over the past decade there has been a strong movement to standardise control
systems. This has been spearheaded by the CiA (CAN in Automation), an organi-
sation that promotes the CAN (controller area network) bus, which is now in
widespread use in automobiles, trucks, trains and GA aircraft as it offers an
effective method of collecting and distributing data over a robust and determinis-
tically timed serial bus, a low-cost system originally specified by Bosch Gmbh.
The CAN scheme has been adopted by the main US control system suppliers,
such as Honeywell, using proprietary names. The original CAN communications
protocol has now been joined by two additional abstractions:
The first is CAN Open which provides a standard model for interfacing devices
within a system, making system configuration much easier and enabling a mass
‘plug and play’ market in CAN-compatible devices such as switches, lamps, level
sensors, shaft encoders, stepper motors, etc.
The second is a CAN safety protocol for data transmission of safety critical data.
It is embedded in a chip, and based on the concepts of functional safety, it is
certified by TÜV SÜD for SIL level 3 safety applications. With his radical inno-
vation, for the first time safety support had been prepackaged into a standard
integrated circuit. The users of the chip just need to add in an algorithm that
customises the component for the specific safety requirements regarding the device
and its context of use. It is interesting to note that the Bosch and CiA collect
royalties on the CAN bus and safety chip by means of a royalty built into the cost of
the IC components required to build CAN-based systems.
A variety of other connectivity standards are in use including Profibus. There is a
renewed interest in a variant of Ethernet which provides a systemwide traffic
management scheme to achieve determinism of message delivery timing (i.e.,
timed Ethernet).
Although industrial systems have tended to lag behind rail, space and aviation
systems in terms of safety, there is now a strong motivation to design safe systems.
This continues to be driven in the USA and Europe by regulations and the threat of
litigation, and a systematic standards framework is in place to support it, based on
ISO 61508 (ISO 61508, ISO 26262).
It should be noted that most of the standard data bus schemes and protocols
currently in use have no security protection. In the new age of the Internet of
Things, this is a major concern.
Safety Approach in the Automotive Industry 49
Safety Approach in the Automotive Industry
The automotive domain has many similarities to GA—the vehicle is relatively

small, carries only a few passengers (or just the driver), and often the driver is the
owner. There is great flexibility for the use of the vehicle and the variety of
destinations and routes that can be used, but far more than in commercial aviation
or railways.
Current On-Board Safety Systems
The automotive community has invested heavily in on-board safety systems, driven
by an active customer base (spearheaded by Ralph Nader in the 1960s), the appetite
for litigation in the USA (and now Europe) and the demands of government
regulators. On-board safety improvements have taken many forms including
those described in the following sections.
Physical Safety Systems
Physical safety systems are concerned with the physical safety of the driver,
passenger(s) and other road users, for example, via passive systems such as seat
belts, crumple zones, roll cages and laminated glass, or active systems such as
airbags. Such systems seek to mitigate harm during or after a crash rather than
preventing the crash in the first place. More recently, systems have been introduced
that continuously monitor the state of wear/expected operational lifecycle of the
safety-related components and subsystems within vehicles. These systems provide
advice to the driver on the roadworthiness of the vehicle, but the driver is still
responsible for the safety of the vehicle he or she is driving.
Route Safety Systems
Route safety systems are concerned with ensuring that the route being taken is safe,
that is, within the vehicle’s and driver’s capabilities and free from risk of collision.
These systems are in their infancy in the automotive domain, currently taking the
form of navigation aids and marketing aids. This is partly due to the complexity of
the task given the existing road infrastructure and immature technology
(low-resolution positional tracking, lack of coverage in tunnels, etc.). Presently,
navigation systems are advisory to the driver rather than contributing to the actual
control of the vehicle. Some systems have recently been introduced, external to
vehicles, to dynamically control the flow of traffic, for example, adaptive speed
restrictions on motorways. These systems are also preventative in nature.
Driving Safety Systems
Driving safety systems are concerned with improving the safety of the vehicle
behaviour. This involves compensating for or enhancing the driver’s control of the
vehicle, for example, via traction optimisation, anti-skid compensation, anti-lock
braking and speed governing. Some systems provide advice for the driver, while
others actually control aspects of the vehicle directly, intervening in the way it is
actually driven with the objective of improving on the driving capabilities of the
driver.
Driver Safety Assurance
Driver safety is concerned with assurance that the driver can be identified, has the
capabilities to drive the particular vehicle, and is currently able to drive the vehicle,
that is, the driver’s performance is not impaired by illness or intoxication. This may
also have a security dimension, for example, with a bullion truck that may only be
driven by specific drivers.
Currently there is no automotive equivalent of aviation’s autopilot or the rail-
way’s “driverless train,” as such systems (e.g., from Uber and Google) are still at
the research stage. Some initial schemes are in place such as cruise control (possibly
adaptive to local road conditions), safe braking distance control and cooperation
schemes such as convoy management for creating “trains” of vehicles. Trials were
held in Europe in 2016 to evaluate the practicality of “vehicle trains” and “self-
driving” cars. Of course, these vehicles are not really “self-driving”; responsibility
for driving has been taken over by a network of computers, programmed by pro-
grammers, some in the local environment and some by third-party providers. It is
not yet clear how responsibility for incidents with self-driving cars, possibly
causing injury or death, will be apportioned between the vehicle owners, vehicle
manufacturers, guidance providers and navigation and safety system providers.
Safety Improvement
Safety in the automotive domain is improved mainly by regulation, litigation and

competition. Regulation, as in the railway, space and aviation domains, has tended
to be motivated by events. Really serious accidents have caused a tightening of
regulations in an effort to prevent a recurrence of similar accidents, or at least to
mitigate the harm caused. Major accidents are analysed, the causes and hazards are
identified, and reports are produced that offer recommendations for safety improve-
ments to processes, systems and equipment. There have been some recent notorious
examples where commercial gain has taken precedence over the safety of products
and their users, for example, exploding petrol tanks, and lethal tires for 4 4
vehicles.
In some cases, new systems aimed at improving safety have actually led to
increased harm, even fatalities. A recent example was an engine management
system that, in attempting to protect the engine from over-revving, prevented a
driver from completing a takeover manoeuver, thus killing the driver. So it always
needs to be borne in mind that safety must be considered pervasively, being the sum
of effects of each system and all their inter-reactions.
A feature of the automotive market is that safety has been a major factor in
building brands, good examples being Volvo and Audi. So far this kind of compet-
itive advantage has been evident in the areas of physical safety and driving safety.
So far, driver automation has been hampered by current technology and perhaps the
drivers’ own perceived need to remain “in control.” Future systems may offer
improved safety with features such as lane management and control of speed
relative to the local environment and weather. Eventually full automation can be
envisaged, the passengers simply specifying the destination and perhaps some
interesting way-points to determine a desirable route. Of course, this could offer
enormous safety benefits, eliminating collisions and the driver’s mistakes, fatigue,
illness and possible abuse of alcohol or other drugs. However, when accidents
happen, as they surely will, then who will be responsible and therefore be held
accountable? Will it ever even be possible to apportion blame?
Operational Safety Cycle
Operational checks for on-board safety are already widely used in the automotive
domain. The typical life-cycle involves:
Maintenance
Here a wide variety of vehicle parameters is available that provide a basis for
diagnosing faults, assessing wear on parts and how the vehicle has been used.
Typically, the on-board computer records the absolute data, for example, brake pad
wear, and summaries of operational data, for example, cumulative distance trav-
elled and engine speed profile. This can be downloaded into a diagnostic computer
and then analysed to provide guidance for the servicing and repair of the vehicle.
The maintenance system may also upload parameters to the on-board system in
order, for example, to improve its driving characteristics or enhance overall safety.
This approach can and has been taken to extremes. In Formula 1 racing, telem-
etry is used to continuously monitor the performance of the vehicle and driver and
then to optimise the vehicle systems on-line and interactively and advise the driver.
The emphasis here is, of course, on performance rather than safety. For most
automotive vehicles, however, there is only one mandatory vehicle maintenance
per year to ensure that the vehicle is safe to drive.
Checks at Start-Up of Vehicle
Many safety-related checks are made during the start-up of the vehicle, for exam-
ple, tire pressures, doors closed, oil pressure, coolant level, etc. In specialised
applications where security is involved there may be additional automatic checks
on the driver and passengers such as identity biometrics (e.g., iris scan, fingerprints,
voiceprints), weight, alcohol in breath, licence validity and passwords.
The objective here is to ensure that the vehicle is safe to drive and that the driver
is entitled and fit to drive it. There is no formal safety check of the vehicle during
the start-up phase, at least not for car drivers. However, commercial and security
vehicles do have safety checklists that must be successfully completed before the
vehicle can be used.
Checks During Operational Use
Many checks recur during operation with feedback provided to the driver, normally
as warnings or advice. Examples of on-going checks are oil pressure, water
temperature, fuel level, fuel efficiency, impact detection (to deploy airbags),
over-rev detection, etc. Insurance and litigation concerns initially ensured that the
driver was in sole control of the vehicle. However, many ancillary systems, such as
anti-skid compensation and anti-lock braking, are now well-proven enough that
they are trusted to take some control from the driver. To put it another way, they
enhance the driver’s apparent performance and safety by compensating for his or
her driving capabilities. Indeed, insurance premiums are now lowered in some
cases to take account of the safety performance of specific models of vehicles.
Checks at the End of Operational Use
At the end of use the data acquired during the journey is accumulated and stored. If
a journey ends exceptionally, for example, because of an impact, then safety
systems such as airbags, fuel cut-off, door unlocking and electrical system isolation
are activated. Additional detailed data related to the event may also be retained,
rather than being accumulated in the normal way. During operation, tachometers
and other instruments are used to record how long and in what way the vehicle has
been driven. This information can be inspected to ensure compliance with the law
governing the use of different classes of vehicles.
In summary, on-board safety systems are well developed in the automotive
domain and continue to develop at a rapid pace to meet the demands of customers
and the regulators. On-board safety systems are seen as important and valuable
benefits: by manufacturers, to protect themselves from litigation while making their
products more marketable, and by customers to protect themselves and other road
users from harm and to avoid litigation or legal sanctions. The issue of assigning
liability for operational incidents and failures is an open topic, and will doubtless be
gradually formed by legislation and case law.
Future Safety Systems in the Automotive Industry
The European Automobile Manufacturers Association has defined three objectives

for the new “active’” safety systems in the automotive industry:
• Reduce pedestrian fatalities
• Reduce pedestrian injuries
• Reduce societal costs
The twofold plan to achieve this is by:
• Avoiding collisions
• Reducing collision severity
The proposed solutions for the achievement of the above are summarised in the
following concepts:
• Anticipate and steer
• Anticipate and brake
• Anticipate and warn
A number of technologies have been proposed for the improvement of safety
associated with road transport. Depending on the nature of the proposed technolo-
gies and the characteristics associated with them, these can be categorised into the
following three fields (according to the direction in which they provide enhance-
ments in):
• Better visibility—Current systems: high-intensity discharge lamps, daytime
running lights, UV lighting. Future systems: night vision systems (infrared),
smart headlamps for steering and spotlighting, vision enhancement and analysis
systems
• Better steering—Current systems: tire optimisation, ABS, enhanced stability and
traction control, variable power assist, body control (active ride levelling and
anti-roll). Future systems: smart steering, steer by wire, collision avoidance
• Better brakes—Current systems: ABS, ABS and electronic brake force distribu-
tion, brake by wire, emergency brake assist. Future systems: automatic precrash
brake intervention, collision avoidance, adaptive cruise control stop-and-go
Further, there are concepts proposed by some automobile manufacturers that are
of particular interest with respect to their applicability in the aviation domain, for
example, the system proposed by Volvo for controlling unintended lane departure of
the vehicle or the system under research by Ford and Autoliv which is to “combine
vision and radar sensor technology to create a new type of auto safety system that
will detect approaching hazards, measure their rate of motion, determine if and
where a collision will occur, and trigger mitigating actions, such as applying brakes,
pre-tensioning seat belts, and firing side airbags, with a near-zero false alarm rate.”
Other such concepts, (for which applicability to the aviation domain should be
investigated) include “Anticipate and Warn” and “Collision Avoidance.”
Safety Approach in the Rail Industry
Most of the safety concepts in use today have been developed gradually in the rail
domain. Dating back to the 1850s, rail accidents and incidents have been investi-
gated, the causes and hazards have been determined, and then systems have been
improved to eliminate or mitigate them. Rail transport introduced a number of
innovations—mass transport for the public, heavy vehicles with relatively poor
braking performance travelling at high speed and the potential for major
“man made” disasters (e.g., collapsing bridges) and collisions. Where rail routes
intersect or end, there is the potential for collision, and from the earliest times safety
systems have been employed (the first being a man on foot preceding the train and
carrying a large red flag).
In the nineteenth century, semaphores were developed in the form of physical
tokens carried on-board the train, to ensure mutually exclusive occupancy of track
sections shared between multiple routes. More recently, in the twentieth century,
dynamic routing and interlocking were developed, which guaranteed transient
exclusivity of a route through the rail network in order to allow safe operation
with more overall traffic. Safety standardisation for operations and equipment have
also been pioneered in the rail domain, and this is reviewed more specifically in a
later section. There is a distinct separation between on-board safety monitoring and
operational control of trains.
Current On-Board Safety Systems
Rail safety systems cover a similar scope to aviation, including:

1. Control centres concerned with route management
Safety Approach in the Rail Industry 55
2. Interlockings concerned with collision avoidance

3. Juridical recorders concerned with providing an independent trace of historical
activity before an incident/accident, and covering signalling both on the track-
side and on the train
4. Train protection systems, which either prevent unsafe train operation or safely
curtail it
5. Automatic train operation, replacing functions of the human driver
6. “Info-tainment” systems for communication with vehicle users
7. Safety-driven maintenance systems for both trains and infrastructure (e.g., track,
signals, etc.)
These are summarised in the following four subsections.
Physical Safety Systems
Physical safety systems are concerned primarily with the safety of the passengers
and include physical containment (carriage design) but not yet seat belts. Rail travel
is considered to be the safest mode of mass transport in terms of deaths per
passenger per mile/kilometre and in the past, speeds have been moderate
(<150 km/h); however, with the advent of modern trains running at speeds of
300 km/h or more, the physical safety of passengers is being reconsidered. Conse-
quently, train and track infrastructure maintenance has come to be considered a
safety-critical aspect and formal management and recording systems have become
mandatory. In subway rail systems underground, additional safety systems are
required both on- and off-board due to the increased risk of harm from fires and
collisions in tunnels and enclosed stations.
Route Safety Systems
Railways have the disadvantage that their route topology is fixed and is
2-dimensional. The cost of changes to track and infrastructure such as stations is
huge and often socially contentious. As pressure mounts for more traffic to run on
existing infrastructure, there has been a movement from static allocation of routes
(protected by static interlocking logic) to dynamic allocation of route fragments
based on current (and managed) availability.
The challenge has been to guarantee safety from collisions across the network
while moving more trains at higher speeds through a fixed topology track network.
Similar pressure is being experienced in the aviation domain, but without such
severe constraints on route topology (3D rather than 2D).
The new dynamic train route management system being deployed throughout
Europe (ERTMS) is based on the concept of providing a series of “movement
authorities” (MAs) to individual vehicles as they proceed on their journeys. Each
MA defines a safe forward speed profile for the train that either the driver or an
automatic train operator (ATO) must conform with when driving.
This is similar to air traffic control in aviation, the grain of movement along each
controlled route being much smaller for trains than aircraft.
Using MAs has the additional advantage that account can be taken of local
environmental factors such as speed and noise restrictions, as well as providing the
mechanism for guaranteeing exclusive occupancy of the track for the duration and
location of the MA. Each operational train receives a stream of MAs from the
control centre via an interlocking. This guarantees collision avoidance apart from
unanticipated collisions with obstructions on the rail track, such as other vehicles
(e.g., cars, trucks), animals or people (e.g., workmen, suicides). There are similar
hazards in aviation such as parachutists, hang-gliders, chairlift cables, flocks of
geese and drones.
Driving Safety Systems
Driving safety systems are well established in the rail domain; an early example is
the “dead man’s handle” used to (hopefully) ensure that the driver is alive and
conscious. Lately, particularly in subways, there has been a move toward driverless
trains using so-called automatic train operator (ATO). Accidents in subways can
cause extensive harm, for example, a fire can cause smoke that suffocates passen-
gers and the public waiting at adjacent stations. The risk of a driver becoming ill,
using drugs or even committing suicide can now be reduced using an ATO, so it is
now perceived as safety-critical. ATO is widely used in the Far East, but its use in
Europe has been tempered by social issues (e.g., trade unions). However, most new
and refurbished rail schemes use ATO or have changed over to full automation with
driverless trains. Note that such systems are much easier to control safely as the
topology of the track limits the possibilities of movement. This is not the case with
road vehicles where there are many more degrees of freedom, including a mix of
driverless and human-driver-controlled vehicles.
Driver Safety Assurance
This is a rapidly changing area. Many current driver interfaces tend to rely on
forcing the driver to acknowledge continuous stimuli from the driving console to
confirm that the driver is aware of the current context and is active and alert. This
scheme is not always desirable from a human factors viewpoint as drivers tend to
start unconsciously and automatically responding to the stimuli rather than the real
and current driving situation.
This is believed to be a major contributing factor to the cause of the notorious
high-speed train crash at Paddington, London, in 2003. This brought attention to the
need to carefully consider human factors as a safety issue in the design of driver
interfaces. Driver identification and confirmation of capabilities (e.g., knowledge,
skills and relevant experience) has now become an important safety and security
issue. After problems with alcohol and drug abuse with drivers and other rail staff,
random testing of operational train staff has been introduced in Europe. The trend is
towards mandatory checks before each workshift and also toward the use of an
ATO to reduce dependency on the driver, based on the well-established use of
autopilots in aviation.
Safety Improvement
Safety improvement in the rail domain is driven by regulation, approvals and

inspection. At the infrastructure level, the equipment and operational standards
are being harmonised across Europe, having previously been highly country-
specific. At the same time, the signalling systems are being upgraded to ERTMS
(European Rail Transport Management System). At the equipment level, there is a
well-established and well-regulated framework (ref: EN ISO 50128) for defining,
designing, verifying, validating and auditing the function and functional safety of
individual products. The production and independent safety audit of safety cases is
mandatory for all products and schemes, that is, the use of products together in
operational systems.
The rail domain is very traditional and conservative in its approach to safety, for
example, in the nineteenth century the route safety interlocking was originally a
mechanical interlocking between the levers used to physically pull the signal arms
via cables, and many are still in use today. In the early twentieth century, relay logic
was introduced to emulate the mechanical interlockings, then subsequently pro-
grammable logic controllers (PLCs), which in turn emulated the relay logic. Only in
the last decade or so has there been a movement toward using application-specific
computer languages to define the signalling rules of the rail network and then
interpret them in real time using journey scripts.
Operational Safety Cycle
Operational checks for on-board train safety are already widely used in the rail
domain. The typical life-cycle involves the following.
Maintenance
For the most part, rolling stock (i.e., trains, wagons, carriages, etc.) are owned by
investments companies and leased by train operating companies (TOCs) to serve
specific routes. The owners are responsible for the safety and maintenance of the
rolling stock, while the TOCs and infrastructure providers (i.e., track, signals, and
stations) are responsible for operational safety on-board the train and within the rail
network. Each train is considered to be a set of wearable parts and they are subject
to a series of regular inspections and/or replacement according to a safety mainte-
nance plan. The service intervals for each train are determined by elapsed time and
also journeys made (i.e., distance travelled, speed profiles, route quality, etc.).
On-board monitoring for most trains is limited to the mandatory automatic train
protection (ATP) system. However, the need to drive down maintenance costs and
increase operational availability (which is crucial to the leasing companies) is
fuelling interest in on-board monitoring and diagnostic systems.
Checks at Start-Up of Vehicle
The four main safety checks here are typically:

1. An approved route and a movement authority to proceed have been provided
2. A qualified driver capable of driving the train is available
3. A safety clearance from the on-board ATP system (driver and brakes approved,
carriages coupled, etc.) has been provided
4. A safety clearance from the ATO system (doors all closed, guard on-board, etc.)
has been provided
No rail personnel involved in any safety-related activity are allowed to consume
intoxicants or drugs; incidentally this extends to the designers and maintainers of all
the equipment, infrastructure and rolling stock. Mandatory random testing has been
introduced for drivers. In many cases the driver’s operational capability is still the
“weakest link” in the safety chain (German Wings 9525 Tragedy).
Checks During Operational Use
The ATP system independently and continuously checks the vital aspects of the
train during a journey, including braking, the physical integrity of the train, the
emergency stop cord and the integrity of the ATP itself. Any compromise of safety
automatically brings the train to a halt. With ERTMS it becomes possible to also
ensure that the train remains within the speed/distance profile defined by the current
movement authority at all times, and this to some extent also mitigates loss of
control or erratic behaviour by the driver.
Currently, this is considered to be an ATO function but it could easily cross over
to being an ATP function. External systems can also affect safety, for example,
trackside transponders used to detect whether a rail signal has been “passed at
danger” that is, the driver has ignored or missed it. Presently, this is presented as a
driver warning, so as not to lower traffic throughput in the rail network; in the future
it may come within the scope of the ATP system.
Passenger information systems are now being more widely used to inform
passengers of safety features and so are becoming part of the on-board safety
system (following the long-established aviation practice). In the case of hazard
conditions or an impending accident, the passenger information system is used to
give advice designed to minimise impending harm, the other safety systems being
focused on accident prevention and mitigation.
Checks at the End of Operational Use
The journey data for each train is accumulated by the ATO (if fitted) and at least by
the train operator and leasor. It is highly likely that as further data is sensed and
recorded during journeys that diagnostic systems will be used to identify and
anticipate developing safety conditions and emerging hazards. This is particularly
relevant for high-speed trains where huge amounts of kinetic energy are involved
and safe braking distances are anything up to 5 km.
Future Safety Systems in the Rail Domain
It will take at least 10 years to fully introduce the new ERTMS system throughout
Europe, probably longer while Europe continues to expand. In the meantime it will
coexist, inter-operate with and gradually displace the existing melange of “traffic
light”–based signalling and safety systems.
The increased risk of harm due to high operational speeds, high mass trains and
increased passenger volumes (e.g., double-decker carriages) will increase the need
and market for on-board safety systems to monitor, predict and mitigate safety-
related conditions and avoid hazards. New systems to reduce the dependence on
human drivers are already being introduced. It is anticipated that systems for driver
identity and capability assurance will also be developed and deployed in the next
few years, particularly in the light of the spread of terrorism.
Safety Approach in the Space Domain
In the space domain, safety is the critical issue. At present, safety systems on-board
spacecraft are split into two main categories—the flight safety systems (FSS) and
the integrated vehicle health management (IVHM) systems:
• FSS are the systems, which are concerned with the protection of the public from
off-nominal launch vehicle flight, and nontraditional FSS will expand this
protection via new methods and to vehicles that re-enter as well as launch.
• IVHM systems form the basis for safe operation of launch and re-entry, espe-
cially with regard to vehicle maintenance and interaction with future
nontraditional FSS.
The kinetic energy of an out-of-control spacecraft and the hazard associated with
such a large volume of fuel as is normally carried may have catastrophic repercus-
sions for both the general public and the environment in the event of an accident.
This is the reason why FSS are very much mandatory for spacecraft.
Five distinct FSS methodologies can be identified:
1. Range containment: Flight trajectory is constrained to a chosen range, which is
perceived to contain in its entirety a vehicle or its debris in a case of possible
malfunction. If the vehicle is to stray out of this range, its destruction is
commanded. This may be done remotely or by on-board means, depending on
whether the vehicle is manned or not.
2. Vehicle destruct: Certain boundaries are set along a vehicle’s trajectory such that
the vehicle’s continued operation within those boundaries will not negatively
affect public safety. However, should the vehicle stray outside of those bound-
aries or become uncontrollable within those boundaries, the vehicle is destroyed
via an active command. The boundaries are defined such that the propagation of
debris to Earth’s surface will not bring harm to the public.
Such systems may be placed on an element of the spacecraft, depending on its
operational characteristics, (e.g., if the vehicle is of the reusable type, the system
may be placed on the rocket boosters so as to assure safe recovery of the main
body of the craft). For a reusable launch vehicle (RLV) carrying people
on-board, the use of the system would be a last resort, a highly undesirable
situation.
3. Flights safening: This is a flight safety methodology presently employed by
UAVs that is applicable for any non-crewed vehicle capable of sustained
powered flight in the atmosphere. Within the general methodology of flight-
safening are several modes, which are dependent upon the degree of autonomy
of the vehicle; all of these modes require a minimum autonomous flight capa-
bility. The first mode entails a cessation of the attempt to fly a course and the
commencement of flight around a fixed point. The mode would be entered
automatically if the command-link is lost, and might be entered by command
if the pilot observes a control problem (however, the control problem could
easily hamper the ability to maintain flight).
Safety Approach in the Space Domain 61
For the very lowest level of autonomous capability, the mode would entail
circling of the vehicle’s present position. The next level of capability would be a
circling of the present position while gaining altitude in an attempt to reacquire a
lost command-link. The next level of capability beyond circling a “present”
location would be for the vehicle to fly to a preprogrammed waypoint. The
highest level of capability is one where it is possible for the craft to be equipped
with an auto-land system that would allow it to fly to a suitable landing area
designated by a waypoint and then land.
4. Thrust termination: This system consists of an on-board computer that deter-
mines, via inertial measurements, when the craft is straying from its course
sufficiently so as to place public safety in jeopardy. If public safety would be
placed in jeopardy by continuing operation of the craft, the on-board system
would terminate the vehicle’s thrust and the vehicle would continue on and
impact Earth along a planned ballistic trajectory. This system may often be
combined with some other FSS, so as to allow recovery of the vehicle.
5. Vehicle recovery system (VRS): A vehicle recovery system is defined as any
system which, either given a launch-abort or a re-entry anomaly, allows the
vehicle to come to a “soft” landing (i.e., a landing after which one can reason-
ably expect to recover the vehicle relatively intact such that it would need only
moderate repairs before being returned to flight status). In the case of NASA
UAVs, this is simply a parachute system. A VRS may be employed as a method
of allowing the vehicle to descend to a “soft” landing in the case that the vehicle
cannot land at an alternate or acceptable landing location. A “soft” landing in
this case will hopefully allow the vehicle to be recovered intact and protect the
occupants, if any. Moreover, it protects public safety by restricting the impact
velocity to a value much lower than the value would be if the vehicle were in
free-fall.
On the other hand, IVHM systems have two separate areas of emphasis. The first
area is the use of IVHM to support vehicle maintenance. In this role, IVHM is used
to record data in-flight; that data is not accessed until post-flight, at which time it is
used to help determine when vehicle systems are in need of repair or replacement.
These systems are normally referred to as “post-flight IVHM.”
The second area of emphasis is the use of IVHM to support vehicle flight
operations. In this role, IVHM actively manages (and therefore is also monitoring)
the vehicle during flight, and is intended to take action in the case of component or
system degradation, imminent failure, or failure. Ideally these IVHM systems
would act so as to prevent component or system failure that in any way would
affect the safety of a mission. These systems are referred to as “in-flight IVHM” and
resemble the active safety concepts explained in this book.
Once again, out of all the systems described in this section, there are some of
particular interest with respect to the active safety and the applicability of the
associated concepts in the field of aviation. Depending on the associated conditions,
the “range containment,” “vehicle destruct,” “flight safing,” “thrust termination”
and “vehicle recovery system” concepts, or a combination of those, may be of
interest with respect to their application in aviation. In light of the events of 9/11
and some previous crashes of civil aircraft in residential areas (e.g., a cargo
747 EL-AL crash in Amsterdam in 1992), future implementation of such systems
in aviation may be worthy of investigation at least at the conceptual level.
Existing Standardisation
In the domains examined above, there are a number of standards that specify the
requirements associated with the safety systems installed on-board the vehicle in
question.
Of these standards, those that bear some relevance with respect to active safety
are discussed in the following sections.
Standards in the Industrial Domain
The range of applications of industrial systems is very diverse. Consequently, there

has been a two-level approach to standardisation. Firstly within a sector (e.g.,
chemical) there are regulations regarding the safe operation and use of specific
products and systems. These tend to be drafted by either manufacturing associations
or the manufacturers themselves. Secondly across all sectors there is a single
standard (IEC 61508), which covers the specification, design and implementation
of safety-related products and systems themselves.
The 61058 standard is concerned with “Functional Safety of Safety-Related
Systems”. It is also the basis for safety standards in a wide variety of other sectors
(e.g., chemical, nuclear, rail).
Safety Definitions of IEC 61508
A full set of definitions and abbreviations can be found in Part 4 of the standard. The
main concepts are outlined below to explain what functional safety is and how it
can be achieved:
• Safety: freedom from unacceptable risk of physical injury or of damage to the
health of people, either directly or indirectly as a result of damage to property or
to the environment
• Functional safety: the part of overall safety that depends on a system or
equipment operating correctly in response to its inputs
• Safety-related system: systems that are required to perform a specific safety
function, or functions that ensure that risks are kept at an acceptable level
Existing Standardisation 63
• Safety function: an individual function of a safety-related system

• Safety function requirements: what the function does
• Safety integrity requirements: the likelihood of a safety function being
performed satisfactorily in terms of the probability of failure of the function:
– Per year of continuous operation
– Its required function on demand
Functional Safety Analysis
To assess safety and clarify requirements, the following techniques are used:
• Hazard analysis: identifies potential hazards and the conditions that led to them
• Risk assessment: determines the nature and performance requirements for the
safety function needed to prevent conditions leading to a hazard; the aim is to
ensure that safety integrity of the safety function is sufficient to ensure that
neither people nor the environment exposed to unacceptable risk associated with
a hazardous event
The purpose of functional safety analysis is to prevent dangerous failures or to
control them when they arise; examples of such failures are:
1. Incorrect specifications of the system, hardware and/or software
2. Omissions in safety requirements (failure to develop all relevant safety functions
for all modes of operation)
3. Random hardware failure mechanisms
4. Systematic hardware failure mechanisms
5. Software implementation errors (logic, sequence, temporal)
6. Common cause (mode) failures of sensing, computation and actualisation
7. Human error
8. Environmental (e.g. electromagnetic, nuclear radiation, temperature,
mechanical)
9. Power supply disturbances (blackout, brownout, reduced voltage, reconnection,
etc.)
The system life-cycle is laid out in a similar way to the safety life-cycle;
however, they cover separate aspects and concerns of the same entity.
Because the 61508 standard is large and comprehensive, it is split into seven
parts, each related to an area of concern:
1. General requirements for any system
2. Requirements for electrical/electronic/programmable electronic safety-related
systems
3. Software requirements (to develop software that is safe in operation, auditable in
design and implementation and maintainable in the long term)
4. Definitions and abbreviations
5. Examples of safety integrity level determinations (SIL1 to SIL4)

6. Guidelines on appropriate techniques and measures used to achieve different
SIL levels
7. Overview of measures and techniques
Further details can be found on the IEC website in the functional safety zone
section at: http://www.iec.ch/functionalsafety.
The 61508 standard has now been used as the basis for many other industry/
sector-specific standards, for example, the well-established ISO EN 5012 family
of specifications in the rail sector already referenced.
Standards in the Rail Domain
Safety techniques are well established in the rail sector as this was the first sector to
introduce mass travel with the attendant potential for disaster. A series of standards
has been defined to provide detailed guidance on how railway systems can be
specified, designed and implemented to be safe to some defined level of integrity.
The basic philosophy behind this group of standards is concisely reviewed and the
standards are based on the concepts defined in the functional safety standard EN
61508 previously mentioned. These standards together cover all aspects of railway
safety from wide-area signalling systems at a high level, down to component-level
design and reliability at the equipment level.
The Safety Case
Railway systems are gradually enhanced and changed over many decades, often
with new subsystems having to interwork with existing systems as well as replacing
their functions as technology has changed. In order to ensure that the overall
subsystem will remain safe when a new system is deployed, a documented safety
case needs to be produced. Typically, this is comprised of the following:
1. The definition of the new subsystem in the context of the existing system
2. A quality management report on the implementation, verification and validation
of the new subsystem
3. A safety management report detailing evidence of the safety management of the
project and product (e.g., safety plan, results of audits such as “vertical slice”
audits of documentation and V&V evidence of requirements, design, implemen-
tation and testing)
4. A technical safety report detailing evidence of functional and technical safety
5. Related safety cases, such as for the bounding system(s) or any pre-existing or
commercial off-the-shelf (COTS) sub-subsystems embedded in the subsystem
being considered
Development Life-Cycle for Safety-Related Systems 65
6. A conclusion that summarises the evidence provided and makes the argument
that the system/subsystem/equipment is adequately safe subject to compliance
with the specified conditions of use
These points are all described in detail in Section 10 of EN ISO 50129.
Development Life-Cycle for Safety-Related Systems
The life-cycle activities for overall development of safety-related systems can be

represented conveniently in a V shape. The top of the V has higher levels of design
abstraction (e.g., system requirements specification), whereas the bottom of the V is
the hardware design itself, with its corresponding software runtime support. The
left-hand side deals with the specification and the right-hand side deals with the
implementation of the verified and validated system.
Clearly the key document is the system requirements specification because this
addresses the scope of the subsystem, its interfaces to its bounding system and
environment, what it does (i.e., functional and nonfunctional requirements) and its
functional safety requirements. As explained in the section on industrial safety
above, the product development life-cycle closely corresponds to the safety life-
cycle with a change of emphasis on product functionality rather than functional
safety; both are essential and intertwined.
The standards also outline the approaches required for hazard analysis, risk
assessment, safety integrity level assessment and failure mode analysis (typically,
failure mode effects and criticality analysis, FMECA, and fault tree analysis, FTA).
Note that active safety may require these or similar techniques, but the principle of
active system safety (PASS) concept dynamically extends the scope of safety
analysis beyond these techniques using analysis of real-time operational data, not
just static “design time” FMECA and FTA data and assessments.
Safety Integrity Levels (SILs)
At some point, the question has to be asked, “How safe is safe?” That is, how can
safety be made measurable objectively? The safety integrity level, or SIL, defines
the level of safety. Depending on the SIL level required for the subsystem, in the
context of its system(s), the EN 61508 standard and the rail standards set out various
minimum technical methods for system, hardware and software design and imple-
mentation recommended for use to achieve each SIL level (1–4). The SILs for
railway applications are defined as follows (Table 2.1).
Non–life threatening systems are usually implemented to SIL 2, (e.g., a data
preparation system for track layout information). Potentially life-threatening
systems and ultra-high-availability systems are normally implemented to
Table 2.1 Typical safety integrity level characterisation for railway applications
SIL level 1 2 3 4
Probability of failure to 10 5
to 10 4
10 6
to 10 5
10 7
to <10 7
perform its design function <10 6
on demand
Dangerous failure rate Function on 0.3 10 8
10 10 to <10 10
per hour per system element demand 10 7 to 10 7 0.3 10 8

to 0.3 10 5
SIL 4 (e.g., the automatic train protection system and parts of the automatic train
operation system). In the active safety context, the passive device used to monitor
active safety would most probably be implemented to SIL 2 as a product (not for the
prototype). If this device were extended in scope to include control of some aspects
of an aircraft, then it would definitely be classified as SIL 4. New systems for
controlling railways are being introduced (ERTMS); however, the basis for sys-
tematic safety assessment, design and assurance remain the same, based on the
existing standards.
Standards in the Space Domain
One of the standards that govern the specification of flight safety systems for space
vehicles is ISO/WD 14620-3. This international standard sets out the requirements
for space-borne operations with respect to the safety of the exposed people,
property and environment for those countries and/or organisations conducting
scientific commercial or civil launch activities. In addition to standard requirements
regarding the availability of the flight safety systems in question, under the worst
predicted environment, the adherence to component storage and operational life-
cycle requirements, the prevention of system unavailability attributable to electro-
magnetic interference, the following requirements have been highlighted so as to
provide an overview of the requirements associated with space-born Flight Termi-
nation System FTS, Range Tracking System RTS and Telemetry Data Transmitting
System TDTS.
Under the section “General Requirements” of the standard:
1. Clause 5.2 requires that: “All guided launch vehicles shall incorporate a means
of tracking that enables real-time monitoring of vehicle position and prediction
of instantaneous impact points from launch through orbital insertion or mission
completion.”
2. Clause 5.3 requires that: “All launch vehicles shall incorporate telemetry data
transmitting systems for monitoring critical vehicle performance data, flight
termination system and tracking system status that are capable of functioning
throughout the launch phase until the end of range safety responsibility.”
Standards in the Space Domain 67
3. Clause 5.4 requires that: “Any launch vehicle having a stage, motor or compo-
nent capable of violating the defined safety envelope shall be equipped with a
flight termination system (FTS) that shall be capable of interrupting the flight of
the vehicle if it diverts from its predicted flight trajectory and has sufficient
energy to become a threat to public safety.”
Under the section “Flight Termination System Requirements” of the standard:
4. Clause 6.1.1 requires that: “Any launch vehicle where a malfunction of the
vehicle or any stage, motor, payload or component may generate an unaccept-
able hazard to public safety shall contain flight termination systems.”
5. Clause 6.1.2 requires that: “All launch vehicle stages capable of violating the
defined flight safety envelope shall contain flight termination systems.”
6. Clause 6.1.3 requires that: “FTS reliability shall be set at 0.999 at the 95%
confidence level, or shall be compliant with the quantitative flight safety objec-
tives if the later are more stringent. The reliability should be established by
analysis of all components and supporting test data.”
7. Clause 6.1.4 requires that: “The FTS shall be capable of rendering all powered
stages and any other propulsive system of the vehicle nonpropulsive.”
Under the section “Range Tracking System Requirements” of the standard:
1. Clause 7.2.1 requires that: “All expendable launch vehicles and suborbital
vehicles shall have an approved means of tracking the vehicle’s trajectory
throughout flight. The RTS may use various ground-based or vehicle-
incorporated tracking modes to provide accurate tracking information.”
2. Clause 7.2.2 requires that: “The RTS shall provide real-time data from which
position and velocity can be determined.”
3. Clause 7.2.5 requires that: “The RTS shall be capable of providing real-time
indications of malfunctions of any components compromising operation of the
system.”
4. Clause 7.2.8 requires that: “Transponder systems used on vehicles shall be
capable of operating within the parameters established for operation of the
tracking facilities.”
5. Clause 7.2.9 requires that: “Space-based translators or receivers, such as GPS,
shall be independent of any on-board guidance system.”
6. Clause 7.2.10 requires that: “Design RTS reliability shall be 0.995 at the 95%
confidence level for transponder systems and 0.999 at the 95% confidence level
for space-based systems such as GPS, or shall be compliant with the quantitative
flight safety objectives if the later are more stringent. The reliability should be
established by analysis of all components and supporting test data.”
Under the section “Telemetry Data Transmitting System Requirements” of the
standard:
Clause 8.2.1 requires that: “All launch vehicles shall have a TDTS to provide
vehicle performance data to flight safety operators.”
Clause 8.2.2 requires that: “The TDTS shall be capable of providing uninterrupted
data from lift-off through orbital insertion, mission completion or until range
responsibility for safety has been fulfilled and terminated.”
Clause 8.2.3 requires that: “The TDTS shall be capable of acquiring, storing,
processing and providing data in real-time.”
Clause 8.2.4 requires that: “Telemetry data shall include data relevant to position
and tracking, FTS status, RTS status, vehicle performance, engine and control
information.”
Clause 8.2.5 requires that: “The TDTS shall be capable of providing real-time
indications of malfunctions of any components compromising operation of the
system.”
Clause 8.2.6 requires that: “Sufficient TDTS data shall be obtained to determine the
adequacy of the flight safety system throughout flight and to support pre-flight
and post-flight analyses.”
Clause 8.2.7 requires that: “The airborne telemetry system shall be compatible with
the ground-based telemetry stations.”
Clause 8.2.12 requires that: “Design TDTS reliability shall be 0.995 at the 95%
confidence level, or shall be compliant with the quantitative flight safety objec-
tives if the later are more stringent. The reliability should be established by
analysis of all components and supporting test data.”
Note that the real-time data during flight is not stored on-board in a “black box”
recorder. Instead, it is transmitted from the vehicle and analysed independently of
the vehicle itself. The above requirements would be of interest with respect to
addressing the hazard associated with aircraft crashes (mostly into a populated
area), whether because of a terrorist act or because the pilot had been incapacitated,
or because of some system failure, etc. These requirements need to be considered as
guidance and the basis for the possibility for incorporation of such safety systems in
future aircraft whether in general, civil or military aviation.
Conclusions
In this chapter we have briefly covered problems of safety and existing solutions,
regulations and trends in:
– Space systems
– Railways
– On-ground transport
We have discovered:
– The role of functional safety analysis based on fault tree analysis
– Requirements for life-cycle for safety (based on the V-scheme)
We have described standards for safety in the space domain.
Functional Safety Standards Based Upon IEC 61508 69
This short overview has indicated that apart from initial steps of implementation
of an in-flight vehicle health monitoring system for aerospace, there is no evidence
so far that active system control and its application for active system safety. In spite
of the fact that fault tree analysis has been proven to be ineffective, static and
inapplicable for real-time safety, this analysis still predominates in safety system
designs.
Additionally, design and management of safety systems so far has been
approached using a V-diagram, while nonfunctional requirements such as active
safety or active system control should be maintained at each level of design with
minimisation of feedback between phases or levels of a project.
Thus, the activeness of system controls or system safety should be introduced at
first theoretically and then further implemented through existing systems, changing
the requirements for the system we design as needed.
Active system control and active system safety, therefore, should be illustrated
by the positive impact of our approach on the schemes, regulations and mainte-
nance. This advantage should be shown quantitatively and address gains in reli-
ability, performance, and energy efficiency with and without implementation of our
concept.
Functional Safety Standards Based Upon IEC 61508
Functional Safety
IEC 61508 Standard on functional safety, see https://en.wikipedia.org/wiki/IEC_61508
IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-
related system
Machinery
IEC 61511 Safety instrumented systems for the process industry sector (in USA: ANSI/
ISA S84)
IEC 62061 Safety of machinery
Railways
IEC 62278 / EN Railways—Specification and demonstration of reliability, availability,
50126 maintainability and safety (RAMS)
IEC/EN 50128 Software, railway control and protection
IEC/EN 50129 Railway signalling
Nuclear
IEC 61513 Nuclear power plant control systems
Avionics
RTCA DO-178C North American avionics software “Software considerations in airborne
systems and equipment certification”
RTCA DO-254 North American avionics hardware
EUROCAE European flight safety systems
ED-12B
(continued)
Automotive
ISO 26262 Automobile functional safety
ISO26262-1 Road vehicles—Functional safety—Part 1: Vocabulary
ISO26262-2 Road vehicles—Functional safety—Part 2: Management of functional
safety
ISO26262-3 Road vehicles—Functional safety—Part 3: Concept phase
ISO26262-4 Road vehicles—Functional safety—Part 4: Product development at the
system level
hardware level
software level
ISO26262-7 Road vehicles—Functional safety—Part 7: Production and operation
ISO26262-8 Road vehicles—Functional safety—Part 8: Supporting processes
ISO26262-9 Road vehicles—Functional safety—Part 9: Automotive safety integrity
level (ASI) oriented and safety-oriented analyses
Medical
IEC 62304 Medical device software
ISO14971 Medical devices—Application of risk management to medical devices
EC/EN 50402 Fixed gas detection systems
DEF STAN 00-56 Accident consequence (UK military)
References
Active Safety
1. AOPA United States GAO (General Accounting Office), GAO-01-916 (2001) General avia-
tion status of the industry, related infrastructure, and safety issues. U.S. General Accounting
Office, Washington, DC
2. ARINC_653. The avionics standard based on the concept of partitioning the processor time,
memory ranges and I/O access. http://en.wikipedia.org/wiki/ARINC_653, also: “ARINC
653 An Avionics Standard for Safe, Partitioned Systems,” www.computersociety.it/wp-con
tent/uploads/2008/08/ieee-cc-arinc653_final.pdf
3. German Wings 9525 Tragedy. Suicide by pilot. https://en.wikipedia.org/wiki/Germanwings_
Flight_9525
4. Bohpal. Gas leak tragedy in India. https://en.wikipedia.org/wiki/Bhopal_disaster
5. CAN Bus. Using software protocols to mask CAN BUS insecurities, B R Kirk, IEE colloquium
on the electromagnetic compatibility of software, Thursday, Savoy Place, London,
12 November 1998, IEE document reference 98/471, available from the IEE Library at
Savoy Place, libdesk@theiet.org, or archives@theiet.org
6. Castano V, Schagaev I (2015) Resilient computer system design. Springer International
Publishing. ISBN 978-3-319-15068-0
7. Chernobyl. Nuclear reactor explosion and meltdown. https://en.wikipedia.org/wiki/Cherno
byl_disaster
8. Concorde. Rupture of fuel tank from runway debris. https://en.wikipedia.org/wiki/Air_
France_Flight_4590
References 71
9. EMC Guide. Guide on EMC for functional safety, published by the IET in 2008, PDF
download. www.theiet.org/factfiles/emc/index.cfm, colour-printed book: www.emcacademy.
org/books.asp
10. EN ISO 50128. Software assurance standard for railway applications. https://de.wikipedia.org/
wiki/EN_50128
11. IEC 61508. Standard on functional safety. https://en.wikipedia.org/wiki/IEC_61508
12. Kaegi T, Schagaev I. System software support of hardware efficiency. eBook from: www.it-
acs.co.uk/book.html
13. Overtoon E, Miloslavin S, Schagaev I (1999) In: Proceedings of the international system safety
society ASGA: active safety for GA, ISSS99. Orlando, 16 August
14. Schagaev I (2001) CASSA: concept of active system safety for aviation. In: 15th IFAC
symposium on automatic control in aerospace, 2–7 September 2001. pp 303–309. ISBN 0-
08-043684
15. Schagaev I (1998) The concept of dynamic safety for aeroplanes, ISSC98. Seattle
16. Shuttle. Launch attempted with rocket fuel seals below specified temperature. https://en.
wikipedia.org/wiki/Space_Shuttle_Challenger_disaster
17. Susskraut. Safe program execution with diversified encoding. Martin Susskraut et al. Embed-
ded World 2015. www.embedded-world.eu
18. Systematics. A book and thesis by John Gall on why systems fail. https://en.wikipedia.org/
wiki/Systemantics
19. Three Mile Island. Nuclear plant accident. https://en.wikipedia.org/wiki/Three_Mile_Island_
accident
20. Timed Ethernet. http://www.ieee802.org/802_tutorials/2012-11/8021-tutorial-final-v4.pdf
21. Train. High-speed train derailed and crashed into a road bridge. https://en.wikipedia.org/wiki/
Eschede_derailment
Chapter 3
Aircraft Flight Reliability and the Safety
Landscape of Aircraft Use
Introduction
The logic of this chapter is simple. We start with a standard reliability analysis of
aircraft flights having two phases—on the ground and in the air. We further
introduce several flight modes (sometimes called phases) and create a reliability
model to analyse the transitions from one flight mode to another. The importance of
having such a model, even one this simple, became once again regretfully obvious
after the Tupolev Tu-154 tragedy in December 2016. See more:
https://www.flightglobal.com/news/articles/erratic-control-preceded-military-tu-154s-
fatal-des-437877/
Thus, speaking about reliability, we should introduce overall reliability and
momentary reliability (availability) that reflect both the long-term and current
status.
Further, we analyse how risk and reliability of aircraft flights are correlated,
because the technology available and the amount of data about aircraft conditions
seem to be growing, while the quality of maintenance and flight phases control,
efficiency and performance are not.
We also briefly analyse what kind of lesson the notorious Space Shuttle Chal-
lenger accident could teach us with regard to the design or redesign of existing
aircraft and systems to gain efficiency, reliability and performance, addressing
primarily the aspect of safety. As was illustrated at FlightGlobal’s Flight Safety
Symposium in 2016 [29], aviation is facing a paradox of logic. The growth of flight
information, tools and Information and Communications Technology ICT support
for maintenance and flight control have not significantly changed flight risk pro-
files: landing and taking off still predominate in aviation accidents. But this should
not be the case! The more we know, the safer we should be—“forewarned means
forearmed”, “knowledge is a power even by itself,” and so on. This does not,
however, seem to be true for aviation, and why this is so needs to be addressed.

74 3 Aircraft Flight Reliability and the Safety Landscape of Aircraft Use
If all improvements are left in the hands of the weakest link of the system—a human—
then to expect any boost in reliability, performance and efficiency seems naı̈ve.
An Operational Reliability Model for Aircraft
One of the objectives of the active safety approach is to improve the operational
safety of aircraft both during a flight and over its entire life-cycle of operation. We
consider safety as a measure of the continuous absence of harm. In terms of
reliability theory, it is a measure of the continuous delivery of correct service;
therefore, safety can also be viewed as intimately linked with reliability with
respect to harmful failure. For the long term the reliability of an aircraft is likely
to exhibit an operational failure rate over the life of the aircraft with the classic
“bathtub” shape illustrated in Fig. 3.1. This model has three main phases: (1) an
initially high failure rate, (2) a relatively steady constant failure rate λ during most
of the overall life-cycle, and (3) a rising failure rate when aircraft age approaches
the end of its operational life. Highly intensive preoperational testing of the aircraft
can mitigate the impact of the first phase. It is only used operationally after the early
failures have been “shaken out” to the steady failure rate λ, which is assumed to be
constant.
In practice, because of factors such as wear and ageing of parts, the actual failure
rate is often more like the upper “real” curve of Fig. 3.1, where the failure rate
gradually increases as parts wear out and fatigue mechanisms become significant.
The reciprocal of the diagram in terms of reliability is shown in Fig. 3.2.
The reliability of the aircraft has two components:
1. The “physical” reliability, due to faults developing in its elements (engines,
undercarriage, etc.); this depends to an extent on proper maintenance
2. The reliability of its operational use
The aircraft’s life-cycle is now modelled as a series of flights, each with many
small segments associated with a phase within the flight. This can be refined to
describe the dependency between flight phases as the accident (failure) rate varies
between flight phases, as is explained elsewhere in this book.
Fig. 3.1 Actual and Failure Rate λ over life cycle

assumed failure rate of
an aircraft λ
Failure rate
Actual failure rate
Assumed failure rate λ
Elapsed time t
Reliability Model of a Flight 75
Reliability Model of a Flight
Reliability models are usually developed based on a number of assumptions and

must take into account the resources available (and types of redundancy possible).
An individual flight can be described by a simplified Markov model of flight safety;
see Fig. 3.3.
For simple illustration purposes, three generalised flight phases are proposed:
take-off, in-flight (or cruise) and landing. Each phase has its own probability of
successful completion: Pto, Pif, Plnd, respectively.
The transitions between flight phases λto, λif, λlnd indicate a successful taking off,
flight and landing, whereas a failure of each phase is denoted by λtof, λiff, λlndf.
The failure state F here is the state that safety systems are designed to avoid, that
is, a catastrophic accident. In terms of this simplified model the role of a successful
active system safety implementation is to avoid the transitions (λtof, λiff, λlndf) that
would lead to an accident.
The thick black arrows in Fig. 3.3 represent a normal sequence of flight mode
changes. The broader arrows are sequences of flight mode changes caused by
emergencies and faults experienced by the aircraft and pilots; they represent the
probabilities of accidents.
Fig. 3.2 Actual and Reliability of aircraft over whole life cycle
assumed reliability of
aircraft
R Assumed reliability
Reliability
Maintenance
Actual reliability
Elapsed time t
lif
PCR
lto llnd
liff
PTO PLND
ltof llndf
Accident F
Fig. 3.3 Simplified reliability model of flight

Fig. 3.4 Flight mode sequences and interdependence
In terms of this model the successful completion of a flight assumes the normal
sequential change of flight phases:
Psuccess ¼ ΠðPto ; Pif ; Plnd Þ
Psuccess þ Paccident ¼ 1
Then the ideal flight safety system in reliability terms has to exclude the
probability of accident: so the goal is to achieve Paccident ! 0 or at least to attempt
to minimise it. In practice, the flight phases can be further refined as shown in
Fig. 3.4. This also shows some flight mode transitions that are not “normal,” for
example:
– An emergency procedure involving a change from take-off to landing
– An aborted landing followed by an emergency take-off
Operational Reliability Model: Equations
The reliability of a flight is the product of the reliability of each of its flight phases.
Assuming Markovian properties for flight phases (and their changes) the set of
equations below describe flight mode and transition probabilities using the
Operational Reliability Model: Equations 77
Kolmogorov forward differential Eq. (3.2] to characterise the transition rates

between states: Eqs. (3.1), (3.2), (3.3), (3.4), and (3.5):
dPtaxi-out ðtÞ
¼ Ptaxi-out ðtÞðλtaxi-out-taxi-in þ λtaxi-out-climb þ λtaxi-out-F Þ
dt
þ Ptaxi-out ðtÞðλtaxi-in-taxi-out Þ ð3:1Þ
dPclimb ðtÞ
¼ Pclimb ðtÞ λclimb-in-flight þ λdescent þ λclimb-F
dt
þ Ptaxi-out-climb λtaxi-out-climb þ Pdescent λdescent-climb
þ Ptaxi-in-climb λtaxi-in-climb ð3:2Þ
dPin-flight ðtÞ
¼ Pin-flight ðtÞ λin-flight-descent þ λin-flight-F
dt
þ Pclimb λclimb-in-flight ð3:3Þ
dPdescent ðtÞ
¼ Pdescent ðtÞðλdescent-taxi-in þ λdescent-climb þ λclimb-descent-F Þ
dt
þ Pin-flight-descent λin-flight-descent þ Pclimb λclimb-descent ð3:4Þ
dPtaxi-in ðtÞ
¼ Ptaxi-in ðtÞðλtaxi-out þ λtaxi-out-climb þ λtaxi-out-F Þ
dt
þ Pdescent λdescent-taxi-out þ Ptaxi-out λtaxi-out-taxi-in ð3:5Þ
and normalisation conditions:
X
5
Pi þ F ¼ 1
i¼1
where i is a probability index for the five states presented in Fig. 3.4.
This set of equations is based on the assumption that the transitions between
flight phases change instantly. Using expert data for determining transitional
probabilities and solving the system of Eqs. (3.1), (3.2), (3.3), (3.4), and (3.5) the
reliability of an aircraft during flight can be analysed in terms of the classic
reliability models from [1] by introducing point and mission reliability and the
notion of mean-time-to-failure for an aircraft during flight. By solving this system
of equations, it becomes possible to estimate the probabilities and thus the reliabil-
ity (availability) for each phase of flight and the flight as a whole.
Measures of System Reliability
The classic measure of mean time to failure (MTTF) and also the point and mission
availabilities can be derived from the equations above as well as from the classic
reliability theory of Birolini [1].
However, there is still the issue of the relationship between availability and
safety. Availability for an aircraft, which is not repairable in flight, is calculated as
the sum of probabilities for each sequential flight phase from the beginning (taxi-
out phase) to the end (taxi-in phase) of flight.
Availability and reliability here are calculated assuming their sequential
processing. There are two measures of availability that may be immediately useful
in this respect; they are point availability and interval availability.
Point Availability
The point availability PA0(t) is defined as the probability that an aircraft is failure-
free and remains in the main (normal) phases of flight from the beginning of the
flight up to the moment t of observation. Assuming that the aircraft is new (i.e., “as
good as new” at each renewal point, i.e., after maintenance), then the point
availability is:
PA0 ðtÞ ¼ Prfup at t jnew at t ¼ 0g ð3:6Þ
Now if the probability of no failure in the interval [0,t] is 1 F(t), the probability
that every renewal point lies in the interval [x, x þ dx] is hnf(x)dx and 1F(tx) is
the probability that no further failure occurs in the interval [x,t] is 1F(tx) then
the following holds at the end of the interval 0, t:
ðt
PA0 ðtÞ ¼ 1 FðtÞ þ nnf ðxÞð1 Fð1 xÞÞdx ð3:7Þ
0
Mission Availability
The mission availability MA0(T0, tflight) is defined as the probability that in the
mission of total operating time T0 each failure can be repaired within a time span
tflight. Hence, considering that the aircraft is “as good as new” at t ¼ 0,
Operational Reliability Model: Equations 79

MA0 T 0 ; tflight
¼ Prfeach individual failure during the mission of total operating time T 0 g
ð3:8Þ
can be repaired in time ≦ tflight I new at t ¼ 0}.

Mission availability is important for flight because interruptions of flight phase
≦ tflight might be necessary; for example, the landing phase of flight might be
interrupted and then take-off resumed. The only condition required to estimate
mission reliability is that at the end of the period T0, the total time of the flight, no
failures have occurred.
If G(tflight) is the probability that all flight phase reiterations (loops) will be
shorter than tflight, and the failure rate is assumed constant and equal to λ, the
mission availability is:
Toð1Gðtflight ÞÞ
MA0 T 0 ; tflight ¼ eλ ð3:9Þ
Joint Availability
Joint availability JA0(t, t þ θ) gives the probability of continued operation at the time
points (t, t þ θ). Assuming that the aircraft is “as good as new” at t ¼ 0 then it is:
JA0 ðt; t þ θÞ ¼ Prfup at t \ up at t þ θ I aircraft new at t ¼ 0g ð3:10Þ
Again, assuming a constant failure rate the two events “up at t ¼ 0” and “up at
t þ θ” are independent (assuming Markov properties) then:
JA0 ðt; t þ θÞ ¼ PA0 ðtÞPA0 ðθÞ ð3:11Þ
Unfortunately, the estimates of availability described in Eqs. (3.8), (3.9), (3.10)

and (3.11) do not consider failure rates for permanent faults and malfunctions
separately. There is no doubt that a permanent fault of almost any main aircraft
element would cause some kind of accident.
However, malfunctions caused by aircraft hardware, software or the user (pilot)
might be tolerated if some redundant resources were available to affect some level
of effective reconfiguration. Therefore, analysis of safety and the safe completion
of flights using classic availability definitions must be used with caution and
carefully qualified. The mindset of the designer needs to be broadened, taking in
the whole aircraft as a system.
The issue of different failure types, malfunctions and permanent faults, requires
the introduction of conditional probabilities to differentiate them in equations
above; this unfortunately creates a substantial growth in the set of states describing
aircraft conditions. Achieving a solution of these new equations during flight to

produce some kind of index of reliability would indeed be problematical.
At the same time, having further details of failure “semantics” provided by after-
flight analysis in terms of reliability trends for an aircraft might be extremely useful
for analysis of flight safety and relative involvement of all aircraft elements. To
make equations from the section above useful we need to define where and how
much we can apply them and the scope of domain of aviation where such analysis
can give benefits.
The Safety Maintenance Landscape
Developments in Modern Aviation and Safety
Modern aviation is affected by many trends:

• Increasing amount of air traffic
• Number of aircraft in active operation worldwide:
• At a peak, 12.5 K units are in use in CA and 300 Kþ for GA
• Increasing complexity of aircraft
• Increasing cost of aircraft
• Increasing maintenance overheads
• Lengthening the period of commercial exploitation, i.e., operational use
• Increasing capacity for passengers
• Increasing volume and weight of loads
Theoretical and technological developments are involved in these trends and,
indeed, make many of them possible in the first place.
In the theoretical domain, two theories are usually mentioned: the theory of
control and the theory of information. In the technological domain, there are, for
example, the new global positioning system (GPS) [3] system and new materials
such as composite structures that increase durability and reduce the weight of
aircraft.
In CA, the improvements in theory and technology have had a financial impact
on both on-board and on-ground aviation activities. Approximately half of the cost
of a typical modern CA aircraft is for avionics, navigation systems, engine control
systems, on-board software and hardware. So far, several billions of euros, dollars
and pounds sterling have been spent globally on new air traffic control systems and
new GPS installations.
According to a recent publication in the Economist magazine, the number of
accidents continues to grow, in spite of this substantial investment. During just one
week in August 2005, three accidents took place and nearly 500 people lost their
lives in aircraft crashes. The year 2014 exceeds all previous records in this sad
record. The end of 2016 again took away several hundred people. Putting it politely,
The Safety Maintenance Landscape 81
there is still no apparent improvement to air safety either in Europe or in America.

Or anywhere else in the world, for that matter.
Another big, “conceptual issue” in aviation broadcasted and promoted world-
wide is the concept of “free flight”. This is an air traffic control method that uses no
centralized control (e.g. air traffic controllers). Instead, parts of airspace are
reserved dynamically and automatically in a distributed way using computer
communication to ensure the required separation between aircraft. It was initiated
in the USA and finally has reached its European supporters in this century. This
concept, when implemented, may well make the safety situation even worse. The
concept is well supported by the European Union and has been promoted in Europe
by Siemens as presented in [4–11]. Perhaps not too surprisingly the free flight
concept will require billions more euros of investment in high-tech computer-based
systems. Discussions concerning the basic idea of free flight started in 1993 [4–11],
and since then its backers have kept promising economic efficiency for aviation, for
every aircraft, for every flight. The main benefits that have been promised are
freedom of manoeuver and that flexibility of flights would be dramatically higher.
By its very nature, the concept almost guaranties a reduction in aircraft safety
and operational safety. The free flight concept, as currently proposed, practically
excludes existing safety management systems and proposes very little to replace
them. We remain sceptical of the prospects for using the free flight concept to
improve safety of flight and believe that it will be hardly possible to maintain the
existing level of safety with this heavyweight campaign for more “freedom”.
We note that general aviation actually is already using, directly or indirectly, the
concept of free flight. Sadly, GA accident statistics prove the level of incidents and
accidents are an order of magnitude higher than in the CA sector. Hardly an
outcome to strive for!
Generally speaking, there are strategic and fundamental weaknesses in the way
that new technologies are applied to aviation. There is a “morally unjustifiable” gap
highlighted by the use of modern technologies for automating routine procedures of
flight rather than using them to ease critical situations. For example, there has been
recently a spate of fatal accidents involving CA and GA aircraft being left solely
under the control of an autopilot, resulting, of course, in a crash.
In other words, new technology tends to be used to provide a bit more comfort
(even when it is not really necessary) with the side effect that it can (and sometimes
does) mislead the crew, or create complications when the situation demands serious
and immediate reaction. As a result, some technology-based applications tend to
provide less rather than more safety. . .and create additional emergency situations!
This view may seem pessimistic; but the net effect of the indiscriminate “adding” of
technology without a clear and commonly understood vision of what fundamentally
needs to be achieved is that safety is not being improved.
Instinctively, one might think that by using technology effectively, safety could
really be improved: the more data we have, then the more we should be able to
know and so our awareness should be better and some accidents should become
avoidable. There is no shortage of data; today, typically 600 MB of data per flight
can be collected from on-board sensors and systems for modern aircraft such as the
A380 or Boeing 777. Unfortunately, there is much raw data, but little safety
information.
In the last decade, the number of devices and volume of data collected in-flight
has increased tenfold. Given that this volume of flight data is in some sense
“available,” it is natural to assume that it would be routinely processed and safety
would also be improved. However, even the most comprehensive statistics of
aviation accidents presented in International Civil Aviation Organization (ICAO)
annual documentation [12], Boeing [13] and the latest two independent sources [14]
show that during the last 18 years, international commercial aviation continues to
suffer a substantial amount of fatal crashes per million departures, up to 900 fatal-
ities from 22 accidents.
It should be of even greater concern that the level of safety in GA is much lower
(see [15, 16]). Many terabytes of flight data have been accumulated from existing
safety systems in CA. It would be natural to expect that this data information could
be analysed and used to improve safety in future aircraft and flight operations.
Recent publications [12–14] show that this is not the case; the rate of accidents
during the last few years, and especially in 2016, has actually grown. This indicates
just one thing: new technologies and information in terms of flight safety have until
now not been used properly or efficiently and, worst of all, not effectively.
In GA, safety aspects of aircraft design and operation are less well developed
than in CA. This is not too surprising given the lower budgets available to owners
and operators in GA for the purchase and support of the aircraft, including its
operation and maintenance. Another aspect is the rather lax regulatory regime
covering GA operations and its enforcement. Consequently, there are rather rudi-
mentary facilities available at airports and on landing strips (see Chap. 1). The
challenge, therefore, is to find a way to effectively improve safety in both sectors
CA and GA without significant cost.
Developments in Risk
In 1998, a case for a “decrease of statistics” was proposed by Boeing [16] for
crashes down to 0.88 fatalities per million departures. Of course, this simply did not
happen, as there are no initiatives to make necessary safety changes and the
statistics have persistently indicated that nothing had really changed at all!
One has to wonder why it was thought that it might be physically possible to
have such a “decrease of statistics,” other than there being some possible “benefit”
for the proposers arising from the misrepresentation or disregarding of the data
being collected. On the contrary, we believe that:
the only way to bring more safety into aviation is to process the available data and extract
information that can help to continuously diagnose and make a prognosis about current
risks and hence take action to reduce them insofar as it is immediately possible.
Only if there is a known cause is it feasible for the statistics of crashes to be used
to start improving safety systematically and automatically.
Chain Mode Flights
A relatively new managerial invention for increasing the utilisation of aircraft is

called “chain mode flights”: the same aircraft is kept operational in the air for up to
20 hours a day. Inevitably, this intensive mode of use further limits the opportunity
for flight data analysis due to tight turnaround schedules at each stopover. In fact,
the only opportunity to process the accumulated aircraft flight data is after a return
to base, but even the concept of an operational base is becoming weakened in the
struggle for maximum operational efficiency.
This, by definition reduces safety, even for CA, simply because the latency
period for detecting and reacting to any on-board event (fault) is increased enor-
mously. Figure 3.5 shows how flight information might accumulate during chain
flights (four flights are assumed).
The figure illustrates that information during each flight is accumulated; how-
ever, between flights it should be processed and any significant data (actually
information) should be made available as a basis for judging whether subsequent
flight(s) would be safe. If the safety management system can be provided with such
data processing and analysis after each flight, then the flight chain data would look
more like that shown in the lower bands of Fig. 3.5.
Before the next flight, the results of previous “express” analysis should be made
available for processing. After the final landing at the end of the “chain of flights”
(back at base), the detailed processing could then take place. Note that it is much
more common that CA aircraft are used in chain-mode flight and it is becoming
almost standard operational practice for most of the lower-cost CA airlines.
- Information between flights, ready for express analysis
- After-flight information, ready for express analysis
Fig. 3.5 Accumulation of chain mode flight information (in tens of megabytes)
Latency of Fault and Safety Monitoring
The latency period between a fault appearing and its manifestation is of crucial
importance for safety management. The old adage “prevention is better than a cure”
has sometimes sadly been ignored when it comes to flight safety management. A
spectacular and rather grim example of this is the Space Shuttle Challenger disaster
[17–19]. In this case, although data had been monitored and recorded many times,
the data were not processed in real time and vital safety information was simply not
available when it was needed most. Even worse, it is quite probable that the crew
could have survived if the goal of the safety management system had been to
actively avoid risk in real time.
The Challenger case is worth some more detailed analysis, as any new aircraft
safety management system should learn from the mistakes of others and avoid their
repetition. The main elements of the Challenger disaster are shown in Fig. 3.6. The
main propulsion elements are two solid-state boosters and an external fuel tank. In
addition, the orbiting manoeuvring system includes two small engines that are used
when changing orbit and then to guide the return to Earth.
Two minutes after blast off, the solid-state boosters are jettisoned from the
spacecraft. After eight minutes of flight, the external tank is jettisoned. This
illustrates that reconfigurability is the key design, functional and operational feature
of the Space Shuttle.
According to the available information about the Challenger accident, it is a fact
that leakage of gas from a seal during blast-off was recorded by on-ground
monitoring devices several seconds before its physical appearance and
External tank,
Solid-state
jettisoned,
booster,
480 sec after
separation 120
launch
sec after launch
Winged orbiter
Solid-state booster,
separation120 sec
after launch
Orbiting
Manoeuvring
System
(Two engines)
Fig. 3.6 Potential for reconfigurability of the Space Shuttle

Visual Accident
manifestation
of leak
Flight blast Leak Flight data

recoded
Time of possible
emergency reconfig-
uration and recovery
of Challenger to the
safe state
10 seconds
72 seconds…
Fig. 3.7 Relative timing of the Shuttle accident sequence
manifestation became apparent. During lift-off the gap between fault occurrence,
fault manifestation and the actual disaster was approximately 10 seconds and finally
the explosion occurred in the 72nd second of flight. The sequence of events is
shown in Fig. 3.7.
The Challenger safety system was (and still is) based on post-flight analysis,
rather than during the real time of flight. It is our opinion that this safety manage-
ment approach was a major contributory factor to the biggest loss in the history of
space exploration. A better safety scheme with a different goal could have made it
feasible to save the lives of the crew.
In the Challenger systems, nothing was done to save the situation even though all
the necessary data on the state of the spacecraft were available in real time. This is
particularly sad because the reconfigurability, on which the Challenger design is
based, could have been applied to dynamically reconfigure the spacecraft and so
make it possible for the crew to survive.
The expertise provided by Russian space program members for the authors of
this book indicates that the time required to jettison a fuel tank and/or a stage is 0.1 s
at best. Emergency separation of the spaceship with a crew on-board takes 0.2 s, or
slightly more, to avoid fatal G forces. Therefore, there was a 10 second “window of
opportunity” for the safety management system and the ground team to reconfigure
the spacecraft before the explosion. One potential option was the immediate
jettisoning of the faulty fuel tank and initiation of an OMS-assisted emergency

landing [19].
The moral of the story is that the design of the safety management system can
have a profound effect on the effectiveness and safety of the system being moni-
tored. This statement is true, especially as the safety system was systematically
implemented. In 2005, NASA finally declared that flight data recorders (black
boxes) would become an essential element for all future manned spacecraft [20].
Too little, too late.
One of the chief experts on the Challenger case, Nobel Prize–winning professor
Richard Feynman, made this statement concluding his investigation:
Let us make recommendations to ensure that NASA officials deal in a world of reality in
understanding technological weakness and imperfections well enough to be actively trying
to eliminate them. . .
Regretfully, no matter how profound, this statement has been ignored by

bureaucrats from transport, aviation, and aerospace.
Of course, the Challenger scenario is a world away from the modest flights of
commercial aviation.
There is little reconfigurability available to deploy in order to improve safety,
other than say by using only one of two engines, or as a last resort, a parachute!
However, the important lesson that can be learned is that: with the timely detection
of faults, we can decrease risk and avoid accidents.
The information gained from rapid fault detection can be used to at least warn
the crew of impending danger and in some circumstances suggests evasive action to
conserve, or improve their own and their aircraft’s safety. The key point here is the
importance of minimising the latency time between a fault being detected and the
active reaction to it by the safety management system.
The Safety Maintenance Landscape: Commercial Aviation
Even with improvements in technology, the accident rate in CA actually rose during
the period 1998–2014 as mentioned above. This growth continues. In the short
term, the prospect for CA and GA is that the number of flights will increase and
traffic intensity and its complexity will grow further. As the passenger-carrying
capacity of modern aircraft increases, the numbers of passengers will inevitably
grow and have their effect of further increasing the average casualties per accident.
As a consequence, more human tragedies are to be expected and substantial
financial losses will be incurred. It is quite evident that “budget airlines” and even
the hard-pressed, traditional aviation companies are “cutting corners” in safety
management [21, 22, 24]. Their first priorities appear to be competitive survival
and short-term profit for the shareholders. The passengers are increasingly regarded
as a commodity to be shipped from place to place. Hardly a mindset that leads
naturally to safety improvement!
The Safety Maintenance Landscape: Commercial Aviation 87
Using existing management systems and maintenance infrastructure, the main

aviation manufacturers (Airbus and Boeing) and aviation carrier companies are
unwilling to increase the cost of flights by including greater insurance and extra
payout premiums in the price of flight tickets.
Profit margins are shrinking due to tough competition even for the established
companies. Indeed, it is the well-established safety-conscious companies who are
under the most pressure; this cost consciousness will inevitably lead to a gradual
erosion of safety.
Taking the longer term view, it is obvious that the current situation is
unsustainable and that eventually the passengers and public opinion will demand
respect for their safety and their lives. However, this change of perspective will not
come naturally to the aircraft manufacturers and carriers; it will take new regula-
tions to force them to take a longer term more safety conscious approach.
Eventually, this will enforce aviation companies to pay more attention to new
concepts in aviation safety, one of which is the Principle of Active System Safety,
[25, 26].
On-Ground Management of Safety
It simply would not be practical financially to equip all airports with safety
specialists and appropriate checking devices. The aviation companies’ mantra
that “aircraft only make money while they’re flying” has to be taken seriously. Of
course, no airline will modernise its safety management system contrary to the
commercial interests of their operations and the aircraft’s owners.
General aviation has a very poor level of on-ground service compared with that
of CA and therefore can never achieve the same level of safety. Figure 3.8 shows
the typical flow of information during the flight cycle.
Fig. 3.8 Information flow (thin lines) and flight cycle (curved lines)
During each flight an aircraft should fulfil the following functions:

– Monitor hardware conditions and states
– Process flight control
– Register flight data parameters
– Directly and indirectly check pilot and crew
– Other conditions
Flight control signals and other parameters such as voice recording and physical
parameters such as air pressure, speed, height and others are registered and stored
typically every 0.125 s (8 Hz) in what is known as a frame. These frames are stored
sequentially using a tape or flash-based memory device—the so-called black box.
The standard specification for a black box has been outlined in [27]. Although all
CA aircraft must be fitted with a flight data recorder, the vast majority of GA
aircraft are not equipped even with the most rudimentary device.
Each time the aircraft lands, the recorded flight data should be processed along
the following lines, at least in principle:
• Download the data onto a special device
• Transport the data to the processing centre
– Either by service car, or
– Using secure data transmission by telemetry media, or
– Other type of special links, such as via the Internet
• Further process the flight data on the ground
• Decide about further use of the aircraft
After landing, an aircraft inspection procedure is supposed to take place,
followed by an initial assessment of the aircraft’s current condition. Then, if any
repairs are needed, they must be completed and signed off before the aircraft is
deemed to be ready for the next flight. Flight data should also be transported for
further analysis and processing to a flight data processing Centre, represented by the
tower in Fig. 3.8.
The data analysis should produce a decision regarding further flights of the
aircraft. This basic procedure is typical, but not mandatory for commercial, busi-
ness and military aviation. It is often avoided, or ignored, replaced instead by a
limited subjective visual inspection of the condition of the aircraft.
In any case, there are several obvious drawbacks to this procedure. One is the
level of coverage of aircraft fault conditions, that is, the proportion of all significant
safety aspects that are taken into account when its condition is assessed. The
recorded flight data, when analysed in the context of the flight phase (takeoff,
cruise, landing), can provide significant information for evaluating an aircraft’s
condition. After landing, nearly all devices are switched off and so it is only
possible to gauge the condition of the aircraft by subjective visual inspection.
This is hardly an effective approach for detecting actual or emerging faults of the
aircraft as a whole, or in its parts. Clearly, the notion of coverage of conditions that
may lead to an accident is crucial and should be included in the modelling and
management of safety.
Another practical problem is that maintenance engineers may not always possess
the required professional expertise. Taking into account the description in Fig. 3.8,
one may note that the weakest link in safety is the fact that safety management is not
handled systematically for the aircraft as a whole. Each part and subsystem must, of
course, be safe and certified as such. However, the aircraft as a whole needs to be
considered as a system in itself, hence the importance of coverage and the crucial
notion of fault latency mentioned earlier. The advent of chain-mode flights exac-
erbates the situation; there is severe pressure to “turn-around” the aircraft to meet
the deadline for its next prebooked take-off slot and so fit in with the carrier’s
logistics. This is a major source of pressure for safety being compromised.
The last phase of the existing scheme of safety management consists of further
copying the recorded data and its archiving in special data vaults of the regulatory
bodies such as the CAA and FAA. It is assumed that further flight data analysis
might be useful for analysis of parameter trends for aircraft in different types or
categories. Sadly, the last phase is hardly ever implemented, unless, of course, there
is an accident; it becomes normal procedure only after aviation accidents.
Consider the operational cycle of an aircraft indicated by the wide light-blue
arrows in Fig. 3.8. If the flight cycle results in the loss of the aircraft, crew or
passengers, then it is regarded as catastrophic. If the present safety management
scheme and hence safety are to be improved, then some mandatory actions are
required that are aimed at increasing the possibility for successful completion of the
operation flight cycle.
Analysis of Fig. 3.8 shows that the cycle of flight data processing, that is, safety
management, is not properly correlated and connected with the aircraft flight cycle.
Note also that these two cycles require various specialists with different skills to
ensure that all the necessary actions are completed in a systematic, consistent and
timely way.
Once again, it is clear that “human factors” will have a bearing on aviation
accidents, which is bourne out by the statistics. Note that within, say, the GA sector,
the period between routine services of an aircraft is much longer that in other
segments of aviation and this is on the increase. Taken all together, the prospects do
not look bright for improving safety with the current approach and under the current
regulatory regimes.
Timing for Safety Management between Flights
The more and more intensive use of aircraft in CA is illustrated by the gap between
sequential landing and the next take-off, which has now shrunk to around
30 minutes; see Fig. 3.9. Relatively recently, some “budget” airlines have indicated
that their target for the near future is to reduce this interval to only 20 minutes. The
main reasons driving this are the financial agreements that define the fees for an
aircraft’s use of on-ground support facilities. Once again, it is safety that is likely to
be sacrificed, or at least compromised.
Unloading
Cleaning,
Turn to service < 45 min consumer
goods
Refuelling
Unloading
Boarding
Safety
checking?
Fig. 3.9 The Flight Turnaround Process (green) and the Safety Turnaround Process (grey)
Social, Political and Commercial Aspects of Aviation Safety
There is a difference in approach to aviation safety between the various parties

involved:
1. Insurance companies and consortia such as Lloyds
2. Airline operators such as American Airlines, Delta, United Continental and
Lufthansa
3. Airport operators such as British Airports Authority, BAA, (tend to be locally
specific)
4. Operational regulators such as Eurocontrol, the FAA and CAA
5. Standards regulators such as ICAO, IATA, EASA and ECARE
6. Aircraft and equipment manufacturers
7. Flight crew and ground maintenance staff
8. Passengers
For insurance companies, airline operators (carriers) and airport operators, flight
safety is important financially. For the operational and standards regulators it is
important politically. For the flight crew, passengers and ground personnel (includ-
ing the public, e.g., 9/11) safety is important vitally.
There are many ways to achieve and improve safety: by developing new
infrastructure, by applying new and existing technologies, by introducing and
implementing stricter regulations and by improving the safety management system
(e.g., reducing latency and improving reliability). It is important to realise, how-
ever, that improvements to a safety system (e.g., PASS) need to be accepted and
applied by all parties (1–7) outlined above.
The best way to achieve an improvement depends on the object in question.
Aircraft and aviation are products of human efforts and are clearly not “natural.” At
the same time, they exist in nature and obey physical and other natural laws; there is
Table 3.1 Features of system design using various laws and regulations
Features Laws
Physical Biological Social Aviation safety
Duration Forever 20–30 years 50–100 years 25 years
Avoidability Impossible Rare, but possible Rare but possible Possible
Application rate Always High Medium Medium
no escape from the laws of physics and chemistry. Aircraft and aviation as a whole
are very probably the most complex working systems ever conceived, designed,
made, operated and used intensively in everyday life by people.
Achieving safety for aircraft and aviation requires an intensive and continuous
effort, as the problem is complex, multidimensional and changes subtly as the
operational context changes (e.g., more traffic, chain mode flights, faster flight
speeds, etc.).
It is now clear that the safety of aircraft is not a stand-alone issue; on the
contrary, maintaining safety is a process. It requires full attention and effective
management during the whole life-cycle of each aircraft, from its design, through
its operation flight by flight, up to its final flight.
An approach to evaluating the efficiency of a safety system based on the
classification of the “governing” laws is shown in Table 3.1 below:
Physical laws are unavoidable; their effect is continuous and each system and
material object is governed by them absolutely. However, the effect of such
physical laws often depends on context, for example, less gravitational effect at
very high speed and high altitude, greater heat accelerating chemical reactions.
Systems that rely on or have similar behaviour to biological laws in their design
and operation have a limited lifespan (unless, like plants and animals, they are self-
repairing and self-reproducing) and depend strongly on environmental conditions.
The third type of systems that are designed and exist in the social sphere usually
exist over a long period of system development, sometimes even centuries. In this
type of system, the laws are definitely avoidable and are applied mainly statisti-
cally, not precisely. Their outcomes are, therefore, inherently less reliable.
Aviation safety management systems are significantly characterised by the
operational lifespan of aircraft, normally 25 years. Financial pressures ensure that
aircraft are used for as long as possible, even when their maintenance becomes
more difficult and their safety increasingly questionable. Our belief is that a safety
management system for aircraft and aviation needs to be developed based on an
implementation that relies as closely as possible on systems based on the implica-
tions and realities of physical laws. Any aviation safety system is very complex,
because it relies on a mix of technological, environmental, social and physical
elements and processes.
Although the quality and reliability of aircraft and human skills varies over time,
the safety of aircraft must be at least be above some defined, absolute limit. The
safety of aircraft and aviation are not basic, fundamental and indivisible. On the
contrary, safety can be described by a procedure or algorithm (and, thus,
dynamically, as a process). The safety algorithm will have many steps and must be
applied continually during aircraft use for it to be pervasively effective.
The algorithm’s implementation requires three main types of resource, as
defined in [28]: hardware, software and human. The features and properties of the
resources directly influence the safety system itself. From this perspective, it is
evident that there is a hierarchy of human involvement and an increase of commu-
nication between humans within and between organisations. Their current duties
and roles shift the safety system into the sphere of biological and social systems. If
this is allowed to continue, then it is inevitable that the safety system will be
avoidable, unreliable and too complex to last, unable to be consistently efficient
and vigilant.
However, the application of hardware and software for the safety system core
would turn the whole safety infrastructure towards a greater dependency on phys-
ical laws, rather than on biological or social influences. Taking all this into account,
it is clear that the structure of a safety system for aircraft and aviation needs to be
based more on hardware and software implementations. Note that though the design
of this new, more physically based safety system requires a separation of concerns.
It means that the safety system itself must be designed in such a way that any faults
and errors within that system do not reduce the reliability or safety of the aircraft.
Finally, to combat the natural aging process that occurs over the operational
lifespan of the aircraft, the safety system gradually becomes more and more
important: the older the aircraft, the more “intensive care” it will need.
Flight Safety Versus Risk and Statistics: Flight Data Paradox
From the statistics of aviation accidents, it has been confirmed in [12–14, 17–24]
that a significant proportion of accidents occur during the take-off and landing flight
phases. Figure 3.10 derives data from these recent reports and shows the relative
rate of crashes in commercial aviation according to the generalised phases of flight:
take-off, cruise and landing. In GA, the rate of crashes is an order of magnitude
greater and the curve is of a similar shape. The figure shows that take-off and
landing dominate the statistics and are much more risky than normal, in-flight
operation.
The observation is rather intuitive, but to make it more rigorous, a correlation
between statistics and risk has to be proved. In any case, Fig. 3.10 confirms that
fruitful efforts to improve safety should be primarily concerned with reducing risk
during the most dangerous phases of flight—those related to taking off and landing.
Gathering, recording and processing information about these phases of flight in
order to handle risk can do this.
Surprisingly, the amount of flight data recorded during take-off and landing is
also greater than flight data during normal flight. This is explained by the involve-
ment of more devices and higher intensity of information exchange during these
phases. Currently, this information is not used and is analysed only in exceptional
Flight Safety Versus Risk and Statistics: Flight Data Paradox 93
Data
accumulation
0.6
0.5
0.4
0.3
0.2
0.1
Take off In flight Landing
Risk of accident Objective - to

change
profile reducing
risk
Risk profile
Fig. 3.10 Flight vs. data accumulation vs. generalized statistics of accidents
cases over several flights. Graphically, the direction of efforts in future aviation
safety systems is clear: to pull the risk “wings” of Fig. 3.10 down and, if possible, to
shift the whole curve down as well.
As was mentioned in the Introduction and in [15, 25, 29] it should be an
opposite—the more we know the safer we are, “forewarned means forearmed,”
“knowledge is a power even by itself” and so on. Well, it is evidently not true for
aviation, and why this is so should be addressed. Besides, if all our inventions are
subject to the weakest link of the system—a human—then to expect any boost in
reliability, performance and efficiency seems to be naı̈ve. We simply must think it
through as well.
Risk and Statistics
The risk of flight can be calculated by different models and approaches, and will
differ from actual statistics and the risk curve. One of the potential explanations for
this “discrepancy” is a data error; another is the lack of a complete understanding of
the correlation mechanisms. The problem of correlation between risk and statistics
requires further investigation and separate, rigorous research that is beyond the
scope of this book.
The problem is a new issue and needs to be tackled for any new aircraft safety
system. Also, any new safety system should include an effective analysis of the use
of flight information during the design of these new safety systems for aviation as a
whole, as well as for each sector—commercial, general and military—with add-on
specifics.
From a theoretical viewpoint, it is essential that when safety concepts are
embedded into the safety management system, the curve in Fig. 3.10 should be
flattened and lowered. Additionally, risk changes dynamically with the phase of
flight and the condition of the aircraft. For this reason, its assessment must consist
of at least two parts.
The first part is a continuous and “immediate” real-time analysis of incoming
flight information, that is, “what’s happening now.” The second part is the infor-
mation that is a distillation of flight data over an extended period. Longer-term
trends (aging of the aircraft and its individual subsystems) can be determined. This
provides the context for the evaluation of the short-term data, that is, “what’s
already happened.” It also makes it possible to refine the analysis, for example,
by dynamically altering acceptable limits of particular data values.
External and Internal Aspects of Aircraft Safety
The safety of aircraft depends on a number of internal and external factors. The
internal factors include the aircraft itself, its main constructive elements (such as
airframe, flaps, landing gear, engines, etc.), the pilot, the crew and passenger
behaviour. The external factors include weather, airport conditions, radio commu-
nication faults, ground control faults, GPS faults, airport service faults caused by
systematic or random faults of operational safety management and maintenance.
Our work has concentrated on making new theory and technological support—
devices and software for on-board active control and safety systems. Therefore, we
are solely concerned with internal aspects of aviation safety. It therefore has no
Flight Safety Versus Risk and Statistics: Flight Data Paradox 95
concerns and no material is included that relates to the other aspects of safety
management, although these could be considered and developed by other
researchers.
On this basis the safety of flight can be abstracted using a vector:
S ¼< Si , Se >
where
– Si represents the level of safety determined by on-board conditions
– Se the level of safety described by external conditions
The safety control problem can then be defined in terms of the vector S and a
proper reaction to the situation determined when Si and Se change toward an
unacceptable threshold level of safety. The function of advanced future safety
systems is to keep the internal value of S as high as possible in the real time of
flight. The challenge of active control development is to investigate ways in which
to characterise and manage safety levels and to create a monitor of flight safety. So
the theoretical problem of the aviation safety model is to create a model for flight
risk that:
– Connects with the accumulation and processing of flight data, extracting relevant
information
– Dynamically uses flight information to describe and predict the risk profile
during flight
– Updates existing statistical and real-time flight data
In turn, any new model of safety system for aircraft should be sensitive to the
volume of real-time flight data. This means the new model should be able to answer
the question:
Why don’t existing safety systems use flight information to systematically improve
safety?
Another practical question concerns the volume of information:
What is the relationship between the nature and volume of flight information
collected to reductions in flight risk?
The last question is rather idealistic, as the practice of exploitation of current
safety systems shows that existing information is not used effectively at all and
certainly not in the real time of a flight. Surprisingly, this is the case even for the
most likely risks and potential criticality.
Another problem of flight safety modelling is derived from the first two. It
concerns the meaning of flight data in terms of safety of flight. It is a problem of
the structure and organisation of the safety system for both: an aircraft and aviation.
A new safety management system therefore must process information about
weather and environmental impacts, vibrations, conditions of devices and sensors,
reliability and the complexity of aircraft hardware and software, and so-called
human factors at the same time. Also, to avoid endless modifications and patches to
compensate for poor design (so-called service pack) the safety system should be
designed based on a generalisation of the flight safety model.
Specific parameters should be used to characterise the model for a particular
aircraft and its specific configuration. This approach makes it possible to avoid
necessary modifications of the main structure of models due to the variety of
aircraft in use.
To achieve higher reliability of aircraft and aircraft safety use, the new safety
system must:
– Use existing flight information
– Accumulate essential information about previous flights
– Process existing and newly received information
– Where possible, make a prognosis concerning the future state of the aircraft
– React in real time of the flight on the basis of the prognosis
– Transmit during and after the flight essential indicators about flight conditions
Another important point is that flight information should be used by the safety
system itself, without pilot intervention, or other intervention from the on-ground
maintenance personnel during flight. Post-flight, accumulated and new flight infor-
mation should be downloaded, registered and processed.
To summarise: given all the requirements outlined for a new safety system and
an effective implementation of an on-board part safety system, it is clear that the
new system must be active and, in fact, must ensure that the pilot gets an intrinsi-
cally safer airplane to control. This can be achieved by implementing an active
safety system or, more rigorously speaking, an active system control system.
Such a new active safety system must be designed rigorously at all levels and
should be free from the known limits already mentioned. Chapter 4 will describe
exactly this—a hierarchy of models that form the logic core of active system control
regarding safety.
Conclusion
In this chapter a basic model for the reliability of flight was introduced, in relation
to a more general safety model for a sequence of operational flights. The pervading
safety landscape has been analysed based on classic reliability modelling and the
context for developments essential for the next generation of active systems. The
existing and required features of aircraft and flight safety are described in the
context of maintenance and everyday aircraft use.
Aircraft safety, maintenance and the risk of flight are discussed with the aim of
defining the role of “active” safety. It has been revealed that even though there is a
substantial amount of flight data available there has been no further actual progress
in improvement of aircraft safety and efficiency.
References 97
The examples of accidents presented illustrate that active system control and
active safety are required, with the “physical model” of the aircraft making active
use of reconfigurability of an aircraft, when it is available, to improve control of
operational flight, and thus its reliability and safety.
The proposed approach, when implemented, could help to avoid a substantial
amount of accidents. The derived features required for new safety systems for
aircraft are considered and further directions regarding the monitoring of the risk
of flight phases are outlined, addressing internal and external aspects of safety.
References
1. Birolini A (2004) Reliability engineering theory and practice, 8th edn. Springer-Verlag,
Heidelberg
2. Reliability Analysis Centre (2002) The applicability of Markov analysis techniques to reli-
ability, maintainability and safety, START. 10(2)
3. Enge P (2004) Retooling global positioning system. Sci Am May:65–71
4. Tomlin C (1999) Invited lecture series at University of Washington, Seattle, October 1999
5. Spaeth A (2000) The sky’s the limit. New World. Dec 2000(4):41–45
6. Weener EF (1998) 98 Commercial aviation safety challenges for the 21st century. Presentation
to system safety conference, 16 Sept 1998
7. Kahne S (2000) Research issues in the transition to free flight. Annu Rev Control 24:20–28.
IFAC Publications
8. Bloom R, Kahne S (1999) New roles for humans in free flight. In: Proceedings IFAC 14th
triennial congress, Beijing, PRC, 5 July 1999, Elsevier Science
9. Kahne S (1999) Security issues in free flight. In: Sivasundaram S (ed) Proceedings 2nd
international conference on non-linear problems in aviation and aerospace, vol 1. European
Conference Publications, Cambridge, pp 333–339
10. Kahne S (1998) Research issues in free flight. In: Proceedings IFAC LSS: theory and
applications, Patras, 15 July 1998, Elsevier Science, pp 1–9
11. Kahne S, Frolov I (1996) Air traffic management: evolution with technology. IEEE Control
Syst 16(4):12–21
12. http://www.skybrary.aero/bookshelf/books/2698.pdf
13. http://www.boeing.com/news/techissues/pdf/statsum.pdf
14. http://aviation-safety.net/index.php
15. Overtoon E, Schagaev I (1999) ASGA, ISSSC 18, Orlando, FL
16. Weener E (1999) Aviation safety for 21st century, ISSSC, Seattle
17. http://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/Appendix-F.txt
18. http://www.scienceandsociety.ucsd.edu/socl30/dossiers/challenger/challenger.htm
19. http://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/Appendix-F.txt
20. Manned aircraft to get black boxes, New Scientist 23 April 2005, p 28
21. http://news.bbc.co.uk/1/hi/business/2217280.stm easy jet cutting corners
22. www.lgt.polyu.edu.hk/lgtssc/documents/notices/TV_Prog5.8.doc md-11
23. www.national geographic channel, 2005 programs (1–30 August)
24. Kingsley-Jones M (2005) Reliability lessons learned. In-service report: A340–500/600 flight
international, 3–9 May 2005, pp 34–39
25. Schagaev I (1998) CoDySa: the concept of dynamic safety for Aeroplanes, ISSSC17, Seattle
26. http://www.it-acs.co.uk/files/Grant_for_a_patent.PDF
27. International Standards Organisation (2001) ISO/WD 14620–3: space systems – safety
requirements part 3: flight safety systems
28. Schagaev I Reliability of malfunction tolerance. http://ieeexplore.ieee.org/xpl/articleDetails.

jsp?arnumber¼4747323
29. Schagaev I, Goebel K. Active system control. Theory and implementation. http://www.
flightglobalevents.com/FSS16/flight-safety
Chapter 4
Active Safety Relative to Existing Devices
Active System Control and System Safety Versus Aircraft

Management
Within the aviation domain, the scope of activity of dynamic safety [1], dynamic
safety for general aviation (GA) [2], which further evolved to active system safety
[3], needs to cover all three defined phases of an aircraft’s operations, or for that
matter any other vehicle capable of flight. These are:
– Flight that is deemed “normal,” as expected and within the normal scope of
operation
– Flight that is affected by current and unexpected incidents
– After flight
The typical flow of safety-related data on-board an aircraft has already been
presented in Chap. 3.
Existing on-board checking systems are designed with the assumption that some
of the available data recorded in-flight, and stored by avionic devices, could be used
as a cross-reference when deriving recommendations on how to improve aviation
safety in the longer term, that is, for future flights. The problem is that this occurs
during post-flight data analysis and requires additional infrastructure for handling
the cumulative collection, analysis and archiving of flight data [4, 5].
Sensors in an aircraft send information to the control system and also, sometimes
in a preprocessed form, to the flight recorder. The system functions of these
recorders are oriented towards collecting, normalising and storing information
about the safety-critical object (in this case the aircraft) during its mission/flight.
The kind of data collected is oriented towards future “retrospective” investigations
about the flight, particularly in the case of a catastrophic incident, that is, after
significant harm has most probably occurred.
The system requirements for such data recording systems are derived from the
nature of a normal expected flight. In normal flight, the requirements imposed on a

100 4 Active Safety Relative to Existing Devices
system are that the flight data recorder is comprehensive, accessible and easy to use
with respect to processing the accumulated flight data after the flight. During an
abnormal incident (e.g, a crash) the requirements placed on flight data recording
systems are completely different and relate to features such as:
– High shock resistance
– High temperature resistance
– Thermal resilience
– Survivability
– Various data retrieval schemes
– Location detection capabilities
– Independent power supply from main aircraft supply
For post-accident situations, the system requirements placed on data recorders
relate to:
– Data recoverability/readability
– Data relevance/stability/consistency/reliability
– Data volume
Specifically, with respect to data recoverability/readability, resilient data con-
tainers supported by special data formats are required to allow the recovery/
retrieval of data by various procedures when incomplete, segmented or corrupted
data may be present. Resilience of the device that contains the data is the
prime goal.
The major drawback of early metallic tape–based recorders was the difficulty in
reading data after a crash, which usually led to serious losses of recorded data.
Magnetic media are susceptible to damage from even moderate temperatures when
a fire occurs after an incident. In terms of data stability and consistency, the
requirements are focused on the avoidance of situations where any flight data errors
during an accident or incident might “mask” the real data related to the cause of the
incident, e.g., possibly caused by malfunctions of the recorder itself.
With respect to data volumes, during critical emergency situations (such as those
that may lead to an accident), maximum data volume recording and maximum data
precision must be triggered somehow. In any case, at least no information should be
lost because of, for example, loss of data during compression or processing, thus
providing “loss-free” data for post-accident investigations.
To investigate existing technologies for recording flight data and their applica-
bility for active system control, a brief analysis of the state of art and future trend in
flight data recording devices and technologies is important and presented in the next
section. We also consider an important extension of the mission data recording
schemes for other vehicles and transport at large.
Safety Devices: Brief History and Evolution 101
Safety Tools and Supportive Devices
Although the main information source relevant for safety is the “conventional”
flight data recording system, there is no doubt that new requirement for “real-time-
ness” of available data requires a complete re-think and modification of the flight
data recording and a real-time processing system.
It is worth analysing the existing structure of flight safety systems, extracting
critical data and other requirements and features, and then applying them to the
main flight safety system and its elements. This makes it possible to use the method
of active system safety, which requires real time and super resilience from the
computing system.
And so a new active system is required, which is capable of performing the
existing and regular functions of a black box. Consequently a new “active black
box” should be considered as the main hardware element of the on-board active
safety system.
The safety system used for a general aviation (GA) [6] aircraft system is used as
an example. There are practical reasons for this as in terms of low price and low
maintenance; this is the nearest application domain to other transport vehicles such
as cars, lorries, yachts, boats and trains. While technology of hardware and system
software is similar for all the mentioned transport, the regulations and requirements
are slightly different from domain to domain. These are addressed in Chap. 2 and in
special sections of this chapter.
In general, an aircraft’s on-board data can be categorised as follows:
– Navigational data (e.g., heading, speed)
– Positional data (e.g., latitude, longitude, altitude)
– Dynamic behaviour (e.g., vertical speed, roll, yaw, pitch)
– Atmospheric data (e.g., pressure, temperature, wind speed, turbulence)
– Engine data (e.g., fuel and oil left, temperature, etc.)
– Voice and cabin audio recording
– Expected terrain (maps, hazards such as obstacles, cable car installations, etc.)
– Expected traffic (routes, corridors in three dimensions, and times)
The related volume of available data/information about flight over the years has
grown considerably. While initially flight parameters may have only been displayed,
nowadays most are also recorded and in some cases stored for a period of years.
Safety Devices: Brief History and Evolution
Active system safety [1], as previously mentioned, requires the redesign of

on-board devices involved in safety-related processes including the on-ground
and external safety framework. On-board safety devices should be able to aggregate
and interpret flight data in real time as well as provide the existing functions of
Fig. 4.1 Dr. Dave Warren,

“the father” of accident
recorders
existing devices. We call this an “evolutionary approach” to both system develop-

ment and system operation. There is no doubt that consideration of existing devices
and technological trends in the area of flight data recording can help identify and
clarify the requirements of previous devices and schemes that need to be inherited
by the new generation of active system control.
According to the NTSB [7], the history of flight data recording started in
Australia in 1948, when Dr. Dave Warren (Fig. 4.1) introduced his first flight
data recorder. There is no doubt that the aviation industry, users and regulators
should pay a tribute to the great efforts of this pioneer of flight data recording and
the inventor of the “black box.”
The authors of this work consider it an honour, privilege and duty to continue this
work to improve aviation safety. At the same time, the authors believe that the EU,
USA, Russia, China and Japan will react on innovation a bit faster than the
Australian authorities. Therefore, it is proposed that the concept of active system
control, including proactive safety improvement, will initially be implemented in
European and US aviation and then distributed through the rest of the world without
a 50-year delay! It is worth mentioning here that delays of implementation of best
existing practices in aviation safety is measured by continuing losses of human lives.
These black boxes typically used 0.25-in.-wide magnetic tape as a storage
medium, and the newer ones use digital technology and memory chips. A typical
such digital system permits a 25-hour continuous recording of the parameters
monitored. However, even in this case, the interaction of the system with other
on-board devices is limited to the simple recording of parameters and sequential
recording.
The next significant development of flight data recording system was
achieved for Concorde aircraft in the 1960s; see Fig. 4.2. A new feature of the
Safety Devices: Brief History and Evolution 103
Fig. 4.2 Concorde flight data recorder (Courtesy of Duxford Aviation Museum)
Non-survivable part
Positional radio signal

scheme
Survivable part
Fig. 4.3 Typical digital flight data recorders
Concord’s development (apart from supersonic CA) was that flight data were
heavily used on-board for safety management during the flight. In combination
with an on-ground full-sized flight simulator, staffed with a team of the best current
experts in the field, this approach to controlling the safety of flight was truly
innovative.
At that time, this intensive approach was not practical for regular CA and GA
purposes, but the precedent was set for the concept of flight data analysis being
performed concurrently with flight data recording in the real time of flight. The
analysis of the cumulative flight data extended over the long-term operational life-
cycle of the aircraft, that is, multiple flights.
Digital avionic systems were introduced into CA in the early 1980s and now
provide a greater volume of flight information on-board; at the same time, the
industry introduced DFDRs (digital flight data recorders) and QARs (quick access
recorders); see Fig. 4.3.
These devices have a processor and RAM-like (in terms of addressing) memory.
They also have an ability to compress and organise the storing of in-flight data. The
ARINC 700 standard (www.arinc.com) provides the basis for the design of these
systems.
Handling and compression of on-board information has shown that an average
compression factor of between 9 and 12 can be achieved without any significant
information loss. Improvements in data handling and compression technologies
indicate that data capacities might be greatly increased in the near future.
With an on-board processing capability, it becomes possible to simultaneously
record and analyse data. This immediately makes possible the new system capa-
bility for the control system and aircraft conditions to be checked in real-time.
Analogue signals are converted into digital format and recorded by the FDAU
(flight data acquisition unit). A DFDAU (digital flight data acquisition unit) can
also accept digital inputs from sensors and other avionics equipment.
New standards and technologies available now enable the storing of 2 h of
cockpit voice data and record 256 12-bit data words per second. The absence of
moving parts in nonvolatile solid-state memory (e.g., flash memory) improves the
reliability of these recorders.
According to Horne [8] accident recording should include all three different
types of recorders as presented in Fig. 4.4.
Many flight safety systems now are able to print events on the cockpit printer as
they occur. However, this does not make any sense in safety improvement terms as
pilots are fully occupied with existing information, and therefore are unable to
assess and react in a timely way to the new flow of information. Further plans for
the development of flight recording can be extracted from [9–14]. To illustrate a
need for data flight data recording now, we might consider this example:
“All aeroplanes over 5700 kg shall be equipped with a Type IA FDR”. . . there is “. . . no
significant difference in the parameter list between: EUROCAE and FAR . . .” (Caj Frostell,
the chief of the Accident Investigation and Prevention Section)
and requirements continue to evolve over time, for example,

– Transport manufactured after Aug. 18, 2000—must record 57 parameters.
– Transport manufactured after Aug. 18, 2002—must record 88 parameters.
(Dennis R. Grossi, National Transportation Safety Board).
Fig. 4.4 Horne’s classification of accident recorders

Existing Flight Data Recording Devices 105
Existing Flight Data Recording Devices
Recently implemented and announced “black box” projects worldwide (as shown in
Table 4.1) clearly show that Europe is somewhat behind in the mainstream of
current research. Taking a broader view, the new devices that support active safety
also need to address the transport market for embedded systems as a whole, across
all segments of the market—more than 210 million transport vehicles have been
registered in Europe. Some international black box trends are introduced in
Table 4.1.
Table 4.1 Existing and developmental flight safety recorders

NASA
FAA mandates major aircraft “black box” upgrade
http:// www.cnn.com/2008/US/03/10/black.boxes/
China
. . .and a new data recorder—a spacecraft black box—is
also being tested. The black box is faster than its
Shenzhou 5 counterpart and contains more storage
space, but at only half the size, Xinhua reported
(Xinhuanet, 05) (Malik, 05)
USA
• Time recorded, 25 h continuous
• Number of parameters, 18–1000þ
• Impact tolerance, 3400Gs/6.5 ms
• Fire resistance, 1100 C/30 m
• Water pressure resistance submerged, 20,000 ft
• Underwater locator beacon, 37.5 KHz
• Battery has shelf-life of 6 years or more
• Capability upon activation with 30-day operation
“Izmeritel” (Russia) new flight recorder
• Time recorded, 25 h continuous
• Number of parameters, 18–1000þ
• Impact tolerance, 3500Gs/6.5 ms
• Fire resistance, 1100 C/45 m
• Water pressure resistance submerged, 20,000 ft
• Underwater locator beacon, 37.5 KHz
• Battery has shelf-life of 6 years or more
• Capability upon activation: 30-day operation
http://www.izmeritel.smolensk.ru/spec1.html
Military Flight Data Recording Devices and Testing Recorders
It is worth being aware of military flight data recording systems and testing, and at
least, in brief, extracting requirements for these devices from various segments of
aviation.
Honeywell AR Series
The new series of advanced recorders (AR) are targeted at the recording needs for
aircraft in business/general aviation and helicopters, where space and weight are of
major concern. The recorders are designed to minimise weight, reduce installation
costs and minimise long-term maintenance. The sales price is on the order of around
$35,000 (in 2016).
The AR recorders meet or exceed all the minimum operational performance
specifications (MOPS) of TSO C-123a/C124a and EUROCAE ED-56/55A. The
recorder can record data rates of 64, 128 or 256 words per second for 25 h.
Allied Signal SSUFDR
The allied signal (now Honeywell) solid state universal flight data recorder
(SSUFDR) was designed to be an improved recording system for GA and large
CAl transport aircraft. This series of recorders is designed for use in ARINC 542A
or ARINC 573//17 aircraft systems. Respective models have up to 21 input ports
and are designed to serve as 11-parameter flight data recorders in aircraft
installations.
The recorder has 13 programmable ports, five discrete input ports, two low-level
DC ports to record acceleration, and one temperature port. The system complies
with TSO-C124 and respective environmental conditions according to RTCA-
DO 160D.
Military Aviation Recorder
This represents a typical example of a modern military aviation data-recording

device and is shown in Fig. 4.5. It is manufactured by L3 in the USA and has the
following specifications:
– Size: 3.000 H 4.500 W 6.500 L
– Weight: 6.5 lb (< 5 lb in titanium)
– Power: þ9 to þ15 VDC @ 150 mA, or 28 VDC
– Operating temperature range: 40 C to þ71 C
– Shock: 5100 g/5–8 ms, six-axis
– Penetration: 10-ft drop of 500-lb weight, six-axis, 0.05 in.2
Existing Flight Data Recording Devices 107
− Size: 3.0" H X 4.5" W x 6.5" L

− Weight: 6.5 lbs. (< 5 lbs. in Titanium)
− Power: +9 to +15 VDC @ 150mA, or 28VDC
− Operating Temperature Range: -40° C to +71° C
− Shock: 5100g/5-8 ms, six axis
− Penetration: 10-foot drop of 500-lb weight, six-axis, 0.05 in2
− Crush: 20,000 lbs. all orthogonal and major diagonal axes
− Fire: 1100°C for 60 minutes
− Seawater immersion: 20,000 ft, 30 days
− Fluids: Fuel, glycol, hydraulic, fire extinguishing, for 48 hours
− MTBF: 30,000 hours (MIL-HDBK-217E)
− Life: 17,000 hours operating, 30 years useful.
Fig. 4.5 Typical military aviation data recorder specifications
Crush surviving Housing
Aircraft Communications Non-Volatile

Interface Microcontroller
Interface Unit Memory
Aircraft Underwater
Power Supply
Power Locator Beacon
Fig. 4.6 A typical military aviation recorder configuration
– Crush: 20,000 lb, all orthogonal and major diagonal axes

– Fire: 1100 C for 60 m
– Seawater immersion: 20,000 ft, 30 days
– Fluids: Fuel, glycol, hydraulic, fire extinguishing, for 48 h
– MTBF: 30,000 h (MIL-HDBK-217E)
– Life: 17,000 h operating, 30 year useful
This device protects the data recorded from mishaps, to levels exceeding
EUROCAE ED- 55. The typical configuration of this flight data recorder is
presented in Fig. 4.6.
The mean time between failures (MTBF) for microcontroller parts and other
hardware that are not enclosed within the crash-survivable housing of the device is
much lower than for the data-recording module. For the L3 flight data recorder
L320A-C, for example, the MTBF is 6700 h. Some other properties of this device
are shown below in Table 4.2.
A relatively recent data recording solution for military flight testing has been
proposed by PLR Information Systems Ltd. (www.plr.com). Their proposal is to
mount the recorders in the cockpit, where the flight data recorder will store data in
Table 4.2 L3 recorder specifications

Size 7. 000 h x 6.200 w x 1000 d
Weight 16.2 lb
Power þ28 VDC @ 60 W
MTBF 6700 h (MIL-HDBK-217E)
MTTR 1.0 h
MMH/FH 0.0007
Life 15,000 h of operation, 20 years of usable life
Navigation System Engine Parameter Other A/C Systems
Mux Bus
FDR
Laptop
Strain
Guages
Pressure
Sensors
Temperature
Sensors Signal Conditioner Airborne VCR
Flight Data Recorder aircraft interconnections
Fig. 4.7 Military flight data processing solution proposed by PLR
standard PCMCIA flash memory cards capable of recording over 3 GB. This device
is compatible with avionic buses such as the 1553 mux bus, ARINC-429 and
RS-232/422/485 (see Fig. 4.7).
Reliability for testing devices is not a critical issue. The most important require-
ment here is the ability to accumulate and keep a huge volume of flight data and also
to provide some facility to allow processing of this data with respect to enhancing
flight control and safety.
Cassettes/tapes have in the past been the medium used in these recording devices
to solve the issue of transporting the data for further processing. However, solid-
state-based memory devices are replacing these in the majority of current systems
because of lower weight, power consumption and size, but with higher capacity,
reliability and robustness. In general, solid-state technologies are replacing
“mechanical movement” as with tape transporters and disk readers.
One danger that needs to be considered when using shared multiplex buses for
communicating data is common mode failure, that is, a single point of failure can
Requirements for New Flight Data Recording and Processing System 109
disable all communication over the bus. This concern also applies to power
supplies, hence the trend for the black box and its sensor network to be powered
independently of the rest of the aircraft to maximise the opportunity for recording
data, particularly during a crash landing, when it might be needed most.
Requirements for New Flight Data Recording

and Processing System
The requirements for the location of future flight safety recording systems were
discussed at a special Safety Board meetings [11–13], where the FAA
recommended locating two recorders in two well- separated areas of aircraft:
typically the nose and the tail. Also, the essential requirement for
autonomous power supplies for each of the recording devices was proposed to
avoid common mode failure due to power supply failure. Past experience has shown
that the last few minutes of flight often failed to be recorded due to the loss of
aircraft power.
Regarding video recorders, the NTSB/AAR-90/04 [12] meeting noted that:
The amount of information that could be provided by a cockpit video recorder is consid-
erable. The Safety Board . . . believes that application of current long duration video
technology in the cockpits of air transport aircraft could prove to be a valuable addition
to aircraft accident investigation.
In 2004, the FAA requested recording of controller pilot data link communica-
tion (CPDLC) messages. In addition to voice and flight data recording, ICAO,
EUROCAE and ARINC are considering video recorder standards and
recommended practices. The recording of air traffic control (ATC) communications
and traffic data are also under analysis by EUROCONTROL and its US
counterparts.
All organisations believe that viewing the pilot, monitoring controls and video
checking of instruments will be useful for flight safety and security. Compressed
formats of images could be used and recorded as sequential pictures at 20–30
frames per second.
Recent mathematical developments in the area of fractal theory are considered
as one of the most promising concepts in terms of sophisticated and efficient
compression of data. However, video recording of the cockpit is a cost and
industrial relations issue and not just a technical one as the capability to make
recordings has existed for many years.
In 1999, the FAA introduced new aircraft black box rules. The NTSB and FAA
have proposed tightening cockpit voice recorder requirements by the end of 2006.
Both bodies have requested video recorders and cameras in the cockpit, especially
for small turboprops that do not currently have safety recorders.
The market for these new devices for GA is estimated at 9600 aircraft (with ten
seats or more) with a cost for the aviation industry of about $256 million. Standard
Table 4.3 Current flight recorder crash/fire survivability requirements

TSO C123a (CVR) and C124a (DFDR)
Fire (high intensity) 1100 C flame covering, 100% of recorder for 30 m
(60 m if ED56 test protocol is used)
Fire (low intensity) 260 C oven test for 10 h
Impact shock 3400 G’s for 6.5 ms
Static crush 5000 lb for 5 m on each axis
Fluid immersion Immersion in aircraft fluids (fuel, oil, etc.) for 24 h
Water immersion Immersion in seawater for 30 days
Penetration resistance 500 lb dropped from 10 ft. with a ¼-in.-diameter contact point
Hydrostatic pressure Pressure equivalent to depth of 20,000 ft
requirements for new black boxes (flight recorders) are presented in Fig. 4.3.
Unfortunately, the efficiency and effectiveness of these efforts with the introduction
of new recording devices has not had the anticipated impact on aviation safety
(Table 4.3).
Flight Data Processing System Post-flight Analysis
In addition to the flight data recording system, the analysis of flight data described
above should contribute to improvement of aviation or transport safety. One of the
most advanced software packages for post-flight data processing was developed by
British Airways for commercial aircraft and is called BASIS (British Airways
Safety Information System). Details of the BASIS system can be found at https://
books.google.co.uk/books?isbn¼9401729131. The entire system consists of flight
data processing modules and reporting modules. A brief review is presented below.
Flight data processing modules are targeted at the raw flight data and, where
necessary, normalise and filter information to be distributed to the various kinds of
users (e.g., maintenance engineers, pilots, aviation experts and others).
Each group consists of several modules. The flight data group includes the flight
data exceedance (FDE) module, the flight data simulation (FDS) module, the flight
data traces (FDT) module and the flight data measurements (FDM) module.
The incident reporting modules include air safety reporting (ASR), the cabin
safety reporting (CSR), ground-found occurrence reporting (GOR), ground-
handling reporting (GHR) and human factor reporting (HFR). Other modules are
the maintenance error investigation (MEI) and safety information exchange (SIE).
Table 4.4 briefly describes each module’s function: The level of complexity of
flight data and processing continues to grow along with the number of parameters
recorded and their mutual dependencies. According to NASA:
Flight data parameters for Control and Flight analysis in military aircraft in the future will
require 120–140 parameters. . .
Flight Data Processing System Post-flight Analysis 111
Table 4.4 Functions of modules in the BASIS flight data processing system
Flight data
module Function
FDE FDE measures and monitors flight data from aircraft, analyses events by
aircraft type, event type, airfield, date, keyword, etc. FDE presents the results
in graphical formats selected as most appropriate for that particular analysis.
FDS FDS recreates the flight as the pilot saw it and represents the actual flight
instrument display for each aircraft type. FDS can reproduce flight data in
various speeds to enable faster or slower playback.
FDT FDT reads in the raw flight data from an aircraft’s on-board flight data
recorders; automatically detects exceeding, e.g., deep landing, high roll rate on
landing, etc.; stores traces; displays selected flight data and detected exceed-
ing/events as a trace on screen
FDM FDM analyses the maximum value of many flight parameters on each and
every flight, e.g., maximum “g” force on landing, maximum rate of descent,
maximum pitch on landing, etc.
Reporting
modules Function
ASR This module is used to process flight crew generated reports of any safety-
related incident
AUD Stores and analyses details of JAR Ops (flight operations, engineering, ground
operations) and health and safety audits
CSR Analyses safety incidents in the cabin
GOR Collects and analyses maintenance incident reports
GHR Collects and analyses ground-handling incident reports
HFR Displays the causal factors behind an incident
MEI Investigation of maintenance errors. It supports the determination of contrib-
utory factors
SIE Contains air safety reports from over 40 contributing airlines. The merged SIE
database is sent out each quarter of the year and contains incidents occurring
during the preceding 12 months
The varying complexity of aircraft types requires that different sets of parame-
ters be recorded. Two such different sets of flight data parameters are presented
below. These two sets concern the current and projected future requirements
(respectively) for parameter recording in advanced G aircraft.
It is worth mentioning that the classification of CA frequently overlaps with
that of the latest GA aircraft generation. Given also that CA has by far the
best safety record in aviation, it is only logical to assume that the trends in flight
data recording relating to CA will be transferred over to GA in the not too distant
future. It therefore makes sense to analyse the set of CA flight data parameters
recorded.
Constraints
Although flight safety has improved significantly over the past 50 years (see the
special chapter on this), the increasing volume of flight will cause the number of
accidents to rise from the present level unless proactive steps are taken to reduce the
rate. This is especially true for private pilots such as those operating GA aircraft, see
Chap. 3 for more details regarding the current practicalities in GA.
Safety systems are usually not welcomed by GA aircraft users/operators as they
consider the vast majority of accompanying regulations and devices as “street
robbery.” This informal quote was taken from a conversation between two well-
known engineers and US Air Force pilots. In turn, there has been a similar recent
reaction in Russia by truck drivers against system Proton (which includes registra-
tion of truck condition, health maintenance details and position). Such systems are
often referred to as the “spy in the cab,” as they provide independent evidence of
driver and vehicle behaviour. At the same time, as one reviewer of this book
rightfully pointed out:
“the status of the Pilot” should be recorded i.e. attention. pulse rate, abnormal behaviour,
alcoholic status. . .
In this sense, any new safety system introduced in the future must standout for its
unprecedented improvement in flight safety, which will in turn ensure that it is
perceived as being a value by the owners, pilots and users of GA aircraft, trucks,
cars or boats. An approach to achieving this is to offer preferential insurance terms
to operators who install such equipment and allow monitoring of the operation use
of the vehicle involved. This establishes a potential cost benefit to those adopting
the new systems. The current use of customers’ mobile phones to monitor driving
behaviour is already coming into use for automotive insurance. The client shares
the benefit of better driving via lower insurance premiums.
The costs associated with current equipment which is (directly or indirectly)
related to flight or mission safety, already exceeds “acceptable” limits. GA is
considered to be the poor relative, as avionics companies do not focus on producing
lower-cost devices for aircraft that may cost today somewhere between 100 K and
300 K euros. It should be noted, however, that there are about 300 K GA aircraft in
the world, which amounts to a significant market. In terms of on-ground vehicles in
action at every second there are about 700 million vehicles registered.
For military aircraft, safety management procedures are an integral part of
training, but sometimes ignored during missions. Each nation’s air force has its
own flight safety regulations and instructions that are not published for and/or
accessible to the wider public for national security reasons. As a result, available
information regarding military aircraft safety procedures is rather limited. The ever-
increasing cost of aircraft is now encouraging an increasing awareness of the value
of safety, and anticipating potential hazards before they become incidents.
For GA aircraft, safety checks are also limited, but in this case the reason behind
this limitation is quite different because in the vast majority of GA aircraft there is
Constraints 113
Table 4.5 Failures of safety Failures of safety management %

management ([11])
Airframe and power plants 32.9
Pilot/owner and operator 12.97
Past overhaul time 3.78
Past or no 100 hour inspection 3.24
Past or no annual inspection 1.62
no such device as the flight data recorder. Therefore, safety management in GA is

exercised based on the experience of the mechanics, engineers and pilots involved
(although in reality this human factor accounts for some – 53% of the primary cause
of GA accidents!). The same is true for on-ground transport owners although some
sectors such as road transport and rail now have compulsory safety systems and data
recorders.
The regular practice in GA safety monitoring consists of simple visual inspec-
tions and hardware on/off checks. The weakest link in the chain (the human factor)
is responsible for maintaining the integrity of the chain as a whole. To confirm this,
regretfully it must be noted, and clearly understood, that the fault almost always lies
with the pilot, owner or operator as found in most accident statistics analyses.
The use of incorrect or substandard parts, improperly installed parts, missing
parts or failure to follow airworthiness directives (ADs) [15] are considered safety
critical issues. In addition, poor maintenance of the airframe and power plant
(A&P) by mechanics (regulated by CFR Part 43) is a major issue with respect to
aviation safety. GA pilots, owners or operators mostly fail to adhere to the required
100 h inspections, annual inspections and service overhauls. The actual percentages
of failures in safety management are listed in Table 4.5.
The observations and data presented in these tables and figures confirm that GA
transport when on the ground must be managed in a different manner, but not by
means of the installation of sophisticated and expensive recorders, which are not
surprisingly favoured by avionics manufacturers, or by means of new regulations
and penalties that are favoured by the FAA, NTSB, EAA and EASA.
The first option is considered to be unacceptable because of the initial costs,
installation and maintenance expenses. The second option is unacceptable due to
the difficulty in implementation. There are two main reasons: more than one-half
of the GA pilots/users/owners are using their aircraft in remote areas (in the USA
there are more than 19,000 landing fields for GA) and their tracking by the
regulators is practically impossible because there are more than 150,000 GA
planes in use. Handling and managing just this market is a great challenge and
requires a different approach in order to have a real impact on safety
improvement.
Meanwhile, the old approach continues: the only objective information relating
to the safety of aircraft is recorded by black boxes (data recorders), and compre-
hensive analysis of GA black box information takes place only post-accident. In
any case, the vast majority of GA aircraft do not have a black box recorder on-board
at all!
The Nature of Devices for Future Aircraft
It is clear that the next generation of black boxes must be compact, extremely
resilient, and active, with the capability to make some prognostic functions on
vehicle behaviour. The requirements are summarised in Fig. 4.8 for a so-called
active black box for aviation and transport (ABBAT).
The architecture and hardware design of the ABBAT must form an ultra-reliable
system with almost theoretical minimum of power consumption and extreme
resilience and reliability. Such a system has already been developed and presented
in two related books [16, 17]. However, there is a further challenge that also needs
to be part of an integrated solution: the case of a crash where the thermal and
mechanical environments for any new device are extreme.
So, “mechanical” innovations must cover the aspects of shape and protective
design and schemes. However, the decreased weight and size and, at the same time,
increased resilience and durability required still represent a great challenge.
Fig. 4.8 Requirements and properties of the next generation of black boxes
The Nature of Devices for Future Aircraft 115
I
M
Active Black Box
P
A
C
T
Fig. 4.9 Active black box mechanical impact handling
The requirements mentioned above can be seen to be contradictory: protection

against high temperature requires layers of protection that tend to increase weight
and size, but higher thermal resistance is required for GA, business and taxi-
aircrafts. More than 15,000 are expected to be used and produced in Europe
in 2016.
Implementing specifications usually applied to black boxes, but at a smaller size,
presents a serious challenge and requires a new protective approach. Traditionally,
the mechanical resistance of black boxes has been implemented using a stabilised,
sprung platform or other vibration- and impact-absorbing platforms [9, 15]. The
current prevalence of electromechanical data recorders has influenced the approach.
These platforms tend to “reduce and smooth” the impact of the crash, assuming a
flat hit as the worst-case scenario. This solution works, but at the cost of greater
weight and size, both of which are unacceptable for taxi aircraft, business jets and
automotive transport.
To cope with mechanical resistance with much smaller weight and size, we
propose subjecting to IPR protection. The new box design will have deliberately
different support structure utilising impact-reducing legs that absorb impact energy;
see Fig. 4.9.
During an accident, the motion of the data pod might be described as a sequence:
– The impact force causes the thinner supportive leg to break
– The data pod starts rotation around the axis of the thicker leg
– The thicker supportive legs then break
– The box flies and rotates at the same time, hitting elements of the aircraft or
vehicle body
According to an initial estimate given by renowned Russian academician Dmitry
Klimov (http://www.ras.ru/news/shownews.aspx?id¼c9dad7ed-cef6-4e3d-a263-
7c8a8b013cc2) during personal meeting with the authors in 1999, this design
converts the kinetic energy of the impact into rotation. This initial estimation
indicates that this approach allows up to 75% of the energy of a direct impact to
be dissipated. Thus, this approach might, in theory, be much smaller and lighter
than a traditional black box.
The thickness and strength of the legs needs to guarantee a sequence of mechan-
ical degradation within the adequate range of impact energy. The proposed
Fig. 4.10 Vector of impact and centre of gravity might be on the same axis
Fig. 4.11 ABBAT

simulations of fall and
rotation
approach denies classic ball or square shapes as inapplicable due to the high
possibility of direct (flat) impact when the centre of gravity of the box—the point
of the impact—and the vector of kinetic energy are on the same axis, i.e., all the
energy of the hit is converted into plastic deformation of the box. The challenge and
novelty for the ABBAT device here is to rigorously define an ellipsoid shape
assuming almost immediate contact after impact (for small aircraft or cars);
Fig. 4.10.
Additionally, one needs to show that after the first hit (when the data pod starts
rotating), the energy of the second and consequential hits can be tolerated for the
survivability of the pod (Fig. 4.10).
Thus, an ellipsoid shape is to be preferred. The challenge and objective here is to
define the optimum dimensions of such an ellipsoid, assuming that it might come
into contact with a surface almost immediately after impact (e.g., in small aircraft or
cars). This is the objective of current research, that is, to define, describe and
analyse the motion of an ellipsoid and the environment together, evaluating the
forces of impact and their distribution to make a probabilistic analysis so that the
data pod can be economically and effectively designed for its optimal survival.
Additionally, it is essential to prove that after the first hit (when it starts rotation),
the energy of the second and consequential hits will not compromise the surviv-
ability of the box. Special simulation models and software need to be further
developed (Fig. 4.11) to design and analyse the interaction of its motion with the
Conclusion 117
Table 4.6 Active black box for aviation and transport vs. NASA project
FAA mandates major aircraft
“Black box” upgrade
[http:// www.cnn.com/2008/US/03/10/black.boxes/]
• ABBAT expected results:
• Impact tolerance 5000 G’s/6.5 ms
• Fire resistance 1100 C/45–60 min and higher
• Underwater beacon 37.5 Khz
• Battery life 6 times higher than above
• Active conditional control functions
• Satellite communication for maintenance and emergency
• Maintenance automatic log
• MTTF 35 years at 0.995 over the whole period
• Power consumption—5–6 time less than above
surrounding environment. A completed probabilistic estimation of ABBAT shape

dimensions vs. impact range and vectors will ease certification of similar devices in
the future.
The thermal-resistance of ABBAT using known physical and chemical coating
protection needs to take account of the smaller size and weaker resilience of
electronics to the temperature gradients and peak values likely to be experienced.
Therefore, one of the novelties of the ABBAT data pod in practice is based on the
application of a known physics phenomena: while a liquid boils and evaporates, it
maintains a constant temperature.
Choosing the right liquid with slow boiling is a promising approach for mitigat-
ing the effects of external fire impact by absorbing as little heat as possible by
rapidly dissipating away any heat absorbed by any heat sensitive components.
There are other constructive and efficient solutions, including some developed
by the authors of this book; however, this path though is not the main area of this
work (Table 4.6).
Ideally, the device on-board the aircraft should be mounted at the top level of the
tail with the strong leg towards the normal aircraft direction of motion, as illustrated
in Fig. 4.12.
Conclusion
1. Existing schemes of safety management in aviation are either conservative or

oriented toward strategic goals and after-flight (accident) analysis (CA, military)
or hardly even exist (GA). All of these schemes are easily “avoidable” by GA
Fig. 4.12 Mounting of the

data pod in the aircraft
aircraft owners and users, because of the “human” factor, the weakest link in the
chain cannot be relied on to reliably monitor and maintain the chain. The
situation gets progressively worse as the complexity of aircraft grows and they
are used more intensively.
2. Devices and elements of safety system have been briefly described and require-
ments are summarised.
3. A new model of safety management must seek to minimise the role of human
factors and be reoriented toward the intensive use of information and commu-
nication technology (ICT). A new, proactive safety management scheme is
required for aviation at large, and for GA and transport vehicles in particular.
4. The new safety system should be designed systematically, from first principles.
With this in mind, the principle of active system control is introduced.
5. All technologies that are required to implement the principle of active system
control—ICT, fault tolerance; temperature and mechanical shock-absorbing
schemes—are viable and available. However, in order to produce a practical
active safety system, serious thought and effort will be needed to ensure its
engineering, adaptation, modernisation and balanced use.
6. It has been shown that current devices are not really best-fit to the active role of
control and safety systems and should be revised in terms of both electrome-
chanical schemes and mechanical and thermo-resilient design.
7. A new conceptual design of an active black box for aviation and transport has
been introduced, aimed at and suitable for aviation and automotive transport
markets.
References
1. Schagaev I (1998) CoDySa: the concept of dynamic safety for airplanes, ISSC98, Seattle
2. Overtoon E, Miloslavin S, Schagaev I (1999) In: Proceedings of the international system safety
society ASGA: active safety for GA, ISSS99. Orlando, 16 August
References 119
3. Schagaev I (2001) CASSA – concept of active system safety for aviation. In: Proceedings of
the15th IFAC symposium on automatic control in aerospace, automatic control in aerospace
2001 IPV G. Bertoni. Bentham Press. ISBN 0080436846
4. Weener E (1998) Aviation safety, boeing, presentation, ISSC1998, Seattle
5. http://www.boeing.com/resources/boeingdotcom/company/about_bca/pdf/statsum.pdf
6. (AOPA) (United States GAO (General Accounting Office), GAO-01-916 (2001) General
aviation status of the industry, related infrastructure, and safety issues
7. NTSB symp International Symposium on Transportation Recorders (1999). http://www.ntsb.
gov/doclib/reports/1999/RP9901.pdf
8. Home, International Symposium on Transportation Recorders (1999)
9. flightsafety.org/files/analytical_methods_and_tools.pdf
10. GAO98 GAO/RCED-98-10 US General Accounting Office. Aviation safety--- efforts to
implement flight operational quality assurance programs. Web-presence: GAO/RCED-98-10
http://www.gao.gov/assets/230/225063.pdf
11. Annual Review of Aircraft Accident Data—U.S. General Aviation (2000)
12. NTSB04 NTSB/ARG-04/01 (2004)
13. National Transportation Safety Board. www.ntsb.gov/investigations/AccidentReports
14. EUROCAE13 073/ ED-112A – MOPS for Crash Protected Airborne Recorder Systems
15. Airworthiness Directives. ad.easa.europa.eu/blob/992701_superseded.pdf/AD_US-99-27-
01_1
16. Castano V, Schagaev I (2015) Resilient computer system design. Springer, Switzerland, ISBN
978-3-319-15069-7
17. Schagaev I, Kaegi T (2016) Software design for resilient computer systems. Springer, Swit-
zerland, ISBN 978-3-319-29465-0
Chapter 5
Principle of Active System Control (Theory)
Introduction
This chapter describes the principle of active system control (PASC), the elements
of theory that underpin it and models that support its realisation.
The Goals, Role and Structure of the Chapter
We have two main goals. First, this chapter generalises some features of control
systems using aviation as an example. Existing aviation and aerospace control
schemes are analysed briefly and their drawbacks are outlined. Then, the chapter
further develops PASC, initially presented in 1994 and later widely discussed
between 1998 and 2016 [1–3]. As an application example, we use the domain of
general aviation (GA) because modern ground transport and GA—and the technol-
ogies applied to each—are very similar in complexity.
When it is applied to improve safety, the PASC introduces proactive behaviour
with respect to the state of a system during a flight or mission. For real-time safety
monitoring, the available information about changes in the aircraft’s condition is
used. The basic purpose of active system control and safety is to mitigate or, ideally,
avoid the effect of detected faults or hazards. Real-time safety monitoring requires
continuous real-time information about the vehicle and modelling that implements
the PASC in order to enable a beneficial reaction on the base of information
available.
Broadly speaking, the PASC in-the-large can be applied successfully to aviation
when the functions and features of the following elements are analysed and
involved:

122 5 Principle of Active System Control (Theory)
(i) On-board implementation of continuous monitoring of conditions (e.g.,

safety, efficiency, reliability, performance)
(ii) On-ground supportive schemes
(iii) Global supportive PASC infrastructure for flight or mission data management
with real-time features
(iv) Development of complementary on-board, on-ground and global PASC sup-
portive systems
(v) Safety management schemes based on the model of the system in terms of
structure and dependencies—defined by and reflected from physical
phenomena
(vi) Regulatory initiatives and infrastructure to improve safety
(vii) Insurance involvement through new business models:
• Development of new business models to include the PASC implementation
• Insurance risk modelling based on safety and reliability
Note that here we are mainly concerned with point (i) above, aiming “to prove
the concept of active system control on-board implementation” [3]. Chapters 6, 7,
8 and 9 discuss modelling of the physical system in terms of dependencies point (v).
All the other points are the subjects of further projects, books and future interna-
tional programmes.
It will take a concentrated effort to make general and other forms of aviation and
transport more efficient, safer and more reliable. In this sense, this chapter is just
one step on the long journey to make European and world transport safer by using
new concepts, regulations and advanced technologies in order to make transport
Performance-, Reliability- and Energy-smart, henceforth refered to as PRE.
We call this concept the PRE-smart system and believe once it is implemented,
transport will become safer.
The announcement by Airbus in June 2005 of a delay to the Airbus 380 project
was primarily the result of safety concerns about the new aircraft. It clearly
demonstrated that safety management was a huge challenge for related European
industries and organisations. Since that time, the number of accidents and solutions
made have not made any breakthroughs in the performance, reliability and energy
(PRE) properties mentioned. It will take a long-term effort, with appropriate
technical, financial and regulatory support, to achieve actual improvements in
transport. However, the PASC concept demonstrates that further tangible improve-
ments are possible and that the problem can be tackled systematically.
First, we introduce a theoretical concept for the essential elements of redundancy
theory that are required to evaluate possible ways to achieve and analyse PRE
requirements. This includes the role of information about the condition of the object
and control elements involved. The chapter then introduces and analyses the
concept and theory of active system control. To differentiate the PASC from
existing approaches, a comparison with the concept of fault tolerance is included.
The main models used by the PASC are based on the aspects of information,
function, reliability and performance; they and their interdependence are then
Active System Control Overview 123
analysed. As a result, a scheme and an algorithm of ASC are defined and developed.
Implementation aspects are highlighted at the end of this chapter and in Chap. 6.
To investigate the limits of the PASC applicability (every good idea has its
limits!), we evaluate some real flight data from a typical GA aircraft. The cycle of
maintenance of GA aircraft is analysed in terms of safety management, and some
proposed modifications are discussed involving the application of the PASC to
substantially improve safety. This includes the theoretical foundation, analysis of
complexity and exploration of the limits of the proposed approach.
The concept of the PASC in terms of efficiency of maintenance is evaluated,
using available data and the proposed scheme, based on the use of flight data
analysis during flight. One particular type of General Aviation aircraft has been
used as an example, based on the classification scheme developed previously. The
longer-term, broader view of the PASC is called the application of the PASC
in-the-large and is explained in Chap. 7.
In contrast, the PASC can be applied to a specific flight, or to a short series of
flights in quick succession—a pattern of use that is becoming more common
because of financial pressures. This is referred to as the PASC in-the-medium and
involves continuously monitoring the level of safety of aircraft or vehicles equipped
with the PASC implementation system. Statistical and probabilistic methods are
used extensively to derive, define and update the PASC models in order to diagnose
and make a prognosis about the behaviour of an object in such circumstances.
At the finest level of granularity, the PASC can be applied as the PASC
in-the-small and is concerned with the reliability and efficiency of on-board avion-
ics and the control system itself; that is, the equipment required to provide the
PASC functionality on-board the aircraft must be an order of magnitude more
reliable that the moving vehicle itself. The internal features of the PASC, in
terms of performance and reliability, can be supported, and are henceforth referred
to as the PASC in-the-small. Reliability and performance models will be developed
together to characterise the features of the theoretical models qualitatively and also
explore the limits of their applicability quantitatively. This was substantially
covered by our recent books [4, 5] and is not discussed in detail in this work.
Active System Control Overview
One of the aims of this chapter is to describe the PASC and to follow-up on [1, 3]
targeting control of system-state essentials to manage efficiency, safety and perfor-
mance of the vehicle. We will be using a GA example as the field of application.
The information needed is gathered on-board the vehicle and also provides a
recording of flight or mission data. Rather than just recording data during flight, to
support post-crash analysis, the PASC involves the analysis of the currently avail-
able data in real time during the flight or mission and the continuous reaction to it
for the purposes of reliability, efficiency, performance, quality of maintenance and
with the aim of accident prevention. The scheme is illustrated in Fig. 5.1.
Fig. 5.1 Overview of the

PASC scheme Flight
Control
System
On Board
Active System
Control
(PASC)
Flight Data Flight Data

Flight Data Processing Memory
Interface Unit Unit
The theory of the PASC is developed using models of different aspects of the
system: the physical system, the system states dependencies, information flow,
reliability and operation. These models make it possible to achieve the goal of
implementing the active system control concept and so evaluate the practical
applicability of the PASC.
In later chapters, the dependencies within and between the models will be
analysed to enable the definition of the features, functions and structures of the
PASC software and hardware.
A comparison between the existing and proposed system structure of aviation
safety will be presented with the aim of analysing the potential efficiency of the
system of active control.
In terms of system software, the main characteristics of the PASC will be
required:
• Extremely high reliability
• Fault tolerance
• Fault-tolerant concurrency
• Recoverability of processed data
• Supporting mechanisms for real-time fault detection
• System reconfiguration support in the case of hardware fault or degradation
• High performance
• Hard real-time scheduling
The PASC was initially introduced in the early 1980s as “a concept of dynamic
safety for aviation” [1, 3]. It has become obvious since then that the PASC can be
implemented worldwide for GA and CA, for transport at large, and in fact for any
other systems or infrastructures that deal with moving substances or masses. This
was followed up by further publications [6, 7], and by Boeing [8–13] this leads us to
believe that PASC will be applicable in the global marketplace. In addition to the
existing possibilities for analysis of flight data after an accident or incident, PASC
Active System Control Overview 125
will make it possible to offer comprehensive preventive analysis and management

of flights in real time, including but not limited by safety.
General aviation, cars, trucks, railway transport, and aircraft are not particularly
well supported by on-ground safety maintenance systems, as already has been
discussed in previous chapters. In this regard, the need for flight data processing
becomes crucial. The practicality of the PASC is based on the assertion that it is
possible to monitor and predict the condition and behaviour of the aircraft’s or
vehicle’s main flight (or mission) agents (i.e., pilots, aircraft, subsystems, electron-
ics, etc.) and either exclude or reduce the risk of an accident/incident, or at least
reduce the level of possible harm. Real-time analysis of flight data during a flight is
involved, as well as analysis of previously accumulated data from previous flights
of the particular aircraft, that is, the historical data that characterises its operation.
Implementation of the PASC will directly benefit:
• Individual countries at large: by using and transferring results of the project to
other transport segments and implementing them at a European level (the
“Safety for Citizens” strategic goal)
• Worldwide: aircraft owners and users, as their operations will be much safer
and secure; and the general public as there will be fewer accidents and/or
incidents
• Main regulatory and funding bodies such as FAA, DG TREN, EuroControl and
ACARE: as they will be able to introduce new, progressive and easy-to-imple-
ment regulations and also maintain regulations based on new technological
innovations and sound theory
• European industries involved in aircraft and avionics manufacturing: by creating
a new segment in the world aviation market
• Insurance companies: as the PASC will help to create the basis for a new
insurance market for GA based on monitoring operational safety, which simply
does not exist at the moment
The successful implementation of the PASC will require the use of all chapters
in this book and two previously published works from 2015 and 2016 [4, 5], as well
as our patent [14]. Conceptually, development will be implemented by hardware
and system software with absolutely new properties. An analytic estimation of the
expected gain in reliability can be made by using the approach outlined here and
also in [15].
In Chap. 1 the aviation market as a whole, and the GA market in particular, as
well as the on-ground transport specifics in terms of design and exploitation, were
all analysed. Trends and challenges at the conceptual and technological levels were
considered and discussed, including cross-segment and segment-specific (for GA)
aspects (such as IT and information processing, use of GPS, navigation avionics,
etc.). From this, it became clear that GA as well as on-ground transport featured
higher risk and lower safety characteristics in comparison with other segments of
aviation. The practical goal of the PASC was to reduce the former and promote the
latter.
At the same time, the PASC should be integrated into and modify existing
exploitation and maintenance. At a different level it will be necessary to adjust
safety definitions and regulations we are seeking to conform with, or complement
them wherever possible. This should be done at least “in spirit,” aiming to create
“common ground” with existing documents and initiatives, programmes and stan-
dards such as EASA and ACARE. In line with this, the flight risk profile should also
be investigated—across all phases of flight—considering both external and internal
risk factors.
Special attention has been directed to the analysis of potential models because
this aspect defines the performance and reliability required of the PASC equipment
itself. All the PASC equipment, as potential future standard avionic devices for GA,
and transport at large must possess the highest possible inherent reliability and
required performance. For further details on implementation, the reader should
refer to Chap. 4 on existing devices that describes known and new concepts of
required properties of devices for active system control.
Defining and Implementing the PASC
The development and realisation of any new concept or idea follows the standard
research practice: review existing phenomena and the state of the art, introduce a
new idea or concept and then analyse the limits of possible implementation of the
new concept or approach: the PASC follows this pattern. First, the “landscape” of
safety in aviation and aerospace is described, followed by what needs to be done to
achieve the desired results in terms of active system control, safety and reliability.
Conclusions of this chapter will be drawn indicating how the new approach to
active system control should work in practice.
It is important at this stage to clarify what we actually do and do not want to
inherit from existing safety systems to be implemented in future ones. In Fig. 5.2
this is referred to as diagnosis of the problem (of control) and accumulation of
essential features (of the new active system control).
We also should identify the essential requirements of an active safety system,
specifically for GA and similar transport vehicles. Elements of the theory and an
initial algorithm to implement the PASC are then introduced. Note that the PASC
implementation for GA concentrates mostly on an implementation of on-board
equipment and data sources.
We investigate the limits of the PASC application and its implementation at
different levels of operational “granularity.” Starting from an investigation into the
lifespan characteristics of the aircraft in a broader context, an assessment can be
made about the level of active control, efficiency, maintenance and safety improve-
ment that can be achieved using the PASC approach.
Secondly, we investigate run-time features of the PASC, in other words, how the
active safety system is implemented to provide safety analysis during the real time
of the flight. Finally, the internal features of the PASC are analysed and the
Defining and Implementing the PASC 127
Chapter
Flight and aircraft features relevant for PASC
What to achieve? Diagnosis of the problem, Essential elements of

Reliability? Safety? accumulation of essential active system control
Performance?
Efficiency?
data, extracting features and safety
1,2,
3,4
Concise requirements in the format Classification of reliability and
of a conceptual solution safety methods
Principle of Active System Control

(PASC) 5
PASC PASC PASC

in the in the in the
large medium small 6, 7
Informational Analytical and Process-orientated

Model of Active Control Models of Active System Control
8
Reliability
PASC Theoretical Limits and Run-time
and
Practical Specifications Models
Safety
Further Development of PASC

Overview of work done and future
Implementation of Graph Logic
trends and plans
Model, Dependency Matrix Cortege 9,10
Fig. 5.2 Structure of the PACS research
requirements for reliability and performance are evaluated. The implementation of

the PASC at these different levels within the project is henceforth referred to as the
PASC in-the-large, the PASC in-the-medium and the PASC in- the-small.
The PASC in-the-medium is a key “implementer” of the PASC on-board aircraft.
The responsibility here is to analyse information, process-based models and algo-
rithmic implementation aspects of active safety. Several kinds of models are
introduced: informational, process-oriented and real-time safety models. Safety/
reliability, real-time models are the “executive core” of the PASC on-board.
The PASC in-the-small defines the necessary specifications for the PASC
architecture in terms of reliability and performance.
Structure of Research of Active System Control
The logical structure of the ASC research area is presented in Fig. 5.2. In this
chapter, firstly the theoretical aspects are defined, including a more detailed expla-
nation of the concept of an active system control. Similarities and differences
compared to the so-called “fault-tolerant” system design approach are investigated
and analysed; a new, generalised theoretical approach is developed, including the
use of redundancy theory for analysis of the PASC.
The three main agents (or players) responsible for the safety of flight are
investigated, along with the complexity of the algorithms required when
implementing PASC. This includes the principal requirement for volume of mem-
ory and performance of the PASC system. Bearing in mind the possibilities for
future commercialisation, an estimate of the initial feasibility of PASC is consid-
ered. Further development and details of this aspect will be continued in Chap. 6.
PASC assumes three levels of implementation: the PASC in-the-large, the PASC
in-the-medium and the PASC in-the-small. The implementation of the PASC in-the-
large is concerned mainly with the strategic impact of the implementation of the
PASC. It concentrates on the strategic aspects of active system control for aviation,
development and at least initially, envisioning a hierarchy of flight data and data
processing. This hierarchy is reflected in the design of three main elements of active
system control, efficiency and safety:
• Aircraft-borne real-time on-board active system control (PASC)
• Post-flight automatic processing—on-ground active system control (GRASC)
• Global active system control (GLASC).
In this book the approach to the PASC in-the-large is analytical, that is, to
evaluate what is possible to achieve in terms of the model of aircraft if models and
information processing (real time and historic) can be performed continuously
on-board—which is the main goal of the PASC implementation. The reduction of
risk and the growth of reliability that can be achieved over the long-term operation
of aircraft are both analysed here, including the introduction of a new model of
conditional preventive maintenance.
This segment of work was covered in Chaps. 1, 2 and 3. Using the conceptual
description of active system control in this chapter, later chapters will address
simulation, coverage, and diagnostic and prognostic features. The complexity of
the proposed model is analysed, as well as the relation to the generalised logic
sequence of the PASC implementation in-the-large.
This and subsequent chapters also cover the PASC in-the-medium, attempting to
combine flight data processing structure, performance and reliability issues.
Principle of Active System Control 129
The result is an estimate of the theoretically achievable safety improvement of

flight using various flight data. The relationship between the coverage of faults as a
function of prognostic power is investigated and the required formulas for point
availability and mission availability are introduced.
There is no doubt that the successful handling of a vehicle using the PACS
depends on the complexity of a vehicle flight (or mission) as well as the condition,
prognosis, coverage and efficiency of both historic and new information available
during flight. The number and nature of recorded parameters here are crucial, as
well as the nature of the model of a vehicle.
In this section some definitions are set out, and then an outline of the basic models
needed is defined.
Factors to Take into Account Making Active System

Control Work
The control and especially active system control of an operational aircraft or any
moving vehicle depends on equipment, as well as environment- and personnel-
related factors.
The equipment factors involve the dynamic behaviour of:
– The aircraft itself, its main elements (such as air frame, flaps, landing gear,
engines, etc.)
– The personnel involved: the pilot, crew and passengers
– Environmental factors include the weather, airport conditions, radio communi-
cation faults, ground control faults, GPS faults and airport service faults caused
by random or systematic faults of operational safety management and
maintenance
Active system control therefore has to be considered and abstracted using a
vector:
S ¼< Si , Se >
where Si represents the level of the system state determined by on-board conditions
and Se the level of the system state determined by external conditions.
The active control problem can then be defined in terms of the vector S and a
proper reaction to the situation determined when Si and Se move toward an
unacceptable threshold level of controllability, efficiency, safety, reliability, etc.
Fig. 5.3 The life-cycle of

an aircraft
The function of future advanced system control therefore is to keep the internal
value of Si as high as possible during the flight or mission as well as through the
entire life-cycle of the aircraft. This is illustrated in Fig. 5.3.
The challenge is to investigate ways in which to characterise and manage
systems-state levels by means of a special monitor.
So the theoretical problem of active system control is to create a model for flight and model
of an aircraft as a system that supports the accumulation and processing of flight data and
then dynamically uses it to describe and predict the system-state profile in the short term
during flight as well as in the long term to assist handling through the whole life-cycle of the
aircraft.
The later point is important because some faults and anomalies will develop over
time; their latency is greater than one or even several flights. Also, to avoid endless
modifications and patches to compensate for poor design (so-called service packs)
the active system control framework and devices should be designed based on a
generalisation of the flight and aircraft model, using, for example, the classification
of aircraft proposed in Chap. 1.
Specific parameters should be used to characterise the model for a particular
aircraft and its specific configuration. This approach makes it possible to avoid
necessary modifications of the main structure of models due to the variety and
particular configuration of aircraft in use.
So any new system must:
1. Use existing flight information
2. Accumulate essential information about previous flights
3. Process existing and newly received information
Definition of the PASC 131
4. Where possible, make a prognosis concerning the future system-state of the

aircraft
5. React in the real time of the flight on the basis of the prognosis
6. Transmit essential indicators about flight conditions both during and after the
flight
Another important point is that flight information should be used by the active
system itself, without pilot intervention, or other intervention from the on-ground
maintenance personnel during flight. Either during or after the flight, new and
accumulated flight data and information should be downloaded to a repository.
The new on-board active system control system must ensure that the pilot gets the
most efficient airplane to use.
Definition of the PASC
Definition 1 The PASC is an approach to continuously evaluating and processing

the state of an aircraft as a system in real time. It uses analysis of the previous and
current behaviour of the system to provide indications of its current and future
states, and then proposes actions to provide the best reliability and safe operation
under the known circumstances.
Definition 2 The PASC analyses the relationships between three models including
their interaction and mutual influence. The three models are:
• The model of the object Mo, in this case the aircraft
• The model of the faults Mf which the object may suffer currently or in the future.
• The model of the active system Mas which may mitigate the effects of the faults
or deviations.
In fact, the object and fault models when combined characterise the overall model
of active safety. Their logical dependence is presented in Fig. 5.4.
Firstly, the model of an object must be defined. Faulty behaviour can then be
interpreted based on a comparison of the “normal” and fault models. Then the
safety model can be defined to take account of the existing models and seek to
conserve or even improve the reliability of the system given the set of evident or
anticipated faults. If this can be accomplished, then according to Definition 1, an
active system safety will have been achieved. On the assumption that all three
models are stable, that is, do not change during the operation of the system, Fig. 5.4
can be modified to Fig. 5.5.
Note that it is only possible to achieve active system control and safety if the
model of the object Mo is known and constant during object operation; this makes it
possible to separate the correct and faulty behaviours of an object. A short descrip-
tion of the Mo, Mf and Mas models is presented below.
Fig. 5.4 The three basic

models Mo
Mf Mas
Fig. 5.5 Mutual

dependence of unchanging Mo
models during operation of
an object
Mf Mas
Mo models the real-world object, in the example case of a GA aircraft. The

challenge is to define the model such that it will be possible to determine the
behaviour of the object (aircraft) in the presence of a fault, or even to predict the
imminent occurrence and manifestation of a latent fault.
Mf models the set of faults that Mo can suffer, and it can also be defined as a model
itself. To take a simple example, in binary logic a typical hardware fault can
create a value in a memory cell that apparently always manifests itself as “stuck
at zero” or “stuck at one” rather than the intended value. In analogue devices,
faults are described by a threshold function—lesser or greater than required
limits, or by noise, etc. It is assumed that the set of faults of Mo is known or can
be derived. Note that faults may not just be manifested in individual values or
within absolute limits. There may be dependencies between the parameters used
to detect faults; also it may be the rate of change of a value or its long-term trend
that indicates a fault rather than its current absolute value, etc.
Mas models the object’s behaviour in terms of the prediction of the system condi-
tion, as well as the increased risk due to the loss of reliability (i.e., safety). Active
system control assumes that the system-state is monitored, and in the presence of
a fault it is preserved (or conserved as far as is possible) or there is a transition
from a correct (fault -free) state to another workable state, such that the existing
fault does not influence the system’s function or does so with a minimal and
tolerable impact. So Mas represents an interaction of the model of an object Mo
with the model of faults (or errors) and as a result may change states of the object
by proposing corrections:
Mo þ Mf ! Mas
Using these three models, it is possible to find a way or ways to avoid, exclude,
mitigate or reduce the influence of faults or deviations of the system state of the
object. This is in contrast to the traditional static approach to safety systems using
techniques such as fault tree analysis (FTA) and failure mode effects and criticality
analysis (FMECA) at design time. Of course, they still have their place in the
original design of the object, but here we are concerned with the operation of the
object over its life-cycle at runtime.
So ideally it would make sense to continually perform the FTA and FMECA
analyses dynamically throughout the operation of the system to identify current
and impending faults and then determine relevant preventative/corrective actions
and indicate them to the system’s users concisely and precisely. This would be very
difficult to achieve in practice (it is difficult enough at design time!) and in any case,
in a safety-critical system it is best to deduce or change as little as possible during
the operation of the system.
The PASC assumes that the models themselves are static during the real time of
the flight; so all models are assumed to be immutable during operation. It might
seem attractive to consider them as dynamic entities/processes Mo(t), Mt (t), Mas(t)
just to make life more interesting and interactive. However, their interaction and
time dependence can only be taken into account after flight because even a static
change in one model enforces a change that must be detected and reflected in the
others, so in practice they are inevitably co-dependent.
The question now arises as to what precisely is active system control and active
system safety in terms of the models? Let us apply Dijkstra’s method for defining
the function of a system [16]. According to this method the function of the system is
defined if it is possible to define an algorithm to implement it. This is the algorith-
mic function definition, widely used in computer science. The function introduced
here is active system control and safety and so the PASC can and will be defined and
described by the algorithm used for its realisation. The algorithm of the PASC is
referred to as the APASC; it is defined in Fig. 5.6.
The implementation of the APASC must execute step A continuously until the
current system state is “comprehended” and deemed consistent (stable) as a basis
for further PASC analysis. In practice, the complexity of the PASC implementation
will vary depending on the complexity of the object, fault and system models. Of
course, hardware support for active system control is the most time-efficient way to
implement it; the same is true for fault tolerance and safety as well. APASC, in fact,
is further generalisation of the algorithm called the generalised algorithm of fault
tolerance (GAFT). The GAFT is described in detail with the system software and
hardware support required in [4, 5].
The hardware and software platform used to implement the PASC will deter-
mine the performance possible and thus determine the resources required. In this
case the key resources are memory and processing power. In order to be effective,
the implementation of active system control and safety needs to produce the
required results in real time, that is, detection of possible trends, evaluation of
possible prognosis and reaction on the existing signals and other information should
be completed before any adverse event takes place. The Space Shuttle Challenger
disaster discussed in an earlier chapter presents a tragic example of the conse-
quences and cost of a non–real-time reaction to faults, primarily due to the lack of
an integrated active system control model.
LOOP
A: Evaluating the conditions and processes in the system that create or might create
a reduction in the current or future safety level (diagnosis and prognosis).
B: Making a decision about trends in the system in terms of control, safety (and
level of danger/risk) using discrete, semantically driven or probabilistic models
of the system (or combinations of them).
C: Determination of the reasons (or faults, or event) that cause a detectable

degradation of performance, efficiency, reduction of safety or safety level.
D: Analysis of possible reactions and options available, including full or

incomplete recovery (management of system deficiency).
E: Formation of the set of actions to restore and/or recover a system properties.
F: Estimation of the level of recovery achieved (restored).
END
Fig. 5.6 APASC, the algorithm for implementing PASC
Ultimately, the system state, resilience, and reliability all depend on time to
restore normal or acceptable conditions. Thus the length, performance and avail-
ability of the APASC implementation become significant in themselves in terms of
the implementation of new properties and processes.
PASC and Elements of Redundancy Theory
Active system control and safety assumes that the system state is monitored and in
the presence of a fault the system state is preserved (if possible) or there is a
transition from the correct (fault-free) state to another workable state, where the
existing fault does not influence the system’s function or does so with minimal
impact.
As mentioned earlier, all steps in the algorithm in Fig. 5.6 must be completed
within some required time and in such a way that the occurrence of faults and their
elimination are transparent to the system. This is in contrast to other known types of
systems that are designed to tolerate faults but with a degradation of performance
and/or functionality—so-called “graceful degradation systems” [17].
In order to be really effective, an implementation of the APASC requires
supportive redundancy. Redundancy can be analysed using the top-down approach
and first-order categories such as matter and time. Within the APASC implemen-
tation the key categories are structure and time.
Fig. 5.7 Classification of

redundancy for ASC REDUNDANCY OF ACTIVE SYSTEM CONTROL
structure information time
SOFTWARE HARDWARE USER

(SW) (HW) (US)
However, a basic function of the active system control and safety system is
information processing, and therefore information must be considered as a first-
order category too. The classification of redundancy categories (types) and their
interrelationships are presented on Fig. 5.7.
The first level of detail in Fig. 5.7 describes the conceptual elements of redun-
dancy used: structure, information and time. So, for example, an implementation
structure in the aircraft might contain redundancy; it might be possible to glide to a
safe landing without engine power or to use the engines to achieve a safe landing.
Each type of redundancy defined at the second level is implemented concretely
either by software, hardware or by user.
An example here might be duplicated or triplicated hardware elements such as
system RAM memory in the active system control and safety computer. Thus,
redundancy has nine basic variants we call types: three based on hardware, three
based on software and three based on user involvement in the APASC implemen-
tation (i.e., the PASC in the large, medium and small).
The more specific and well-defined the redundancy types are, the more charac-
teristics of the system can be expressed in terms of this classification, and the more
predictions regarding the behaviour of the aircraft can be made in terms of active
control and safety (i.e., by making active use of the redundancy to avoid risk). In the
tables below, the redundancy types are clarified and further defined using examples
from various known and widely used safety systems; in each case the suffix
indicates the main type of redundancy involved (i.e., S ¼ structure, I ¼ information
and T ¼ time):
Hardware-based redundancy types (in this case, the whole aircraft is the
hardware):
• HW(2S)—structural redundancy of hardware such as duplicated engines
• HW(S1,S2)—hardware system with different (nonidentical) units for the
same function
• HW(I1)—extra information in the hardware, to check errors
• HW(nT)—special hardware-implemented n-time delay to repeat functions
• HW(dT)—special hardware-implemented small delay to avoid malfunction
Software-based redundancy types:

• SW(2T)—double repetition of the same procedure to check the results
• SW(I)—informational redundancy of the program: back-up files, recovery
points
• SW(S1,S2)—two different diverse versions of the program for the same
function
• S(dT)—time delays realised in software when waiting for a guaranteed result
User-based redundancy types:
• US(2T)—double deliberate delay to act, used to check the results
• US(I)—informational redundancy; extra information to improve reliability
• US(S1,S2)—two pilots with different functions to increase safety
• US(dT)—small time delay to increase the reliability of the result
A similar classification approach will be used for implementation of fault
tolerance using system software and hardware in later chapters.
As described in Chap. 3 regarding aviation landscape, reliability and safety, the
occurence of faults in the hardware, software and pilot errors can reduce control-
lability and safety by introducing significant risk, which in turn may cause an
accident. Therefore, subsequent use of the aircraft without recovery from such
fault(s) would be potentially dangerous.
The situation becomes more acute as the aircraft hardware becomes more and
more complex and this itself is inconsistent in terms of safety regulations and
maintenance. Software also is becoming much more complex and almost
unmanageable. At the same time, the users (pilots) are becoming stretched to
their maximum capabilities to cope with the growing complexity of hardware and
software and the growth of traffic (i.e., the complexity of the environment within
which they are flying both inside and outside the aircraft).
The absence of some required information and of a model that provides real-time
estimation of the aircraft both exclude the possibility of reacting to the occurrence of
a fault until the manifestation of its effect. The delay between the occurrence and
manifestation is known as the latent period. The latency of the faults, the indeter-
minacy of the period before manifestation and the ultimate influence on hardware,
software and users makes it hard to solve the problem of effective formation, correct
evaluation and if possible recovery from their effect. This represents a serious and
growing problem in aviation; note that in more than half of all accidents the actual
cause was not identified; see Chap. 3 on aviation landscape, reliability and safety.
Hardware faults are considered to be of two kinds, either permanent (solid,
continual) or temporary (in this case referred to as malfunctions). A permanent
fault manifests itself by repeated unchanging signals during flight. The malfunction
has temporary character and is transparent for testing procedures.
There is no doubt that difference between these definitions of permanent fault
and malfunction can in some circumstances be rather fine: for example, when a
malfunction of a landing gear wheel happens exactly at the end of the landing phase
it can cause an accident and therefore must be considered as permanent fault. In
relation to time, if a malfunction’s presence lasts longer than the time to complete a
flight, it should again be considered as a permanent fault.
Note again that in availability terms, the faster the fault and its influence are
detected and then eliminated from the system, the better; we call this ASALAP
(As Soon and As Local as Possible). The second aspect relates more to the
technology, hardware operation, software and pilot training and should be
addressed in special research. The first enforces an embedding of checking for
system condition, states and faults at the beginning of the PASC algorithm.
The PASC Algorithm in More Detail
The system is considered to be under control and safe if and only if the APASC is
realised in full, that is, steps A–F, as shown in Fig. 5.6. Further development of the
APASC is presented in this section. The APASC consists of three very similar parts:
one for hardware, one for software and one for the user(s).
It is assumed that the APASC is applied as long as the system exists, and with the
flight data received and processed in the real time of flight. So, the APASC deals
with the following possible “triggers”:
• Hardware checking signals
• Periodic runs of testing procedures or software
• Initiated signals as in acceptance test approach
• External instruction signals such as:
– On-ground service or
– GPS instructions
In practice, the actions proposed by the APASC, related to recovery, must be
specific and due to the latency of faults; so the recovery scheme needs to be carefully
designed. If successive steps of recovery attempts are not successful and it is not
possible to determine a correct state or any acceptable degraded state of aircraft
system which enables continued safe operation, then the APASC must inform the
pilot and request that he/she deal with the final stage of exception handling of the
situation. The intention is that the APASC should propose timely and highly relevant
ongoing recovery advice to the pilot, rather than “panic signals.”
The problem of determining the set of correct states of the aircraft is particularly
difficult, and its refinement is a subject of further chapters. The structure of the
APASC implementation reflects also the physical features of errors and faults
against which APASC has been designed. This, in turn, must take advantage of
redundancy within the aircraft, when viewed as a system, as a basic means for
achieving active safety as a new system feature.
Various implementations of the APASC may differ:
• In time of completion of different steps
• In types of redundancy used for various steps
• In types of fault and errors tolerated (Mf)
User
(S,I,T)
User
Software
Hardware SW HW
(S,I,T) (S,I,T)
User Redundancy
Software Redundancy
Hardware Redundancy
Fig. 5.8 The redundancy types for implementing PASC
Figure 5.8 shows a notional APASC implementation using different

redundancy types. Redundancy based on user involvement is light green, redun-
dancy based on software implementation is mid green and hardware redundancy is
dark green. The figure shows a series of protective shells, which seek to provide
different aspects of control and safety protection based on user, software and
hardware.
In each of these shells, different techniques can be used that are specific to the
user, software and hardware, as outlined above in the three tables in the section
“The PASC Algorithm in More Detail.” For example, software monitoring of user
conditions such as health, skills, etc., is widely known. Software that can also be
used to test and reconfigure hardware and static hardware redundancy is widely
used in aviation (the use of multiple engines is primarily justified by safety
requirements).
All these redundancy types are interdependent and are designed in concert and
implemented together to achieve the final goal—active system control and safety of
the system. Naturally, each implementation of APASC will differ in active system
control and system safety features, performance and cost depending on the partic-
ular aircraft’s fundamental features.
Note also that cost of applying various redundancy types will have an influence
on the architecture and engineering solutions selected for safety and active safety
systems.
The main “ingredients” of the system (user, hardware, software) are the sources
of all the possible internal system changes and faults. By considering and using
various redundancy types the active system control and safety of the system can be
improved by design and in operation.
User Hardware Software

(S,I,T) (S,I,T) (S,I,T)
APASC APASC APASC
Fig. 5.9 APASC implementation
Thus, the elements of the problem become the elements of the solution. For
implementation the APASC can be considered to be a three-phase algorithm (as in
Fig. 5.6) applied for each part of the system, that is, the user, software and hardware
(white boxes in Fig. 5.8), implemented using redundancy types defined in Fig. 5.7,
in a sequence illustrated by Fig. 5.9.
PASC: Dependability and Fault Tolerance
The PASC concept differs from the other known concepts such as dependability
and the concept of fault tolerance [18]. Dependability assumes that the system
tolerates a wide range of various faults after their appearance. Briefly, if the state of
the hardware is denoted by SHW, the state of software by SSW and the state of user as
SUS, then the system dependability SD is:
SD ¼ PðSSW Þ&PðSHW Þ&PðSUS Þ
In other words, this is the predicate of the absence of software errors, hardware
faults and user mistakes in the system and on the set of states of the program. It is
defined and then defensive mechanisms are put in place in an attempt to ensure that
the predicate is continually true.
But dependency in practice ignores an inherent latency of faults in the system,
which in turn reduces the timely responses that can be used to avoid fault manifes-
tation and to conserve or improve the reliability and safety of the system.
In contrast with dependability, the PASC is an active part of the system itself;
this is based on step A of the algorithm of Fig. 5.6. It is proactive and operates
concurrently with the functioning of the system and is based on diagnosis and
prognosis of actual and potential fault trends in the aircraft system not just on the
actual manifestation of faults.
It is also important to understand the difference between fault tolerance and the
PASC. The key difference is that fault tolerance (or reliability or safety) is a feature
of the object, while active safety is a process. So, active system safety is NOT the
same as fault tolerance because:
• Step A of the APASC assumes proactive behaviour to search for new potential
threats and the PASC considers the model of the system and analysis of risk as
dynamic with changeable behaviour. These two processes are interacting, and
the known level of safety of the basic system is being tracked as it changes. The
PASC assumes that we, to some extent, will be able to keep the safety level
within acceptable bounds by relevant actions.
• Steps C, D and E of the APASC present an analysis of possible reasons/causes
and reactions to them.
• Step E of the APASC assumes a decision-making procedure to restore the
required level of safety in the basic system, not just following the pattern
previously (and statically) defined.
• Step F of the APASC does not exist in the algorithm of fault tolerance.
The PASC can be implemented in various ways and these reflect structure,
information and timing of the system itself. For example, all steps of the APASC
for a hard real-time (RT) system should be also developed as RT, and without any
reduction of existing features for the sake of safety.
In general, the operation of PASC should be transparent for the basic system; this
is especially true for existing systems where we are trying “to add” more safety.
However, if the system can tolerate some delays in decision-making procedures or
accept latent (hidden) erroneous conditions before active phases of the application
then some steps of the APASC might not need to be completed in real time, for
example, steps A, B, D and E.
Improving the Control and Safety of a System
A system that has not been initially designed to fit active system control or active
safety can only be improved if we either redesign it completely (to be intrinsically
pro-active and actively safe) or add a system level that will be able to measure,
analyse and control changes in the structure and dependencies of the basic system.
Complex systems, such as society, defence, transport at large, aviation, aircraft,
railways, etc., are very difficult to change, and it is certainly rarely an option to
redesign and replace anything that already exists and is already well-established.
This is true in particular for GA, because there is no prospect that all existing
aircraft can be redesigned, even on safety grounds. The fact is, “we are where we
are,” and the strategy to improve safety must therefore, for the most part, rely on
Flight
Control
System
Flight Data Piloting of Flight

Input from the Aircraft Control
Devices Outputs
Fig. 5.10 Aircraft system without the PASC
improvement by adding to the existing system. This must not, of course, unduly
affect its original function and availability.
So, to embed ASC and safety as two new features of a system, they need to be
extended with the models mentioned above to identify state changes and to reduce
risk in the system being monitored. The active system control and safety monitor
implements the PASC in-the-medium and itself must have unique features of super-
reliability and availability so that it does not also adversely affect the controllabil-
ity, safety or any other existing properties of the overall system.
The system (aircraft) without the PASC is illustrated in Fig. 5.10. Here the flight
data is collected and presented to the pilot(s); the pilot then interprets the data
within the flight context and within his/her knowledge of the previous history of the
aircraft (usually not very much). In some cases an autopilot may use the same data
to control the aircraft on behalf of the pilot.
Here the model Mo (see section “The PASC and Elements of Redundancy
Theory”) is embedded in the flight control system which itself is partly embedded
in equipment and mostly in the pilot’s brain or the autopilot’s computer.
The aircraft (and pilot for that matter) can suffer from faults, which are either
latent or manifested. The pilot, and to a lesser extent the autopilot, can react only to
manifested faults or deviations and only then when they become conscious of them.
Any latent faults remain hidden unless or until they become manifested. So the
model of faults Mf that the object may suffer currently or in the future will very
much depend on the knowledge and experience of the pilot and the pilot’s aware-
ness of the manifested faults. Consequently, the awareness of current and future risk
is very dependent on human factors and the nature of the pilot’s response to current
faults.
The evaluation of the implications of the faults/risks is also totally dependent on
human factors. Unfortunately, there is no “built-in memory” about what has
happened during previous use of the aircraft in terms of previous piloting, faults
and the actual behaviour of the aircraft; once the pilot leaves the aircraft that
knowledge is lost.
In contrast, an aircraft fitted with the PASC is illustrated in Fig. 5.11. Here, as
before, the flight data is collected and presented to the pilot(s); the pilot then
Flight
Control
Outputs
Flight Data
Input from
Devices
Flight
Control
System
Risk alerts
Active System and advice
Control for avoidance
Mo, Mf, Mas
Flight data
and trends
recorded in
here
Fig. 5.11 Aircraft system with PASC
interprets the data within the flight context and within his/her knowledge of the
previous history of the aircraft (usually not very much).
However, the flight data is also stored and interpreted by the ASC safety
subsystem, which forms a kind of “active system control and safety loop” around
the existing flight control system. Now the model of the object (aircraft) is
represented in the form of Mo in the ASC. Of course, there is still a less-detailed
and less-consistent version in the pilot’s brain too.
The model of faults Mf is also contained in the ASC and again is more complete
and consistent than the version in the current pilot’s brain. Most importantly, the
model of active safety Mas is also in the ASC, and it evaluates and interprets the
short and long flight data to extract information regarding both current and latent
conditions and faults without dependence on human factors during flight.
It also contains an “active memory” which not only stores data collected on the
current flight but also stores a condensed form of the data relating to previous
flights, that is, the aircraft’s previous behaviour. Again, this is without reliance on
human factors.
So, the resulting system, including both the aircraft and the PASC, makes for
safer operation without intervention from extraneous causes of errors and faults,
that is, the pilot, hardware and software. The existing inputs and outputs and model
of the object are used to create a landscape in which it becomes possible to analyse
the behaviour of the real object and predict its likely behaviour in the future, in
particular, with respect to faults. Note that the processing of the three models can be
Interpret current flight

data against Model of
Model of Active
Object System Control
Flight data
input
Model of
Object Evaluate current
conditions, potential risk Indication of risk
against the avoidance advice
Model of Active System
Control
Evaluate current flight data
against Model of Object and
accumulated
data
Evaluate impact of
Derived
risk and provide
States advice
Model of
Faults
Fig. 5.12 Information processing in PASC (sketch)
to a large extent concurrent in real time. This is illustrated in Fig. 5.12 as a sketch of
the internal structure of the ASCS subsystem in the form of an information-
processing model. This is discussed in the next chapter.
It is worth noting that a request to “evaluate impact of risk and provide advice” is
an action that might include in different variants of implementation such as an
autopilot of safety, an ASC scheme by itself, remote-control monitoring systems, or
pilots (at the initial stages of implementation).
A Generalised Information Model for Active System Control
This section presents a generalisation of the role of information in the process of

safety management. The models presented so far have not illustrated the role of
information in terms of determining the system conditions and risk of flight. In fact,
there are two main sources of information relevant to the condition of the aircraft: it
is either incoming information or existing information that has been derived and
processed during flight. Consider now some generalisation of the connection
between information, control and safety in flight.
An object (in this case the aircraft) can be described as an abstract model by a set
of states Ω and a “reflection” (R) of real object information into its model
presentation.
There is an opinion, often instinctively true, that the more data a model accu-
mulates about an object, the greater will be the possibility to predict the behaviour
of the real object based on the model. It is clear from their heavy reliance on CAD
and simulation techniques that Boeing and Airbus, as well as NASA, ARINC and
EASA share this opinion.
Note that the reflection process R is about a transformation of real data into data
of the model for further control, predictive processing for control and safety. In
terms of the PASC project, R is implemented by scanning the input sensors and
building up a sequence of data frames that dynamically track the flight.
The rate at which data must be sampled must take account of its intrinsic
information content as established by Shannon in the 1940s. The number of
information sources is not the key issue here; the most important feature of each
source is that it must contain information that is relevant for detecting a dangerous
system state deviation, user mistakes, software errors and hardware faults. Of
course, sometimes several information sources may need to be correlated in order
to detect (extract) the relevant information; it is unlikely to be contained within a
single source.
Information from the object is transformed by means of R into model informa-
tion about the object in a state domain Ω. This model is described by its own
transformation T of the state domain Ω: T(Ω) ! Ω. Note that the transformation T is
an internal feature of the model, not of the object itself. So the model of information
about flight can be based on the analysis of the behaviour of Ω. Growth of Ω can be
achieved by:
• Growth of “performance” R, while the reflection procedure has sufficient power
to process more info from the e existing flow of information in a timely way
• Growth of time t to form Ω using the same R, while one is able to use more time
to provide more precise prognosis, that is, the results are not required urgently
• Autogeneration A(Ω) ! Ω+, Ω+ Ω, where a new state of domain Ω+ is
generated based on the existing Ω in an attempt to achieve some additional
meaning or benefit
With active system control and flight safety in mind, the third variant of Ω
growth seems questionable as it does not involve receiving any new information
from the object for its translation into information for the model and further
decision making. This is a well-known phenomenon in any system where the
human factor is involved, for example, bureaucracy tends to create more bureau-
cracy but not efficiency.
The two other options are much more attractive: growth of time t having the
same R increases set Ω up to Ω+, and if Ω+ Ω, it means that new information
about the object is presented in the model. On the other hand, growth of the
performance of R so that R ! R+ changes the pair {R,Ω} into the pair {R+,Ω+},
where Ω+ can also be substantially bigger than Ω. Some correlation measure
between the “physical” state of the object (aircraft) and its level of control and
safety needs to be established. Let us assume it is the probability of flight success.
Now flight safety improvement is concerned with the analysis of {R, Ω, T(Ω), P},
where P is the probability of successful flight completion, and all the rest are
presented above. Other probabilistic measures will be presented later in Chap. 7.
Practically useful directions of active system control and flight safety theory
development are:
• To change Ω so that Ω ! Ω+ to increase P up to required P+ | P+ > P
• To change T(Ω) to provide growth Ω up Ω+ and P up to P+
• To vary Ω and T so, to achieve maximum of P | P: Φ(Ω, T(Ω)) ! Pmax
The symbol Φ here represents a subset of the states in Ω that describe a faulty or
strange behaviour of aircraft. Between them, Φ and Ω define a probability function
of successful flight. The transformation of existing space Ω by means of T to T(Ω)
describes the role of an active control and safety model and can be used for
evaluation of achievable flight control, safety and the efficiency of the aircraft
design and model itself.
The connection of these tasks to real-flight data is determined by the size of Ω,
the performance of algorithms and hardware (T(Ω)) and, from a different view-
point, the statistics of aviation crashes.
So in terms of information the task of analysis of flight safety can be described
by:
I u ! Ru ðI u Þ ! I m ! Rm ðI m Þ ! Ω ! T ðΩÞ ! P ð5:1Þ
where:
• Iu,Im are real information about the object and model information, respectively
• Ru,Rm are the reflections (transformations) of the features of the object into
features of the model
• T(Ω) is the transformation of the set of states in the model for further analysis of
the probability of successful flights
Growth of Ω into Ω+ might infer an indirect increase in information about the
object, but only within the limits imposed by physical laws. The number of states
connected with crashes is presented in the model as Φ, and Φ Ω and Ω Ω+.
This means also, Φ/Ω > Φ/Ω+ and so a model with a larger set of states should be
possible, at least in principle, and therefore a reduction of risk of an accident—
presuming that we are able to detect adjacent bordering states.
The growth in the number of states is determined by (Ψ/Φ)/Ω+ where Ψ goes
from Ψ/Ω+ ¼ Φ/Ω. Figure 5.13 illustrates the relationship of the set of these states.
When Φ Ψ, then there is an option for prognosis of the system-state, and
success will be more likely when the “smoother” and “regular” set of states Φ is
enclosed by set Ψ. It is worth pointing out again that Φ represents the set of accident
(risk) states, and fortunately it will not grow when Ω+ grows.
Increased set of states
“Warning” area states
W+ Accident (Risk) state(s)
Y
F
Fig. 5.13 The relation between different kinds of states
On Coverage
Figure 5.13 was made with an assumption about coverage (our knowledge about the
system or model) is a constant that represents graphically a proportion WWK/Ω
(5.2):
WWK
C¼ ð5:2Þ
Ω
In other words, what we know (WWK) in relation with what really exists: Ω.
And the more we know the greater the coverage. Knowledge can be gained in time;
therefore a coverage becomes a function of time, and not only time.
The coverage, in fact, is a function of three independent variables: information,
structure and time. By information here we mean as applied or aggregated in
relation to the particular subject or of phenomena. There is no doubt, the coverage
as a function of time is either growing or at least not shrinking one—if the system
and our knowledge about it evolves.
There is no doubt, the coverage as a function of information is a growing
function (the more we gather the more we can extract).
There is no doubt, coverage as a function of structure is a growing function—the
more links and elements we can see, recognise and define in the system, the more
we know, at least statically.
All three functions—coverage in time, coverage in information, coverage with
model of structure—are growing, depending on when the system or knowledge
evolves. All of the I, S, T growths cause growth on coverage and might have
different gradients. In the system we consider—all growing—they all have differ-
ent gradients.
Conclusion 147
It is worth mentioning that for any system description we can consider some
invariant:
System ¼ I S T ð5:3Þ
“To know everything about the subject” in terms of information, structure and
time required is constant; we speak about Ω here (see above), not coverage.
For coverage we can write:
Coverage of System ¼ Ic Sc Tc ð5:4Þ
where all variables should be considered with “c” from the point of view of
coverage.
Conclusion
• In this chapter, the theoretical model of active system control and safety was
developed from first principles.
• The principle of active system control safety (PASC)—including its theoretical
background and its connection with redundancy theory, fault tolerance and
dependability—has been introduced. This leads to a generalised information
model for active system control and safety.
• It has been shown that it is possible to apply all three main agents (hardware,
software and user) to implement ASC and safety-related processes and algo-
rithms. This requires flight information, structure and time dependencies to be
included and an understanding of the use of this information for active control
and safety monitoring.
• It is clear that the use of information and communication technology provides
the best basis for introducing an unavoidable scheme for improving aircraft
safety and making active system control achievable. It is also proposed that the
use of hardware/software safety monitors can be applied to exclude the possi-
bility of cutting corners in aircraft maintenance and safety.
• The application of the PASC in-the-medium is developed here for analysis of
states of aircraft during and after flight.
• The feasibility of the active system safety approach has been demonstrated, and
thus prevention of some accidents in the real time of flights is possible. Various
mathematical models and their features are briefly analysed.
• The nature of the connections between flight data, elements of an aircraft, the
fault dependencies between them and performance of flight data analysis should
be taken into account and will be explored in further chapters.
References
1. Schagaev I (1998) The concept of dynamic safety. In: Proceedings of the 16th ISSC, Seattle
2. Schagaev I (2001a) Redundancy classification and its application for FT computer system
design. In: IEEE TESADI-01, Tucson, October 2001
3. Schagaev I (2001b) Concept of active system safety. In: Proceedings 15th IFAC symposium on
automatic control in aerospace, Bologna/Forli, 07 Sept 2001
4. Castano V, Schagaev I (2015) Resilient computer design. Springer. ISBN 978-3-319-15069-7
5. Schagaev I, Kaegi T (2016) Software design for resilient computer systems. Springer. ISBN
978-3-319-29465-0
6. Tomlin C Invited lecture at University of Washington, Seattle, October 99
7. Spaeth A (2000) The sky’s the limit. New World 4:41–45
8. Earl F (1998) Weener 98 commercial aviation safety challenges for the 21st century. Presen-
tation to system safety conference, 16 Sept 1998
9. Kahne, S (1998) Research issues in free flight. In: Proceedings of the IFAC LSS: theory and
applications, Patras, 15 July 1998. Elsevier Science, pp 1–9
10. Bloom R, Kahne S (1999) New roles for humans in free flight. In: Proceedings of the IFAC
14th triennial congress, Beijing, PRC, July 5, 1999, Elsevier Science
11. Kahne S (1999) Security issues in free flight. In: Sivasundaram S (ed) Proceedings of the 2nd
international conference on non-linear problems in aviation and aerospace, vol 1. European
Conference Publications, Cambridge, pp 333–339
12. Kahne S (1998) Research issues in free flight. In: Proceedings IFAC LSS: theory and
applications, Patras, 15 July 1998, Elsevier Science, pp 1–9
13. Kahne S, Frolov I (1996) Air traffic management: evolution with technology. IEEE Control
Syst 16(4):12–21
14. ITACS Ltd. Method and apparatus for active system safety, Patent GB 0707057.6, (2006.01)
15. Birolini A (2016) Reliability engineering, 8th ed. Springer
16. http://plato.stanford.edu/entries/computer-science/
17. Pierce WH (1965) Fault tolerant computer design. Academic, New York
18. Bouricius W, Carter WC, Schneider PR (1969) Reliability modelling techniques for self-
repairing computers. In: Proceedings 24th national conference of ACM, pp 295–309
Chapter 6
Principle of Active System Control: Aspects
of Implementation
Introduction
This chapter describes the principle of active system control (PASC) in terms of
required elements and schemes needed to implement it. This includes the elements
of theory and models that support its realisation. PASC assumes three levels of
implementation: PASC in-the-large, PASC in-the-medium and PASC in-the-small.
This chapter describes the PASC in-the-medium by combining and relating flight
data processing structure, performance and reliability issues. Figure 6.1 shows the
position of the chapter within the content of the book.
Implementation of PASC in-the-Medium
This chapter explains how information-driven, conditional flight safety monitoring

can be implemented for aircraft. First, the flight information model is introduced,
then schemes for flight information flow and processing are described. The basic
schemes for flight data analysis are developed, considering the need for real-time
flight data analysis.
The material here also relates to that in Chap. 7 on “Reliability” as well as
extending the concept, but it also concentrates on the operational aspects, including
the flight information model, whereas the latter deals with the reliability model,
flight phases, reliability of prognosis, and also point and mission availability. The
relationship between chapters is illustrated in Fig. 6.2.

150 6 Principle of Active System Control: Aspects of Implementation
Chapter
Flight and aircraft features relevant for PASC
What to achieve? Diagnosis of the problem, Essential elements of

Reliability? Safety? accumulation of essential active system control
Performance?
Efficiency?
data, extracting features and safety
1,2,
3,4
Concise requirements in the format Classification of reliability and
of a conceptual solution safety methods

(PASC) 5
PASC PASC PASC

in the in the in the
large medium small 6, 7
Informational Analytical and Process-orientated

Model of Active Control Models of Active System Control
8
Reliability
PASC Theoretical Limits and Run-time
and
Practical Specifications Models
Safety
Further Development of PASC

Overview of work done and future
Implementation of Graph Logic
trends and plans
Model, Dependency Matrix Cortege 9,10
Fig. 6.1 Structure of PASC research
The PASC for General Aviation: The Cycle of Operational

Management
For the purposes of this chapter, the operational cycle for general aviation (GA) is
briefly reviewed (it has already been covered in detail in previous chapters). The
static flight information model for PASC implementation is introduced, including
its main elements and its constituent blocks. The information flow (i.e., flight data
Implementation of PASC in-the-Medium 151
Information-driven Active System

Control and Safety Monitoring
Chapter - PASC in medium Chapter - Reliability
Flight Information Model Flight Reliability Model
Graph of Basic Flight

Information Flow Phases
Schemes of Flight Assessing Coverage

Data Analysis Achieving Prognosis
Performance Issues: Point Availability

Complexity, Volume of Data Mission Availability
Simulation of Flight Data

Processing by PASC
Fig. 6.2 Relationship between the PASC and reliability chapters
accumulation and processing) is then described to show how the model processes
flight data, thus achieving the “activeness” of system control. Further possible
schemes of flight data analysis are explained and developed algorithmically using
a matrix of data dependencies and recovery strategies. Finally, performance and
complexity issues are discussed.
Five general phases of flight are illustrated in Fig. 6.3: taxi-out, take-off, cruise,
landing and taxi-in. Several other phases related to determination of flight modes,
described previously in chapters about reliability models and elsewhere, are using
different numbers of flight modes. It does not decrease the importance of this
chapter, however, as here we deal with PASC in-the-medium, that is, what we can
and should do on-board aircraft (and/or vehicle) to implement active system
control.
For the purposes of PASC research, only the take-off, cruising and landing
phases are relevant; the other phases involve ground control systems. Each of the
Fig. 6.3 Operational phases of fight
phases has different environments and risks associated with it, and therefore the
effects of faults during each phase have different consequences.
The cycle of operation is shown in Fig. 6.3. One aim of the PASC is to make
operational management more reliable and easier to execute; another aim is to
enhance the enforcement of safety rules. The objective is to use flight data to
anticipate potential faults and therefore to avoid, or at least mitigate, them, thus
making aircraft more reliable operationally.
Other practical factors also affect the operational reliability of an aircraft. These
include external factors such as the weather and the lack of servicing facilities
because many GA airstrips have poor-quality servicing. Internal factors also exist;
for example, the PASC itself must be ultra-reliable so that it is always available
despite poor aircraft maintenance. Also, the reliability of equipment that provides
the data feeds for the PASC has a bearing on its effectiveness.
Process-Oriented Informational Model
The implementation of the PASC assumes that the condition of an aircraft can be
predicted using flight data, and thus that some events that might reduce aircraft
properties, including safety, can be avoided.
The model to analyse flight data during flight—the model of active system
control for aircraft (MASCA)—comprises an object (in this case, an aircraft), its
elements, the functional models of those elements, the operational flight modes,
real-time flight data, predicates of an object and element states, a dependency
The Model
Real Object and its Structure

The Aircraft
Functional
Object Elements Models
Logical
The Flight
dependence
Flight Modes Flight Data Predicates
Manifestation of the States for an Object
Dependency
Matrix
Recovery
Matrix
Object Description
Fig. 6.4 Main elements of the MASCA
matrix defined on the object elements and a recovery matrix. Figure 6.4 presents the
structural organisation of MASCA.
The typical component elements of an aircraft are its wings, engines, generators,
fuel subsystem, landing gear, pilot, control system and so on. This is described in
more detail in Chap. 1, which describes in detail an aircraft as a system. An object
and its elements are presented in the top left corner of Fig. 6.4.
Component elements exist in the real world, and their conditions, as far as we
can know them, are reflected in recorded flight data. Note that the condition of one
element might be recorded (and manifested directly or indirectly) in various
snapshots of flight data; that is, there is not necessarily a one-to-one mapping
between elements and the flight data recorded.
To gain as much relevant information as possible, the meaning and interpretation
of flight data might be different in various flight modes. For example, an engine
speed of 2700 rpm during take-off might be considered normal, but during the
cruise flight mode the same value might indicate some fault in the engine, the
gearbox or the engine control system. So, the interpretation of the flight data
depends on the context of the flight modes: a logical and relational dependence
exists between them.
To manage the behaviour of an aircraft in terms of system control, active system
control and safety, a set of models is needed for each individual element. These
models might be of different types; for example, functional, probabilistic and
threshold models might co-exist for different elements. Their purpose is to provide
the basis for system prognosis, safety and reliability analysis, each with different
qualities, which might include precision of result, depth of prognosis, reliability and
performance.
The functional and other models make it possible to evaluate the condition of the
elements and then assess each element as either good or faulty. The conditions form
a vector of predicates, called the syndrome of an object. The syndromes are the
MASCA snapshots that describe the condition of the aircraft in terms of the
conditions and processes that are taking place and that are manifest in an aircraft’s
elements.
When regarding a system structurally, elements of an aircraft are interdependent
in terms of conditions, faults and sequences of possible events. The specifics of the
interdependence varies with the various modes of flight: the faulty behaviour of
each element has potentially a different impact. The interdependence between
impacts is reflected in the matrix of mutual dependence, which is called the
dependency matrix.
Faulty elements can cause various kinds and levels of harm, which may also vary
by flight mode. These consequences should be reflected in the MASCA. The
dependency matrix uses a directed graph to represent this information.
Alternative ways to react to the object’s condition, taking into account the
condition of all its elements, are defined in the recovery matrix. The use of the
recovery matrix makes it possible to analyse “what we are going to do” when a
particular situation occurs. A close relationship exists between the nodes of the
dependency matrix and those of the recovery matrix. Further details on each of the
MASCA models are described below.
The Object
The term object here refers to a GA aircraft. The model of the object consists of
elements, or elementary components, for example, the engine, pilot, wing, fuel
supply, pedal, gear, pump etc. The object and its elements exist in the real world and
represent the physical manifestation of something manufactured (even the pilot!).
The dependencies and relations between elements at the model level are now
described in more detail.
The MASCA considers an aircraft as a set of elements:
O ¼ fe1 ; e2 ; e3 ; . . . :; ek g: ð6:1Þ
OBJECT
e1 e2 e3 ek
d1 d2 d3 d4 d5 d6
d7 d8 d9
dx
Fig. 6.5 Hierarchical dependence of an object and elements
Each element of the set O is described in the model by its description. The
hierarchical dependence of an object and elements is presented in Fig. 6.5.
The object and its elements exist in terms of flight in various flight modes, during
which flight data reflecting the state and condition of each element are recorded,
typically each 0.125 s, in the form of standard data frames (records).
Flight Data
For the MASCA, a data frame is considered to be a set of vectors, or a

multidimensional array of flight data, and is denoted as:
Flight data frame D ¼ fd1 ; d 2 ; d3 ; . . . ; dx g ð6:2Þ
where x is the number of flight parameters recorded during each cycle of data
collection (and possibly transmission). For GA, there are typically between 5 and
88 parameters in a frame. A sequence of recorded frames is illustrated in Fig. 6.6.
Data values from the object’s sensors provide the signals and external variables
in the flight data. These represent, often indirectly, the condition of the object and
its elements. Each particular condition of the object might in some way be related to
the parameters collected. In turn, several flight data records taken together may
provide evidence of a trend.
The PASC project bases its work on flight parameters according to the Interna-
tional Standard 14CFR121.343, which refers to CA aircraft. The standard param-
eter sets are:
Fig. 6.6 Flight data array recording
(1a) (1) Time, (2) Altitude, (3) Airspeed, (4) Vertical

acceleration, (5) Heading, (6) Time of each radio trans-
mission either to or from air traffic control.
(1b) (1) Time, (2) Altitude, (3) Airspeed, (4) Vertical

acceleration, (5) Heading, (6) Time of each radio trans-
mission either to or from air traffic control, (7) Pitch
attitude, (8) Roll attitude, (9) Longitudinal acceler-
ation, (10) Control column or pitch control surface
position, (11) Thrust of each engine.
(2c) ( 1) Time, (2) Altitude, (3) Airspeed, (4) Verti-

cal acceleration, (5) Heading, (6) Time of each radio
transmission either to or from air traffic control,
(7) Pitch attitude, (8) Roll attitude, (9) Longitudinal
acceleration, (10) Pitch trim position, (11) Control
(continued)
Fig. 6.7 Elements and flight data dependencies
column or pitch control surface position, (12) Control

wheel or lateral control surface position, (13) Rudder
pedal or yaw control surface position, (14) Thrust of
each engine, (15) Position of each thrust reverser,
(16) Trailing-edge flap or cockpit flap control position,
(17) Leading-edge flap or cockpit flap control position.
Figure 6.7 illustrates that each element may contribute to the value of one or
more data parameter values.
In order to use the current and accumulated flight data (d1,. . .,dy) in the real time
of the flight, models for the elements involved and their dependences need to be
developed. The significance of the recorded data varies in different flight modes.
The PASC Flight Data for Trials
To implement the PASC, a series of flight trials need to be carried out using a GA
aircraft or (initially) using a flight simulator package. The data/parameters that will
actually be available on-board this kind of aircraft will be presented further. Clearly
the values collected need to be the ones relevant to the aircraft and the kinds of
faults and conditions to be detected; duplication also needs to be eliminated. A
typical list might be as follows:
1. GPS time
2. Pressure altitude
3. Indicated air speed
4. Heading
5. Outside air temperature
6. Ground speed
7. Drift angle
8. Wind speed
9. Wind direction
10. Latitude/longitude
11. Right engine fuel flow (twin-engine only)
12. Left (or single) engine fuel flow
13. Barometric pressure setting
14. True air speed
15. Mach speed
16. Density altitude
17. True air temperature
18. Rate of turn
19. Vertical speed
20. Fuel remaining
21. Track
22. Distance to next waypoint
23. Magnetic variation
24. Baro-corrected altitude
Given that GA aircraft are most likely single-engined, we can eliminate the
“right engine fuel flow” parameter from the list. This leaves us with the 23 param-
eters needed for the research PASC flight trials.
In Figure 6.8, the aircraft elements are divided into three categories: (1) the
airframe/structure, (2) the engine and (3) the systems. For our specific case (of the
PASC trial aircraft), only four elements are identified for which data/parameters are
available (and they all belong to the “systems” category); these are the air data
computer, the GPS unit, the altitude encoder and the slave gyro. The parameters
acquired from each of these elements is listed, and wherever more than one source
for a parameter is available, the parameter appears in red.
Following this categorisation, it is possible to define trends/patterns in data
“evolution.” Combinations of parameter values and/or thresholds can be used to
monitor the operation of the four previously mentioned aircraft elements and to
allow the PASC to evaluate whether an element has gone “faulty” or continues to
operate in a “healthy” manner.
However, these parameters provide data, which may be used (as described) to
assess the failure status of the air data computer, the GPS unit, the altitude encoder
and the slave gyro.
The parameters also provide some data that can be used to assess the condition/
status of further aircraft elements from which there are no direct inputs, e.g., the
aircraft landing gear, engine or aircraft fuselage, wings, rudder, etc.
Of course, more data relating to the specific aircraft would be required to be
built-in to the PASC software core [such as fuel consumption vs. range algorithms,
yield loading for the fuselage, wing(s), rudder, etc.] for such assessments to
be made.
Aircraft
Airframe / Structure Engine Systems
Air Data GPS Unit Altitude Slave

Computer Encoder Gyro
• Pressure altitude • GPS Time • Pressure altitude • Heading

• Indicated air speed • Ground Speed
• Heading • Latitude / Longitude
• Outside air temperature • Track
• Ground Speed • Distance to next waypoint
• Drift angle • Magnetic variation
• Wind speed
• Wind direction
• Latitude / Longitude
• Left (or single) engine fuel
flow
• Barometric pressure
setting
• True air speed
• Mach speed
• Density altitude
• True air temperature
• Rate of turn
• Vertical speed
• Fuel remaining
• Track
• Distance to next waypoint
• Magnetic variation
• Baro-corrected altitude
Fig. 6.8 Aircraft elements, data parameters and sources
Given the incorporation of this extra data, an example of the data/parameters that
could be used to assess the condition/status of the various aircraft elements is
represented in Fig. 6.9. Dark blue-coloured boxes show elements of the aircraft;
yellow-coloured boxes show the element categories; and pale blue-coloured boxes
show relevant (available real-time) parameters.
Note, of course, that the figure is not exhaustive. There may be further aircraft
elements for which the status can be assessed and/or monitored, or for which
parameters could be used in order to do so.
Flight Modes
In the MASCA, flight modes are considered as a set {f1, f2,. . ., fy}, where y is the
number of possible functional flight modes of the aircraft. Denote the set of the
modes as FM:
Aircraft
Airframe / Structure Engine Systems
Air Data
Fuel Tank GPS Unit
Computer
• Fuel remaining • Pressure altitude • GPS Time

• Left (or single) • Indicated air speed • Ground Speed
engine fuel flow • Heading • Latitude / Longitude
• Outside air • Track
temperature • Distance to next
• Ground Speed waypoint
• Drift angle
• Wind speed
Landing • Wind direction
Wings Rudder Fuselage • Latitude / Longitude
Gear
• Left (or single)
engine fuel flow Altitude
• Indicated air • Indicated air • Indicated air • Indicated air • Barometric pressure Encoder
speed speed speed speed setting
• Ground Speed • Wind speed • Wind speed • Wind speed • True air speed
• True air speed • Wind direction • Wind direction • Wind direction • Mach speed • Pressure
• Mach speed • True air speed • True air speed • True air speed • Density altitude
• Vertical speed • Mach speed • Mach speed • Mach speed • True air temperature
• Density altitude • Density altitude • Density altitude • Rate of turn
• Rate of turn • Rate of turn • Rate of turn • Vertical speed
• Vertical speed • Vertical speed • Vertical speed • Fuel remaining
• Track Slave
• Distance to next Gyro
• Heading
Fig. 6.9 An example of aircraft elements and data parameters dependency
n o
FM ¼ f 1 ; f 2 ; . . . ; f y , ð6:3Þ
For the most known classification of flight phases, y ¼ 10 and elements of the set
FM are as follows:
f1 pre-flight/post-flight maintenance
f2 “push-back”
f3 taxi-out
f4 take-off
f5 climbing
f6 cruise (in flight)
f7 descent
f8 approach/landing
f9 taxi-in
f10 “lock-down”
Each change from one flight mode to another is assumed to be instantaneous.
The set of flight modes (FM) contains two subsets: main Fm and supportive Fs.
The object (aircraft) itself is in the subset of main modes Fm during take-off,
cruising and landing; it is in Fs when the preparatory or post-flight procedures
take place. It is assumed that an object starts from the preparatory state before it
initiates the sequence of the main modes in fj 2 Fm. In terms of the flight mode
phases listed above:
Fm ¼ ff 3 ; f 4 ; f 5 ; f 6 ; f 7 ; f 8 g and Fs ¼ ff 1 ; f 2 ; f 3 ; f 8 ; f 9 ; f 10 g ð6:4Þ
The dynamics of sequential changes between modes is described by probabilities

Pij that connect different phases of flight and thus provide a basis for estimating the
reliability and success of a flight. The probability Pij represents the fact that the ith
mode of system A ( fi) transfers to the mode j and
!
X
m

pij ¼ 1; i; j ¼ 1; m ð6:5Þ
i¼1
It is clear that the graph of possible dependencies between phases of flight is

much more complex than presented in the Fig. 6.4 sequence of flight changes. In the
previous chapter, a detailed analysis of the possible changes of flight phases from a
probabilistic point of view was presented, together with a reliability analysis of a
flight using flight modes.
A change to a new flight phase implicitly defines a set of possible sequences,
dependencies and recovery procedures. These are captured in the dependency
matrix and recovery matrix, which are covered later. Consequently, determining
the flight phase is an important issue. A procedure for flight phase determination is
proposed below, based on analysis of incoming flight data in real time.
Take-Off
The take-off flight phase is defined as the period between the time when the ground
speed has increased to a value above maximum taxi speed and the time when a
certain altitude above the departure runway elevation is reached. The values used to
determine the maximum taxi speed VMaxTaxi and altitude HMinTake-off thresholds can
be configuration parameters because they depend on the aircraft type. Typical
values are 25 knots for VMaxTaxi and 1000 feet for HMinTake-off.
Cruise
The cruise phase is between the end of the take-off phase and the beginning of the
landing phase.
Landing
The landing phase is the period between the time when the aircraft has slowed down
to a level below a certain threshold landing speed (while having a negative rate of
climb in excess of a certain threshold rate) and the time when the ground speed has
decreased below maximum taxi speed. The landing speed VMaxLanding and vertical
rate HMaxLanding thresholds need to be configurable parameters because they depend
on aircraft type.
Note that often, several detailed phases have been combined to create these
simplified PASC take-off, cruise and landing phases.
The following algorithm describes the determination of flight phases using
current flight data:
– Flight mode ¼ before take-off (for the PASC only)
– Measure and record the barometric pressure datum at local zero altitude
– Wait until the ground speed increases above the maximum taxi speed, VMaxTaxi
– When current speed > VMaxTaxi, then flight mode ¼ take-off
– Measure and record the barometric pressure datum at this zero altitude
– When height is HMinTake-off relative to the datum then flight mode ¼ cruise
– When the vertical descent rate is negative and exceeds the vertical rate threshold
HMaxLanding and the air speed is below the landing speed threshold VMaxLanding
then flight mode ¼ landing (The vertical rate value must be determined from an
interpolation of the barometric altitude values over a certain time span, typically
a few seconds, to avoid unintended triggering due to measurement spikes.)
– When the ground speed falls below the taxi speed threshold, the flight
mode ¼ end of flight (as far as the PASC is concerned)
Note that this linear sequence is a simplification, for example, an aircraft might
touch down and need to immediately take-off again, perhaps due to wind conditions
or to the runway being blocked. More details on algorithms and the methods of
flight mode detection and monitoring are provided in Chap. 8.
Models of Elements
The operability of an aircraft depends on the condition of its constituent elements.

Each element Ei | Ei 2 O and i ¼ 1,. . .k - 1, where k is defined by a state, or states. In
the MASCA, each element is considered to be a source of possible faults that could
affect the object (aircraft). Consequently, at any one time, an element is considered
to be faulty, or correct. One, or more, sequential flight data records (frames)
represent each condition of each element.
Our objective is to determine whether the elements have become faulty. This can
be achieved in a number of ways. Each element is analysed in terms of safety of
flight using relevant flight data. The result of this analysis is a Boolean result, true or
false, of the predicate “is the element functioning normally in the current
Possible Flight Data Evaluators

(Models Of Elements)
Functional
Threshold Statistical Functional RT AI
Models with
Functions Models Models Models
inheritance
Fig. 6.10 Possible element-modelling techniques
Table 6.1 Characteristics of element-modelling techniques

Type of the model Features and issues Tools and hardware
Real-time artificial Decision trees Tools are under construction
intelligent model Fuzzy logic Trial implementation on
Evolutionary and genetic programming neural network of processors
but
timing indeterminate and coverage
Unstable
Computational Possible hypotheses of flight data con- Neural network
learning models vergence in probability with min risk Recurrent neural network
System of ODE
Statistical models Categorisation of data Fixed-point arithmetic
Volume of simple calculations Large RAM memory
Functional models Based on ODE or PDE Floating-point arithmetic
Euler method for ODE
Threshold func- Discrete analysis Simple CPU, easy to
tions for elements N-dimensional matrix implement
circumstances.” Thus, we say that the fault status of the ith element of O is
described by the predicate function Pi.
There are many alternative ways to model an object and its elements in order to
make it possible to determine the fault status of the elements. In the MASCA, flight
data is considered to reflect the behaviour of elements of the object. These individ-
ual models will be referred to as evaluators. They could be, for instance, threshold
functions, functional models, functional models with history or expert systems. The
complexity and reliability of models (and their prognostic features) are shown in
Fig. 6.10:
Features of existing models for element evaluators are summarised in Table 6.1.
Prediction effectiveness of an aircraft’s behaviour by MASCA depends on the
precision of the element models, as well as the volume and quality of snapshots
of real flight data. The element models define their behaviour and are used to make
prognoses of possible consequences. In turn, accumulated and real-time data are
used to determine whether there are statistical dependencies in the flight data; in this
way, element dependencies can be corrected.
Table 6.1 briefly describes such models in order of complexity from top to
bottom.
Artificial Intelligence Models
At first glance, the Artificial Intelligence Models look as though they provide an
ideal fit for the implementation of PASC and so form the core of MASCA: “. . .the
objective of developing prediction and classification rules for various problem
domains pursued by statistical and machine learning”. . . [1].
Unfortunately, a closer examination quickly reduces any initial optimism,
because:
• AI decision trees are based on IF, THEN,. . ., ELSE-type rules that assume the
inter-dependency relations are known and stable.
• Recursive programming separating data into different groups is complex even
using Boolean logic separators.
• Patterns for partitioning as well as for the formation a training set—choosing
patterns for further steps of prognosis is “overcooked” and the value of predic-
tion using recursive formation of patterns is uncertain.
• Generic programming relies on the random introduction of the fittest pattern and
is stochastic by nature; different runs may produce different results.
• Time and hardware costs of AI schemes are significant: best results so far have
been achieved using a neural network of parallel processors.
• There is no industrially approved approach to using AI schemes, and verification
is extremely difficult.
All of these points exclude the possibility of using AI models for the MASCA in
GA and other segments of aviation. The authors are aware that this view does not fit
in with the current general enthusiasm for AI based solutions, however in safety
critical systems the issues of clarity and verifiability are paramount.
Statistical Learning Model

The concept of recognising trends within data samples (in our case flight data) using a
generalisation of the data sample sequence as several possible distributions looks
impressive. If it is possible to discover a distribution for data samples with any required
precision using a fast converging procedure, then this helps to determine the actual
trend for each element. Chervonenkis and Vapnik introduced the idea in 1971 [2].
In a later development by Haussler [1], it was shown that if the number r of
hypotheses is finite (which is certainly true for the behaviour of the elements
on-board), then the probability that any hypothesis with an error larger than ε is
consistent with the target concept on a sample of size m is less than (1 ε)mr.
Thus, with the growth in the volume of flight data and a fixed number of
hypotheses, it should be possible to identify the actual trend for each element and
therefore make a judgement as to its fault status and hence reliability.
Unfortunately, to develop an acceptable hypothesis, sets of training and testing data
need to be composed. Speeding up the converging process here requires a recurrent
neural network of dynamic elements that is described by means of systems of ordinary
differential equations (ODE). Therefore, at the moment, this most suitable theoretical
concept is not applicable in practice for the implementation of MASCA.
Statistical Models
Statistical models seem to be suitable for the PASC and might well be part of the
MASCA as they are oriented towards the categorisation of data using distributions.
The flight data accumulated regarding each element of the aircraft are called
observations. Such an observation is classified as belonging to one of a finite
number of possible categories. It is assumed that there are a finite number of
possible categories for this data.
Models of this type are used to discover probabilities within categories. Fig-
ure 6.10 has already described how to use categories of data for the PASC. In this
case, there are three subsets of states that might be defined normal, warning and
dangerous: Ω+, Φ and Ψ, respectively. The credible estimation of flight data and its
categorisation depends directly on the volume of flight data received and processed.
Interestingly, and again, regretfully, to implement this kind of model, a vast
number of simple calculations are required, such as sums and differences, both
exponential and combinatorial. Even if not processed during the real time of the
flight, these statistical category-defining models should be processed immediately
after flight in order to detect and determine any slow-developing trends with respect
to elements in MASCA.
Functional Models
For the purpose of this chapter we consider the following definition of a functional
model:
A functional model explicitly represents the functions of an element of the object.
Their place within the MASCA has been illustrated in Fig. 6.11 and Table 6.1.
The kind of functional models considered here are based on a description of the
elements using ordinary differential equations (ODE). The analysis and application
Fig. 6.11 Graph of

1 2
dependencies between the
MASCA elements 7
4
5
3
8
9 10
11
of the functional model to element behaviour analysis can then be broken down into
the classic steps as described in [3]:
– Model the phenomena as a set of ODE
– Solve the set of ODE
– Impose the given data
– Interpret result
The advantage of using functional models based on analytical equations ODE
[or partial differential equations (PDE)] is the possibility to achieve any required
precision of element behaviour modelling, continuously. The disadvantage of a
functional model described as ODE is the requirement for a numerical solution. In
practice, even the simplest numerical solution of ODE, where derivatives are
replaced by difference quotients as originally proposed by Euler, is not easy to
apply.
Functional models defined by ODE or PDE may be designed as open- or closed-
loop systems. The problem of a functional model based on the open-loop approach
is instability and the need for periodic recalibration.
Functional models with inheritance are also called closed-loop systems. In
contrast with open-loop models, closed-loop models do not require calibration of
input and output to obtain the required accuracy. Closed-loop models are usually
considered as self-calibrating, assuming, of course, that they are stable and
convergent.
The modelling of over hundred parameters or flight data in the real time of a
flight might be prohibitively slow, require high performance hardware and thus
consume a great deal of power. Besides, ODE is likely to require a floating-point
arithmetic processor in order to process the data in real time. All these arguments
cast doubt on the suitability of using functional models for the PASC.
In spite of the disadvantages, where simple functional models would be ade-
quate, they may still be well suited to modelling some elements.
Threshold Functions
It is believed that it is possible to use threshold-based models for analysis and
possible prognostic and recovery functions without sacrificing accuracy in the
MASCA. The simplest model to analyse the state of an element using recorded
flight data is called the threshold function.
Suppose that the flight parameters form a set (d1(t), d2(t), . . ., dx(t)). Suppose that
flight parameter values drift during aircraft operation. In effect, a random vector
process describes the time behaviour of the parameter:
DðtÞ ¼ ðd 1 ðtÞ; . . . ; dx ðtÞÞ, t 0 ð6:6Þ

with an initial state:
~ ð 0Þ ¼ ð d 1 ; . . . ; d x Þ
D ð6:7Þ
We suppose that the use of statistics is sufficient to estimate the type of

processes, {D(t)} and the dependencies between them. System operation is consid-
ered to be successful during the flight if both parameters and their different
combinations do not leave given domains within Euclidian spaces of appropriate
dimensions. In other words, it is defined by a set:
M ¼ fðr; di1 ; . . . ; d i1 Þg ð6:8Þ
of the cut set with r indicating the dimension of the cut set. With any cut set s
¼ ðr; di1 ; . . . ; dii Þ one associates a domain Ds Rr.
Thus, if T denotes the flight time of the aircraft, then the system’s failure-free
operation means that for any s ¼ ðr; di1 ; . . . ; di1 Þ 2 M and any t 2 [0,T] the relation
((d1(t), . . . , dx(t)) 2 D) holds, with initial stated 1 ð0Þ ¼ di1 , . . . , d ir .
If for at least one element of s 2 M, the corresponding relation is violated, then a
failure has occurred.
The main aim of the generalised threshold theory is to develop a procedure to
evaluate the risk of failure. The model needs to be connected with a control process.
Note that even this simple threshold model makes it possible to analyse the
probability of approaching the process (in our terms the elementary object or
element) behind the critical events. A generalisation of this model is proposed in
the following discussion.
Element Models
Models of aircraft form a set M ¼ {m1, m2,. . ., mk} and taking into account their
elements we obtain
M ¼ fm1 ðe1 Þ; m2 ðe2 Þ; . . . :; mk ðek Þg ð6:9Þ
Assuming that each element in the object is described by some kind of functional
model, then:
Mð0Þ ¼ fm1 ðe1 ðd1 ÞÞ; m2 ðe2 ðd2 ÞÞ; . . . :; mk ðek ðdk ÞÞg ð6:10Þ
Introducing time into each model gives:
Mð0ðtÞÞ ¼ fm1 ðe1 ðd1 ðtÞÞÞ; m2 ðe2 ðd 2 ðtÞÞÞ; . . . :; mk ðek ðd k ðtÞÞÞg ð6:11Þ
To provide an analysis of the current situation on-board during operation, it is

necessary to obtain real snapshots of flight data. With this data, it will be possible to
discover statistical mutual dependencies and hence the role of each elementary
object. With this knowledge, there is the opportunity to avoid the consequences
and/or mitigate the effects of a potentially dangerous flow of events. It also becomes
possible to analyse and evaluate the coverage of possible faults.
Predicates, Dependency and Recovery Matrix

The MASCA performs two functions:
• During flight: It must produce a high-quality prognosis of aircraft faults using
existing models of elements and a defined matrix of dependencies.
• After flight: It must be capable of adapting (tuning) the model of element
dependencies using updated statistical analysis of accumulated flight data.
The rationale for the MASCA being static during flight and dynamic after flight
is that:
• There will never be a serious operation (such as the replacement of engine) for
an aircraft during flight. The only scenario is that, say, one of the engines stops
which the overall modelling must cope with (the object has many elements, not
all vitally necessary for safe operation).
• Dynamically updating the MASCA will make the prognosis and diagnosis much
more difficult. It would also be extremely difficult to verify the model from a
safety viewpoint.
A vector of predicates {P} describing the condition for each element of an object
has the form:
P ¼ fp1 ðm1 ðe1 ðd 1 ðtÞÞÞÞ; p2 ðm2 ðe2 ðd2 ðtÞÞÞÞ; . . . :; pk ðmk ðek ðd k ðtÞÞÞÞg ð6:12Þ
Thus, the MASCA describes an aircraft as a quintuple: object, flight modes,

flight data, models and predicates:
< O, FM, FD, M, P > ð6:13Þ
A vector of predicates P is defined for each elementary frame recorded about

object states, as well as defined for each element: ei 2 O.
PASC requires an analysis of possible faults and their consequences for each
element ei in O. For this purpose, the MASCA includes a dependency matrix.
Dependency Matrix
The dependency matrix R describes possible dependencies (relations) between
elements of O, in terms of fault influence and propagation. The simplest version
of R is a square matrix that has k columns and rows, and that describes possible
dependencies of k elements in the object {O}. There are several alternatives for
implementing the matrix in the MASCA using various mathematical techniques
such as the Boolean matrix, undirected graph, directed graph and probabilistic
graph.
1 2 3 4 5 6 7 8 9 10 11
1 1 1 1
2 1 1 1 1
3 1 1
4 1 1
5 1 1 1
6 1 1 1 1
7 1 1
8 1 1
9 1 1
10 1 1
11 1 1
Fig. 6.12 Example of matrix R for 11 elements in O
• One recent development is called the graph logic model (GLM) and is presented
in the documents of the on-board active safety system (ONBASS) project and
published in details in a number of books [4, 5] and papers [6, 7, 9, 10]. To
explain the logic of searching for the “guilty node” we will use the simplest
version of the graph model (GLM would need its own its own book to explore
the property it introduces in depth).
An example of the dependency relation between elements is illustrated in
Fig. 6.11, and its corresponding Boolean dependency matrix is described in
Fig. 6.12.
In the case of a graph, each matrix element rij is defined according to the rule:
rij ¼ 1 when an object element ei functionally relates to another elementary object
ej. Their interactions in terms of induction of faults are also possible.
Defining the initial values for the cells in the dependency matrix R depends on
the characteristic of the aircraft and the way in which it has been designed,
manufactured and configured. Special expertise is required from aviation special-
ists, manufacturers and maintenance engineers for the chosen type of aircraft to
support the PASC systems engineers. A 1 indicates a dependency between the
elements indexed.
Note that the direction of the links in the matrix R are not presented. This
generalisation allows a path of possible dependencies to be traced through the
matrix from any object y when the predicate on this object is false:

py my ey d y ¼ FALSE ð6:14Þ
In fact, the matrix R is a form of the graph of possible connections between

elements of the set O written in terms of fault consequences. The deliberate
omission of a directed link on the graph R allows for the creation (generation) of
possible subgraphs starting from any yth node, and thus analyses possible conse-
quences of fault in the element y.
The generation can be done in the real time of the flight, as long as it takes a
limited amount of time to know length and makes it possible to react to an event or
event sequence before the situation on-board develops into the level of an accident.
In contrast to known models of analysis of fault propagation inside the object such
as fault tree analysis [13], test and quality control before flights, etc., the MASCA is
the targeted reaction made on the basis of the flight data during flight.
Furthermore, there is the possibility to update the matrix R between flights,
based on the history of flights to date and information from other sources (e.g., the
aircraft manufacturers, accident investigations). This is in contrast to techniques
such as FTA and FMCEA, which are static and only performed when the object and
its elements are originally designed.
The dependency matrix describes the logical connections between elements of
objects. It needs to be updated as the dependencies between elements change (e.g.,
faulty elements are replaced by new elements and wearing elements suffer from the
ageing processes). Also, the original matrix may not have been quite correct
because of the limitations in expert knowledge and because of more accurate
dependencies between elements have been derived from the accumulated
flight data.
In order to clarify the role of statistical data processing, we take an example from
the human body: the heart and body before and after heart transplantation.
The connection between the heart, blood pressure and the immune system is not
straightforward. Before the heart transplant operation, the blood pressure in abnor-
mal, but the immune system is normal. After the transplant, there is a changed
relation between the heart and body indicated by a more normal and stable blood
pressure and a much greater number of immune cells in the blood. The operational
“normal” after the transplant is different to the “normal” before the transplant. Any
further diagnosis or prognosis needs to take into account that there has been a heart
transplant and that ambient conditions have changed.
Regular automatic statistical analysis can be used to tune a model of element
dependencies by updating it with newly discovered dependencies and possibly
excluding existing ones that are obsolete. For an aircraft, this means that statistical
analysis processing after each flight can provide automatic self-tuning of the
MASCA to take into account the changes in the condition of its elements. The
tuning of the MASCA is performed only post-flight.
1 2 3 4 5 6 7 8 9 10 11
1 P11 P12 P16 P19
2 P21 P23 P25 P27
3 P32 P3, 11
4 P45 P48
5 P52 P54 P5,10
6 P61 P67 P68 P69
7 P72 P76
8 P84 P86
9 P91 P96
10 P10, 5 P10, 11
11 P11, 3 P11, 10
Fig. 6.13 Probabilistic mutual dependencies between nodes
Probabilistic Matrix
Another possible option for describing the dependence between elements in terms
of safety is a probabilistic matrix; let us call it Rp. In this case, the MASCA
introduces the probabilities of possible transitions between the ith and jth elements
from R; see Figs. 6.11 and 6.12. Then:
MP ¼ jPkk j
where k is the number of elements in the Rp.

The MASCA considers the probabilistic dependence of two elements (the ith
and jth elements) in terms of fault dependence, that is, a fault of one element
probably causes (induces) a fault in another.
A generalisation of matrix Rp assumes that there are possible inequalities of
conditional probabilistic dependencies in both directions, to and from elements. In
other words, for the ith and jth elements, two probabilities Pji and Pij are defined,
and if Pji is a probability that element j induces fault in element i, then generally
Pij 6¼ Pji.
Inequalities of probabilities of possible dependence between nodes do not obey
the Markovian property; thus, the sum of outgoing event probabilities for each node
is not equal 1.
The probability matrix for the graph in Fig. 6.12 presented in Fig. 6.13 makes it
possible to define diagnostic features of the MASCA for each particular implemen-
tation. It generalises the well-known fault tree scheme and introduces a flexible
ordering on R. The ordering can be based on temporal, informational or structural
redundancy [7]. Applying a weighting in the graph R can also complement

ordering.
Evaluating a set of processes defined on matrix RP provides a powerful tool to
analyse the possible consequences of faults that appear in the aircraft. Two pro-
cesses are defined on the matrix presented above:
– Searching for possible consequences of a fault
– Determination of “who is guilty”—the locus or loci of faults
The first process is about making a prognosis about a possible flow of events. It is
initiated by information derived from flight data analysis regarding existing sys-
tematic discrepancies. The processes are developed as an algorithm of diagnosis
and prognosis. The second process implements the evaluation of a possible reason,
or reasons, for the manifestation of the discrepancy.
The Recovery Matrix

The recovery matrix (RM) determines the reactions to the detected, or at least
suspected, faults and is defined as n by n and has the same format as matrix R. Each
cell of the RM contains two variables: the addresses of the program components
that are activated when the MASCA analyses the probability of possible success of
recovery and produces a decision to attempt recovery. The MASCA assumes that
there is a possibility for non-absolute recovery. A successful recovery procedure is
a recovery with probability Prji where:
Prji 1 Prji ð6:15Þ
The success of the MASCA can then be defined via the analysis of both matrix
Rp and RM: the events detected and recovered are the justification for the existence
of these matrices. Also, the knowledge about the aircraft, the values initially
provided for the matrix and the algorithm applied indirectly define the coverage
of the faults.
Reverse Tracing
Another unique possibility of the MASCA is the option of reverse tracing. This
means that element ei of the object can be the starting point to analyse possible fault
dependencies with the element ei-1.
Matrix Data for the PASC Trial
Dependency Matrix
As discussed previously, given that the test aircraft in the PASC will most likely
have a single engine, we can eliminate the “right engine fuel flow” parameter from
the list of available parameters. This leaves us with 23 parameters available during
the PASC flight trials. These parameters can be monitored, as discussed earlier, for
exceeding predefined thresholds, specific patterns/trends with respect to the “evo-
lution” of the data over a period of time, the probabilities of interdependence, etc.
Based on aeronautical theory and the experience and expertise of the Consortium
partners, extensive efforts have been made to define the dependence of each
parameter in turn with respect to the rest. The result is the “dependency matrix”
for the PASC trial aircraft as illustrated in Fig. 6.12.
In the matrix of Table 6.2, a value of “1” signifies that the parameter in the
relative row depends on the parameter of respective column in a “direct” sense. A
value of “0” correspondingly signifies that there is no direct dependence of the
parameter in that row on the parameter in the respective column.
As explained previously, the link between parameters can be either unidirec-
tional or bidirectional. For example, in the above matrix, the ground speed of an
aircraft is the vector sum of the aircraft’s true air speed (TAS) and the wind speed.
Thus, the ground speed (GS) depends on the TAS, the wind speed and the wind
direction. In contrast, the wind speed and wind direction do not depend on the TAS
or GS of the aircraft, as can be easily appreciated.
There are data and/or parameters that are not directly available in real time in the
aircraft that will need to be preconfigured in the PASC software so as to support the
determination of the specific dependency between parameters.
For example, using the “reverse tracing” method outlined above, on the one hand
it is demonstrated that all speeds defined in relation to the aircraft are interrelated as
illustrated in Fig. 6.12, but on the other hand, these speeds also depend on a series of
parameters that are not available in real time to the PASC system and hence need to
be preconfigured and loaded along with the software core of PASC.
In Fig. 6.14, red-coloured text has been used to distinguish between the param-
eters available and those not available to PASC in real time. Another point to note
here is that some of the parameters that are unavailable in real time are aircraft
independent (e.g., the air speed compressibility charts), whereas others are very
much dependant on the aircraft in question (e.g., the air speed calibration charts).
The dependency matrix, as discussed, reflects a preliminary effort to define
parameter dependencies based on aeronautical theory and the experience and
expertise of the PASC authors. For each particular type of aircraft or vehicle, the
dependency between parameters should be defined either by mathematical models
(theory), probabilistic methods and/or the definition of specific trends/patterns.
The Algorithm for PASC: APASC

Existing elements in the MASCA define behaviour of the aircraft. In turn, accu-
mulated and real-time flight data are used to find out whether statistical dependence
between elements does exist.
An example from heart monitoring clarifies the role of the statistical data
processing in complex systems. After a heart transplant, dependency of blood
pressure and myocardium is changed, though the problem of immunity due to
possible rejection of the new heart becomes a new and crucially important issue.
Table 6.2 Dependency matrix of the PASC trial aircraft

Is dependent Left (single)
on: GPS Pressure Indicated Outside air Ground Drift Wind Wind Latitude/ engine fuel
Depends on: time altitude air speed Heading temperature speed angle speed direction longitude flow
GPS time – 0 0 0 0 0 0 0 0 0 0
Pressure 0 – 0 0 0 0 0 0 0 0 0
altitude
Indicated air 0 1 – 0 1 1 0 0 0 0 0
speed
Heading 0 0 0 – 0 0 0 0 0 0 0
Outside air 0 1 0 0 – 0 0 0 0 0 0
temperature
Ground speed 0 0 0 0 0 – 0 1 1 0 0
Drift angle 0 0 0 1 0 0 – 1 1 0 0
Wind speed 0 0 0 0 0 0 0 – 0 0 0
Wind direction 0 0 0 1 0 0 1 0 – 0 0
Latitude/ 0 0 1 1 0 1 1 1 1 – 0
longitude
Left (or single) 0 0 1 0 0 1 0 1 1 0 –
engine fuel
flow
Barometric 0 1 0 0 1 0 0 0 0 0 0
pressure
setting
True air speed 0 1 1 0 1 1 0 1 1 0 0
Mach speed 0 1 1 0 1 1 0 1 1 0 0
Density 0 1 0 0 1 0 0 0 0 0 0
altitude
True air 0 1 0 0 1 0 0 0 0 0 0
temperature
Rate of turn 0 0 1 1 0 1 1 1 1 0 0
Vertical speed 0 0 1 1 0 1 1 1 1 0 0
Fuel remaining 0 0 0 0 0 0 0 0 0 0 1
Track 0 0 0 1 0 0 1 0 0 0 0
Distance to 0 0 1 1 0 1 1 1 1 1 0
next waypoint
Magnetic 0 0 1 0 0 0 0 0 0 1 0
variation
Baro-corrected 0 1 0 0 1 0 0 0 0 0 0
altitude
Barometric True Rate Distance to Baro-

pressure air Mach Density True air of Vertical Fuel next Magnetic corrected
setting speed speed altitude temperature turn speed remaining Track waypoint variation altitude
0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0 0 0 0
1 1 1 0 1 0 0 0 0 0 0 0
0 0 0 0 0 1 0 0 1 0 0 0
1 0 0 1 1 0 0 0 0 0 0 1
0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 1 1 0 0 1 1 0 1 1 1 0
0 1 1 0 0 0 1 0 0 0 0 0
– 0 0 1 0 0 0 0 0 0 0 1
1 – 1 1 1 0 0 0 0 0 0 1
1 1 – 1 1 0 0 0 0 0 0 1
1 0 0 – 1 0 0 0 0 0 0 1
1 0 0 1 – 0 0 0 0 0 0 1
0 1 1 0 0 – 1 0 0 0 0 0
0 1 1 0 0 1 – 0 0 0 0 0
0 0 0 0 0 0 0 – 0 0 0 0
0 0 0 0 0 0 0 0 – 0 0 0
0 1 1 0 0 1 1 0 0 – 0 0
0 0 0 0 0 0 0 0 1 0 – 0
1 0 0 1 1 0 0 0 0 0 0 –
Indicated Air Speed (IAS) Equivalent Air Speed (EAS)

–altitude independent
Air speed compressibilty charts
Air speed calibration charts (charts are a/c independent)
(charts are a/c specific)
Density altitude
International Standard Atmosphere (ISA)
Calibrated Air Speed (CAS) Local air density or
Local air temperature or
Local air pressure
True Air Speed (TAS)

Wind speed
Wind direction
Ground Speed (GS) Local speed of sound
Mach speed
Fig. 6.14 PASC aircraft speed dependencies
So a patient with a “new” heart needs to have different treatment due to new
conditions of their organs (elements in MASCA) as their dependencies have
changed.
Regular automatic statistical analysis here can help to “tune” dependencies
between elements in the MASCA to update them and exclude obsolete ones. In
our example, graphs Figs. 6.12 and 6.13 will be updated. This makes it possible to
account for each change of conditions of elements for a particular aircraft.
Main APASC Functions

Thus, the APASC performs two functions during its principally different phases:
on-ground before flight and on-board during flight. They are:
• Before and after flight: adaptation of the model of element dependencies using
updated statistical analysis of accumulated flight data. Note that safety experts
for this particular aircraft prepare initial values in the MASCA. All subsequent
“tuning” is processed after the flight using accumulated flight data and existing
matrixes by the APASC.
• During flight: high-quality prognosis of aircraft conditions using the MASCA
and defined by the matrix of dependencies.
The schematic structure of the APASC is presented in Fig. 6.15.
How the APASC Works

The procedure of searching for possible sequences of faults in the elements is
shown in Fig. 6.16, and identifies all consequences from the suspected node.
Initial preparation of MASCA, all matrixes are Before first

prepared using expert knowledge Flight
Analysis of aircraft element’s conditions

Prognosis of element states
Searching using dependency matrixes possible
consequences of faulty element During Flight
Searching of possible reason of faulty element
(“reverse tracing”)
Selection of recovery procedures if any
Processing of flight data to determine modify

(and correct) dependencies between elements
using statistical analysis of flight data. After every
Modification of matrixes Flight
Report on modification of all matrixes is
prepared using expert knowledge
Fig. 6.15 The APASC on-board and on-ground phases
Along each trace during each search an iteration of multiplication of sequential

dependencies between nodes is produced. Note here that the probabilistic matrix in
Fig. 6.12 is not Markovian; thus, the sum of probabilities on the links at each node is
not equal to 1; in contrast, several probabilities or “consequences” might be very
highly possible.
What must be done? The objective is to find a node that causes the deviation of
the parameters of flight. This determination should be done effectively, using two
principles, ASAP (as soon as possible) and ALAP (as local as possible). Cumulative
multiplication of “probabilities” along the paths of the graph makes this search
rather effective.
Two processes are here required to execute:
• Firstly, it is required to determine the potential consequences of the situation that
has appeared.
• Secondly, we need to find the node that causes the problem.
Starting from a suspected node, the APASC evaluates the possible paths and
ranks and records potential risk (e.g., damage). Tracing for each path continues
until multiplication of probabilities along the trace is less than ε, where the value of
ε is defined empirically, using engineering expertise, and is considered as a constant
Fig. 6.16 Tracing of possible consequences
for a particular aircraft. The elements along the processed path are added to the set
of potentially dangerous sequences.
Termination Conditions for APASC On-Board

The APASC on-board algorithm has two termination conditions. The first one is
defined by the number of elements of the model (matrix n by n, where n is the
number of elements). Even for a model that is described by a fully connected graph,
APASC on-board terminates when all the nodes have been visited.
The second termination condition is the “likeliness” of the analysed sequence;
thus, the above-mentioned tracing of the sequence is terminated if the cumulative
probability along the path traced is less than ε.
Probability Along the Path

The probability of consequences along the paths from the suspected node i to node
j is defined as Π( pi, j). As long as several paths might lead from node di to node dj,
all possible Π( pi, j) are ranked and nodes along the paths are included into the set of
suspected nodes. The algorithm called Tracing is shown in Fig. 6.16 and covers
both termination scenarios.
Initially, each node in the graph is considered to be safe and Ds is initialised to
“empty” (line 5). For the suspected node the probability is initialised to ε (line 2);
all nodes of the graph are put into a priority queue Q. Queue updates by a special
function “delete from the queue” and the node-reaching probability in the queue is
updated with the function “increase” by the adjacent nodes. Initially the first tracing
node s is the active node (line 8).
Inside the tracing loop for each node, probabilities for all possible paths are
calculated. The highest probability for the traces defines the next step of the
algorithm; the node along the highest probable trace is identified as active and
thus it is deleted from the queue. The probabilities of all the adjacent nodes (i.e.,
minor to major) with an active node are calculated (line 12).
To avoid looping during tracing analysis, the adjacent nodes that have been
visited are excluded from further tracing (line 12). When a loop is detected, a
production Π( pi,j) is calculated by excluding the last probability. All the remaining
nodes will be traced; probabilities along their paths (from staring node) are updated
(lines 14 and 15). As has already been mentioned, tracing terminates when the
probabilities Π( pi, j) of reaching the remaining nodes are less than ε.
An example on how the tracing algorithm works is illustrated in Fig. 6.17 Let’s
assume that node d1 manifests the fault; the estimation of potential damage of this
event starts using the dependency matrix from the active node d1 for all traces that
potentially might be dangerous.
Let D(n) be the dependency matrix with a number of n elements. The depen-
dency between any pair of nodes (di,dj) in D(n) is denoted as D(n)i,j. In D(n)i,j all
other elements are zero except those that belong to the possible traces from di,dj.
Initially, the first active node is d1. The adjacent nodes from d1 are d2 and d3; the
reaching of probabilities of d2 and d3 are calculated from d1. Because p1,3 > p1,2,
the node d3 is considered to be the next active node. The adjacent nodes (d6 and d4)
of d3 are traced, and their reaching of probabilities are updated by the node d3.
0.02
2 5
0.6
0.3 0.7
1 0.5
4 0.01
0.6
0.4
0.5
3 6
0.8
p1,1 , p1,2, p1,3, p1,4, p1,5, p1,6 0.00, 0.30, 0.50, 0.00, 0.00, 0.00
p2,1 , p2,2, p2,3, p2,4, p2,5, p2,6 0.60, 0.00, 0.50, 0.00, 0.02, 0.00
D(6)= p3,1 , p3,2, p3,3, p3,4, p3,5, p3,6 0.00, 0.70, 0.00, 0.60, 0.00, 0.80
=
p4,1 , p4,2, p4,3, p4,4, p4,5, p4,6 0.00, 0.00, 0.40, 0.00, 0.00, 0.00
p5,1 , p5,2, p5,3, p5,4, p5,5, p5,6 0.00, 0.00, 0.00, 0.00, 0.00, 0.00
p6,1 , p6,2, p6,3, p6,4, p6,5, p6,6 0.00, 0.00, 0.00, 0.00, 0.01, 0.00
Fig. 6.17 An example of tracing
Tracing continues until Π( p1,x) < ε; x 2{all nodes}. When tracing nodes from d2
(the active node), although node d1 is also reachable from d2, it will not be
considered for further tracing because d1 has already been visited before, and it
will not be traced to avoid endless tracing when a loop between nodes exists. The
node d5 might be visited through two traces (d1-d2-d5) and (d1-d3-d6-d5). Π( p1,5)
will choose the maximum value of (D1,2 * D2,5) and (D1,3 * D3,6* D6,5) for
evaluation. The details of the PASC ONBOARD tracing algorithm are illustrated
in Fig. 6.19 for each step of tracing.
The entries of the table in Fig. 6.18 are:
– Column steps denote the steps of the algorithm.
– Column tracing progress presents snapshots of tracing for each step.
– Column priority queue contains current weights of nodes updated by the already
traced node from the starting node.
– Column traced nodes defines which node is processed at this stage of the
algorithm and the “probabilistic weight” for every already processed node.
Entries in the priority queue are tuples (the node number, its father node, the
cumulative probability from the starting node). The grey line is the next active
node. Thus, the first grey line in the priority queue [the first element in a queue “1
(, 1)”] means that the algorithm starts from the node d1; “–” means that there is no
previous node; and the second “1” indicates the probability of activation of the flow
of event. Whenever the tracing algorithm is invoked (by a signal) the initial
probability for the starting node is always set to 1.
0.02 1(-,1) 1(-,1)

2 5
0.6 2(-,ε)
1th 3(-,ε)
0.3 0.7
1 4 0.01 4(-,ε)
0.5
0.6
0.4
5(-,ε)
0.5 6(-,ε)
3 6
0.8
0.02 3(1,0.5) 3(1,0.5)

2 5
0.6 2(1,0.3) 1(-,1)
2nd 0.3 0.7 4(-,ε)
1 0.5
4 0.01
5(-,ε)
0.6
0.5
0.4 6(-,ε)
3 0.8
6
0.02 6(3,0.4) 6(3,0.4)

2 5
0.6 2(1,0.3) 3(1,0.5)
3rd 0.3 0.7 4(3,0.3) 1(-,1)
1 0.5
4 0.01
5(-,ε)
0.6
0.4
0.5
3 6
0.8
0.02 2(1,0.3) 2(1,0.3)

2 5
0.6 4(3,0.3) 6(3,0.4)
4th 0.3 5(6,0.004) 3(1,0.5)
0.7
1 4 0.01
0.5 1(-,1)
0.6
0.4
0.5
3 0.8
6
0.02 4(3,0.3) 4(3,0.3)

2 5
0.6 5(2,0.006) 2(1,0.3)
5th 0.3 0.7 6(3,0.4)
1 4 0.01 3(1,0.5)
0.5
0.6 1(-,1)
0.4
0.5
3 6
0.8
0.02 5(2,0.006) 4(3,0.3)

2 5
0.6 2(1,0.3)
6th 0.3 0.7 6(3,0.4)
1 0.5
4 0.01 3(1,0.5)
0.6 1(-,1)
0.4
0.5
3 0.8
6
Fig. 6.18 An example of the PASC ONBOARD algorithm

The rest of the entries in the priority queue are initialised to ε. The next step of
the algorithm is the tracing of direct neighbours and the calculation of their
probabilistic weights. Thus, the second entry of the priority queue (2, 0.3) in the
second step means that probabilistic weight of node d2 from node d1 is 0.3. Further
rows, say the fifth step, 5 (2, 0.006) in the priority queue contains the probabilistic
distance from d1 to the node d5 which is the cumulative multiplication of probabi-
listic distance from node d1 to the node d2 and the dependency between the node d2
and the node d5 (0.3 *0.02 ¼ 0.006).
Every traced node column contains the current active node in bold font and its
probabilistic weight. It also contains a number of already processed nodes and their
weights, respectively. For example, the last entry in the table (the sixth step)
contains all processed traces and their ranked probabilistic weights. The bold
entry for traced nodes such as 3 (1, 0.5) for the second row is used to update
weights of all nodes in their respective order of entry in the priority queue, provided
these nodes are adjacent to the active node.
Consider the node d1 is a suspected node as an unusual event has been detected
on it. Initially, p1,x ¼ ε; x 2{all nodes}, then p1,1 ¼ 1 as an unusual event is already
detected on it. The first element in the priority queue will be the next active node
(the first step). All the adjacent nodes from the active node will be updated if
necessary. The adjacent nodes from d1 are d2 and d3. The highest reaching proba-
bilities from d1 to d2 and d3 are updated [Π( p1,2) ¼ 0.3, [Π( p1,3) ¼ 0.5] and the
priority queue is re-sorted (the second step).
If the cumulative path probability of the first node in the priority queue is greater
than ε, the searching continues. The node d3 is taken from the priority queue (the
second step) and Π( p1,3) > ε. It is used to update its adjacent nodes d4 and d6
(Π( p1,4) ¼ 0.3; Π( p1,6) ¼ 0.4) in the priority queue (the third step). Although the
node d2 is also adjacent to the node d3, it will not be updated because p1,2 > p1,3 *
D3,2 and Π( p1,2) ¼ max ( p1,2, p1,3 * D3,2).
The next active node (node d6) is taken from the priority queue (the third step)
and is used to update its adjacent mode d5 (the fourth step). Now the node d2 is the
highest reachable node among the nodes left, and it is used for further tracing (the
fourth step) and updating the priority queue (the fifth step). Although node d3 can
also be reached by node d2, it is excluded for further tracing to avoid tracing a path
that loops endlessly and also because it has been visited before.
As mentioned above, this process terminates when either all nodes have been
visited or all nodes left in the priority queue have a cumulative probability less than
ε along the path. In the example illustrated, the tracing terminates at the sixth step
that Π( p1,5) of the current active node 5 is less than ε. Because Π( p1,5) < ε, any
further traces from node d5 will not be visited. Tracing starts at the starting node and
terminates when the algorithm has revealed all the nodes contribute to risk (danger).
Algorithm of Backward Tracing (Recovery)

A similar algorithm can be applied to discover the source or reason for the potential
sequence of manifested faults. This is required for two reasons: Firstly, not all
Fig. 6.19 Backward tracing to find the causes
elements might have good quality of sensors or precise models; and a fault in
element might not be manifested as a discrepancy of data or behaviour at another
node. Secondly, if possible, recovery should be started not from a manifested
element but from the reason, treating the reason not just the symptoms. Backward
tracing of the dependency matrix makes it possible to find the elements that are
likely to be the cause of the faults manifested by the suspected element. The
algorithm of backward tracing is presented in Fig. 6.19.
When a high probability of system failure is discovered, measures such as an
emergency landing might be recommended. If, however the result of the backward
recovery algorithm shows that there was no sequence of faults, then no action will
be taken other than the suspect event being recorded. Recovery actions from list of a
legitimate and relevant actions will be reported to the crew, pilot and maintenance
engineer. Also, using telecommunication links, information about the possible fault
and advice given could be transmitted to responsible bodies, possibly via a satellite.
Implementation of the APASC During Flight

The APASC ONBOARD has two main functions:
• Searching of possible consequences of potential fault of elements
MODULE APASC ONBOARD;

IMPORT RealTimeSystem;
PROCEDURE APASC;
(* ….. system initialization…. *)
CONST N: INTEGER; (* N is the number of the elements *)
VAR k: INTEGER; (* k elements will be monitored *)
BEGIN
FOR k=:1 TO N Do RealTimeSystem.RealtimeThread
(applicationLogicforElement_k, priorityofElements_k, period_k);
END
END APASC;
BEGIN
APASC
END APASC ONBOARD.
Fig. 6.20 Algorithm of the PASC
• Determination “what is the source or the reason of possibly dangerous event

sequence”
The first function is initiated by a signal from flight data analysis about existing
systematic discrepancies in an element. The second process defines “what was the
possible reason and how to react on it.” The reaction is in fact a recovery procedure
or procedures. Both functions use dependency and probabilistic matrixes in
Figs. 6.12 and 6.14, respectively.
An implementation of the APASC during flights is described in the style of
OBERON [8] in the pseudo code in Fig. 6.20. The elements of the aircraft are
monitored during each phase of flight.
The on-board part of the APASC is activated by a signal indicating that there is a
discrepancy in behaviour of one or more elements. When a fault from an element is
suspected, a sequence of actions should be taken to interpret the unusual event to
prevent the further development of the fault that could put the aircraft at risk. The
procedure is called Monitor and operates on the dependency matrix shown in
Figs. 6.21 and 6.22.
Starting from the “suspected” element, all possible traces and their probabilities
are calculated and their sequences are ranked according to their relative
probabilities.
The corresponding tracing and backward tracing implementation are illustrated
in Figs. 6.23 and 6.24.
Conclusion
The principle of active system control and safety (PASCS) has been further
developed. Specifically, the mapping between flight information and the elements
of an aircraft have been defined, highlighting their mutual dependence. A model for
Conclusion 185
PROCEDURE applicationLogicforElement_X (period_X: LONG);
BEGIN
WHILE (SwitchOff # TRUE and AircraftCrashing # TRUE ) DO
(* acquire data and accumulate them for the element x
for the specified period *)
IF ( pxmx(ex(dx(t))=False ) THEN
(* discrepancy in behaviour of element(x) happened *)
Monitor (x)
System.Wait(period_X-TimeForProAndDiagnosing);
ELSE
System.Wait(period_X);
END
IF (NormalSwitchOff = TRUE) THEN
(* … normal switch off ...*);
ELSE
(*… Back up enough information during aircraft crashing …..) ;
END
END (* WHILE *)
END applicationLogicforElement_X;
Fig. 6.21 Monitoring of elements condition
PROCEDURE Monitor(suspectedNode);
CONST
N (* N is the number of the elements *)
d={ } (*sequences of elements in danger *)
f={ } (*sequences of elements originating faults *)
BEGIN
IF ( d=tracing(suspectedNode,DependencyMatrix) is not Empty AND
aircraftInDanger(d)) = TRUE)
(* define most probable sequence of further damages and identify
potential sequence of faults *)
THEN
(* identify the source of the faulty events to add then into the
reasons of fault elements set *)
backwardTracing(suspectedNode, RecoveryMatrix, f);
(* suggest recovery scheme to pilot, it must be list of actions *)

recovery(f)
ELSE
ignoreSuspecteds()
END
END Monitor;
Fig. 6.22 Monitor of suspected node
analysing the safety of aircraft in terms of changes in their internal conditions was
introduced, called the model of active system safety for aircraft (MASCA).
The advantages and disadvantages of various mathematic methods to analyse the
behaviour of aircraft in terms of the MASCA were briefly discussed, including AI,
Fig. 6.23 Tracing implementation
learning models, statistical models and threshold models. The threshold model has
been chosen for trial implementation in the PASC project based on practical
implementation considerations.
The MASCA was developed using binary and probabilistic matrixes of depen-
dency between aircraft elements. Assuming the non-Markovian property of the
matrices, two new algorithms were introduced: an algorithm of possible conse-
quences and an algorithm of possible reasons for developing trends or the faulty
behaviour of the aircraft. These algorithms make it possible to monitor the safety of
an aircraft in real-time of flight. They were defined in both mathematical form and
also in pseudo-code form for implementation using a programming language.
An example of implementation of the model of active system safety was
presented using typical flight data for typical GA aircraft.
The role and structure of information about flight control conditions and safety
conditions of the aircraft have been analysed and modelled. It has been shown that
there is no direct one-to-one mapping between flight information and aircraft
safety; at the same time it is clear that any active safety system for aircraft should
be designed to take best advantage of the dependencies that exist in practice.
Conclusion 187
Fig. 6.24 Backward tracing implementation
Aviation and aircraft provide the most complex areas for the application of
technological advances: they involve the most complex and long-lasting working
periods, an extremely wide range of working environments and need
multidisciplinary skills from personnel involved. Therefore, the PASCS has
become the subject of multidimensional research covering many logically
connected aspects.
References
1. Haussler D (1988) Quantifying inductive bias: AI learning algorithms and Valiant’s learning
framework. Artif Intell 36:177–221
2. Chervonenkis AY, Vapnik VN (1971) On the uniform convergence of relative frequencies of
events to their probabilities. Theor Probab Appl 16(2):261–280
3. MacClure C (2000) Industrial mathematics. Prentice Hall, Upper Saddler River
4. Castano V, Schagaev I (2015) Resilient computer system design. Springer. ISBN 978-3-319-
15069-7
5. Schagaev I, Kaegi T (2016) Software design for resilient computer systems. Springer. ISBN
978-3-319-29463-6
6. Schagaev I et al Graph logic model framework for predictive linguistic analysis. http://
worldcomp-proceedings.com/proc/p2016/ICA6078.pdf. CSREA Press. ISBN: 1-60132-438-3
7. Schagaev I (2001) Concept of active system safety. In: Proceedings of the 15th IFAC
symposium on automatic control in aerospace, Bologna/Forli, Italy, 7 Sept 2001
8. Wirth N (2016) Programming in Oberon. http://www.oberon.ethz.ch. Accessed 10 June 2016
9. Schagaev I (1998) Concept of dynamic safety for aviation. ISSC, Seattle
10. Schagaev I (2001) Redundancy classification and its application for FT computer system
design IEEE TESADI-01, Tucson
11. Kirk B et al (2007) Applying the principle of active safety to aviation. In: Proceedings of the
2nd European conference for aerospace sciences (EUCASS), Brussels. https://www.academia.
edu/7124264/Applying_the_Principle_of_Active_Safety_to_Aviation
12. Schagaev I Control operators vs graph logic model, WordlComp14. http://worldcomp-pro
ceedings.com/proc/p2014/FCS2096.pdf
13. https://elibrary.gsfc.nasa.gov/_assets/doclibBidder/tech_docs/25.%20NASA_Fault_Tree_Hand
book_with_Aerospace_Applications%20-%20Copy.pdf
Chapter 7
Active System Control: And Its Impact
on Mission Reliability
Reasoning
As is generally known, existing regulations on transport, such as trucks, trains and

aircraft, require periodic maintenance according to a schedule defined either by the
manufacturer, by actual operational use or by rules imposed by regulatory bodies
e.g., an airworthiness certificate.
Maintenance periods for vehicles are accompanied by intermediate checks based
on actual operational use, and also annual checks if use is infrequent [1–4]. In
practice, it is difficult to know the precise quality, depth and regularity of these
checks, and maintenance as a whole, even for aircraft, can hardly comply with the
requirements [5–8].
As was shown in previous chapters, and as is also shown in [3, 9, 10] presented at
the Flightglobal Safety Symposium in 2015 [11], the enforcement of regulations
and improvement of vehicle control and internal vehicle handling conditions might
be achieved by use of our active system control (ASC) approach.
Even in aviation, maintenance suffers from the lack of effective enforcement and
consistent quality. Above all, maintenance procedures in aviation are considered to
be an extra cost concerned with efficiency. Controllability and safety requirements
do not necessarily result in a visible benefit [12, 13]. Even when maintenance is
performed, checking is highly unlikely to be considered as being complete [7]. Dur-
ing flights, health monitoring systems [14] derived from [15] (in form but not in
depth) are incomplete and do not reduce the risk of aircraft failure or prevent
unpleasant events. This approach is based on statistical analysis of the data about
the system and is useful when:
(a) Data are sufficient and reliable
(b) Data can be aggregated with previous data and results. This is not always easy, as
– Conditions of the flight may vary over the operational life
– Modes of flight and pilot or crew skills might vary widely

190 7 Active System Control: And Its Impact on Mission Reliability
ASC requires and provides: An awareness of aircraft conditions and opportu-

nities to adapt control for flight safety in real time of flight during each mission and
across the lifetime of operation of the aircraft.
ASC acts during the flight, taking into account both historic information about
faults that the aircraft may already have its current state, and information gathered
in real time and already available. ASC will therefore help to analyse, reflect and
further monitor the vehicle/aircraft missions as well as quality of maintenance.
To accomplish this, real-time structural models of the aircraft are required to enable
the checking of deviations that may be developing.
Regretfully, so far we have faced a situation where the decision to use an aircraft
for the next flight is taken almost arbitrarily, based more or less on trust: examples
and cases described by Observer 2005 include Airbus 330 Air France 2009 case,
Boeing Quantas 2012, Eurowing, Egypt Air accidents 2015–2016. Note that the
quality of airworthiness certification depends greatly on human factors (e.g.,
existing qualification, training, integrity). The risks associated with poor training
are a real concern in the commercial aviation (CA) segment. Recent accidents show
that neither design of aircraft nor their control systems or maintenance procedures
are satisfactorily reliable.
Expectations about special training and retraining of personnel involved, or
improving the quality of maintenance and upgrading landing strips to
airfields, cannot alone improve the situation. Making maintenance obligatory is
goodwill, but in practice it is neither realistic nor feasible. On the contrary, ASC
supported by new Information and Communication Technology ICT might provide
new qualities of control and maintenance of an aircraft and their flight conditions
within required corridors of safety, reliability and efficiency as a whole. As
described, ASC needs to be based on an information-processing framework or
system that analyses aircraft conditions using both accumulated and current flight
(or mission) data from aircraft devices and based on a knowledge of each aircraft’s
structure [9, 17].
Active system control goes further in prescribing the procedures to cope with the
operational situations and deterioration of conditions in real time, highlighting what
maintenance improvements may be possible and beneficial, and if longer-term what
redesign of the aircraft might be done in the future.
In the interview to Boston Facultimedia [18] we have mentioned that:
“. . .every good idea has it own limits”, Here we have to add: “. . . and its own cost”.
Although the logic of this approach and its implementation has already been
covered in other chapters, one question remains unanswered:
“What are the gains? What mix of performance, reliability, energy efficiency and safety is
required?”
To answer these questions we need to estimate what our ASC gives in the real
time analysis of each flight as well as in the long run. Further, we will try to
analyse the changes and possible gain in overall reliability of an aircraft or vehicle.
Preventive and Conditional Maintenance Versus Active System Control. . . 191
Initially, we will consider regulated maintenance periods to analyse in comparison

to the impact on reliability from the point of view of preventive or conditional
maintenance theory. Secondly, it is interesting to estimate how far ASC can be
applied to evaluate and estimate conditions of an aircraft or vehicle in real time of
the mission or flight.
But the most important thing is to define the main semantic difference between
classic estimations [1] and proposed active system control approach defining where
possible similarities and highlighting major differences.
Preventive and Conditional Maintenance Versus Active

System Control: A Semantic Difference
The concept of preventive maintenance [13] has been known amongst aviation
academics and less so amongst aircraft engineers and maintenance engineers for a
long time, but it has never actually been thoroughly implemented [7]. The distance
between theory and reality is huge—for example, two accidents with Rolls Royce
engines within two days of the 4th and 5th of November 2010 manifested the lack
of knowledge and ability to apply them to maintain the required level of reliability
for aircraft engines.
To some extent, a trend towards preventive maintenance is happening in the
automotive sector, mostly for the aggregation of information about the wear of parts
and the amount of vehicle use [6], but again the volume of recalled cars due to poor
reliability for Ford, Toyota, Mercedes and other brands regularly exceeds hundreds
of thousands each year, making it clear that the existing concepts of preventive
maintenance and quality of design are not sufficient or efficient enough by
themselves.
In the case of automotive subsystems such as engine management (VW/Bosch)
and air bags (Takata) the recall numbers are in the millions per year and the costs
into billions of US dollars:
http://www.dailymail.co.uk/wires/afp/article-4118090/US-charges-three-indictments-
Takata-airbag-scandal.html
https://www.washingtonpost.com/business/economy/toyota-reaches-12-billion-settle
ment-to-end-criminal-probe/2014/03/19/5738a3c4-af69-11e3-9627-c65021d6d572_
story.html?utm_term¼.d8c399db6e00
http://www.autoexpress.co.uk/volkswagen/92893/vw-emissions-scandal-recalls-
compensation-is-your-car-affected-latest-news.
By way of contrast, we propose the application of the principle of active system
control (PASC) which can change the situation by shrinking the gap between what
we think and what we do. This approach was developed and implemented in
1991–1994 as part of, and for, the Sukhoy advanced aircraft program. Known
then as the concept of dynamic safety (CoDySa), it was translated in 1995, then
presented and published in 1998 in English [15, 19, 20]. Further, extended as the
concept of ASC and safety, this approach was registered on September 20, 2010, by
European OHIM, No 008895674 and patented in the UK [20], as well as presented
at [9, 10] and now is progressing with NASA [11, 21] (at an initial stage).
Our concept of dynamic or active controlling of states of a system and preven-
tion of “system drift” to dangerous states and trends inside is not 100% new. This
concept is a direct derivative of our original approach introduced as an extension of
fault tolerance from being considered as a system property to that of a process of
implementation of this property in 1983–87 and published in [22]. Known as
CoDySa it was already prototyped as mentioned above during 1991–1994 at
Sukhoy Design Bureau projects. CoDySa was also presented in 1995 for and by
special invitation from British Aerospace in Filton and in York for senior members
of UK Safety-Critical System Task Force. Later, CoDySa was presented as a paper
and in a presentation included in the International System Safety Society Confer-
ence, Seattle 1998 [15].
During this period, the CoDySa concept for unknown reasons was renamed by
British Aerospace (now BAEsystems) as a health monitoring system [23]. Rela-
tively recently our concept was renamed again as the “Damage prognosis model”;
see Royal Society publication [24]. Unfortunately, all of these adaptations tend to
be based on or stick with statistical models aimed at the estimation of trends
concerning the conditions of elements. A more recent trend has been to call it
“prognostic methods.” These methods have been further developed by NASA [25]
and again later by MIT [26].
Semantically there is a difference between what we first presented and what was
later adapted by others:
• The schemes they use assume that system conditions can be evaluated before
and after use; the approach is based on the application of probabilistic models for
the analysis of potential trends (eventually) after accumulation of data and
application of various statistics techniques. Note that all methods use statistics
to estimate behaviour; in other words, they all are about a posteriori analysis and
later actions, the danger being that “the baby can be thrown out with the
bathwater”.
• By way of contrast, in ASC, as registered in a patent by the authors of this book
[20], we need to address the physics of processes and react to a single event, even
if we have no statistics at all. It does not exclude the role of statistics if it is
available; it integrates real-time data and reaction with existing knowledge and
data when it is possible, making real-time reliability possible and improving it!
It is worth mentioning here that no matter how good a principle is, without
implementation it only has rhetorical value. Science is tempered by the reality of
evidence used to verify theory in practice.
Reliability Gains: Conditional Maintenance Versus Active System Control 193
Reliability Gains: Conditional Maintenance Versus Active

System Control
The implementation of the PASC requires a combination of a model of aircraft,

feasible for real-time application, as well as special on-board hardware and system
software. The model, as described in previous chapters, includes continuous,
detailed dependency capture, analysis of model and available data of both kinds.
Initial data of the model that are created during the development cycle characterise
the particular aircraft, and data registered during the flight/mission captures its
usage/abusage.
When combined with an aircraft model, and integrated with real-time analytics
focused on aggregation and processing of real-time aircraft data, an analysis of
aircraft or any other vehicle condition, the PASC can be extremely powerful. As
shown in Chaps. 5 and 6, the PASC might reconfigure the system, even in the
presence of faults eliminating the impact and consequences of even very powerful
faults, as faulty behaviour can be detected dynamically including discovering new
types of fault and reconfiguring the system to the correct conditions.
Note that a pilot or driver cannot be involved directly in handling critical
conditions; the processes and complexity of control systems and aircraft designs
do not leave room for manoeuver. Humans would quickly become the weakest link
and cannot be considered as an element in an active conditional control approach.
In turn, to have any credibility, the ASC framework itself must be ultra-reliable in
three ways:
– Always be available, even though the aircraft itself may not be serviced to
schedule
– Always offer safe and relevant actionable advice based on the current conditions,
using previous flight data, current flight data and trustworthy analysis
– Present an action plan to conserve or improve conditions by avoiding risk, which
is credible in its own right and transparent and clear to the operators, crew and
other relevant institutions
Leaving challenges in the analysis of available data for researchers [14], and
mentioning the complexity of the real-time model described in Chaps. 5 and 6, we
need to point out that complexity of modern aircraft or any transport vehicle is not
decreasing, and reliability, controllability and other properties either define or
depend on special evaluation of the aircraft state, which becomes more and more
important and difficult to achieve as aircraft become larger and/or more complex.
So what is wrong with that approach? This question, applicable to any theory or
result, can be applied to the implementation of ASC. The answer is clear, the
condition of the aircraft will not be really known and its operational behaviour in
real time deviates from normal.
The PASC, in contrast, deals with the physics of a system and describes real
dependencies, addressing each event and coping with its consequences as well as
predictions of the consequent vehicle state. Taking the longer-term view, we can
apply similar “estimators” of the system states as well as those used in the real time
of the flight.
By starting with well-known models of preventive maintenance and later intro-
ducing the active system control model it becomes possible to compare these
approaches probabilistically using similar assumptions for both cases. Preventive
maintenance for aircraft, as well as for other complex technological objects with
safety-critical functionality, was introduced in the early 1960s [13]. Professor
Alessandro Birolini in his book Reliability Engineering [1], which has had eight
editions over 20 years, introduced the fundamental assumptions that define condi-
tions and features of models for preventive maintenance:
• Dependence of the periods of preventive maintenance on parameters and data
• Role of checking and testing coverage on quality parameters
• Development of generalised model including these two factors
Classic preventive maintenance assumes, as previously mentioned, statistical
modelling and analysis of the system after each mission. The last bullet point deals
with efficiency of processing of flight data and evaluation of system condition; this
is well covered by the PASC models which include analysis of an aircraft or a
vehicle state in all phases of flight/use: pre-, during-, and post-mission.
There is no doubt we need to consider some future research challenges:
• The impact of the volume of data on the quality of evaluation of vehicle
condition
• Time of processing of flight (current) data
• Reliability versus models available (“are the structure models available good
enough?”)
• The impact of flight data on safety (“how much we need to know to be safe?”)
• The relationship between accumulated and current flight data to define condition
• Data integrity in the long term (distillation of flight data trends)
• The efficiency of data access for evaluation of conditions according to PASC
Development of a model for preventive maintenance based on:
• Analysis of conditional probability
• Reasoning and inference about the assumptions of preventive maintenance
• Analysis of the main factors that influence the period of preventive maintenance
We have to add here an evaluation of the impact that the PASC has on the
policies of preventive maintenance, but we will introduce that at a later stage.
Taking into account [3], the whole analysis of conditional and preventive
maintenance presented in detail by Birolini [1], we summarise and briefly explain
the assumptions on conditional maintenance and the above-mentioned parameter.
The result of applying the ASC model and implementation are then compared with
those resulting from conventional methods.
Figure 7.1 shows the function of mission reliability MR(t) for the case of
periodic maintenance with incomplete coverage. The solid curve is the mission
reliability curve; the dashed line is the threshold; and the dot-dash line indicates the
Perfectly reliable state, R = 1

1
0.8 MR(t)
0.6
0.4
0.2
MR0
0
0 5 10 15 20 25 30 35 40
Fig. 7.1 Conditional periodic maintenance with incomplete coverage
perfect reliable state of the system, that is, as if it were 100% reliable. It is assumed
that while the threshold is reached, maintenance is carried out. But for this example,
because of incomplete coverage, the mission reliability of the system cannot return
to 100% after maintenance, and the peak amplitude of recovery of conditions after
iterations of maintenance gradually degrades over time.
The following assumptions and equations for mission reliability were used in the
case of conditional maintenance:
Assumption 1: Coverage is not 100%. Coverage percentage is 100αM%, where
0 < αM < 1 and is assumed to be constant over the whole lifespan of the aircraft
and represents the gradual degradation of the effectiveness of maintenance of the
system.
Assumption 2: Maintenance is instantaneous, not delaying the aircraft use schedule.
Assumption 3: A threshold of acceptable reliability R0 exists for R(t).
Assumption 4: TPM is not a constant but a variable—actually, a function of several
variables, including α, λ and R0.
Reliability is then calculated according to (7.1):
8 !
> X
n
>
> T PM ðiÞ
>
> λ t
X
n
>
< RðtÞ ¼ αðn1Þ e i¼1 , T PMðiÞ < t
! ð7:1Þ
>
>
i¼1
>
> X
n
>
> T PM ðiÞ ¼ R0 , n ¼ 1, 2, . . . , m
: R
i¼1
The resulting reliability curve for this case is presented in Fig. 7.1; it is now
assumed that maintenance takes place when the system (in this case an aircraft)
reaches the threshold reliability, that is, when R(t) R0.
This case has some theoretical interest, as it may be useful to analyse the role of
all the variables that define behaviour of the period of maintenance TPM. Calculat-
ing TPM (i), for i ¼ 1,2, ...,n, and taking into account the role of the other variables
such as R0 and α, then TPM (i) is given as (7.2):
1
T PM ðiÞ ¼ ln Ro αð1ði1ÞÞ ð7:2Þ
λ
This model is more realistic than the classic periodic maintenance described in
details in [Birolini16]; in principle, it is now possible to schedule maintenance
when the threshold of acceptable reliability has been reached. Note that the interval
between maintenance inspections is shrinking significantly (7.3):
ΔT ðiÞ ¼ T PM ðiÞ T PM ði þ 1Þ ð7:3Þ
The relative decrease can be evaluated by the rate of decrease of T(i) (7.4):
T PM ðiÞ T PM ði þ 1Þ
ΔT ðiÞ ¼ ð7:4Þ
T PM ði þ 1Þ
or by the function of the interval index (7.5):
T PM ðiÞ T PM ði þ 1Þ
ΔT ¼ ð7:5Þ
i
Figure 7.1 shows the reliability function under conditional maintenance with
incomplete coverage using the previous assumptions. In Fig. 7.2, after the threshold
has been reached, maintenance is carried out. But now, because of incomplete
coverage, the reliability of the system cannot return to 100% after maintenance, and
the amplitude of coverage that the maintenance can achieve gradually reduces over
time.
The actual condition of the aircraft use depends on the defined reliability
threshold Ro and the interval between two sequential maintenance inspections
when the mean mission (flight) duration approaches ΔT. When the aircraft reliabil-
ity approaches Ro just after a flight it should be grounded in the interests of safety.
0.8
0.6
0.4
0.2
0
0 5 10 15 20 25 30 35 40
Fig. 7.2 Preventive maintenance using online checking
Preventive Maintenance with Implementation of Active System

Control
Active system control introduces a new process in aircraft management: online

checking of the aircraft’s fault status and safety condition. Online checking is a
process of checking of the aircraft’s main elements in real time, including aircraft
hardware (in general), avionics and pilot during the flight. The aim of checking
within the system is detection of degradation or a change in behaviour and, if and
when possible, corrective recovery of the suspected element and therefore conser-
vation of the system’s reliability. When recovery is not possible, the preventive
nature of ASC schemes promotes actions to reduce the level of danger, risk, etc.,
aiming for graceful degradation of service to the aircraft’s users.
The processes of checking the state of the aircraft, the estimation of its reliabil-
ity, and the estimation and scheduling of maintenance are, of course, independent in
principle, so they can be considered concurrently or sequentially. Each activity can
be started when required, when possible or just when convenient. The classic idea
here is to perform checking well in advance when the current reliability RT is higher
than the threshold reliability and in such a way that during TPC the aircraft does not
reach the threshold reliability, that is during a flight.
What is interesting here is that the processes of checking and preventive main-
tenance, when combined, change the estimated reliability of the system. The
gradient of this change depends on the quality of checking (coverage) and the
quality of maintenance.
When considering the impact of ASC in operation, we need to stress that
preventive procedures are possible and implemented on-board during each flight
or mission. For an estimation of the reliability behaviour we assume:
• A constant failure rate
• Maintenance is not ideal and coverage is less than 100%
• The minimum acceptable reliability threshold is introduced as before
Some other assumptions relate to the checking process:
Assumption 1: Coverage of maintenance is not ideal that is, is 100αM%, where
0 < αM < 1 and is assumed as a constant.
Assumption 2: Threshold R0 exists for R(t).
Assumption 3: There is online checking process with period TPC, and TPC is a
constant.
Assumption 4: After each online checking, the confidence about the system’s
conditions is increased; therefore, R(t) is also increased, and this confidence is
100αC%, while 0 < αC < 1 and αC is a constant.
Assumption 5: The period between two successive maintenance inspections is TPM
(i). TPM(i) is a variable, actually a function of i, R0, αC, αM, λ and TPC.
The reliability function for the aircraft is then calculated according to (7.6):
RðtÞ ¼ RI αC ðn1Þ eλðtnT PC Þ , nT PC t < ðn þ 1ÞT PC ð7:6Þ
In Eq. (7.6), R(t) signifies the nth online checking period, and nFAM signifies the
first online checking period after the latest maintenance inspection, that is, the nFAM
is the online checking period. For a brand new system, nFAM ¼ 0. RI is the initial
value of reliability at the beginning of a maintenance period, or the reliability level
as reassessed after the latest maintenance inspection has been carried out, so RI ¼ 1
for a brand new system. After that, RI gradually decreases over time because the
coverage of maintenance is not 100% and there is a continual natural ageing process
at work.
Actually, RI can be calculated by an equation like (7.7):
RI ðiÞ ¼ αM i1 ð7:7Þ
where i corresponds to the ith maintenance period. It is easy to see that RI denotes
the initial value of reliability at the beginning of a maintenance period, while RI
αC ðnnFAM Þ denotes the initial value of reliability at the beginning of an online-
checking period.
When the reliability of the aircraft reaches the threshold Ro it should be grounded
awaiting maintenance, and so (7.8):
Rððn þ 1ÞT PC Þ R0 ð7:8Þ
From a practical point of view, the online checking period should be constant,
and the checking procedure resulting action—recovery of the system should
start straight after. Note here that while avionics nowadays consume 60% of
aircraft costs and complexity, and for avionics the ratio of malfunctions to
permanent faults is typically 65,000:1, the reliability of the aircraft will indeed
be improved dramatically. When the ACS includes actions for reconfiguration of
the aircraft due to mechanical faults, the impact of recovery will be even higher.
Suppose that the checking takes (relatively) no time, then effectively mainte-
nance (recovery, reconfiguration) will be carried out immediately when
R((n þ 1)TPC) R0.
Even if a time delay due to the checking process needs to be considered, we still
assume that the maintenance is carried out only at the end of the following online-
checking period. This means the maintenance period is composed of a certain
number of online-checking periods. Let index n be the serial number of an
online-checking period, and index i be the serial number of a maintenance period,
then the online-checking period TPC and the maintenance period TPM(i) are the
points of interest. The difference and relationship between TPC and TPM(i) is that
the online-checking period TPC is a constant, whereas the maintenance period
TPM(i) is a variable; TPM(i) contains a certain number of TPC.

T PM ðiÞ ¼ ðn þ 1ÞT PC T PM ði 1Þ, i > 1
ð7:9Þ
T PM ðiÞ ¼ ðn þ 1ÞT PC , i¼1
R(t) ¼ RIαM then RI ¼ R(t).

Under these assumptions the reliability function is then illustrated in Fig. 7.2,
which shows the reliability function for preventive maintenance with online
checking, where the solid curve is the reliability curve, the lower line is the
threshold and the upper line indicates the “as new” reliability of the system.
During each online checking period, the latest system states are measured and
analysed to provide an awareness and confidence about the reliability of the
system (subject to no faults being detected). When the nominal reliability reaches
the threshold, the on-ground maintenance is carried out just as with conditional
maintenance.
When no maintenance takes place for a long time (the actual situation in GA
and in the vast majority of budget airlines), the reliability of the aircraft or
vehicle will reach the lower threshold Ro. The rate of reliability decrease is in
fact faster than with online checking. The gap of confidence between a point in
time before and after checking is now referred to as a corridor of confidence or,
more exactly, a corridor of reliability. It is the safe operational area where the
reliability curve is normally expected to stay during operation of the online-
checking scheme.
The Real-Time Reliability Corridor: Introduction

and Definitions
The basic model of a reliability corridor δ is defined using practical assumptions

and a set of scenarios as in the previous sections. The reliability corridor provides
an estimate of where the reliability (curve) could reach in each online checking
period, and therefore could effectively help to decide when maintenance is neces-
sary in order to avoid violating the given reliability threshold. On the other hand,
the “width” of the reliability corridor will help to define the requirements for
software and hardware in terms of allowable data processing time delays. The
corridor is plotted in Figs. 7.3, 7.4, 7.5, 7.6, 7.7, and 7.8 using the same layout
conventions as before. The limits of the corridor are shown with dotted lines above
and below the reliability trace on the graphs.
Definition 1 In each online checking period, the width of the corridor δ is a
constant and does not depend on time. During the nth online checking process the
reliability corridor δ(n) is a function of n and given as (7.10):
δðnÞ ¼ RðnT PC Þ Rððn þ 1ÞT PC Þ ð7:10Þ
Clearly the corridor under this definition becomes too conservative at the end of
each online checking period because the amplitude of coverage by online checking
shrinks as time goes on, as is illustrated in Fig. 7.3.
Perfectly reliable state: R = 1

1
Upper boundary of
R(t) reliability corridor
0.8
0.6
0.4
0.2
Lower boundary of
Threshold: R0 reliability corridor
0
0 5 10 15 20 25 30 35 40
Fig. 7.3 Reliability corridor as a function of number of iterations

0.8
0.6
0.4
0.2
0
0 5 10 15 20 25 30 35 40
Fig. 7.4 Reliability corridor as a function of time
Definition 2 Here we introduce a time-varying corridor, that is, the width of the
corridor δ varies over time within each online checking period. The expression δ(t)
for the nth online checking process is given as:

δðtÞ ¼ RðnT PC ÞαC ðtnT PC Þ=T PC 1 eλT PC , nT PC t < ðn þ 1ÞT PC : ð7:11Þ
Actually, RðnT PC ÞαC ðtnT PC Þ=T PC in Eq. (7.11) defines the upper limit of the
corridor at time t.
Assume that a ghost system has a reliability of the same value at the upper limit
of the corridor at time t; then RðnT PC ÞαC ðtnT PC Þ=T PC eλT PC is the reliability of the
ghost system after an online checking period TPC. The width of the corridor at time
t, δ(t), equals the difference between the upper limit of the corridor at time t and the
reliability of the ghost system at time t + TPC. It is evident that the width of the
corridor varies over time.
The resulting corridor of the reliability curve is illustrated in Fig. 7.4, where the
corridor more closely matches the reliability curve compared with Fig. 7.3 and
crosses the lower threshold later. Note also that with each major cycle the best
reliability achievable gradually decreases.
Defining the Frequency of the Checking Process
There is no doubt that to check a state of an aircraft every nanosecond is useless

simply because now data about aircraft conditions become available at the end of
every 0.125-sec period, which is a standard on-board convention about the interval
between data recording frames. Therefore, we need to introduce and define the
frequency of the checking process. To estimate reliability values – note – real-time
analysis during flight as opposed to
Assumption 1: The online checking process starts at the beginning of each online
checking period. Due to the time consumed by online data processing, the real
reliability curve is more like that illustrated in 5, where the dotted vertical lines
indicate each online checking period, in this case 2-time-units long. Because the
measurement and analysis of the latest system states are completed immediately at
the beginning of each online checking period, awareness and confidence about the
system are not improved until these data are available, and therefore there is a delay
β on the coverage of the reliability curve in each online checking period. So β is the
time required for data processing, which may vary, and has an upper bound
βmaxandβ βmax; at worst:
βmax ¼ T PC ð7:12Þ
The question is, what is the influence of a data processing delay on the definition
of the corridor, that is, the impact of βmax onδ(t), assuming the second definition of a
corridor is adopted? When βmax is taken into account, δ(t) can be calculated using:

δðtÞ ¼ RðnT PC ÞαC ðtnT PC Þ=2T PC 1 e2λT PC , nT PC t < ðn þ 1ÞT PC ð7:13Þ
Compared with TPC in Eq. (7.11), 2TPC in Eq. (7.13) embodies the maximum
delay due to online data processing of the data collected in real-time from the
aircraft. For the ASC approach that is introduced, the processing of conditions and
the estimation or reliability of a hypothetic system will be on the order of seconds
during the application or mission.
Note that existing schemes of estimation of aircraft or vehicle conditions assume
periods of a posteriori estimation in days and sometimes, more realistically,
months. That is why ASC equations define real-time reliability of an object.
Avoiding R0 Being Breached When a Delay Occurs
For ASC to be practical, it is crucial that the real-time reliability should not fall
below the threshold R0 even when βmax is taken into account. This can be achieved
in one of the following three ways or methods.
Method 1 Within each online checking process, after data processing is finished,
investigate whether or not the reliability is below the threshold R0. In this case, due
to the delay caused by data processing, the threshold could still be violated.
Figure 7.5 shows that when online checking is carried out (e.g., at time 30) the
modelled reliability is above the threshold but then goes below the threshold when
the online checking process is finished at time 32.
0.8
0.6
0.4
0.2
0
0 5 10 15 20 25 30 35 40 45 50
Fig. 7.5 Reliability with calculations after the checking period
Method 2 In each online checking process, check whether the bottom line of the
corridor is below the threshold R0, that is,
ðnnFAM Þ remðt;T PC Þ=T PC
RI α C αC δðtÞ R0 ð7:14Þ
where the first term on the left-hand side of the equation defines the top of the
corridor, and “rem” signifies the remainder after dividing t by TPC. The result of
applying this method is illustrated in Fig. 7.6. The maximum delay, that is, TPC, is
taken into account when defining the width of corridor in Eq. (7.13) so that the
corridor always covers the reliability even when there is a data processing delay.
Consequently, the reliability never reaches the lower threshold because mainte-
nance is carried out in time before the bottom of the corridor reaches the threshold.
Method 3 Define a buffer zone, that is, [R0, RB], then in each online checking
process, see whether the reliability is within the buffer zone, that is,
Rððn þ 1ÞT PC Þ R0 þ RB ð7:15Þ
The result of this method introducing a buffer zone is illustrated in Fig. 7.7,
where the buffer zone is represented as the area between the two lower horizontal
lines. Due to the delay caused by online data processing, there is a possibility that
the reliability may fall below the upper limit of the buffer zone. After this happens,
maintenance must be carried out in a timely way in order to avoid the nominal
reliability going below the low threshold limit.
0.8
0.6
0.4
0.2
0
0 5 10 15 20 25 30 35 40 45 50
Fig. 7.6 Reliability with checking for reaching threshold R0
0.8
0.6
0.4
0.2
0
0 5 10 15 20 25 30 35 40 45 50
Fig. 7.7 Reliability with checking in a buffer zone

Conditional Maintenance Versus Active System Control 205
Conditional Maintenance Versus Active System Control
From the previous sections it should be evident that preventive maintenance is more
efficient than conditional maintenance. The quantitative analysis in this section will
help to make the picture clearer. First of all, some criteria are needed in order to
carry out a fair comparison. For example, the time between two successive main-
tenance sessions, the lifespan of the system under certain maintenance strategy, and
how many times maintenance is carried out during the lifetime of the system.
However, an effective index is the integration of reliability over a given time
period, which literally means the volume of the area enclosed by the reliability
curve and the reference axes.
The key reason this index is proposed is because it can reveal how reliable a
system is during a given time period. The integration values of reliability under
conditional maintenance and preventive maintenance are calculated by Eqs. (7.16)
and (7.17), respectively:
Z T1
V CM ðT 1 Þ ¼ RCM ðtÞdt ð7:16Þ
0
Z T2
V PM ðT 2 Þ ¼ RPM ðtÞdt ð7:17Þ
0
where RCM(T ) and RPM(T) are given by Eqs. (6.5) and (6.10).
The gain of efficiency using the proposed ASC over conditional maintenance
can be assessed from (7.18):
V PM ðT 2 Þ V CM ðT 1 Þ
y ðT 1 ; T 2 Þ ¼ ð7:18Þ
V CM ðT 1 Þ
First, let T1 ¼ T2. This means that the reliability of the system under preventive
maintenance is compared with that under conditional maintenance in a same time
period. Figure 7.8 gives an example of such a comparison, where T1 ¼ T2 ¼ 40.
1 1
0.8 0.8
0.6 0.6
0.4 0.4
0.2 0.2
0 0
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
Fig. 7.8 Efficiency of conditional and preventive maintenance

According to Eqs. (7.16) and (7.17):
V CM ð40Þ ¼ 15:5961, V PM ð40Þ ¼ 18:5084 and yð40Þ ¼ 0:1867
The fact that VPM (40) > VCM (40) means that in the 40-unit time period
specified, the system under preventive maintenance often has a higher reliability.
It is evident that the efficiency of preventive maintenance using PASS is improved
by nearly 20% compared with conditional maintenance. It is clear from Fig. 7.8 that
the time between two sequential on–ground maintenance sessions is significantly
increased by preventive maintenance, which infers a significant reduction in main-
tenance costs.
Let T1 and T2 be the lifespan of the system under preventive maintenance and
conditional maintenance, respectively. Then the value of y in Eq. (7.18) can be used
to assess how much gain in reliability is created by the adoption of preventive
maintenance relative to a conditional maintenance scheme.
Summary and Conclusions
• The principle of active system control (PASC) is analysed in terms of condi-

tional and preventive maintenance in order to derive a gain in reliability of the
aircraft during its life.
• There is an opportunity to improve the controllability, reliability and efficiency
of aircraft and flight operations.
• The real-time analysis of operational reliability during a flight can be used to
significantly improve safety management schemes. It provides the opportunity
for unavoidable monitoring of the fault condition of an aircraft and a strong
contribution to the crucial “fly/no fly” decision made before every flight.
• From a theoretical point of view, the operational reliability of a typical aircraft
can be improved on the order of 20% over its life-cycle. This would result in a
significant reduction in the cost of maintenance, higher availability for opera-
tional use and a reduction in the likelihood of incidents and accidents in the most
risk-prone phases of flight.
• The PASC should be used as a process in the design of aircraft to improve
operational reliability “by design.” In other words, by continuously analysing
the emerging design for fault dependence with a view toward improving oper-
ational safety, the design itself will become more safety resilient. This “intrin-
sic” safety management could be just as important as the “additive” efficiency
and safety management achieved by incorporating an “active system control”–
based monitoring.
• One of the immediate next steps for further development of the method of ASC
is analysis of the discussion of cost efficiency in comparison with preventive
maintenance while addressing an aspect of locality, that is, how much of the
References 207
workshop location and its availability can impact on overall efficiency of aircraft
of vehicle.
• The availability of an ASC supported by hardware and system software on-board
an aircraft opens the way for tighter regulation of their operation and the
introduction of insurance-based incentives to improve operational usage and
regular maintenance.
References
1. Birolini A (2016) Reliability engineering, 8th edn. Springer Verlag, Heildelberg/New York/
Dordrecht/London. ISBN 978-3-662-03792-8
2. http://www2.lns.mit.edu/fisherp/Appendix-F.txt
3. Schagaev I, Carbone JN (2013) Principle of active condition control: impact analysis.
In: Suh S, Tanik U, Carbone J, Eroglu A (eds) Applied cyber-physical systems. Springer,
New York
4. CAD 418 condition monitored maintenance: an explanatory handbook, 2012. www.cad.gov.
hk/english/pdf/CAD418.pdf
5. Galie T, Roemer M, Gregory M, Kacprzynski J, Byington C (2004) Prognostic enhancements
to diagnostic systems for improved condition-based maintenance. http://www.dtic.mil/dtic/tr/
fulltext/u2/a455198.pdf
6. Huang Gary K, Lin Kuen Y A method for reliability assessment of aircraft structures subject to
accidental damage. https://depts.washington.edu/amtas/publications/presentations/Lin_
AIAA_4-05.pdf
7. Kingsley-Jones M (2005) Reliability lessons learned. In-service report: A340–500/600 flight
international, 3–9 May 2005, pp 34–39
8. Middleton DH (1993) Aircraft maintenance management part 3. Aircr Eng Aerosp Technol 65
(2):6–9. doi:10.1108/eb037340, Publisher: MCB UP Ltd
9. Kirk B, Schagaev I (2007) Applying the principle of active safety to aviation EUCASS 2nd
European conference for aerospace sciences, Brussels. http://www.vki.ac.be/eucass2007/
index.html. Accessed 29 Jan 2008.
10. Bukov V, Kirk B, Schagaev I (2007) Analytical synthesis of aircraft control law EUCASS 2nd
European conference for aerospace sciences, Brussels. http://www.vki.ac.be/eucass2007/
index.html. Accessed 29 Jan 2008.
11. www.academia.edu/15742326/Active_system_control_for_safety_maintenance_efficiency
12. General operating and flight rules Canadian aviation regulations 2009–2 standard 625 appendix
B maintenance schedules. www.tc.gc.ca/civilaviation/regserv/affairs/cars/part6/standards/
a625b.htm
13. Summerfield JR A model for evaluating fleets of transport aircraft, Logistics Department,
RAND Corp 12 Jan 1960. http://www.rand.org/pubs/papers/2009/P1882.pdf
14. Bole B et al (2013) SIL/HIL replication of electric aircraft powertrain dynamics and inner-loop
control for V&V of system health management routines. In: Annual conference of the
prognostics and health management society, New Orleans, LA, October 2013
15. Schagaev I (1998) Concept of dynamic safety for aviation ISSC 1998, Seattle. https://www.
academia.edu/7119860/The_Concept_of_Dynamic_Safety
16. http://aviationweek.com/commercial-aviation/a380-wing-rib-feet-work-drags-late-2015
17. http://www.academia.edu/26459013/Russian_MAKS_2007_astec_210807f
18. https://www.youtube.com/watch?v¼QBhZQX2jLWk
19. Schagaev I, Overtoon L (1999) Active safety system for general aviation. In: Proceedings of
17th international system safety conference, Orlando, FL. http://www.system-safety.org/Con
ference99/Orlando99.htm. Accessed 29 Jan 2008
20. Method and apparatus for active system safety of active system safety. UK patent GB
0707057.6
21. http://www.flightglobalevents.com/FSS16/flight-safety
22. Schagaev IV, Sogomonyan ES (1998) Hardware and software for fault-tolerant computing
systems. Autom Remote Control 49(2):129–151; translation from Avtom.Telemekh (1988),
2:3–39
23. http://www.army-technology.com/features/feature97110/
24. Farrar C, Lieven N Damage prognosis: the future of structural health monitoring. http://rsta.
royalsocietypublishing.org/content/365/1851/623
25. Prognostic performance metrics. https://ti.arc.nasa.gov/publications/2649/download/
26. Willcox K et al (2014) Multifidelity DDDAS methods with application to a self-aware
aerospace vehicle. Proc Comput Sci 29:1182–1192
Chapter 8
Flight Mode Concept and Realisation
Introduction
This chapter describes how the principle of active system control (PASC) can be
applied to control the flight of an aircraft. As explained in previous chapters, we
consider an aircraft to be an aggregation of three matrices of dependencies:
information (input variables), state dependencies (the states we recognise as
being important for the behaviour of a system) and components (or elements),
denoted as Di, Ds and De, respectively.
Therefore, an operational aircraft’s function can be characterised by these three
matrixes:
Da≔ < Di, Ds, De >
The information vector that is the input to the systems, in the form of current
signals and or historic data, can be considered as a vector of independent variables,
and so should be analysed as a group of dependent functions. Variables over time
are functions; their dependencies are not defined, recognised and vary, as has been
shown in [1, 2].
In turn, state dependencies of an aircraft can be considered for the purpose of this
chapter as a matrix of flight modes and their mutual dependency; see also the
chapter on aircraft reliability in this book), the papers in [3, 4] and the patent in [5].
Flight modes occur in a sequence, and by monitoring aircraft conditions (e.g.,
related to state change), they can be extremely informative and contribute to
controlling the aircraft safely and efficiently. Additionally, monitoring elements
of De helps us to understand where we really are in terms of flight modes, even in
the presence of elements that are partially working or faulty sensors. Cases exists in
which poor design has costs hundreds of lives. Some examples are presented in
[6, 7, 10, 12] another chapter.

210 8 Flight Mode Concept and Realisation
In this chapter we consider an aircraft as a system, assuming the following:

1. The data and content of the matrix of elements De is correct:
PðDeÞ ¼ true
that is, no faults inside were manifested or misled us while defining a flight mode
2. The input data are also correct and are available in a timely way:
PðDiÞ ¼ true
When these two assumptions are valid, we can create an algorithm of detection
for the flight mode and track the flight mode required by tuning the functioning of
an aircraft to achieve the desired flight in the longer term.
So why is flight mode detection and tracking its state changes so important? The
main reasons include the following:
• First, knowing that the vehicle (or aircraft in our case) has reached a particular
mode and that we are using it more safely and efficiently, for example, it may be
possible to save on fuel costs.
• Second, timely detection of changes in the flight mode, especially when it drifts
toward a potentially uncontrollable mode or approaches a danger zone (see more
in the chapter “Principle of Active System Control: Implementation”) can
improve safety.
• Third, a deliberate attempt by the crew or a terrorist to change a flight mode, as
was done more than 20 years ago [6], as well as in 2015 [7, 8], could be avoided
and, again, foolproof operation could be affirmed.
The last point indicates that at present neither the aircraft designers nor the pilot
is fully aware that setting two keys or switches inside the cabin might critically
change the reality outside it.
Goals and Objectives of the Chapter
This chapter has four main goals. It introduces the concept of flight modes, which are
used to partition the control task by defining a series of distinct contexts of flight.
This makes it possible to adapt the ASC to meet the specific needs of the flight and
also to track the desired dynamic flow of the flight in terms of these flight modes. In
this way, overall control of the flight can be systematically adjusted to the specific
condition and characteristic of the aircraft in each flight mode in a refined way.
Figure 8.1 illustrates the dynamic progress of a typical flight and the most
common flight modes. Flight mode transitions during the flight create a “portrait”
of flight as a whole. Our objective is, of course, to manage the progress of the
intended flight efficiently and safely.
Introduction 211
Fig. 8.1 An example of flight modes
As mentioned above:
• We indicate how knowledge of the dynamically changing flight modes can be
used to tune the overall influence of ASC on an aircraft’s control.
• The context of each flight mode can then be used to activate specific control and
recovery matrices (e.g., the group of actions that might react to potentially
unsafe or dangerous flight developments of the PASC).
• We enable dynamically tuning the control system to the current flight situation.
A key point here is that flight mode analysis and detection are continuous; it is
not a “target state” that the aircraft control system then strives to achieve
(a disastrous mistake already implemented in many current commercial aircraft
control systems). It is the current flight context of the aircraft. The pilot, or
autopilot, flies the plane based on the intent (destination, course, flight plan, etc.).
The key challenge is how to monitor and assess the flight in terms of its actual
modes as they happen, and make available the most appropriate control responses
to maintain safety, performance and efficiency.
The second goal is to show how the PASC can be applied in a practical way. In
this case, the flight modes are represented as states; within each state the operating
conditions are continuously monitored and assessed, and if the boundary condition
(s) for changing from one flight mode (state) to another are met, then the control
algorithm for the new states context takes over.
The flight modes, boundary conditions and algorithms will be represented here
in XML as a declarative specification for the following main reasons:
1. It is desirable that the main structure of the software should remain the same,
even though the flight modes, boundaries and control rules may change from
aircraft to aircraft, or even different models of the same aircraft.
2. The declarative form of the flight mode model can be checked independently of
its normal activating software. It is in effect a flight model specification and it is
desirable that it can be checked independently of the control system
implementations, which could involve different computers in different aircraft,
or even multiple diverse implementations of hardware and/or software in the
same aircraft.
3. An actual implementation is described and reviewed, including the stages of its
development using Flight Simulator (Microsoft) to verify the flight mode model
at low cost and low risk and then by real flight testing of the identical flight mode
model
The Objectives of Implementation
The objectives of implanting ASC are to:

• Explain how the control of a flight can be partitioned based on the specific design
characteristics of the aircraft
• Introduce the idea of a separate state model that partitions the operational use of
the aircraft into distinct control contexts called flight modes and the boundary
conditions between them
• Describe the information processing model of the aircraft, embedding flight
mode detection and monitoring
• Separate the structure of the flight mode model from the software structure of the
software implementation by using XML as a declarative specification technique
• Describe a simple computing architecture capable of supporting the dynamic
activation of the model to monitor the context of the aircraft in flight and to
enable dynamic selection of the currently appropriate control algorithms
• Indicate future research directions for dynamic evolution of flight mode models
and operation interpretation of them using active system control
In short, this chapter introduces the concept of flight mode models as part of the
ASC approach and describes some ways to use them. A similar scheme can be used
in other application domains: the key is to partition the application state space as the
system journeys through its dynamic operation.
The Flight Mode Model 213
The Flight Mode Model
Flight Mode Definitions
The flight mode model is illustrated in more detail in Fig. 8.2. Each oval shape
represents the scope of a specific flight mode, and its circumference represents the
boundary. Each arrow represents a transition from one flight mode to another. The
transition only occurs when the required conditions have been fulfilled.
Within the scope of the flight mode detection we need to provide a continuous
evaluation of sensor inputs and internal contexts of aircraft (Di and De matrixes)
and when all criteria for a change of flight mode have been met the transition is
instigated, which is reflected in the D’s.
In order to clarify the diagram, transition vertices are coloured to indicate
different classes of the nature of the transitions.
In the example, the normal sequence of flight would transition between the flight
modes in a clockwise direction shown in blue colour arrows:
Cruise
d e
Controlled
Climb Descent
Uncontrolled
Descent
f
c
Accident
Take off Landing
b g
Taxi Out Taxi In
a BASE h
Fig. 8.2 A flight mode model

Base, TaxiOut, Take-off Ground, Take-off–Airborne (shown as Take Off), Climb, Cruise,
Controlled Descent, Landing, Taxi In, Base.
The flight modes “uncontrolled descent” and “air accident” are “unforeseen”
states and, ideally, never occur in practice. Nevertheless, there might be control
algorithms that could mitigate the potential loss of control. The kinds of events that
might force these modes are bird strikes (in the jet engine), fuel blockages, terrorist
interventions and collision avoidance procedures.
The line colouring conventions used for transitions are as follows:
– Thick blue lines denote normal transitions between flight modes.
– Light grey lines denote unusual sequences of transitions, such as a “touch down
landing followed immediately by a take-off.”
– Thinner (red) lines denote emergency and emergency recovery situations.
To connect with other chapters: in the “Reliability” chapter flight modes were
considered as a set {f1, f2,..., fy}, where y is the number of possible functional flight
modes of the aircraft.
Denote the set of the modes as FM:
FM ¼ ff 1; f 2; . . . ; fvg, ð8:1Þ
For most known classifications of flight phases, y ¼ 10 and the elements of the
set FM are as follows:
f1 – pre-flight/post-flight maintenance
f2 – “push-back” or “taxi”
f3 – “take-off ground”
f4 – take-off/airborne
f5 – climbing
f6 – cruise (in flight)
f7 – descent
f8 – approach/landing
f9 – taxi-in
f10 – “lock-down”/base
For modelling and control of flight modes, each change from one flight mode to
another is assumed to be instantaneous, although in reality—as will be shown
later—this is far from the truth.
The set of flight modes FM contains two subsets: main Fm and supportive Fs.
The object (aircraft) itself is in the subset of the main modes Fm during flight: take-
off, climbing, cruising, descending, and landing; it is in Fs when the preparatory or
post-flight procedures take place. It is assumed that an object starts from the
preparatory state before it initiates the sequence of the main modes in fj2 Fm. In
terms of the flight mode phases listed above:
Fm ¼ ff 3; f 4; f 5; f 6; f 7; f 8g and Fs ¼ ff 1; f 2; f 3; f 8; f 9; f 10g: ð8:2Þ

Height
Cruise Phase is Minimal
Climb Controlled Descent
1000 ft
Time
Fig. 8.3 Flight mode change with minimal cruise
Height
Single Period of Cruise
Climb Controlled Descent
1000 ft
Time
Fig. 8.4 Flight mode change with single period of cruise
Multiple Phases of Climb,

Height Cruise and Controlled
Descent
1000 ft
Fig. 8.5 Flight with several phases of cruise, climb and descent
Potentially possible sequences of flight mode changes are presented in Figs. 8.3,
8.4, and 8.5.
A change to a new flight phase implicitly defines a set of possible sequences,
dependencies and recovery procedures. In turn, determining the flight mode and the
flight mode sequence is an important issue as it adds on to monitoring the behaviour

of an aircraft as a whole.
In addition, Figs. 8.4 and 8.5 illustrate a problem of flight mode determination.
The simplest case of flight mode change is illustrated in Fig. 8.3, which refers to
a “legitimate” first flight when an aircraft reaches cruise speed and altitude for a
short period of time (which is widely used during the testing of new aircraft) and
also to short flights typical for general aviation, such as air taxis.
Figure 8.4 illustrates a standard flight for CA aircraft without any deviation.
Here all flight modes are easily defined and might be successfully determined and
predicted.
Further, Fig. 8.5 illustrates several possible changes of flight modes when
cruising is allowed at several heights, which is typical for flights when external
conditions such as weather, mountains and other external factors are applied.
A similar pattern of flight mode sequence applies to GA aircraft, cruise missiles
and unmanned autonomous change vehicles (UAV). All these flight mode
sequences might be used to test the algorithm of flight mode determination.
The simple ASC application scheme works considering the aircraft and its
environment as a set of element models united by the dependency matrix. Flight
modes as described in previous chapters and briefly presented here define aircraft
behaviour in terms of its states, which characterise a flight and the conditions,
which trigger the change from one state to another.
Although the state diagram of the aircraft’s flight modes is presented in Fig. 8.2,
up to now states have been just named without elaboration or explanation of the
combinations of conditions relating to each state and the transition conditions to
change from one state (flight mode) to another. Here are some typical flight mode
change conditions relative to flight modes experienced in GA:
• Taxi-out: When the speed of the aircraft V lies in the range 0 < V < 25 knots
(and no previous flight mode has been recorded as part of this specific flight)
• Take-off: When the speed of the aircraft V is greater than 25 knots and the
previous flight mode was “Taxi- out.”
• Climb: When the speed of the aircraft V is greater than 25 knots, the barometric
altitude is greater than 1000 ft, the rate of climb (i.e., the vertical speed) is
positive and greater than +100 ft/min and the previous flight mode was “Take-
off”
• Cruise: When the rate of climb of the aircraft is less than +100 ft/min but greater
than 100 ft/min, and the previous flight mode was “Climb”
• Descent: When the rate of climb of the aircraft is negative but less than 100 ft/
min and the previous flight mode was either “Climb” or “Cruise”
• Landing: When the speed of the aircraft V is less than the minimum landing
speed, VMaxLanding (aircraft specific), and the rate of climb is negative but greater
than 100 ft/min (for say 3 seconds) and the previous flight mode was either
“Climb,” “Cruise” or “Descent”
• Taxi-in: When the speed of the aircraft V lies in the range 0 < V < 25 knots and
the previous flight mode was “Landing”
The Flight Mode Detection Algorithms
A simple algorithm for flight phase determination is proposed below, based on the
analysis of incoming flight data in real time. This algorithm describes the determi-
nation of flight phases using current flight data:
1. Flight mode ¼ Before take-off.
2. Measure and record the barometric pressure datum at local zero altitude.
3. Wait until the ground speed increases above the maximum taxi speed VMaxTaxi.
4. When current speed > VMaxTaxi then flight mode ¼ Take-off.
5. Measure and record the barometric pressure datum at this zero altitude.
6. When height is HMinTake-off relative to the datum then flight mode ¼ cruise.
When the vertical descent rate is negative and exceeds the vertical rate threshold
HMaxLanding and the air speed is below the landing speed threshold VMaxLanding
then flight mode ¼ landing. (The vertical rate value must be determined from an
interpolation of the barometric altitude values over a certain time span (a few
seconds) to avoid unintended triggering due to measurement spikes).
7. When the ground speed falls below the taxi speed threshold, the flight mode ¼
end of flight.
For an initial trial scheme a simplified flight mode scheme can be introduced,
using three main phases, a generalisation of previously mentioned seven phases:
take-off, cruise, landing.
The data values received from available sensors are filtered using linear inter-
polation over the previous 5 seconds; the algorithm of flight determination is
presented in Fig. 8.6.
During operation the predicates are continuously evaluated—in the example
here, once per major cycle of flight data acquisition—and then if a predicate
becomes true, the matrix is evaluated, the action is executed and the subsequent
state is adopted (note that it might quite possibly be the same state, i.e., no change).
In practice this scheme can be represented as an array of records each with two
fields: one a reference to the action procedure (using a procedure variable) and the
other an enumeration of the state (a named constant value).
The advantage of the matrix representation is that all states and all transitions are
covered in all combinations (their Cartesian product). In practice, such matrices are
usually sparsely populated; however, this notation is excellent in the design state as
it encourages an exhaustive solution and makes test coverage clearly visible. Note
that the ordering of evaluation of the transition predicates effectively prioritises
their relative significance in the circumstances where more than one predicate
might evaluate to true at any given time. So, careful consideration must be given
to this point as it may affect the outcome.
Another representation of the flight mode change (i.e., state transition) diagram
is as a narrative algorithm. Here there is a main loop, which evaluates all the state
machines, one after the other. Each element model has its own state machine
encapsulated in a procedure, which is repeatedly called to perform the evaluation.
(* Determine the current FlightMode of the aircraft *)
(* configure key parameters for this specific aircraft *)

vMaxTaxi := 25.0; (* knots *)
hMinTakeoff := 1000.0; (* feet *)
vMaxLanding := 100.0; (* knots *)
dhMaxLanding := 50.0; (* feet *)
(* Get current data values and calculate derivative values *)

v := speed.val[speed.pos]; (* current speed *)
dv := speed.slope; (* speed gradient over 5 seconds (=5 samples) *)
h := alt.val[alt.pos]; (* current height *)
dh := alt.slope; (* height gradient over 5 seconds *)
...
mode:=invalid; (* initialisation *)
...
(* Determine current Flight Mode *)
IF mode = invalid THEN
IF v < vMaxTaxi
THEN mode := preflight;
ELSE (* mode cannot be determined *)
Log.Str( "cannot determine flight mode, assuming cruise for now"
);
Log.Ln; mode := cruise;
END;
ELSIF mode IN supportive THEN
(* all modes on the ground *)
baseAlt := h; (* determine base altitude *)
IF v > vMaxTaxi THEN mode := takeoff;
ELSIF mode = takeoff THEN
IF h > hMinTakeoff THEN
mode := cruise; END;
ELSIF mode = cruise THEN
IF (dh < dhMaxLanding) & (v < vMaxLanding) THEN
mode := landing;
END;
ELSIF mode = landing THEN
IF v <= vMaxTaxi THEN mode := taxiin; END;
END;
Fig. 8.6 The algorithm of flight mode determination
In this case, the predicate evaluation and the resulting actions are combined in a
narrative text style. The general form in a modular style language is shown in
Fig. 8.7.
The advantage of this format is that the algorithm is clear and readable and the
relationships between states are represented in a sequential narrative form. Note
that the priority of predicates evaluation is important within each case evaluation; it
is embodied in the ordering of the IF/ELSIF statements which evaluate the predi-
cates sequentially.
(* The main program*)

LOOP
AWAIT the next 125ms cycle start;
Read in all the Flight Data;
LOOP
ModelAircraftElement;
ModelPropulsionElement;
ModelLiftElement;
(* Model other elements*)
Evaluate modelling results;
END
END
MODULE AircraftSTD;
TYPE State = (Stop, TaxiOut, ...); (* define state names *)
VAR currentState: State; (*define the state variable *)
PROCEDURE ModelAircraftElement (old : State, VAR new : state);

BEGIN
new := old; (* in case no predicates are true *)
CASE old OF (* depending on current state chose narrative*)
Stop: (*enumerate all predicates for transition from Stop state*)
IF speed > 0.5 THEN action; new := TaxiOut
ELSIF speed < 0.0 THEN action; new := Accident
END
TaxiOut: (* enumerate all predicates ... *)
IF (* predicate *) THEN action; new := TakeOff;
ELSIF (* predicate *) THEN action; new := Stop; (* and so on *)
END
END ModelAircraftElement;
BEGIN (* AircraftSTD *)
CurrentState := Stop; (* initialise this state machine *)
END AircraftSTD;
Fig. 8.7 Narrative algorithm of flight mode determination
There is a similar effect at the higher level where the dependence of order while
evaluating the state machines may be important if one state machine is dependent
on the state of another state machine during its evaluation. For example, the aircraft
element model might be evaluated first because it determines the flight mode state;
that state may then characterise the evaluation of other models, for example, the
propulsion element.
From a design viewpoint it is good practice to localise all state variables;
however, in an application like this, where efficiency is of prime concern, the
judicious use of globally shared data can be highly advantageous. If this is done,
then careful commenting of the program is recommended. The simplified algorithm
for flight mode detection implemented as a demonstration prototype is presented
below. A more detailed algorithm is presented in the Appendix.
The importance of the correctness of this algorithm is clearly explained in the
chapter about PASC: it enables the possibility of predicting a potential deviation of
parameters that might lead in the end to stalling.
Visualisation of Flight Mode
Presentation of Advice to the Flight Crew
The set of fault indications and safety advice should be taken into account and
formatted for presentation by the human machine interface (HMI) to the pilot.
Communication needs to be clear, concise, precise, relevant, practical, timely and
easy to assimilate, especially taking into account that the most important warnings
take place during an emergency.
The pilot observes the advice and uses judgement and skill to decide how best to
adapt the control of the aircraft given the current perception of the flight context and
the safety advice provided. The pilot’s reaction to the advice, via the flight control
system, closes the safety control loop on-board the aircraft in real time, depending,
of course, on the response time and appropriateness of the reaction of the pilot.
There are two kinds of indications envisaged:
1. A simple fly/no-fly indicator to warn the flight and/or ground crew that the
aircraft is not considered airworthy due to a current or impending fault (set)
which might render it unsafe.
2. Advice to the flight crew in the event that a fault is diagnosed during flight,
which would impact the safety of the aircraft. It is envisaged that this informa-
tion would relate to safety, that is, the avoidance of harm occurring during the
rest of the flight.
The possibility for a variety of warnings about regular and especially dangerous
changes of flight mode are inherent in the design, for example, the background
colour of the display may change from black to green to yellow to red as the overall
importance of the warnings escalates.
Additionally, as another option, the text and audio messages might be shown and
broadcast on a separate display or separate audio channels. The outer ring of the
display might also limit information specific to the current flight mode. For exam-
ple, in the “climb” flight mode, the pilot might suggest that the rate of climb limits
could define a corridor with “white/amber/red” indicators on the display with
corridor limits of 2500 for white, 2600 for amber and 2700 for red.
An experimental “flight mode aware” display is shown in Fig. 8.7. The dial
illustrates two different flight mode contexts as indicated by the “advice” message
from the flight mode “detector” (Fig. 8.8).
The aim here is to offer reliable information without too much delay, so that it is,
from the pilot’s point of view, credible, immediate and relevant.
Information Processing of Flight Data Including Flight Mode 221
Fig. 8.8 Representation of threshold limits for pilot warnings
Information Processing of Flight Data Including

Flight Mode
Flight mode detector is not the only system required for aircraft control. Informa-
tion system general structure simplified for the purpose of highlighting novelty of
active system control and flight mode management is shown on Fig. 8.9.
The purpose of the system is to improve the control and safety of a flight either
by advising against starting a new flight or by providing salient advice during the
flight in the event of a fault developing that might compromise operational safety.
The information processing involved in the loop of flight monitoring is shown in
Fig. 8.9. It represents an abstract view of the top-level implementation of the ASC
implementation within the aircraft during flight, in real time.
Note also that the system is continually active, with the same analysis, before
take-off, and so may offer an “unsafe to fly” indication to the ground and/or flight
crew. In this case it would be unsafe to attempt a flight at all.
The data flows and processing are shown in the data flow diagram in Fig. 8.9.
The main processes are labelled P1 to P5 and the main data flows are represented by
the arrows.
The aircraft contains a number of elements, a flight control system and a flight
data interface (FDI). Flight data is read from the FDI by the capture flight data
process P1 on a regular basis, in this case eight times per second, and is stored in the
flight data memory which is typically implemented using, for this illustration, a
Flash RAM memory, which contains a data frame for each sample period holding
all the sample values read each time.
The current operational flight mode is identified by the “determine flight mode
process” P2 based on the flight mode predicates; it is also stored in the flight data
memory.
The Flight /
Ground Crew
Aircraft Flight Control

Panel/Browser Fault indication
System Flight Safety advice Fly / No Fly advice
Element, element, element...
Flight Mode
Predicates
Flight Data Interface
P5
P2 Presentation to
P1 Current
Determine Pilot/Crew
Capture Flight Mode
Flight Mode
Flight Data
8 Hz 8 Hz
Flight Data Memory Action Advice
(fault and safety)
1. History
2. Data d1, d2, d3,
Flight Mode,
Element Models Time Stamp...
and Predicates 3. Free space
for Flight Modes
P4
P3 Determine
Evaluate Recovery
Discrepancy
Fault
Most Recovery Matrix
Dependency contributory and Safety Rules
Matrix of element
Elements
Fig. 8.9 ACS information processing
The “evaluate discrepancy” process P3 then uses the element models against the
current and previous flight data memory values using the element model predicates
and models for the current flight mode. If a discrepancy is found, then the fault
dependency matrix is also evaluated to determine the element most likely to be the
cause.
Now the determine recovery process P4 is used to produce the action advice
based on the recovery matrix, which embodies the safety rules and possible
response actions.
The presentation process P5 now takes the advice and the current flight mode
and presents the information to the crew via the panel. Implementationwise the data
format used might be, for example, internally exploited by HTML in combination
with the serial link internet protocol (SLIP) so that a standard Internet-style browser
can be used as a graphic display device; this supports both testing and flexible
integration with other instrumentation in the aircraft.
This approach was expedient for the prototype that the authors were involved in
developing; however, in a production-quality system a dedicated user interface
would be provided so that both hardware and software could be verified. There may
also be a fault indication and alarm device on the aircraft panel warning the pilot not
to take off, or to land as quickly as possible if already in flight.
Finally, the pilot(s) receives the safety information as explained before and
responds to it based on his or her perception of the overall flight situation.
Information Processing of Flight Data Including Flight Mode 223
Flight Mode Detector
The flight mode is tracked in real time as described in the previous sections of this
chapter and in the Appendix containing the flight mode model specification in an
XML format. In a production system, such flexibility of configuration would need
to be carefully protected to conserve its overall integrity, versioning and security,
with access controls to prevent malicious tampering with the specification.
The element models are required to characterise their parameter limit values and
thus improve the discrimination of fault detection and enable optimal control use of
the flight modes.
Real-Time Diagnosis and Prognosis
The evaluation of the current (diagnosis) and future (prognosis) faults in the aircraft
is performed by P3; this takes data from the flight data matrix (FDM) and:
1. Evaluates the fault status of each of the aircraft’s elements based on a set of
predicates; then
2. For any detected fault the fault dependency matrix is evaluated to assess
consequential contributions to other fault conditions using
3. A set of rules (packaged experience provided by experts) to guide and charac-
terise the evaluation
The system is configured initially by downloading values into the dependency
and recovery matrices based on the fault dependencies and recovery strategies
needed for the particular aircraft.
Determination of Response
The response to the fault/risk profile is generated by P4 to determine how best to

conserve or improve safety by considering the whole fault/risk profile by:
• Mitigation of the effects of a set of current faults
• Avoiding or preventing escalation of current faults from developing into future
errors or failures
• Preventing the likelihood of occurrence of the pending fault, or mitigating the
severity of its effect
• Addressing fault/risk combinations by priority (i.e., higher risks first)
This involves evaluating the fault/risk profile from P3 based on so-called
“recovery” methods and (possibly in the future) a set of rules, the flight mode
characterising the overall strategy.
The result of this evaluation is an advice profile aimed at conserving or improv-

ing the safety of flight, that is, a set of information and recommended actions for the
pilot. There are two kinds of information resulting from this analysis:
1. Fault advice, for example, major fault detected, aircraft not airworthy
2. Consequential safety advice based on a safety analysis of the consequences of
faults for example, fuel leak in the left engine, shut down engine if possible
(to avert a fire)
The safety advice referred to above is generated from a safety analysis of the
consequences of a fault. This will be specific for each type of aircraft, hence the
need for customisation.
Configurability of the System
The purpose of system configuration is to make it possible to have a single

“standard” software package, which is then characterised for each type of plane
(for evaluation algorithms) and particular installation by the configuration meta
data. This avoids the possibility that the software itself would need to be adapted
and re-verified for each different installation, as this would not be economical and
too time-consuming.
The configuration data is shown in Fig. 8.9 in the borderless boxes that are light
yellow.
The configurable data sets are:
1. Flight mode determination rules for P2
2. Predicates for each element model for each flight mode for P3
3. Dependency matrix content for P3
4. Recovery matrix content and safety actions (rules) for P4
The configuration should be both machine- and human-readable to support
verification so an XML format has been used to make development more flexible.
In effect, XML provides a format that can be both human-readable as a specification
and machine-interpretable as an algorithm.
A Trial Architecture for Flight Mode Detection
To support the demonstration of ASC functioning in the context of flight mode

monitoring and control, a hardware and software support system in needed. This
system should also be able to process dependency and a recovery matrix generated
for a sample aircraft.
A Trial Architecture for Flight Mode Detection 225
The Avionics System: System Block Diagram
A block diagram of the implementation within the aircraft is illustrated in Fig. 8.10.
The upper part of the diagram shows the existing sensors, the flight control system,
the control system actuators and the human–machine interface (HMI) indicators for
the crew.
Typically, sensors might be for altitude, air speed (in three dimensions), heading,
position, engine revs/sec, etc. The flight control system (FCS) processes this sensor
data and provides information via the display to the crew. It also monitors actuators
such as engine throttle, brakes, landing gear, etc.
The flight crew use the FCS and their own experience, skills and judgement to
make decisions about how best to fly the aircraft. The key parts of the system are:
Existing sensors Existing actuators
Flight
Control System
Aircraft
Flight Data
Interface
Flight System Interface
InterfaceIndicators
The Flight
Crew
The
Aircraft
Crew Display Interface
Flight & PASC

Flight Data Evaluation
Interface Unit Power
Supply
Additional sensors
(option) Flight Data
Memory
Data transfer
via physical
medium or via
transmission
Data Storage
Fig. 8.10 Block diagram of an aircraft system with ASC

I. The aircraft’s flight data interface (FDI), which provides the physical interface
with the data sensors in the aircraft. Its purpose is to manage the variation
normally found in GA aircraft. It samples the data and then presents the data
values in a standard form to the active safety monitor’s own FDI and the MASS
system which:
– Monitors the data stream provided by the aircraft’s FDI and its own sensors
(optionally)
– Applies the PASS processing to both short-term and longer-term data
– Stores the relevant data in the flight data memory (FDM)
– Provides an indication of safety information to the flight crew
II. Flight data memory (FDM), which retains the flight data during each flight and
also over the lifespan of the aircraft’s use. This must be resilient enough to
survive a crash, be locatable and, of course, ultra-reliable. In effect, it is the next
generation of a flight data recorder.
It is important to note that it is the responsibility of the flight crew to monitor the
display indicator(s) and to act on them either before the flight (by simply not using
the aircraft if it is found to be in an unsafe state) or during flight (via the flight
control system). In a typical product the system would interface directly with the
flight control system, and thus become an extension of it.
The flight data memory stores data collected during each flight and accumulates
a condensed version of it over the life of the aircraft. It is somewhat similar to a
flight data recorder; however, it is anticipated that further safety related data/
information will be retrieved from it.
The information in the FDM is physically stored in solid-state memory chips
within a housing that can survive a crash (possibly including a resulting fire). Its
data can be analysed between flights and/or after a crash. There is also the potential
to dynamically download data during a flight by satellite, SMS messages or radio
link, but this is outside the scope of this work.
Flight Data Memory
Data is captured from the aircraft’s sensors and avionics, via the FDI on a periodic
basis by P1 and stored in the FDM. The frequency of the data captures will initially
be 8 Hz, this being an established standard for flight recorders.
However, when real data is available, it will be analysed to determine the
frequency required in order to be able to extract the required information from
the data. In this way it will be possible to optimise the amount of relevant data that
can be stored in the limited FDM. The FDM is, of course, finite in size and its use
must be managed. The design in the prototype has three zones:
A Trial Architecture for Flight Mode Detection 227
1. The current data record being written.

2. A file in the form of a circular buffer containing the history of previous data
records; after all the available records in the buffer have been written, then the
next record is overwritten on the oldest stored data record in the buffer.
3. A file in the form of a circular buffer containing the history of previous flight
records, after all the available records in the buffer have been written, then the
next record is overwritten on the oldest stored flight record in the buffer.
Each data record includes a time stamp, an indication of the current flight mode
and enough metadata to enable rebuilding of the whole file system from individual
records. A further issue when using Flash technology for the memory chips is that
each memory cell can only be reliably written to a limited number of times
(typically on the order of 109). This is not a problem for normal operation as long
as an “anti-wear”’ algorithm is used to ensure that memory writes are evenly
distributed across memory blocks on each chip.
Software Architecture and Partitioning
At the top level the software is partitioned into three closely coupled collections of
modules as shown in Fig. 8.11:
• Operating system core modules [9]
• Framework modules
• Application modules
Each component or module (represented by a box) implements some specific
functional domain and exports an abstract interface. Upper-level modules may use
or import (interfaces of) lower level modules.
The run-time core corresponds to the actual “operating system.” It is responsible
for the management of resources such as the processor, volatile memory, flight data
memory and I/O ports. In addition, it provides file system functionality, low-level
recovery procedures, and system and component initialisation.
The run-time core is a set of hierarchically structured components, close to
hardware, which are allocated in the lower levels, the lowest level being the
hardware abstraction layer (HAL). Its purpose is to improve the system’s portability
by hiding platform-specific details. Other low-level components are the system boot
loader and the floating-point emulator, if hardware applied does not have a special
processor for this kind of calculations.
The device drivers are allocated on top of a HAL that serves to hide the
idiosyncrasies of a particular hardware platform from the rest of the software.
The drivers use the HAL abstraction to communicate with hardware devices.
On the next higher level we find the I/O system whose responsibility is
standardising input/output programming. The memory management system man-
ages the system heap. It provides routines to allocate and free memory blocks.
OS Modules Application Modules
Fault Advice
OS Display
Evaluator Evaluator
Boot Flight Data PASS

Module Loader
Loader Management Algorithms
I/O Logger Element Flight Mode

Subsystem Tracer Model(s) Model
Lifecycle Data Flight Data

TCP/IP FDM Scanner
Management Capture
ROM File Flash File

System System Framework Modules
Drivers Fault Eval Advice Eval

Gyro, FLASH, UART … Socket Socket
Task Memory Element XML

Scheduler Manager Sockets Utilities
Hardware Floating
Abstraction Point Statistics Compression
Layer Emulation Package Utilities
Math CRC32
Utilities Utilities
Fig. 8.11 Software partitioning and module structure
However, the run-time core does not implement automatic garbage collection
because it is de facto incompatible with hard real-time constraints. Instead, a
specific programming discipline is used to avoid garbage collection, that is, instan-
tiation of all used objects at initialisation time.
Support for several protocols and other services including, for example a ROM
file system, a flash RAM–based file system and TCP/IP are included. A linking
module loader supports dynamic loading of software components.
The system scheduler is responsible for distributing the processor resource
(time) among the different tasks according to real-time constraints. There is also
a liveliness checker (“watchdog”) and a logging and tracing facility for debugging
purposes. The top-level component provides the human machine interface
functionality.
Using Flight Modes to Tune Flight Performance and Safety 229
The application framework consists of a plug-in mechanism for flight data

analysis algorithms and a software library provides support modules for mathemat-
ics and statistics, string handling and XML [10] document management.
The application itself consists basically of an implementation of the ASC
algorithm—in this example, using the matrix of aircraft states created around flight
modes. It is responsible for analysing the different streams of sensor data and for
identifying potentially hazardous situations. Several logical processes (see Fig. 8.9)
are required for functions such as recording the flight data and giving feedback to
the crew via a thin client interface based on HTML; these are implemented as
program tasks.
Using Flight Modes to Tune Flight Performance and Safety
A major advantage of being able to partition the flight into distinct modes with their
own control contexts is that within each mode the control system can be more finely
tuned. This connects back to the main theme of this book, the principle of active
system control (PASC).
There are two specific approaches that can be taken: (1) adaption of the control
system for each specific flight, by using PASC in each flight mode based on the
matrices already discussed in previous chapters; and (2) the second approach, using
the information collected during each flight to build up a cumulative “big data”
picture of the evolution on the aircraft, including ageing, its constituent parts and
looking ahead to improve the reliability of its flights over the airframe lifetime.
As an example, an aircraft can be characterised as follows:
All of the configuration data can be brought together in the aircraft characteri-
sation matrix (ACM). The form of this matrix is shown in Table 8.1.
It basically relates the flight mode to the elements of the aircraft that are
significant in that context, as well as the parameter values that characterise those
elements. In this case, the ASC adapts continuously to the current operational
reality of the flight.
The matrix shown in Table 8.1 is made up of nine submatrices labelled 1–9.
Their meanings are as follows:
1. The parameter correlation matrix is a submatrix that has a row and column
representing each of the parameter (or derived) values measured by the flight
data acquisition unit. The content of each cell represents the expected correlation
between the sensed values. Each pair of parameter values may have a set of
correlation tolerance limits. This matrix can be used to detect faults during
operation using a set of predicates that define the “normal” relations
between them.
2. The flight mode transition matrix is a matrix representation of the flight mode
model described in previous sections. It defines the transition also represented in
XML in the flight mode model in the Appendix. Each cell also contains a data
Table 8.1 General form of the aircraft dependency matrix

Parameter Values Flight Modes Elements
Parameter
1 Parameter 4 Parameters 5 Parameter
Values Correlation Used by Flight Limits used by
Matrix Mode Matrix Elements Matrix
9
2 Flight Mode 6 Flight mode
Flight Modes Matrix Characterisation by
Elements
8
7 Elements 3 Elements
Elements Characterisation by Dependency
Flight mode Matrix
record with fields representing the threshold limits to be used in the “flight”
mode transition predicates.
3. The element fault dependency matrix defines the probability of propagation of
faults between elements; it is defined in Chap. 6, “Principle of Active System
Control: Aspects of Implementation.” The content of each cell is the value of the
probability between 0.0 and 1.0. In a simple implementation the probability can
be considered to be Boolean (either influence or no influence), represented by
0.0 and 1.0. It may also contain a reference to the element predicates or
conditions used to evaluate the next transition from the current flight mode.
The element fault recovery matrix is effectively a “shadow” of the dependency
matrix as it has the same structure (but a different search algorithm). It contains
references to the control and safety recovery actions required when an element is
identified as the most likely to be causing a manifested fault.
4. The parameter limits per flight mode matrix defines which parameter values
need to have dynamically set limits on their acceptable values for each (or at
least some) flight modes. A set of values may be associated with each cell (a data
record) which defines the normal, warning, danger and critical values for each
parameter’s (and some sensor’s) value.
5. The parameters used by elements matrix defines which parameter values are
required by each element model. The way in which the parameter values are
used is encapsulated in each element model.
6. The flight mode characterised by elements matrix defines which elements
contribute to the determination of the current flight mode (if any). Note that
care is needed to ensure that there is no dynamical “circular dependence”
between this matrix and matrix 6 above via the element model. Such a depen-
dence could cause the flight mode to oscillate (dither) between its values.
Further Steps 231
7. The element characterisation by flight mode matrix defines which elements need
to be characterised dynamically by the current flight mode. The way in which the
flight mode is used is encapsulated in each element model. A set of values may
be associated with each cell (a data record) defining the normal, warning, danger
and critical limit values for evaluating the element’s current fault status. These
limits can also be used in the graphic representation of values to the pilot. Some
examples are shown in figure of section “Visualisation of Flight Mode”
(Figs. 8.2 and 8.9).
8. This submatrix is void as parameter values are not affected by flight modes.
9. This submatrix is void because parameter values are not affected by elements.
So, this indicates how the ASC approach can be applied for the use of flight
modes.
Conclusions
1. An approach of active system control (ASC) has been applied successfully to the
rigorous design of a flight mode system of aircraft, making its operation and
aircraft as a whole more efficient, reliable and safe in general.
2. Physics and flight mode detection were explained briefly with illustrations to
support the user (i.e., the pilot).
3. Conditions of flight mode changes were explained and several algorithms of
flight mode detection and change were introduced with arguments of both
advantages and disadvantages.
4. The kinds of changes needed in an aircraft information processing system have
been outlined.
5. Starting from the level of a block diagram of the active system control scheme,
essential architectures of hardware and system software have been explained,
embedding a flight mode detecting system.
6. The dependency matrix scheme of ASC was introduced to integrate flight mode
control.
Further Steps
1. Flight data required to apply for flight mode detection should be as accurate as
possible yet practical. Thus, noise filtering and data error control problems
should be solved for real flight mode detection. A step along this path might
be considered in application of [11]. This requires further joint research of
filtering algorithms and computer architectures to achieve efficiency of solution.
2. Above all, the flight data processing system requires extreme reliability for the
key avionics components involved, and therefore should be implemented as a
resilient computer system [9].
3. Finally, taking into account that UAV and general aviation aircraft have only
limited power supply resources for electronics, the design of a prototype of the
ASC scheme should be implemented on new computer architecture featuring
performance and reliability to provide efficient use of available energy.
Acknowledgements Dr. Felix Friedrich, Dr. Florian Negele and Dr. Thomas Kaegi [all from
ETH (Zurich)] and Dr. Brian Kirk (from Robinson Systems Engineering Ltd. and ITACS Ltd.)
were involved in the development of flight mode algorithms, as well as system architecture and
design required to implement the ASC concept in the general aviation aircraft application domain.
Engineer Alex Schagaev (IT-ACS LTD) developed and tested various flight scenarios to detect
conditions of flight mode changes and verified fight mode changes using two diverse flight
simulators—the X-plane and Microsoft’s Flight Simulator in preparation for field trials using a
general aviation aircraft. This enabled us to improve our understanding of previously unknown
conditions for flight mode change and to refine and improve the flight mode model.
We sincerely appreciate the help of our colleagues and friends and offer our heartfelt thanks.
Appendix: Flight Mode Model: XML Specification



<?xml version="1.0" encoding = "UTF-8" ?>
<Flight_Mode_Model_Specification>




< Hardware_Device_Assignments_Section >

<!—Specifies the Hardware configuration during Initialisation-->
<UART name = "UART0" speed = "115200" parity = "none" databits = "8"
flowcontrol = "false" /> 
flowcontrol = "false" />
<RAMDisk base = "500000H" size = "512" blockSize = "4096" />

<MMCDriver/>
<MMCDisk prefix = "MMC1" partition = "1" cache = "0" format = "true" />
<MMCDisk prefix = "MMC2" partition = "1" cache = "0" format = "true" />
Appendix: Flight Mode Model: XML Specification 233
</Hardware_Configuration_Section>
------------------------------------------------------------------
<Software_Configuration_Section log = "true">


<Call name = "Uart Polling Task" value = "IRoCUartTask.Install" />

<Call name = "BlackBox" value = "BlackBox.Install" />
<Call name = "Flight Mode Detector"
value ="FlightModeDetector.Register" />
<Call name = "Check Safety" value = "CheckSafety.Register" />
<Call name = "TCP/IP" value = "Net.Install" />
<Call name = "Echo server" value = "EchoServer.Install" />
<Call name = "UIS" value= "UIS.Install" />
<Call name = "FrameCapture" value = "FrameCapture.Install" />
<Call name = "ADCParser" value = "ADCParser.Register" />

<Call name = "GPSParser" value = "GPSParser.Register" />
<Call name = "AEParser" value = "AEParser.Register" />
<Call name = "Check Safety" value = "CheckSafety.Register" />

</Software_Configuration_Section >
------------------------------------------------------------------
<Hardware_Device_Assignments_Section >


<BBReplication mmc1 = "MMC1" partition1 = "2"

mmc2 = "MMC2" partition2 = "2" /> 
<BlackBox format = "true" />
<TestSupport device = "UART0" timeout = "10" />
<Net device = "UART4" localhost = "192.168.1.210" />
<UIS port = "5061" />
<EchoServer port="1234" />
<GPSParser device = "UART3"/>
<ADCParser device = "UART1"/>
</ Hardware_Device_Assignments_Section >
------------------------------------------------------------------
<Flight_Mode_Detector_Section>


<speed is 3 seconds filtered GroundSpeed>

<height is 3 seconds filtered GPSHeight>
<RateOfClimb is 3 seconds slope of height>
<acceleration is 3 seconds slope of speed>

<Mode from = "Invalid" to = "Base" condition = "height > -10000" />

<change mode from = "Base" to = "Taxi"
condition = "speed > 0 & speed < 10 knots" />
 <!—this version covers both taxi out and taxi in -->

<change mode from = "Taxi" to = "TakeOffGround"
condition = "speed > 25 & speed < 55 knots
& RateOfClimb = 0 feetperminute" />
<change mode from = "Taxi" to = "Base" condition = "speed = 0 knots" />



<change mode from = "TakeOffGround" to = "TakeOffAirbourne"
condition = "IndicatedAirSpeed > 55 knots
& RateOfClimb > 25 feetperminute" />
<change mode from = "TakeOffGround" to = "Taxi"
condition = "speed < 25 knots" />


<change mode from = "TakeOffAirbourne" to = "Climb"
& RateOfClimb > 0.1 feetperminute & height > 1000 feet" />

<change mode from = "TakeOffAirbourne" to = "Landing"

condition = "RateOfClimb < -10 feetperminute
& height < 1000 feet" />


<change mode from = "TakeOffAirbourne" to = "UncontrolledDescent"

condition = "IndicatedAirSpeed < 55 knots" />


<change mode from = "Climb" to = "Cruise"

condition = "RateOfClimb < 500 feetperminute
& RateOfClimb >-500 feetperminute" />
<change mode from = "Climb" to = "UncontrolledDescent"


<change mode from = "Cruise" to = "ControlledDescent"

condition = "RateOfClimb < -500 feetperminute" />
<change mode from = "Cruise" to = "Climb"

condition = "RateOfClimb > 500 feetperminute" />
<change mode from = "Cruise" to = "UncontrolledDescent"



<change mode from = "ControlledDescent" to = "Landing" condition =
"RateOfClimb < -0.1 feetperminute & IndicatedAirSpeed < 55 knots" />
<change mode from = "ControlledDescent" to = "Cruise"

condition = " RateOfClimb < 490 feetperminute
& RateOfClimb >-490 feetperminute & height > 1000 feet" />
<change mode from = "ControlledDescent" to = "UncontrolledDescent"


<change mode from = "Landing" to = "Taxi"

condition = "IndicatedAirSpeed < 25 knots & RateOfClimb = 0" />
<change mode from = "Landing" to = "TakeOffGround"
condition = "GroundSpeed > 25 knots & GroundSpeed < 52 knots
& RateOfClimb > 0 feetperminute & acceleration > 0.1" />

<change mode from = "Landing" to = "TakeOffAirbourne"
& RateOfClimb > 1 feetperminute & height > 200 feet " />


<change mode from = "UnControlledDescent" to = "ControlledDescent"

condition = "IndicatedAirSpeed > 55 knots" />



</FlightMode_Detector_Section>
———————————————————————————————————————————————————————————————————
<Check_Safety Section>
<-- This section contains a declarative specification of the safety checks

(conditions) and responses (description of event, advice and significance)
within each Flight Mode, it is used to characterise the continuous evalua-
tion of the safety of the aircraft as an element, and to propose safety advice
for the Pilot given the current operational context (Flight Mode)
Note that this is the direct equivalent of the dependency and recovery matrix
of the aircraft as an element, but the paths have been pre-searched and the
recovery actions combined for each Flight Mode-->
<mode name="Any">
<-- Continually checked in all Flight Modes -->
<error name= "flying above the certified ceiling"
advice = "structural integrity is being compromised"
level = "red"
condition = "DensityAltitude>14600 feet OR PressureAltitude > 14600
feet"/>
<error name="approaching ground rapidly"

advice="reduce the rate of descent"
level="red"
condition="RateOfClimb < -2400 feetperminute & height < 2000 feet"/>
<error name = "the aircraft is undergoing dangerous manoeuvres"

advice = "level out aircraft"
level = "red"
condition = "RateOfTurn > 10 & RateOfClimb < 0
& PressureAltitude < 400 feet" />
<error name = "structural integrity is being compromised"

advice = "reduce the aircraft speed immediately"
level = "red"
condition = "TrueAirSpeed > 191 knots" />
<error name = "air data computer or GPS error"

advice = "land aircraft and maintain the ADC (or GPS)"
level = "yellow"
condition = "RateOfClimb > 0 & (Groundspeed > 338 knots
OR GroundSpeed < 0)" />
<error name = "air data computer error"

advice = "land aircraft and maintain the adc"
level = "yellow"
condition = "WindSpeed < -1 OR WindSpeed > 150 knots" />

level = "yellow"
condition = "RateOfClimb > 0 & (TrueAirSpeed > 188 knots
OR TrueAirSpeed < 0 knots)"/>

level = "yellow"
condition = "RateOfClimb > 0 & (MachSpeed > 300 OR MachSpeed < 0 )"/>

level = "yellow"
condition = "RateOfTurn < -20 feet OR RateOfTurn > 20" />

level = "yellow"
condition = "RateOfClimb < -6000 feetperminute
OR RateOfClimb > 6000 feetperminute" />

level = "yellow"
condition = "IndicatedAirSpeed <0 OR IndicatedAirSpeed > 385 knots" />

level = "yellow"
condition = "PressureAltitude <-1000 feet
OR PressureAltitude > 14600 feet" />
</mode>

<mode name = "Taxi">

<error name = "Taxi Speed High"

advice = "decrease taxiing speed now ?"
level = "yellow"
& IndicatedAirSpeed < 20 knots" />
<error name = "Taxi speed dangerous!"
advice = "Nearing flight speed !"
level = "red"
condition = "IndicatedAirSpeed >= 20 knots"
/>
</mode Taxi>
<mode name = "Cruise">
<error name = "aircraft about to stall"
advice = "increase aircraft speed now"
level = "red"
condition = "IndicatedAirSpeed <55 knots" />
<error name = "cruise speed to high"

advice = "decrease cruise speed"
level = "yellow"
<error name = "No acrobatic manoeuvres are approved by the manufacturer"

advice = "Discontinue the manoeuvre immediately!"
level = "yellow"
condition = "( RateOfTurn > 1 OR RateOfTurn < 1)
& ( RateOfClimb > 1 feetperminute OR RateOfClimb < -1 feetperminute )" />
</mode>
<mode name = "TakeOffAirBourne">
<error name = "Takeoff speed to high"
References 239
advice = "decrease takeoff speed"

level = "yellow"

level = "red"
</mode>
<mode name = "Climb">
<error name = "climb speed to high"
advice = "decrease climb speed"
level = "yellow"

level = "red"
</mode>
<mode name="ControlledDescent">
level = "red"
condition = "IndicatedAirSpeed<55 knots" />
<error name = "descent speed too high"

advice = "decrease descent speed"
level = "yellow"
condition = "IndicatedAirSpeed > 129 knots"
/>
</mode>
</Check_Safety_Section>
</Flight_Mode_Model_Specification>
</END>
References
1. Schagaev I, Kirk B and Bukov V (2007) Applying the principle of active safety to aviation. In:
Proceedingsof 2nd European conference for aerospace sciences (EUCASS), Brussels, Report
3_02_05
2. Bukov V, Schagaev I, Kirk B (2007) Analytical synthesis of aircraft control laws. In: Pro-
ceedings of the 2nd European conference for aerospace sciences (EUCASS), Brussels
3. Schagaev I (1998) Concept of dynamic safety for aviation, ISSC 1998, Seattle
4. Schagaev I (2001) Concept of active system safety. In: Proceedings of 15th IFAC symposium
on automatic control in aerospace, Bologna/Forli
5. Schagaev I, Schagaev A, Kirk B (2007) Method and apparatus for system safety. UK patent
PGB0707057.6, 12 Apr 2007
6. http://lessonslearned.faa.gov/ll_main.cfm?TabID¼1&LLID¼71&LLTypeID
7. Taylor E Flight mode error led to 737 loss of separation. https://www.flightglobal.com/news/
articles/flight-mode-error-led-to-737-loss-of-separation-415564/
8. http://www.usatoday.com/story/news/2016/02/25/ntsb-pilot-mistakes-caused-us-airways-acci
dent-philadelphia/80950156/
9. Schagaev I, Kaegi T (2016) System software support for resilient computer systems, Springer
10. https://www.w3.org/XML/
11. Steiner J, Termonia Y, Deltour J (1972) Comments on smoothing and differentiation of data by
simplified least square procedure. Anal Chem 44:1906–1909
12. https://www.academia.edu/32297513/The_role_of_technology
Chapter 9
Active System Control: Realisation
Introduction: The Safety Aspects of Active System Control
One of the important algorithms that active system control (ASC) executes is one
for active system safety. This algorithm has already been described in [1, 2] and
assumes performing three functions principally during different phases of flight:
(1) before the first-ever flight (initial configuration), (2) on the ground before each
flight, and (3) on-board during the flight:
1. Initial configuration of the ASC scheme by setting parameters that characterise
the aircraft, based on the opinions of safety experts and available aircraft
specification details.
2. Before flight: updating element dependencies based on previous flights and then
evaluating the “safety-worthiness” of the aircraft before take-off. All subsequent
“tunings” are automatically processed by ASC after flight using accumulated
flight data and existing matrices.
3. During flight: high-quality evaluation, estimation and prognosis of aircraft
conditions using the method of ASC and safety [3] and characterised by the
matrix of dependencies.
Figure 9.1 presents the schematic structure of the procedure used for searching
possible sequences of an aircraft’s faults in its elements and devices.
Evaluation of the aircraft conditions using our approach of ASC, when it is
applied to safety, may be triggered by any discrepancy between the expected and
real values of flight information, including flight data based on the analysis of flight
conditions or aircraft element dependency matrix changes. All of these may trigger
the analysis (and tracing) of potential risks to identify an element that is the prime
cause of a subsequent safety violation.

242 9 Active System Control: Realisation
Initial preparation of active

Before first flight
system control parameters,
including “filling all matrixes
- Analysis of aircraft element’s conditions

- Prognosis ofelement states
- Searching using dependency and probabilistic matrixes
possible consequences of faulty element During first flight
- Searching of possible reason of faulty element
(“reverse tracing”)
- Selection of recovery procedures if any
- Processing of flight data to determine modify (and

correct) dependencies between elements using
statistical analysis of flight data
After every flight
- Modification of matrixes of dependencies
- Report on modification of all matrixes is prepared using
expert knowledge
Fig. 9.1 The cycle of ASC application for aircraft safety
Objectives of the Chapter
The objectives of our discussion are to:

• Introduce the generic model of ASC as it applies to all ASC-based systems
• Describe what the key algorithms do
• Define more formally how the algorithms work, using mathematical notation
• Clarify how fault detection and fault localisation can be achieved
• Describe how the currently most efficient and effective recovery activities can
be chosen
• Give a practical example widely used in aviation to illustrate how the whole
scheme can work in practice
The Active System Control for Safety: Theoretical Model
To apply ASC to an application domain, it is essential to have a clear understanding

of what ASC does and how the concept can be represented as algorithms that can be
practically implemented and adapted to a given application domain. As an example,
in this chapter the dependencies of aircraft elements already discussed in previous
chapters are the basis for the element dependency matrix De.
The Active System Control for Safety: Theoretical Model 243
Fault Detection and Handling: Algorithms and Procedures
For any technical system with fault handling, the prime concern is to define the
capability of searching for and identifying a faulty element—that is, “localisation,”
using current terminology. The reliability and power of detection of faulty elements
and the speed of fault handling ultimately define the overall availability of a system
as a whole and might be very important, for example, for systems critical to
safety [4].
It is also very important that the system of fault handling be able to detect
multiple faults and trace fault propagation in order to achieve a system recovery
given the current faults. There is no doubt that the introduction of new technolo-
gies— Information and Communication Technology ICT with a high density of
electronic elements—forced us to consider system behaviour, assuming multiple
hardware faults [5]. Given these assumptions, we intend to analyse further the
functional behaviour (as an example) of aircraft equipment to demonstrate and
investigate the efficiency of the proposed approach.
In the case of aircraft, and in the vast majority of complex technological systems,
a difference exists between element faults and functional faults. Functional faults
are the consequences of element faults and may cause system functions to either
degrade or even stop completely. During the design phase of each system, a fault
dictionary is compiled based on the faults that each of its constituent elements can
suffer.
However, some element faults might not cause functional faults and might be
compensated for or self-recovered, for example, an intermittent fault. In other
cases, functional faults appear when several elements in combination cause them,
even though none of them is singly responsible. Further, fault propagation can
manifest at a distance from the real source of faults in the system. Procedures to
handle this have been patented [3] and are explained in this Chapter. Thus, for any
complex system the issues of fault detection, fault handling and system recovery
become crucial.
The generalised algorithm of fault tolerance (GAFT) was presented in chapter 5,
and GAFT implementations have been described in detail for implementation in
both hardware [5] and system software [6]. Here we introduce an algebraic model
of fault handling whereby a system is presented using a GLM [8–12].
We further assume that information from the flight data, and also a predefined
fault dictionary about functional and permanent faults, are readily available for use
in the active system control unit (ACSCU) (when installed) and ultimately for the
crew. A two-phase approach to technical fault handling is proposed:
• While the ACSCU detects faulty elements or their combination, and recovery
procedures are then successfully initiated, the log of the event is recorded for
further handling after landing not only for immediate and targeted maintenance
but also for the benefit of regulatory bodies and aircraft manufacturers. Note that
actions are performed both during flight and after flight.
• While the ACSCU cannot cope with faults of elements and fault propagation, the
only sequence of actions that makes sense is to advise a pilot and crew what
options of control are available and then to provide information about “who or
what we can trust.” This means that fault propagation may create faulty and
uncertain behaviour of software, hardware, and sensors and therefore affect the
behaviour of the on-board computer system. Some algorithms of system soft-
ware recovery have already been developed; see [6, 12]. Forward and backward
searches for “culpable elements” in real time, and exclusion or limitation of their
impact, is achieved by providing an aircraft crew a concrete procedure for
handling the aircraft in the presence of faults—in a degraded mode, but both
limiting fault propagation and manifestation, and mitigating their effects.
The Theory: Based on Applied Graph Logic

Graph Logic Model (GLM): Logic Operators
In previous chapters and in [8–11], an approach has been described whereby a

system can be described as a graph logic model (GLM), illustrated by Fig. 9.2. The
nodes are connected by links (vertices) to form a graph. Each node can have logic
operators associated with its inputs and its outputs. These logic operators define the
propagation paths through the graph during real-time operation of the system being
modelled by the GLM model.
In general, an operator applied to the outcome of a link has index i, whereas the
incoming logic operator has index o. The logic operator ANDo has links from node
b to nodes c, d, and e, and so they are activated together and, in principle, at the
ORo(b,d) - means that no order Node b assumes parallel activation

or imperative timing is required of links to nodes d, e, and c as it is
to move from vertex a; described in callout with operator
ANDo(c,d,e).
ORo(b,d) ANDo(c,d,e)
a b c
d e f XORi (e,d)
ANDo(b,f)
for f node: input links that

required to be mutually
exclusive are described by
special callout as (XORi (e,d))
Fig. 9.2 An example of graph logic m with all XOR, OR, AND
1
ORi
ORo 2
4
ORi
ANDi
ANDo
ORo
5 3
ORi 6
ANDi
ORo ANDi
ANDo
ORo
Fig. 9.3 Example of GLM with OR and AND
same time. The link between node b and a is not defined by a logic operator, as is
the case with several other links. The logic operator XORo for incoming links to
node f means that only one of these links will be activated at a time. For tracing fault
propagation and manifestations along the GLM operator, XOR is a great help
because other choices of propagation are excluded. Thus, for the purpose of
demonstration, we can deal with two logic operators applied to each input and
output of the digraph. They are OR and AND; see Fig. 9.3.
Also, for simplicity of demonstration, let us assume that each graph vertex of
GLM that describes an object has no more than two inputs and two outputs. Greater
numbers of inputs and outputs are not critical, but visualisation of the algorithm
functioning would be more complex.
As described in the patent [3], two algorithms are introduced—forwards and
backward tracing of fault detection and propagation within the modelling of the
object. When moving through the GLM forwards or backward, assuming logic
operators are associated with each of the incoming or outgoing links, the tracing
complexity can be created when we reach an operator OR. Thus, when a fault
(or any signal for that matter) propagates and reaches the node with the output logic
operator AND, it means that the signal (and fault) “broadcasts” directly in all
directions defined by the node’s logic network connectivity. So, for node 2 this
means that both links—to nodes 3 and 6—will be activated simultaneously. The OR
operator in turn assumes that only one of the outgoing links will be activated, thus
leaving some uncertainty in the system state.
In practice, when modelling a system, the incidence of a fault in an element,
according to dependency, propagates along the graph and affects other elements
(e.g., the vertex). This can cause a fault manifestation at one or more location, and
an abnormal, or at least undesirable, behaviour will be finally discernible. We
assume also that the influence of a fault may cause further damage to other elements
of a system, leading to a harmful incident. Thus, according to [3] we need two
processes: (1) detection of consequences that might lead to safety degradation of an
aircraft, and (2) localisation of reason, that is, the source of fault leading to the
manifestation of the fault, with logic and time latency. In this chapter we address
only one process—the backward tracing of a system described by the GLM.
Table 9.1 The forward function of the basic logic operators

Symbol Name Equation
ORi OR at the input 1þ1¼1 1þ0¼1 0þ1¼1 0þ0¼0
ANDi AND at the input 11¼1 10¼0 01¼0 00¼0
ORo OR at the output N 1¼1þ0 1¼0þ1 0¼0þ0
ANDo AND at the output 1¼11 N N 0¼00
Table 9.2 The inversed function of the basic logic operators

Symbol Name Equations
iORi Inversed «OR» at the input 1=1+1 1=1+0 1=0+1 0=0+0
iANDi Inversed «AND» at the input 1=1×1 0=1×0 0=0×1 0=0×0
iORo Inversed «OR» at the output conflict 1+0=1 0+1=1 0+0=0

iANDo Inversed «AND» at the output 1×1=1 conflict conflict 0×0=0
When one applies a system described using GLM, with OR and AND operators
associated with each node’s outputs and inputs, a fault propagation might be
described as in Table 9.1. This table and further discussion was originally defined
and presented in D3.X of the ONBASS project [7], completed under the FP6
program and briefly described in [7, 10, 11]. Any signal or fault when propagated
through the GLM is effectively propagated through and subject to the logic
operators of the model. In this context, “0” means no fault and “1” means there is
a fault. Thus, when a fault reaches an element with LO AND, it might be either
stopped in terms of manifestation or propagated further; see Table 9.1.
Some outcomes of analysis are uncertain as LO combinations for them do not
exist. Note that when such logical combinations are not defined, (as Figs. 9.2 and
9.3 present, and Table 9.1 shows), then they are marked by N, as in the two
bottom most cells.
Let us define the logic by “inverse analysis,” that is, what it could be at the input
to create a given output. This logic is required for the process of localisation
(search, backward tracing) fault starting from the moment (and point) of detection.
For searching the reason of faulty behaviour one needs to introduce an algorithm for
backward movement along a graph. To do this we invert the formulae in Table 9.1,
which results in Table 9.2.
As the patent [GB] describes, by using the GLM, well-known fault trees [13] can
be combined into a unified model that makes it possible to investigate fault
propagation, forward and search reasons and sources of faults by backward search.
Taking an inverse view of the logic enables backward searching, that is, when an
output is known then the causal source or value of an input when an output is known
some inputs can be inferred, with a level of detail depending on the specific context.
Table 9.2 presents this for the model of Figs. 9.2 and 9.3. Here selected cells imply
multiple options that force us to make more branching of the node.
Thus, inverse tracing analysis might show that the existence of “1” at the output
of the logic operator OR means that either one or both inputs have “1.” The
absence of some formulae in Table 9.1 creates conflicting situations in Table 9.2.
Based on this argument, the conflict “all branch” (hypothesis) should be excluded
up to the nearest branching in order for the semantics of the GLM to be completely
defined.
The Modelling of Fault and Fault Detection
Using the results of analysis of a real system, one might create a GLM of fault
appearance and propagation of their effects. To promote modularity within com-
plex systems, this analysis assumes that each node represents a subsystem, unit or
element of the system, and each might have its own suite of input and output logic
represented by the operators OR and AND.
Figures 9.2 and 9.3 present an example of a hypothetical system with six nodes.
Here some nodes are elements with possible faults; others might be considered as
internal processes with a manifestation of faults. Analysis of fault propagation and
consequences might start therefore from any node. For example, vertices 1 and
3 are elements of the system; they might have faults. Vertices 2 and 5 are elements
of a system that might manifest discrepancy (i.e., fault manifestation) of the
mentioned faults. In this case, vertices 4 and 6 are internal elements that do not
belong either to the first or to the second group. To implement the logic operator
ORo a rule of selection must be defined for the output edges either explicitly or by a
random distribution that is relevant to the context.
It is possible to continue using visual graphing; however, to ease formalisation
and emphasise completeness, it is more concise, precise and mathematically rigor-
ous to use matrix notation. Denote: xi(k), the binary value of the ith component
(vertex) before an iteration of expansion process (0, absence of fault; 1, existence of
fault, or its manifestation or influence); and xi(k þ 1), binary value of the ith
element state of the vertex after iteration. The upper index is a symbol of the
logic operator at the input of the vertex; the lowercase index is a symbol of the logic
operator at the output of the vertex. We number for each element the code, physical
content and relation to category: fault, manifestation or internal variable.
2 3 2 3
ORo ðk þ 1Þ
xOR i
2 3 ORo ðk Þ
xOR i
0 0 1 1 0 0
6 ORi 7 6 ORi 7
6 xANDo ðk þ 1Þ 7 6 1 07 6x ðk Þ 7
6 7 6 0 0 0 0 76 ANDo 7
6 ANDi 7 6 76 AND 7
6 xANDo ðk þ 1Þ 7 6 0 1 0 0 0 0 76 xANDio ðkÞ 7
6 7¼6 76 7 ð9:1Þ
6 ANDi 7 6 17 6 AND 7
6 xORo ðk þ 1Þ 7 6 0 0 1 0 0 76 xORo i ðkÞ 7
6 7 6 76 7
6 xORi ðk þ 1Þ 7 4 0 0 0 1 0 1 56 7
4 xORio ðkÞ 5
OR
4 ORo 5
1 1 0 0 0 0
xORo ðk þ 1Þ
ANDi
ORo ðkÞ
xAND i
We note that the symbols of the logic operators at both the input and output of
the vertex belong to rows and columns of this binary matrix of transitions. Based on
this observation, one might rewrite formulae in the form of Eq. 9.2:
2 3 2 3 2 3
x1 ðk þ 1Þ ORi 0 0 1 1 0 0 x1 ðk Þ
6 x2 ðk þ 1Þ 7 ORi 61 0 0 0 0 0 7 6 x 2 ðk Þ 7
6 7 6 7 6 7
6 x3 ðk þ 1Þ 7 ANDi 60 1 0 0 0 0 7 6 x 3 ðk Þ 7
6 7 6 7 6 7:
6 x4 ðk þ 1Þ 7 ¼ 60 7 ¼6 7 ð9:2Þ
6 7 ANDi 6 0 1 0 0 1 7 6 x 4 ðk Þ 7
4 x5 ðk þ 1Þ 5 ORi 40 0 0 1 0 1 5 4 x 5 ðk Þ 5
x6 ðk þ 1Þ ANDi 1 1 0 0 0 0 x 6 ðk Þ
ORo ANDo ANDo ORo ORo ORo
|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}
Dependency Matrix
This can be written in many equivalent forms, as Eq. 9.3 illustrates.

2 3
ORi 0 0 1 1 0 0
ORi 61 0 0 0 0 0 7
6 7
ANDi 60 1 0 0 0 0 7
DEP ¼ 6 7
ANDi 60 0 1 0 0 1 7
6 7
ORi 40 0 0 1 0 1 5
ANDi 1 1 0 0 0 0
ORo ANDo ANDo ORo ORo ORo
2 3
0 0 1 1 0 0
61 0 0 0 0 07
6 7
LogIn 6
60 1 0 0 0 077
¼ ð9:3Þ
LogOut 6
60 0 1 0 0 177
40 0 0 1 0 15
1 1 0 0 0 0
Where LogIn ¼ {ORi, ORi, ANDi, ANDi, ORi, ANDi} is the set of logic
operators at the input of all vertices of the graph, LogOut ¼ {ORo, ANDo, ANDo,
ORo, ORo, ORo} is the set of logic operators at the output of all vertices.
The model presented is neither a matrix nor an algebraic object; generically it is
a GLM matrix. This “matrix” does not allow applying known rules of numeric
matrix calculations and transformations. Accordingly, this construction is called a
“dependency matrix” when its content represents the fault propagation dependen-
cies in a system.
The principal difference in this table besides the GLM is in the allocation of
predefined logic operators to each column and row. Rules for this “matrix” are as
follows: all multiplications by vector are processed as usual, but are subject to two
additional conditions:
1. Independence of the operator at the output of the vertex (i.e., the operator is
written under the respective column or near the respective underline)
implements output logic of vertex’s predecessor. See, for example, Table 9.1 for
operators ANDo and ORo. For operator ANDo all “1” of this column produce a
“1” at the output, whereas operator ORo handles various options: when one “1”
equal “1,” and another “0,” and vice versa (as defined in the chosen logic).
2. Accordingly, the input logic of the operator at the input of the vertex is
implemented (the operator is presented to the left of raw or near respected
position upper line). See Table 9.1 with operators ANDi and ORi. The output
of operator AND is “1” when both inputs are “1,” produced using values of
elements of column x (k) and operators ANDo, ORo, while for operator OR, in
the case when at least one of inputs is “1,” it is deduced in a similar way.
In addition to the dependency matrix, one also needs to produce an output
matrix. This matrix defines the vertices of a graph that correspond with observable
faults. In general, faults might become manifest via some linear combination of
graph state. For example, a matrix of outputs can be defined as equalities.
2 3 2 3
x1 ðk Þ x1 ðk Þ
6 x 2 ðk Þ 7 6 7
6 7 6 x 2 ðk Þ 7
y1 ðk Þ 6 7
x 3 ðk Þ 7 0 1 0 0 0 0 6 x 3 ðk Þ 7 6
¼ E6
6 7 ¼ 7 ð9:4Þ
y 2 ðk Þ 0 0 0 0 1 0 6
6 x4 ðkÞ 7 |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl x 4 ðk Þ 7
4 x 5 ðk Þ 5 ffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} 4 x ðkÞ 7
6
5
E 5
x 6 ðk Þ x 6 ðk Þ
Thus, a concrete multidimensional model of fault propagation in the system has

been achieved which includes
X (0) Appearance of faults at the moment 0,

X (k þ 1) ¼ DEP X (k) Fault influence propagation node-to-node
or X (k þ 1) ¼ DEP X (k) + X(0) Generalised propagation of fault influence
Y (k) ¼ E X (k) Fault manifestation via special vertex
must be adequate for the processing of fault propagation in a real system. In

practice, for a particular system, this model is based on formal system descriptions,
expert opinion and the results of practical experiments. After a model of the system
has been approved, the next phase is to define the localisation of faults and faulty
elements.
The Localisation (Search) of Faults
Let us assume that faults might be simple (single fault) or complex (multiple faults).
The only limiting assumption introduced here is the fact that the nature of the faults
does not change during operation of the algorithm searching for a faulty element.
Let us consider a procedure for inversed transformation in the above model just
presented.
At first, using a vector of observable manifestations Y(0), one forms an estimated

b for the whole vector of state for the system (i.e., the logic variables of all
value X(0)
the vertices in the graph). Common rules applied include the following: elements of
b
the vector X(0) are assigned values
• 0, corresponding element is guaranteed working.
• 1, corresponding element is guaranteed not working.
• * state is undefined; state of the element is impossible to determine using the
observable manifestation of faults.
This procedure might be best described as looking for a set of all solutions for an
equation.
Y ð0Þ ¼ E Xð0Þ, E 2 ℜmn , m < n, on vector Xð0Þ:
In the general case, this solution might be presented as
~ ð0Þ þ ER μ,
fXð0Þgμ ¼ EY
where curly brackets denote a set of valid but different solutions generated by a
~
variation of parameter μ; in this case, μ is a vector of dimension n – rank E, where E
R
is the canoniser of matrix E; E is the right divider of zero for matrix E with
maximum rank, that is, the matrix of dimension n (n – rank E) with maximum
rank, for which the following condition holds:
EE ¼ 0
R
Canonisation of matrix E in the problems here (all elements of matrix E are

represented only by “0” and “1” so the matrix itself has maximal raw rank) are
~ ¼ ET . E
equal to the transposed value of the initial matrix: E ~ ¼ ER Thus, the
resulting formula has the form:
Xf0gμ ¼ ET Y ð0Þ þ ER μ ð9:5Þ
and all elements of a vector μ are further presented as “*”.

Secondly, using the known dependency matrix, namely, its inversion INDEP, a
backward sequence of fault influences is determined by vector X, denoted by “*,”
that is, not defined. Now, t by transposing (mutual change of elements in rows and
lines including logic operators) and replacing source operators by their inversions
(using inversed logic), one is able to produce relations for backward tracing: τ ¼ 0,
1, 2, . . .:
2 3 2 3 2 3
x 1 ð τ þ 1Þ i ORo 0 1 0 0 0 1 x1 ðτ Þ
6 x2 ðτ þ 1Þ 7 i ANDo 60 0 1 0 0 1 7 6 x 2 ðτ Þ 7
6 7 6 7 6 7
6 x3 ðτ þ 1Þ 7 i ANDo 61 0 0 1 0 0 7 6 x 3 ðτ Þ 7
6 7 6 7 6 7
6 x4 ðτ þ 1Þ 7 ¼ i ORo 61 0 1 0 1 0 7 6 x 4 ðτ Þ 7
6 7 6 7 6 7
4 x 5 ð τ þ 1Þ 5 i ORo
40 0 0 0 0 0 5 4 x 5 ðτ Þ 5
x 6 ð τ þ 1Þ i ORo 0 0 0 1 1 0 x 6 ðτ Þ
i ORi i ORi i ANDi i ANDi i ORi i ANDi
|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}
INDEP
ð9:6Þ
Here there is a table for which we will use an equivalent presentation:

2 3
i ORo 0 1 0 0 0 1
i ANDo
60 0 1 0 0 17
6 7
i ANDo
61 0 0 1 0 07
INDEP ¼ 6 7
i ORo
61 0 1 0 1 07
6 7
i ORo
40 0 0 0 0 05
i ORo 0 0 0 1 1 0
i ORi i ORi i ANDi i ANDi i ORi i ANDi
2 3
0 1 0 0 0 1
60 0 1 0 0 17
6 7
InLogOut 6
61 0 0 1 0 077
¼ ð9:7Þ
InLogIn 6
61 0 1 0 1 077
40 0 0 0 0 05
0 0 0 1 1 0
where:
InLogIn ¼ {iORi, iORi, iANDi, iORi, iANDi} is the set of inversions for logic
operators at the inputs of nodes and
InLogOut ¼ {iORo, iANDo, iANDo, iORo, iORo, iORo} is the set of inverses at
the output of nodes
Again, the principal distinction of this table is in the fact that it is neither a matrix
nor an algebraic model, because of the rows and columns affiliated with logic
operators (now inversed).
When working with this table there are two more conditions:
1. Solutions are generated by operators iORi and iANDi (where there are two “1” in
a column) as in Table 9.2. This potential alternative hypothesis of fault propa-
gation within the system needs to be analysed further. After each transfer via this
operator it is required to have three possible variants.
2. Calculating the possibilities in Table 9.2 reveals conflicts that belong in different
rows, the corresponding hypothesis about the pre-history of fault propagation is
therefore cancelled.
Here the first condition defines a rule for branching in a “fault tree”; the second
condition excludes t unpromising (i.e., contradictory to the logic of the system)
branches. A generalised procedure for localisation of faults using backward tracing
of faults might be written as a formulae:
_
XðτÞ ¼ INDEP INDEP . . . INDEP ET Y ð0Þ þ ER μ ð9:8Þ
that cannot be presented as an algebraic equation due to the nonalgebraic character

of the table structure INDEP. The number of iterations is selected either using the
termination condition of transformation for the vector of state X(τ þ 1) ¼ X(τ), or
by some limiting value τ ¼ τmax, as was introduced in [12].
A simplified structure of this algorithm, which implements this iterative proce-
dure of fault localisation, is presented as follows:
Given the iterative process described in the equation above using interactively
table INDEP, it is possible to approximate by an equation such as
b ðτÞ ¼ RECð0Þ,
X ð9:9Þ
Then the matrix RECX will be the so-called recovery matrix, which contains any
actions or procedures required for recovery after localisation of a fault. The
structure and context of recovery actions are different for various systems due to
their structure and properties as well as the nature of the fault. This needs further
special development and practical guidance from experts who fully understand the
system.
Thirdly, the potential faulty elements are defined by “1” values in the vector. The
value “0” at the position of the element defines correct elements of the vector of
state. The presence of “*” defines the group of elements in the system that, using
existing information about possible faults and the structure of elements connection,
do not provide enough certainty about their state of faultiness or correctness. This
represents areas of a system where the need for coverage needs to be analysed and
possibly addressed using other means.
Recovery Matrix
The recovery matrix (see Table 9.3) for ASC consists of a set of elements related to
one another in terms of actions to recover or reduce the consequences of any faulty
element detected. Clearly, in general, the reasoning for recovery actions might be
different in each system due to its intended purpose, architecture and implementa-
tion. This difference is defined by the semantics of fault propagation in the system.
Note that the diagonal of the recovery matrix is not zeroed: when analysis of the
dependency matrix shows that the faulty element is the same element from which
searching the consequences was initiated, then recovery of this element has its own
Table 9.3 Recovery matrix: an example
action without any connections to other neighbours—all these actions are placed on
the main diagonal of the matrix.
Element recovery is, in fact, a link to the program to be performed when an
element is considered to be faulty and that fault is detected, located and attributed to
this element. We make a link to the recovery procedure Lxj if element x depends on
element j in recovery terms. Note that the sequence of fault propagation that ended
up on element x as being “culpable” might be different and not include element j in
the recovery sequence. Various recovery procedures are affiliated with each ele-
ment and its neighbours. For example, when an aero-engine is accidentally stopped,
it might be restarted; when an engine is shut down due to overheated wires by a fire
alarm system, the recovery of the engine should consist of a delay and cooling by
neutral gas with a warning to the pilot about procedures performed.
The graph of the recovery matrix is defined by the topology of the dependency
matrix, that is, the absence of a link between elements in the dependency matrix
implies an absence of recovery actions. When the recovery procedure concerns
hardware of avionics, the property of reconfigurability might be required and can be
efficient, for example, being hot-swappable so there is no loss of availability. One
example of reconfigurability handling is described relatively fully in [5, 15].
The Algorithms of Fault Localisation
Using the same example to demonstrate how the introduced matrix model of
dependencies can be applied, we might assume for simplicity that we agree that
the element outputs will be done using an AND operator. Then for analysis of faults
and their propagation we have:
2 3
ORi 0 0 1 1 0 0
ORi 61 0 0 0 0 07
6 7
ANDi 60 1 0 0 0 07
DEP ¼ 6 7
ANDi 60 0 1 0 0 17
6 7
ORi 40 0 0 1 0 15
ANDi 1 1 0 0 0 0
ANDo ANDo ANDo ANDo ANDo ANDo
2 3
0 0 1 1 0 0
61 0 0 0 0 07
6 7
LogIn 6
60 1 0 0 0 077
¼ ð9:10Þ
AND 6 60 0 1 0 0 177
40 0 0 1 0 15
1 1 0 0 0 0
and for inversed analysis (localisation of fault):

2 3
i ANDo 0 1 0 0 0 1
AND 6 0 0 1 0 0 17
i o 6 7
AND 6 1 0 0 1 0 07
INDEP ¼ i o 6 7
AND 6 1 0 1 0 1 07
i o 6 7
i AND o
4 0 0 0 0 0 05
i AND o 0 0 0 1 1 0
OR OR
2i i i i i AND i 3i AND i i ORi i ANDi ð9:11Þ
0 1 0 0 0 1
60 0 1 0 0 17
6 7
i AND o 6
6 1 0 0 1 0 07 7
¼
InLogin 661 0 1 0 1 07
7
40 0 0 0 0 05
0 0 0 1 1 0
To demonstrate the principle of ASC for safety purposes, including real-time

detection, localisation and recovery of a specific aircraft system, a special frame-
work of six algorithms has been developed, as Fig. 9.4 illustrates.
These six special algorithms form the basis of ASC for safety:
• Algorithm 0 – defines initial values for a vector X and, using the vector of fault
manifestation, implements a procedure to solve the equation Y(0) ¼ EX(0).
• Algorithm 1 – defines at the jth column of matrix INDEP all elements with
value 1, and assigns corresponding elements of vector X zero values.
• Algorithm 2 – searches in the jth column of matrix INDEP all 1-tuple elements,
and checks values of corresponding elements of vector X. If all values between
are equal to 1 and one value is undefined (*), then the undefined value is assigned
“0.”
Input data:
BEGIN DEP − Dependency Matrix;
LogIn − n-vector with the elements AND and OR − input logic of the Dependency
Matrix;
Information E − Transformation Matrix from X into Y: Y=EX
gathering about Y
Prior step: Making of an initial vector X0 which contains

Algorithm
0 1 − for disabled elements for sure ;
0 − for able-bodied elements for sure ;
∗ − for uncertain elements ;
k := 0 The null step number

The next step number
k := k + 1
j := 1
j − the element number of a vector X
no
Xk j = 0 Xki = 1 no
yes
yes
no no
LogIn j = OR LogIn j = OR
yes yes
Algorithm Algorithm Algorithm Algorithm Algorithm

1 2 3 4 5
Switch to analysis of the next

j := j + 1 element of a vector X and the
next DEP - matrix row
Giving out no no yes

Stop
j≤n
Xk condition
yes
END
Fig. 9.4 Framework of ASC algorithms for the safety of aircraft
• Algorithm 3 – searches in the jth column of matrix INDEP 1-tuple values, and
detects values for corresponding elements of vector Х. If all values are equal “0”
and one is undefined (*), then the undefined element is assigned value “1.”
• Algorithm 4 – searches in the jth column matrix INDEP “1” elements and
assigns corresponding vector Х values “1.”
• Algorithm 5 is used for possibilities of direct transformation of matrix DEP to
define the element Xkj:
Xkj ¼ DEPj Xk ð9:12Þ

The logic implemented is:

• If LogInj ¼ OR and between input elements Xkj exists at least one “1,” then Xkj:
¼ 1.
• If LogInj ¼ AND and amongst input values Xkj exists at least one “0,” then Xkj: ¼ 0.
• If all input values are defined, then Xkj ¼ DEPjXk.
• Otherwise, Xkj remains the same, Xkj ¼ “*”.
The termination condition assumes that Xk ¼ Xk-1 or the number of iteration
exceeds 2n þ1.
The Application Example: Air Pressure System
To check the applicability of the GLM and how the defined searching algorithms
might work to detect fault components, let us consider a simplified scheme of the
height–speed parameters of an aircraft shown in Fig. 9.5. The abbreviations
presented in Table 9.4 are used.
Here, TPP is the tube Pitot pressure sensor; ADS is the airborne digital system;
SI is the speed indicator. SH1 and SH2 are the static height air pressures experienced
by the aircraft.
Output (fault manifestation) here is aggregate of devices indicated parameters:
– Airspeed indicator SI (y1)
– Altimeter A (y2)
– Variometer V (y3)
The scheme of Fig. 9.5 corresponds to a model described by Eq. 9.14. Here ∇ is
input and output without alternative (1 input and/or 1 output), x1 is the output of
TPP1; x2 is the output of TPP2; x3 is the state of the tract (pipe) of full pressure; x4 is
SH1
TPP1
Impact pressure airline

A
Static pressure
SI airline
TPP2
V
ADS
SH2
Fig. 9.5 Sample of the scheme to detect faults

Table 9.4 List of element faults (aerometric system)

No Fault description Notation Fault manifestation
1 Supervising fault of cADS1 Stopping of finding and reflection all height–
2 ADS computer cADS2 speed parameters on MFI from ADS (MFI
resumes operation after choosing the trig ADS)
3 Supervising fault of Hb cADS1Hb Stopping of finding and reflection Hb on MFI
4 circuit of ADS cADS2Hb (MFI resumes operation after choosing the trig
computer ADS)
5 Supervising fault of Vtr cADS1Vtr Stopping of finding and reflection Vtr, Te on MFI
6 circuit of ADS cADS2Vtr (MFI resumes operation after choosing the trig
computer ADS)
7 No supervising fault of fADS1 False reading Vdv, Hb, Vtr, Te on MFI (readings
8 ADS computer fADS2 improve after choosing the trig ADS)
Discrepancy of readings MFI and SI, A
9 Becoming dpTPP1 False reading Vdv, Vtr on MFI (MFI resumes
depressurised or partial operation after choosing the trig ADS)
stopping up of TPP1
10 Total stopping up of tsTPP1 Reading Vdv on MFI is constant while airspeed
TPP1 changes
False reading Vtr on MFI
11 Fault of TPP1 heating hTPP1 Stopping of readings Vdv, Vtr on MFI
(while icing)
12 Becoming dpTPP2 False readings Vdv, Vtr on MFI (MFI resumes
depressurised or partial operation after choosing the trig ADS)
stopping up of TPP2 False readings Vdv, Vtr on SI
13 Total stopping up of tsTPP2 Reading Vdv on MFI is constant while airspeed
TPP2 changes
Reading Vdv on SI is constant while airspeed
changes
False reading Vtr on SI and MFI
14 Fault of TPP2 heating hTPP2 Stopping of readings Vdv, Vtr on MFI
(while icing) False reading Vdv on SI
15 Open-circuit failure of ocTPP1 Stopping of outcomes Vtr, Te of ADS to MFI
16 TPP ocTPP2
17 Fault of SI fSI There is no indication Vdv, Vtr on SI (zero value)
18 Fault of A fA There is no indication Hb on A (zero value)
19 Becoming dpSH1 False readings Hb, Vtr on MFI (MFI resumes
depressurised of sensor operation after choosing the trig ADS)
or piping of SH1
20 Becoming dpSH2 False readings Hb, Vtr on MFI (MFI resumes
depressurised of sensor operation after choosing the trig ADS)
or piping of SH2 False reading Hb, Vtr on reserve apparatuses
21 Stopping up of sensor spSH1 Reading Hb on MFI is constant while altitude
or piping of SH1 changes. False reading Vtr on MFI (MFI
22 Stopping up of sensor spSH2 Reading Hb on MFI is constant while altitude
or piping of SH2 changes. False reading Vtr on MFI (MFI
Reading Hb on A is constant
False reading Vtr on SI
(continued)
Table 9.4 (continued)

No Fault description Notation Fault manifestation
23 Supervising fault of sfAHRS Stopping of finding and giving ψM, ψtr, γ, Z
AHRS
24 Supervising fault of sfAHRShead Stopping of finding and giving ψM, ψtr, Z
yaw channel of AHRS Reading of SC is absent
25 Supervising fault of sfFMC Stopping of finding and giving all parameters
FMC from FMC
26 Signalled fault of mode sgFMCfgc Controlling signal from FMC to FGC is absent
of operation “route” of
FGC
27 Fault of FGC fFGC Shut down all channels and control modes
28 Fault of yaw channel of fFGChead Going out of rudder servo up to the stop
FGC
29 Fault of roll channel of fFGCbank Going out of rudder servo up to the stop
FGC
the output of AI; x5 is the output of ADS; x6 is the output of A; x7 is the output of V;
x8 is the state of the pipe of static pressure; x9 is the output of SH1; x10 is output of
SH2.
2 3
2 3 0 0 0 0 0 0 0 0 0 0 2 3
x1 ðk þ 1Þ ∇ 6 7 x 1 ðk Þ
6 x2 ðk þ 1Þ 7 0 0 0 0 0 0 0 0 0 0
6 7 ∇ 6 61 1
7 6 x 2 ðk Þ 7
6 x3 ðk þ 1Þ 7 6 0 0 0 0 0 0 0 07 6
7 6 x 3 ðk Þ 7
7
6 7 ANDi 6 76 7
6 x4 ðk þ 1Þ 7 0 0 1 0 0 0 0 1 0 0
6 7 ORi 6 60 0
7 6 x 4 ðk Þ 7
7 6 7
6 x5 ðk þ 1Þ 7 1 0 0 0 0 1 0 0 76
6 7 ORi 6 60 0 7 6 x 5 ðk Þ 7
7
6 x6 ðk þ 1Þ 7 ¼ ∇ 6 6 0 0 0 0 0 1 0 0 7 6 7
6 7 0 0 0 0 0 0 0 1 0 07 6 x 6 ðk Þ 7
6 x7 ðk þ 1Þ 7 ∇ 6 7 6 x 7 ðk Þ 7
6 7 60 0 0 0 0 0 0 0 1 17 6 7
6 x8 ðk þ 1Þ 7 ANDi 6 7 6 x 8 ðk Þ 7
6 7 60 0 0 0 0 0 0 0 0 0 76 7
4 x9 ðk þ 1Þ 5 ∇ 6 7 4 x 9 ðk Þ 5
40 0 0 0 0 0 0 0 0 05
x10 ðk þ 1Þ ∇ x10 ðkÞ
∇ ∇ ANDo ∇ ∇ ∇ ∇ ANDo ∇ ∇
|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}
Dependency Matrix
ð9:14Þ
To form output we write:

3 2
x1
6 x2 7
6 7
6 x3 7
6 7
2 3 2 3 6 x4 7
y1 0 0 0 1 0 0 0 0 0 0 6 6 7
7
4 y2 5 ¼ 4 0 0 0 0 0 1 0 0 0 0 5 6 x5 7 ð9:15Þ
6 x6 7
y3 0 0 0 0 0 0 1 0 0 0 6 7
|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} 6
6 x7 7
7
E 6 x8 7
6 7
4 x9 5
x10
Let us assume that the fault is icing (i.e., the blocking by ice of pressure sensors
TPP1 and TPP2). Due to this fault, the required pressure does not exist in the full-
pressure pipe, and so devices SI and ADS show wrong values. This leads us to the
conclusion that after several iterations in the model, vector X in the model of
“matrix” gets the value:
XT ¼ ½1 1 1 1 1 0 0 0 0 0 ð9:16Þ
At the same time the fault manifests as device SI not working:
Y T ¼ ½1 0 0 ð9:17Þ
Let us now find, using the presented algorithms, the vector X and compare it with
the “initial value”
1. Initial (preliminary) calculations. Using algorithm 0 gives the value for vector
b T ð0Þ ¼ ½∗∗∗ 1 1∗ 0 0∗∗

X
2. Zero step, k ¼ 0.
At j ¼ 1, 2, . . ., 5 vector Xb (0) has not changed. At j ¼ 6 the following equalities

take place
b 6 ð0Þ ¼ 0, LogIn6 ¼∇, and one needs to start algorithm 2.
X
Accordingly, with this X b 8 ð0Þ≔0
At j ¼ 7, 8, 9, 10 vector X b □ ð0Þ has not changed. As a result, zero step vector
b □ ð 0Þ
X
takes the values X b T ð0Þ ¼ ½∗∗∗ 1∗ 0 0 0∗∗
3. First step, k ¼ 1.
b ð1Þ has not changed. At j ¼ 4 the following equalities take
At j ¼ 1, 2, 3 vector X
place
b 4 ð1Þ≔1, LogIn4 ¼ OR and algorithm 3 should be initialised. Accordingly,
X
b 3 ð1Þ≔1
X
At j ¼ 5 the following equalities take place X b 5 ð1Þ ¼ ∗, LogIn5 ¼ OR, and the
process of analysis continues by algorithm 5, Accordingly,
b 5 ð1Þ ¼ 1 because X
X b 3 ð1Þ≔1
At j ¼ 6, 7, 8, 9, 10 vector X b 1 ð1Þ has not changed. As a result of the first step
vector
b 1 ð1Þ takes the values
X
b T ð1Þ ¼ ½∗∗ 1 1 1 0 0 0∗∗

X
4. Second step, k ¼ 2
At j ¼ 1, 2 vector Xb 12 ð2Þ has not changed. At j ¼ 3 Xb 3 ð0Þ ¼ 1, LogIn3 ¼ AND

and it is required to initiate algorithm 4. Accordingly, algorithm 4 values are
X1(2) ≔ 1; X2(2) ≔ 1.
During further steps of the algorithm, vector Xb □ has not changed. As a result, one
has the final result
b ðk Þ ¼ X
X b ð2Þ ¼ 1 ½1 1 1 1 1 0 0 0∗∗
Comparing this value with the real initial value one might determine that all
faulty elements have been found. Because of the identical pair of TPP1 and TPP2,
to define the state of both sensors at the same time seems to be problematical,
provided the solution [16] is not applied. Therefore, the vectors above positions
9 and 10 have uncertainty *. These show that checking the system does not have
enough information to define all states, leaving these two unknown.
Modelling and Handling of Faults: A More Realistic Example
The key aspect of fault detection is element modelling. This provides the means by
which the behaviour of each element’s set of data values can be assessed as
being “normal” or possibly indicating an actual, potential or latent fault.
Another possible source of anomaly, and, therefore a kind of fault, is that the
aircraft’s instrumentation is faulty, e.g., the position values from GPS are not the
same (within expected tolerance) as the position values from say an inertial
guidance system.
We propose the following classification of faults:
1. An actual fault is one that really exists in an element and is manifested, for
example, a fuel pump is blocked, an air pressure sensor is frozen, an engine’s
revolutions have stopped when the aircraft flight mode is “cruising”.
2. A potential fault shows symptoms but cannot yet be classified as an actual fault,
for example, the fuel pump may “stutter” due to some grit in the fuel, but then
recover if the grit is eventually flushed away. This could cause a significant but
temporary dip in engine revs which would be unexpected in the current flight
mode context (probably all of them). This type of fault is usually called func-
tional deviation beyond expected limits.
3. A latent fault is a fault that has already occurred but has not yet manifested itself,
for example, the nose wheel braking system was damaged on take-off but this
will not be manifested until the aircraft attempts to land when the brakes are
applied.
4. An instrumentation (or sensor) fault where an erroneous and possibly invalid
value is provided from the aircraft equipment. In this case there may not be a
fault in the aircraft elements, other than the instrumentation itself.
Detection of faults for each aircraft element (including itself, like the Pitot tube)
should be presented in the ASC framework as a model of faults. The sets of values
associated with each element are read from flight data, and then this data—let us
call them variables—are compared with those expected from the model of the
elements.
There is no doubt that the ASC approach, when implemented as a software
framework, needs to have a set of models for the aircraft components or elements.
Models should include a scheme “customisation” for each kind of aircraft compo-
nent or element and be able to configure for that specific type. Then by choosing a
concrete subsystem we will be able to demonstrate the activeness of system control,
including active safety, all using the GLM of dependencies in terms of faults and
behaviour and fault propagation via the dependency matrix.
The discrepancy in an element’s behaviour is made manifest either by data
values or trends in data values, and provides the indication(s) of a fault. This is
then further analysed by the previously mentioned algorithm to determine the most
likely source of the fault. After that is known, a remedial action from the available
set (derived from the recovery matrix) can be chosen and activated or
recommended when the pilot is involved.
What is crucially important for modern aircraft is that the ever-growing use of
ICT applications on-board, up to the level of fly-by-wire, means that the faulty
behaviour of instrumentation and on-board computer system must be considered, as
well as sensor and executive mechanisms. Any action along this path or research
and development should be welcomed; the inadequacies of the ICT system on the
Air France A340 travelling from Brazil to France on June 1, 2009, cost over
200 lives.
Further demonstration of fault detection and searching for potential conse-
quences, as well as the ability to determine faulty elements using ASC and to
visualise flight parameters that reflect faulty behaviour, will be presented below
based on material in Deliverable D3.1 and D3.X of the ONBASS project [7, 9],
which was submitted to EC DG Research in 2006, and presented to Airbus safety
specialists in Toulouse in 2007 [17] and to EASA in 2007.
The avionics of an aircraft can be classified using channels for:
• Displaying flight navigation information
• Automatic and semiautomatic flight control (management and guidance)
• Warning for critical modes
• Navigation and control of radio aids
• Aerometry
• Radio-location and observation of the air environment
Here two channels are considered, namely, the channel of aerometry and the
channel of flight control. The structure and content of the channel of aerometry is
presented in Fig. 9.6. As a main indication means that a multifunctional indicator
(MFI) is used. Information on MFI is received from a system of air-signals, ADS1
and ADS2. Selection of an ADS-airborne digital system is performed by pressing
MFI
to consumers SH 1.2 SH 2.2
TPP
ADS2
A
STS2 SI
HC
STS1
ADS1
TPP
SH 1.1 SH 2.1
to consumers
Fig. 9.6 This diagram shows the scheme of a dual redundant aerometry channel
buttons adjacent to the MFI. As a back-up, the devices airspeed indicator (AI) and
altimeter (A) are used.
A multichannel unit HC is used for checking conditions of heating an air
pressure device (TPP). As a source of faults one might consider:
• Two TPP together with related pipes of full pressure (TPP1, TPP2)
• Pairs of sensors of static pressure together with two looped pipes of static (SH1,
SH2)
• Two systems ADS (ADS1, ADS2)
• Stagnation temperature sensors for both channels (STS1, STS2)
• Reserved devices to indicate SI, A8
Faults that lead to an indication to stop are caused by the following reasons:
• Fault of heater TPP, controlled by unit HC (if icing takes place)
• Fault of computer ADS; accordingly, height–speed parameters
• Fault due to the breakdown of electrical wiring in the cable of the temperature
sensor
“STS–ADS” in the channel of temperature
Faults that lead to faulty measurements might occur due to the following
reasons:
• Block or loss of hermetic state SH, TPP
• Functional fault of СВС; accordingly, height–speed parameters
MFI
TPP
ADS2
A
HC STS2
SI
STS1
ADS1
TPP
Fig. 9.7 Situation with blocking of a sensor or pipeline SH2 (dpSH2)
A full list of faults of the elements at the channel of aerometry is presented in

Table 9.4. The table presents the following values: Vdv, device-defined speed; Vtr,
true speed; Нb, barometric height; Тe, temperature outside aircraft.
For further analysis, we will use a developed dictionary of faults for an
aerometric system that is summarised in Table 9.4.
Localisation Procedure
Features
Based on the structure of a system, its faults can be divided into two groups. The
first group (well-localised faults) is defined without any alternative. This is the case
when we determine the propagation or complete pairing of branching of manifested
faults. The second group of faults appears when, in the model of the system, we face
uncontrollable branching of ways for their propagation. These faults are condition-
ally called “hardly localised.” To further improve the success in the process of fault
detection and recovery, one might use the recommendations for system design
regarding the balance of checking and recovery from [4, 5] which is further
developed in [6].
Localisation Procedure: A Simple Case
For an example of a fault, based on the discussion above, one might assume the
blocking of a sensor or pipeline SH2 (dpSH2). The general class of faults is in the
channel of aerometry and is highlighted in red (Fig. 9.7). Manifestations of this fault
include:
• Freezing the determination and displaying on the MFI the barometric height Нb
from ADS2
• Freezing the measurement and indicating on the reserved device A of barometric
height Нb
• Differentiation of the detection and display of barometric height Нb on the MFI
and reserved device (indication from ADS1)
• Faulty determination and displaying on the MFI of the true speed Vtr from ADS2
• Faulty determination and display on SI of the true speed Vtr
The localisation algorithm in this case correctly determines the faulty element
using a combination of appearances/manifestations of faults. At first, it is defined by
the existence of reserved devices that allow the exclusion of faults caused by ADS
and the first pipeline of static pressure.
The result of using the search algorithm is shown in Figs. 9.8 and 9.9. The first
one corresponds to pilot choice for a computer ADS2 and the second one does for a
computer ADS1. The difference is clear through values indicated by MFI.
These two figures result from simulation of flights with the model of faults
within the air pressure system and the ability to advise the pilot by marking with red
boxes the values and devices he or she can trust.
Fig. 9.8 Searching of an SH2 fault (ADS2 is chosen)

Summary and Conclusion 265
Fig. 9.9 Searching of an SH2 fault (ADS1 is chosen)
It is stressed again that the ability of aircraft control systems to operate in the
way proposed here is largely ignored in many “state of the art” systems, while the
complexity of the control system and fly-by-wire systems are growing with no
justification. This is leading us directly to greater danger for the aircraft’s primary
users: pilots, passengers and innocent bystanders on the ground.
The human factor aspects of each possible fault scenario and its context need to
be considered so that the pilot is always presented with a simple, clear, consistent
and unambiguous warning. Advice to the pilot should also be provided if and only if
it can also be objectively and authentically determined with a high level of
confidence.
Summary and Conclusion
• We have described how ASC can be applied to the design and analysis of active
safety systems using a collection of dependency matrixes that describe depen-
dent input information, dependent states of a system and dependencies of
physical components or elements of the system.
• The matrix of element dependencies has been described using our original GLM
notation.
• As follow-up to the ONBASS project, we described a GLM in algebraic form,

explaining that so far there is no known descriptive model that possesses the
power of analysis competitive with our approach.
• The way in which our original and patented forward and backward tracing
algorithms and analysis of dependencies can be used based on the physical
form of the system has been illustrated.
• We pointed out that the forward and backward tracing of the potential source of
fault and potential consequences might not always be straightforward and easy.
Whenever the logic operator OR is applicable for both the input and output links
of dependencies the more that uncertainties within the system, and the outcomes,
are exposed and the methods of handling them have to be practically devised. So
the modelling exercise may require much thought, analysis and discussion.
Several iterations may be required to comprehend the implications of the require-
ments and to resolve uncertainties when mutually exclusive variants are
introduced.
• At the same time, the amount of possible cycles within this collection of matrices
is countable and has its limit. Thus, our approach provides exceptional predictive
power for the analysis of complex systems both at the conceptual phase of
system design and during development and operational use.
• An example of an air pressure system illustrated that our approach, even in the
presence of a fault in the system, can define consequences and signal which parts
of the system are still operational and which require urgent attention, or at least
can be ignored. This example, developed by us during 2005–2006 was regretta-
bly proven to be right in the AirFrance A340 accident in 2009. Without blaming
anybody, we can say that more could have been done and implementation of the
approach proposed here could have been vitally important.
Acknowledgements Dr. V. Bukov, working as a consultant for the ONBASS project [9],
contributed to the “algebraic” description of the GLM representation, while his colleagues
contributed to modelling and simulation of an experimental aircraft air pressure monitoring system.
We sincerely appreciate the help of our colleagues and friends and offer our heartfelt thanks.
References
1. Schagaev I, Sogomonyan E (1988) Hardware and software of fail-safe computing systems

Automat. i Telemekh 2:3–39
2. Monkman S, Schagaev I (2013) Redundancy þ reconfigurability ¼ recoverability. Electronics
2:212–233. doi:10.3390/electronics 2030212
3. Schagaev I, Kirk B, Schagaev A (2006) Method and apparatus of active system. UK Patent GB
2448351
4. Schagaev I Reliability of malfunction tolerance. In: Proceedings of the international multi-
conference on computer science and information technology pp.733–738, ISBN:978-83-
60810-14-9, issn:1896–7094, 2011
5. Castano V, Schagaev I (2015) Resilient computer system design. Springer, ISBN 978-3-319-
15069-7
References 267
6. Schagaev I, Kaegi T (2015) Software design for resilient computer systems. Springer-Nature
7. Deliverable D1.2 (2005) ONBASS project, FP 6, EC
8. Schagaev I., Control operators vs graph logic model, Proceedings of the International Confer-
ence on Foundations of Computer Science (FCS), WorldComp 2014, USA
9. http://ec.europa.eu/research/transport/projects/items/onbass_en.htm
10. Kirk B et al. (2007) Active safety for aviation, 6th INO workshop, Eurocontrol Experimental
Centre, 04 December 2007
11. Kirk B et al. (2007) Analytical synthesis of aircraft control laws. Paper presented at the 2nd
European conference for Aerospace Sciences (EUCASS), 11 July 2007
12. Schagaev I (1990) Using software recovery for determining the type of hardware fault. Autom
Remote Control 51((3) Part 2):400–409
13. Fault tree handbook with aerospace applications (2002). www.hq.nasa.gov/office/codeq/
doctree/fthb.pdf
14. Шагаев И.В (1990) Определение типа неисправности аппаратуры программными
средствами восстановления вычислительного процесса. Aвтомат.и телемех
выпуск 3:151–160
15. Blaeser L et al. (2014) Evolving systems. CSREA Press
16. Schagaev I (1986) Detecting defective computer in two-unit, fault-tolerant system using a
sliding stand-by unit. Autom Remote Control 47(5)part 2: 717–723
17. PASS: Principle of active system safety, Report on visit Airbus HQ 29.03.06 http://www.it-
acs.co.uk/files/Airbus_visit.pdf
Chapter 10
Active System Control: Future
Igor Schagaev, Brian Robinson Kirk, and Kai Goebel
Abbreviations
ASC Active system control

DM Dependency matrix
FHM Flight health monitoring
FTA Fault tree analysis
GLM Graph logic model
GMDH Group method of data handling
LC Life-cycle
NN Neural networking
Introduction
When discussing the new property of a system—in this case active system control
(ASC) and aviation—we need to be clear about the following questions:
– What is aviation?
– What is an aircraft?
– How can ASC be introduced and implemented?
I. Schagaev (*)
Director, IT-ACS Ltd, 157 Shephall View, Stevenage, SG1 1RR Hertfordshire, UK
B.R. Kirk
Research Director, Robinson Systems Engineering Ltd, Weavers House, Friday Street,
Painswick, GL6 6QJ Gloucestershire, UK
K. Goebel
Tech Area Lead, Prognostics Center of Excellence, NASA Ames Research Center,
Mail Stop MS 269-1, Moffett Field, CA 94035, USA

270 10 Active System Control: Future
LIGHTER THAN AIR

Agricultural
Geological Balloon
CIVIL Airship/Zeppelin
Sport
General Aviation
Medical
Combined
Administrative(Public)
HEAVIER THAN AIR
Commercial AirTaxi
Passenger Wingless
Cargo Backpack
Rocket
Research
Combined
Multiple
Winged
Search&Rescue
DUAL-PURPOSE Immobile Wing
Training
Soft Wing Paraglider
Multitask Paraplane
RigidWing Plane
Reconnaissance Glider
Ground-effect
Plane
Drone Semi-rigid Kite
MILITARY Wing Delta lane
Patrol
Observation Mobile Wing

Rotorcraft Helicopter
Anti-submarine Gyroplane
Gyrodyne
LowTemp.Operation
Flap-hinged
Tanker
Combination
Fighter Vertical
Takeoff
SpecialElec.Equipment
aft
Plane
Direction
of aircr
Attack
T ype
Fig. 10.1 Classification of aircraft by mission and type
– What are advantages and where are the obstacles?

– How will the new property change aircraft and aviation in the long run?
– What improvements can be expected during fight?
– What are the new roles for the pilot?
– What are the new roles of maintenance engineers?
– Do we need to change our approach to insurance for aviation schemes?
These questions will be explored in this chapter to determine what is achievable
to improve aircraft and aviation by applying ASC.
Classification of Aircraft: Reiterated
Two main types of aircraft classification were introduced previously, by primary

mission and by type of aircraft; see Fig. 10.1. The idea of classifying aircraft by
mission and by type was originally proposed by the authors of this book, whereas
expert analysis and detailed development was done by Dr. S. Plyaskota, who was
also a consultant to the ONBASS project [1].
Considering the different missions of aircraft (see the left side of Fig. 10.1)
enables us to evaluate the importance of implementing ASC and estimating its
potential gains and drawbacks in each context. Detailed analysis of how ASC “fits”
aircraft with different missions is worth serious analysis as a new direction of
research in aviation as a whole. It is clear, though, that dual-purpose and military
Classification of Aircraft: Reiterated 271
mission aircraft require special attention in terms of the potential consequences of

accidents. Thus, ASC for these types of aircraft needs to include ASC of the weapon
systems as well as ASC of the aircraft itself.
The interaction between these two systems and how they interact also needs to
be considered; in effect, the scope of the aircraft system needs to be expanded to
include the weapon systems too, so that a holistic view can be taken.
Surprisingly, for general aviation, where on-board mechanical systems and
avionics are less complex, embedding an ASC might be much more efficient and
easier to implement. This has been demonstrated by [1], where the system of flight
modes for the aircraft was rigorously defined and the schemes for evaluating
aircraft conditions, detecting flight mode and handling of faulty devices and control
systems were developed at the level of prototype.
Special attention is also necessary when considering the subclass of training
aircraft. On the one hand, the main factor is the lesser experience of pilots, because
they require much more support from ASC. On the other hand, development of
ASC for this type of aircraft provides powerful support for the training of new
pilots, as well as retraining existing pilots, so they are able to use the new properties
and functions provided.
Half of the recent Flight Global Safety 2016 conference [2] was about training
and on-going education to establish and refresh pilots’ skills needed for handling
complex aircraft. Pilots can quickly become “deadly automatic” and uncontrollable
in the presence of even small malfunctions. The real nub of this problem was very
well explained in detail in recent publications by Tim Harford [3, 4].
Additionally, ASC provides much more “space” to act in emergency situations
and is aimed at enabling an aircraft to be flyable even with degraded systems and
configurations by selecting what is trustworthy and what must be ignored as
currently irrelevant. This separation with support of ASC might have saved Air
France Flight 447 in 2009. Regretfully, time cannot be rerun, but there is no excuse
for avoiding the lessons to be learned from such tragedies and then endeavouring to
avoid them in the future by improving aircraft and aviation systems.
Each aircraft mission has its own specific implementation and thus its own pros
and cons regarding ASC, but this is a vast subject area and the current discussion is
not the place to address all these differences. Instead, we invite readers, aviation
manufacturers, engineers, researchers and scientists, as well as experts from the
CAA, FAA and EASA, to create a consistent and unified plan for improving aircraft
of different types.
Regarding classification by type of aircraft (the right side of Fig. 10.1), this also
provides a challenge and opportunity for the implementation of ASC. For mobile
wing–type aircraft, a malfunction of an engine or wing can become lethal, and
therefore ASC should be organised in such a way as to predict well in advance, and
control with maximum efficiency and intensity, how this type of aircraft will
operate if there is such a problem. In contrast, the Hindenburg disaster in 1937
[5] might have been avoided if it had had properly organised sensors, a system for
gas pressure control, and the ability to monitor deviations to support graceful
degradation and recovery. There may be opportunities, too, to improve systems
on the new generation of airships [6].
What Else Can Active System Control Do?
The ASC framework includes three matrixes that are analysed simultaneously:
• Matrix of inputs (to find/prove their independence and error-free state)
• Matrix of aircraft states (flight modes for this particular variant) to define where
we are during flight and what is the best option to reach scheduled flight mode
• Matrix of elements or modules dependencies, to be able to see conditions and
interactions between elements of aircraft construction
Using available data from sensors as well as historical data, it becomes possible
to make pre-flight and in-flight analyses of the performance of the aircraft’s
engines, their efficiency and to monitor sporadic and systemic deviations that
might be caused by internal reasons, such as fatigue, or external reasons, such as
weather, bad maintenance, pilot errors, etc.
In turn, by tracing the dependencies of a matrix of elements, we are able to
derive a state portrait of the aircraft as a whole, and then prepare the required
on-ground checks and maintenance to be performed after landing. This illustrates
that all three nonfunctional properties—performance, reliability and energy effi-
ciency of the aircraft—can be monitored, analysed and corrected (for) in real time
of the flight and after landing.
And so, ASC can be considered easily as active reliability monitoring and
control, or to put it another way, active real-time reliability (not based on real-
time data after a crash or on thousands of tests to gain reliable statistics). Further,
we can consider all available equipment—sensors, engines, devices, executive
schemes—as parts of the working configuration they also must be efficient in
terms of energy saving. The initial estimation shows that in terms of reliability an
immediate gain of ASC implementation could be up to a factor of 10 [7].
Taking into account that ASC provides the possibility of reconfiguration of the
whole system of the fly-by-wire and control instruments—see Chap. 8 for more
details—we can declare that aircraft handling is increasing, and that reliability and
safety could reach unprecedented levels, by improving and retaining controllability
of the degraded aircraft. More intermediate states between the fully working state
and the fatal state system can enable the aircraft to survive longer.
Generally, by framing the description of an aircraft as a system of three depen-
dency matrixes designed individually and taken together, the number of common
operations increases the number of options that can be used for recovery from the
influence of faults. Smart controllable use of these new options is not “pay as you
go,” it is “use it as you want and are able,” and the point is that you are much more
able than before. This provides more degrees of freedom to improve overall
reliability for the twenty-first century.
Active System Control: Life-Cycle of Aircraft Application 273
The Life Cycle for Process of Aircraft Manufacturing

STATES Z
(e.g. concept, design, development, prototyping, ground testing, start of

field testing, production) exploitation
Z1 Z2 Z3 Zn Zn+1
Performance
Reliability
Energy-Efficiency
pn1
pn2
p12 p23 p34 pn-1,n pn,n+1

p11 p22 p33 pnn
p21 p32
pn3
p31
Fig. 10.2 Active system control impact on life-cycle
Active System Control: Life-Cycle of Design

and Manufacturing
Any good idea has it limits. On-board improvement might cost a fortune during the
maintenance and design phases of a new system or product. Figure 10.2 shows the
life-cycle of designing an aircraft, so we make a brief analysis of ASC in relation to
the form of values of the phases, at least quantitatively.
To be more specific, in practice the processes P1 and Pn might be called concept,
design, development, manufacturing, prototyping, testing, field-testing and volume
production. Table 10.1 shows the impact of involvement of ASC in the phases of
the manufacturing life-cycle.
Feedback from each phase back to the previous one makes the project of
development into an evolution. Here ASC helps to control the amount of feedback
and improvement of the project at every phase as much as possible. This has been
explained in more detail in [13–15].
Active System Control: Life-Cycle of Aircraft Application
In the previous section, we explained qualitatively what ASC can do for the process
of design and development of aircraft, showing where the cost of phases will be
increased and where they will be reduced. But this is not the whole story: the
Table 10.1
Project
life-cycle Impact of active system control implementation
P1 concept Introducing description of information, system structures, probabilities, GLM,
and semantics of matrix links might be costly in comparison with standard
design flow. Doubled efforts are expected at this stage of aircraft design—
based on application of the ASC concept for general aviation aircraft [1]. For
the conceptual phase of CA aircraft the workload caused by introduction of
ASC might be tripled; this is due to the complexity of data input matrixes and
element dependency matrix descriptions. An outcome of these efforts will be
useful in the next phases of aircraft design and especially development and
maintenance
P2 design Fault tree models (FTM) [8, 9] were known in the design of safety-critical
systems for a half-century, if not more. The complexity of FTM designs
exceeds the complexity of introducing ACS for the same system, thus reducing
the workload in this segment of system development. The complexity of the
section of dependencies of input variable and their monitoring of potential
dependencies might be estimated by the group method of data handling [10], to
name one, or NN and AI approaches, when possible. Taking into account that
flight data might be considered as functions over time, the complexity of this
part of the work is defined by (n,{f}), where n number of functions and an {f}
set of functions are applied
P3 During this phase the programming of ASC is extra and nontrivial effort. At the
development same time, applying various weights such as cost, time (in terms of delays, i.e.,
performance), reliability, the GLM makes it possible to control the whole
project flow within an expected and feasible flow. The GLM analysis, within
the dependency matrix of the presence of logic operators XOR, makes it pos-
sible to navigate about potential drawbacks of the whole design and helps
improve flexibility (i.e., degrees of freedom)
P4 The use of ASC software during manufacturing enables checking, quality
manufacturing control and verification of the project since questions of operations in the
presence of a fault, or deviations might be implemented automatically,
choosing any of the nodes from all three defined matrixes, <Di, DS, De>
P5 prototyping ASC software makes possible an unprecedented level of completeness of
design supported by simulation and prediction of system behaviour well before
it is ready for volume production. Saving costs and effort here are on an order
of magnitude smaller than when the standard state of the art prototyping is
applied
P6 testing As long as ASC predicts well in advance the system behaviour and provides
coverage of faults and errors within the widest class of faults, testing will be
eased by automatic procedures and searching for invariants within the system
in order to be able to operate at various level of degradation. This can be
controlled by a so-called syndrome [11, 12]
P7 field- Use of ASC will reduce the need for field testing in terms of time, workload and
testing costs, leaving mostly testing of sections of the design that do not provide
sufficient information support
P8 production Running in parallel with ASC software during production makes the growth of
quality control and the reduction of costs required for phases and a components
check
Active System Control: Life-Cycle of Aircraft Application 275
Process of Aircraft Exploitation with Maintenance
NB: green circles are for profit,

light brown for costs
Known state
of an aircraft
over time
Knowledge about
state of aircraft
decreases as
flight progresses
Knowledge about
system restored
after maintenance
cycle
FLIGHT FLIGHT FLIGHT & MAINTENANCE CYCLES FLIGHT
Zn+1 Zn+2 Zn+3 Zn+x Zfin

Performance
Reliability
Energy-Efficiency
TIME
Fig. 10.3 The life-cycle of aircraft maintenance
aircraft life-cycle splits into two topologically different areas: the development is
shown in Fig. 10.2 and the exploitation in Fig. 10.3.
Green nodes of the life-cycle in Fig. 10.3 represent the states of an aircraft during
flight. Light brown states are about maintenance. It is clear that as an aircraft state
becomes less and less known and its maintenance state becomes less and less
reliably known, an aircraft must be either scheduled for overhaul or, if necessary,
decommissioned.
Grey nodes illustrate that all three key design requirements—performance,
reliability and energy efficiency (PRE)—become less and less known and degraded,
causing the need for maintenance to restore all of them back to the required level for
safe operation. Also, the speed of degradation of P-, R- and E- might be quite
different, creating a need to have all of them monitored within acceptable limits.
It is apparent that feedback between sequential flights, in terms of improvement,
does not exist. Instead, at each phase of each flight, knowledge about the current
condition of the aircraft becomes less and less known. This is caused mostly due to
accumulation of malfunctions, fatigue of equipment and aircraft elements, different
climate zones and the cumulative effects of inadequate maintenance. All these
factors reduce our confidence regarding the condition of the aircraft and force
periodic maintenance. Note here that so far periodic and preventive maintenance
are based mainly on “wishful thinking.” This is because:
(a) The information available about aircraft condition is not processed either in real
time or after each flight
(b) There is no tangible model that captures the aircraft’s condition and, therefore, no
algorithms can be used to rigorously define the required level of confidence in it.
This is why ASC might be extremely useful in practice—both points will be
addressed. Note that the design cycle of aircraft is typically 5–8 years and that its
operational use may extend over 20 or more years. So the payback period is already
long and getting even longer as time goes on.
So, the more we know about an aircraft’s condition and the feasibility of being
able to address potential new problems, the better, hence the aspiration toward
“zero maintenance.”
Active System Control: Risk Information Paradox: RIP?
What is the importance of ASC and where is a logical niche for this concept? There
are several significant aspects, but probably the most natural aspect arises out of the
so-called risk information paradox. The abbreviation actually has a double meaning
that might be helpful: RIP.
Before each flight an aircraft is supported with various manuals, procedures,
tables of parameters, testing and maintenance, and a lot of regulatory information.
For the moment, let us call this “historic” information. During sequential flights and
maintenance periods this initial historic information is updated.
It is expected that after each flight some new flight data will be processed for
various purposes—quality control, tests of aircraft equipment, pilot behaviour
patterns, diagnostics of potentially sensitive subsystems to arrange targeted and
timely planned maintenance, etc. Then the new information that is gathered “during
flight” is combined with the “after flight information”; see Fig. 10.4. The results can
then be integrated with historic data and be distributed not only to maintenance or
Fig. 10.4 Type of aircraft We do have information…

information vs. flight
During flight After flight Integrated with historic data

Active System Control: Risk Information Paradox: RIP? 277
insurance companies and bodies, but also to developers of aircraft and even
regulatory and certification bodies.
It is clear that eventually flight data will be less and less critical while depen-
dency matrixes of ASC will be enriched by aggregated and processed information.
Then current information will mostly be used for the purposes of fault detection and
prognostic prevention of aircraft deterioration by way of faults or mishaps (using
ASC).
Surprisingly, there is a very strange and absolutely unnatural paradox. Whereas
the English proverb is: “Forewarned is forearmed,” a similar Russian one is, “If I’d
known where I’d fall, I’d have put a pillow there.” With aviation there is the
following unnatural situation:
– During “take-off,” recorded information may vary from 150 MB to 1 GB with a
mean 0.28 GB for typical aircraft in CA
– During “cruise,” the mean value over several hours in a regular flight might
achieve 0.18 GB
– During “landing,” flight data accumulation might be easily higher than 3 GB for
testing flights, but based on our experiments it does not exceed 0.5 GB
The upper part of Fig. 10.5 illustrates the volume of flight data in these three key
flight phases of a typical CA aircraft. And we do have a paradox here: according to
Boeing’s comprehensive statistics [16] and ongoing statistics from Flight Global
Fig. 10.5 More information does not mean more safety or efficiency
[17], the proportions of accidents and flight risk are highest for flight phases about
which we have the most information!. . . so data per se does not improve safety.
What is wrong here? Why does more information not bend the left and right
wings of the red curve of Fig. 10.5 downward?
The answer is actually pretty philosophical: Francis Bacon’s proverb “Knowl-
edge is power” is actually wrong, just as is the current ICT declaration that the more
data the better—“big data,” supercomputer data centres, data support of every step
of business or industrial process is a key, etc.
All of this is profoundly and perfectly wrong. It reflects the desire of pedagogists
to exaggerate their role and industrialists to sell more data centres. How and why
these two trends should relate to aircraft safety, performance and efficiency we do
not know! The answer must be elsewhere.
What is really required is to have a system that will be able to keep an object,
here an aircraft, in a practical “safety zone” by using available information and
making corrections not due to analysis of data interpolation, but instead based on
data interpretation. The active system control concept might be promoted to cover
the “performance zone” and “efficiency zone” as well.
Getting benefits from data interpretation is only possible when there are models
of objects that enable us to determine the problems, and when a scheme of control
and reconfiguration is always at hand if necessary to take corrective action or to
mitigate consequences.
So far, there is no concept that can offer anything tangible to solve this RIP
except the concept proposed and developed in this book—active system control.
There is no doubt—what is possible on-board is different than what is possible
on-ground. When an unpleasant sequence of events occurs, we must react in real
time to avoid deterioration and make best steps to keep the situation after control.
After landing we mostly should deal with data handling for the aggregation of
flight data with historic data about specific aircraft and provide for tuning of
maintenance and (NB!) automatic control of the quality of maintenance after that.
Surprisingly, this is possible.
The next section gives some illustration of limitations.
Active System Control in Almost One Page, “During”

and “After”
In Fig. 10.6 the red box and links illustrate where active system control is located
for existing systems of flight control. Having models of an object, its faults, and
prepared reactions Mo, Mf, Mas, respectively, we can:
– Correct faults of data inputs
– Flight control system itself
– Flight control outputs
Active System Control Dependency Matrixes: Who Is Doing What 279
Flight
Control
Flight Data Outputs
Input from
Devices
Flight
Control
System
Risk alerts
Active System and advice
Control for avoidance
Mo, Mf, Mas
Flight data
and trends
recorded in
here
M - model, o - an object, f - fault, as - active system
Fig. 10.6 On-board active system control
This makes it possible for aircraft behaviour to be controllable within a

PRE-smart space, with information available and accumulated in the real time
and active control of the flight.
After a flight, within the typical operational time slot between landing and the
next flight, the ASC ground support needs to process safety checking and data
aggregation. If necessary, the next flight must be blocked if emergency mainte-
nance is required. In this case there is already targeted information available to
guide maintenance and/or repair. Figure 10.7 summarises what needs to be done to
make automatic improvements and enable maximum efficiency of aircraft exploi-
tation and maintenance. Typically there is only approximately 45 minutes between
flights to do this.
Active System Control Dependency Matrixes: Who

Is Doing What
Even the best ideas have limits. Creating a structure of three matrixes is one story,
but defining methods and tools that enable us to make optimum use of the ASC
structure of dependencies is just as important as the invention of ACS itself.
Figure 10.8 summarises available approaches to dealing with each meaningful
segment of ACS information structure.
Unloading
Cleaning,
Turn to service < 45 min consumer
goods
Refuelling
Unloading
Boarding
Safety
checking?
Fig. 10.7 Active system control: time slot after landing
Active System Control: Who is doing what
data& mode& element&
Internal
data&
data
External
data
s,
istic
H , Stat
m ode&
D R “Health” monitoring system &

GM N, ML
N prognostics (NASA, Baesystems,
etc.)
FTA
, GL
M
elem ent&
Safety of flight can be abstracted using a vector: S = < Si, Se >

Si internal conditions; Se external conditions
Fig. 10.8 Active system control dependency matrix: available methods
For monitoring flight data dependencies (especially if the initial assumptions

were wrong), the group method of data handling (GMDH) [10] can be introduced,
such as classic statistics [18], neural networking schemes and algorithms [19], or
the method of linear recovery (MLR) [20].
Active System Control Dependency Matrixes: Who Is Doing What 281
For NN applications it is required to have a “learning” period for data patterns. It

is not critical as events we are able to process on-board are registered with regular
intervals—between time frames of 0.125 s—giving us time to apply our algorithms
using previous data samples. MLR is good to apply for the sections of data and
systems when we are able to repeat a segment or instruction accompanied by
checking the outcome. It mostly filters out malfunctioning devices manifested as
noisy data.
Regarding the central segment of a matrix—the aircraft mode (state)—the flight
mode control registration methods are known and can be applied. Chapter 8 of this
book describes our approach to defining and refining flight modes using
multiparameter analysis. Airbus itself recently announced its own development
[21]. Thus, the solution proposed by Airbus works but not without flaws, for
example, one pilot tried setting a wrong flight mode and nearly killed himself and
the passengers [22].
The flight mode cannot be set, future flight modes are an aspiration! If a flight
mode can be achieved, then when it is, some actions can be requested in a
semiautomatic regime to keep the current flight parameters within margins. This
is reflected in combination as a flight mode.
Here we can proudly declare that this section of ASC is readily evident in an
industrial application.
A system using data dependencies vs. aircraft elements and an element depen-
dency matrix, then known as the concept of dynamic safety (in 1986), was dem-
onstrated in a prototype for Sukhoy 27 in 1994 [24]. It was further presented at
[25, 26] and renamed by others as a health monitoring system [27].
Fault tree analysis [9] was used to describe dependencies of elements and their
impact on each other. In the new ASC scheme these are replaced by a graph logic
model (GLM) [28]. This has been successfully applied in hardware design [12] and
in system software design [11].
Note here the evolution of the naming of the concept of dynamic safety—
properly named now by us as active system control—does not affect the key
concept of ASC described in this book. This renaming activity actually has some-
times misled researchers. This whole book and our previous papers serve one key
purpose: Using data interpretation with a dynamically, self-evolving system of
object description that manages an object with maximum gain in terms of its current
operational properties.
It should be noted that neither the health monitoring “derivative” that we
presented to British aerospace experts at Bristol Filton in 1994, and then to the
York Safety Critical Steering Committee in 1995, nor later as discussed with NASA
[29, 30], address the concept of real-time interpretation to monitor the behaviour of
the system or object and adjust its model or models dynamically.
The Impact of Prognostics on Active System Control
Prognostics is the estimation of properties relating to remaining useful life. The

concept of predicting how long a component can last can be an integral part of ASC
when the remaining life information is being processed to accommodate the
occurrence of faults.
Several aeronautics organizations (such as NASA, the Armed Forces of several
countries, Airbus, Boeing, GE, United Technologies, Lockheed Martin, Bell Heli-
copter, Northrop Grumman and others) are pursuing these technologies, albeit
under a variety of different labels such as integrated vehicle health management
(IVHM), structural health management (SHM), integrated systems health manage-
ment (ISHM) and condition-based maintenance (CBM), just to name a few.
Common to all is an active observation of the component, subsystem, or system,
processing the data, determining the state of health, and taking appropriate action in
response. Figure 10.9 shows this process as a flowchart where raw sensor data are
first examined to ascertain that the sensors themselves are working properly.
Faulty sensors are flagged and data from these sensors are either discounted or
being discounted. Next, features are extracted from the sensors. These features were
crafted ahead of time with the goal of maximising the information about presence
and the magnitude of particular fault modes. Incidentally, the sensors were opti-
mally placed to maximise information content, possibly based on a fault mode
effects and criticality analysis (FMECA).
Ac#ve System Control – NASA View
: ]
tails H MS
o re d e , [ AC P & Raw Sensor Data
M
HM ]
[ IJ P Sensor Validation
Validated Data
Faulted Sensors Flagged
Time-stamped Features, Event Messages &/or

Feature Extraction Parametric Data
Warnings & Alerts

Anomaly Detection/Id Coarse Granularity Id (subsystem level)
Diagnostic Analysis Subsystem Failure Modes
Remaining Useful
Prognostic Analysis Life Estimation
Fault Corrective Action Identification/Reconfiguration/

Accommodation Contingency Management
Fig. 10.9 Prognostic steps and role in active system control

Embedding Active System Control into Aircraft 283
Next, anomaly detection algorithms can report about the presence of signatures
that do not agree with “normal” operations. The warnings or alerts that are the result
of these algorithms do not provide information about the original root cause of the
anomaly.
That is tackled in diagnostic analysis, which attempts to pinpoint the exact
nature of the fault. Further, prognostic analysis determines the remaining life of
the component. This is critical information, which is being input to a decision-
making unit to determine the best course of action. The type of action is dictated in
part by the prognostic horizon, that is, the anticipated time left until failure occurs.
Clearly, if there are only milliseconds left, the action is different than if there
were hours or months left. The decision-making unit can decide whether to
reconfigure the system, whether to re-plan the mission or whether to call for
maintenance at a time of least cost to operations.
Embedding Active System Control into Aircraft
Implementation of active system control requires system software support illus-

trated briefly in Fig. 10.10. It is worth offering some comments that differentiate
ASC from other special-purpose software.
ASC editor
ASC
EGNOS
GPS ASC model
ACU
ACU
FMS DMfd, data
data access
DMfm, logs
ADC
DMae
Sensors
ASC ACU
platform- service
independent operating
code system
Abbreviations: EGNOS – European Geostationary Navigation Overlay Service; GPS –global position system; FMS –flight
management system; ADC–Aircraft data computer, in case of application of ACU for aircraft
Fig. 10.10 System software architecture to implement active system control

The modules ACU, ACS model and ACU data logs are all involved in the real
time of flight functions and serve for data collecting, aggregation, running through
the three matrixes (explained before) and all—and we stress all—potential devel-
opments and impact of change of conditions and regular diagnostics when record-
ing the results (to use for longer-term maintenance and redesign of aircraft).
Design of dependency matrixes for aircraft or similar systems could be done on
any platform with universal platform-independent presentations for both matrix
structures (ASC platform-independent code) and editing tools (ASC editor). In
addition to the real time and service parts of software there is a need to modify
specific aircraft’s dependency matrixes on board.
These procedures are of extreme importance, and critical requirements in reli-
ability and rigorousness, because the failure or malfunction of this subsystem could
be lethal. Thus, the ACU service operating system core simply must be done
correctly and with the highest reliability, i.e., with extreme PRE-properties. How
to achieve it is conceptually described in Luc Blaeser et al. [11], and [20].
Software Organisation of Active System Control
An overview of the structure of the software required to implement ASC is shown

in Fig. 10.11. There are two main sections: application and system software; these
have quite different functions when compared with more conventional schemes and
approaches.
The application part of the software should include three groups of modules:
supportive, making matrixes update the structure and values, preferably using a
platform-independent approach such as XML. A language that incorporates graph-
logic dependencies also needs to be developed. Arguments supporting the need and
advantages of the GLM as programming tool were presented in [25, 29].
On-board ASC software includes data interpolation using methods described in
previous chapters. A module concentrates on running an analysis of potential
dangers by introducing models of faults with a model of the system and checks
behaviour and reasoning about “suspected” elements or groups of elements that
may be suffering a fault.
There is a need to handle data from recorded frames with the ability to extract
what is required and filter non-necessary information. This is a task for the Frame
driver module. The active control segment of the software includes a main cycle of
checking of matrix cortege integrity that includes flight mode detector and predic-
tor, for example, as one presented in previous chapters. The continuous cycle of
checking states and conditions of elements as well as data inputs and appearing
errors or routine checks is a duty of a software subsystem called “cycle of separa-
tion of concerns.”
When a deviation of parameter values or an error in behaviour is detected, either
in data or element dependencies, active system control initiates running forward
and backward tracing algorithms to discover what might be a consequence and
Software Organisation of Active System Control 285
Path of implementation of active system control (software)

Active
System:
Software
Application System
Software Software
Dependency matrix
(conditional Aircraft data RT language
Active control with support of
monitoring) processing
non RT tools HW fault tolerance
DMe tracing RT data

WEB-based Program
Interpolator State predictor backward and Compiler
editor structure control
forward
<DM> cycle of Emmbedded

Recovery real-time OS
Binary editor Detector separation matrix tool
of concerns (EROS)
Graph Logic Maintenance

Frame driver Log
language Core I/O drivers
FT
concurrency
monitor
Fig. 10.11 System software architecture for active system control: overview
prevent propagation of error within the aircraft’s systems. Backward tracing

enables us to define what is most likely cause of the anomaly and also provide
essential information for recovery module/matrix so that further recovery actions
can be activated. The recovery matrix is a collection of software routines that
execute some special actions to reconfigure hardware and system software. It is
called the “recovery matrix tool.”
Active System Control, as a part of safety critical system application domain,
requires hard real-time mode of functioning—so special-purpose system software
should be built to guarantee that the necessary processing is scheduled at the right
time and can be completed within defined time boundaries. It is all programmed in a
language with efficient data structures that provides high performance for real-time
data handling and processing. Very promising examples of new data structures that
possess the properties required for ACS purposes can be found in work [31] and by
Dr Felix Friedrich [11].
Reconfiguration of the hardware, which is required in the case of permanent
faults, needs to be supported by special data structures and operations defined on
them to enable maximum efficiency of recovery. Our separate monographs [12, 20]
provide sufficient explanations for this.
Finally, due to the crucial importance of the identification and isolation of faulty
or erroneous domains of the system, the real-time operation system simply must
possess an ability to handle cases when signals are missing, are lost, or are delayed
and so prone to blocking each other when system itself is overloaded. This may be
supported via a special module called fault-tolerant semaphores.
This concept means that any agent, process, or program in a critical section,
when it is blocked for any reason, must exit the critical section, leaving all resources
for the rest of the system. This concept was introduced by the authors of this book in
the early 1980s and surprisingly has found support in the works of Prof. Takaoka
[32]. A special section of [20] explain this solution in detail.
Active System Control Essential Device: Active Black Box
To expect that the world will quickly adopt a new concept, even a developed and
promising one, is at best naı̈ve. The history of the human race shows that the
evolution of even the most advanced human species was as slow as general
wildlife’s eventual development. In our case, with active system control we foresee
a step-by-step adoption. As one of the key hardware elements that must be
implemented in order to make active system control possible for a wide range of
application is a new black box. We call it active black box for aviation and
transport, or ABBAT.
It must be compact, capable not only of recording but also processing on-board
data, and the complexity of the vehicle is capable of running the algorithms of
active system control. The tough requirements that the black box usually has
regarding temperature, vibration and survivability are exceptional (Fig. 10.12).
The electronics of ABBAT can be implemented using the concept of hardware
Fig. 10.12 Active black

box : active system control
core device
- Impact tolerance 5000Gs/6.5ms

- Fire resistance 1100 deg C/45-60min and higher
- Underwater beacon 37.5 Khz
- Buttery life 6 time higher than exsiting systems;
- Active conditional control functions
- Satellite communication for maintenance and emergency -
Maintenance automatic log;
- MTTF 35 years at 0.995 over the whole period
- Power consumption – 5-6 time less than above
Summary and Conclusion 287
design as described in [11, 12]. The design of physical hardware (mechanics) is

based on the concept of controlled motion after a crash—compacting box size and
defining a shape forced to rotate as the accident occurs. The specifications that need
to be achieved are summarised in the figure.
After this device has been implemented, it will enable the gradual modernization
of vehicles toward ASC. In the chapter about the future we can point out that
research and development of the shape for ABBAT requires serious mechanical
research and iterative development. Our late 1990s discussion with Academic
Alexandrov (Institute of Mechanics, Russian Academy of Science) and the recent
paper of analysis of object motion during flight and contacts with the surface [33]
provide us careful optimism, indicating that the design of ABBAT with required
specifications is feasible.
Summary and Conclusion
• We have described how active system control (ASC) can be developed starting
from classification of an object. Without the “semantics” of an object being
introduced into design, the known mathematical methods would be over-
complex and inevitably inefficient. In ASC the “semantics” are expressed in a
set of dependency matrixes that describe dependent input information, depen-
dent states of a system and dependencies of physical components or elements of
the system.
• The scope of application of active system control across the whole life-cycle of
aircraft design, including “smoothing” the whole design and maintenance pro-
cesses, has been described. These processes are no longer considered separately;
each step of the life-cycle can benefit from the application of active system
control.
• The RIP (risk information paradox) has been exposed, as well as the means for
resolving it by applying the active system control approach for the design of
aircraft, vehicles or any other complex system with moving parts or substances.
• In a compact manner, we explained where active system control can be used
on-board and on the ground after a mission, including essential blocks, models
and timing.
• Existing and required research and results that are applicable for further devel-
opment of the active system control approach have been summarised and
explained illustrating potential options.
• In turn, prognostics, let us say “system-level prognostics,” become more and
more challenging, and in concert with active system control as framework might
be extremely progressive and productive.
• We illustrated how the active system control concept can be implemented in
existing aircraft systems, highlighting what is required in real time of flight and
when it should be included in post-flight automatic analysis.
• The initial structure of the essential software for active system control shows the
structure and organization of system and application software required.
• As an immediate practical solution we have outlined the on-board development
required to initiate active system control applications, including new hardware:
an active black box for aviation and transport (ABBAT).
Acknowledgements This chapter as well as the book has been the product of efforts of several
people. We would like to thank Kai Goebel for his contribution to this chapter. We would also like
to thank Jean Luc Marchand for his constructive suggestions for improving the book; he has (in our
humble opinion) made a significant contribution in Eurocontrol and DG Research in aerospace. Of
course, “perfection” cannot be reached, but the reviewers’ feedback has been welcome and
constructively used. Regarding chapter organisation and design, Simon Monkman made good
comments, and all pictures we have were designed and created by him with the quality that is well
beyond our reach!
Constant support and friendly advice from Springer Editor Mary James made this chapter
completed almost on time. Mr Jonathan Guest and his colleagues from FlightGlobal (RBI) have
stoically addressed, promoted and distributed the concept of active system control as a vision of the
future of aviation; we thank them for their support. We sincerely appreciate all of their help and
offer our heartfelt thanks; sometimes it is nice to be appreciated!
References
1. http://ec.europa.eu/research/transport/projects/items/onbass_en.htm
2. http://www.flightglobalevents.com/FSS16/flight-safety
3. https://www.theguardian.com/technology/2016/oct/11/crash-how-computers-are-setting-us-
up-disaster
4. Harford T (2016) MESSY how to be creative and resilient in a tidy-minded world Little Brown
Book Group. ISBN 13: 9781408706763
5. http://www.airships.net/hindenburg/disaster
6. https://www.youtube.com/watch?v¼qT4fuol5u4M
7. Schagaev I (2008) Reliability of malfunction tolerance. In: Proceedings of the International
multi-conference on computer science and information technology. USA, pp 733–773
8. https://www.hq.nasa.gov/office/codeq/risk/docs/ftacourse.pdf
9. NASA (2002) Fault tree handbook with aerospace applications, Version 1.1. NASA Publica-
tion. August 2002. https://elibrary.gsfc.nasa.gov/_assets/doclibBidder/tech_docs/25.%
20NASA_Fault_Tree_Handbook_with_Aerospace_Applications%20-%20Copy.pdf
10. Ivakhnenko A (1978) The group method of data handling in long-range forecasting. Technol
Forecast Soc Chang 12(2–3):213–227
11. Blaeser L et al (2014) Evolving systems. CSREA Press. ISBN 1-60132-270-4
12. Castano V, Schagaev I (2015) Resilient computer system design. Springer. ISBN 978-3-319-
15069-7
13. Plyaskota S, Schagaev I (1995) Economic efficiency of fault tolerance. Avtomat. i Telemekh
7:131–143
14. Aнулова СВ, Катышев ПК (2004) КОНЕЧНЫЕ ЦЕПИ МAРКОВA С ДОХОДAМИ,
ЗAВИСЯЩИМИ ОТ ПРОШЛОГО. RFFI. sicpro04.narod.ru/code/r04_28.htm
15. Schagaev I, Anulova S, Arabnia H (2015) Quantitative software engineering. In: Proceedings
of the SERP’15, July 2015. Las vegas, pp 103–108
16. www.boeing.com/resourses/boeingdotcom/company/about_bca/pdf/statsum.pdf
References 289
17. www.flightglobal.com/news/articles/report-airline-safety-and-losses-annual-review-2015-
420487/
18. DeGroot M, Schervish MJ (2012) Probability and statistics, 4th edn. Pearson
19. de Castro LN (2006) Fundamentals of natural computing. CRC Press, Science
20. Schagaev I, Kaegi T (2016) Software design for resilient computer systems. Springer, Cham
21. http://www.airbus.com/presscentre/pressreleases/press-release-detail/detail/easa-certifies-
new-autopilotflight-director-tcas-mode-for-a380/
22. https://www.youtube.com/watch?v¼0CCv5D1HZ30
23. http://www.bbc.co.uk/news/technology-33078767
24. http://www.it-acs.co.uk/files/itacs_devices.pdf
25. Schagaev I (1998) The concept of dynamic safety. In: Proceedings of the 16th international
system safety conference, 1998, pp 448–452
26. http://www.istc.int/en/project/B499F6DA9C53A4EEC32568D6001AE42C
27. http://www.baesystems.com/en-uk/our-company/corporate-responsibility/working-responsi
bly/safety/how-we-manage-safety/health-and-safety
28. Schagaev I (2014) Control operators vs. graph logic model. In: Proceedings of the FCS,
WorldComp, 2014
29. https://www.nasa.gov/ames-partnerships/technology/technology-opportunity-health-moni
toring-for-complex-systems/
30. Farrar CR, Lieven NAJ (2007) Damage prognosis: the future of structural health monitoring.
Phil Trans Royal Society A 365: 623–632. doi:10.1098/rsta.2006.1927. Published online 12
December 2006
31. Friedrich F. https://www.inf.ethz.ch/personal/felixf/pdfs/2006_ArrayStructuredOT.pdf
32. Takaoka T The semantics of new while loop. Comp J. Oxford. http://comjnl.oxfordjournals.
org/content/29/1/33.full.pdf
33. Uchida TK, Sherman MA, Delp SL (2015) Making a meaningful impact: modeling simulta-
neous frictional collisions in spatial multi-body systems. Proc R Soc A 471:20140859. doi:10.
1098/rspa.2014.0859
Index
A MAs, 56
Active black box, 286–287 on life-cycle, 273
Active real-time reliability, 272 on-board safety systems, 59
Active system control (ASC), 212, 221, 231 online checking, 197
ACSCU, 243 OR and AND, 244
active, 45 passive, 45
aircraft classification, 270 periodic maintenance, 194
aircraft model, 193 preventive maintenance, 194
algorithm, 250, 252, 286 principal difference, 192, 249
application, 242 prognostics, 282
ATO, 56 rail domain, 57
automotive domain, 49 real-time structural models, 190
automotive market, 51 recovery matrix, 252
aviation academics, 191 reliability corridor, 200
basic logic operators, 246 reliability curve, 201
CAN, 48 reliability function, 196
CoDySa, 192 safety aspects, 241–242
element modelling, 260 safety lifecycle, 47
element’s behaviour, 261 safety requirements, 189
ERTMS, 58 safety systems, 45
fault handling, 243 SH2 fault, 265
flight modes, 281 SIL, 65
framework, 255, 271 software architecture, 283
GAFT, 243 space domain, 60
GLM, 244 VRS, 61
human factor, 47 Active system control and flight safety, 144
ICT, 190 Active system control and safety, 131, 134
industrial systems, 48 Active system control unit (ACSCU), 243
inverse analysis, 246 Active system safety, 69
IVHM systems, 61 Advanced recorders (AR), 105
journey data, 59 Aerometry channel, 262
life-cycle, 275 Aeronautics organizations, 282
localisation procedure, 263–266 Aerospace, 3
maintenance period, 199 Air pressure system, 256–266
manufacturing life-cycle, 273 Aircraft characterisation matrix (ACM), 229

I. Schagaev, B.R. Kirk, Active System Control, DOI 10.1007/978-3-319-46813-6
292 Index
Aircraft classification, 4, 5 GAMA, 7

Aircraft elements, 158 military aircraft, 6
Aircraft flight PASC, 1
aviation, 91 phases are characterised, 27
CA and GA, 86 risk factors, 3
CAA and FAA, 89 safety, 24
components, 74 technical specification, 12
external and internal aspects, 94–96 US Air Force, 10
hardware and software, 92 ОD and OS, 5
laws and regulations, 91 Aviation insurance policies, 39
modern aviation, 80 Aviation safety management systems, 91
MTTF, 78 Avionics system, 225–226
on-ground management of safety, 87–89
operational cycle, 89
operational reliability model, 74 B
parameters, 96 Basic logic operators, 246
profit margins, 87 Boeing airlines, 16
risk and statistics, 94 Boeing’s comprehensive statistics, 277
safety management, 89–90 British aerospace, 192
Aircraft inspection procedure, 88 British Airways Safety Information
Aircraft market System, 110
CA, 16 Budget airlines, 86
EU forecast, 16
fuel prices, 22
GA, 18 C
helicopters, 21 CA flight data parameters, 112
military, 14 Chain mode flights, 83
Aircraft mission, 271 Challenger safety system, 85
Aircraft Owners and Pilots Association Civil aviation, 7
(AOPA), 7 Commercial aviation (CA), 16
Aircraft system, 141, 226 Concept of dynamic safety (CoDySa), 191
Aircraft’s true air speed (TAS), 173 Concorde flight data, 103
Airline operators, 90 Conditional maintenance theory, 191
Airworthiness directives (ADs), 113 Conditional preventive maintenance, 128
Algorithmic function definition, 133 Coverage of faults, 129
Artificial intelligence models, 164 Critical emergency situations, 100
Australian GA accidents, 32
Automatic train operator (ATO), 56
Automobile manufacturers, 54 D
Automotive community, 49 Damage prognosis model, 192
Automotive domain, 49, 50 Dependency matrix, 154, 168
Aviation aircraft, 230
accidents, 7, 25 ASC, 231
aircraft by mission, 7 discrepancy, 222
aircraft manufacturer, 25 element models, 215
AOPA, 7 Design standardisation, 48
ASC, 4 Diagnosis of the problem (of control), 126
CA, 16 Digital avionic systems, 103
classification, 5 Digital flight data recorders, 104
definitions and terminology, 4 Dijkstra’s method, 133
flight data processing, 11 Driving safety systems, 50, 56
GA, 18 Dynamic safety, 1
Index 293
E real-time diagnosis, 223

Each matrix element, 169 safety, 229–231
Economist magazine, 80 XML specification, 232–239
Element models, 167–168 Flight mode detector, 223
Element-modelling techniques, 163 Flight phase accident statistics, 36
Eurocopter Consortium, 23 Flight risk analysis
European aircraft market forecast, 17 causes/factors, 36–37
European airlines, 16 NTSB, 34
European and US aviation, 102 occurrence codes, 35
European Automobile Manufacturers Flight safety, 40–41
Association, 53 Flight safety systems (FSS), 60, 76
European industries, 125 Flight simulator package, 157
European Rail Transport Management Flight trajectory, 60
System, 57 Flightglobal safety Symposium, 189
Evaluators, 163 Flights safening, 60
FTA and FMECA analyses, 133
Functional faults, 243
F Functional models, 165–166
Fault localisation, 254–256 Functional safety, 62
Fault mode effects and criticality analysis
(FMECA), 283
Fault tree analysis, 34, 281 G
Faulty sensors, 282 GA accident statistics, 81
Flight control signals, 87 GA safety monitoring, 113
Flight data General aviation, 99, 101, 121
memory, 227 accident statistics, 30–33
software architecture, 227–229 risk and safety, 30
Flight data array, 156 UK GA accidents, 32–33
Flight data matrix (FDM), 223 US GA accidents, 30–31
Flight data memory (FDM), 225 distribution, 20
flight data simulation (FDS) module, 111 features, 20–21
Flight Global Safety 2016 conference, 271 The General Aviation Manufacturers
Flight mode Association (GAMA), 7
aircraft conditions, 209 Generalised algorithm of fault tolerance
algorithms, 212 (GAFT), 133, 243
analysis and detection, 211 General-purpose aviation (GA), 7
ASC, 210 Global positioning system (GPS), 80
assumptions, 210 Government accident investigators, 40
boundary conditions, 212 Graceful degradation systems, 134
configurability, 224 Graph logic model (GLM), 169, 244
definitions, 213–217 Group method of data handling
dependencies, 209 (GMDH), 280
detection algorithms, 217–220
determination, 223–224
flight crew, 220–221 H
flight performance, 229–231 Hardware-based redundancy types, 135
goals, 210 Hazard analysis, 63
information processing, 221–224 Health monitoring systems, 1
information vector, 209 Helicopters, 21–23
intended flight, 210 High-profile accidents, 46
objectives, 212 Hindenburg disaster, 271
PASC, 211 Horne’s classification, 105
prognosis, 223 Human machine interface (HMI), 220, 225
294 Index
I On-board active system control, 279

Industrial systems, 46, 62 On-board mechanical systems, 270
Integrated vehicle health management (IVHM) On-board safety systems, 53
systems, 60 Operational aircraft, 129
International Civil Aviation Organization Operational use, 52–53
(ICAO), 82 Ordinary differential equations
International System Safety Conference (ODE), 165
(ISSC), 34
Inverse analysis, 246
Inverse tracing analysis, 246 P
Partial differential equations (PDE), 166
Physical safety systems, 49, 55
J PLR Information Systems Ltd, 107
Joint availability (JA), 79 Point availability (PA), 78
Post-accident situations, 100
Preventive maintenance, 191, 194, 197, 199,
K 205, 206
Kinetic energy, 60 Principle of active system control (PASC), 191,
209, 229
algorithm, 134, 173–176, 182
L backward tracing implementation, 187
Landing phase, 162 benefit, 125
Latency period, 84, 136 CA aircraft, 155
Liability coverage, 40 cruise phase, 161
Life-cycle activities, 65 cycle of operation, 152
Localisation of faults, 249, 252 defining and implementing, 126–129
element-modelling techniques, 163
equipment, 126
M factors, 152
Markovian properties, 76 flight data, 157
Mas models, 132 flight modes, 155, 159
Mean time between failures (MTBF), 107 functionality, 123, 176
Measure of mean time to failure (MTTF), 78 GA, 150
Method of linear recovery (MLR), 280 GAFT, 133
Military aircraft, 6, 113 global supportive, 122
Military aviation data, 107 implementation, 149–184
Military flight data, 109 landing phase, 162
Minimum operational performance MASCA, 153
specifications (MOPS), 105 node, 180, 182
Mission availability (MA), 78 object’s sensors, 155
Model of active system control for aircraft parameters, 130, 158
(MASCA), 152 phases of flight, 151
Movement authorities (MAs), 56 purposes, 151
Multifunctional indicator (MFI), 262 service packs, 130
software, 158
structure, 127, 150
N take-off flight phase, 161
Numeric matrix calculations, 248 threshold-based models, 166
tracing node, 179
vehicle’s main flight, 125
O Probability matrix, 171
Object of danger (OD), 4 Prognostic methods, 192
Objects of safety (OSs), 4 Programmable logic controllers (PLCs), 57
Index 295
Q Space domain, 60
Quantitative analysis, 205 Space Shuttle Challenger disaster, 84
Statistical data processing, 170
Statistical learning model, 164
R Statistical models, 165
Rail accidents, 54 System software architecture, 285
Rail safety systems, 54 Systems of objective Checking (SOC), 6
Railway systems, 64
Real-time reliability, 192, 202
Recovery matrix (RM), 154, 172 T
Recovery matrix tool, 285 Take-off flight phase, 161
Redundancy theory, 122, 128, 134–137 Thrust termination, 61
Reliability engineering, 194
Reliability models, 75, 77
Route safety systems, 49 U
Route topology, 55 UK Civil Aviation Authority (CAA), 32
Russian space program, 85 UK GA accident types, 33
UK Safety-Critical System Task
Force, 192
S Unmanned autonomous change vehicles
Safety Board meetings, 109 (UAV), 215
Safety control problem, 95 US GA accidents, 31
Safety improvement, 57 User-based redundancy types, 136
Safety integrity levels (SILs), 65–66
Safety integrity requirements, 63
Safety maintenance, 80–86 V
Safety management scheme Vehicle destruct, 60
aircraft operations, 39 Vehicle parameters, 51
failures, 42 Vehicle recovery system (VRS), 61
NTSB, 38 Visual graphing, 247
replacement value, 39
Safety-related checks, 52
Semaphores, 54 W
Sensors, 99 What we know (WWK), 146
Service packs, 130 World accident fatalities, 27
Shuttle accident sequence, 85
Sikorsky boasts, 23
Small industrial systems, 47 Y
Software-based redundancy types, 136 York Safety Critical Steering
Solid state universal flight data recorder Committee, 281
(SSUFDR), 105

Active System Control Design of System Resilience

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Active System Control Design of System Resilience

Uploaded by

Copyright:

Available Formats

Igor Schagaev · Brian Robinson Kirk

Active System Control

ISBN 978-3-319-46812-9 ISBN 978-3-319-46813-6 (eBook)

Library of Congress Control Number: 2017945950

© Springer International Publishing AG 2018

Printed on acid-free paper

This Springer imprint is published by Springer Nature

Stevenage, UK Igor Schagaev

1 Aviation: Landscape, Classification, Risk Data . . . . . . . . . . . . . . . . 1

Safety Approach in the Automotive Industry . . . . . . . . . . . . . . . . . . . 49

The Safety Maintenance Landscape: Commercial

Improving the Control and Safety of a System . . . . . . . . . . . . . . . . . 140

A Trial Architecture for Flight Mode Detection . . . . . . . . . . . . . . . . . 224

Professor Igor Schagaev is the Director of IT-ACS

Dr. Brian Robinson Kirk is the founder and Director

© Springer International Publishing AG 2018 1

– An information flow model

Fig. 1.1 Scope of the work

Fig. 1.2 Structure of the

Market analysis, classification, regulations, requirements

Key features of aircraft and spacecraft

Technological profile of design, maintenance and safety

Principle of Active System Control (PASC)

Theory and methods of implementation

Survey of the Aviation Application Domain

Each object of danger has one or a number of factors of danger or so-called

A defining (or “principal”) attribute is that attribute of a substance which distinguishes it

Classification of Aircraft by Mission

According to generally accepted standards (e.g., Federal Aviation Require-

Commercial Air Taxi

Search & Rescue

Low Temp. Operation

Special Elec. Equipment

Fig. 1.3 Classification of aircraft by primary mission

LIGHTER THAN AIR

HEAVIER THAN AIR

Soft Wing Paraglider

Fig. 1.4 Classification by the type of aircraft

Classification by Type of Aircraft or Method of Operation

The type of an aircraft is defined by its construction and method of operation

There are five levels of branching based on:

Classification by Technical Specifications

Aircraft can be defined by their consumer features and technical specifications.

Classification by State of Development

Another important classification group for aircraft is their state of development.

Flight Weight (Take-off) Super-light Light Middle Large

< 49 49 - 79 79 – 118 118 – 171 171 – 214 214+

Cruising (Air) Speed Subsonic Supersonic Transonic

Power Plant Characteristics

None Single Double /

Coaxial Reblade Straight Multi (N)

Flight Control Rudder Type

Airframe Scheme Monocoque Classic Canard

CIS Design Cockpit Instruments

Pilot Static System

Other Onboard Systems

Fuel System Configuration

Electrical System Configuration

Fig. 1.5 Classification by technical specification

The Aircraft Market

Fig. 1.6 Sales of military and civil aircrafts

According to analysts, despite some stabilisation of deliveries of military aircraft in

Near East & China South Asia

Fig. 1.7 Export market for military aircrafts