Formal specification of requirements for analytical redundancy-ba

Analytical redundancy

Fault tolerance in systems necessitates redundancy, which allows for continued operation despite localized failures There are two main approaches to redundancy in closed-loop systems: physical redundancy and analytical redundancy Physical redundancy employs a multichannel architecture with three or more independent systems that communicate with each other, utilizing a voting mechanism to ensure consistency among components In contrast, analytical redundancy relies on software routines rather than additional hardware, processing sensor and actuator outputs to verify consistency with the system's analytical model When inconsistencies arise, the faulty component is isolated, and the control law is adjusted This method maintains observability for estimating isolated sensor measurements and controllability for managing isolated actuators Numerous resources explore the theoretical and practical applications of analytical redundancy for achieving fault tolerance.

The conceptual framework for analytical redundancy-based fault detection and identification systems is divided into two primary stages: residual generation and decision making Residuals indicate discrepancies between a system's actual performance and its analytical model, with values near zero suggesting a fault-free operation, while non-zero values signal potential faults The decision-making stage processes these residuals to detect and isolate faults, employing various algorithms ranging from simple threshold tests to advanced statistical methods like the Generalized Likelihood Ratio test and the Sequential Probability Ratio test To enhance fault tolerance, a recovery stage is also essential, utilizing adaptive or multi-model control laws based on insights from the decision-making stage Each of these three stages is crucial for the effectiveness of a fault-tolerant control system, although much research has predominantly concentrated on the residual generation aspect.

Since the early 1970s, various techniques for generating residuals have been proposed in technical literature, beginning with the geometric approach that led to the Beard-Jones Fault Detection Filter These detection filters create a residual vector with distinct directions for each faulty component, enabling both detection and isolation of faults Key design considerations for these filters are discussed in sources [46] and [45] Additionally, the dedicated observer approach offers a deterministic method for achieving fault tolerance, particularly in the context of sensor failures.

The system utilizes a network of observers, each analyzing a specific portion of sensor data to generate estimates of the overall state vector By comparing these estimates from various observers, the system effectively detects and isolates discrepancies in the data.

Initially, the scheme was applied using Luenberger observers, later expanding to non-linear observers, Kalman filters, and neural-network based estimators The parity relation approach creates invariant relationships among system inputs and outputs derived from the system's state space model These methods primarily concentrate on system inputs, outputs, or state variables to generate the residual vector In contrast, a parameter estimation approach aims to estimate unmeasurable system parameters that are directly linked to the fault source While the differences among these techniques are largely conceptual, research indicates a practical equivalence between parity relation and observer-based methods, as well as between parity relation and parameter estimation approaches.

Early analytical redundancy-based residual generators exhibit weaknesses, particularly in their sensitivity to process disturbances and limited performance in non-linear system applications The introduction of the unknown input observer approach marked a significant advancement in robust fault detection, focusing on creating a residual vector that remains unaffected by disturbance inputs This was followed by the development of parity relation-based schemes that incorporated robustness through the orthogonal parity relation concept To enhance robustness, design methodologies have increasingly shifted to the frequency domain, allowing for the application of optimal and robust design techniques such as H∞ and àsynthesis.

To address the non-linearity issue researchers extended linear design techniques or adopted approaches based on fuzzy logic [50] and neural networks [57] and [39].

Analytical redundancy in flight control systems

The analytical redundancy approach to fault detection has been utilized across various fields, including automotive engines, electromechanical actuators, and flight control systems Research has demonstrated its application in diagnosing aircraft actuator and sensor failures, particularly in fly-by-wire technology However, concerns persist regarding whether analytical redundancy can satisfy the stringent fault tolerance requirements of flight control systems, which differ significantly from other applications While traditional fault detection focuses on enhancing reliability through monitoring, flight control systems demand the ability to operate continuously after any component failure, with no assumptions of fault-free operation unless proven highly unlikely To achieve necessary fault tolerance, civil and military aircraft implement physical redundancy, such as triple and quadruple systems in models like the Airbus A320 and Boeing B777, prioritizing safety over reliability despite the increased complexity and potential degradation of overall system reliability.

Analytical redundancy poses challenges in the performance evaluation of fault-tolerant systems, particularly in flight control applications These systems rely on the functional redundancy of the aircraft and require validation across the entire operational envelope However, most evaluations utilize simplified aircraft dynamic models, focusing on a restricted flight envelope and a narrow range of maneuvers and fault modes Additionally, the criteria for assessing fault detection and identification systems are often heuristic in nature A comprehensive list of these evaluation criteria can be found in reference [52].

A typical testing procedure for fault detection and identification systems involves simulating a range of failures and calculating performance indexes While these values allow for the comparison of different solutions, they lack absolute interpretation and are significantly influenced by the testing environment Missed detection and false alarm rates become meaningless outside the system's operational envelope, as they depend on various factors, including the disturbances affecting the system and the type of injected fault In non-linear systems, the state of the system also plays a critical role Additionally, if a fault is completely undetectable, it can result in a 100% missed detection rate, which does not necessarily reflect poor performance of the fault detection system but rather highlights a deficiency in functional redundancy.

To effectively evaluate analytical redundancy-based fault-tolerant flight control systems, it is essential to establish a comprehensive requirements specification Validation of these systems can only be conducted in accordance with their defined specifications.

Formal specification of system requirements

Requirements engineering

A successful system effectively meets its intended needs, and requirements engineering plays a crucial role in identifying and documenting these needs for analysis and implementation Understanding the system life-cycle, which includes the concept, development, and operation cycles, is essential for evaluating the importance of requirements in system development The concept cycle focuses on defining the system's main functions and assessing feasibility, while the development cycle encompasses requirements specification, design, implementation, and testing The requirements specification phase bridges the concept and design phases by converting informal needs into clear requirements that guide subsequent design, testing, and operational phases During the design phase, these requirements are transformed into algorithms and physical processes, which are then implemented as software and hardware Finally, the testing phase ensures that the system meets all specified requirements, with successful certification indicating readiness for the operational phase.

Requirements specification and design are interconnected throughout the development cycle, as they involve a hierarchical decomposition of the system based on functional principles Requirements engineering addresses all elements across various levels, with steps of requirements analysis and design alternating to create a series of specifications that reflect different decomposition levels The critical importance of requirements specification is well-documented, highlighting that poor specifications can severely hinder the resulting system and are challenging to correct later Inadequacies in requirements are a significant and costly factor in project failures.

The main activities of requirements engineering are [19]:

Elicitation involves identifying the problems a system must solve and defining the boundaries between the system and its environment Modeling focuses on creating an abstract description of both the system and its environment, which is crucial for requirements specification The system's environment includes all external factors it interacts with and where its effects are assessed System requirements consist of conditions related to environmental phenomena, which can be categorized as shared or private Shared phenomena are common to both the system and its environment, while private phenomena are exclusive to the environment The system can meet requirements involving private phenomena through indicative properties of the environment, which remain true regardless of the system's presence In contrast, optative properties require the system's assurance and are reflected in the requirements A thorough description of the environment is essential for understanding the system's purpose and informing its design.

The specification activity in requirements engineering involves formulating requirements using various formal and informal languages, with the benefits of formal specification languages highlighted Validation ensures that the requirements specification is complete, correct, unambiguous, consistent, testable, and feasible, with completeness often being subjective A formal specification language can help eliminate ambiguity and enhance consistency, while feasibility must be assessed by domain experts to determine if the system can be built to meet the requirements Requirements management is the final activity, acknowledging that specifications will evolve throughout the system's lifecycle Effective requirements management is essential for tracking changes and ensuring traceability, and the IEEE Guide for Developing System Requirements Specifications offers valuable guidelines for structuring documents to support modifications However, due to the extensive nature of these documents, managing specifications without well-engineered tools can be challenging.

Requirements engineering is characterized by its multidisciplinary nature, involving three key agents: customers, domain experts, and requirements engineers Customers articulate the initial requirements based on real-world problems, while domain experts contribute their technical expertise to decompose the system, analyze, model, and assess the feasibility of these requirements Requirements engineers collaborate closely with both customers and domain experts to elicit, analyze, and model the requirements, focusing on specification, validation, and management tasks The requirements specification document serves as the official communication tool among these agents, consolidating essential information for system design and outlining the acceptance criteria for verifying that the system meets real-world needs.

Advantages of adopting a formal specification language

Creating a requirements specification is a complex process that involves extensive engineering analysis, collaboration among various experts, and results in a detailed document with intricate dependencies This complexity often leads to inconsistencies and ambiguities, particularly when using plain English as the specification language To address these challenges, adopting a formal specification language, defined by precise mathematical syntax and semantics, can significantly reduce ambiguity and enhance consistency A formal approach not only facilitates automated analysis but also provides a structured framework that guides the formulation of requirements, ensuring a cohesive document through all stages of refinement.

Adopting a formal language for requirements brings improvements, but it also has drawbacks The necessity for explicitness in all aspects of formal specifications often leads to more cumbersome documents Additionally, the complexity of interpreting these formal specifications can hinder effective communication, reducing the overall clarity of the document.

An effective specification language must be expressive enough to formalize plain-English requirements without adding unnecessary artifacts It should avoid imposing modeling constraints that could skew the structure of the specification Additionally, it needs to be monotonic, allowing for the composition of sub-specifications, which facilitates easy updates throughout the development cycle.

It should be supported by well engineered tools for automatic checking of consistency and for management.

The specification language adopted in this research work is based on predicate logic and relational algebra and is defined in Appendix A

Chapter 1 outlines the research goal of creating a formal requirements specification for a Fault-Tolerant Flight Control System (FTFCS) that utilizes analytical redundancy for fault tolerance This chapter further clarifies the research objective by detailing the system's operational environment and its functional role within that context Additionally, it introduces the aircraft selected as the pilot application for the specification development and references the military specifications that will inform the performance and fault tolerance requirements of the Automatic Flight Control System (AFCS).

FTC: the system to be specified

FTC environment

The Flight Control Task (FTC) operates within the Automatic Flight Control System (AFCS) and is influenced by the overall dynamics of the aircraft As illustrated in Figure 3.1, the functional block diagram of an aircraft with an AFCS depicts various data streams, including forces, moments, electrical signals, and software data In this diagram, square-corner blocks signify hardware components, while round-corner blocks denote software units Additionally, blocks are organized with dashed lines to represent distinct subsystems or systems, highlighting the structured interplay between hardware and software in aircraft control.

The aircraft system encompasses the airframe, control surfaces, and engines, with control surfaces analyzed separately due to distinct fault hypotheses The airframe also accounts for gravitational and air turbulence effects on aircraft dynamics The automatic flight control system (AFCS) consists of the flight control computer (FCC) and its related subsystems, including the processing computers for output (Cout) and input (Cin) The FCC integrates the Flight Control Software (FCSw), which comprises three units: IN for pre-processing, OUT for post-processing, and the Flight Control Law (FCL) that translates pilot inputs and sensor data into actuator commands The Cin and Cout subsystems are designed for their respective input and output functions Additionally, sensors are categorized into primary sensors, which provide critical measurements for the FCL, and secondary sensors, which serve alternative purposes, potentially linked to different control laws not depicted in the diagram.

