Abstract
This work presents a systematic process for building a Fault Diagnoser (FD), based on Petri Nets (PNs) which has been applied to a small helicopter. This novel tool is able to detect both intermittent and permanent faults. The work carried out is discussed from theoretical and practical point of view. The procedure begins with a division of the whole system into subsystems, which are the devices that have to be modeled by using PN, considering both the normal and fault operations. Subsequently, the models are integrated into a global Petri Net diagnoser (PND) that is able to monitor a whole helicopter and show critical variables to the operator in order to determine the UAV health, preventing accidents in this manner. A Data Acquisition System (DAQ) has been designed for collecting data during the flights and feeding PN diagnoser with them. Several real flights (nominal or under failure) have been carried out to perform the diagnoser setup and verify its performance. A summary of the validation results obtained during real flight tests is also included. An extensive use of this tool will improve preventive maintenance protocols for UAVs (especially helicopters) and allow establishing recommendations in regulations.
1. Introduction
The growth in number and complexity of Unmanned Aerial Systems (UAS) missions within civil frameworks is significant. Nevertheless, there is an enormous gap between large and expensive military systems that are able to board redundant equipment and complete health monitoring systems and small, light, and inexpensive commercial aircrafts. Thus, although there are several initiatives aiming at including the UAVs in the nonsegregated air space by using a unique Aerial Traffic Management (ATM) system, these approaches are not affordable for small commercial units. For this reason, during the last years, different organizations [1] have contributed with outstanding efforts to create a necessary regulatory framework that allows integrating small UAS within everyday activities. According to these efforts, some researchers [2] involved in UAS operations are concerned not only about the frequency and incidence of accidents caused by UAS failures but also about of surveillance and safety of the population. Moreover, few attempts have been made in Europe for identifying their causes, including them into the regulation to define and standardize the foundations and routines for the use of UAS in order to decrease the percentages of failure. In addition, according to the report about data reliability of UAVs in military field of the United States [3], UAVs are highly vulnerable to unforeseen situations of the equipment devices (control station and aircraft) and operating environment where they are tested.
Although multirotor systems (e.g., quadrotors and hexrotors) have recently broken into the market in the category of mini-UAVs due to their simplicity, helicopters are still the most frequent option when hovering maneuvers are required in the mission, mainly due to their higher payload capability with respect to the multirotor systems.
Remotely piloted helicopters are inherently unstable with fast dynamics. They do not have the graceful degradation properties of fixed-wing aircrafts or airships in case of failures. Even when stability augmentation devices are used, a skilled pilot is required to control them during flight. Therefore, a helicopter (HC) has been used for this research, considering that helicopters are the most complex platform from the mechanical point of view. Hence, a failure in any part of the autonomous helicopter (i.e., sensors, actuators, or control system) can lead to a dangerous situation.
The motivation behind our work is to collect data about the behavior of the helicopter flying in normal and fault conditions, which will provide the foundations for developing strategies of FDI that will allow to prevent the aircraft from accidents. Thus, the main contribution of this work is to report how to develop an FD tool based on PN, capable of detecting permanent and intermittent faults. Moreover, the procedure presented in this work illustrates how the thresholds of each variable have been established, for both normal and fault conditions.
Although initially the tool has been used for FD in UAS, in the near future, it can be applied to any kind of system. FDI techniques have been widely applied in process industry [4, 5]. Some approaches can also be found in the field of UAS to detect faults in sensors and actuators. Thus, Fault Tolerant Control (FTC) techniques or Fault Detection Isolation and Recovery (FDIR) techniques are required if a fault is detected. In these cases, the structure of the controller has to be changed to get the best possible response of the system, since the system cannot be stopped. FD techniques applied to UAS are commonly based on analytical model approaches, signal processing based approaches, and knowledge based approaches [6]
Analytical model-based FD approaches make use of mathematical models. Moreover, helicopters exhibit complex dynamics, which makes it difficult to create high fidelity models able to detect small deviations or abnormal functioning. Nevertheless, fault isolation observers for square and nonsquare linear systems can be found in the literature [7]. They provide the observer with a design that ensures the stability and minimizes the influence of disturbances on the residuals at the same time. Other approaches such as the Unknown Input Observer (UIO) designed by Liu et al. [8] aiming at tracking actuator fault parameters and decoupling the effect of faults and unknown inputs are valuable contributions. Moreover, Qi et al. [9, 10] propose states and parameters combined estimation based on square-root Unscented Kalman Filter (UKF) and Kalman Filter- (KF-) based adaptive UKF with a full nonlinear model of an unmanned helicopter (UH). The KF-based adaptive UKF is composed of two parallel master-slave filters. The KF-based adaptive UKF is simpler and more effective than UKF estimation method.
Signal processing based methods are developed on the basis of thorough analyses of the failure mechanisms to determine signal characteristics that can represent failures. A novel wavelet-based approach to detect an abrupt sensor fault in a UH system is presented in [11], accurately localizing the characteristics of a signal (time and frequency domains) and the occurring instants of abnormal status of a sensor in the output signal, whereas an experimental validation of wavelet-based analytical redundancy technique on a 3-degree-of-freedom UH platform is presented in [12]; the technique successfully detects a fault of small magnitude, consisting of a 10% reduction in the pitch sensor gain. Furthermore, a technique for detecting the faults by measuring the rate of change of data with respect to time is applied in [13].
On the other hand, knowledge based FD approaches require a deep cognition of the entire process, acquired typically during the operation of the system. Thus, the knowledge allows avoiding the reliance on accurate mathematical models. For instance, an adaptive threshold Neural Network scheme for UH sensor failure diagnosis is presented in [14], the adaptive threshold approach eliminates the need for thresholds changing with flight conditions.
Previous works as [15], applied to fault diagnosis of Discrete Events Systems (DES), use Regular Languages, State Graphs, or Finite State Machines (FSMs) for modeling the knowledge. These techniques highlight a main drawback, which is the combinational explosion that makes their elaboration difficult when the number of the components increases. Another approach [16] applies the concepts of marking and justification. This allows performing diagnosis without performing an exhaustive enumeration of the states. An evolution of this work can be found in [17], where interpreted Petri Nets are used to model the system, taking advantage of the power of the PNs by making a better use of their mathematical basis. A generalization of the problem that uses a centralized diagnosis solution for diagnosing a distributed system can be found in [18]. This method known as Diagnoser Approach splits the net into modules that may share places, which are called “bordered places.” A communication system connects the different modules and updates the diagnosis information.
Considering fault diagnosis applied to Hybrid Systems, a hybrid integration of discrete and continuous FD techniques can be found in [19], where hybrid automata, timed Petri Nets, fault trees, and signal processing techniques are integrated in a single tool.
Petri Nets are a well-known method for implementing Fault Diagnosers due to their capability to manage concurrence. They allow representing either small or large systems. A large number of references can be found in the literature [20–22].
Among the different types of PNs, interpreted PN is the most adequate to represent the model of a system [23, 24].
This work is a useful guide to close the gap between the theory and a real application, and this is one of the most important contributions of the work, since it shows a complete methodology to build a diagnoser of a complex system based on interpreted PN. Moreover, the work includes real data validation in UAV applications, which has not been previously found in the literature.
The present Petri Net diagnoser is able to detect not only permanent but also intermittent failures avoiding combinational explosion problems. Furthermore, flexible architecture of the PND allows including additional devices to the model. The tool can be used in different areas of engineering (industrial process, Robotics, etc.).
Section 2 summarizes the basis of Petri Nets, necessary for understanding the models in the process of fault diagnosis. Section 3 describes the methodology for building the model and the diagnoser, starting with the models of the components for each subsystem and ending with a unique PN as diagnoser. Section 4 shows the results when applying the diagnoser to a radio control helicopter considering both normal and fault operations. Finally, the conclusions of the work are presented in Section 5, analyzing different options for future work.
2. Petri Nets
Petri Nets (PNs) are a graphical and mathematical modeling tool that has been widely applied, especially in the field of automation. They allow describing concurrent, parallel, asynchronous, distributed, and not deterministic systems by using marks to simulate the dynamics and concurrency activities. From mathematical point of view, PNs manage either state equations, algebraic equations, or some other kind of models that can govern the behavior of systems. An excellent reference of the theory that applies to Petri Nets can be found in [25].
A Petri Net (PN) has two types of nodes, namely, places and transitions. A place is represented by a circle and a transition by a bar. Places and transitions are connected by arcs. The number of places and transitions is finite and not zero. An arc is directed and connects either a place to a transition or a transition to a place. In other words, a PN is a bipartite graph; that is, places and transitions alternate on a path made up of consecutive arcs.
Definition 1. An unmarked ordinary PN is a quadruple such that is a finite, nonempty set of places; is a finite, nonempty set of transitions; ; that is, the sets and are disjointed; denotes the input incidence application; denotes the output incidence application. characterizes the weight of the arc . Thus, the weight is 1 if the arc exists and 0 if not. Conversely, denotes the weight of the arc .
The following notations will be used: is set of input places of ; is set of output places of ; is set of input transitions of ; is set of output transitions of .
Definition 2. A marked PN is a pair in which is an unmarked PN and an initial marking. The validation conditions can be expressed in the following way: transition is enabled for a marking if for every .
The reachability set of the PN is the set of all marked reachable from , activating only enabled transitions; this set is denoted by . A sequence of transitions firing of a PN is a sequence of transition , such that . The set of all firing sequences is called the language :
2.1. Interpreted Petri Nets
Among the different types of PN (interpreted and colored), this research work deals with the interpreted Petri Nets (IPNs) mainly due to their features such as synchronization, timed places, and a part for processing data.
The inputs are associated with the transitions and outputs are associated with places. As Figure 1 illustrates, the event and condition are associated with transition . Thus, condition is a Boolean function that depends on both the data processing part and the environment. Event is either an external event derived from the environment or the always occurring event Transition will be activated as follows.
If transition is enabled and if condition is true, when event occurs.
The product is called the receptivity of transition . Actions denoted in the figure , and are associated with place . When a token is deposited in place , at instant , the operation is carried out and the impulse action is sent to the environment. The Boolean output has the Boolean value 1 as long as there is a token in .
A control interpreted Petri Net exhibits the following five characteristics.
Necessary characteristics are as follows:(1)It is synchronized on external events and stable.(2)It is safe ().(3)It is deterministic (no conflict).
Frequent characteristics are as follows:(4)It relies on a data processing part, whose state is defined by a set of variables . This state is modified by operations , which are associated with the places. It determines the value of the predicates .(5)It receives Boolean information from the ambient. It sends level actions (Booleans) and impulse actions (event type), associated with the places, to the environment.
3. Building Process of Model and FD Diagnoser
Let be the PN that represents the model of the system to diagnose, where both normal and fault operation are considered. Moreover, transitions can be classified as unobservable and observable , as . Observable transitions are those transitions that are activated by control events (command supervisor) or the instrumentation deployed in the process . Therefore, . On the other hand, not observable transitions are those that are not detected by the system when they happen. Thus, fault transitions are a subset of the unobservable transitions . can be classified into disjointed sets, corresponding to different types of failure that may occur in the system, consequently . denotes the number of components of the system. According to this, when a type fault occurs, a transition of set will be activated. Faults distribution defines the faults set to be evaluated in the system.
This section summarizes the procedure for modeling and diagnoser designing. As previously mentioned, the system is made up of several subsystems working together and sharing different functionalities. Consequently, they are linked by several dependence relationships.
Step 1 (to divide the system into subsystems). The system can be split into subsystems with close relationships among them, depending on their performance. Thus .
Step 2 (to build up the PN model of the components of each subsystem). Let be the marked PN of the -component belonging to subsystem, , with being the number of components in the subsystem . is a set of places, is a set of transitions, are the input/output incidence applications, and is the initial marked.
Step 3 (operation of integration). The following notation will be used to denote the integration operation for the subsystem : . Therefore, refers to the representation of the subsystem behavior through of a stand-alone PN model, which includes different PN models corresponding to its components. Since this model integrates the normal and fault behavior of the system, transitions (observable and unobservable ) can occur from any place of the model. Let and be the sets of places and transitions of of the subsystem, composed by the union of place and transitions of the components, respectively, as follows:The following process has to be completed to build the integration model.
Step 3.1. Define the set of faults for each component of the subsystem:Step 3.2 (define the initial place ). It brings the initial places of each component of the subsystem together:Step 3.3 (assign a mark to initial place ). It defines the starting point for the evolution of the subsystem represented.
Step 3.4 (build the branch corresponding to normal conditions ). It designates the interaction and evolution of the components. Transitions are merely composed by controller commands . The set of places of the subsystem is made up of the places of each component.
Step 3.5 (add the faults places ). A place for each fault from the set has to be generated.
Step 3.6 (add the transitions faults ). From each place of general PN, a fault transition is therefore added:Step 3.7. Connect the normal places to the fault transitions and the faults transitions to the faults places by using arcs.
Step 4 (refine the general model). It is necessary to consider only the observable part of general model ; therefore, must be transformed to refined model . It is only made up of observable transitions and places. According to this, fault transitions have to be replaced by readings of the sensor . The following process must be followed to refine the model.
Step 4.1 (identify the sensors of the system). Each subsystem has sensors.
Step 4.2 (build a discrete set of the sensors outputs). represents the number of combinations of the sensors readings. Hence, are the inputs for the sensors integration table. Consider . See first column (with “”) of Table 1.
Step 4.3 (define the outputs of the integration table). An output (column) in the sensors integration table is added for each branch of normal conditions in PN for each subsystem. Each place represents the current state of sensors readings, as first row (†) in Table 1 depicts.
Step 4.4 (build the sensors integration table). Consider , , where denotes the discrete set of sensor outputs possible of subsystem ; it defines The integration sensor table is defined by The inputs of the integration table and the sensors expected readings of each place of the normal branch must be compared; that is, if the sensor readings and the expected readings are the same, then is classified as normal . Moreover, the readings can lead to fault or to indeterminate when they have no information to use. Consider . The results of this classification are marked with “‡” in Table 1.
Step 4.5 (replace the fault transitions and remove the places which are not reachable). The fault transitions of the PN general model have to be replaced by the sensor readings. The fault places that cannot be identified because the information available does not allow enabling the market of that place must be removed of . .
Finally, the refined integration model of each subsystem is made up of normal places and fault places given in , . Transition includes control events and those considered in the integration table ; consider . In conclusion, the refined model of each subsystem will be composed only by observable events.
Step 5 (create the diagnoser). The diagnoser is a PN that is implemented considering the refined model of the system. Let be the PN that represents the refined model of each one of the subsystems of the whole system () and the final transition from a sequence , defined as follows: denotes a set of all sequences of (languages representing system behavior) that end in a fault transition, belonging to the class . Consider and . The notation is used to denote that is a transition of the sequence , also writing to any .
In addition to this, a label has to be assigned to each system fault, producing a set of fault labels defined according to the expression .
In general, a set of labels is made up of normal labels and fault labels ; thus .
In general, the diagnoser for system is a PN of the form , such that(i) is a finite, nonempty set of places;(ii) is a finite, nonempty set of transitions;(iii); that is, the sets and are disjointed;(iv): is the input incidence application;(v): is the output incidence application;(vi) is the initial marked;(vii) is the starting place,(viii) is the starting transition;(ix) is the ending transition.The set of places of the diagnoser is an extension of the set of places of general model. Thus, a place of is of the form where places belong to observable places, , and the label belongs to labels set . The labels for a specific place will be of the form . Therefore, a place can take a label either of normal or fault operation.
The functions essential for building the diagnoser are as follows.
Label Assignation function LA: . Given , , and , LA assigns the label over (transitions sequences) starting from and following the dynamics of , according toThis mean that PN diagnoser assigns to each place its respective label, depending on the transition fired, it will be (normal) if is fired in the sequence or it will be if it has been fired in a fault transition .
It should be pointed out that sink places appear in the integration model . If marking fell into a sink place, the PN would be blocked. In order to avoid this problem, a fault expanding (FE) function has to be created, taking advantage of the concurrence capabilities of the PN.
Consequently, the fault expanding function is defined according to the following expression: EF: , where is the normal operating branch and is the fault operating branch. For each set of failure , a new branch of failures in the PN will be created so as to fulfill the role of overseeing the failures individually. The diagnoser will have as many branches as the number of faults the system has. specifies the total number of branches of the diagnoser:The procedure for creation of the diagnoser is as follows.
Step 5.1. Define the initial place .
Step 5.2 (add a starting transition ). Connect to by using an arc.
Step 5.3 (add an ending transition ). Connect to by using an arc.
Step 5.4 (add the fault branch). For each fault of , a fault branch is built according to the fault expanding function EF. Each branch includes a normal branch parallel to a fault branch since each place can fire a fault transition or normal transition . When a is fired, the PND goes to a fault place and consequently LA function assigns a label. In order to continue the evolution of the PN, the sensors reading plus control transition must be fired .
Step 5.5 (add recovery transitions ). For each one of the fault places, its evolution can go in a way of normal conditions (step before) or sensor readings can change from fault state to normal state. Therefore, a recovery transition must be added to the branch and the mark of place must return to normal place priorly:Step 5.6 (connect and to the branches). An arc must be connected from to each initial place of the branch and, in the same way, from each initial place of the branch to . In this step, weighting arcs are used for avoiding conflicts in the PN; therefore, the weight of the arc must be equal to the number of faults plus one (corresponding to the normal branch of its respective subsystem).
Step 5.7 (temporal dynamics for diagnosing intermittent faults). For each fault place, a time variable is added. It is started when the mark arrives to the fault place and ends when the mark goes out because the recovery transitions are fired. This time stored by must be added to another when the branch falls in fault. , , where , with being the numbers of faults of the system. For each fault branch of the diagnoser, a temporal account place is added. When a fault transition is fired, a mark must be added to . This means that the numbers of faults are stored into this place . And the sum of the times registered by variable is stored in . Then, from each fault transition of the fault branch, an arc must be connected to temporal account place . The numbers of marks in the temporal account place is the sum of the marks registered in each fault place:Step 5.8 (reset of temporal dynamic). When the operator (i.e., the pilot) stops the diagnoser to replace or fix a component, the variables and temporal account place must be resetting. An arc must be added from to for this purpose. Another arc starting from but without place for arrival should be also added. The weight of this arc is equal to numbers of marks stores in . In this manner, is empty (no marks) and variable is set to zero.
PN diagnoser evaluates possible changes in each branch. The diagnoser emerges in normal or failure operation according to function. The diagnoser evaluates each fault separately and takes into account the failures that are caused by other failures in their transitions; therefore it is able to detect failures simultaneously, regardless of the order in which they occur.
4. Application to Helicopter
A radio controlled helicopter model Vario Benzin Trainer was chosen for this study. It relies on six servo-controllers for maneuvering. It has a length of 1.46 meters, a wingspan of 2 meters, and a weight of 7.3 Kg. The system (helicopter) is made up of three main subsystems: engine, main rotor (known as plate), and tail rotor. If any of them fails, the mission unavoidably has to be aborted, because the helicopter could crash with serious consequences rapidly.
The motor system is made up of a small gasoline engine and a servo that controls the throttle. It is responsible for generating the rotation of blades, both main rotor and tail rotor, in a mechanically settled proportional relationship. An electronic controller is typically used to maintain the speed of the rotor constant, independently of the attack angle of the blades. This angle is directly related to the drag that engine has to overcome.
The main rotor system is controlled by four servos. They allow modifying the lift and helicopter attitude (i.e., the roll and pitch angles) by varying the collective and cyclic pitch of the blades along their rotation. Thus, the collective pitch varies the lift and the cyclic one modifies the attitude.
The main component of the tail rotor system (antitorque) is a servo-controller, which receives commands from the pilot in order to modify the pitch angle of the tail rotor blades. The variation of this angle allows modifying the yaw angle of the helicopter (heading), mainly because it varies the antitorque that is required to compensate the one generated by the main rotor.
The full system relies on additional devices, such as power supply, navigation sensors (i.e., inertial systems, tail gyro, GPS, and electronic compass), controllers, communications (antennas and radios), and the ground control station.
The following lines are dedicated to describe the diagnoser implementation for the helicopter, according to the process described in previous sections. It is worth stressing that the no faults have been considered in the controller.
4.1. Classification in Subsystems
The helicopter is classified into three fundamental subsystems, as Figure 2 highlights, namely, the motor subsystem , the main rotor subsystem , and tail rotor subsystem .
4.2. Building the PN Model of the Components of Each Subsystem
Subsystem Motor . This subsystem has two components to model: controller and throttle servo . The monitored variables are fuel flow , engine temperature , engine speed (RPM), and current required by the throttle servo . The faults to diagnose are high temperature of the motor: Fault Warming Motor (FWM), lack of gasoline in the fuel tank: Fault Level Flow (FLF), and failure of servo stuck (FSS1). Therefore, the set of faults for motor subsystem is .
Figure 3 shows the PN model of the controller and servo. The PN model of the controller represents its cyclic work that is represented by the place . If the transition AS1 (activation servo 1) is activated, it will move to place (new location). When the transition AS2 is activated, the model will return to , representing a new location. In the same way, in the motor servo PN model, SNA1 represents servo normal operation. When transition AS1 is activated in synchrony with the controller, the model moves to SR1. Finally, when the transition AS2 is activated, the PN returns to SNA1. The rest of the branches represent faults of the subsystem, which are depicted by using dark places and transition, due to being unobservable.
Main Rotor Subsystem . As previously mentioned, there are two components to model in the plate subsystem, namely, plate servos and controller. The monitored variables are currents required by plate servos , roll and pith angles , and the vibrations in tail . The faults considered in the diagnoser are failure of servos stuck (FSS2, FSS3, FSS4, and FSS5) and mechanical imbalance of the chassis (FM). Therefore, the set of faults for main plate subsystem is as follows: .
Tail Rotor Subsystem . Two components have been considered in the model: tail servo and controller. The monitored variables are current required by tail servo and yaw angle . The fault to diagnose is a failure of servo stuck in the tail FSS6. Subsequently, the set of faults is defined as follows: .
4.3. Operation of Integration
Motor Subsystem. It consists in joining in a single model the two models of the previous step. The initial place is the union of the initial places of controller and servo (SNA1). integrates the places of the controller and servo (SRA1). The rest of the components of the PN models are kept. General model can be seen in Figure 4.
Main Rotor Subsystem. An initial place has been defined as the union of the initial places of controller and current action of the servos . Normal branch has been built. Fault places and transitions have been added for each fault of the set . integrates the places of the controller and required action of servo .
Tail Rotor Subsystem. As in previous cases, an initial place has been defined as the union of the initial places of controller and current action of the tail servo SNA6. After defining the normal branch, fault places and transitions have been added for each fault of the set . integrates the places of the controller and required action of servo SRA6.
4.4. Refining the General Model
4.4.1. Identify the Sensor for Each Subsystem according to the Sensors Required for Monitoring the Desired Variables
As previously mentioned, motor sensors’ set is made up of a fuel flow sensor , a temperature sensor , a speed sensor (encoder) RPM, and current servo of fuel . The set for the engine subsystem is therefore defined as follows: .
Following the same procedure, the main rotor sensor set is , which is made up of four current sensors for the servos of the plate , an inertial sensor that estimates the roll and pitch angles , and an accelerometer for measuring vibrations in the frame . Finally, tail rotor sensor comprises two sensors, a current sensor of the tail servo and magnetic compass for estimating the heading or yaw angle . Subsequently, set is
4.4.2. Build a Discrete Set of the Sensors Outputs
The combinations of sensor readings that have to be used as inputs of the sensors integration table are shown in Table 2.
According to previous definitions, motor subsystem has combinations. According to this formulation, main rotor subsystem has combinations (notice that the four sensors’ current of the plate is represented just by a single value: ). Tail rotor subsystem has therefore . Each reading is measurement in a discrete way and a threshold has been independent.
4.4.3. Define the Outputs of the Integration Table
Two outputs have been added for the motor subsystem, namely, and . Under normal operating conditions, the reading of fuel must be (i.e., the fuel in the tank is above the minimum threshold of 100 mL), the reading of the temperature must be (i.e., the engine temperature is below the threshold, 90°C), the value for the speed of the rotor must be RPM (i.e., the engine revolutions are over the threshold of 1200 rpm), and the readings from the servo current should be (i.e., the servos demand a value of current from 100 to 600 mA, which denotes normal functioning instead of blockage problems).
Main Rotor Subsystem. Two outputs have been included in the table for and . The readings of current sensors must be in the same range of that of the servos of the plate (different values happened if a more powerful servo would be used to control the tail). The motor subsystems and the readings of the position angles (roll and pitch) must be , (i.e., angle below 45°) and vibrations must be (i.e., vibrations below 2.5 g).
Tail Rotor Subsystem. Two outputs have been incorporated to the table for and . The readings of the current servo must be and the readings of the yaw angle must be . The outputs of the integration table are represented in Table 3.
4.4.4. Build the Sensors Integration Table
The sensor readings have to be cross-checked with their corresponding normal operations of the place for each subsystem. This allows determining whether sensors readings indicate a fault , a normal behavior or which combinations of sensors will provide with undetermined information to the diagnosis system .
The integration table of motor subsystem is showed in Table 4. This step requires a deep knowledge of the system.
4.4.5. Replace the Faults Transitions and Remove the Places Which Are Not Reachable
This step consists in replacing transitions unobservable (fault transitions) by sensors readings identified in the integration table. Motor subsystems: transition FLF is replaced by , the transition FWM is replaced by , and the transition FSS1 is replaced by . Main rotor subsystem: any fault of the stuck servo FSS is replaced by the readings of the and the mechanic fault FM is replaced by . The refined PN of the motor is shown in Figure 5. Tail rotor subsystem: fault of the servo stuck FSS6 is replaced by the readings of .
4.5. Building of the Diagnoser
Finally, the whole algorithm is integrated in one single PN, the FD helicopter. The PN that represents the diagnoser is mainly composed of three branches, corresponding to each subsystem: motor, main rotor, and tail rotor branches, as Figure 6 depicts. An initial place for starting and starting transition have been defined. The starting transition has to be activated manually by the operator in the ground control station so as to start the diagnoser. This moves a token for each of the branches of the helicopter subsystems. Likewise, the PN diagnoser has an ending transition , which allows the pilot to finish the diagnoser. The refined PN models of each subsystem are joined to the diagnoser with their places and transitions, respectively; then, based on the functions of fault expansion EF, the fault braches are added for each subsystem. Recovery transitions for each one of the fault places of each subsystem are added, connecting with the previous normal place. Consequently, each one of the transitions and places has to be connected by arcs, considering that their weights are equal to the numbers of faults plus one (normal branch). Finally, the temporal dynamic must be implemented adding the temporal account places , which is used for storing the time and number of fault for each variable of the system.
The diagnoser makes an online assessment of whole system and serves as the supervisor, indicating whether a branch falls into failure by means of the label assigned by function LA. If this happens, the other branches continue assessing the system, although, due to vulnerability of the helicopter, it should be landed for repairing immediately.
Sometimes, small faults happen during a flight for short periods of time. If no additional action is provided, the recovery transitions will hide these faults to the operator. The diagnoser relies on a display to show the operator this kind of information.
5. Analysis of Results
A series of field missions has been carried out in order to evaluate the PN diagnoser performance. Several lab tests were previously carried out in order to set up the thresholds for the variables that determine the normal operation of the helicopter. A summary of the variables threshold in each of the variables is shown in Table 5.
Diverse types of failures were intentionally introduced in the system during the field tests. Namely, different unbalances were introduced both in main and in tail rotor, aiming at increasing the vibrations of the helicopter frame. Moreover, several problems in the engine carburetor were also induced (e.g., the fuel flow was restricted to the engine).
A complete Data Acquisition System (DAQ) has been designed and built so as to implement the diagnoser. It is made up of two main components: the instrumentation onboard the helicopter and the components running into the ground control station (GCS). Since DAQ has been built for providing data and housing to the PND algorithm, it is responsible for sensing the field variables of the helicopter and sending the information to the GCS. This information is used to feed the fault diagnosis algorithm; which monitors the normal or fault operation of the aircraft by using the diagnoser Petri Net. The PND reports the frequency with which any device on the aircraft falls into alarm or fault.
A LabVIEW module that contains a graphical interface is responsible for acquiring, storing, and displaying all data from the UAV. The DAQ system works in parallel and independently of the control system; therefore it is fully autonomous and does not share any resources with the aircraft. This allows using the system with any other UAV. Moreover, since there is a redundancy in the information (i.e., position and attitude), a simple comparison method could be useful to detect malfunctioning of the navigation systems.
It is worth noting that the tests required to evaluate the performance of the diagnoser are extremely risky since they require forcing real failures during the flights. Furthermore, some difficulties are commonly found when working with real-time systems that have to be shipped on a vehicle with an extremely limited payload (e.g., data processing and storing limitations and consumption of computing elements). Additional problems arise when the information should be transmitted to ground station (noise, range of communications, and limited bandwidth). Therefore, it is essential to be as pragmatic as possible; that is, the maximum sampling time should be used and only the essential discrete variables monitored.
Another important limitation is the reaction time that the pilot requires to decide if a mission has to be aborted when a warning/fault is detected. The UAS operator could observe during this period of time how a monitored variable falls into alarm (warning) and, in some cases, into fault for short periods of time, and recover the normal condition.
A summary report corresponding to the results obtained during real flights (normal, vibrations in main and tail rotor, and wrong mix in fuel) is shown in Table 6. It reveals the number of times that each variable exceeded the threshold during the mission. For instance, in the normal conditions flight, the vibrations exceeded 93 times the value of the 2.5 g.
The behavior of the flight in normal conditions is showed for temperature, vibrations, and RPM variables in Figure 7. It can be concluded that those variables deserve special mention over the others. Each flight stage is referred to by numbers; for example, take off is denoted by stage 2. Although RPM and vibration thresholds exceeded intermittently their failure thresholds during the flight, no warning was activated. The RPM value highlights changes during takeoff and landing stages. Vibrations during idle stage (motor started but UAV on the ground) exceeded the thresholds of fault; nevertheless they recover their normal range during the flight.
The helicopter safety strongly depends on its suitable mechanical performance, and the expertise of the pilot supported by this diagnoser is the best indicator to decide whether a mission should be aborted or not.
6. Conclusions
This research addresses the fault diagnosis applied to an UAS by using Petri Nets. A methodological process for creating the model and the diagnoser has been presented. The process has been split into subsystems. This allows assessing the failures in an independent way.
As result highlights, the created Petri Net diagnoser is able to detect not only permanent but also intermittent failures, providing the pilot with a set of health monitoring alarms.
The main advantages of the proposed method are the ability to be implemented in complex processes, the flexibility to make changes (i.e., including additional devices to the diagnoser), the reduction of the combinational explosion, and a systematic construction.
An application on a real system (a radio controlled helicopter) has been presented as demonstrator. Since the helicopter is a quite vulnerable platform, it requires a robust fault diagnosis method. Although real experiments pose a high risk, a valuable amount of flights have been carried out in order to assess the performance of the algorithm and methodology. Moreover, the use of a commonly used tool such as LabVIEW allows providing the diagnoser with additional features that turn out to be of great importance for preventive maintenance.
This work opens the door to some fields of development in the area of the FD to be considered in further work, such as to perform spectral analysis of vibration aiming at detecting more types of mechanical damages. Moreover it could be applied to generate mathematical models of normal and fault operation of the aircraft.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This work has been supported by the project RoboCity2030-III-CM (Robótica Aplicada a la Mejora de la Calidad de Vida de los Ciudadanos; Fase III; S2013/MIT-2748), funded by the I+D program at Comunidad de Madrid and cofunded by Fondos Estructurales of European Union and by the project Protección Robotizada de Infraestructuras Críticas, DPI2014-56985-R, by Ministerio de Economía y Competitividad of Spain.