Multi-domain Modeling and Simulation of an Aircraft System for Advanced Vehicle-level Reasoning Research and Development

—In this paper, we describe a simulation based health monitoring system test-bed for aircraft systems. The purpose of the test-bed is to provide a technology neutral basis for implementing and evaluation of reasoning systems on vehicle level and software architecture in support of the safety and maintenance process. This simulation test-bed will provide the subsystem level results and data which can be fed to the VLRS to generate vehicle level reasoning to achieve broader level diagnoses. This paper describes real-time system architecture and concept of operations for the aircraft major subsystems. The four main components in the real-time test-bed are the aircraft subsystems (e.g. battery, fuel, engine, generator, heating and lighting system) simulation model, fault insertion unit, health monitoring data processing and user interface. In this paper, we adopted a component based modelling paradigm for the implementation of the virtual aircraft systems. All of the fault injections are currently implemented via software. The fault insertion unit allows for the repeatable injection of faults into the system. The simulation test-bed has been tested with many different faults which were undetected on system level to process and detect on the vehicle level reasoning. This article also shows how one system fault can affect the overall health of the vehicle.


I. INTRODUCTION
A Vehicle Level Reasoning System (VLRS) aids in enhancing the safety of the aircraft.Such systems comprise of various units (sub-system reasoner) that monitor related components for functional status and relay back operational status to the entities of interest.Thus, a primary function of the VLRS, see Figure 1, is to deduce the overall operational health of the aircraft.
The VLRS takes data/results input from several subsystems and processes this information to provide overall vehicle health status [1], [2], [3].However the major challenge is the sub-system level data and results are not available on vehicle level (includes several sub-systems with connected physics).One of the objectives of this simulation test-bed is to demonstrate VLRS, Artificial Intelligence Exchange and Service Tie to All Test Environments (AI-ESTATE) [4]and Open System Architecture for Condition Based Maintenance (OSA-CBM) [5].The aim of the current work is to develop a simulation test-bed that emulates hardware for a practical aerospace related application and implement a health monitoring system for the test-bed [6].
With the lack of large scale diagnostic test-beds and in order to meet the complexity of the aerospace applications, we have developed the diagnostic test-bed with the following goals in mind:  Provide a data and results sub-system to create a VLRS  Provide the capability to perform testing of diagnostic algorithms by manually or algorithmically inserting faults, and  Provide a technology neutral basis for implementing and evaluation diagnostic systems and software architecture, tosupport the condition based maintenance (CBM) process.www.ijacsa.thesai.org In this case, a system representation of an aircraft's basic core sub-system (i.e.batter, fuel, engine, generate, heating and lighting system) is chosen as an example for the simulation development.These sub-systems and their associated health monitoring algorithm will then be used to develop a VLRS (Vehicle Level Reasoning System) for demonstration.This simulation is considered to be a good candidate for a test-bed to be used for data processing architecture evaluation purposes, i.e. being composed of many systems/components to be monitored and many sensors that generate data.These data can be collected and used to generate diagnostics results at vehicle level across the aircraft systems.
The system that has been used in this simulation can provide multi-physics data such as electric, temperature, fuel flow and pressure which will enable us to insert faults in the fuel system and different electrical systems.Generally aircraft's all major systems are very complex in nature, Hence the modelled system in this simulation are very complex in their design,therefore this simulation has been created by the basic design of these systems by aiming to create a system level data to perform a testing of Vehicle level reasoners simulation platform.

