Redes sociales Facebook

Input Settings

Method responsible for setting the initial settings in the Schiphol frame, such as the

prediction horizon (time components spend in the ‘AlertBuffer’ before proceeding to the ‘FailureBuffer’) and it writes the right values in the ‘CreateComponents’ table,

which is used by the source to create components.

When components are created in the source, this method is called. It assigns all the

component specific values to MU’s (moving units), such as the aircraft registration

and the component ID. When an user-defined attribute (uda) is unknown yet, it set to a default value.

Table used by the source to find how many components it should generate.

This method installs components to the right aircraft. It can be called in the beginning of the simulation, to facilitate initial instalment. It is also called later in the simulation when a component is replaced and a tail needs a new part to be installed. This method can also be seen as ‘the gate’ before instalment on an aircraft.

Therefore, this method also tracks performance data, such as delivery performance.

Prior to installation on the aircraft, this method calls ‘SetTimeOnWIng’ to determine

the Predicition Horizon, Time To Alert, or Time To Failure on a specific tail. Assigns the user defined attribute ‘Time To Alert / Failure’, in the program named as .MTBR. This time is set as the ‘processing time’ (operational time) on an aircraft.

The code is programmed such that it derives this operational time from a failure distribution (experimental factor). The prediction horizon can be deterministic or stochastic (also an experimental factor). The prediction horizon is the time a component stays in the AlertBuffer.

If the failure distribution is empirical, a random number is generated by the software which determines from which histogram bin the operational time is derived. Another random number determines, together with the value for Prognos’

sensitivity, whether the failure will be detected by Prognos (resulting in a time to alert instead of a time to failure).

This table represents the empirical distribution and should be determined prior to running the simulation.

Component Inflow

Responsible for creating components.

This represents an ‘infinite’ supply of lease components. In the beginning of

the simulation, a large number of lease components is created and stored in this EmergencyBuffer. If a stockout occurs, and replacement is required according to MEL restrictions, this buffer supplies extra components. When a spare part becomes available from repair, it is sent back to the EmergencyBuffer.

Basic method that returns a lease component to the method that called this method.

Same as GetLeaseComponent, now for a spare from inventory.

The model includes some extra coding to make the computer model more representative for current operations at KLM. When there is a stock out and MEL violation (model requires lease), it checks whether a repair is expected to be finished within the planning interval of the MCC. MCC normally needs 5 to 10 days to plan a corrective replacement. In the method

‘EmergencyReplacement’ a random number is generated between 5 and 10.

This corresponds with the time the MCC needs to plan replacement. When a repair is expected to be finished within that interval, the model ‘pulls’ a repair from the repair shop instead of leasing a component. This specific method is responsible for returning a spare from repair and called by the method

‘EmergencyReplacement’.

When a component leaves the EmergencyBuffer, it tracks performance data

regarding lease components and stores it in the table ‘LeaseComponents’

Same, but for returning exchange components.

KLM Boeing 787 Fleet

Represents a 787 aircraft. N components can be installed on the aircraft. The processing time on an aircraft is an uda: @.MTBR. After the processing time, the component is sent to

the AlertBuffer or

FailureBuffer.

Table filled with the active status of the Fleet. It includes all tail registrations, the number of alerts, failures and the total of these two per aircraft.

Component Outflow

A buffer where components stay for -PredictionHorizon- days. After the prediction horizon, components are sent to the FailureBuffer with the method MoveToBuffer.

The place for failed components that are still installed on an aircraft.

This table is used as input to determine whether replacement is required on the fleet. It provides all alerted and failed components that are still installed on aircraft.

Coordination

When a component ‘leaves’ an aircraft after its time to failure or time to alert, it

is sent to the AlertBuffer or FailureBuffer; this method is responsible for managing that process.

This methods determines the value for 𝑋𝑖𝑗𝑡. The method evaluates the decision

every time the system state changes. When replacement is required (demand arises), it calls the method regular replacement or emergency replacement. it logs the demand date in the table DeliveryPerformance. The method is also responsible for sending spares back to the emergency buffer for exchange (when there are outstanding lease components).

Method responsible for updating the current system state.

Performs a replacement for a component that was on an aircraft with 2 failures (aircraft are airworthy when 3-out-of-4 components are operational) and replaces it with a lease or with a component that is expected on a short notice from repair (see also the explanation of the ‘GetRepairSpare’ method in the subsection ‘Component Inflow’)

Responsible for performing replacements with spares from on-hand stock.

Method that writes values to the table ‘FleetStatus’. This table is used to sort

removals.

Figure 34: Method structure for replacement (2/2)

On the right side in Figure 34 a table overview shows which method is called in case of demand.

III. Logistic Centre