The block diagram in Figure 3.1 illustrates the essential functions of the Automatic Flight Control System (AFCS) rather than the actual physical components and their connections Specifically, the FCC block symbolizes the collective operation and interface of three physical computers, reflecting the overall behavior of the FCC block within the AFCS framework.

Main functions of the FTC system

The failure of any component within a Flight Control System (FCS) can jeopardize aircraft safety, necessitating a level of fault tolerance in these systems Military specifications outline three degrees of fault tolerance based on the criticality of FCS functions, which are assessed according to the aircraft's operational state following a failure Specifically, the relevant operational state for evaluating fault tolerance is State III.

Operational State III indicates a degraded performance in the flight control system, affecting safety and reliability This state allows for the safe completion of precision tracking or maneuvering tasks, as well as safe cruise, descent, and landing at the intended destination or an alternate However, it also results in excessive pilot workload and reduced mission effectiveness.

Hence, a FCS function is declared:

Essential if loss of the function results in an unsafe condition or inability to maintain FCS Operational State III

Flight phase essential if loss of the function results in an unsafe condition or in- ability to maintain FCS Operational State III only during specific flight phases

Non-critical if loss of the function does not affect flight safety or result in control capability below that required for FCS Operational State III

The degrees of fault tolerance for FCS functions are defined as follows:

Fail operational The capability of the FCS for continued operation without degra- dation following a single failure, and to fail passive in the event of a related subsequent failure.

Fail passive The capability of the FCS to automatically disconnect and to revert to a passive state following a failure.

The fail-safe feature of the Flight Control System (FCS) allows it to revert to a secure state in single channel mode after an automatic disconnect occurs due to a failure or when a pilot initiates a disconnect.

Each Flight Control System (FCS) function must achieve a specific level of fault tolerance based on its criticality Essential FCS functions are designed to be fail operational, while flight-phase-essential functions must be fail passive, and non-critical functions are expected to be fail safe In reality, the fault tolerance levels for both flight-phase-essential and essential controls often surpass these requirements due to the stringent demands of reliability and flight safety This discussion centers solely on fault tolerance, without addressing reliability or safety considerations.

The Flight Control System (FCS) operates typical autopilot functions, including Pitch Attitude Hold and Roll Attitude Hold, which are considered non-critical and must be fail-safe To ensure fault tolerance, these autopilot functions monitor sensor readings and control inputs; if values exceed predetermined thresholds, the autopilot disengages, allowing the pilot to regain control This research extends the fault tolerance requirements of autopilot systems to include fail operational capabilities, utilizing an analytical redundancy approach.

Analytical redundancy-based fault tolerance operates at the software level, where routines analyze control law inputs and outputs against an analytical model of the aircraft However, this approach cannot address failures of all Flight Control System (FCS) components, as both hardware and software can fail Specifically, analytical redundancy is ineffective against software failures and single-channel FCS failures, such as when the Flight Control Computer (FCC) fails, since it is responsible for fault tolerance software Additionally, failures of control or display panels cannot be managed at the software level, rendering analytical redundancy inadequate in these scenarios The literature typically addresses actuator and sensor failures separately, as sensor failures primarily involve observation issues while actuator failures pertain to control challenges, necessitating distinct expertise for each This article focuses on providing fault tolerance for primary sensor failures, as secondary sensor outputs are not utilized by the Flight Control Law (FCL).

Focusing solely on sensor failures does not imply that other components in the Fault Tolerant Control (FTC) environment are immune to failure The susceptibility of each component to failure is inherently determined by its nature Assuming all Fault Control System (FCS) components can fail, it is essential to determine the appropriate redundancy approach for ensuring fault tolerance For certain FCS components, such as the Fault Control Software (FCSw), Fault Control Computer (FCC), Control Processor (CP), and Data Processor (DP), fault tolerance must be achieved through physical redundancy, while still meeting performance requirements after a single failure Conversely, fault tolerance for actuator and sensor failures can be managed through software solutions.

Analytical redundancy in aircraft dynamics is supported by functional redundancy, necessitating consideration of potential failures in aircraft subsystem components While control surfaces and engines are recognized as fallible, the airframe is generally assumed to be infallible, particularly in commercial aviation where significant structural failures are rare In military scenarios, however, partial separation of wing or tail surfaces may occur Components lacking guaranteed fault tolerance through physical redundancy are indicated with oblique lines in figure 3.1.

The article discusses the implementation of fault tolerance in a system using different modules that either employ physical or analytical redundancy Analytical redundancy is non-modular, relying on correlations among system quantities and outputs from other components to detect and accommodate failures In contrast, physical redundancy is modular, where each component's fault tolerance is supported by similar components, maintaining local information This research outlines a stratified structure of fault tolerance control (FTC) modules, with one module focusing on physical redundancy at the highest level, ensuring the correct operation of the hardware Below it, a second layer addresses sensor failures through analytical redundancy, providing validated readings while filtering out irrelevant component failures The final layer targets actuator failures, utilizing fault-tolerant sensor readings while also filtering out non-relevant components.

Before illustrating the interface between the FTC and its environment the main functions of the FTC system are summarized as follows:

The FTC system must ensure fault tolerance at a fail-operational level concerning primary sensor failures, achieved solely through software without relying on redundant sensors This capability should extend to failures of components outside the monitored sensors and those supported by physical redundancy Additionally, if the FTC is not activated, the AFCS should maintain its original operation without the fault tolerance features.

FTC interface with its environment

Figure 3.2 shows how the FTC system fits within its environment To contain the dimensions of the drawing either acronyms or short-names are used in place of some

OUT FTC FTC-AR IN FTC

The FTC system operates within its environment, featuring key components such as actuators (ACT), display panels (DP), and control panels (CP) The control and display panels (CP F T C and DP F T C) serve as the pilot's interface, allowing for the activation and deactivation of the FTC while indicating the operational status of the monitored sensors The ADC F T C and DAC F T C facilitate the connection between electrical signals from the control and display panels and the corresponding software variables Software modules IN F T C and OUT F T C act as intermediaries between these blocks and the FTC-AR block, which is the system's core FTC-AR processes sensor readings and control inputs to ensure their consistency with the analytical model of the environment, utilizing analytical redundancy to enhance fault tolerance.

The implementation of the FTC system within the FCS necessitates ensuring fault tolerance for FTC components, similar to the physical redundancy utilized for achieving fault tolerance Consequently, it is assumed that fault tolerance for the FTC components will be effectively maintained in the same manner.

DHC-2 aircraft

To develop the requirements specification for a Fault Tolerant Control (FTC) system, it is essential to detail the aircraft's environment, necessitating a pilot application The chosen aircraft for this purpose is the De Havilland DHC-2, or Beaver, a single-engine, high-wing aircraft with a wingspan of approximately 15 meters, a fuselage length of about 9 meters, and a maximum take-off weight of 2300 Kg The analytical model and Flight Control System (FCS) for the DHC-2 are available in the Flight Dynamics and Control (FDC) Toolbox for Matlab Key references provided detailed descriptions of the FTC environment's components, including the aircraft's analytical model, actuator-control-surface chain, engine, and continuous-time flight control laws, covering the aircraft subsystem, actuators, and flight control laws Additional analytical models were developed to complete the environment description.

The analytical model of the aircraft incorporates aerodynamic derivatives and moments of inertia, as referenced in [37], with uncertainty bands based on nominal values introduced in accordance with [31] The model includes dynamics for actuator-control surfaces such as elevators, ailerons, and rudders, while omitting flaps since they are not utilized by the autopilot functions Additionally, due to the absence of a sensor model in the cited documentation, analytical models were created based on the technical specifications of the relevant sensors.

Table 3.1: DHC-2 autopilot functions and related controls Autopilot function Controls

Pitch Attitude Hold (PAH) SW P AH , θ r

Altitude Hold (ALH) SW ALH

Roll Attitude Hold (RAH) SW RAH , φ r

Heading Hold (HH) SW HH

Heading Select (HS) SW HS , ψ r

Rate gyros and accelerometers M otionP ak T M Multi-Axis Inertial Sensing Sys- tem, by BEI, Systron Donner Inertial Division

Angle of attack FAA-authorized commercial airliner angle of attack transducer Se- ries 2568A, by Gulton Statham

Dynamic pressure sensor differential pressure sensor series 142PC05D by Honey- well - Microswitch

Static pressure sensor absolute pressure sensor series 142PC15A, by Honeywell - Microswitch

Attitude and heading sensors FAA authorized Advanced 4MCU IRU, by Hon- eywell.

The control panel features autopilot control switches and knobs, while the Manual Flight Control System (MFCS) controls are excluded from this study A 16-bit data acquisition card with a ±10 Volt input and output range is utilized for the ADC and DAC components The input to the ADC and output from the DAC consist of electrical signals within this range, with raw software variables representing the 16-bit equivalent of these signals The IN and OUT blocks convert raw software variables into refined software variables, with the IN block also processing pressure and temperature data to generate air-data metrics like air density and airspeed based on the ICAO Standard Atmosphere model The flight control laws, implemented within the Flight Dynamics and Control Toolbox for Matlab, have been discretized using the forward Euler approximation at a sampling rate of T s = 1/50s The AFCS functions available in the FDC Matlab Toolbox are detailed in Table 3.1, while the specifics of the Flight Control Computer are not included, assuming it adequately supports the FCSw Figure 3.3 illustrates the block diagram of the DHC-2 aircraft and its AFCS, with each component identified by a unique letter code.

’C’ and a subscript that identifies the component.

Military specification for AFCS

The military specification MIL-F-9490D serves as the primary reference for establishing fault tolerance and performance criteria for the Automatic Flight Control System (AFCS) This specification, titled "Flight Control Systems - Design, Installation and Test of Piloted Aircraft, General Specification for," outlines the essential guidelines and standards for Flight Control Systems (FCS) in military applications.

The US Air Force operates manned piloted aircraft, adhering to a range of military specifications, standards, and handbooks, along with relevant non-military publications like FAA Advisory Circulars and National Aircraft Standards These guidelines ensure the safety and efficiency of air operations.

The research is supported by key military specifications and technical reports, including MIL-F-8785C, which outlines the flying qualities of piloted airplanes, and the supplementary materials related to MIL-F-9490D These documents provide essential background information and user guidance necessary for understanding the performance and operational standards of the DHC-2 aircraft and its Flight Control System (FCS).