A. Detection and Diagnostic System
Detection and diagnosis can be achieved manually, by rulebased systems, mathematical or other learning or model based techniques.Fault detection and diagnosis in systems have been widely used in commercial industry over the past few decades [7], [8].The diagnostics algorithms can be based on different types of measurement depending on the systems and applications, for example, the electrical currents in Motor Current Signal Analysis (MCSA) [9] and accelerations in Vibration Analysis [10].The purpose of these methods is to detect and diagnose faults at an early stage and therefore allow contingency plans to be put into place before the problems worsen.
Historically, troubleshooting has been a major element of the maintenance strategy for mechanical equipment of any kind.The traditional diagnostics monitoring equipment detects any abnormal behaviour and triggers a ground based test or troubleshooting activity.Nearly all systems, especially more complex aerospace systems, fall short of the ideal system that could accurately and unambiguously drive replacement or repair actions with no additional testing required.Inherent diagnostic ambiguity and conditions that lead to false alarms results in extensive troubleshooting, parts swapping and shotgun maintenance which increases in turnaround time and maintenance costs [11].This of course has an impact on further development for the diagnostic reasoners, initiating several different techniques such as Model Based Reasoning (MBR) or data driven methods [12].
NASA was an early contributor to vehicle level reasoning systems.In 2004, NASA uploaded Livingstone Version 2 (LV2) software to the EO-1 satellite to test its ability to find and analyse errors in the spacecraft's system, [13].Tests, normally performed on the ground, were conducted in flight to automatically detect and diagnose simulated failures in the satellite's instruments and systems.Livingstone provides the opportunity to recover from errors to protect these assets, and continue to achieve mission goals.On this mission, LV2 also monitored another software application that controlled EO-1 to autonomously run its imaging system.If EO-1 did not respond properly to the software control, LV2 detects the error, makes a diagnosis, and sends its analysis to mission control.LV2 compares a model of how the spacecraft's systems and software should perform to the actual performance.If the spacecraft's behaviour differs from the model, then the LV2 reasoners search for the root cause and provide mission controllers suggestions of what may have gone wrong.Actually very few aircraft have VLRS built in, even those VLRS are based on a basic detection and pattern recognition diagnostics system.These VLRS have been designed concurrently with the aircraft and do not incorporate plug and play facilities.Therefore, including any further sub-systems in the VLRS is not feasible.The literature review shows very little information about VLRS implementation in military and no implementation in civil aircraft.

III. CHALLENGES TO VLRS MODELLING
VLRS is there to detect and predict faults and failures at the aircraft level.It does this by receiving health information from individual sub-systems and fusing them to derive an overall health status for the aircraft.Generally, the reasoning system is Sponsors of this project are IVHM Cranfield University, Boeing, BAE System and other IVHM partners www.ijacsa.thesai.organ artificial intelligence based software application, hardware device or combination of hardware and software whose computational function is to generate conclusions from available knowledge using logical techniques of deduction, diagnosing and prediction or other forms of reasoning [14].
In an aircraft the sub-systems are developed by many different vendors, see Figure 2.Each vendor has their own development and design philosophy and will use the best diagnostic algorithm for their equipment.Such algorithms will produce results that are interfaced to the aircraft system via a communication bus such as ARINC 429.To enable the communication on an ARINC 429 bus the component has to follow the interface standards.This shows that in there are major issues that must be dealt with when developing/manufacturing the aircraft.Each component, sub-system and part has been designed by a much defined outlined interface in order to communicate with CMC (Central Maintenance Computer) or sub-system [15].If this outlines changes it would require component, sub-system vendors and suppliers to change their design as well as to communicate with the rest of the system.It would be unreasonable to require vendors and suppliers to use particular algorithm techniques.Their systems have to go through intensive testing and certification before they can be used in a commercial aircraft; further testing would mean more cost.Consequently, interoperability between the components or subsystems supplied by different vendors has essentially become one of the major challenges for VLRS.With each component being specific in its nature, there exists a need for a common communication vocabulary that allows for health status communication between the components and the VLRS.This simulation platform test-bed will allow manufacturer, vendors and suppliers to test their design and their reasoners.It will also show how the system will react with certain faults (fuel leak, electric short circuit) occurring in the system [16].

