Integration and evaluation of aircraft power plant production and operational data

The paper focuses on identification of the limits of data collection based on data analyses in GE Aviation Czech, Ltd. to improve current system for data collection pertaining non-conforming products which are collected during the process of the product reconciliation. The paper contains a description of non-conformity product, data collection as well as their analysis and evaluation. Paper describes development of conceptual model of data integration about non-conformity products regarding aircraft power plant production and operation data, by the means of UFO upper level ontology. It shows the importance for building a system for collecting and evaluating data about non-conformity products in GE Aviation Czech, Ltd.


Introduction
In everyday life we can find things or situations which are not as we planned or expected.We can say, that reality does not conform to expectation.In the manufacturing process within GE Aviation Czech, Ltd., which design, manufacture, sell and service highly sophisticated aircraft engines, we can find products which are not meeting compliance requirements.Within the company, non-conformity is defined as a product property, which indicates deviation from a specification, standard, or an expectation, but it is consistent with ISO definition [1].These cases are in some respect sensitive as they may carry on important information about their origin and potential clues for remedy.Such cases pertain limitations in product quality, reliability and finally safety.Non-conformity also means extra costs for the manufacturer, not only because there usually is additional effort needed to correct them, but because in extreme cases, the regarded product may need to be scrapped.
For analyzing and later evaluation, it is necessary to collect data about non-conformity products.Within GE Aviation Czech, Ltd., this is already done to certain extent, but multiple system are in use for the purpose, ranging from usual Excel sheets up to usage of advanced Oracle database.This variety of tools used to collect and record data brings about the classical problem of heterogeneous data integration, where the gap is closed by experts using the systems on daily base [2].However, experts may change and some of their knowledge and understanding could be lost.The next person to replace them may not be able to see all the information stored in the records.Similarly, different experts may establish different understanding of the data.This is only an excerpt of the well-known issues with data integration.
With this respect, we propose to utilize ontology engineering to establish an ontology of key concepts and patterns from the domain [3].By defining objects, events and properties in the data and their relevance to processes where they originate from, it is possible to propose a well-founded concept of data integration about non-conformity products regarding aircraft power plant production and operation [4].Such concept could be used as a cornerstone for future integrated system of data collection about non-conformity products.In that way, it is possible to limit the negative effects coupled with these products so as to improve safety, reliability and quality of the final product -in this case an aircraft engine.

Non-conformity product
In the context of GE Aviation Czech, Ltd., non-conforming product regards any product that does not meet the requirements of the design documentation and/or does not meet the technical specifications.The product may become nonconforming even if the tests and checks that follow from the relevant documentation have not been performed.Nonconforming product, after being discovered, is isolated with other non-conforming products from other products.In the case of an initial finding, non-conforming product must be visibly marked with appropriate label to prevent its usage.The appropriate label for the initial finding is called stop card [5].
Defining the data flow about non-conformity products is focused on accurate definition of processes, objects and persons, which are involved in data collecting pertaining nonconforming product.The regarded processes are depicted in Figure 1.Main process steps are depicted in green, additional process steps are in yellow and data outputs are in white.

Detection and final check of a non-conformity product
The possibility of discovering a product that does not meet the prescribed parameters may occur during performance of standard work task of any employee.It is important for an employee to report a potential non-conformity to his supervisor, who will take appropriate action.After the detection, the supervisor is obliged to mark the product with label and fill in data that are known at that time.The product is next handed over to the Technical Control inspector.Subsequently, the inspector of the Technical Inspection performs a functional check of the part.After the product non-conformity is confirmed, there is an obligation to make a record in Oracle database [6].

Oracle database records
A record must be created in the cases when [7] Figure 1.Processes of the reporting of non-conformity product (ONV) • there is an engine or engine part where the required parameters (e.g.drawing tolerances, specifications) are out of tolerance; • there is an engine that was not subjected to the engine test, so its functionality is not confirmed; • there is an engine that did not meet relevant drawing documentation; • manufactured part does not correspond to the technological process.
Initial record in Oracle databased is called Master.Here we can find information about the place, where the nonconformity was detected as well as detailed description.Also, important is the information about non-conforming part -part number, number of drawing documentation, quantity [6].
Another type of record in Oracle database is called Detail.Here we can find additional information to the Master.More information are provided here -respective owner of the non-conformity and a more detailed specification of the process where the non-conformity emerged.It is important to select department that identified the non-conformity, and also specify from which department the non-conformity originates.Furthermore, there is an attribute that specifies the Commission as the owner of the decision about non-conformity reconciliation.The Commission is specified on the basis of the date of its meeting because it meets only once a day.