MIL-F-9490D outlines the specifications for Flight Control Systems (FCS), detailing operational states, criticality classifications, and quality assurance procedures The document serves as a comprehensive guide for the design, analysis, and testing of FCS, covering a range of requirements from high-level system needs to specific subsystem and component criteria It includes performance requirements for autopilot functions like Pitch Attitude Hold, Altitude Hold, Roll Attitude Hold, Heading Hold, and Heading Select, as well as functional requirements focused on fault tolerance for fail-operational capabilities Appendix B.1 provides a curated subset of military specifications, with modifications tailored to the requirements of the FTC system, emphasizing the importance of maintaining operational integrity during failures.

The specifications outlined in [2] are not exhaustive for an aircraft, as they focus on aircraft-independent criteria In contrast, aircraft-dependent specifications are detailed in the manufacturer's documentation, known as detail-specifications These specifications encompass the aircraft's operational envelope, normal and fault states, maneuver limits, and Automatic Flight Control System (AFCS) functions, including engagement procedures, selection logic, and safety criteria To create the DHC-2 detail-specification, the previously discussed documentation will be utilized.

Formal specification of the FTC environment

The FTC specification is built upon the performance specification from MIL-F-9490D and the DHC-2 detail specification, aiming to create a formal requirements specification To achieve this, both performance and detail specifications must be formalized first The formal specification framework utilized is relational algebra, which is introduced in Section 4.1; for a comprehensive understanding of relational algebra, please refer to Appendix A and the cited bibliography.

To enhance performance and detail in formal specifications, relevant requirements are systematically broken down into elementary requirements Each of these elementary requirements is formalized independently, resulting in an elementary specification Subsequently, relational algebra composition operators are utilized to construct higher-level requirements, culminating in the complete specification This chapter thoroughly details the process of formalizing elementary requirements, exemplified by one specific requirement from the performance specification Additionally, it demonstrates the composition of these elementary specifications through a practical example, ultimately illustrating the requirement structure of both performance and detailed specifications.

Relational specification of elementary requirements

Equation 4.1 represents the prototype of a relational specification.

A relation consists of elements derived from the Cartesian product of the domain space A and the image space B, represented as A×B, which is known as the signature of the relation In this context, A and B are distinguished in boldface to differentiate the spaces from their respective elements Each element within these spaces signifies a structure of variables, where A refers to domain elements and B to image elements The predicate, denoted as predicate(A,B), incorporates domain and image variables along with constants and possibly quantified variables It evaluates to true or false based on the values assigned to these variables, and the relation encompasses all pairs (A, B) for which the predicate returns true.

A requirement can be understood as a relationship between relevant quantities within a defined space, where each point corresponds to a specific set of values for those quantities This relationship delineates a region in the quantity space, similar to how a function y = f(x) defines a curve in a two-dimensional plane This region encompasses all values that meet the specified relationship criteria By utilizing a relation as described in equation 4.1, one can accurately define this region and thereby clarify the associated requirement, provided that the chosen constants and variables accurately represent the pertinent quantities and that the predicate effectively captures the relationship among them.

In the requirement formalization process, the first step is identifying the quantities used to formulate the requirement, both explicitly and implicitly Constants represent fixed quantities, while image variables indicate constrained values, domain variables define the scope, and quantified variables contribute to the formulation without being constrained To enhance readability and reduce repetition, auxiliary terms are introduced to encapsulate frequently used expressions and functions Ultimately, a predicate is formulated to accurately capture the semantics of the requirement, ensuring it evaluates as true only when the specified relationship among the quantities is upheld.

In control systems, variables typically represent instantaneous values, which is effective for defining input/output relationships but inadequate for Automatic Flight Control Systems (AFCS) requirements AFCS performance is often defined by constraints on a quantity's time evolution over a specified interval rather than its instantaneous values For instance, damping and RMS-deviation requirements illustrate this concept; the damping requirement is expressed through the damping factor of an equivalent second-order system, necessitating an identification procedure to analyze system input and output over time Similarly, the RMS-deviation requirement is based on the integral of output within a time interval, making it impossible to express these requirements solely through instantaneous values.

To address this issue, the author utilizes variables that capture the entire time evolution of the relevant quantity instead of just its instantaneous values For instance, the variable φ() signifies the time evolution of the bank angle over the interval [0,∞) The empty brackets () indicate that the variable reflects the complete time progression of a quantity rather than its value at a specific moment.

This article discusses the formalization process of the Heading Hold (HH) control function requirement, highlighting its simplicity while also addressing several important discussion points The plain-English specification is referenced to aid in the analysis, with each section labeled for clarity.

In smooth air, the heading must be maintained within a static accuracy of ±0.5 degrees relative to the reference During turbulent conditions, the root mean square (RMS) deviations in heading should not exceed 5 degrees, as outlined in section 3.1.3.7 When heading hold is activated, the aircraft is required to roll towards a wings-level position The reference heading is defined as the heading of the aircraft when it achieves a wings-level roll attitude, allowing for a specified tolerance.

The analysis of the plain-English requirement begins by identifying the quantities specified explicitly or implicitly within the specification, with identifiers introduced for clarity The HH requirement outlines accuracy standards for the heading angle (ψ) during both smooth air and turbulent conditions, necessitating a distinction between the two scenarios To facilitate this, the auxiliary function turb(t_a, t_b) is defined, which evaluates the wind velocity components and returns false if the airplane operates in smooth air during the interval [t_a, t_b] Accuracy in turbulence is quantified through the RMS deviation from the reference heading, using the auxiliary function RMS(dev(), t_a, t_b) to calculate the RMS value of the variable dev() over the specified time frame Key time instants include t_1, marking the engagement of the HH function, and t_2, when the reference heading (ψ_r) is established.

The specification mandates that the airplane must roll towards a wings-level position, defining the reference heading as the orientation when the aircraft achieves a roll attitude of wings level within a specified tolerance (φ acc) The third time instant (t 3) can occur at any moment before the disengagement of the heading hold (HH) function Additionally, it is essential to represent the required accuracy levels for both smooth air (ψ acc) and turbulent conditions (ψ RM S), along with the HH control switch (SW HH()) An auxiliary function, engaged(SW(), t a , t b), is also defined; it returns true if the control switch SW() is engaged at time t = t a and remains engaged throughout the entire interval [t a , t b].

The relevant quantities are categorized into classes, including constants, domain, image, quantified variables, and auxiliary functions Tables 4.1 to 4.4 provide a comprehensive list of all identifiers utilized in the HH relational specification The signature and predicate of the HH relational requirement are defined by two key equations.

Table 4.1: Constants used within the specification of the HH function.

The heading accuracy in smooth air is defined as ψ acc = 0.5° (SI angle-T), while in turbulent conditions, the root mean square (RMS) heading accuracy is noted as ψ RM S = 5° (SI angle-T) Additionally, the roll accuracy in smooth air is specified as φ acc = 1.0° (SI angle-T).

Table 4.2: Domain and image variables used within the specification of the HH func- tion.

The SW HH time-T controls the switch-T for the autopilot system, allowing for the activation or deactivation of autopilot features The velocity-T includes wind-turbulence components along the body-axes, represented as u w g, v w g, and w w g at time-T Additionally, the wind-gust components of wind velocity are also measured along the body-axes The heading angle, denoted as ψ, and the bank angle, represented as φ, are both tracked at time-T to ensure precise navigation and stability.

Table 4.3: Quantified variables used within the specification of the HH function.

The ID type definition outlines various time instants: t1 represents the generic time instant, t2 indicates the engagement time when the reference heading is established, and t3 marks the time instant that defines the scope of the requirement Additionally, ψ denotes the angle related to the reference heading.

Table 4.4: Predicates and functions used within the specification of the HH function.

ID Description engaged(SW(), t a , t b ) predicate that evaluates true only if the switch SW() is engaged at t = t a and stays engaged throughout the time interval [t a , t b ]

RM S(f(), t a , t b ) Root Mean Square value of the function f() over the time interval [t a , t b ] turb(t a , t b ) predicate that evaluates true if random and discrete turbu- lence wind components are not zero

∀t ³ t 2 ≤t ≤t 3 ⇒ |φ(t)|< φ acc ´ ∧ ψ r =ψ(t 2 ) ∧ ơturb(t 1 , t 3 ) ⇒ ∀t ³ t 2 ≤t≤t 3 ⇒ |ψ(t)−ψ r |< ψ acc ´ ∧ turb(t 1 , t 3 ) ⇒ RM S(ψ()−ψ r , t 2 , t 3 )< ψ RM S ´ ´

Hence, the relational requirement for the HH control function is:

R HH = n HH sign ¯¯ ¯ HH pred o (4.4)

The HH predicate 4.3 can be read as follows:

FOR EVERY couple of time instants t 1 , t 3

[t 1 , t 3 ] is a time interval within [0,∞) AND the HH control function is engaged at t = t 1 and stays engaged throughout the interval [t 1 , t 3 ]

There exists a time instant \( t_2 \) and a reference heading \( \psi_r \) such that \( t_2 \) falls within the interval \([t_1, t_3)\) During the interval \([t_2, t_3)\), the bank angle remains approximately zero The reference heading \( \psi_r \) corresponds to the heading angle at \( t = t_2 \) If there is no turbulence in the interval \([t_1, t_3]\), the deviation of the heading angle \( \psi \) from the reference heading \( \psi_r \) must not exceed \( \psi_{acc} \) at any time within \([t_2, t_3]\) Conversely, if turbulence is present, the RMS value of the deviation of the heading angle \( \psi \) from the reference heading \( \psi_r \) during the interval \([t_2, t_3]\) must not exceed \( \psi_{RMS} \).

The THEN section labels correspond to those in the plain-English specification, with sections a) and b) addressing accuracy requirements for both smooth and turbulent operations Sections c1) and c2) reference section c) of the plain-English specification, which states that when heading hold is engaged, the aircraft must roll to a wings-level position This has been formalized to require the airplane to achieve a bank angle close to zero at a specific time, t2, with the accuracy threshold φ acc from the Roll Attitude Hold (RAH) specification being utilized to quantify this closeness This approach compensates for the absence of a defined threshold in the original specification Additionally, the original specification's section d) indicates that the reference heading is determined when the aircraft reaches a wings-level roll attitude, but it fails to specify the tolerance for this heading.

Composition of elementary requirements

This article introduces composition operators from relational algebra to describe the elementary specifications and explores the concept of refinement ordering between requirements and system correctness A relation R1 is said to refine relation R2, denoted as R1 w R2, when R1 imposes a stronger requirement, either by covering a broader domain or being more specific System correctness is defined through a refinement constraint, where a system implementation relation P is considered correct with respect to requirements relation R if P w R The composition operators utilized are the join (t) and product (◦) operators, with the join representing the cumulative requirements Consequently, a system P that satisfies the requirements specified by R1 t R2 inherently meets the individual requirements of R1 and R2.

R 2 separately This is formally stated by the following formula:

The join operator is utilized to combine relations that reflect parallel requirements within a specification structure The resulting relation from two relations, R1 and R2, signifies the requirements of two sequential systems, P1 and P2, as defined by R1 and R2 When P12 represents the series of systems P1 and P2, the primary characteristic of the product operator can be expressed through a specific formula.