A. Case study 1 of real accident
In this article the faults that are simulated have been adopted from real accident/incidents.These faults were undetected or miss detected at the system level detection system during the flight, they can be taken as a starting point to see how the VLRS system performs.This requires the system simulation to have certain components which can provide the data to perform higher level reasoning.The following are the accident case studies which have been adopted for this simulation: Fault Type:fuel leak at the entrance of the engine inlet pipe line.
Detection:No fault has been detected at the aircraft system.

1) Details
Flight TS 236 took off from Toronto at 0:52 (UTC) on Friday August 24, 2001 (local time: 8:52 pm (ET) on Thursday August 23, 2001) bound for Lisbon.There were 293 passengers and thirteen crew members on board.The aircraft was an Airbus A330 which was manufactured in March 1999.Leaving the gate in Toronto, the aircraft had 46.9 tons of fuel on board, 4.5 tons more than required by regulation.
At 05:16 UTC, a cockpit warning system chimed and warned of low oil temperature and high oil pressure on engine #2.There was no obvious connection between an oil temperature or pressure problem and a fuel leak.Consequently Captain Piché (who had 16,800 hours flight experience) and First Officer DeJager (pilot who had 4,800 flight hours) suspected they were false warnings and shared that opinion with their maintenance control centre, who advised them to monitor the situation.
At 05:36 UTC, the pilots received a warning of fuel imbalance.Not knowing at this point that they had a fuel leak, they followed a standard procedure to remedy the imbalance by transferring fuel from the left wing tank to the near-empty right wing tank.Unknown to the pilots, the aircraft had developed a fuel leak in a line to the #2 engine.The fuel transfer caused fuel from the left wing tank to be wasted through the leak in the line to the #2 engine.The fractured fuel line, which was leaking at about one gallon per second, caused a higher than normal fuel flow through the fuel-oil heat exchanger (FOHE), which in turn led to a drop in oil temperature and a rise in oil pressure for the #2 engine.
The Portuguese Aviation Accidents Prevention and Investigation Department (GPIAA) investigated the accident along with Canadian and French authorities.
The investigation revealed the cause of the accident was a fuel leak in the #2 engine, caused by an incorrect part installed in the hydraulics system by Air Transat maintenance staff.Air Transat maintenance staff had replaced the engine as part of routine maintenance, using a spare engine, lent by Rolls-Royce, from an older model.This engine did not include a hydraulic pump.Despite the lead mechanic's concerns, Air Transat ordered the use of a part from a similar engine, an adaptation that did not maintain adequate clearance between the hydraulic www.ijacsa.thesai.orglines and the fuel line.This lack of clearanceon the order of millimetres from the intended partallowed vibration in the hydraulic lines to degrade the fuel line, causing the leak.Air Transat accepted responsibility for the accident and was fined CAD 250,000 by the Canadian government, which as of 2009 was the largest fine in Canadian history.

B. Case Study 2 of real accident
Fault Type: "Fatigue cracking" in a stub pipe within the engine resulted in oil leakage followed by an oil fire in the engine.The fire led to the release of the Intermediate Pressure Turbine (IPT) disc.
Detection: Emergency warnings in the cockpit indicated (engine 2) failure.Pilots were alerted by 54 error messages generated by aircraft systems.

1) Details
Qantas Airline flight 32, Aircraft-Airbus A380, the flight was on route to Sydney Airport via Singapore Changi Airport from London Heathrow Airport on 4 th November 2010.
The aircraft engine 2 had an uncontained failure; the shrapnel from this engine had punctured part of the wing and also damaged the fuel system which further caused the problem of leaking fuel and a fuel tank fire.One hydraulic system and the anti-lock brakes were also disabled, which caused engine 1 and engine 4 to go into degraded mode.This meant that the landing flaps were also now damaged.
The failure occurred over Batam Island, Indonesia.After holding to determine aircraft status, the aircraft returned to Changi nearly two hours after take-off.Upon landing, the crew were unable to shut down the (engine 1) which had to be doused by emergency crews 3 hours after landing until flameout.Fuel was leaking from the left wing onto the brakes, which were extremely hot from maximum braking.
An hour after landing the passengers were finally safe to exit the aircraft, there were no injuries to the passengers, crew or people on the ground.Rolls Royce determined that the direct cause of the oil fire and resulting engine failure was a misaligned counter bore within a stub oil pipe leading to a fatigue fracture.