Assessment by the Commission responsible for non-conformity products reconciliation
The Commission, which is responsible for the assessment of respective non-conformity, meets every day and intends to carry out preliminary assessment of the non-conformity.An important factor influencing the decision is the initial price of the product compared to the current one.This is also important for clarification of the repair specifications that will be applied to the non-conformity.For example, there may be repair that is considered as cost-inefficient and therefore respective product is scrapped.The data from the Commission are added to the Master, and after that it is called Detail.
Possible reconciliations are [7]: • Scrap -cost-inefficient repair which costs more than 50% of the actual cost of the product; • Exception -used only is special cases as per decision of the Commission; • Claim -8D report is required, where the supplier fills the information about non-conformity.Supplier decides if the product will be repaired or a credit note will be used; • Repair -non-conforming product is moved to the Shop repair based on Overhaul Repair Manual; • Safety concern -If the Commission agrees that the non-conforming product is safety concern, the Safety management team will take an action to find out if the non-conformity affects flight safety.

Determination of root causes
For this purpose, Root Cause Analysis is used, comprising several methodologies for determination of causes, such as five times why (5 Whys [8]).This can help identify the most likely cause of non-conformity.
The identified non-conformity may also concern another set of parts, assemblies or processes that are identical or very similar to the part, in which this particular non-conformity was found.As relevant may be considered also a part which came into contact witch the non-conformity part.So it is very important to have data about every relevant process because corrective actions can be applied for several products or the root causes can be used for avoiding similar cases in the future.
The next step is to determine whether the operator has discovered the non-conformity -if not, it is necessary to identify why he could not discover the non-conformity to prevent further omission of non-conformity in engine operations [9].

Gaps in the process of non-conforming products reconciliation
To improve the current situation pertaining the reconciliation of non-conforming products, it is important to identify the gaps in the current processes.
When searching for the owner of the non-conformity, it would be of benefit to identify the owner more accurately than it is done today.Identifying the owner is important for the clarifying the process which caused the non-conformity.Figure 2 shows the owner of non-conformity throughout one calendar year, as is usually collected in GE Aviation Czech, Ltd.The numbers are illustrative and not conforming to exact numbers in a year due to confidentiality restrictions, but their ratio is roughly preserved.The figure shows that the most often origin of non-conformity is not precisely defined as "Other" category leads the statistics.It is necessary to specify the term "Other" into more detailed locations of nonconformity origin.
Another gap is inconsistent recording of data based on non-uniform nomenclature.Another process which can be improved is the process of sharing data with the Commission, which deals with the non-conforming products.The solution is creating a system where all data are with uniform nomenclature and consistent data sharing is assured across the company.It is also appropriate to record the causes of products being scrapped with detailed description.This can prevent reduction in lifetime of the product and reduce respective financial losses.
In case of an inspection, there is output from overhaul checks which are recorded in physical form.Detailed statistics from this department are not available.It is also important to put this data to the unified system with other non-conformities.

Data from inspection
The following texts show examples of non-conforming products found during an inspection.Output from this process is called Finding report (Table 1).This report is a part of the Book of the engine [7].
Next data from inspection are called Test list (shown in Table 2).It is used for evaluation the Safety concern.Test list contains specific engine parts and issues which, if present, qualify the part as Safety concern.If a Safety concern in identified, the information are shifted to the Safety department [11].

Report from the Commission
Output from the Commission is a table that is distributed to selected persons in the company (see Table 3).Each depart-  The information is then processed by the department -without any unified form [6].

Report in Oracle database
Master record contains the information about the product (part number, drawing number, detailed description and owner of the non-conformity, place of finding).Detail record is completed by the information from Commission (date and decision of the Commission).