Figure 4.1: Sample requirements specification structure.

The product operator is adopted to compose relations that capture sequential re- quirements within the specification structure.

Figure 4.1 illustrates a sample specification structure where relations R1, R2, and R3 define the elementary requirements The specification is decomposed into subsystems and components based on a convenient partitioning criterion, which also influences the relationships among the specification components In this figure, R2 and R3 are sequential requirements, indicated by the connecting arrow, while R1 alongside R2 and R3 represents parallel requirements Together, these relations form a higher-level requirement, R_TOT, shown within a dashed-line box Additionally, the arrows denote the signature of R_TOT, with A representing the domain space and B signifying the image space, allowing the entire specification to be effectively articulated.

Composition operators are limited in their application to relations with compatible signatures; specifically, the join operator requires matching signatures, while the product operator necessitates that the image space of the left operand aligns with the domain space of the right operand Consequently, to effectively compose relations for higher-level requirements, it may be necessary to expand the domain and/or image spaces of the involved relations This expansion maintains the original relational properties, ensuring that the expanded relations continue to specify the same requirements One potential strategy is to extend the spaces of all relations to encompass all variables present in the specification, resulting in a homogeneous set of relations where both join and product operators can be applied However, this method risks creating a flat set of relations, which may obscure the underlying system structure.

The adopted expansion approach enhances system structure, resulting in a more informative specification that can lead to more effective validation This process is exemplified by the composition of the Heading Hold (HH) and Heading Select (HS) requirements, as detailed in Sections 3.1.2.2 and 3.1.2.3, respectively The expansion operation requires only the two relation signatures, with the HH relation signature provided in equation 4.2, while the HS relation signature is derived from the plain-English requirement.

The aircraft must automatically turn to any selected or preselected heading while maintaining specified tolerances for heading hold The contractor is responsible for establishing a bank angle limit that ensures a satisfactory turn rate without risking an impending stall Additionally, the aircraft should not overshoot the selected heading by more than 1.5 degrees, and both entry into and exit from the turn must be smooth and rapid The roll rate is limited to a maximum of 10 degrees per second, with roll acceleration not exceeding 5 degrees per second squared.

The requirement establishes constraints on the roll angle φ(), heading angle ψ(), and roll rate p() Its scope is influenced by the HS engagement control switch SW HS, the chosen reference heading ψ r, and the wind velocity components u w t, v w t, and w w t, in relation to the HH requirement Consequently, the signature for the HS relational requirement is defined.

The signature of the HH relational requirement is reported below:

The HH and HS control function requirements in the AFCS performance specification are closely related, forming the Heading Control Function requirement despite differing signatures (4.12 and 4.11) To enhance the domain and image space of these relations while maintaining the specification structure, the author implements two expansion operations The first involves partitioning all variables into disjoint subsets based on functional equivalence, which guided the decomposition into subsystems and components Each instance of equivalent variables in the signature is replaced with its corresponding equivalence class The specification includes various classes of equivalence, such as pilot input variables (U p), aircraft state variables (X), and components of the wind velocity vector (U w), allowing for the formulation of the HH and HS relation signatures.

The two signatures 4.13 and 4.14 are now the same and the two relations can be joined.

In certain relationships, a second expansion operation is necessary, particularly for the sensor requirement R Sp and the control panel requirement R CP outlined in the DHC-2 detail specification These two requirements must be integrated into the computer input requirement R CIN, despite having distinct signatures following the initial expansion.

The classes of electrical signals related to aircraft states (X) and pilot inputs (U p) face challenges due to the equivalence partitioning based on the initial subsystem composition of the FTC environment components The R CIN relation operates at a higher level by integrating the subsystem requirements R Sp and R CP To address this issue, equivalent classes at the same hierarchical level within successive system compositions are merged Consequently, the signals X and U p, along with ˜ X and ˜ U p, are unified to create a common signature for the requirements R Sp and R CP.

Table C.1 collects the original signature and the expanded signatures for each rela- tional term used in the specification.

Formal specification of the FTC environment

Performance requirement composition

Section B.1 outlines the fundamental requirements for the performance specification of the Automatic Flight Control System (AFCS), focusing specifically on static accuracy during smooth air and turbulent conditions relevant to the DHC-2 autopilot functions The selected performance requirements encompass the PAH, ALH, RAH, HH, and HS autopilot functions, as well as the coordination requirements for lateral-directional control in both Steady Banked Turn (SBT) and Level Flight (LF) The original requirements from the source are presented alongside a relational specification, with an intermediate formulation that bridges the two specifications, particularly highlighted in Section 4.1 for the HH function.

The AFCS performance requirements specification is structured to enhance clarity, with requirements numbered as in the original document and ellipses indicating omitted text The plain-English specification is organized into subsections identified by letters, which correspond to related sections in the intermediate specification This approach helps eliminate ambiguity by omitting unclear subsections from the formal specification.

Figure 4.2 illustrates the structure of performance requirements, which are combined using the join operator to create the Performance Specification (RPS) The dashed outline blocks categorize the relationships defining requirements for Symmetric Control Functions (RSCF), Coordination Constraints (RCC), Heading Control Functions (RHC), and Asymmetric Control Functions (RACF) The performance specification RPS operates over the domain space comprising trim-variables (Ctr), AFCS input variables (Upa), air-turbulence variables (Uw), and airplane state variables (X), with the corresponding image space being X Each requirement serves as a constraint on the evolution of the airplane state under specific turbulence conditions, tailored to particular AFCS input and trim conditions.

The performance specification is created by combining all elementary performance requirements using the join operator This specification is limited to acceptable combinations of Automatic Flight Control System (AFCS) inputs, valid trim conditions, and the necessary wind turbulence model, as defined by the pre-restriction sets outlined earlier The composition can be expressed through specific equations.

R RAH t R HH t R HS t R SBT t R LF ´

DHC-2 detail-specification

Section B.2 outlines the fundamental requirements for the DHC-2 detail specification, detailing the expected performance of each component of the DHC-2 aircraft and its Automatic Flight Control System (AFCS) This information primarily consists of analytical equations that describe the operation of each component, lacking a straightforward plain-English equivalent.

Elementary specifications are organized into subsections based on their function within the specification framework In Section B.2.1, relationships defining airplane dynamics are presented, including equations for force (R F eq), moment (R Meq), kinematics (R Keq), and navigation (R Neq) The driving factors for these equations include aerodynamic forces (R aef) and moments (R aem) generated by the airframe, as well as forces (R csf) and moments.

The control surfaces generate forces and moments, including R csm, R pf, and R pm, while gravity (R grf) and wind (R wf) also play significant roles This section outlines the relationships that define air-data quantities (R ad) and kinematic acceleration at the crew station (R ka) Additionally, Section B.2.2 details the hardware component requirements for the DHC-2 AFCS, including specific actuator specifications.

The article outlines the specifications for various sensor components, including R rud, R ail, and R elv, as well as control panel specifications (R CP) and FCC interface card specifications (R ADC and R DAC) Section B.2.3 details the relationships that define the requirements for the FCSw components, encompassing the interface modules R in and R out, along with all modules associated with the FCL, such as R P AH d, R ALH d, R RAH d, R d HS, and R HH d.

Figure 4.3 presents the detail-specification structure, resembling the block diagram in figure 3.3, with the key distinction being the expansion of the airplane system to illustrate its dynamic relations Notably, the display panel has been excluded from the AFCS as it is not relevant to the specification Additionally, the diagram outlines the various classes of variables that define these relations, with some classes previously introduced and others yet to be detailed.

The DHC-2 detail specification introduces key elements, including the MFCS control inputs (U pm) and the aerodynamic coefficients for force and moment (C f).

In the context of control surface deflection variables, different accents are used to signify various types of quantities: the tilde (˜) denotes electrical signal variables, the bar (¯) indicates ADC or DAC software representations, and the hat (ˆ) represents software variables Specifically, ˜X refers to electrical signals related to airplane states, ¯X corresponds to the ADC software representation of those states, and ˆX signifies the software variables associated with the airplane states This convention applies similarly to other classes and variables with accents.

The DHC-2 detail specification is developed by integrating the fundamental requirements outlined in Section B.2, as supported by the structure in figure 4.3 This specification encompasses a comprehensive description of the dynamics of the DHC-2 airplane.

The R DHC 2 and DHC-2 AFCS R AF CS frameworks introduce key relationships to gather functionally related specifications These include R f and R m, which compile the force and moment components essential for flight dynamics equations Additionally, R S p and R S s represent the primary and secondary sensor subsystems, respectively The relation R F CL encompasses the flight control laws, while R ACT pertains to the actuators Furthermore, R F CSw denotes the flight control software, and R F CC signifies the flight control computer.

The formal composition of the elementary requirements is expressed by the following equations

R f = R aef t R grf t R csf t R pf t R wf (4.20)

R DHC 2 = R f ◦R F eq t R m ◦R Meq t R Keq (4.22) tR Neq t R ad t R ka

R F CL = R P AH d t R ALH d t R RAH d t R HH d t R HS d (4.25)

R AF CS = ³ R S p t R S s t R CP ´ ◦R F CC ◦R ACT (4.29)

Correctness of AFCS design

The AFCS performance specification R P S outlines the necessary system requirements for an Automatic Flight Control System (AFCS), detailing the expected behavior of an aircraft when it is equipped with this technology By integrating the DHC-2 detail specification with the AFCS performance specification, a comprehensive specification is established for the airplane outfitted with the AFCS.

The design specification of the AFCS is correct with respect to R P S if

Formal requirements specification of the FTC

This chapter presents the formal specification of the Fault Tolerance Control (FTC) system, beginning with a breakdown of fault tolerance requirements into functional and non-functional categories, which are structured for easier formalization The relational specification is built upon these plain-English requirements The core of the FTC system, the FTC-AR module, is examined in detail, while other FTC modules are summarized in section B.5 Finally, the chapter concludes with a discussion on concepts pertinent to the feasibility analysis of the fault tolerance requirements.

FTC requirements

FTC functional requirements

The relation R P S defines the performance specifications of the Automatic Flight Control System (AFCS) for the DHC-2 airplane When each component meets its designated requirements, the design's correctness, as outlined by equation 4.31, ensures that the system's actual behavior aligns with performance expectations Fault tolerance is crucial for maintaining these specifications even if one or more components fail Key concepts of fault tolerance in flight control systems were introduced in Section 3.1.2, and this section revisits the definitions of fail operational and fail passive to support the analysis leading to the establishment of fault tolerance requirements for the DHC-2's AFCS.

Fail operational The capability of the FCS for continued operation without degra- dation following a single failure, and to fail passive in the event of a related subsequent failure.

Fail passive The capability of the FCS to automatically disconnect and to revert to a passive state following a failure.