IV. ARCHITECTURE OF THE SIMULATION TEST-BED
The overview of aircraft vehicle major systems and their architecture is shown in figure 3.In this figure it shows the major systems, which have been modelled in the simulation test-bed.This figure also illustrate basic layout of these systems.
An overview of the experiment architecture for testing and the demonstration of the communication protocol, fault insertion and HM algorithms for the aircraft vehicle is shown in figure 4. The aim of the architecture is to act as a modular testbed for HM algorithms and data processing architectures from simulation based to embedded hardware implementations [15].The four main components in the real-time test-bed are the vehicle systems' simulation model, fault insertion unit (FIU), HM data processing and user interfaces (UI).These computation nodes are linked to the Ethernet, and the integrated test bed is enabled by a User Datagram Packet (UDP) based communication between the computers [17], [18].

V. MODEL OF THE SIMULATION OF AN AIRCRAFT SYSTEM
In order to evaluate model based diagnosis algorithms, we developed a simulation of the system.The simulation serves as a virtual test bed where we can easily study a large number of fault scenarios to develop our diagnosis models and test our algorithms.An accurate and realistic simulation model will help in migrating diagnosis algorithms to the actual system.
To this end we developed a physics-based simulation of the whole vehicle system in MATLAB/Simulink.We adopted a component based modelling paradigm, where parameterised simulation models of generic components including AC generators, breakers, relays, DC adapters, loads and sensors are available within the SimPowerSystems' component library.
The system model is constructed by instantiating the different components from the component library, specifying their parameters and connecting the components to each other in the appropriate fashion.However, if the required component is not available, we have developed our own by using the Matlab code and performing the task by using mathematical equations.
The simulation test-bed allows for the repeatable injection of faults into the system [19].All of the fault injections are currently implemented via software.In general, a software fault injection includes one or more of the following: 1) sending commands to the test-bed that were not initiated by the user; 2) blocking commands sent to the test-bed by the user; 3) altering the test-bed sensor data.Because each fault mode is parameterized within the Simulink model, a fault can be inserted either at the beginning of the simulation, or while the simulation is running.
Each component in the simulation model is associated with the fault modes.For example, a relay may become stuck at a particular operating mode.The associated fault injection model of a relay is shown in figure 5, more details of fault insertion are provided in the fault insertion section.

VI.
AIRCRAFT SUB-SYSTEM MODELLING This section will discuss the physics of the each modelled system.The modelling of each sub-system was very important as this simulation test-bed is made to capture the fault progress, how each fault effects the other systems and overall vehicle health.

1) Battery system
Before the engine is started the main source of electrics in an aircraft or in an automotive vehicle are the batteries.The battery also powers up the aircraft systems and brings the aircraft to life before the engine has been started.Once the engines are started the electrical energy to run the system comes from the generators.It also is used to support ground operations such as refuelling and powering the braking system when the airplane is towed.The main battery also provides backup power for critical systems during flight in the unlikely event of a power failure.
In this simulation platform, the battery provides a current before the engine and generators are switched on or in the event there is a need of extra electricity or to store extra electricity.Therefore this simulation platform only monitors the state of the charge of the battery and the charging/discharging rate.However the battery system is extendable.

2) Fuel System
The Fuel system provides the fuel to the engines at the required rate.In the fuel system most of the parts are powered by the electricity.The major fuel system parts are shown in table 2: This fuel system is a small module of the whole simulation platform.The main task of the fuel system simulation is to www.ijacsa.thesai.orgFig. 6.The Simulation results of a healthy state provide the data of the fuel system while physically connected with the other systems.This will make the system produce more realistic behaviour data; for example, if the fuel system has any problem and provides less fuel to the engine, then the engine will automatically be affected.However the fuel system has been kept very basic for simple diagnostic tasks.This system provides a flow sensor, pressure sensor, fuel consumption per minute and fuel level at the tank.
In most flows of liquidsand gases at a low Mach number, the density of a fluid can be considered to be constant, regardless of pressure variations in the flow.Therefore, the fluid can be considered to be incompressible and these flows are called incompressible flow.The Bernoulli equation in its original form is valid only for incompressible flow.A common form of Bernoulli's equation is given to calculate the pressure of the pipelines:

3) Engine System
The engine has been simulated as a jet engine, not all the parameters of the jet engine have been simulated at this level as this engine simulation unit is designed for higher level reasoning rather than engine (sub-system) level reasoning.The engine system is physically connected from the fuel and electrical system.The parameters of this engine are fuel intake, air intake, required speed and engine thrust.The mathematical equation has been used in the simulation of the engine unit.

Engine efficiency equation:
The energy efficiency of jet engines installed in vehicles has two main components:  Propulsive efficiency ( p ): how much of the energy of the jet ends up in the vehicle body rather than being carried away as kinetic energy of the jet.
 Cycle efficiency ( ve ): how efficiently the engine can accelerate the jet.
Even though overall energy efficiency is simply: Thrust equation: The net thrust (F N ) of a turbojet is given by:

F N = (ṁ air + ṁ fuel )v e -ṁ air v
Where: ṁ air = the mass rate of air flow through the engine ṁ fuel = the mass rate of fuel flow entering the engine www.ijacsa.thesai.orgv e = the velocity of the jet (the exhaust plume) is assumed to be less than sonic velocity v = the velocity of the air intake = the true airspeed of the aircraft ( ṁ air + ṁ fuel ) v e = the nozzle gross thrust (F G ) ṁ air v = the ram drag of the intake air The engine has been modelled closely to the Rolls-Royce RB211, which is part of a family of high-bypass turbofan engines.However the main parameters can get changed by the user to model another jet engine or another type of jet engine.

4) Generator System
The electrical generator system has been modelled to a very basic standard,just as a provider of the electricity at several different speeds.In the civil aircraft industry the generator modules are connected with the engine, each engine has one generator to provide the electricity for the aircraft.Therefore the number of the generator and engine has to be equal in this simulation to make the simulation and functional model of the simulation equal.The generator system monitors the electricity generated by the generator according to the engine and required electricity of the aircraft.

5) Heating System
The aircraft needs heating systems in several places to ensure the safety of the aircraft, for example, a heater at the Pita tubes, turbine blades heaters, front screen heaters etc. Generally these heaters are managed by the heating system.These heaters are electricity powered and provide the required heat at the certain places.The heating unit of the simulation has multidimensional parameters, it consumes the electricity and provides the heat in temperature.

6) Lighting System
The lighting system provides the light to the aircraft in several different places such as the head lamp, tail light, cabin light etc.The lighting system takes the electricity from the main system and the simulation provides the data as to how many bulbs are switched on, how much electricity is being consumed and how much is supposed to be consumed.
The faults can be inserted into all the sub-systems of the whole vehicle system, however, as this simulation platform has simulated very basic sub-systems, not all the parts which are present in a real aircraft system have been available to insert the fault into.Fault insertion modelling is explained in a later stage in this article.
Each component in the simulation model is associated with the fault modes.For example, a relay may become stuck at a particular operating mode.The associated fault injection model of a relay is shown in Figure5.

The Communication Protocol
The communication protocol is a very important part of this project.In order to have a decentralised communication all subsystems are bound to have information shared between them.Most network based communications is either UDP or TCP based, a comparison of the two is provided below.The UDP protocol does not support the guaranteed delivery of messages, where on the other hand TCP protocolallows guaranteed message delivery.Therefore the TCP protocol has been used in this simulation.

