Records and Quality Assurance

Airframe Time Accumulation

A TMI log sheet record will detail the hours and landings/cycles an aircraft accumulated on a log sheet as well as all of the maintenance information on the log sheet. The hours and landings/cycles totals entered on a TMI log sheet record will cause the aircraft total times to be incremented by that amount, and furthermore causes all parts attached to the aircraft to have their respective times incremented as well. It is this process of time accumulation that allows RAAS to keep track of pending maintenance jobs.

Special separate time tracking features for items such as heaters, APUs and rotary wing time accumulators (RIN/RHL) are also available in TMI. Any part or assembly can be defined as an item that may accumulate hours or landings/cycles at a rate different than the airframe. For such items the user is provided with an area for separate hours and landings/cycles input.

Technical Log Book Auto-Generation

RAAS generates fully electronic Technical Log Books including the Airframe Log, Modification Log, Installation and Removal Log, Engine Logs and Propeller Logs. RAAS allows the user to identify the parts/components that require log books. It is the verbatim text from the maintenance section of the log page, and entered into TMI, that will be used for producing technical log books. This RAAS feature alone can save substantial manpower because it eliminates the need to transcribe maintenance compliance information from journey log sheets into the various technical log books.

Component and Inspection Compliance

While inputting log sheet data the TMI clerk will clearly detail information about part installations, removals, and constraint compliance. A constraint is something that determines the maintenance interval of a part or an inspection. A typical constraint would be an overhaul, and that overhaul constraint would be limited in terms of hours, landings/cycles, or calendar (days, months, years, or date). The limiters (hours, landings/cycles, calendar) indicate to RAAS how often the overhaul must be accomplished. A constraint compliance is therefore the action of carrying out that overhaul constraint in respect to the aircraft records. Installation, removal, and constraint compliance are called maintenance actions, and it is this maintenance action data that TMI uses to update the maintenance status of an aircraft.

Quality Assurance Rule Definitions

RAAS employs a feature called Triggers to allow the user to define either procedural rules or Associated Maintenance within the system. A typical trigger would be a brush check that accompanies an alternator overhaul. RAAS allows the user to define a trigger rule that says, When complying with an Alternator Overhaul remind the Technical Records Clerk to check to see if the Brush Check has been carried out or not. So, when an alternator overhaul is complied with via TMI the Technical Records Clerk is reminded to check for brush check compliance at the same time.

Triggers are designed to allow qualified personnel (QA for example) to define rules within the system. The rules that have been defined will determine how a Technical Records Clerk can proceed with his or her work. This approach represents a significant advance in Technical Record keeping because by allowing appropriate personnel to define rules the traditional need for a Technical Records Clerk to be aware of the subtle aspects of each aircraft type's maintenance procedures can be completely removed. Furthermore, because rules are defined on a system-wide basis every Technical Records Clerk is subject to them which results in highly consistent data input and management.

Triggers can be associated with the installation, removal, compliance or reset of any constraint tracked by RAAS. Triggers can also be configured to simply cause "reminder" notes to appear when working in TMI.

Component and Inspection Configuration Definitions

RAAS allows you to define a base-line configuration for any assembly or inspection. This means that you can define what components and inspections should be attached to a given aircraft type, and how each of those components and inspections should be configured. RAAS takes a sub-assembly (hierarchical) approach to this feature in the sense that you first define the configuration of assemblies (engines, etc.) and then define the configuration of the airframe by including the configuration definition of the assemblies within the configuration of the airframe. A configuration can be defined for anything in RAAS, from something like an alternator with a brush check inspection attached to it right up to an entire aircraft.

Defined configurations are used in two different ways:

• Configuration Build Tool: Assume you had defined a standard alternator configuration as having a brush check inspection attached to it. Now, when introducing new alternators to the system (either through system set-up or upon receipt of newly purchased/received items) you can have RAAS build the alternator to the base-line configuration. This ensures that every alternator that is introduced to RAAS will be configured that same way. This is a cascading tool which means that if there were nested configurations all down-stream items will be built to their respective configuration.
• Configuration Verification Tool: Again, assume you had defined a standard alternator configuration as having a brush check inspection attached to it. As a type of routine data maintenance users can run verification routines against one or many alternators and expect RAAS to report back indicating if the alternators verified are configured correctly. This is also a cascading tool in that if down-stream items are found to have configurations of their own RAAS will verify those items as well.

The configuration utilities allow for the input of serial number applicability. This means, for example, that different serial number ranges within an aircraft type can be configured to have different component and/or inspection requirements.

Component Reliability Analysis

Component reliability refers to the process of carrying out data analysis against component maintenance history to determine reliability performance, typically with respect to TBO. Component reliability analysis is a very broad term when applied to aircraft records and it can often require substantial human resources to manage. RAAS provides high level functions for broad and narrow-based component historical analysis.

Due to the nature of our inventory management strategy RAAS is able to store all part and maintenance history data in one common storage area. This data storage strategy combined with the data available from TMI makes RAAS a very powerful component reliability analysis tool.

RAAS takes a 2-tier approach to component reliability analysis. The first tier will provide detailed analysis about both schedule and unscheduled component removals including percent TBO and reason for removal, organized by reason. The second tier allows unscheduled removals to be linked back to the “last overhaul facility” which in turn can help identify problematic overhaul procedures.

The two primary advantages of this type of detailed analysis are 1) identification of poor performance from overhaul facilities or component vendors, and 2) potential for sustained TBO extension through successful proof of quality.

Snag Reliability Analysis

As a result of routine daily log sheet data input via the TMI module RAAS retains all of the information necessary to produce complete snag reliability analysis. This includes 30 day type, 30 day fleet and 12 month type, per aircraft system (ATA range), demonstrated in graphical form and broken down by problem category.

Advanced tools allow RAAS users to include or exclude individual snags from analysis reports for complete fine-tuning of Snag Reliability Analysis.