The concept of fail operational capability involves ambiguity regarding related subsequent failures, particularly in how single and double failures are addressed The sequence of failures is irrelevant, but the conditions under which two failures are deemed related remain unclear In scenarios of physical redundancy, the failure of two out of three units may be seen as related, yet this perspective shifts with analytical redundancy The author proposes a functional definition, categorizing fallible components into equivalence classes: measurement units (M), actuation units (A), processing units (P), and interface units (I) Failures within the same class are considered related, reflecting a critical interpretation that emphasizes the importance of related failures over unrelated ones This distinction is vital, as fault-tolerant systems must be fail passive in the event of related failures, while they are expected to maintain operation during unrelated failures Thus, defining related failures based on component function is essential, as failures of components serving the same function pose a greater risk than those serving different functions.

To effectively define the automatic disengagement requirement within the fail passive framework, a formal description of the Multi-Function Control System (MFCS) is essential The specifics regarding the transition from the Automatic Flight Control System (AFCS) to the MFCS after automatic disengagement are not addressed; instead, the focus is on the necessity for the Flight Control Computer (FTC) to signal this transition.

Fault tolerant flight control systems must include a "FCS warning and status annunciation" feature, as specified in section 3.2.1.4.2 of [2] This system is designed to provide warnings in the event of a fault and during automatic disengagement To achieve this, the flight control system (FTC) must be equipped with a display panel featuring a warning light for each monitored component, along with an additional light indicating automatic disengagement Additionally, the FTC control panel should include a switch to manage the ON/OFF status of the FTC system.

The core of the fault tolerance requirements specification is defined by the fail operational capability and the necessary warning and status annunciation To better formalize these fault tolerance requirements, specific fault hypotheses are introduced.

H 0 Fault free hypothesis; all of the components used by the FTFCS are working according to the corresponding specifications.

H 1 Single failure hypothesis; at least one component among those used by the FTFCS is working according to one of its fault modes, and there are no related faults;

H 2 Multiple failure hypothesis; at least two related components used by the FTFCS are working according to one of the corresponding fault modes.

Fault hypotheses H1 and H2 define fault modes to describe a component's behavior when it fails to meet specifications This approach recognizes that the required and faulty behaviors do not encompass all potential operational modes of a component Therefore, both the required behavior and the identified fault modes are utilized as the foundation for certification, rather than relying solely on the required behavior and any behavior that deviates from the component's specifications.

The fault tolerance requirements are formulated as follows:

- if the FTC is not engaged then the FTFCS shall operate like the original AFCS and all FTC warning lights shall be off;

- if the FTC is engaged then

- under conditions captured by the fault hypothesis H 0 the DHC-2 airplane equipped with the FTFCS shall meet the performance specification R P S and all FTC warning lights shall be off;

Under the fault hypothesis H1, the DHC-2 airplane equipped with the FTFCS is expected to fulfill the performance specifications outlined in RPS, with only the warning lights for the affected components illuminated.

- under conditions captured by the fault hypothesisH 2 the FTC automatic- disengagement warning light shall be on.

FTC non-functional requirements

In Section 3.1.2, two critical non-functional requirements for the Fault Tolerant Control (FTC) system were outlined, emphasizing constraints on the modular architecture and redundancy strategies for each component Fault tolerance must be achieved through physical redundancy for components classified as P and I, while analytical redundancy is required for components classified as M and A The modular solution prioritizes fault tolerance, addressing failures in classes P and I first, followed by M, and lastly A This prioritization ensures that failures in classes P and I remain transparent to the fault tolerance mechanisms for class M components, whereas failures in class A do not The research specifically targets the FTC module that ensures fault tolerance against sensor failures.

Non-functional constraints significantly influence the specification of Fault-Tolerant Control (FTC) requirements The analytical redundancy approach affects the definitions of fault hypotheses by emphasizing the correlation between sensor outputs and actuator inputs at the software level, necessitating a comprehensive consideration of all potential failures that could disrupt this correlation Additionally, the module priority constraint plays a crucial role in determining whether a failure is deemed transparent to the FTC module This modular approach shifts the focus of FTC requirements from maintaining the performance of the Automatic Flight Control System (AFCS) during a single failure to ensuring the functionality of the entire sensor set.

FTC-AR requirements

The DHC-2 airplane's specification structure, depicted in Figure 5.1, highlights the FTFCS components, with the FTC-AR module being central to the system's analytical redundancy and fault tolerance during sensor failures Key components of the FTC system include the control (CP) and display (DP) panels, which interface between the FTC and the pilot, along with the hardware (ADC, DAC) and software blocks (IN, OUT) that connect the external interface to the FTC-AR module Additionally, the FTC-SW block functions as a switch within the system.

The DHC-2 and FTFCS requirements specification structure highlights the differences between the original AFCS and the FTFCS The FTC-SW serves a critical safety function by isolating the FTC-AR module when the FTC is disengaged, ensuring its output does not influence the FCL input The integration of the FTC system into the AFCS introduces new variables essential for formulating the requirements, specifically represented by the class of FTC input variables.

U f , the class of FTC warning variablesY f , and the class of validated airplane states

The decomposition of the Fault Tolerance Control (FTC) system has led to the isolation of the FTC-AR module, which specifically addresses fault tolerance requirements These requirements are established by integrating fault tolerance needs with non-functional constraints and projecting them onto the module's interface This methodology results in the identification of key fault hypotheses.

- all of the sensors used by the FTFCS are working according to the corre- sponding specifications and

- all of the processing and interface units used by the FTFCS are working according to the corresponding specifications and

Only two actuation units utilized by the FTFCS are functioning in line with one of the designated fault modes, while all remaining units operate according to their specified standards.

- all fallible components not used by the FTFCS are either working according to the corresponding specification or according to one of the corresponding fault modes.

The FTFCS utilizes a sensor, denoted by the subscript, that operates under one specific fault mode, while all other sensors function according to their designated specifications.

- hypothesis among remaining fallible components: same as for H M 0

The FTFCS operates effectively with at least two sensors functioning in alignment with specific fault modes, while all other sensors adhere to their designated specifications.

- hypothesis among remaining fallible components: same as for H M 0

The fault tolerance requirements specify that when the switch SW d F T C is OFF, all warning variables must also be OFF Conversely, when the switch is ON, the response varies based on the correlation between ˆU c and ˆX If this correlation aligns with fault hypothesis H M 0, all FTC warning variables remain OFF However, if it corresponds to fault hypothesis H M 1,m, then the variable ˆW m is activated while all other warning variables stay OFF In cases where the correlation relates to fault hypothesis H M 2, the variable ˆW dis is turned ON Additionally, if the correlation matches either fault hypothesis H M 0 or any of the hypotheses H M 1,m, the sensors equipped with the FTC must comply with the specification R X X ˆ.

Fault tolerance requirements can be categorized into three main areas: fault-free requirements, detection and identification requirements, and recovery requirements This classification is based on the distinct nature of each requirement's signature Specifically, detection and identification requirements are articulated through FTC-AR inputs and outputs, whereas the recovery requirement is defined by the actual states of the airplane and their related software variables.

Formal specification of FTC-AR

Components partitioning

The DHC-2 airplane, integrated with the FTFCS, has been broken down into distinct components, each linked to a specific relational specification as illustrated in figure 5.1 These components are denoted by the letter C, accompanied by a subscript that corresponds to their respective relation The overall collection of components is represented by C, while the components utilized by the FTFCS are categorized as U Additionally, the components that are susceptible to failure are classified as F, which is further divided into subsets: measurement components (M), actuation components (A), processing components (P), and interface components (I).

C aef , C aem , C grf , C wf , C ka , C ad , C csf , C csm , C pf , C pm ,

C in , C out , C P AH d , C ALH d , C RAH d , C d HH , C HS c ,

Set of components used within the FTFCS

C in , C out , C P AH d , C ALH d , C RAH d , C HH d , C HS c ,

C in , C out , C P AH d , C ALH d , C RAH d , C HH d , C HS c ,

A = n C csf , C csm , C pf , C pm , C rud , C ail , C elv o (5.5) Set of Processing components

Formal specification of fault hypotheses

A fault hypothesis assigns a mode of operation to each fallible component based on its specification or fault modes For a component \( C_c \), \( R_c \) defines its requirements, while \( F_c \) represents its fault-mode relations, and \( R_{c,n} \) indicates its fault-mode number \( n \) The behavior of component \( C_c \) under fault hypothesis \( H \) is denoted by \( R_c(H) \), and \( H^* \) encompasses all possible fault hypotheses The explicit definition of fault hypothesis \( H_{M_0} \) serves as a reference point for other fault hypothesis definitions.

Measurement components used by the FTFCS

Processing components used by the FTFCS

Interface components used by the FTFCS

Actuation components used by the FTFCS

Components not used by the FTFCS

Measurement components used by the FTFCS

All other fallible components: same as for fault hypothesis H M 0

Measurement components used by the FTFCS

All other fallible components: same as for fault hypothesis H M 0

Relational specification of the FTC-AR requirements

The relations of this section specify the fault tolerance requirements of section 5.1.3.

R ENV (H) describes the environment of the FTC-AR block under fault hypothesis

The relationship described captures the correlation between software variables that represent the airplane's state and actuator inputs The requirements for Fault Tolerant Control (FTC) disengagement are outlined in R F T C − OF F, while R F T C − DI details the detection and identification criteria applicable under all fault scenarios Additionally, R F T C − R specifies the necessary recovery requirements.