1) The Initial Results
The simulation test-bed can simulate several different profiles of the system.In the figure below the simulation ran for a 100 seconds without any fault in the system.This confirms the normal behaviour of the simulation, so the data can be compared with the similar real system.
The light and heating are switched on at the start of the system simulation and the heating switches off at 20sec for 5 sec and the light switches off at 40 sec for 5 sec as shown in the figure9.The General phenomena is visible as the available current increases as the consumption of the current are goes down then the available current are more and other graphs shows the effects as well.

2) The Fuel System Fault Results
The simulation test-bed can simulate several different profiles.In the figure below the simulation has been ran for a 100 seconds and the fault was inserted at 60sec in the system for 10sec.
Figure 7 demonstrates the leakage in the fuel pipe for 10 seconds which shows the behaviour of the engine affected.As the engine didn't get enough fuel the engine thrust level got affected.www.ijacsa.thesai.org

3) The Heating System Faults Results
The heating system fault has been inserted in the simulation.In the figure 8 the simulation has been ran for a 100 seconds and the fault was inserted at 60sec in the system for 10sec.
Figure 8 demonstrates the short circuit in the heaters of the heating system for 10 seconds which shows the effect on theavailable electric current and it also effected the rest of the electrical system as there wasn't enough current available for other systems to use.www.ijacsa.thesai.org

4) The Lighting System Faults Results
A lighting system fault has been inserted in the simulation result.In the figure below the simulation has been ran for a 100 seconds and the fault was inserted at the 60sec in the system for 10sec.
Figure 9 demonstrates the short circuit in the heaters of the lighting system for 10 seconds which shows the effect on the available electric current and it also effected the rest of the electrical system, there wasn't enough current available for other systems to use.www.ijacsa.thesai.org

VIII. FUTURE WORKS
This simulation test-bed has been designed to produce the data and results on the sub-system level which can be used at VLRS and/or for to apply information exchange between subsystems.However, in this simulation the VLRS hasn't been implemented.The next stage of this work would be to implement the VLRS and sub-system reasoner and tweak the simulation according to the need of data to reasoners.

IX. CONCULSION
The Simulation Test-bed has been designed a as platform to provide data to perform the reasoning at vehicle level.The vehicle level reasoning system provides higher level reasoning results which are achieved by fusing information from the several sub-systems.This simulation platform will provide the data which could be used for the proof of the concept of the efficiency of the vehicle level reasoning system.The simulation platform is very basic compared to the real system however, the data generated from this test-bed would be sufficient enough to provide the health stat and basic fault detection on the vehicle level as well as sub-system level.The next step of this simulation test-bed would be to design the VLRS by utilising the data of this simulation.

X. ACKNOWLEDGMENT
We would like to thank Boeing, BAE Systems and all IVHM centre's industrial partners for their support and guidance in our research.In particular, we would like to thank Kirby Keller from Boeing, and Antony Waldock from BAE

Fig. 2 .
Fig. 2. Boeing 787 an example figure for aircraft and their vendors.

Figure 2
Figure2demonstrates the suppliers and parts provided by different vendors for just one aircraft model; in this case it shows the parts made by the different countries and vendors.This shows that in there are major issues that must be dealt with when developing/manufacturing the aircraft.Each component, sub-system and part has been designed by a much defined outlined interface in order to communicate with CMC (Central Maintenance Computer) or sub-system[15].If this outlines changes it would require component, sub-system vendors and suppliers to change their design as well as to communicate with the rest of the system.It would be unreasonable to require vendors and suppliers to use particular algorithm techniques.Their systems have to go through intensive testing and certification before they can be used in a commercial aircraft; further testing would mean more cost.Consequently, interoperability between the components or subsystems supplied by different vendors has essentially become one of the major challenges for VLRS.With each component being specific in its nature, there exists a need for a common communication vocabulary that allows for health status communication between the components and the VLRS.

Fig. 3 .
Fig. 3.The architecture of the simulation and physical location of the system in aircraft.

Fig. 8 .
Fig. 8. Fault at heating system due to short circuit.

Fig. 9 .
Fig. 9. shows the fault in the lighting system