UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Real-time performance monitoring and fault diagnosis of hydraulic manipulators Sun, Xiaodan 1995

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1995-0239.pdf [ 5.09MB ]
Metadata
JSON: 831-1.0064865.json
JSON-LD: 831-1.0064865-ld.json
RDF/XML (Pretty): 831-1.0064865-rdf.xml
RDF/JSON: 831-1.0064865-rdf.json
Turtle: 831-1.0064865-turtle.txt
N-Triples: 831-1.0064865-rdf-ntriples.txt
Original Record: 831-1.0064865-source.json
Full Text
831-1.0064865-fulltext.txt
Citation
831-1.0064865.ris

Full Text

REAL-TIME PERFORMANCE MONITORING AND FAULT DIAGNOSIS OF HYDRAULIC MANIPULATORS  by  XIAODAN SUN  B. A. Sc. Beijing University of Aeronautics and Astronautics, 1985 M . A. Sc. Beijing University of Aeronautics and Astronautics, 1988  A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES DEPARTMENT OF ELECTRICAL ENGINEERING  We accept this thesis as conforming to the required standard  THE UNIVERSITY OF BRITISH COLUMBIA March 1995 © Xiaodan Sun, 1995  In presenting  this thesis in partial fulfilment of the requirements for an advanced  degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may department or by  his or her  representatives.  be granted by the head of  It is understood that copying or  publication of this thesis for financial gain shall not be allowed without my permission.  Department The University of British Columbia Vancouver, Canada  DE-6 (2/88)  my  written  Abstract In this thesis, a revised hydraulic model of a heavy-duty Caterpillar 215B excavator is presented. The functional module based dynamic and hydraulic simulator is rewritten in C and tested. The simulator, which is the fundamental part of the model-based fault diagnostic algorithm for real-time performance monitoring and fault diagnosis, is validated by means of using real system data., Fault diagnosis algorithms are reviewed in both the control and artificial intelligence communities. Based on the analysis of the system's working mechanism, system structure and behavior, a model-based Incremental Fault Diagnostic Algorithm — IFDA is presented which has the capability of multiple fault detection for both sensor and component faults. The IFDA's task is to monitor and diagnose active machine component faults, sensor faults or other electronics faults. Another diagnostic algorithm for the idle machine is proposed to detect electronics failures based on the contribution of hydraulic component deadband behavior. The monitoring and diagnostic system structure and software/hardware configuration are proposed, and the main scheme has been i  implemented. Experimental data on steady state single fault and multiple fault tests have demonstrated the algorithm.  Contents Abstract  ii  List of Tables  v  List of Figures  vi  Acknowledgment 1  -  viii  Introduction  1  1.1  Motivation and General Objective  1  1.2  Approach and Framework  1  Hydraulic and Dynamic Modelling  5  2.1  Introduction to the Hydraulic Controlled Caterpillar Manipulator  5  2.2  Fault Behavior Analysis  7  2.3  The Hydraulic Model  10  2.4  The Dynamic Model  16  2.5  Modification to the Hydraulic Model  19  Simulation and Implementation  24  3.1  Implementation Algorithm  24  3.2  Simulator Modification and Verification  26  Diagnostic Algorithm  36  4.1  Diagnostic Algorithm Review  36  4.2  Proposed Incremental Fault Diagnostic Algorithm ( I F D A )  43  4.3  Electronics Diagnosis  53  4.4  Active Machine Diagnosis  56  System Design and Evaluation  58  Diagnostic System Configuration and Implementation  58  2  3  4  5 5.1  iii  5.2  Software Module Interface and Interrelationship  5.3  Algorithm Test and Evaluation  6  Discussion and Conclusion 6.1  Discussion and Conclusion  6.2  Recommendation for Further Work  Appendix A -  Diagnostic System Graphical User Interface  Bibliography  iv  L i s t of T a b l e s Table 2.1  Possible Configurations for The Hydraulic Main Circuit  14  Table 5.1  True Voltage Channel Fault Situation  75  Table 5.2  Diagnostic Result from the Voltage Channel Fault Situation  75  Table 5.3  True Multiple Sensor Fault Situation  76  Table 5.4  Diagnostic Result from the Multiple Sensor Fault Situation  77  Table 5.5  True Multiple Sensor Increased Fault Situation  79  Table 5.6  Diagnostic Result from the Multiple Sensor Fault Situation  80  L i s t of F i g u r e s Figure 1.1  Brief Description of Our Model-based Fault Diagnostics  3  Figure 2.1  The Structure of the Caterpillar 215B and the Coordinates  5  Figure 2.2  The Interrelationship of the Control System Components  8  Figure 2.3  Old System Working Mechanism  11  Figure 2.4  Main Hydraulic Circuit  13  Figure 2.5  New System Working Mechanism  19  Figure 2.6  Pilot Valve Model  21  Figure 2.7  Main Valve Spool Model  22  Figure 3.1  The Secant Method  25  Figure 3.2  Comparison of Old Simulator with the Real Machine for Link "Boom"  27  Figure 3.3  Modularized Simulator Performance (same)  29  Figure 3.4  New Simulator Result: Positive Input to "Boom"  30  Figure 3.5  Simulation and System Response for Negative Input to "Boom"  31  Figure 3.6  Simulation and System Response of Joint "Stick"  33  Figure 3.7  Simulation and System Response of Joint "Bucket"  34  Figure 3.8  Deadband Behavior of Hydraulic System with 1 Volt Input to " Boom"  35  Figure 4.1  Stages of Model-Based Failure Detection and Isolation  37  Figure 4.2  The Diagnostic Algorithm Architecture of The Diagnostic Management System  46  Figure 4.3  System Structure Model .  49  Figure 4.4  Interaction among Boards and Sensors  56  Figure 5.1  Software and Hardware Configuration of the Real-time Diagnostic System  61  Figure 5.2  Offline Diagnostic System Configuration  63  Figure 5.3  Module Interface and Interrelationship  64  Figure 5.4  Active Machine Diagnosis Program Flow Diagram  67  Figure 5.5  Idle Machine Diagnostic Program Flow Diagram  68  vi  Figure 5.6  Algorithm for Active Machine Diagnosis  70  Figure 5.7  Algorithm for Idle Machine Diagnosis  72  Figure 5.8  Quantitative Range Checking Algorithm  73  Figure 5.9  Incremental Model Builder Algorithm  73  Figure 5.10  Single Sensor Fault Diagnosis  74  Figure 5.11  Multiple Sensor Fault Simulation and Diagnosis  79  vii  Acknowledgment I am indebted to my supervisors Dr. Peter Lawrence and Dr. Chris M a for their support and continuous guidance. Without their constant encouragement and valuable suggestions, the completion of this thesis would not be possible. I would like to acknowledge sincerely the assistance provided by research engineers Dan Chan and Alison Taylor. Without their help, I would not be able to build up the model, implement the simulator, get the data, and do the test.  viii  i  1  Introduction  1 Motivation and General Objective The heavy duty machine which we describe here, a Caterpillar 215B, which is a hydraulically-controlled 4 link manipulator whose structure is shown as Figure 2.1, is used in construction, mining and forestry industries. The working environment for this machine is potentially hazardous. The machine is exposed to faults, such as mechanical/hydraulic part deterioration, hydraulic leaks, and electronic failures, quite often because of the rough working environment. Those failures may cause the machine to be shut down, or move suddenly or sluggishly. Those unexpected movements are dangerous to operators and the material held by the machine. To ensure the safety of the operator and people working around the machine, to reduce the cost of repairing the machine ( sometimes long transportation is needed ), and to cut down the maintenance time or machine non-productive time, it is highly desirable to detect and locate the faulty components in the system easily and prevent further damage to the machine. Any complete or partial facilities or computer tools to help to decrease the maintenance time and cost caused by the failure, predict the machine behavior in order to avoid fatal hazard, and ensure a safe working environment for the machine operator is really needed. The objective of my research is to propose a model-based performance monitoring and fault diagnostic algorithm based on the machine behavior and working mechanism. A model-based fault diagnosis algorithm, which we call the Incremental Fault Diagnostic Algorithm — IFDA, which emulates the normal machine behavior and fault behavior in the simulator is presented in this thesis. The basic idea is that when a fault happens and is detected in the real system, it is injected into the simulator. Thus when new faults happen later, the simulator can still be used for detection. The related work including machine modelling, simulation, diagnosis system design and implementation as well as the tests is described in the following chapters.  2 Approach and Framework In this thesis we propose a model-based real-time machine performance monitoring and diagnosis algorithm for hydraulic heavy duty machines, and validate the algorithm by testing it on offline data.  Chapter 1. Introduction  2  Our machine consists of multiple hydraulic parts and electronic components such as sensors, computer D/A and A/D boards. Each component has its own behavior based on its model and its own fault mode. Generally, no matter what kind of failure happens in the component or sensor, it will definitely affect the system output or some sensor readings. If a model can describe the system current states, any discrepancy between the model prediction and the system observation can be used to detect the fault location. This is the basic idea of model based fault diagnosis. The dynamic and hydraulic model and simulator which was modelled and simulated by Dr. Nariman Sepehri ( hydraulics ) and Dr. Darrell Wong ( dynamics ) is not able to achieve the purpose of model-based fault diagnosis since the model is not matched with the real machine's behavior. System time delay, transient response, sampling rate, etc., are not accurately rendered in the simulator. Based on their work, a new separate 5-level component model and system structure is incorporated into the new simulator which can better describe the machine behavior and meet the diagnostic requirements. The pilot valve model and the main valve spool displacement have been separated from the previous model, and the main valve orifices and pumps have been modified based on the real machine's data. The simulation result is also tested and compared to the real machine data. Fault diagnosis is under research in both the control and artificial intelligence communities. Model-based fault diagnosis is widely expanded and takes the leading role in the diagnostics area. In the control community, fault detection and isolation techniques generally rely on a precise mathematical model of the process and on pre-enumerated symptom-fault patterns known as fault signatures, central approaches like observer design, Kalman filter design, continuous parameter identification, statistical test, and pattern recognition are utilized in fault detection and isolation algorithms. In the artificial intelligence community, model-based fault diagnosis relies on models of structure and behavior.  Given the discrepancy between the observation and the model prediction, fault candidates are  identified using the structural model by following a dependency chain back from the discrepancy point to the input that would contribute to that prediction. The diagnostic algorithm we have proposed for the manipulator is much like the algorithms in the artificial  Chapter 1.  Introduction  3  intelligence area. We use a component-based simulation to predict the system behavior, in which the simulator describes the system structure and functional behavior. The algorithm generates the sensor or component fault hypotheses based on a discrepancy between the model predictions and real machine sensor readings which has not been explained in the current system status model. The simulation which is called an incremental simulator always mimics the current state of the real machine. When the hypothesis is confirmed, the corresponding fault is fixed in the model and injected into the incremental simulator, then the model and simulator are used for diagnosing further multiple faults. Electronic sensor and hydraulic component problems are treated simultaneously in our diagnostic algorithm. The basic structure of this diagnostic algorithm is briefly described in Figure 1.1.  Simulation!I*  Current Model  Hypothesis approvement  Input  j Real Machine  -J Hypothesis I Generator  Figure 1.1 Brief Description of Our Model-based Fault Diagnostics  In Figure 1.1, the real machine and the simulator are controlled by the same input signal, and run simultaneously. When the system detects the discrepancy between the simulator and the real machine, it will check the system current status model to see if the discrepancy has been tracked or not.  A tracked  discrepancy means that the discrepancy has been explained by a faulty component which has been detected before. For example, a sensor fault will always cause the discrepancy between the reading and the simulator prediction. After we detect a fault and inject it into the model, that particular discrepancy monitored later is called a tracked discrepancy. The simulator can keep track of the real machine current status by injecting the fault that happened previously in the machine into the model. For those untracked discrepancies the diagnostic system will generate fault hypotheses, inject the fault into the new model, use the new model in the incremental simulator, check the discrepancy to prove or disprove the hypothesis.  Chapter 1.  Introduction  4  To simplify the electronics fault diagnosis and the complex time-consuming simulation, based on the machine behavior analysis, we propose an idle machine diagnosis which is used to detect sensor and other electronics problems in addition to the model-based active machine diagnosis. The active machine diagnosis is used to diagnose the mechanical and hydraulic components. The idle machine diagnostics is to test the electronics like the computer boards and all machine sensors by using a special software controller for the real machine based on the machine deadband characteristics. Range checking and partial model-based diagnosis are used in this case. The monitoring and diagnostic result would be dynamically displayed by the user interface running under a host machine which communicates with the diagnostic system through network using distributed communication techniques. The real-time performance monitoring and fault diagnosis system architecture is proposed in this thesis. The main scheme has been implemented. A corresponding offline U N I X version is also designed and implemented to do offline test. Some artificial failure situations of the real machine are generated and tested under the U N I X environment, and the correctness of our diagnostic algorithm is proved.  5,  2  Hydraulic and Dynamic Modelling  1 Introduction to the Hydraulic Controlled Caterpillar Manipulator The Heavy Duty Machine  Figure 2.1 The Structure of the Caterpillar 215B and the Coordinates [25]  Figure 2.1 shows the mechanical structure of the heavy duty machine. The Caterpillar 215B excavator is a 4 D O F manipulator with 4 links which are called "Cabin" , "Boom", "Stick", and "Bucket". Each degree of  Chapter .2.  Hydraulic and Dynamic Modelling  6  freedom controls one link's rotation. The boom and stick rotate about a horizontal axes and provide the ability to lift the bucket ( end-effector ). The end-effector is used to dig or carry the load and also rotates about a horizontal axis. The upper structure of the machine rotates based on the cabin motion controlled by a motor through a gear train. The other links are operated through hydraulic cylinders. The hydraulic power and flow come from the hydraulic pumps ( pump 1 for boom and bucket, pump 2 for cabin and stick ) to act on each link through motor or cylinder via the main valve orifices which are controlled by the pilot pressure, e.g, the motor and cylinders are activated by means of hydraulic pressure and flow modulated by the main valves, and the modulation of the oil flow in the main valves is controlled by the pilot pressure which is given by the pilot control valve. The movement of the pilot valve spool is controlled by the voltage output of the machine controller on the board through the amplifier. So the pilot valve, the main valve, the cylinder or motor come out a one by one chain. The control signal goes through this chain to activate each link.  Machine Configuration The principal components of the machine are shown in Appendix A . The hydraulic controlled mechanical parts of the machine consists of 4 pilot pressure valves, 6 main valves, one for each link, and two for boom crossover and stick crossover, 1 motor and 3 cylinders, 2 pumps to provide the main valve required power, and a pump to supply energy to the pilot valves. A n electronic computer system controller is used to perform the control and monitoring tasks. This machine control system consists of following electronic components : 1.  a system controller card ( T800 ) for the overall control and monitoring as well as the I/O processing  2.  a 12 bit 32 channel A / D card to sample the joysticks and pass all the sensor signals to the computer  3.  a 12 bit 4 channel D / A card to send voltages to the pilot valves  4.  a 12 bit 4 channel R/D ( resolver to digital ) card to pass the joint position information to the processor  5.  a steady 24 V power supplier for the system. To achieve the control and monitor target multiple sensors and resolvers are installed in the machine: the  power sensor to monitor the power situation, 8 pressure transducers to measure each line pressures of motor and  Chapter 2.  Hydraulic and Dynamic Modelling  1  both head and rod sides of the cylinders, another 4 pressure transducers to test the values of the pilot pressures produced by the servovalves, another 2 pressure transducers to read the hydraulic power of the two pumps, 6 spool displacement sensors to read the main valve spool positions, 4 angle resolvers to read the joint positions. A l l the components listed above consist of the system elements needed to be monitored and diagnosed in order to ensure a safety and accurate working environment.  Machine Control Mechanism Two joysticks are provided to control the movement of the machine. The forward or backward movement of the left joystick controls the stick link, left or right side movement controls the rotation of the cabin. The forward or backward, and the side movements of the right joystick control the boom and bucket rotations respectively. The computerised control system components are shown in Figure 2.2. Left and right joysticks are used to give the voltage input to the on-board controller by means of converting to the end-effector ( bucket) Cartesian position which can be treated as the trajectory of the manipulator. The Cartesian position is converted to the desired joint angle for each link by the controller by means of Inverse Kinematics. Because of the limitation of the pump pressure and the cylinder length, safety check and joint angle limitation check are performed by the controller. Each link can be controlled individually. The control output voltage value of the PD controller with the optional load and deadbands compensations are calculated based on the differences of desired joint angle, velocity from the actual ones for each link. The joystick voltage signals are digitized by an A/D converter, and the control signals go through a D/A converter to the pilot valves.  2 Fault Behavior Analysis For this computer controlled hydraulic system, faults or incorrect behavior can be caused by mechanical faults, electrical faults, the combination of hydraulic and electrical problems, hydraulic problems, and operator error. The operator error is not considered in our research. A fault can be defined as any kind of malfunction in the system or components with its location, cause, symptom and effect. The difficulties of troubleshooting for this machine are mainly caused by:  Chapter 2.  Hydraulic and Dynamic Modelling  Figure 2.2 The Interrelationship of the Control System Components  Chapter 2.  Hydraulic and Dynamic Modelling  9  1.  The interaction of components and subsystems because of fluid behavior and mechanical connection  2.  The environment effect on component parameters or hydraulic behaviors  3.  Deterioration of machine components, such as partial or total loss of power, surface contamination  4.  Discrepancies between the measured and true values of machine variables, e.g. sensor biases  5.  Disturbances acting on the machine, such as noise signals which are independent of measured inputs, etc.  The hydraulic system has its own problems such as dust or air in the oil, loose connections etc., which are different from other electrical or mechanical problems.  Possible Hydraulic Faults  A fault is usually observed as a symptom caused by a specific reason. Most  of the hydraulic faults reflect five types of symptoms such as 1) flow, 2) pressure, 3) heat, 4) noise and vibration, 5) leakage. The reason for each component fault is different from another, for example, the reason which causes the pump to have no pressure or abnormal pressure reading lies in several reasons, such as improper assembly, broken internal parts, fluid supply obstructed, or pump turning dry. The common failure type of hydraulic system such as leakage, cavitation, parts of the component deterioration, seals failure, may exist in any kind of hydraulic parts. A problem description can be given as a symptom based statement such as the system is overheated or the pressure is too high or a leakage happens in the system, or a component based statement like the cylinder is not working well. We focus on component based problem description in order to detect the fault location. The component based problem statements can also be easily described from the component sensor reading. For example, a pump does not rotate, or has no pressure or a low pressure, or has no flow or low flow. The reason causing those symptoms may lie in internal parts seized or broken, excessive internal wear, no load resistance, inlet or outlet restrictions, or vanes stuck in slots.  Possible Electronic Faults  We classify the electrical problems of our machine as computer, A / D , D / A ,  R/D ( resolver to digital ) problems or sensor problems, as well as electrical power failure. Based on the structure of computer boards, faulty readings may be caused by a single channel failure or multiple channel failures. Sensor problems such as.bias, dead zones, scale factor errors, may cause no reading or bias reading. Disconnection, short circuit may be the common reason for a no reading value sensor rather than a sensor failure.  Chapter 2.  Hydraulic and Dynamic Modelling  10  The above problems are often caused by components or part of the system fault and can be represented by an abnormal value or change of either component or some system parameters which causes the undesired output of the system. Our purpose is focused on monitoring system behavior and locating the faulty component through the comparison of the real machine reading with the simulator prediction when the system is misbehaving. The further fault reason is not considered here.  3 The Hydraulic Model In the control community most of the diagnostic algorithms use either parameter distributions or system input output relationships to describe each fault mode. The fault hypothesis is proved by matching the run-time problem with one of the predefined fault modes. The fatal drawback is that the completeness and accuracy of those predefined modes cannot be achieved. A n alternative approach is to use a model to predict the normal behavior of the system, diagnose the real system based on the discrepancy between the model and the machine whenever any kind of fault occurs. The excavator is modeled as a large system consisting of two separate elements — a complex hydraulic actuation system which we will give the model here, and a rigid multi-body mechanism which.we will describe the dynamics in the next section. Our machine consists of standard components such as valves, hoses, pumps, motor and cylinders. The principal characteristics of these components have been generally modelled.  The difficulties lie in the  nonlinearity in the manipulator dynamics and the interactions among the components especially in the main valve crossovers. A system approach to analyze this complex hydraulic system is basically the aggregation of component models together with a set of constraints. The hydraulic model has been built up by Dr. Sepehri.  System Working Mechanism  This heavy duty machine takes pilot voltage as the input and gives out  the joint position and velocity as outputs. The mechanism is composed by hydraulics and robotic dynamics. In Sepehri [25], the working mechanism is modeled into 4 levels shown as Figure 2.3 Old System Working Mechanism  Chapter  2.  Hydraulic  and Dynamic  11  Modelling  volts  servo & pilot system 1  o  — I  <  ZD  \—  flow  O  <  y  main valves & pumps 2 connecting hoses 3  UJ DC ZD r-  o  ZD  DC h-  velocity  spool displacement  pressure  pressure  actuators & links 4 motion  Figure 2.3 Old System Working Mechanism [25]  In this working mechanism, the pilot valve component is combined with the main valve spool, and is modelled into a single level which takes the pilot voltage into main valve spool displacement. This model could not separate the pilot valve from the main valve. So the drawback of this model is that it could not use the pilot pressure sensor reading for the sensor fault and pilot valve component fault diagnosis. At the second level, the movement of the spool gives the valve orifices from pump to cylinder, from cylinder to tank, and from pump to tank for each main valve, and provides the flow to the hoses and tanks. The main valve also takes the pressure from the hose to act on the pumps through the internal main valve pressure. A t the third level, the connecting hoses pass the flow from the main valve to the cylinder and takes the pressure caused by the cylinder motion to the main valves. At the fourth level, the hydraulic cylinder or motor combines the link dynamics, provides the power required by the movement of each link. This machine is separated as 4 subsystems which are Cabin, Boom, Stick, and Bucket subsystems. Each subsystem has the same working mechanism as described in Figure 2.3.  Chapter 2.  Level 1  Hydraulic and Dynamic Modelling  12  The spool displacement Xi(i) is modelled as a first-order differential equation given a voltage v,  in Sepehri [25]  Xi(t) = Xi 1 - e "^ -  (2.1) Xi = fi{vi(t)} where T\ is the time constant. / , is a nonlinear function.  Level 2  In Sepehri [25], the main hydraulic circuit is shown as Figure 2.4. The output flow from the axial  piston pumps is used to operate the hydraulic cylinders and the cabin rotation motor. This circuit performs as a load-sensing torque-limited circuit. The highest load is sensed from the main valve internal pressure via the orifice and line pressure, and the pump flow is changed to meet the maximum power available for the engine. The oil from pumpl goes through boom, bucket and stick crossover valves to the cylinders or to the tank, while the oil from pump 2 to cabin, stick and boom crossover valves to the cylinder, or the cabin motor, then to the tank. When the cabin or boom valve is moving, the stick or bucket has to operate at a slower rate because of low power. The motion of the boom and the stick are coupled by the crossover valves. This causes a faster movement of one when the other is at low, speed. But this structure also costs the complexity of the hydraulic modelling and dependency of the component functions. In Sepehri [25], either the "pressure-based modelling" method or the "flow-based modelling" technique can be used to model this level with a state-space representation in time domain. In thefirstone, any input to each link subsystem is related to both an external input and an output from other subsystems. The state variables of the hydraulic circuit could be divided into two groups: fast-response states involving a restriction linking two rigid pipes in the main valve system and slow-response states lying in the flexible hoses connecting the main valves to the actuators which have a considerable effect on the dynamics and the vibrational behavior of the structure. The existence of fast-response states results in the loss of computational efficiency. Using integration routines specifically developed for stiff system may be useful in terms of computational efficiency, but are subject to a failure at a discontinuous point. An explicit integration method can be used to handle this problem but hard to handle stiff systems which require a small integration time interval. This is the critical part in our real time simulator in order to achieve the diagnostic target. In the "flow-based modelling", fluid-flow  Chapter 2. Hydraulic and Dynamic Modelling  13  rate, rather than the conventional fluid pressure is chosen as a state-space variable. This method is good for less complex systems with less links. The computation efficiency decreases when the system becomes more complex, this makes this method not suitable for our system with crossovers, torque-limited pump control, and pilot system dynamics.  ( Branch 1) Pump 1  i = input e = exit m - main c ~ cross-over  ( Branch 2) Pump 2  bo(BO) = b o o m bu(BU) = bucket st(ST) = stick sw(SW) = s w i n g  Figure 2.4 Main Hydraulic Circuit [25]  Flow-based modelling technique is used in our system. All fast-response states are localized in the main valve hydraulics ( level 2 ). Steady-state equations are formed to give the subsystem model. All the fast-  Chapter 2. Hydraulic and Dynamic Modelling  14  response elements are confined into this subsystem. Due to the low compliance in the connections of the main valve system , steady-state equations could simulate the dynamics of this level accurately. These equations can be derived using fluid flow continuity and orifice flow equations. Each branch flow value should keep constant no matter if it goes to a link or to the tank. There is interconnection between the branches which allows the flow crossover action. The flow goes across any valve including the crossover valve in the main valves can be expressed as:  1  Q  kayjp  0ut  - p  (2.2)  in  where Q reference the flow rate goes through the orifice, and the a represents the area of either the orifice from the main valve to the cylinder, from the cylinder to the tank or from the main valve to the tank which are converted from the spool displacement of main valve and crossover valve, and P , out  Pin refers to the pressure  at the output and input sides of the orifice. The crossover of boom and stick acts in this subsystem. The internal pressure values of the main valves ( Pi, Pn, P13, and P2, P22, P23 determine the check valves behavior. Depending on which one of the four check valves in the crossover lines are functioning, nine different hydraulic configurations can be achieved, which are tabulated in Table 2.1 from Sepehri [25].  Table 2.1 Possible Configurations for The Hydraulic Main Circuit [25]  Boom Main & Cross-over P?2>Pl3  Pi = P23 case (e)  '  . No cross-over  Boom Cross-over only  Pi2 > Pl3  P22 <  Pl>P 3  Pi <P 3  case (a)  case (b)  2  P13  2  Chapter 2. Hydraulic and Dynamic Modelling  Table 2.1 (Continued)  15  Possible Configurations for The Hydraulic Main Circuit  Stick Cross-over only P22  < Pn  Pi =  P22  < P,3  Pi > P 3  P23  2  P22 < Pl3  Pi < P23  case (c) Stick Main & Cross-over  P22 =  P,3  Pi = P23  P22 = Pl3  P22 = Pl3  Pi >P 3  Pi < P23  2  case (d)  It can be shown that four out of nine configurations are not physically possible. Therefore, the solution to the hydraulic circuit is within five alternatives as shown in Table 2.1. Case (a) is when the crossover valves are not functioning. Each main line is capable of providing the amount of flow needed to the corresponding actuator. The condition to be met to accept this as a solution is given in terms of the pressure distribution along the lines. Cases (b) and (c) can still be studied separately. Case (d) shows the stick in/out motion which speeds up through getting more fluid from the other branch. Case (e) shows the resulting circuit where boom-up motion is speeded up. Either boom crossover or stick crossover can function at a time, but never both. And the crossover check valves are not required to be modelled.  Level 3  The connecting hoses have a high value of fluid compliance which can affect the line pressure. The  hoses connect the main valves and the motor or cylinders, pass the control power to each link and the load or force to the main valve, adjust the system behavior. The differential pressures in the hoses are proportional to the valve flows Q, the link velocity, and the hose hydraulic compliance 4- , and can be described as follows:  Pi=  (Qin-Qi)f3/Vi (2.3)  Po=  (Qo-Qout)p/Vo  Chapter 2.  16  Hydraulic and Dynamic Modelling  where the Pi, P are the line pressures of the connecting hose, Qi , Q 0  n  out  are the fluid into the hose from the  main valve or out of hose to the tank, Vi, V are the fluid volume trapped on each side of the actuator piston, 0  Qi, Q  0  Level  are the fluid into and out from each side of the actuator.  4  This level combines the cylinder hydraulics in Sepehri [25] shown as following, and the dynamics  in Wong [27] described in next section. The joint angle velocity is converted into cylinder piston speed based on the joint geometry. The flows going into and out of the cylinder are calculated based on the piston movement and the volume values at the rod and head sides. The actuator torque given by the motor ( r  m  ) or cylinder ( r ) acting to the link is given as: c  r - (Pi ~ P )D n m  0  m  (2.4)  r = (PiAi - P A )x/6 c  Where the Pi, P  0  0  0  are the line pressures of the connecting hose, A,-, A  0  are either side of area of the  cylinder piston, x, 9 are the linear velocity of the piston and the angular velocity of the each link, D  m  is a  motor constant. The dynamic equation of the structure is given in next section.  4 The Dynamic Model Dynamics The multibody dynamics of this machine is represented as a four link mechanism forming a single chain, with each link having one rotary degree of freedom. The dynamics of the multibody system is determined by the kinematics, which describes the topology, and the kinetics, which describes the forces. Kinematics is focused on the geometric aspects of motion, excluding the forces involved. Link length and rotational or translational displacement and velocities are calculated to obtain the end-effector ( or some link in between ) position or velocity in Cartesian coordinates ( forward kinematics ), or conversely, to determine the joint displacements that produce the endpoint position ( inverse kinematics which is used in our controller ). Kinetics is concerned with describing the balance of forces that  Chapter 2. Hydraulic and Dynamic Modelling  17  influence body motion, such as gravity, actuator moments, and Coriolis forces due to the effects of angular velocity. Together, the kinematics and kinetics completely describe dynamic behavior through the differential equations of motion, in terms of joint variables, structural parameters, and the internal and external forces appjied to the joints. The forward kinematics model can be deduced by the Denavit-Hartenberg frame convention in the form of a homogeneous transformation for each link associated with a coordinate and an origin in the Cartesian space. Inverse kinematics is used in the controller to control each joint link angle and velocity to achieve the target position of the end-effector. Two main approaches of kinetics can be found in literature: Lagrangian , and Newton-Euler. Lagrangian is used to model the robotic dynamics in our system.  Lagrangian In our system, the joint angle and velocity of the current joint with respect to the previous joint is chosen as the state variable to characterize the position and orientation of each joint. A l l the joint variables come out a set of independent variables known as the set of generalized coordinates. Assuming our generalized coordinates are 0 i , & i ( measured relative to the previous link ). The Lagrangian is defined as the difference between the kinetic  and potential (E ) energy of the system. p  L(9,6y=E (e,6)-E {0) k  (2.5)  p  The equation of motion are defined as:  ' M \ _ d L  =  i  =  1  |  . . .  4  Where F, is the force or torque in the direction of the f?, coordinate. The  Ek(i)  -  ^miXi Xi T  + ^wf  JiWi  (  2  .  6  )  of a link i is given by  (2.7)  Chapter 2. Hydraulic and Dynamic Modelling  18  Ji is the link inertia tensor, and ii and w, are the 3 x 1 translational an angular velocity vectors of the centre of gravity of the ith body, measured relative to an inertial frame of reference. The velocities Xi and  are  the Cartesian velocity coordinates of the ith body. The system vector [ x w ] forms a nonminimum set of coordinates. Transformations from Cartesian coordinates to 9 or 8 are required in our system because w ( a 3x1 vector ) is not a minimum representation and is generally not a measurable variable since it is a function of up to three Euler-type angular rotation rates. After the transformation, the system kinetic energy  4  (2.8) i=i  can be written as  -e Me  E =  l  k  T  (2.9) i=l where M is the n x n inertia tensor for the complete manipulator system The potential energy for the system is due to gravity g, and is 4  E  = Y, i9 Xi m  p  (2-10)  T  i=l When the Lagrangian is differentiated, the equation of motion for the ith link is  4  4  4  4  Y^Mijtij+Y<J2 i/k9)d\+Y, j9 B^ j=l j=lk=l j=l h  where Fi is the actuator torque, and B^ differentiation of E  p  m  = Fi  T  is the j'th column of the  i = l,..A  (2.11)  matrix appearing as a result of the  with respect to d6i. hijk represents the terms that occur as a result of differentiating  M with respect to 86. The first term of. equation ( 2.11 ) represents the moment due to inertia, the second term represents the Coriolis and centrifugal moments, and the third term represents the moment due to gravity vector g. The dynamic equation can be given as  M{6)6 = F -h(e,6^  -G{B ) T  (2.12)  Chapter 2. Hydraulic and Dynamic Modelling  19  The benefit of working with the Lagrangian approach is that the forces of constraint between hinges do not have to be considered. We use this algorithm in our simulator.  5 Modification to the Hydraulic Model Since the model given in Sepehri [25] is unable to satisfy the diagnosis requirements we modify the system model based on component functionality. The new system working mechanism is shown in Figure 2.5 in which the model is divided into 5 levels. The main difference from the old working mechanism is the separation of the pilot valve. Those 5 levels come out a component working behavior chain for each link.  PValves  level 3  level 2  level 1  p — » •  sdis  MSpool  — •  a MOrifice — • > MainHY pf  level 4  •  PP  CylHY  level 5  Dynamics  e, e, e  Pumps Figure 2.5 New System Working Mechanism  At the first level, the voltage signal coming out from the on-board controller acts on the pilot valve. At the second level, the main valve takes the pilot pressure as its input and invokes the spool displacement as its output, the movement of the spool produces the valve orifices from the pump to cylinder, from cylinder to tank, and from pump to tank for each main valve. At the third level, the main valve's hydraulics takes the line pressures, valve orifices, and the pump flows as its inputs and gives out the line flows acting on the cylinder or motor, and pressure to the pump. At the fourth level, the hydraulic cylinder provides power of movement on each link and feedbacks the line pressure to the main valve. At the fifth level, each link takes the torque from the cylinder or motor and feedbacks the link movement results to the cylinder or motor. The MainHY, C y l H Y , Dynamics, Pumps interact on each other, result in an acting loop. The basic mechanism is that the changes of  Chapter 2. Hydraulic and Dynamic Modelling  20  the line pressures and link speeds are adjusted by the pump flows. While the pump flows are controlled by the pump pressures which are affected by the orifices and the link load which is fed back to the main valves by the cylinder. Each link works as Figure 2.5 shows. A l l the four links interact in the mainHY ( e.g. in the main valves ) to provide a better performance for the machine. In the figure, the key components, the main valves ( level 3 ) with its corresponding crossover and the connections are considered as a level which is activated by the pilot valves (level 1 ), spool and orifice (level 2 ), and feedback by cylinders (level 4 ) and dynamics (level 5 ). The first two levels are only activated as the hydraulic models with a first-order response characteristics. The last three levels have very complex hydraulic ( crossover, load sensing ) arid multi-link dynamic characteristics which are corresponding to the level 3 and level 4 in Figure 2.3. The level 5 has been modelled in Dr. Wong's thesis. The level 3 and level 4 have been modelled in Dr. Sepehri's thesis. So we remodel the level 1 and level 2 as the following:  Level 1 The voltage input is applied to the pilot servovalve and gives out the pilot pressure which acts on either side of the main spool valve. This relationship  Y(t) = f(U(t))  where Y(t),U(t) are component output and input. is shown in Figure 2.6 by using curve fitting from experiment data and pilot structure.  (2.13)  Chapter 2.  21  Hydraulic and Dynamic Modelling  Pilot Pressure vs. Volt for Cabin, Boom, Stick, and Bucket  400 300  co  a. o 51  Volt  Figure 2.6 Pilot Valve Model  By analyzing the transient and steady-state response of the pilot valve, the transfer function between the input voltage and the pilot pressure can be modelled as a first-order response system with the form of transfer function as  H{s) =  a s+a  (2.14)  By using Step-invariance method, we convert equation ( 2.14 ) from continuous time to discrete time:  (l-e- )zaT  H(z) =  1  (2.15)  where T is the sampling period. So the discrete time system response function is given by:  Y(n) =  H(z)*f{U(n))  (2.16)  Chapter 2.  22  Hydraulic and Dynamic Modelling  By analyzing the pilot value step input response, choosing the 66.3% of steady value point, the a is calculated at 114.28 and used in the simulator.  Level 2 The pilot pressure causes the main spool valve's movement. The boom and stick pilot valves' output also acts on the crossover side. The boom crossover only acts on boom up, while the stick crossover works on both stick in and stick out. The single relationship between the input pressure and the spool displacement can also be described in Figure 2.7.  Spool Displacement v.s. Pilot Pressure  -400  -300  -200  -100 0 100 Pilot Pressure ( psi)  200  300  400  Figure 2.7 Main Valve Spool Model  The relationship in this level is also modelled as a first-order differential equation. In our sampling model, the same discrete time model like ( 2.16 ) is given to describe the relationship between the pilot pressure and the main valve spool displacement. Each joint has a main valve spool invoked by its pilot valve. The pilot pressures to "Boom" and "Stick" invoke crossover spools respectively. The boom crossover valve only works when "Boom" is raised up as shown in Figure 2.7.  Chapter 2.  Hydraulic and Dynamic Modelling  23  The model of the spool displacement to the three orifices which are pump to cylinder, cylinder to tank, and pump to tank are also given as nonlinear curves. In level 1 and level 2, all the curves are calculated and modified based on experimental data from our test. The a value in the relationship function 2.15 of pilot pressure and spool displacement is calculated at 22.56 by analyzing the step input response and used in the simulator.  24  3 Simulation and Implementation The simulator is a software package with the implementation of the hydraulic and dynamic model, and is used to represent the machine behavior.  1 Implementation Algorithm The hydraulic and dynamic models of the Caterpillar manipulator are programmed into a simulator. The software is composed modularly like the structure described in Figure 2.5 New System Working Mechanism. Each hydraulic component has its own function module which can take the component input and pass the output. The first and second levels in Figure 2.5 are implemented into a first order discrete time model with the nonlinear curves obtained from experiments. This implementation is very straightforward. The previous model of the main valve orifices and the pump behavior did not match the real machine data well. We derive the orifice models based on the real machine behavior using an inferring technique, i.e. using the orifice output — the flows which go through the valve into the cylinder or the motor ( Q ) and out from in  the cylinder or the motor ( Q , ), and the line pressures as well as pump pressure as ( Pu ) or ( P ou  pump  ) to  derive the orifice values ( like pc pump to cylinder and ct cylinder to tank )  Q  in  — k*pc* y/Ppump - Pn (3.1)  Qout — k*ct* \JP\i -  Pt k an  When the system is in the steady state, the flow out from the main valve should be equal to the flow into the cylinder, and the flow into the main valve from the cylinder or the motor should equal to the flow out from the cylinder or motor. And the flows can be derived from the joint position and joint speed based on the joint structure model. In the hydraulic simulation loop, the internal pressure of the main valve is determined by the line pressure and the main valve orifice. Then the pump pressure is adjusted to the value required by the load based on its load sensing capability. The main valve circuit may have one of the five solutions depending on the 24  Chapter 3. Simulation and Implementation  25  pressure values in the main valves. The search for the solution amongst the five alternatives ( as described in Chapter 2 ) is performed through an iterative search strategy. This is done by examining the five alternative circuits in parallel. The one which satisfies the condition for the pressure distribution is the solution. Further simplifications can also be performed to ease the search for the solution. For example, it is noted that when stick or boom is not activated, cases (d) or (e) ( in Table 3.1) are not amongst the possible solutions and thus are not considered. Also case (a) is the only solution when neither boom nor stick is activated. Following general numerical simulation algorithms used in [27] are also applied in our new simulator. The Secant Method [23] is used to solve the internal main valve pressures P  in  in the five alternatives  given the hydraulic equation:  (3.2)  Q = ka\/P - Pin out  Assuming the flow Q pass the orifice a and line pressure P , are known and only one solution for P ou  in  exists,  equation 3.2 is used to solve the />,„. The general idea of this method is to find the root satisfying the function  f(x) = Q-  kay/P  out  - P  in  =0  (3.3)  by choosing two initial value points, then extrapolating or interpolating the two most recently evaluated points as Figure 3.1 shows  Figure 3.1 The Secant Method  Chapter 3.  26  Simulation and Implementation  The fatal drawback of the method is that it cannot guarantee a converging solution because the root does not necessarily remain the solution bracketed. Fourth-Order Runge-Kutta [23] In Figure 2.5 the hydraulic flows out from the main valves acts on the cylinders or the motor which in turn give the torque to the corresponding links. And the level 5 dynamics feeds back the joint position and velocity parameters to level 4 the cylinders or motor which change the joint pressures due to the characteristics of the fluid compliance. The models of level 4 and 5 are described by first-order and second-order differential equations which are used for integration in our hydraulic and dynamic simulator. The integration of the line pressures and the joint position, joint speed, and joint acceleration are achieved by using the fourth-order Runge-Kutta method. The basic idea to advance a solution from x to x i = x n  n+  n  + h for the formula of  y +i n  = yn+hf'(x ,y ) n  (3.4)  n  is to use four evaluations of the right-hand side to assure the high accuracy. The formula is given.as:  ki = hf , ,' (lx k = hf 2  (x ,y ) n  n  h \1 +—  h  + -,y  n  n  •. h &2 k = hf \^x + -, y + — 3  n  n  (3.5)  k = hf (x + h,y + k ) 4  n  n  3  and ki  kn  k  3  &4  Vn+i = Vn + y + y + y + y . + In our system x  n  ,-./.^\  0(h ) 5  consists of the line pressure p, the joint position 0 and the joint speed , then y includes the g  derivative of line pressure ' , the joint speed j and the joint acceleration  fl  n  respectively, and / is a relationship  function vector of the parameter vector x with the parameter vector y-.  2 Simulator Modification and Verification Simulator Modification  In order to use this simulator in our fault diagnosis algorithm, we require this  simulator to achieve following targets:  Chapter  1.  27  Simulation and Implementation  3.  It must be modelled like the real machine as good as possible. So this simulator can be treated as pure fault-free model in the fault diagnosis  2.  It must be able to finish one cycle of simulation in a sampling interval, e.g. the execution period for one iteration can be less than sampling period of the real machine in order to be used for diagnosis  3.  It must be modelled based on the component functionality.  The first requirement is verified by next paragraph and the second should be achieved by parallel simulation, and the third is fitted by, the new model. The dynamic and hydraulic simulator was previously modelled and coded by the authors of [25] and [27]. We run their simulator using the real machine control signals. The simulation results and the real machine sensor readings are shown in Figure 3.2.  (a )  CD  60 c  I/O: Input, SimuAng "  1 1 i  Angle (S)  40  < %  ", RealAng " - "  Angle (R)  20  1 1 1  j  "  ~~t~~~~ '~'f'Z rr  'input "|  i  2  0.5  0  "5  (b)  >  1  i  2.5  1.5  Pump Pres: P1 "  4000  time (sec)  ", P2 " - "  P1 & P2 (<S)  to Q.  2000  / :  CD  !  P1 & P2 (R  Q.  0.5  (c) 5000 Q.  •>  1  Line Pres: Head "  RodP(Sf.  2.5  1.5 time (sec)  ", Rod " - "  ~;>r~  CD  RodP(R)  HeadP(S)  CD  t  HeadP(R)  CL  -5000  0.5  1  1.5 time (sec)  ( S ) : Simulation  ( R ): Real Machine  Figure 3.2 Comparison of Old Simulator with the Real Machine for Link "Boom"  2.5  Chapter  3.  Simulation and Implementation  28  In Figure 3.2, ( a ) shows the real machine and the simulators joint position value given the step voltage input on the link " Boom ", ( b ) shows the pumps result from both the machine and the simulator, ( c ) gives the joint line head and rod pressures. There are several serious drawbacks in the results which are: 1.  In ( a ) the movement of the joint in the simulator is much faster than the real machine  2.  The timedelay of the system response is not considered in the simulator  3.  The software floating point exception case is not considered in the simulator like divided by zero which causes the diverging oscillation as shown in ( c ), etc.  4.  The simulation variable values are not matched to the real machine reading From the figure we can see.that the same inputs go to the simulator and the real machine, all the simulation  results do not agree with the real machine performance. There are several serious features in the implementation of the old simulator: 1.  The simulator does not have a separate pilot valve model, so no pilot pressure simulation result is given from the simulator to isolate the component  2.  The simulator is not exactly modelled and coded based on each component's functionality  3.  The simulator is running at a fixed sampling rate. In order to use the simulation model in our diagnostic algorithm, the" simulator has to be modified. Our first step was to modify the simulator to give one functional module for each component in the hydraulic  machine as we described in Figure 2.3. In this simulator, we use [25] and [27] 's model, and eliminate all the global variables in their simulator software and enable the simulator to run for any sampling rate. The same performance result is given in Figure 3.3 for our functional-module-based simulator as it should. The results show that the old simulator is not modelled and implemented like the real machine exactly, especially in the pilot valve and main valve models. Our next step was to modify the hydraulic model in the simulator. Each module was coded to represent the component functionality. The component model has been described in previous chapter in the hydraulic  Chapter  3.  29  Simulation and Implementation  modelling section. The significant changes have been done with the level 1, level 2, and level 3, such as pilot valve models and main valve models of the spool displacement and the orifices, as well as the pump models based on the real machine data. A l l the modules are connected based on the machine system structure as described in Figure 2.5 " New System Working Mechanism ". So the component functional module can take the previous component's output as its input. The new result using the same input to the link " Boom " as Figure 3.2 and Figure 3.3, is shown in Figure 3.4. We can see from this figure that our new simulator has modelled the real performance correctly. 1.  The system input and the joint angle output are in ( a )  2.  The pilot pressure and the spool displacement of the main valve are in ( b )  3.  The pump pressures are in ( c )  4.  The line pressures are in ( d )  ( a ) I/O: Input, RealAng  CD  ;o  6 0  c  4 0  <  SimuAng  i  _i_  I  -ArigreTSTf  i  f  Angle ( R )  i  1  1  2 0  CD  Input  0  I  o >  0 . 5  .  time (sec)  ( b ) Pump Pres: P1 4 0 0 0 P I  Q-  &  (s)  pi  * P K R )  CD  3 CO CO  2 . 5  1 . 5  1  2 0 0 0  CO  P2 " - "  "I  7T  A J  '  I / I / k  P 2 ( R ) 0  I  5 0 0 0  Line Pres: P1 "  ", P2 " - "  . . -\"^r  R0d ( R )  Rod (_S j  i i i i  - 5 0 0 0  1 0 0 0 0 0  2 . 5  time (sec)  - w  0  ' 1 . 5  1  0  0 . 5  ~~t". H e a d ( S ) j i , i i i i i  "  j  Head ( R ) | • i i i  1 . 5  1  time (sec) ( S ) Simulation  ( R ) Real Machine  Figure 3.3 Modularized Simulator Performance (same)  2 . 5  Chapter  30  Simulation and Implementation  3.  From the figure we can see that the simulation results match the real machine performance in most aspects such as sensor reading values, response time and time delay as well as deadband, and steady response. There are some features in the second step implementation. The new simulator is programmed to fit for any sampling rate which is less than 100 hz. We also implemented the deadband and time-delay held by some hydraulic components like the pilot valve and main valves. Most of the deadband and time-delay of the system lie in the first three levels. Simulation results will show the deadband and time-delay are modelled for the real system.  (b]  (a)  Pj]otPres:(R)"+",(S)"_"& Splxl .e+3:(R)"_",(S)"—" -5 5 0 " Spool (|S)  l/0:lnput"++",Ang(R)"_",Ang(S)"  1  1  1 2 time (sec)  2  time (sec) PumpPres:(R)P1"+",P2"_".(S)P1"_",P2" 2500 f ' ! P1 & P2l (S)  I  2  0  0  0  ! - ^ ^ -  LinePres:(R)Hd"+",Rod"_",(S)Hd"_",Rod"—" 3000,—  Rcjd(S)  Rod ( R )  55 2000  a. CD  |  i  1000  CD k_ CL CD  '_ i  HeadC?) n  -1000  0_.^=-^w^--c|:  0  Head —  j  ^ ^  1  ;  2  time (sec)  (d)  ( S ) : Simulation  ( R ) : Real Machine  Figure 3.4 New Simulator Result: Positive Input to "Boom"  Simulation Verification  The "Boom" is a very special joint in the simulator. The crossover only acts  when the boom moves up i.e. positive control input to the link. When the crossover is not working, the  Chapter  3.  31  Simulation and Implementation  simulation result is also matched to the real system response as Figure 3.5 shows. So the crossover behavior has been correctly modelled and implemented. The other joint's responses are shown in Figure 3.6 for the "Stick" and Figure 3.7 for the "Bucket". (b)  (a) l/0:lnput"++",Ang(R)"_",Ang(S)"—"  ,PilotPres:(R)"+",(S)"_"& Splxl .e+3:(R)"_",(S)"—" o 100  o "  Q. w  41  J PilotPres R)  "V%  J PilotPres ( S )  •\  jsp°°i(_FM__  — -200 CO  2-300 3 CO CO  1 2 time (sec) PumpPres:(R)P1"+",P2"_",(S)P1"_",P2"— 4000 r  2 -400 0  ZS^ZJZJZ-  ~ Spool ?S )" 1 2 time (sec)  LinePres:(R)Hd"+",Rod"_",(S)Hd"_",Rod" 4000 r  Q.  2  1000 1 2 time (sec) (d)  ( S ) : Simulation  ( R ) : Real Machine  Figure 3.5 Simulation and System Response for Negative Input to "Boom"  In all of the simulations we give a step input voltage value to the Boom, the Stick, or the Bucket. From these figures, we can see that the simulation result is very similar to the real machine output. In the simulations the final joint position result and the pilot pressure, spool displacement are quite similar to the real machine's readings. The pressures' values are all in an acceptable range. Because pressures are very sensitive parameters which are adjusted according to the joint load and movement and are significantly changed by a tiny movement of the spool valve or the orifices' modification. The pressure results show some kind of deviation and vibration because of the integration and the effect of the big hydraulic compliance value since the differential pressure is proportional to that compliance.  Chapter  3.  Simulation and Implementation  32  In figure 3.7, bigger differences are shown in the pump pressures and the line pressures. In reality we cannot exactly model the real system. The difference in Figure 3.7 could be caused by following reasons:  1.  Inexact modelling of the pilot valve pressure as well as the spool or orifice  2.  Inexact friction model for the joint as well as inexact dynamic model which is related to the link mass and the joint position.  We also tried to modify the corresponding parameters like the fluid compliance in the simulator at above respects in order to get the better simulation performance. The Cabin simulation result is not shown here. Because the link is much more affected by the friction model and degradation of the component surface, we do need to have a better friction model to improve the simulation result. This work is not included in my thesis.  One important feature of the hydraulic machine is the deadband in the components such as the pilot valve and the main valve. We also implement the deadband behavior in the simulator. The machine deadband behavior and the corresponding simulation results are shown in Figure 3.8 which the system is given 1.0 volt input to the "Boom". Due to the deadbands of the pilot valves and the main valves, as well as the gravity of the manipulator link, a small voltage value of input signal would not cause the machine to move as shown in the figure 3.8. In this figure the boom is activated by a 1.0 voltage input, all the pilot pressure, and line pressures give the corresponding reading, while the link keeps idle. The results show our simulator can model this behavior as desired. The little oscillations may come from the fluid compliance and the inaccurate friction model. Furthermore, this characteristic will be used in the sensor and board diagnosis in next chapter.  From figure 3.8 we can see after a certain response time, all the parameters especially the pump pressure and line pressures stay at the steady values. Those characteristics will be discussed in next chapter and utilized in electronics diagnosis.  Chapter  3.  Simulation  and  33  Implementation  (b)  (a) l/0:lnput"++",Ang(R)".  J?ilotPres:(R)"+",(S)"_"& Splxl .e+3:(R)"_",(S)"— 4001  —  cu 03  c  < CO rare  100  ~o  >  -150 time (sec) PumpPres:(R)P1"+",P2"_",(S)P1"_",P2"2000 r  time (sec) LinePres:(R)Hd"+" Rod"_",(S)Hd"_",Rod"20001  time (sec)  2 time (sec)  (c)  (d)  ( S ) : Simulation  ( R ) : Real Machine  Figure 3.6 Simulation and System Response of Joint "Stick"  Chapter  3.  Simulation  and  34  Implementation  (b)  (a) l/0:lnput"++",Ang(R)"_",Ang(S)"— 50 I Inpjut | CD T3 B 0 O)  c  0 -50  <  £-100  j.i,  ->4^<-  >  _ _NJ  -200 0  1-200  J  I  Angle | ( R )  ! 1 1  Spool (R)!  o  -7=-!^-'----!-  I I I  IT !---^ln-tr\-  o 300M—*|  Angle ( 6 )  CD O)  5-150 o  PjjotPres:(R)"+",(S)"_"& Splxl .e+3:(R)"_",(S)"— -§400 -I ..r...r-J o I o "V"i  i i  hf  _!  § 100  1  °-  2 time (sec)  0  1  i  i  j__>_jt<s)  i  >?(R)  ft  CO CO CD  !  1  Spo^l(S)  i i  !  2 time (sec)  4  LinePres:(R)Hd"+",Rod'V ,(S)Hd"_",Rod"2000 i Head(S) ! i  PumpPres:(R)P1"+",P2"_",(S)P1"_",P2"— 2000 r  ,  r  I  55 1500 CD  |  I  .  Rod ( S ) I  1000  I  Q. CD  A Head ( R ) i i  \ .i  CD  I/V4--T  --{-  -+—t  1-  500 - i f  4  w  —  i |  I  I  Rodi( i  i ~i R)  time (sec)  (d) ( S ) : Simulation  3  ( R ) : Real Machine  Figure 3.7 Simulation and System Response of Joint "Bucket"  i i i  i  Chapter 3.  Simulation and Implementation  35  (b)  (a) l/0:lnput"++",Ang(R)"_",Ang(S)"1 CD  ''\ \  ' ^ ' ^ - ' ^ ^ 1 1 I 1  i i  i i i i -1  i i  Input Q) '  CD  TO >  i. _ _^ i |  j_ i  i i  i i  2  •5 200  Anglej(R)  Angle ( S ) j  <  PjlotPres:(R)"+",(S)" ."& Splxl .e+3:(R)"_".(S)"-  i i i  i  4 time (sec)  4 time (sec)  Pump Pressure 1500  i i jts. i  P 1 (  /'l  0)  Line Pressure  I I  j> 1000 CO CO  S1)  2000  I  I I  D. 500 3 CL  II  1  J>"  P  ^  R  )  y  jp2 (s;  time (sec)  (c) ( S ) : Simulation  4 time (sec)  (d) ( R ) : Real Machine  Figure 3.8 Deadband Behavior of Hydraulic System with 1 Volt Input to " Boom"  36  4 Diagnostic Algorithm 1 Diagnostic Algorithm Review Model Free and Model Based approaches  The approaches of fault diagnosis fall into two major  groups as characterized by Janos Gertler in [11]: 1.  Methods that do not make use of system model;  2.  Methods that do make use of system model. The model-free methods consist of :  1.  Limit checking;  2.  Installation of multiple sensors (physical redundancy which is aimed at detecting and isolating sensor failures);  3.  Frequency spectrum analysis of system measurements;  4.  Expert system approach which is aimed at evaluating the symptoms by using IF symptom A N D symptom T H E N conclusion logical rules [11].  Faults are declared based on the discrepancy between the reading or the analysis result and the expected value ( for the first 3 methods ), or if the phenomena matches the predefined symptom ( expert system approach ). The model-free methods have been generally replaced by model-based approaches. Current model-based diagnostic algorithms fall into two distinct research communities. In the engineering community, fault diagnostic techniques mainly rely on a precise mathematical model of the process and on pre-enumerated symptom-fault  patterns known as fault signatures. In the computer science!artificial intelligence community, model-based diagnosis relies on models of structure and behavior. This A I model is component-oriented in the sense that it explicitly represents the components of which the system itself is composed, and interconnects them in the same way that they are interconnected in the system. So the model includes both the functional and physical organization of components. For example, given symptoms of misbehavior ( as detected by the behavioral 36  Chapter  4.  Diagnostic  37  Algorithm  model ), fault candidates are identified using the structural model by following a dependency chain back from a violated prediction to each component and parameter that contributes to that prediction.  Model-Based Algorithm in Control Community Model-based failure detection algorithms in the control community rely on the idea of analytical redundancy ( i.e. the analysis result of mathematical model). The procedure can be described by three steps as shown in Figure 4.1:  Model Design  |  1  Measurements  Residual • Generation  Residuals  Statistical Testing  Signatures  Decision Making  Interence  Figure 4.1 Stages of Model-Based Failure Detection and Isolation  Residual Generation  Gertler describes the "residual generation" in [11]: sensory measurements are  compared to analytically obtained values of the respective variable. Such computations use present and/or previous measurements of other variables and the mathematical model describing their relationship. The resulting differences are called "residuals" . At this stage, different variables or techniques are used. When state variables are selected to generate residuals, the state-space model, and the state estimation techniques such as observer schemes, Kalman filters, are applied. Most of the component fault detection and instrument (i.e. sensor) fault detection methods utilize a state-space technique. When system physical parameters are chosen to generate residuals, a continuous time physical system parameter identification technique is utilized. R. Isermann proposed this method in [12] [13] [14]. General techniques used at this stage are [10]: 1.  The parity space approach: the key point is to check the parity (consistency) of the mathematical equations of the system ( analytical redundancy relations) by using the actual measurement. A fault is declared to  Chapter  4.  Diagnostic  Algorithm  38  have occurred once preassigned error bounds on the state variables are surpassed. This method leads to the concept of state estimation. 2.  Dedicated observer approach: the basic idea of the observer approach is to reconstruct the outputs of the system from the measurements or subsets of the measurements with the aid of single or banks of Luenberger observers or Kalman filters using estimation error or innovation. The advantage of this approach is that for state estimation one can use full or reduced-order state observers in the deterministic case or Kalman filters in the stochastic case when noise has to be considered[10][26].  3.  Fault detectionfilter(FDF): a full-order state estimator with a special choice of time-variant observer gain matrix.  4.  Parameter identification approach:. it bases on the fact that faults of a dynamic system are reflected in the physical parameters, and to detect the faults via estimation of the parameters of the mathematical model. The difficulty lies in the technique of accurate continuous time parameter identification [12]. Statistical Testing  A logical pattern which is called the signature of the failure is generated by statistical  analysis because of the existence of noise to show which residuals can be considered normal and which ones indicate a fault [11]. If there is no noise, any nonzero residual is an indication of a fault condition so that the logical analysis of the fault situation can be performed directly on the residuals. In general, the effect of faults on the residuals has to be separated from that of noise. This is done by statistical testing, making use of the fact ( or assumption ) that the noise is random with zero mean. Common statistical methods are listed in [10] as follows: 1.  Direct parallel testing: This method supposes each element of the residual vector is independent of each other, so the elements can be tested in parallel. Following each computation of the residuals, a separate test is applied to each element of the residual vector. Based on the outcomes ( mean and variance ) of the individual test, a boolean signature vector e(t) is formed so that a ej(t) = 1 if <?,(t) fired if the deviation of mean exceeds the threshold in the test, and e;(t) = 0 if it does not  2.  Multivariate testing: When the elements of the residual vector are not independent of each other, even if the noise is white, multivariate testing must be used. In the p-dimensional space of the residuals  Chapter  4.  Diagnostic  39  Algorithm  e(t) = [ei(t), ...e (t)] , any constant probability density p(ei, ...e ) = const "isotherm" is described by T  p  p  a closed hypersurface. Selecting a level of confidence implies choosing one such surface. If the point defined by e(t) is outside the limit surface, the system is declared faulty. The main disadvantage is that it provides only a faulty/not faulty decision 3.  Sequential likelihood ratio test: This test compares the hypothesis Hi of nonzero residual mean to the null hypothesis Ho of zero mean. The decision is based on the likelihood ratio  t K  >  p{e,-(0),...e,-(t) | H }  K  0  The numerator and denominator are the probability densities of the observed time series under the two hypotheses. If the residuals are independent and normally distributed, it becomes the difference of two sums. Logical Analysis  The logical patterns generated by statistical testing are analyzed with the aim of isolating  the failure or failures that cause the residuals. This is the final fault isolation step of a fault detection and isolation technique. This step is performed by comparison to a set of predefined patterns (signatures) known to belong to simple failures or by the use of some more complex logical procedure. The tools mainly used for the logical pattern analysis are: 1.  Pattern recognition, such as Bayes Rule, Neural Network, and so on  2.  Logic tree which shows the cause and result relationship  3.  Rule-based interpreter or expert system like the symptom and conclusion rule. In this area, the ability lies primarily in the structure of the model used in residual generation and in the  statistical test applied, combined with the fault model. In the observer technique, isolation depends strongly on the observer design scheme by using redundant observers with a priori knowledge of the fault mode. Restriction  The diagnostic techniques in the engineering area have an undesirable drawback.  development of suitable models to support the required detection is difficult.  The  Although design models are  typically available, they may not be suitable for diagnosis. Expertise may not be available for newly developed systems. Suitable models may not be available for complex systems. Design models focus on those interactions  Chapter  4.  Diagnostic  Algorithm  40  between system elements that are required for achieving the desired functionality; other interactions are omitted, and thus not all faults can be explained in such models. Moreover, detailed models are often too complicated to facilitate diagnosis: dynamic systems may employ feedback loops, the model may change over time, or there may be non-linear components present. The model-based, approaches require advanced information processing  techniques such as state estimation, parameter estimation, adaptive filtering, variable threshold logic, statistical decision theory, pattern recognition, and various logical operations. So the algorithm in the control community is very computational power intensive. For example, Isermann's model-based approach to process fault diagnosis, uses dynamic mathematical models and measurable input and output signals to allow estimation of unmeasurable internal quantities, which can then be used for fault detection. However, Isermann's models are strictly quantitative and are expected to describe the process behavior precisely. The resulting approximate-matching problem ( to determine if an observation is "normal" ) is handled with a "Bayes decision algorithm". After recognizing a symptom, this system classifies the fault by comparing it with fault signatures, which must have been established beforehand. The requirements for this algorithm are hard to achieve, and the complete fault signatures are extremely difficult to get.  Model-Based Diagnostic Algorithm in Artificial Intelligence Diagnostics In this area, most early knowledge-based systems diagnose faulty behaviors in dynamic systems using heuristically derived causal relations between the faults and the causes, like a set of symptom-fault pattern or production rules. Although many such systems offered a high run-time performance, they suffered from well-known disadvantages, including incompleteness and inflexibility. Model-based problem solvers have been successfully applied in static domains, such as digital circuits, but they generally cannot deal with dynamic mechanisms. However, they can predict behavior and compare it to actual observations. A l l the model based approaches are based on an underlying model of the system's structure and behavior, using a model of a physical system to explain discrepancies between the faulty and normal behavior[4] [24] [6] [5] [16] [15]. In the artificial intelligence area, a model contains information about the structure and correct behavior of the components in the system, and diagnostics refers to model-based qualitative reasoning [4]. Models have  Chapter  4.  Diagnostic  Algorithm  41  several distinct properties: 1.  They are models of structure and behavior;  2.  They are capable of both simulation and inference (e.g. predicting outputs from inputs and inferring inputs from observations); due to the logical relationship of system structure;  3.  They are organized around components and connections;  4.  They are often hierarchical. Structure includes both the functional and physical organization of components  But a dynamic engineering system can hardly meet all of those conditions. A diagnostic system in the AI area is a triple system which utilizes [4]: 1.  SD, the system description, most likely is a set of first-order sentences, (component behavior )  2.  COMPS, the system components, is a finite set of constants (system structure)  3.  OBS, a set of observations, is a set of system values (system observation). SD and COMPS are used to predict system behavior given the system input or infer the system input given  the system output. A "diagnosis" is a sentence describing one possible state of the system, where this state is an assignment of the status "normal" or "abnormal" situation to each system component. The fundamental paradigm of model-based diagnosis using the triple system is the interaction of prediction and observation. The difference between the prediction and observation is called a "discrepancy". Model types vary a great deal : there are numerical models, dynamic qualitative models, extended signed directed graphs, fuzzy qualitative models and semiquatitative models [22]. It is not practical to set up a logical model for a dynamic system. In the A I area a dynamic system is described by a qualitative differential model. For the qualitative model the system is decomposed into a finite set of system components, and one or more qualitative differential equations governs the behavior of each component, it is known as "component-connection model". In most cases of model-based dynamic diagnostics, qualitative simulation is used as an inference engine during troubleshooting to predict possible behavior patterns. This algorithm uses finite states to represent the infinite states of a dynamic system.  Chapter  4.  Diagnostic  Diagnostic Procedure  Algorithm  42  The fundamental procedure of qualitative reasoning for fault diagnosis lies in three  subjects [4]:  1.  Generating hypotheses by reasoning from a symptom to a collection of components whose misbehavior may plausibly have caused that symptom, given one discrepancy, the result of this step is a set of system diagnosis hypotheses which describe the possible states of normal or abnormal system components  2.  Testing each hypothesis to see whether it can account for all available observations of system behavior given a collection of components implicated during hypothesis generation, and give the possible minimum set of the system diagnoses, at this step, all the overlay hypotheses are cut off from the hypothesis set  3.  Discriminating when more than one hypothesis survives the testing phase, what additional information should be gathered to discriminate among them, similar to fault localization in engineering area.  One advantage of this A I algorithm with respect to the algorithms in the control community is that diagnosis is only needed to be invoked when the system develops a certain kind of problem. A l l of the possible fault reasons i.e. the hypotheses which cause the fault symptom are generated and tested at run-time based on the run-time symptom rather than based on predefined fault patterns. . Restriction  The ..crucial drawback lies in the narrow static application domain. The representation of the  model usually gives the logical relationship among components, and P R O L O G or LISP are generally chosen to describe the model. Using finite states to represent infinite states of a dynamic system restricts this approach to be used for logical relations or heuristically described systems. This model-based approach is generally used for two situations. First, the structure and behavior of the system should be reasonably well known and simple enough to be modelled, but complex enough that exhaustive simulation is infeasible. Second, the set of possible faults should be difficult to be reliably enumerated in advance. The diagnosis hypothesis in A I area usually gives the component a normal or abnormal rating only, not the component fault mode or fault reason as the engineering community does. Traditional diagnosis relies on fault models, descriptions of the varieties of component misbehaviors typically encountered.  Chapter  4.  Diagnostic  43  Algorithm  2 Proposed Incremental Fault Diagnostic Algorithm (IFDA) System Analysis  In our system, several conditions hold that would challenge the previous diagnostic  methods. Firstly, the machine is a continuous-variable dynamic system with feedback loops in a real-time operating situation. Secondly, subsystems interact with each other. Thirdly, many system quantities are not measured. Finally, measurements are not absolutely reliable due to sensor failures. Our diagnostic algorithm is also based on the interaction of prediction and observation of the triple dynamic system ( behavior, structure and measurement ). The difficulties lie in: 1.  A system model can only give a dynamic relationship of the component rather than a logical one  2.  Real-time diagnosis requires an efficient language  3.  The complex main valve model also precludes the qualitative simulation for behavior prediction.  Fortunately, our machine model looks like a chain for each subsystem as shown in Figure 2.5. This provides the possibility'of separating each component behavior.  The difficulty lies in the interaction among those  subsystems. The machine is installed with some sensors for some components for control. This provides the opportunity to diagnose the component separately. But the sensor can also cause an ambiguous diagnosis because the abnormal signal may come from either an abnormal sensor or a faulty component, or both. So we propose a distinguish sensor and board ( e.g. electronics ) diagnosis which can be performed separately from the component diagnosis before activating an idle machine or after stopping an active machine. This will be discussed' in the next section. In order to assure accurate control over the machine operation, sensor monitoring and diagnosis is also expected to go with component diagnosis when the machine is active.  Real-Time Diagnosis Requirement  On the purpose of real-tirrie diagnosis, the diagnostic system  must satisfy following requirements: 1.  It must provide a guaranteed response time, completing its reasoning within a deterministic amount of time  2.  It must perform nonmonotonically, i.e. it must be able to change its results and possibly discard old results in response to new data  Chapter  4.  Diagnostic  44  Algorithm  3.  It must operate continuously  • .  4.  It must be able to diagnose both single and multiple fault cases  5.  Only a single fault can occur during one sampling period  6.  It must be able to produce a precise result. Because components are interacting with each other in the machine, a fault in any component can propagate to another level  7.  It must recognize sensor failures when machine sensors generate invalid data.  After detecting and  diagnosing such an occurrence, the system must still continue to generate an acceptable diagnosis 8.  The system must precisely identify which components are the source of failure for our feedback loop model. A failure in any component can either be magnified or compensated due to interactions within the loop.  IFDA Primitive Components  The new algorithm which we'call "Incremental Fault Diagnostics"  proposed here is much like the diagnostic algorithms in the A I group [24] [6] [5] [15] [19] [8] [4] which is a triple system utilizing the system behavior description, system structure, and a set of system observations. We diagnose a fault based on the triple system, detect the discrepancy from the model predictions and the set of observations, generate fault hypotheses from the first discrepancy point downward through the model dependency structure, (because a fault should happen before the first discrepancy point in general, the following discrepancies are caused by the first discrepancy usually), then prove the hypothesis further. Most of the A I diagnostic algorithms utilize a qualitative model or a semiqualitative model with finite states to describe the dynamic system briefly. The advantage of using this kind of model is its speed in certain cases, but the serious drawback is that the state transition path, i.e. which state of the system should follow which state in what conditions, must be defined beforehand, and it is really hard to give a complete state description for a dynamic system. Furthermore, the next state might be uncertain at run-time which will cost much more computing to decide which state should be chosen. Model-based fault diagnostic algorithms in the A I area are difficult for dynamic systems, especially in real-time. Several features exist in our diagnostic algorithm. Firstly, the model we used in our algorithm is a quantitative model with a confidence intervals which alleviate the effect of inaccurate modelling and uncertain factors. This model is chosen based on our system's features, like the crossover behavior, mechanism chain structure, etc.  Chapter  4.  Diagnostic  Algorithm  45  Secondly, we use a fault injected model which holds the current condition of all the system components including the previous fault information rather than a pure fault free model. This model provides the capability for further multiple fault diagnosis for a system in which fault has already happened and has been detected. Thirdly, no predefined fault mode in control area or any finite state transition path used in the A I group, which is usually incomplete, is required at run-time in our fault diagnostic algorithm, so no tedious statistics and pattern matching methods are required in our algorithm. The simulator can always mimic the real system situation and hold the previous fault information in it. This is why we call our algorithm as "incremental fault diagnostic algorithm".  In our algorithm the system behavior description and the structure are implemented into component functionality based on the so-called incremental simulator which embeds the system current condition. The general procedure is to simulate the system with the incremental simulator simultaneously. When the system's observation does not agree with the simulation prediction, and thus the current system status model does not "track" the machine behavior, some new hypotheses about a faulty component are generated, and the corresponding new model is set up and injected into the simulator to see if the further prediction can agree with the system behavior or not. If one of the hypotheses is confirmed, the faulty component is declared, otherwise, test another hypothesis. Since the simulator retains the system current states including the current faulty components, when another fault comes in, the diagnoser generates new hypotheses to match the new discrepancy. So this diagnostic algorithm is able to detect multiple faults at run-time. The algorithm architecture and module interrelationship is described as Figure 4.2.  Based on the algorithm idea and the general procedure for analysis, we do need some functional modules to simulate the real machine current condition, to find the discrepancy between the prediction and the observation, to generate the fault hypothesis, to set up the information model, to read the sensor reading from the machine or recorded files, and to pass all the information needed by each module, to coordinate all the modules' functionality.  To achieve the diagnostic target and accomplish all the functionality required, the primitive  components in our diagnostic system should include a Quantitative incremental simulator with variable range,  a Diagnosis manager, an Hypothesis generator, and a model-based diagnostician diagnoser. These components  Chapter  4.  Diagnostic  46  Algorithm  work together in a hypothesis-model-simulate-prove cycle in our diagnostic management system which should be running in real-time, i.e. to satisfy the real-time requirements. The term hypothesis-model-simulate-prove describes the general diagnostic procedure from monitoring the discrepancy between the simulation and the real machine, generating the fault hypothesis based on new discrepancy and system status model, building a new fault injected model from the hypothesis, simulating the new incremental model, to proving the hypothesis, and declaring the newly detected fault.  R Observations (O)  Inputs  Real Machine  O.P.M.H.&R  Diagnosis Manager  Diagnoser  Discrepancies Predictions (P) Incremental^Simulator  Hypothesis Hypothesis ( H ) Generator  system status model  R : Results Model ( M )  Figure 4.2 The Diagnostic Algorithm Architecture of The Diagnostic Management System  Hypothesis generation is the process of generating the fault hypothesis based on the discrepancy between the incremental simulator's prediction and the real machine reading, setting up the corresponding simulation model by the Model Builder and letting the simulator to follow the machine behavior constantly, and proposing the potential fault component hypothesis backward from the first untracked discrepancy point towards the system input based on the system structure i.e. component interrelationship, and the discrepancy position on the dependency chain. The Diagnostic Management System maintains a current condition model, which reflects the system condition with the previous fault component declarations and the suspected fault information. Each hypothesis results in a new model by the model builder. And the Model Builder embodies the fault hypothesis and represents an alternative interpretation of the system. The Incremental Simulator uses the newly built  Chapter  4.  Diagnostic  Algorithm  47  model. During diagnosis, diagnostic management system modifies the system condition to the current model as it generates fault hypotheses and proves or disproves them. During the machine operation, a measured component faulty behavior may come from the component itself or the sensor which measures the component signal. This complicated condition can be simply solved by the hypothesis generator. Sensors are also treated as components in our system. Model-based diagnosis Assuming only one fault can happen in a sampling period. This module is used to detect the discrepancy between the simulator prediction and the real machine reading. It can be used for either monitoring or hypothesis confirmation. Should discrepancy is found during monitoring, the diagnostic system will invoke the hypothesis-model-simulate-prove procedure. If the previously detected discrepancy disappears after simulating the newly built system status model and comparing the new prediction to real reading, the corresponding hypothesis is confirmed true, the related fault can be declared. Diagnosis Manager The diagnosis manager is a coordinator in the diagnostic management system. This manager holds the updated machine and simulator conditions and monitors the machine behavior. When the manager detects the discrepancies between the simulator and the machine, it will check the system condition model which holds all the previous fault component information in the system first to see the discrepancy has been tracked by a previous fault detection or not, execute the hypothesis-model-simulate-prove procedure to detect the potential fault. The functionality executed by this module is something like reading sensor data from machine or record file, synchronizing all the functional modules activities, calling the hypothesis generator to generate fault hypothesis based on the discrepancy detected from the diagnoser, passing input to the simulator and fetching the predictions from the latter, as well as communicating to the user interface and the diagnoser module.  Quantitative Incremental Simulator Our machine is a continuous-variable dynamic system. A set of first order differential equations are given to describe this machine, and the simulator has been coded based on the hydraulic and dynamic models. Given a set of initial values, a numerical simulation of the equations yields predictions of values within floating point accuracy for each variable over time. In our case, the numerical simulation is not precisely matched to the real machine and is too narrow for our purpose. The real machine contains the effect  Chapter  4.  Diagnostic  Algorithm  of deadband and drift. Sensors, actuators, and functional units operate within certain tolerances.  48  Parameter  values and some functional relations are known only approximately. One approach, is to do precise numerical simulation using average values, and then use some form of approximate matching of simulation results to observations. The problems that exist here are: given initial conditions, numerical simulation predicts only one behavior from a model, e.g. numerical simulation makes an inappropriate commitment to a single behavior; and the approximate matching can cause potential misjudgment — how to decide in a principal way, when a difference between the prediction and the observation is due to imprecision or when it is due to a fault? Here, the possible solution might be to express the imprecise knowledge as part of the model, in other words, to produce valid ranges for each variable and permit direct matching of observations to the prediction ranges. The system is modelled with two parts: the behavior model and the structural model. The former refers to each component's behavior. The latter is the dependency chain in system construction.  Manipulator Diagnosis  We have run the simulator and have seen in Chapter 3 that the prediction can  agree with the machine observation. We have also deduced the machine working mechanism, in other words the system structure, in Figure 2.5. Next we will see how the algorithm works in our machine. One subsystem ( a link ) structure shows the component physical interconnection and functional relationship in Figure 4.3.  Chapter  4.  Diagnostic  49  Algorithm  (a)  Real Machine mf  Pilot Valve  Computer  Cylinder  Orifice  Spool  Link  pp Pump  s  •i  Pilot  i vl've  s  •  P°  0 1  ioi  0rifice  J  i  [7 >i y !  c  |inder  L i n k  lp PP  ! Pump  Switch  I  Switch  (b) Simulator  Component  Module  Figure 4.3 System Structure Model  The real machine consists of several components such as pilot valves, main valves (including spool, orifice, etc ), cylinders, pumps, and links , and sort of sensors like voltage sensors ( v ), pilot pressure sensors (p ), spool displacement sensors ( s ), pump pressure sensors ( pp ), line pressure sensors ( lp ), and joint position resolvers ( 8 ). The simulator is composed by several functional modules corresponding to the real machine. The real machine and the simulator are both controlled by the system input ( v ) and run simultaneously and separately. If any of the real machine sensor readings do not match the corresponding prediction of the simulator, the diagnostic management system should invoke the diagnostic procedure. Let us see how the  Chapter  4.  Diagnostic  Algorithm  50  diagnostic algorithm handles the multiple fault problem and distinguishes the component fault or sensor fault when the machine is continuously running. We can briefly explain how this diagnostic algorithm works as the following. In Figure 4.3, suppose a discrepancy happens at the spool displacement position, e.g. the s variable, the following observations like the line pressure Ip, pump pressure pp, joint angle 6 may or may not match the simulator predictions. In the case of matching, we will let the hypothesis generating module generate a hypothesis that the fault source is the sensor of the spool displacement because only one discrepancy exists at that point. After this hypothesis is proved, this sensor fault information is injected into the system model. In order for the simulator to be used for further fault diagnosis, in the later simulation, the simulator will keep using the previous pilot valve functional module's output as the spool displacement module's input. In the case of unmatching, the hypothesis about the spool problem may be generated and proved, and the model information is modified, for detecting a further sensor or component fault, the module after the spool module in the simulator will use the real, machine's spool reading rather than the previous module's output as its input, i.e. we inject the spool fault into the simulator. The sensor fault or component fault diagnostic result will determine the corresponding module's input source in the simulator. That is why we have a switch in each connection of the simulator structure. For complex situations in the main valve, pump, cylinder, and the link dynamic loop, one component fault behavior will definitely affect another component module's output. If any discrepancy happens in this loop, several hypotheses should be generated because of the loop behavior, e.g., failure pump, main valve problem like an orifice obstacle, cylinder problem, etc., then the corresponding new model configuration is built to project the new prediction in order to prove the correctness for each hypothesis. In the circumstance that only one sensor reading discrepancy happens in the loop, the sensor failure hypothesis should be generated. One of the key advantages of this new diagnostic algorithm over to the algorithms in control and A I communities is the capability to detect the component fault and the sensor fault using the same model. This will be described in detail later.  1. Run-time Component Fault Diagnosis Suppose the discrepancies occur at both a pilot pressure  Chapter  4.  Diagnostic  Algorithm  51  and the following comparing points simultaneously. The hypothesis generator should generate a hypothesis in which the current fault component might be the pilot valve. Then the model builder will give the simulator a new system status model which consists of the information about the suspected faulty pilot valve and other well behaved components, the diagnostic manager will pass the real machine sensor readings into the simulator ( as the dotted line connecting the real machine and simulator shows ). For the new simulation, the spool module in the simulator will decide to choose input from the real machine reading based on the pilot valve fault hypothesis. The diagnostic manager will collect the new prediction from the simulator to diagnose and prove the hypothesis. If the hypothesis is true, before the fault detection, there should be multiple discrepancies which exist on the working mechanism chain starting from the pilot pressure point, after the new fault model injection, all the discrepancies starting from the spool displacement point are expected to disappear. After the fault happens and is detected, the simulator will take the machine pilot pressure value as the spool module's input instead of the simulator's pilot valve module's output for the following monitoring and diagnosing. We assume that only one fault is possibly happening between two successive measurements. Next we found that if the first discrepancy comes out at point of the joint position sensor reading and it's prediction, a set of fault hypotheses should be generated and tested to locate the fault source. We notice that the interaction among the pump main valve and the cylinder results in a functional loop. So one component fault will definitely affect other components' output. This situation will result in several hypotheses to be tested in the diagnosis procedure.  2. Run-time Sensor Fault Diagnosis Our algorithm also provides a mechanism to detect a sensor fault. Unlike other algorithms in control community [11] [10] [12] [13] [14] [26] and A I group [24] [6] [5] [15] [19] [8] [4] , our algorithm treats the sensor as a special component in the system. In the diagnostic procedure, a sensor fault hypothesis can be generated in a certain condition. The sensor fault.will only affect the reading but not change the following component outputs in the machine dependency chain. For instance, in Figure 4.3, if the pilot pressure sensor fails, it would not affect the other sensors' reading, like the spool displacement, joint angle etc. So, when we compare the results from the real machine and the simulator, if there is no other component failure, all of the sensor readings should be matched to the simulator prediction except the fault sensor reading, the pilot pressure. When a sensor is declared faulty, the simulator will still  Chapter  4.  Diagnostic  52  Algorithm  use the simulation prediction as next module's input in the dependency chain in order to diagnose the further potential fault which will happen to either a component or another sensor.  Advantages of Our Algorithm  The major advantages of our diagnostic algorithm are discussed as  the following: 1.  it does not require predefined symptom-fault pattern matching techniques in which patterns are usually incomplete, rather, it relies on discrepancies, system structure, system status  2.  it can detect multiple faults by injecting a previous fault into the incremental simulator  3.  it can handle both component fault and sensor faults using the same model  4.  it uses reasonable method and computing power to handle complex dynamic system problem.  The diagnostic model is based on the component-connection information. Our general structure is to use a model of the machine to predict its behavior and to check its consistency with the observations. When observations disagree with the model's prediction, the diagnostic procedure is invoked to identify the fault candidates. Unlike the algorithms used in the control community, we do not use predefined symptoms and pattern matching techniques. Such patterns are usually incomplete, since it is difficult for an expert to anticipate all possible faults and predict their symptoms, especially the symptoms of interacting faults. Even if we collect symptom-fault patterns from exhaustive fault-model simulations, using these patterns is not necessarily more efficient. Rather, we rely on a real machine's discrepancies with the incremental model's prediction which holds all the previous fault information in the model. In this way we can handle any unanticipated fault and diagnose multiple faults. We focus on the detection and location of component misbehavior, e.g. we make diagnostic assumptions about behavioral states of system or component as correct, abnormal, and so on. Unlike the algorithms in the control area [11] [10], which separate the component fault detection and the instrument ( i.e. sensor ) fault detection using different techniques or fault models, our algorithm has the capability of handling faulty sensors naturally. Since a sensor is treated as another component which affects an observation, it can be identified as a suspect in the same way as other components based on the dependency  Chapter  4.  Diagnostic  Algorithm  53  tracing. The key feature of a sensor fault, which is different from a component fault, is that a sensor only  affects one comparing point, while a component fault may cause several discrepancies on the dependency chai If a sensor cannot agree with the corresponding prediction, it just becomes a suspect. In the machine, internal parameters like the pump flows and the flows through the main valve orifices, etc., are invisible, and are not compared with the predictions, therefore, it would not cause a discrepancy. Lack of the corresponding sensors restricts accurate diagnosis capability. A quantitative simulation model with the numerical range of a physical system can predict the possible behaviors that are consistent with the incomplete and imprecise model of the machine's component. This ensures, for example, that rare but hazardous behaviors will not be overlooked. By using a structural model of the machine and tracing upstream from the site of unmatched observations, model based diagnosis generates fault candidates efficiently, without resorting to predefined ( and often incomplete ) symptom-fault patterns. To implement this algorithm, the simulator is required to be modularized based on component behavior, and the real machine can provide the corresponding measurements for the component. And the simulator must be able to describe the real system perfectly.  3 Electronics Diagnosis In the algorithm described above, we do not include the computer boards. A l l of the sensor readings go through the board channels. In some cases, a faulty reading may come from the board channel rather than the sensor itself. It would be desirable to separate the sensor and the board failure to a certain degree. This separate electronics diagnosis is aimed at assuring the status of sensors and boards before invoking an idle machine or stopping an active machine, as well as checking the accuracy of an active machine diagnosis. The general idea of electronics diagnosis is to compare the expected value due to gravity of the machine with autual measurements when machine is not moving. The difficulty in diagnosing the electronics in our machine lies in the facts: there is no separate information source for each element, some of the elements like the board and sensor share the same data source in the real  Chapter  4.  Diagnostic  Algorithm  54  system. It means we can only judge the sensor or board based on the same information: the sensor readings. Physical redundancy ( multiple sensors ) is not achievable because of higher cost. This structure limits our diagnosis to certain coupled results. The board and sensor diagnosis ( e.g. the idle diagnosis ) is performed by a special controller in our diagnostic program. We remember that the pilot valve and main valve models all have input deadbands, for the whole system, if the main valves' spools do not move, or move in the spool displacement deadband, the machine's four links will be idle. In this case, all the mechanical parts after level 2 are idle, so the dynamics and the complex main valve hydraulics in the simulator are not performing, only the first 2 levels and the pumps in the whole system and the gravity related dynamics are needed to achieve the board and sensor diagnosis. While the first two levels' model is straightforward. In Figure 3.8 , we can see that when the boom link is given a 1.0 volt step input, the boom link does not move due to the deadband of the pilot valves and the main valves as well as the friction of the manipulator, the steady value of all the pilot pressures, spool displacement, and the line pressures can be used to diagnose the sensor and board problems before beginning to move the machine. An abnormal sensor may have problems like bias readings, total failure. In this diagnostic algorithm, some sensor readings are expected to be a fixed value. Any discrepancy between the real value and the expected value can be used to detect the sensor problem. This provides an advantage of multiple kind of sensor problem diagnosis using straightforward technique. Remember, the first two levels of the system also join the system. So some sensor diagnosis can only be achieved to a certain degree. How much do we send the input to each link would be very important for this sensor diagnosis. Given the value of voltage input, the pilot valve has its deadband to give out pilot pressure. Given the pilot pressure input, the main valve has its spool displacement deadband output. A deadband also exists for the main valve orifice given the spool displacement input. If the orifices from the pump to the cylinder and from the cylinder to the tank are zero, there will be no flow to the link, so the link will not move, and all the flow provided by the pumps goes through the pump to tank orifice back to the tank. If the value is too small which cannot invoke the spool displacement, then the pump to tank orifice for each link will always be open which could  Chapter  4.  Diagnostic  Algorithm  55  not cause a pump pressure since the pump pressure will be equal to the tank pressure. The value we expect is that which can invoke a small spool displacement which is less than the spool deadband for the orifice from pump to cylinder. Because the orifices related to link motion are zero, any kind of hydraulic problems such as air bubble or dirty oil and any kind of mechanical problems of the orifices like cavitation will not affect the sizes of the from pump to link's orifice and the from link to tank's orifice. And the size of the from pump to tank orifice will cause an internal pump pressure which can be used test the pump pressure sensor. The problem exists in this diagnosis is that the bias reading for some sensors (like the pilot pressure sensors, spool displacement sensors, pump sensors) cannot be detected because the mechanical parts of the pilot valves and main valves take part in the diagnosis. The resolvers for each joint angle is expected some constant values which depend on the initial link positions. The line pressures require a certain value to hold the manipulator against gravity. The value is also dependent of the joint positions. In this diagnosis, the electrical power should be kept constant. As the Figure. 4.4 shows, the resolver values go through the R/D board to the computer, other sensor readings come into the computer through the A / D board. And the controller outputs go through the D / A board to the pilot valves. We can only get the sensor readings through those boards. And the sensor signals are also used by the on-board computer to control the manipulator. The board or the board channel condition is really important to the machine. In our diagnosis, if a channel is not working well, we should claim that the corresponding board is faulty. Assuming that not all of the sensors are faulty simultaneously, if we could not read all the sensor values through the particular board, that board is claimed a complete failure, otherwise, the abnormality of the sensor and channel is claimed.  Chapter  4.  Diagnostic  56  Algorithm  line pressure sensor spool displacement sensor pump pressure sensor pilot pressure sensor  A/D Power su  PP'y  sensor  Computer D/A  voltage sensor control value  \ Manipulator  R/D A  Joint position resolver  Figure 4.4 Interaction among Boards and Sensors  The D / A board diagnosis coupled with the corresponding A / D channels and sensors can be achieved by comparing the voltage values before sending to the pilot valves in the computer and the sensor readings of the pilot valve inputs through the A / D board and the computer. Any discrepancy would claim the sensor and channel problem. The complete board failure is declared when all of the values have a problem simultaneously. The limitation in our diagnosis coming from the electronic system structure, is that the capability of isolating an abnormal sensor reading from the faulty sensor or the faulty channel can not be achieved. The diagnostic result is coupled. The D / A board is coupled with the A / D board, any sensor is coupled to its board channel, the resolver is coupled to the R/D board. Only the complete failure of the board is not coupled if all the readings through the board are not correct and we assume only one sensor or one channel can be failed during one sampling period. The advantages of this diagnosis lie: 1.  No complicated hydraulic and dynamic model simulation is required, easy to be diagnosed in real-time  2.  No complex hardware reconfiguration is required.  4 Active Machine Diagnosis Active machine diagnosis utilizes the algorithm discussed in section 2 to achieve both real-time monitoring and diagnosis and off-time diagnosis. The algorithm consists of quantitative simulation, hypothesis generation, and model based diagnosis. Component behavior description, system structure information, and all possible  Chapter  4.  Diagnostic  Algorithm  57  observations are used in the diagnostic procedure described in section 2. Quantitative simulation is performed by the hydraulic and dynamic simulator discussed in Chapter 2 and Chapter 3. In hydraulics diagnosis, electronics diagnosis is also performed in order to assure accurate diagnosis. In our active machine diagnosis, a sensor suspect is one kind of hypothesis. Either a sensor fault of a component fault is declared in one sampling period, and the fault model is injected into the incremental model. For each diagnosis, the diagnoser will check the model to make sure that the discrepancy is due to the previous fault or not, this procedure is called discrepancy tracking. If the discrepancy cannot be tracked, new hypothesis is issued and tested. Multiple fault diagnosis is achieved during the continuous simulation and diagnosis. By analyzing the system behavior, we find the main valve decides the system performance significantly. A tiny change in either the spool displacement or the main valve orifices will affect the line pressures and the pump pressures dramatically. Line pressures' changes cause the modification of the pump pressures and the pump flows due to the load sensing behavior of the machine. The line pressure values are mostly adjusted by the orifice value. The derivative of the line pressure is altered by the joint movement and the hose fluid compliance. If the line pressure sensors are working well, any abnormal discrepancy of the line pressures should be referred back to the main valve. Sluggish movements of the joints are mostly due to cylinder leakage or orifice behavior if the pumps provide enough flow to the system.  58  5 System Design and Evaluation 1 Diagnostic System Configuration and Implementation Software and Hardware Configuration  Several functional components and multiple processors  should be considered in implementing the model-based Incremental Fault Diagnostic Algorithm discussed in the previous chapter and designing the diagnostic system. This diagnostic system is designed to have a U N I X version for algorithm test and off-line diagnosis, and a Unix-VxWorks version for real-time diagnosis based on the requirements. The software structure of the diagnostic system consists of six components: the  real machine, the monitoring and diagnosis manager, the hypothesis generator and model builder, and the incremental simulator, the diagnoser, as well as the graphical user interface as shown in Figure 5.1. 1. The real machine refers to the Caterpillar 215B. This module should include all of the sensor readings provided by the on-board computer. The software package has data acquisition and communication submodules in real time for both electronics diagnosis and active machine component and sensor diagnosis. This module is only used for real-time diagnosis. When offline data is recorded,to a file. 2. The user interface is used to display the electronics diagnostic result, the active machine diagnostic result, receive user commands and send them to the diagnoser. A figure showing this user interface is in Appendix A . R P C ( remote procedure call ) communication techniques are applied in this module to communicate the host machine to the diagnostic management system through the network. This user interface is acting as a client in terms of R P C entities. The interface is shown as Appendix A is implemented using Hoops, and can be used both for the offline version and real-time version. For the real-time system, it also consists of active machine diagnosis and idle machine diagnosis. 3. The incremental simulator described before combines all the component modules to predict the machine performance. Whenever a component or a sensor fault occurs, the corresponding fault model is injected into this simulator, which is continuously used to monitor and diagnose further multiple faults. Each module in the simulator will choose its input either from the real machine or from the previous module in the simulator 58  Chapter  5.  System Design and  Evaluation  59  based on the machine status condition. In real time diagnosis, the simulator is supposed to finish computing in one running cycle i.e. in one sampling period. In the simulator, the functional module of each separate component will select the corresponding input signal from either the real machine or the previous module's output on the dependency chain based on the machine status model which holds the previous detected fault and the current fault hypothesis. If a hydraulic component is declared faulty, that component output sefisor reading should be injected into the simulator for other component or sensor's fault detection. If a sensor is found faulty, the simulator will still use the previous module's output as the next module's input in the working chain. The current running cycle for the simulator is more than the sampling interval, to achieve real-time diagnosis, multiple processors have to be utilized in the future.  4. The hypothesis generator and model builder generates a set of hypotheses from the untracked discrepancy, each of which is an alternative interpretation of the discrepancies between the observations and the predictions. And the corresponding model is built by the model builder to mimic the machine situation and the hypothesis. The current model can be set and unset by the diagnoser and the diagnosis manager before or after the hypothesis has been confirmed. The machine current status model is used for generating a new discrepancy, producing a new hypothesis, and controlling the simulator functional module's input. The hypothesis generator is supposed to handle as many fault situations as possible. It should definitely tell a sensor fault from a component fault. It should also generate the corresponding hypothesis to detect the new multiple faults in the diagnosis, based on a new discrepancy and previous fault record if the diagnostic system had detected some faults before. In the diagnostic system, the active diagnosis hypothesis generator and model builder and the idle diagnosis hypothesis generator and model builder are used separately for the corresponding situation. The one for active diagnosis is used for both U N I X offline version and Unix-VxWorks real-time version to diagnose component and sensor faults. A reference active diagnostic algorithm and its implementation are explained in Figure 5.6 in next section. The idle diagnostic partner is given in Figure 5.7. The model builder algorithm is briefly described in Figure 5.9.  5. The diagnoser consists of active machine component and sensor diagnosis and idle machine electronics diagnosis modules. The active machine diagnosis combines the new incremental predictions and the machine  Chapter 5. System Design and Evaluation  60  observations to verify the hypothesis which is embedded in the simulator. This module should be able to set or unset the machine current status model based on the new data from the prediction and the real system whenever the hypothesis has been confirmed or not. The algorithm diagram is provided in Figure 5.8 in next section for this module. The diagnoser uses a confidence interval to threshold the difference e between the expected value y and the actual reading y  e = \y-y\  (5.1)  Where e is expected to be in a confidence interval with respect to the expected value. If the difference exceeds the confidence interval, a discrepancy is declared. Different variables have different confidence values based on the variable sensitivity in our diagnoser. For example, pump pressures and line pressures should have bigger confidence values than other variables. 6. The monitoring and diagnosis manager ( M D M ) is the key module in our diagnostic system. This module should be running in a real-time operating system to do real-time monitoring and diagnosis. It is also provided in the offline version under U N I X for the purpose of verifying the diagnostic algorithm and diagnosing the machine records. It should be able to synchronize, schedule, communicate with all the other modules. This module is also designed to handle electronics diagnosis, and the active machine diagnosis. It receives commands from the user interface and passes diagnostic results to the user interface. Since the manager and interface are running in different machines in real-time, distributed system communication technique remote procedure call (RPC) is used to send and receive messages and data between the two machines. This M D M is executed as a R P C server. It also synchronizes the machine and the simulator. It has a data acquisition submodule, iprocess scheduling and synchronization module, discrepancy detect module, and communication with remote machine module. Whenever the discrepancies between the predictions and the observations are detected, it coordinates the hypothesis generator and model builder, passes the status model and the corresponding machine readings to the simulator, e.g. injects the fault model into the simulator, and records the system situation, invokes the diagnoser with the machine and simulator information to verify the hypothesis. To achieve the functionality, multithread processing ( light weight process ) and multitasking are implemented in U N I X and  Chapter  5.  System Design and  61  Evaluation  VxWorks respectively. A n active machine diagnostic procedure and the implementation reference diagram is described in Figure 5.4 in next section, and an idle diagnostic partner is given in Figure 5.5.  Transputer  Processors  Real Machine  Incremental Simulator  Mailbox  Hypothesis Generator & , model builder!'  Monitoring Diagnostic Manager  Diagnoser  VxWorks  RPC Server^ RPC  RPC Client  SPARC Commands & Diagnostic Results  Graphical User Interface SUN (UNIX)  Figure 5.1 Software and Hardware Configuration of the Real-time Diagnostic System  Besides those machine related sensors, resolvers, on-board computer elements and the machine components, multiple computers are used in our diagnostic system for real-time diagnosis. One computer is used as a host to run the user interface under U N I X and communicates with the machine which runs the monitoring and diagnostic management system. Multiple processors are definitely needed to run the simulator and other diagnostic modules in order to satisfy time requirements. The desired real-time software and hardware configuration of the diagnostic system is shown in Figure 5.1. Relationships among the software modules are described as before. The real-time monitoring and diagnostic system is a distributed real-time network application with multiple machines running under different operating systems and communicating through the local network. The hardware processors are referenced in Figure 5.1 The offline U N I X version is provided first to verify the correctness of the diagnostic algorithm. This U N I X version can be running in a single workstation or a couple of machines. Most of the modules are quite similar  Chapter  5.  System Design and  Evaluation  62  to the real-time active machine diagnosis version except for the monitoring and diagnostic manager which is required to synchronize and schedule processes using system calls. We use the light weight process (thread ) in U N I X and the multiple tasks in the real-time operating systems — VxWorks to execute parallel processes. The real machine module is replaced by the recorded data resource. A l l the system components are implemented in C. A figure showing the user interface is in Appendix A . This software package is coded as an application of the 3-D graphical software package "Hoops" and is a client of R P C communication technique Communication Techniques The communication techniques used in the real-time diagnostic system are shown in figure 5.1. A Remote Procedure Call ( R P C ) is used for the G U I ( as a client) to send commands to the diagnostic management system ( as a server) and get the diagnostic results from the latter. A mailbox is used for the communication between the diagnostic manager and the real machine. Real-Time Consideration The real-time monitoring and diagnostic system should be running under realtime operating systems to achieve real-time multitask scheduling and synchronization. The simulator is the bottleneck in the diagnostic system. It is programmed to be suitable for any sampling frequency for the real machine. But the running time in one cycle is 3-4 times more than the interval of 50 hz sampling rate. Multiprocessors are needed to run the simulator in real-time.  Chapter  5.  System Design and  63  Evaluation  I n c r e m e n t a l  M a c h i n e D a t a  S i m u l a t o r  H y p o t h e s i s Generator & m o d e l b u i l d e r i  M o n i t o r i n g D i a g n o s t i c M a n a g e r  D i a g n o s e r  Graphical U s e r Interface  Figure 5.2 Offline Diagnostic System Configuration  2 Software Module Interface and Interrelationship Each module in the software structure provides its interface i.e. functions to other modules. All the modules combine together to give the system integrity. The real-time diagnostic system consists of the most complicated modules and functions. We can use Figure 5.3 to show the module interface and the interrelationship among those files and functions  Chapter  5.  System Design and  64  Evaluation  Machine  /* simulator.c */ w  initsimulator() simulatorQ  /* io.c 7 sendVoltToT800() /* Simulator.c */ functions  idleReadDataFromT800() activeReadDataFromT800()  for idle  for active  /* idlediag.c */  /* hypogen.c */  getSimuO  hypogen() hypbgetO  /* VxWorks */  idlelnitiate()  hyporemove()  realmanager.c  getlnitPosO  msg_xdrvw.c  getController()  /* UNIX 7 manager.c  hypoidleremove()  /* diagnoser.c */ discrepancyQ  getidlemodelO setidlemodel()  /* model.c 7 initmodel() setmodelO unsetmodel() getmodelQ  unsetidlemodelO /* realmanager.c 7 /* or msg_svc. c 7 msgprog_1 () rundiag_1() idlemsgget_1 () activemsgget_1 ()  idlehypogetO hypoidleremove() idleDispTest() idleDiagnose()  /* controlFunc.c 7 comdRPC-0 readActiveMsg() readldleMsg() msg_xdr.c msg_clnt.c  /* Unix Interface 7 hoopgra.c  Operator  Figure 5.3 Module Interface and Interrelationship  File hypogen.c is used to generate or remove hypotheses based on discrepancy. The interface of this file includes hypogen(), hypoget(), hyporemove(). Those functions can be called by realmanager.c in VxWorks and  Chapter  5.  System Design and  65  Evaluation  manager.c in Unix for active component and sensor fault test. This file belongs to the hypothesis generating and model building module. File model.c is aimed at setting up or modifying the system status model with the interface of initmodel(), setmodel(), unsetmodel(), getmodel() which are used for the component and sensor fault diagnosis. This file belongs to the hypothesis generating and model building module. File diagnoser.c is used to monitor the discrepancy between the simulator and the real machine and prove the hypothesis. This file belongs to the diagnoser module. File io.c's functions are used to get sensor readings from the machine and send control signals to the board for idle diagnosis. This file belongs to the real machine module. File simulators consists of the hydraulic and dynamic functional modules and provides the initsimulator(), simulator() interface to the diagnostic manager. It also provides a bunch of functions to the getSimu() function in file idlediag.c to calculate the expected steady state parameter values given a control signal. The function simulator() calls getmodel() to get the current system status model to select each module's input and give the simulation prediction to the realmanager or manager. This file belongs to the simulator module in the software configuration. File idlediag.c is used for idle electronics diagnosis.  The interface to the realmanager provides the  functionality of hypothesis generating and model building, idlediagnoser modules. This file uses the simulator once to get the steady state value to be used for the whole diagnosis period if given an unchanged control input value. The steady values of the simulation result given an input value are used as reference values for the sensor and board diagnosis. File realmanager.clmanager.c are used to manage the diagnostic system in VxWorks or U N I X respectively which coordinates all other modules' behavior. The general flow diagram of active machine diagnosis is shown in Figure 5.4. In this diagram the function is invoked by the user interface by sending a command to it. It first reads the initial joint angle and initializes the simulator and sets the system current status model to fault free value. If no termination command comes in or no problem happens in the monitoring and diagnosis process, it will keep  Chapter  5.  System Design and  Evaluation  66  running. In the process the function reads sensor readings from the real machine or from the data record, then gets the system status model, passes the sensor readings and model to the simulator, gets the simulation result. Then it checks the discrepancy between the predictions and the machine readings,^ and sees if the discrepancy found has been tracked or not, i.e the discrepancy can be explained by a fault previously detected or not. When an untracked discrepancy exists in the system, it continues the diagnostic procedure. The system generates hypotheses based on the discrepancy and the system current status model, then proves the hypotheses one by one. The confirmation procedure is executed by setting the suspect fault item value in data structure of the system model, then simulating the new model, checking the discrepancy between the new model prediction and the machine reading to prove the hypothesis. When a hypothesis is confirmed, the simulator current parameter values and the model should be set. Since the simulator runs in a continuous dynamic condition, its value should be carefully used in the pure simulation procedure and the hypothesis test procedure. This problem is solved by using dual data values in the simulator. The hypothesis test value will be assigned to the simulation value for further simulation or test if the hypothesis is confirmed true. The idle machine diagnostic flow diagram is much similar to the real machine's except for some steps as shown in Figure 5.5. The diagnostic manager should send the control input value to the target machine, run the simulator once using the input signal and machine initial joint position value. In the simulation, a transient state is not considered, only the steady state value is calculated to be used for the whole diagnostic procedure if the control input value is not changed. This step is used to get the expected reference variable value no matter what input control signal and machine initial position are given. Then the diagnostic procedure will use the reference values and the machine readings to detect any electronics problem. The major difference between the active diagnostic and idle diagnostic procedures is that the idle diagnosis uses the simulator only once. When hypotheses are generated, they, do not need further confirmation or require new simulation. Idle diagnosis is generally based on the discrepancy between the reference value and the machine reading, as well as the idle machine current status model.  Chapter  5.  System Design and  67  Evaluation  start  read initial data from machine or file activeReadDataFrom800() / fopen/fscan  initialize simulator & model initsimulatorO & initmodelQ  read real machine data activeReadDataFromT800() get current model run simulator getmodelQ & simulatorQ & discrepancy^)  discrepancy^ untracked.  generate fault hypothesis hypogenQ  ^hypothesis # ==JTL  f -nget hypothesis & set model hypogetQ & setmodel()  simulate new model simulatorQ & discrepancyQ  n  unset model unsetmodelQ  confirm model & simulator simulator(APRO) &  f  hyporemoveQ  =  save result saveactivemsgO & savediagresult()  Figure 5.4 Active Machine Diagnosis Program Flow Diagram  Chapter 5. System Design and Evaluation  ' j •  start  68  /  T  :  get initial position & initialize model, simulator getlnitPosO & idlelnitiate() T  get controller & send control value to machine getControllerQ & sendVoltToT800()  get controller & send control value to machine getControllerQ & sendVoltToT800()  t  read data , test discrepancy idleReadDataFromT800() & idleDispTest()  generate fault hypothesis idleDiagnoseQ ?  y  T_n get idle hypothesis idlehypogetO .  1  :  Y _  set diagnostic model setidlemodelQ  •  clear hypotheses hypoidleremove()  • save diagnostic result getidlemodelQ & setidlemsgO  Figure 5.5 Idle Machine Diagnostic Program Flow Diagram  . .  The intelligent core or key part of this fault diagnostic system is the hypothesis generation. Hypothesis  Chapter 5. System Design and Evaluation  69  generation is a process which generates the suspect fault component hypothesis based on the system current status model and the newly detected discrepancy of observation with respect to prediction. This is a rule-based machine-dependent process which consists of a collection of logical facts. All the judgements are logically and artificially deduced from the system behavior and the dependency chain. The algorithm for active machine diagnosis is briefly shown as Figure 5.6. The illustration may not.be complete from the point of viewing human thinking. In the diagram, loop means the interactional functionality from level 3 to level 5 as shown in Figure 2.5, ptpres means pilot pressure, spool means spool displacement in a short.  Active diagnostic algorithm Inputs: discrepancy, subsystems to be detected Output: number of hypotheses, hypotheses of fault mode, subsystem id, item id { get system current status model; getmodel(); /* to test if a discrepancy is tracked or not */ /* check system problem */ if discrepancy happens everywhere in the system declare the system fault, like an A/D board, power, computer failure, return fault number; else begain checking subsystem component / sensor fault; for each subsystem to be tested do { if voltage discrepancy if both pilot pressure & spool displacement discrepancy II other discrepancy if no D/A channel problem declared before, it might be a new voltage D/A channel problem, return; else if neither pilot pressure nor spool displacement discrepancy, only the voltage discrepancy if untracked, it might be a new A/D voltage channel (voltage sensor) problem, return; if only voltage & pilot pressure discrepancies if one discrepancy is untraced & another is tracked, it might be the untracked point problem, return; if only voltage, pilot pressure & spool discrepancies if only discrepancy is untracked, other two are tracked, it might be the untracked point problem, return; else if ptpres discrepancy /* no voltage discrepancy */ if ptpres, spool, & loop discrepancies, it might be the pilot valve component problem, return; if only ptpres discrepancy, it might be ptpres sensor problem, return; if only ptpres & spool discrepancies, no other discrepancy Figure 5.6  Algorithm for Active Machine Diagnosis  (Continued) . . .  Chapter 5. System Design and Evaluation  70  if one discrepancy is untracked & another is untracked, it might be the untracked point sensor problem, return; else i f spool discrepancy /* no voltage & ptpres discrepancies */ i f all other loop discrepancies, it might be the spool component problem, return; if only spool discrepancy, it might be the spool sensor problem, return; else /* no discrepancy before spool sensor on the dependency chain , check the loop only */ i f one untracked pump discrepancy, any other tracked discrepancy / no discrepancy at other comparision points in the loop, it might be the pump pressure sensor problem, return; i f one untracked line pressure discrepancy, any other tracked discrepancy / no discrepancy at other comparision points in the loop, it might be the line pressure sensor problem, return; i f one untracked joint angle discrepancy, any other tracked discrepancy / no discrepancy at other comparision points in the loop , it might be the joint resolver problem, return; if all untracked discrepancies happen in the loop, this is the complex component failure situation, multiple component fault hypotheses for pump, main valve, cylinder are generated, return; }  ,  /* handle unrelated situations, like tracked ptpres ( any tracked discrepancy outside of the loop ) will not affect untracked loop discrepancy, these cases are not described above */ i f one of the pumps discprepancy, no other discrepancy in the loop, & the discrepancy is untracked, it might be a new pump sensor problem, return; if one of the line pressure discprepancy, no other discrepancy in the loop, & the discrepancy is untracked, it might be the new line pressure sensor problem, return; if the joint angle discprepancy, no other discrepancy in the loop & the discrepancy is untracked, it might be the new joint resolver problem, return; i f all voltage discrepancies, no sensor failure & no D/A board failure before, it might be a new D/A board problem, return; if all joint angle discrepancies, no resolver failure & no R/D board failure before, it might be a new R/D board problem, return; } Figure 5.6 Algorithm for Active Machine Diagnosis  Figure 5.7 shows the idle machine diagnostic algorithm. In idle machine diagnosis, most of the sensors can be diagnosed independently if the level 3 to level 5 hydraulics and dynamics in Figure 2.5 keep constant.  Chapter 5.  71  System Design and Evaluation  Level 1 and level 2 hydraulics is coupled with the sensor diagnosis somehow. For idle diagnosis, we suppose that multiple faults are able to happen simultaneously in the system. So the test in a sampling period may give more than one hypotheses.  Further hypothesis approvement is not required in the diagnostic manager  for idle diagnosis comparing to active machine diagnosis since idle machine diagnosis is aimed at diagnosing electronics faults only and a sensor or board fault will not affect the simulation's prediction, so new simulation will not result in new discrepancies comparing to the current time machine reading. Remember that all of the rules in 5.6 and 5.7 may not be complete. The logical order and the correctness of those rules need further verification.  Idle diagnostic algorithm Inputs: discrepancy, joints to be detected Output: number of hypotheses, fault mode, subsystem id, item id of hypothesis { get system current status model, getidlemodel(); /* to test if a discrepancy is tracked or not */ if discrepancy happens everywhere in the system /* check system problem */ declare system fault, like an A / D board, power, computer failure, return fault number; else begain checking subsystem component / sensor fault; for each subsystem do { if voltage discrepancy if no pilot pressure & spool displacement discrepancies & voltage discrepancy is untracked, it might be a new voltage channel problem; if only voltage & spool discrepancies if either one of them is untracked, another is tracked, it might be the untracked point problem; if both of them are untracked, all of them might have problems; if only voltage & pilot pressure discrepancies if either one of them is untracked, another is tracked, it might be the untracked point problem; if both of them are untracked, all of them might have problems; if only voltage, pilot pressure & spool discrepancies if one of the discrepancies is untracked, others are tracked, it might be the untracked point problem; if voltage is tracked, others are untracked, it might be the two sensor's problem, or might be the pilot valve's problem; Figure 5.7  Algorithm for Idle Machine Diagnosis  (Continued) . . .  Chapter 5.  System Design and Evaluation  72  else if one of ptpres and spool is tracked, others are untracked, it might be the two sensor's problem; else if all of them are untracked, it might be the D/A channel's problem; else if ptpres discrepancy /* no voltage discrepancy */ if only ptpres discrepancy & untracked, it might be the ptpres sensor's problem; if ptpres & spool discrepancies only if one of them is untracked, the other is tracked, it might be the untracked point problem; if all of them are untracked, it might be two sensors' problem, or pilot valve's problem; else if spool discrepancy /* no voltage & ptpres discrepancies */ if this discrepancy untracked, it might be a new sensor problem; if any line pressure discrepancy & untracked, it might be a new sensor problem; if joint angle discrepancy & untracked, it might be a new resolver problem; }  if any pump discrepancy & untracked, it might be a new pump pressure sensor problem; if all voltage discrepancies & not all tracked & ho previous D/A board problem was declared, it might be a new D/A board problem; if all resolver discrepancies & not all tracked & no previous R/D board problem was declared, it might be a new R/D board problem; } Figure 5.7 Algorithm for Idle Machine Diagnosis  The diagnoser uses straightforward range checking algorithm to check if the sensor reading is in the range of the quantitative incremental simulator's prediction or not. Variant variable confidence range levels are selected since the acceptable range for each variable is different from each other according to the sensitivity analysis for a particular parameter. The algorithm is shown in Figure 5.8.  Diagnoser algorithm Input: sensor reading, simulation prediction Output: discrepancies {  initialize all discrepancy values to 0; for each subsystem do { for each parameter do { Figure 5.8  Quantitative Range Checking Algorithm  (Continued) ...  Chapter 5.  System Design and Evaluation  73  if real reading is out of simulation prediction range discrepancy flag for this parameter is true, increase the total discrepancy number; else if system status model shows this sensor a previous failure state, remove the failure state this time;  } } }  Figure 5.8 Quantitative Range Checking Algorithm  The model builder sets / unsets the fault item value in the system current status model, or raises / sets down a flag for the suspect fault item according to the fault hypothesis generated by hypothesis generator and hypothesis confirmation result. For implementation, the model is a data structure held by the model builder module, while each variable in the data structure reflects the corresponding physical item's fault state, flag 1 represents failure, 0 represents O K . We consider three types of faults in our system: system faults, hydraulic component faults, and sensor faults. System faults refer to board, power, computer failures in particular. A . brief diagram shows the algorithm in Figure 5.9.  Model builder algorithm for setmodel() / unsetmodel() Input: fault mode, subsystem id, item id for each hypothesis Output: n/a { switch fault mode { case sensor fault: set / unset the corresponding item value in the data structure to 1 / 0; break; case component fault: set / unset the corresponding item value in the data structure to 1 / 0; break; case system fault: set / unset the corresponding system item value in the data structure to 1 / 0; break; } }  Figure 5.9 Incremental Model Builder Algorithm  3 Algorithm Test and Evaluation The model-based diagnostic system has been implemented and tested under the offline U N I X environment. Some artificial fault signals ( only fault sensor information now ) of the real machine have been recorded and run by the diagnostic system. We consider the capability to test both single fault and multiple faults. We  Chapter 5. System Design and Evaluation  74  do the test using open loop system data and begin the test procedure when both the simulator and the real machine signals reach the steady state. The test results show that our diagnostic algorithm can handle both single fault and multiple faults.  Single Fault Test  We test the single artificial A/D voltage channel (the stick voltage channel) fault with  either a step input or a ramp input to the real machine. The test joint is "Stick". For the step input the real machine readings and the simulation results are shown in Figure 5.10  (b)  (a)  l/0:lnput"_",Ang(R)"_",Ang(S)"—"  50  CD  J Fault Input  CD  T3  0) O) c: <  u -50  LJF^L_^ I  __l I  Real Input i i 1  ' T  Angle (S,)  cu  cn-100 CO  o > -150  J  j • 'j'i i r  Angle (JR) i i  i  i  i  P_ijotPres:(R)"+",(S)"_"& Splxl .e+3:(R)"_",(S)"—" •5 400 ^  o  Sdool(S) i j kpool ( FJ)  8 300h-  o o  *-"^™-<~»~~y  #200h-^-^  •  CO  Pilot P ( S )  § 100 tn co  £  0  CL  I  1  time (sec)  2 time (sec)  3  LinePres:(R)Hd"+",Rod"_",(S)Hd"_",Rod"—" 2000 % [Head P { R )  PumpPres:(R)P1"+",P2"_".(S)P1"_".P2" 3000  r  , i « c o h - . ; ] - / CO Q,  I CO  <  H e a t , p ,  10001—^  2 time (sec) (c) (S)  : Simulation  4  ( R ) : Real Machine  Figure 5.10 Single Sensor Fault Diagnosis  -  S )  -  Chapter  5.  System Design and  75  Evaluation  The fault reading of the voltage output to the joint "Stick" (joint number 2 ) is double of the real input, and all of other readings are correct. Part of the diagnostic result recorded for this situation is shown as following: ( in all the following results, 1 means problem, 0 means ok. Joint 0, 1, 2, 3 means "cabin", "boom", "stick", and "bucket" respectively ). Table 5.1 gives the discrepancy result between the simulator predictions and the real machine data in the artificial "stick" joint voltage channel fault situation. Table 5.1 True Voltage Channel Fault Situation  joint (i)  pump  Spool  Pilot  HeadP  Volt Pres  Disp  RodP  pump2  Angle 1  Cabin  0  0  0  0  0  0  Boom  0  0  0  0  0  0  Stick  1  0  0  0  0  0  Bucket  0  0  0  0  0  0  0  0  The system component and sensor diagnostic result is shown in Table 5.2: Table 5.2 Diagnostic Result from the Voltage Channel Fault Situation  Volt  Pilot P  Spool  HeadP  RodP  Angle  Pumpl  Pump2  1  0  0  0  0  0  0  0  Compo  PilotV  Spool  MainV  Cyl  Purripl  Pump2  nent  0  0  0  0  0  0  Com_  A/D  D/A  R/D  Power  Cmpt  puter  0  0  0  0  0  Volt  Pilot P  Spool  HeadP  RodP  Angle  Pumpl  Pump2  1  0  0  0  0  0  0  0  Compo  PilotV  Spool  MainV  Cyl  Pumpl  Pump2  nent  0  0  0  0  0  0  Com_  A/D  D/A  R/D  Power  Cmpt  puter  0  0  0  0  0  Sensor time 1.020 sec  Sensor time 1.040 sec  Chapter 5.  System Design and Evaluation  76  In this diagnostic result, the first part shows the discrepancy between the sensor readings and the simulator predictions, and the second gives the diagnostic result of sensors, hydraulic components, and boards, etc. We can see only one discrepancy exists ( e.g. the stick voltage ), and the voltage channel for the stick joint is declared faulty. We also test the single sensor fault with a ramp voltage input instead of the step input. The expected diagnostic result is obtained as the same as the result shown above.  Multiple Sensor Fault Test  We suppose only one fault can happen in a sampling interval. So multiple  fault diagnosis means if a fault happens in the system already, the diagnostic system can detect other faults which may happen later. Due to the capability of the algorithm and the previous fault information held by the current model, multiple sensor faults can be distinguished by checking the current sensor and component conditions from the system status model to generate fault hypotheses based on the new discrepancies. The detail is implemented in the hypothesis generator. The algorithm is tested by the multiple sensor fault situations. The artificial faults are produced to the pump pressure and the line pressure sensors. We can handle the multiple fault situation in two ways. Firstly, we read only one sensor fault this time, and read another fault next time, after we finish this round robin cycling we go back to the first fault again, all the other readings are correct each time. This is much like the single fault problem but handling different fault sensors each time. The discrepancy situation is shown in Table 5.3 and the system diagnostic result is in Table 5.4 . Table 5.3 True Multiple Sensor Fault Situation  Pilot Time  joint (i)  Spool  Head RodP  Volt Pres  Disp  P  pump  pump  1  2  1  0  Angle  Cabin  0  0  0  0  0  0  1.100  Boom  0  0  0  0  0  0  sec  Stick  0  0  0  0  0  0  Bucket  0  0  0  0  0  0  Chapter 5.  77  System Design and Evaluation  Table 5.3 (Continued)  True Multiple Sensor Fault Situation  Cabin  0  0  0  0  0  0  1.120  Boom  0  0  0  0  0  0  sec  Stick  0  0  0  0  0  0  Bucket  0  0  0  0  0  0  Cabin  0  0  0  0  0  0  1.140  Boom  0  0  0  0  0  0  sec  Stick  0  0  0  1  0  0  Bucket  0  0  0  0  0  0  Cabin  0  0  0  0  0  0  1.160  Boom  0  0  0  0  0  0  sec  Stick  0  0  0  0  1  0  Bucket  0  0  0  0  0  0  0  1  0  0  0  0  Table 5.4 Diagnostic Result from the Multiple Sensor Fault Situation  Volt  Pilot P  Spool  HeadP  RodP  Angle  Pumpl  Pump2  -0  0  0  0  0  0  1  0  Compo  PilotV  Spool  MainV  Cyl  Pumpl  Pump2  nent  0  0  0  0  0  0  Com_  A/D  D/A  R/D  Power  Cmpt  puter  0  0  0  0  0  Volt  Pilot P  Spool  HeadP  RodP  Angle  Pumpl  Pump2  0.  0  0  •0  0  0  0  1  Compo  PilotV  Spool  MainV  Cyl  Pumpl  Pump2  nent  0  0  0  0  0  0  Com_  A/D  D/A  R/D  Power  Cmpt.  puter  0  0  0  0  0  Sensor time 1.100 sec  Sensor time 1.120 sec  Chapter 5.  System Design and Evaluation  Table 5.4 (Continued)  1.140 sec  Pilot P  Spool  HeadP  RodP  Angle  Pumpl  Pump2  0  0  0  1  0  0  0  0  Compo  PilotV  Spool  MainV  Cyl  Pumpl  Pump2  nent  0  0  0  0  0  0  Com_  A/D  D/A  R/D  Power  Cmpt  puter  0  0  0  0  0  Volt  Pilot P  Spool  HeadP  RodP  Angle  Pumpl  Pump2  0  0  0  0  1  0  0  0  Compo  PilotV  Spool  MainV  Cyl  Pumpl  Pump2  nent  0  0  0  0  0  0  Com_  A/D  D/A  R/D  Power  Cmpt  puter  0  0  0  0  0  Sensor time 1.160 sec  Diagnostic Result from the Multiple Sensor Fault Situation  Volt  Sensor time  78  From the result we can see that during each sampling interval a new sensor fault has been detected. Secondly, we use a fault adding scheme which keeps adding a new fault to the readings each time until the reading cycle is done, i.e, at the first reading, read one sensor fault only, at the second time, read two sensor faults which include a old fault and a new one, at the third time, read three with two old ones and a new fault, and so on. After the cycle, we start reading from zero fault to one fault, then two, then three, etc.. So in each time a new sensor fault reading is added to the diagnostic system. The system is supposed to test the new fault although it has some faulty sensors in the machine already. Based on the capability of the hypothesis generator and the system status information model which holds all the previous fault information in it, this situation can be detected correctly. The real machine readings and the simulator predictions are shown in Figure 5.11.  Chapter 5. System Design and Evaluation  79  (b)  (a)  J'ilotPres:(R)"+ ,(S)"_"& Splxl .e+3:(R)"_",(S)"—" -g 6001 • • Spool ( $ ) |  l/0:lnput"++",Ang(R)"_",Ang(S)"—" 50  ,,  CJ)  o  CD  33  §  0 lnp(jt  cn  < ~  o  ra-100  o >  -150  r . 7-r-^~ _  —f-  i  Angle (|S) i h-1 • c - i - * - Angle (i R  ,>  j  0  Spool ( R )  o  1  -50  400  CO  |  Vf-----  2 -200 °0  3  i -4  Pilot P ( R )  CO CO  i  1 2 time (sec)  0  Pilot P ([S )  1 2 time (sec)  LinePres:(R)Hd"+",Rod"_",(S)Hd"_",Rod"—" 3000 [  PumpPres:(R)P1"+",P2"_",(S)P1"_",P2" 4000 a. 3000  P1 & P2 ( S ) -1000  1 2 time (sec)  (c) (S) : Simulation  (R) : Real Machine  Figure 5.11 Multiple Sensor Fault Simulation and Diagnosis  The discrepancy and the multiple sensor fault diagnostic result can be seen from Table 5.5 and Table 5.6 Table 5.5 True Multiple Sensor Increased Fault Situation  Time  joint (i)  Pilot  Spool  Head  Pres  Disp  P  Volt  RodP  Angle  Pumpl  Pump2  1  0  Cabin  0  0  0  0  0  0  1.100  Boom  0  0  0  0  0  0  sec  Stick  0  0  0  0  0  0  Bucket  0  0  0  0  0  0  Chapter  5.  System Design and  80  Evaluation  Table 5.5 (Continued)  True Multiple Sensor Increased Fault Situation  Cabin  0  0  0  0  0  0  1.120  Boom  0  0  0  0  0  0  sec  Stick  0  0  0  0  0  0  Bucket  0  0  0  0  0  0  Cabin  0  0  0  0  0  0  1.140  Boom  0  0  0  0  0  0  sec  Stick  0  0  0  1  0  0  Bucket  0  0  0  0  0  0  Cabin  0  0  0  0  0  0  1.160  Boom  0  0  0  0  0  0  sec  Stick  0  0  0  1  1  0  Bucket  0  0  0  0  0  0  1  1  1  1  1  1  Table 5.6 Diagnostic Result from the Multiple Sensor Fault Situation  Volt  Pilot P  Spool  HeadP  Rod P  Angle  Pumpl  Pump2  0  0  0  0  0  0  1  0  Compo  PilotV  Spool  MainV  Cyl  Pumpl  Pump2  nent  0  0  0  0  0  0  Com_  A/D  D/A  R/D  Power  Cmpt  puter  0  0  0  0  0  Volt  Pilot P  Spool  Head P  Rod P  Angle  Pumpl  Pump2  0  0  0  0  0  0  1  1  Compo  PilotV  Spool  MainV  Cyl  Pumpl  Pump2  nent  0  0  0  0  0  0  Com_  A/D  D/A  R/D  Power  Cmpt  puter  0  0  0  0  0  Sensor time 1.100 sec  Sensor time 1.120 sec  Chapter 5. System Design and Evaluation  Table 5.6 (Continued)  1.140 sec  Pilot P  Spool  HeadP  RodP  Angle  Pumpl  Pump2  0  0  0  1  0  0  1  1  Compo  PilotV  Spool  MainV  Cyl  Pumpl  Pump2  nent  0  0  0  0  0  Com_  A/D  D/A  R/D  Power  Cmpt  puter  0  0  0  0  0  Volt  Pilot P  Spool  HeadP  RodP  Angle  Pumpl  Pump2  0  0  0  1  1  0  1  1  Compo  PilotV  Spool  MainV  Cyl  Pumpl  Pump2  nent  0  0  0  0  0  0  Com_  A/D  D/A  R/D  Power  Cmpt  puter  0  0  0  0  0  Sensor time 1.160 sec  Diagnostic Result from the Multiple Sensor Fault Situation  Volt  Sensor time  81  .  0  From the result we can see that the diagnostic system detects a .new sensor fault at each new sampling time and shows current fault status of the real system. Another multiple sensor fault test is done to the pilot pressure and the spool displacement sensors. And the test which is eliminated here also gives us the correct result based on the implementation in the diagnostic system. From all the above tests we can say that the diagnostic algorithm does have the capability to detect the single fault and multiple faults correctly. Because of the unavailability of component fault, the implementation has not been tested for a hydraulic component fault of the real system.  82  6  Discussion and Conclusion  1 Discussion and Conclusion The major contributions over the existing state of the art are: 1.  Modelling, simulation, and validation test for the hydraulic machine  2.  Design, implementation and testing of a new model-based performance monitoring and fault diagnostic algorithm (IFDA) Based on two Ph.D. theses, we remodelled part of the hydraulic controlled machine and rewrote the simulator  to meet the diagnosis requirements.  Generally speaking, the hydraulic machine is modelled based on the  component behavior and system structure. The pilot valve model, the main valve spool displacement and orifice models are independent modules in the system model and built based on experimental data and system response. Each component's behavior in the system is described by a functional module and the modules are linked up as shown in Figure 2.5 system working mechanism. Those modules are implemented into functions with the corresponding input and output. To implement the simulator, the general simulation techniques used in [27] are also applied here. The secant method is used to solve the unknown internal pressure given the hydraulic flow function and external pressure in the main valve model, and the fourth-order Runge-Kutta technique is used for simulation in the time domain. For each hydraulic component, its deadband behavior is modelled and implemented in the simulator. The deadband behavior is carefully used to test the sensor and other electronics performance in the system. The response time for each component and the time-delay have been considered and implemented to match the real system's response. The simulator is implemented to be suitable to any sampling rate which is less than 100 hz. The simulator has been tested using the recorded real machine data for link "Boom", "Stick", "Bucket" respectively. The test result shows the simulation prediction can agree with the real machine reading given the same input. So we can declare that the simulator can perform like the real machine and can further be used as the reference in the model-based fault diagnosis.  Chapter  6.  Discussion  and  Conclusion  83  The model-based fault diagnosis algorithms are reviewed both in the engineering control community and computer science artificial intelligence group. A diagnostic algorithm based on behavior and system structure model has been proposed in this thesis. A n Incremental Fault Diagnostic Algorithm proposes a fault hypothesis when the new untracked discrepancy between the simulator prediction and the real machine observation happens. After the fault hypothesis is proposed, the simulator is rebuilt, the fault component mode is injected into the incremental simulator, then the new result is used to prove the, hypothesis.  After the confirmation of the  hypothesis, the fault component is combined into the system status model to represent the machine current state which retains all the previous fault information, which is in turn used to monitor and detect further failures. The key point is that we let the simulator mimic the faults which happen in the real system all the time. So the simulator will always represent the real system condition. This feature can be utilized to detect any further unanticipated faults at run-time and save the necessity of building up any predefined fault model as the algorithms in the control community do. This algorithm provides the capability of detecting both component fault and sensor failure unlike most of the algorithms in control and AI groups, which build separate complex models for component faults and sensor faults. In our algorithm the sensor fault is treated as a special case unlike the algorithms in control community which set up different models and use variant techniques for sensor fault detection and component fault detection individually. Based on the system deadband behavior, we also propose the algorithm or technique to test electronics fault in the machine when the machine is idle, such as the computer board and sensor problems. In this case, the complex dynamic and hydraulic simulation and tedious hardware reconfiguration are not required. Multiple processors are not required to achieve the real-time simulation here. The real-time monitoring and fault diagnosis requirement is analyzed. The diagnosis system scheme is proposed in this thesis according to real time requirements. The main frame of the diagnostic system has been implemented both under Unix for offline test and under VxWorks for real-time monitoring and diagnosis. The software and hardware configuration is discussed in the previous chapter. Both single fault detection or multiple fault diagnosis, and sensor fault diagnosis or component fault detection algorithm is implemented in the diagnostic system. Offline single fault diagnosis and multiple fault diagnosis  Chapter 6. Discussion and Conclusion  84  are tested under Unix environment using the artificial fault data from the real machine. For the single fault, we test the voltage channel problem using either a step input or a ramp input. For the multiple faults, we test the line pressure and pump sensor faults either with only one fault reading or with one increased fault reading in each sampling period both in a round robin fashion. We also test the multiple pilot pressure and spool displacement sensors' faults. The correct test results prove that the Incremental Fault Diagnostic Algorithm is feasible in some cases.  2 Recommendation for Further Work Because of the insufficiency of the sensors installed in the machine, like the lack of the spool displacement sensor, and the limitation of the processor power, which is in conflict with the speed requirement of the realtime simulator, the whole real-time diagnostic system has not been completed implemented and tested under the Unix-VxWorks environment. The component fault test is not done due to short of the component fault data. For implementing a completed real-time performance monitoring and fault diagnosis system, the following further work is recommended: 1.  More precise friction modelling for each joint, especially for the joint "Cabin"  2.  Further fault mode and effect analysis and further hypothesis generation implementation, further test, especially the component fault test  3.  Parallel implementation of the simulator to satisfy the critical time requirement for real-time diagnosis. One running cycle time of the simulator is currently 5.00e-2 sec on S U N SPARC which should be decreased to less than 1.00e-2 sec  4.  Real-time diagnostic system integration, which refers to the synchronization of the diagnostic manager, the real machine, the simulator, and the graphical user interface,  5.  Optimization or refinement of this Incremental Fault Diagnostic Algorithm like decoupling the diagnostic results, for example the sensor and board coupling in idle machine diagnosis, the component coupling in the loop of level 3 to level 5 in active machine diagnosis.  85  Appendix A Diagnostic System Graphical User Interface  ir X -2 © 5; 2.8 q  >  7  z  ^  o  I  u  o -^0  2i G  Q.  o o o  C ao a ™ i  Xi  >  >  >  s 4J  g.1  a. E o U  [ "r/y j  D  a  5 >  1\  •8 i  V  *  \  86  Bibliography  [I]  M . Basseville. Detecting changes in signals and systems — a survey. Automatica , 24(3):309-326,  [2]  Enrico W. Coiera. Qualitative superposition. Artificial Intelligence , 56:171-196, 1992.  [3]  Randall Davis. Retrospective on "diagnostic Intelligence , 59:149-157, 1993.  reasoning  based on structure  1988.  and behavior". Artificial .  [4]  Randall Davis and Hamscher. Artificial Intelligence , chapter 8, page 297 — 345. 1991.  [5]  Johan de Kleer and Brian C. Williams. Diagnosing multiple faults. Artificial Intelligence , 32:97-130, 1987.  [6]  John de Kleer, Alan K. Mackworth, and Raymond Reiter. Characterizing diagnoses and systems. Artificial Intelligence , 56:197-222, 1992.  [7]  Peter Drans field. Hydraulic Contr ol Systems — Design and Analysis of their dynamics . Springer-V erlag,  1981. [8] [9]  Daniel Dvorak. Process monitoring and diagnosis — a model-based approach. IEEE Expert, pages 67-74, 1991. P. K. Fink and J. W. Lusth, J. C. an Duran. A general expert system design for diagnostic problem solving. IEEE Transactions on Pattern Analysis and Machine Intelligence , PAMI-7(5):552-560,  1985.  [10] Paul M . Frank. Fault diagnosis in dynamic system using analytical and knowledge-based redundancy — a survey and some new results. Automatica , 26(3):459-474, 1990. [II] Janos J. Gertler. Survey of model-based failure detection and isolation in complex plants. IEEE Control Systems, pages'3-11, December 1988. [12] Rolf Isermann. Process fault detection based on modelling and estimation methods — a survey. Automatica , 20(4):387-404, 1984. [13] Rolf Isermann and B. Freyermuth. Process fault diagnosis based on process model knowledge — part 1 . principles for fault diagnosis with parameter estimation. Journal of Dynamic Systems, Measur ement, and Control, 113:620-626, December 1991. [14] Rolf Isermann and B. Freyermuth. Process fault diagnosis based on process model knowledge — part 2 . case study experiments. Journal of Dynamic Systems, Measurement, and Control, 113:627-633, December 1991. [15] Benjamin Kuipers. Commonsense reasoning about causality: Deriving behavior from structure. Artificial Intelligence , 24:169-203, 1984. [16] Benjamin Kuipers. Qualitative simulation. Artificial Intelligence , 29:289-338, [17] F. Lackinger and W. Nejdl. Diamon: A model-based troubleshooter  1986.  based on qualitative reasoning. IEEE  Expert, pages 33-40, February 1993. [18] Herbert E. Merritt. Hydraulic Control Systems . Wiley, 1967. [19] Hwee Tou Ng. Model-based, multiple-fault  diagnosis of dynamic, continuous  physical devices. IEEE  Expert, pages 38-43, December 1991. [20] Katsuhiko. Ogata. Discrete-Time Control Systems , chapter 4. Prentice-Hall, 1987. [21] R. K. Paasch and A. M . Agogino. A structural and behavioral reasoning system for diagnosing large-scale systems. IEEE Expert, pages 31-36, 1993. [22] S. Padaldar, G. Karsai, and C. Biegl. Real-time fault diagnostics. IEEE Expert, pages 75-85, 1991. [23] William H. Press and Brian P. Flannery. Numerical Recipes in C — The Art of Scientific Computing , chapter 9 and 15, pages 263-266, 569-573. [24] Raymond Reiter. A theory of diagnosis from first principles. Artificial Intelligence , 32(l):57-95, 1987. [25] Nariman Sepehri. Dynamic Simulation and Contr ol of Teleoperated Heavy-Duty Hydraulic Manipulators .  PhD thesis, UBC, 1990.  87  [26] Alan S. Willsky. A survey of design methods for failure detection in dynamic systems. Automatica , 12:601-611, 1976. [27] Darrell Wong. Parallel Implementation of Multibody Dynamics for Real-Time Simulation,. PhD thesis,  UBC, 1991.  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0064865/manifest

Comment

Related Items