Solution based on using the UFO-A Ontology
The current data flow has gaps due to inconsistent recording and poor sharing across all departments.The solution to the lack of uniformity in this paper is based on a UFO-A Ontology (Unified Foundational Ontology [4,13]) which is a top level ontology used for representation of any part of the real world, with no limitation regarding its application domain.The focus of the ontology application in this case is process of nonconforming product identification and reconciliation.For this purpose, a modification of UML language according to the UFO-A Ontology, called OntoUML, was used.The modelling was performed in dedicated tool called Menthor Editor1 which supports creating OntoUML models.Application of the data modelling based on UFO-A Ontology to the conceptual modelling level allow a precise definition of relationships for future system within the implementation level.Based on this, there are defined the entities and their attributes which are necessary in the process of reconciliation, the data about non-conformity and the links between them.Based on this concept, the data collected in the nonconformity reconciliation process will have unified records and their sharing will be facilitated within the enterprise.The data will also facilitate creating sound statistics for different departments.
Figure 3 represents the core model in OntoUML, including all persons, products and processes necessary to discover, resolve, and reconciliate a non-conforming product.Also, important are the connections shown in the concept because they characterize interactions among the mentioned entities.
At the center of the model, it is useful to project the nonconformity product, such as part of the engine or the entire engine.It is also appropriate to measure the processes that contribute to the detection, notification and reconciliation of the non-conformity.In the model, there are company processes (in Figure 3 in light blue colour) for review and evaluation of the non-conformity.For the processes, the Relator stereotype is used, because processes are events occurring during non-conformity detection and reconciliation.
Kind stereotype is used for products because they have identity in time.We can describe the products as a Role, specifying properties of the products.The Commission that we   are talking about in section 2.4 is dark blue and it is modelled with Collective stereotype, because all members contribute in the same way to the functionality of the whole.So, every member of Commission is responsible for the reconciliation of the non-conforming product.
In the UFO Ontology there is a pattern in which the participants of the processes are expressed through mediation (Figure 4).This allows at the same time to express a material relation that is based on the mutual participation of the participants in the process.This connection is based on Relator, which is in the model linked to the material relationship with derivation (dashed line).Deviation therefore depends on the existence of Relator.
Every process in this model has links resulting from the same construct.

Model validation
Validation of the conceptual model was done on several levels.The first was the validation based on the comparison of the constructs in this model (attributes, entities and their links) with the real functioning of the company by domain experts.The second one is the validation of the conceptual model using Alloy modelling language, which is not intended for modelling the architecture, as is the case with OntoUML.This language is part of the analytical extension in Menthor Editor and allows to validate the model by generating instances according to the conceptual model, that are validated by domain experts afterwards.The model was pronounced valid with respect to these validation methods.

Discussion
The main benefit of the model is integration of all non-conformity product processes as well as the flow of data that are in the processes, since the identification of the non-conformity product.The key contribution of the model is the unity of the expression among processes, people and products.Analysis and selection of data from the operation and power plant production were realized on the basis of data regarding nonconforming products, namely from their detection until the reconciliation.
Three of the gaps specified in section 3 are resolved by the integration of the data from detection to settlement of nonconformity products by integration and adding the data from inspection to the reconciliation.Another contributing solution can be introduction of more specific information about scrap.

Conclusion
This paper describes development of a concept that provides formal description of all processes relevant to non-conformity products.The focus of the concept are entities and their attributes, which are captured by data sources in the GE Aviation Czech company.The concept was created using UFO upper level ontology (OntoUML modelling language) and validated using expert assessment and Alloy-based instances.In the course of the concept development, several operational issues with the data so as their content was revealed.The model provides sound basis for data integration and relevant nomenclature unification.
The concept can be implemented into a real system for the sake of data integration and flow improvement.It means that the data will be distributed timely where needed and they will contain all the necessary information to support subsequent tasks, thus supporting reduction in repairs and scrapping costs, safety improvements and similar.
Certainly, this work is limited in some ways.First, the concept contains only the processes and attributes, which already are in place in the GE Aviation Czech, Ltd.No effort was made to further improve data content and flow beyond that in this work.Secondly, the concept was not implemented into real company environment and so its validation at this level was not possible.These limitations pose an opportunity for further development of the concept in the future.
The long-term vision of the presented research is that the implementation of the developed concepts to the system for improving the data flow about non-conforming product is completed to allow further improvements and validation.

Figure 2 .
Figure 2. Distribution of non-conformity owner per category on Oracle database

Figure 3 .
Figure 3. Core of the developed conceptual model for non-conformity relevant product processes

Figure 4 .
Figure 4. Demonstration of conceptual pattern used for processes (green colour)

Table 2 .
[12]ple of a test list.In the example, two issues are ticked as being identified during the part check[12].

Table 3 .
Report from the Commission