(³ Uˆ c ,Xˆ ´¯¯ ¯ ∃ U 0 w ∃ U 0 pm ∃ U 0 c ∃U˜ 0 c ∃ U 0 pa ∃ X 0 ³ ³ Uˆ c ,U˜ 0 c ´ ∈R out (H)◦R DAC (H) ∧ ³( ˜U 0 c ,X 0 ), U 0 c ´ ∈R ail (H) t R elv (H) t R rud (H) ∧ ³( ˆU 0 c ,U 0 pm ,U 0 w ,X 0 ), X 0 ´ ∈

R Keq t R Neq t R ad t R ka t ³ R aef t R grf t R csf (H) t R pf (H) t R wf ´ ◦R F eq t ³ R aem t R csm (H) t R pm (H) ´ ◦R Meq ∧ ³(U 0 pa ,X 0 ), Xˆ ´ ∈ ³ R p (H) t R q (H) t R r (H) t

Feasibility analysis

Traditional interpretation of detectability and identifiability 78

Fault detectability and identifiability, emerging concepts in fault diagnosis, have garnered limited attention in the technical literature, with varying interpretations presented in existing studies Frank et al define a system as unknown-input fault detectable if, within an arbitrarily small time interval, a unique determination of the fault can be made based solely on known inputs and available output data This definition positions fault detectability as a property applicable to nearly all faults within a system.

In a system, both detectable and undetectable faults can coexist, leading to overly restrictive detectability conditions According to Horak, a fault is considered detectable if its impact on system outputs surpasses model uncertainties By applying an optimization method based on the Maximum Principle, the maximum deviation between nominal and actual output values is calculated at each time step A fault is deemed detectable if it results in system outputs that fall outside the reachable measurement interval This approach emphasizes detection feasibility despite disturbances, yet it distinguishes between detectable and undetectable faults solely based on their temporal effects Additionally, faults that introduce low-amplitude, high-frequency components may be identified through frequency analysis, but they remain undetectable if their effects lie within the reachable measurement interval.

Fault detectability can be defined in various ways, either as the detection capability of a specific fault detection system or as the optimal detection capability achievable through a particular residual generation approach According to the fault transfer matrix defined in previous studies, a fault is detectable if the transfer function between the fault input and the residual vector is non-zero, while it is identifiable if the residual vector can distinguish it from other faults However, these definitions often depend on the specific residual generator used and do not encompass all relevant aspects of detectability and isolability A more comprehensive definition of detectability, independent of the residual generator, is proposed, stating that a fault is detectable if knowledge of system inputs and outputs over a finite time interval post-fault occurrence enables detection despite disturbances Key elements influencing fault detectability include fault dynamics, disturbance action, and system dynamics, leading to the formulation of an analytical criterion in the frequency domain.

Formal definition of detectability and identifiability

The definition of detectability and identifiability can be formulated on the basis of the fault detection and identification requirements specified in section 5.1.3:

- the correlation between ˆU c and ˆX allows distinguishing between conditions cap- tured by fault hypothesis H M 0 and conditions captured by any of the fault hypotheses H M 1 ,m and

- the correlation between ˆU c and ˆX allows distinguishing between conditions cap- tured by fault hypothesisH M 0 and conditions captured by fault hypothesisH M 2 and

- the correlation between ˆU c and ˆX allows distinguishing between conditions cap- tured by any of the fault hypotheses H M 1 ,m and conditions captured by fault hypothesis H M 2;

- The correlation between ˆU c and ˆX allows distinguishing between conditions captured by any couple of fault hypotheses H M 1 ,m and H M 1 ,n

The above definition can be formalized as follows:

The detectability condition 5.19, when examined alongside the detection requirement 5.17, clearly indicates that at no point can two of the three OR operands in the relation R F T C − DI be true simultaneously Additionally, all components highlighted in reference [29] are included in this detectability definition; specifically, the fault dynamics are represented by the fault mode defined in the fault hypothesis, while the system dynamics and disturbances are encapsulated within R ENV().

This research culminated in the formal specification of requirements for the Fault Tolerance Capability (FTC) system, which interfaces with the Automatic Flight Control System (AFCS) to enhance fault tolerance during sensor failures The specification serves as the baseline for the FTC system, initiating a refinement process throughout its lifecycle Developed from the AFCS performance and DHC-2 detail specifications, the fault tolerance requirements were derived from the military specification MIL-F-9490D and adapted for analytical redundancy after thorough analysis This extensive process clarified the fault tolerance challenges within the analytical redundancy framework and highlighted critical issues across FTFCS specification, analytical redundancy, and requirements engineering, with key insights summarized for future reference.

The re-engineering process of the active FCS specification uncovered the ambi- guity and incompleteness of the FCS performance and fault tolerance requirements.

The potentially hazardous aspects of the FCS specification do not necessarily pose a threat, as the goals of FCS certification extend beyond merely meeting the documented criteria Nonetheless, these issues underscore the specification's lack of maturity A more developed and precisely defined set of requirements would lead to improved design outcomes and a streamlined certification process, ultimately facilitated by automated tools.

The analytical redundancy approach offers fault tolerance primarily for functionally redundant components within a system, necessitating a certain level of physical redundancy in the Fault-Tolerant Flight Control System (FTFCS).

Analytical redundancy solutions are significantly influenced by their reliance on numerous environmental components, which affects both the modularity and certifiability of the Fault Tolerant Control (FTC) system To implement different FTC modules for various component classes, a priority ordering must be established, creating a stratified architecture where lower-layer monitored component faults remain transparent, while upper-layer faults are not Although the FTC architecture maintains modularity, it necessitates total fault tolerance for each module concerning all fallible components This requirement, along with the established priority ordering, can undermine the typical benefits associated with a modular design.

The certification of Flight Control Systems (FCS) is significantly influenced by the dynamics of the aircraft, necessitating a process similar to that of Automatic Flight Control Systems (AFCS), which entails substantial costs, time, and resources Additionally, the certification relies on the fault modes of both the aircraft and the Flight Control System components, requiring the FTC to be validated against every possible combination of component failures and fault modes The impact of non-transparent component failures on the FTC module is critical for determining the overall feasibility of the certification solution.

Adopting the analytical redundancy approach for fault tolerance has significant implications, emphasizing that the FTC fault tolerance requirements and certification procedures are more stringent than commonly found in existing literature These rigorous standards should inspire FTC designers to create more rational and effective designs rather than deter them While functional redundancy aids in achieving fault tolerance, the key challenge lies in integrating analytical redundancy with physical redundancy By incorporating analytical redundancy, it is possible to reduce the physical redundancy in multistring architecture from triple or quadruple to dual configurations, resulting in substantial benefits.

The observations in requirements engineering highlight the challenges associated with specification methodologies and the appropriateness of relational algebra as a formal specification language Issues such as hierarchical decomposition, specification modeling, and variable dependencies outside the system's input/output interface present significant difficulties The absence of a robust methodology for developing complex system specifications has notably hindered the specification process Additionally, the necessity for automated tools to aid in development and documentation is critical, as the complexity and interdependence of specifications, along with the ongoing need for modifications, demand a well-engineered development environment Without such automated tools, the advantages of formal specifications remain largely unrealized.

Monotonicity is a crucial characteristic of formal specification languages, enabling the modification and updating of specifications over time, which ensures continuity and consistency throughout the development process As the formalization of requirements enhances understanding of the underlying problem, it necessitates continuous updates, highlighting the significance of monotonicity The author's negative experiences with non-monotonic specification languages resulted in ineffective specifications, reinforcing the preference for relational algebra, which not only supports monotonicity but also offers readable predicate logic specifications without the need for cumbersome translations into rigid models.

Creating a formal specification demands significant resources; however, the investment leads to a deeper understanding of the problem being analyzed and results in clear, upgradable requirements It is particularly beneficial to employ formal specifications in systems where safety concerns are paramount.

[1] Background information and user guide for MIL-F-9490D Technical report AFFDL-TR-74-116, USAF, 1975.

[2] Flight control systems - design, installation and test of piloted aircraft, general specification for Military specification MIL-F-9490D, USAF, 1975.

[3] Appendix to background information and user guide for MIL-F-9490D Technical report AFFDL-TR-74-116 sup1, USAF, 1980.

[4] Flying qualities for piloted airplanes Technical Report MIL-F-8785C, USAF, 1980.

[5] Background information and user guide for MIL-F-8785C Technical report AFWAL-TR-81-3109, USAF, 1982.

[6] IEEE guide for developing system requirements specifications Standard IEEE Std 1233, IEEE, 1998.

[7] B D Appleby, J R Dowdle, and W Vander Velde Robust estimator design using à synthesis Proc of the 30th conference on Decision and Control, pages

[8] M Basseville Detecting changes in signals and systems - a survey Automatica,

[9] B W Boehm Verifyng and validating software requirements and design speci- fications IEEE Software, 1:75–88, 1984.

[10] F W Burcham, T A Maine, and C Gordon Development and flight test of an emergency flight control system using only engine thrust on an F-15 aircraft. Technical Report 94-02, NASA Dryden Flight Reserach Center, 1994.

[11] J Chen and R.J Patton Robust Model-Based Fault Diagnosis for Dynamic Systems Kluwer Academic Publishers, 1999.

[12] J Chen and H Y Zhang Parity vector approach for detecting failures in dy- namic systems Int Journal Sys Sci., pages 765–770, 1990.

[13] Jie Chen and R.J Patton A re-examination of fault detectability and isolability in linear dynamic systems Fault Detection, Supervision and Safety for Technical Processes, pages 567–73, 1994.

[14] E Y Chow and A S Willsky Issues in the development of a general algorithm for reliable failure detection Proc of the 19th Conf on Decision and Control,

[15] E Y Chow and A S Willsky Analytical redundancy and the design of robust detection systems IEEE Trans on Automatic Control, 29:603–614, 1984.

[16] R N Clark The dedicated observer approah to instrument failure detection.

Proc of the 18th IEEE Conf on Decision and Control, pages 237–241, 1979.

[17] J C Deckert, M N Desai, J J Deyst, and A S Willsky F-8 DFBW sensor fail- ure identification using analytical redundancy IEEE Transactions on Automatic Control, 22:795–803, 1977.

[18] X Ding, L Guo, and P M Frank A frequency domain approach to fault detection of uncertain systems Proc of the 32nd IEEE Conference on Decision and Control, pages 1722–1727, 1993.

[19] M Dorfman Requirements engineering Software Requirements Engineering, pages 7–22, 1997.

[20] Brooks F No silver bullet: Essence and accidents of software engineering Com- puter, April 1987.

[21] C Favre Fly-by-wire for commercial aircraft: The airbus experience Interna- tional Journal of Control, 59:139–157, 1994.

[22] P M Frank Fault diagnosis in dynamic system via state estimation - a survey. in Tzafestas, Singh, and Shmidt (Eds.), System Fault Diagnostics, Reliability and Related Knowledge-based Approaches, D Reidel Press, Dordrecht, pp.35-98,

[23] P M Frank and J Wunnenberg Robust fault diagnosis using unknown input schemes in R J Patton, P M Frank, and R N Clark (Eds.), ”Fault Diagnosis in Dynamic Systems: Theory and Application”, Prentice Hall, chapter 3, pp.47-

[24] P.M Frank and B Koppen Review of optimal solutions to the robustness prob- lem in observer-based fault detection Journal of Systems and Control Engineer- ing, 207(12):105–12, 1993.

[25] J Gertler Fault detection and isolation using parity relations Control Eng.Practice, 5:653–661, 1997.

[26] J Gertler and M Costin Model-based diagnosis of automotive engines-case study on a physical vehicle IFAC Symposium on Fault Detection, Supervision and Safety for Technical Processes - SAFEPROCESS ’94, 2:421–430, 1994.

[27] J Gertler and G DiPierro On the relationship between parity relations and parameter estimation Proc of the IFAC Sympo on Fault Detection, Supervision and Safety for Technical Processes: SAFEPROCESS’97, pages 453–458, 1997.

[28] J Gertler, Q Luo, K Anderson, and X W Fang Diagnosis of plant failures using orthogonal parity equations Proc of the 11th IFAC World Congress, 1990.

[29] D Del Gobbo and M Napolitano Issues in fault detectability for dyanmic systems American Control Conference, 2000.

[30] D M Himmelblau Fault detection in heat exchangers Proceedings of the 1992 American Control Conference, 2:2369–2372, 1992.

[31] D E Hoak, D E Ellison, and et al USAF Stability and Control DAT- COM Flight Control Division, Air Force Flight Dynamics Laboratory; Wright-

Patterson Air Force Base, Ohio., 1968.

[32] D.T Horak Failure detection in dynamic systems with modeling errors Journal of Guidance, Control, and Dynamics, 11(6):508–16, 1988.

[33] R Isermann Process fault detection based on modelling and estimation methods:

[34] R Isermann Experiences with process fault detection via parameter estimation. in Tzafestas, Singh, and Shmidt (Eds.), System Fault Diagnostics, Reliability and Related Knowledge-based Approaches, D Reidel Press, Dordrecht, pp 3-33,

[35] R O Lewis Independent Verification and Validation: A Life Cycle Engineering Process for Quality Software John Wiley & Sons, 1992.

[36] Jackson M The meaning of requirements Annals of Software Engineering,

[37] Rauw M FDC 1.2 - A Simulink toolbox for flight dynamics and control analysis

- user manual http://www.mathworks.com/, 1998.

[38] Rauw M.O A Simulink environment for flight dynamics and control analysis - application to the DHC-2 ’beaver’.Graduate’s thesis Delft Univ of Thechnology, the Netherlands, 1993.

[39] M R Napolitano, V Casdorph, C Neppach, S Naylor, M Innocenti, and G Sil- vestri Online learning neural architectures and cross-correlation analysis for actuator failure detection and identification International Journal of Control,

[40] M R Napolitano, C I Chen, and S Naylor Aircraft failure detection and iden- tification using neural networks Journal of Guidance, Control, and Dynamics,

[41] M R Napolitano, D A Windon, J L Casanova, M Innocenti, and G Silvestri. Kalman filters and neural-network schemes for sensor validation in flight control systems IEEE Transactions on Control Systems Technology, 6:596–611, 1998.

[42] B A Nuseibeh and S M Easterbrook Requirements engineering: A roadmap.

Proceedings, 22nd International Conference on Software Engineering (ICSE’00), pages 35–46, June 4-11 2000.

[43] M Nyberg and L Nielsen Parity functions as universal residual generators and tool for fault detectability analysis 36th IEEE Conference on Decision and Control, 5:4483–9, 1997.

[44] S Osder Practical view of redundancy management-application and theory.

Journal of Guidance, Control, and Dynamics, 22:12–21, 1999.

[45] J H Park, Y Halevi, and G Rizzoni A new interpretation of the fault-detection filter 2: Theoptimal detection filter Int Journal of Control, 60:1339–1351, 1994.

[46] J H Park and G Rizzoni A new interpretation of the fault-detection filter 1: Closed-form algorithm Int Journal of Control, 60:767–787, 1994.

[47] R J Patton Robust model-based fault diagnosis: The state of the art IFAC Symposium on Fault Detection, Supervision and Safety for Technical Processes - SAFEPROCESS ’94, 1:1–24, 1994.

[48] R J Patton and J Chen A re-examination of the relationship between parity space and observer-based approaches in fault diagnosis European Journal of Diagnosis and Safety in Automation, 1:183–200, 1991.

[49] R J Patton and J Chen Robust fault detection of jet engine sensor systems using eigenstructure assignment Journal of Guidance, Control and Dynamics,

[50] R J Patton, J Chen, and C J Lopez-Toribio Fuzzy observers for non-linear dynamic systems fault diagnosis Proceedings of the 37th IEEE Conference on Decision and Control, 1:84–89, 1998.

[51] R.J Patton, P M Frank, and R N Clark (Eds.) Issues of Fault Diagnosis for Dynamic Systems Springer Verlag, 2000.

[52] Patton R.J., Frank P., and Clark R.Fault Diagnosis in Dynamic Systems, Theory and Applications Prentice Hall, 1989.

[53] Tjee R.T.H and Mulder J.A Stability and control derivatives of the De Hav- illand DHC-2 ’beaver’ aircraft Report LR-556, Delft Univ of Technology, The Netherlands, 1988.

[54] M A Sadrnia, J Chen, and R J Patton Robust fault detection observer design using H ∞ /àtechniques for uncertain falight control systems Proc of the 2ndIFAC Symposium on Robust Control Design: RECOND97, pages 531–536,

[55] G Schmidt and T Strohlein Relations and Graphs Springer Verlag, 1993.

[56] K.J Szalai, R.R Larson, and R.D Glover Flight experience with flight control redundancy management In AGARD Lecture Series No.109 Fault Tolerance Design and Redundancy Management Techniques, AGARD Lecture Series, pages

8/1–27, AGARD, Neuilly-sur-Seine, France, October 1980 AGARD.

[57] A T Vemuri and M M Polycarpou Neural-network-based robust fault diag- nosis in robotic systems IEEE Transactions on Neural Networks, 8:1410–1420,

[58] Alagar V.S and Periyasamy K Specification of Software Systems Springer

[59] J L Weiss and J Y Hsu Design and evaluation of a failure detection and isolation algorithm for restructurable control systems Technical Report NASA- CR-178213, 1985.

[60] A S Willsky A survey of design methods for failure detection in dynamic systems Automatica, 12:601–611, 1976.

[61] A S Willsky, J J Deyst, and B S Crawford Adaptive filtering and self- test methods for failured detection and compensation Proc of the 1974 Joint American Control Conf., pages 637–645, 1974.

[62] Y.C Yeh Triple-triple redundant 777 primary flight computer IEEE AerospaceApplications Conference, February 1996.

This appendix offers a formal definition of the syntax and semantics of predicate logic and relational algebra, which are essential for relational specifications Predicate logic serves as the formal language used in these specifications, while relational algebra provides the mathematical framework for manipulating them The information presented here supports the discussions in chapters 4 and 5, as well as appendix B, and is primarily derived from references [55] and [58].

Logic

Propositional logic

A proposition is a statement that is eitherTrue (T) orFalse (F).Propositional logic consists of sentences constructed from atomic formulas and the logical connectives

Table A.1: Syntax of propositional logic terminals = {P, Q, R, , ơ, ∧, ∨, ⇒, ⇔,(,);} nonterminals = {atomic f ormula, sentence}; atomic f ormula = P |Q|R| ; sentence = atomic f ormula |(, sentence,)| ơ, sentence | sentence, ∧, sentence| sentence, ∨, sentence| sentence, ⇒, sentence| sentence, ⇔, sentence;

∧ (and), ∨ (or), ơ (not), ⇒ (if then), ⇔ (if and only if) Atomic formulas are the simplest form of propositions Examples of atomic formulas are:

Table A.1 outlines the syntax of the language using Backus-Naur formalism, while Table A.2 details its semantics The precedence of logical operators is ranked as follows: ơ, ∧, ∨, ⇒, ⇔, with ơ having the highest priority To determine the semantics of a sentence, truth values (T or F) are assigned to atomic formulas, and sentences are evaluated based on the language's semantics.

Predicate logic

Table A.3 defines the syntax of predicate logic Constants and connectives are in- terpreted as in propositional logic Predicates are functions that evaluate either true

Table A.2: Semantics of propositional logic

Table A.3: Syntax of predicate logic f ormula = proposition|predicate| ơf ormula| quantif ied f ormula|

A formula in logic is structured as a proposition consisting of components such as predicates, terms, and operations Predicates are identified by a name followed by a list of terms, which can be constants, variables, or functions Variables can be quantified using existential (∃) or universal (∀) quantifiers Formulas can contain operations like conjunction (∧), disjunction (∨), implication (⇒), and equivalence (⇔) Variables in a formula may be either quantified or free, with closed formulas being those where every variable is quantified These closed formulas can be evaluated as true or false, depending on the assignments made to the free variables within a defined domain Each interpretation of a formula results in a specific truth value based on the assigned values to its free variables.

• evaluation of functions and predicates according to their semantics

• evaluation of propositions and non-quantified sub-formulas according to the semantics of propositional logic

• evaluation of quantified formulas according to the following semantics:

– a quantified formula of the type∀x F evaluates true ifF is true for every value ofx in the domain of interpretation; otherwise it evaluates false

– a quantified formula of the type∃x F evaluates true if there exists at least one value of x within the domain of interpretation for which F is true; otherwise it evaluates false

Each operation is carried out to reduce the arguments of the formula until the truth value of the formula can be determined.

Relational algebra and requirements specification

Basics of relational algebra

Given two spaces (or sets) A and B , a relation R over A × B is a subset of A × B and is specified as follows:

The above expression reads: relation R is the set of couples of elements (A,B) ∈

In the context of predicate logic, we denote a relation A × B where the formula F(A, B) evaluates to true The specifics of the predicate logic formula F are defined according to the syntax and semantics outlined in section A.1.2 Unless stated otherwise, all relations discussed pertain to the space A × B.

In a relation R, if (A, B) is an element, A is referred to as the antecedent and B as the image The set of images corresponding to A in relation R is represented as A • R, while the set of antecedents for element A is denoted R • A The domain of relation R, indicated as dom(R), encompasses all antecedents, whereas the range, or codomain, of relation R, represented as rng(R), includes all images.

Universal relation The universal (or total) relation over the set A is defined by

Identity relation The identity relation over the set A is defined by {(A,A 0 )| A A 0 } and is denoted by I A Given a set S ⊆ A we define I A ( S ) ={(A,A 0 )|

Relations, being sets, utilize various set operators such as the power set (P(S)), complement (¬S), Cartesian product (×), intersection (T), difference (\), union (S), and inclusion ordering (⊇) The precedence of these operators follows their introduction, with the power set operator holding the highest priority Additional operators specifically related to relations are defined subsequently.

Inverse The inverse of relation R is the relation over ⊆ B × A denoted ˆ R and defined by:

Restriction Theprerestriction of relation R to subset S of A is the relation denoted by S\ R and defined by:

The postrestriction of relation R to subset S of B is the relation denoted by

Relational specifications

In the context of requirements specification, expression A.1 represents the objects involved in formulating the requirement through domain and image variables Here, A and B are structures containing the respective domain and image variables The formula F(A,B) serves as a predicate logic expression that articulates the requirement using these variables, along with any additional quantified variables, functions, and constant values.

Relational algebra serves as a formal framework for reasoning with predicate logic specifications, utilizing composition operators and a refinement ordering among requirement specifications This approach enables the breakdown of system behavior into distinct parts, each represented by a relation By composing these relations, a comprehensive requirements specification is formed Additionally, the refinement ordering illustrates the relative strength of two requirements, facilitating the definition of a system's implementation correctness in relation to its specified requirements.

Refinement ordering Relation R is said to refine (or be a refinement of ) relation

R 0 (denoted by R w R 0 ) if and only if

• dom( R ) ⊇ R 0 , that is the requirement specified by R extends over a larger (or equal) number of input scenarios, or

• ∀ A(A ∈dom( R 0 ) ⇒ A •R⊆ A •R ), that is relation R is more specific in its assignment of outputs to inputs.

The established hierarchy among specifications indicates the intensity of the associated requirements Relation R enhances relation R0 by specifying a more stringent requirement that is more challenging to meet Consequently, if R is a refinement of R0, then any system that fulfills R will also comply with R0.

If R w R 0 , then any system that satisfies R satisfies R 0

Correctness A system implementation P is said to be correct with respect to its specification R if and only if

Product The product of relation R 1 ⊆ A × K by relation R 2 ⊆ K × B is the relation over A × B denoted by R 1 ◦R 2 (or R 1 R 2 ) and defined by:

Join The sum of the requirement information of two relations R 1 ⊆ A × B and

R 2 ⊆ A × B is called the join of R 1 and R 2 and is denoted by R 1 t R 2 The join of two relations is defined as follows:

The join exists if and only if R 1 and R 2 do not contradict each other The consistency condition to check whether the join of relations R 1 and R 2 exists is the following:

Meet The common requirement information of two relations R 1 ⊆ A × B and

R 2 ⊆ A × B is called the meet of R 1 and R 2 and is denoted by R 1 u R 2 The meet of two relations is defined as follows:

Expansion operation If R is a relation over the space S = A × B , its expansion over the space S 0 =( A , A 0 ) × ( B , B 0 ) is defined as follows: σ S S 0 ◦R◦σˆ S S 0 (A.13) where the operator σ S S 0 is defined by: σ S S 0 = n (S,S 0 )| A(S) =A(S 0 ) ∧ B(S) =B(S 0 ) o (A.14)

The expansion operation is used to expand the spaces over which the relation is defined in order to apply the composition operators.

In relational specifications, operators from relational algebra, set theory, and logic can coexist within the same expression The evaluation order prioritizes relational operators first, followed by set operators, and finally logic operators Additionally, the precedence among operators within the same class has been detailed in section A.1.1 for logic operators.

A.2.1 for the set operators The precedence ordering among relational operators is the following: restriction, inverse, complement, product, meet, join; restriction being the operator with higher priority.

This appendix outlines the fundamental specifications of the AR-FTC environment, organized into five distinct sections Section B.1 details the relations utilized in the AFCS performance specification, while Section B.2 focuses on relations relevant to the DHC-2 detail specification Section B.3 describes various fault modes, Section B.4 presents the restriction sets, and Section B.5 outlines the relations that define the interface blocks of the FTC system with the AR-FTC module Requirements are articulated through relations based on the syntax and semantics introduced in Appendix A.

Elementary requirements of AFCS performance specification

3.1.2 AFCS performance requirements Unless otherwise specified, these requirements apply in smooth air and include sensor error .

In smooth air conditions, the pitch and roll attitudes must be maintained with high precision, achieving a static accuracy of ±0.5 degrees in pitch attitude and ±1.0 degrees in roll attitude, relative to the reference The wings should remain level during this process to ensure optimal performance and stability.

(θ r (), φ r ()∈D;constRef()∈A). d) RMS (RM S() ∈ A) attitude deviations shall not exceed 5 degrees in pitch

In turbulence conditions, the roll attitude should be maintained within 10 degrees, adhering to the specified intensity levels outlined in section 3.1.3.7 Accuracy requirements must be met and sustained within 5 seconds of mode engagement for both pitch and roll attitudes, particularly when addressing a 5-degree attitude disturbance.

FOR EVERY couple of time instants t 1 , t 2

- [t 1 , t 2 ] is a time interval within [0,∞) AND f) the length of the time interval [t 1 , t 2 ] is larger than T θ AND b) the aircraft is wings level throughout the interval [t 1 , t 2 ] AND

- the PAH control function is engaged at t = t 1 and stays engaged throughout the interval [t 1 , t 2 ] AND

- the reference pitch is constant throughout the interval [t 1 , t 2 ] AND g) the pitch deviation from the reference at engagement is ∆θ ∗

In the absence of turbulence during the time interval [t1, t2], the pitch angle deviation from the reference must remain within θ_acc at all moments from [t1 + T_θ, t2] Conversely, if turbulence occurs within this interval, the root mean square (RMS) value of the pitch angle deviation from the reference should not exceed θ_RMS over the period [t1 + T_θ, t2].

∀t ³ t 1 ≤t ≤t 2 ⇒ |φ(t)|< φ acc ´ ∧ engaged(SW P AH (), t 1 , t 2 ) ∧ constRef(θ r (), t 1 , t 2 ) ∧

|θ(t 1 )−θ r (t 1 )|= ∆θ ∗ ⇒ ³ ơturb(t 1 , t 2 ) ⇒ ∀t ³ t 1 +T θ ≤t≤t 2 ⇒ |θ(t)−θ r (t 1 )|< θ acc ´´ ∧ ³ turb(t 1 , t 2 ) ⇒ RM S(θ()−θ r (t 1 ), t 1 +T θ , t 2 )< θ RM S ´ ´)

FOR EVERY couple of time instants t 1 , t 2

- [t 1 , t 2 ] is a time interval within [0,∞) AND f) the length of the time interval [t 1 , t 2 ] is larger than T θ AND

- the RAH control function is engaged at t = t 1 and stays engaged throughout the interval [t 1 , t 2 ] AND

- the reference bank is constant throughout the interval [t 1 , t 2 ] AND g) the roll deviation from the reference at engagement is ∆φ ∗

If there is no turbulence during the interval [t1, t2], the bank angle deviation from the reference must remain within φ acc throughout the period [t1 + T φ, t2] Conversely, if turbulence occurs within the same interval, the root mean square (RMS) value of the bank angle deviation from the reference must not exceed φ RMS during the time frame [t1 + T φ, t2].

|φ(t 1 )−φ r (t 1 )|= ∆φ ∗ ⇒ ³ ơturb(t 1 , t 2 ) ⇒ ∀t ³ t 1 +T φ ≤t≤t 2 ⇒ |φ(t)−φ r (t 1 )|< φ acc ´´ ∧ ³ turb(t 1 , t 2 ) ⇒ RM S(φ()−φ r (t 1 ), t 1 +T φ , t 2 )< φ RM S ´ ´)

In smooth air, the heading must be maintained within a static accuracy of ±0.5 degrees relative to the reference heading In turbulent conditions, the root mean square (RMS) deviations in heading should not exceed 5 degrees at specified intensity levels When the heading hold feature is activated, the aircraft is required to roll towards a wings-level position The reference heading is defined as the heading at which the aircraft achieves a wings-level roll attitude, allowing for a specified tolerance.

FOR EVERY couple of time instants t 1 , t 3

[t 1 , t 3 ] is a time interval within [0,∞) AND the HH control function is engaged at t = t 1 and stays engaged throughout the interval [t 1 , t 3 ]

There exists a specific time instant \( t_2 \) and a reference heading \( \psi_r \) such that \( t_2 \) falls within the interval \([t_1, t_3)\), the bank angle remains approximately zero during \([t_2, t_3)\), and the reference heading \( \psi_r \) corresponds to the heading angle at \( t = t_2 \) Additionally, if no turbulence occurs within \([t_1, t_3]\), the deviation of the heading angle \( \psi \) from the referenced heading \( \psi_r \) must not exceed \( \psi_{acc} \) throughout \([t_2, t_3]\) Conversely, if turbulence is present during this interval, the root mean square (RMS) value of the deviation of the heading angle \( \psi \) from \( \psi_r \) over \([t_2, t_3]\) must not surpass \( \psi_{RMS} \).

∀t ³ t 2 ≤t ≤t 3 ⇒ |φ(t)|< φ acc ´ ∧ ψ r =ψ(t 2 ) ∧ ơturb(t 1 , t 3 ) ⇒ ∀t ³ t 2 ≤t≤t 3 ⇒ |ψ(t)−ψ r |< ψ acc ´ ∧ turb(t 1 , t 3 ) ⇒ RM S(ψ()−ψ r , t 2 , t 3 )< ψ RM S ´ ´)

The aircraft must automatically adjust to the selected heading by turning through the smallest angle while maintaining that heading within specified tolerances The contractor is responsible for establishing a bank angle limit that ensures a satisfactory turn rate without risking a stall Additionally, the aircraft should not overshoot the selected heading by more than 1.5 degrees, and both entry into and exit from the turn must be smooth and rapid Furthermore, the roll rate should not exceed 10 degrees per second, and the roll acceleration must remain within a limit of 5 degrees per second squared.

FOR EVERY couple of time instants t 1 , t 4

During the time interval [t1, t4], the HS control function remains engaged, maintaining a constant reference heading Throughout this period, the heading deviation from the reference is restricted to a maximum of 180 degrees, while the roll rate and roll acceleration are limited to values not exceeding p+ and ˙p+, respectively The bank angle is required to remain within the range [φ−, φ+] There exists a specific moment, t2, within the interval where the heading approaches the reference, having previously deviated, and it will not exceed a deviation of ψos in the subsequent period [t2, t4] Additionally, at a time t3 within [t2, t4], if no turbulence occurs, the heading angle deviation will not surpass ψacc, whereas, in the presence of turbulence, the RMS value of the heading deviation during [t3, t4] must remain below ψRMS.

∃t 3 ³ t 2 ≤t 3 ≤t 4 ∧ ơturb(t 1 , t 4 ) ⇒ ∀t ³ t 3 ≤t≤t 4 ⇒ |ψ(t)−ψ r (t 1 )|< ψ acc ´ ∧ turb(t 1 , t 4 ) ⇒ RM S(ψ()−ψ r (t 1 )r, t 3 , t 4 )< ψ RM S ´ ´)

Lateral acceleration and sideslip limits are crucial performance metrics that must be maintained whenever a lateral-directional Automatic Flight Control System (AFCS) function is activated Lateral acceleration specifically pertains to the apparent acceleration sensed at the aircraft's center of gravity.

In steady banked turns, it is crucial that the incremental sideslip angle (β) does not exceed 2 degrees from the trimmed value, and the lateral acceleration should remain within 0.03g These parameters must be maintained while operating at a steady bank angle, up to the maneuver bank angle limit, during normal maneuvers with the Automatic Flight Control System (AFCS) engaged.

FOR EVERY couple of time instants t 1 , t 2

The time interval [t1, t2] is defined within the range of [0, ∞) During this period, one of the control functions—RAH, HH, or HS—must be in an engaged status Additionally, the airplane must maintain a steady bank turn, ensuring that the bank angle remains within permissible limits throughout the entire interval.

During the interval [t1, t2], if there is no turbulence, the deviation of the sideslip angle from its trim value must remain within the limits of ∆β/SBT Additionally, the lateral acceleration should not surpass A + ycg/SBT throughout this same interval.

(³(U w ,U p ,X,C tr ),X 0 ´¯¯ ¯ ∀t 1 ∀t 2 ³ 0≤t 1 < t 2 φ acc ´ ∧ ơturb(t 1 , t 2 ) ⇒

∀t ³ t 1 ≤t ≤t 2 ⇒ |β(t)−β tr |