ABSTRACT

Ontologies have emerged as an important tool in the Enterprise architecture discipline to provide the theoretical foundations for designing and representing the enterprise as a whole or a specific area or domain, in a scientific fashion. This paper examines the domain of maintenance, repair, and overhaul (MRO) of the Sikorsky UH-60 helicopter involving multiple enterprises, and represents it through an ontology using the OWL Language and Protégé tool. The resulting ontology gives a formal and unambiguous model/representation of the MRO domain that can be used by multiple parties to arrive at a common shared conceptualization of the MRO domain. The ontology is designed to be conformant to ISO 13030 or the Product Life Cycle Support Standard (PLCS) standard, hence representing the state of being as per this standard especially at the interfaces between enterprises while incorporating existing reality to the greatest possible extent within the enterprises. As a result the ontology can be used to design Information Systems (IS) and their interfaces in all enterprises engaged in MRO to alleviate some of the issues present in the MRO area and to support business intelligence efforts.

1. Introduction

This template, Enterprise Architecture is a comprehensive blueprint for the automated enterprise that is developed from different views and perspectives [1]. The thought was that a single company or organization can be an enterprise, when the reality is that no organizational entity can operate as a complete enterprise without considering 1) relationships with customers, 2) relationships with suppliers and contractors, and 3) relationships with regulators. Therefore, the enterprise model expressed in enterprise architecture must address how the operation interacts in its functional universe. Special consideration is given to 1) information, 2) processes, 3) enabling technology, and 4) enabling human resources and their associated organization.

Enterprise model or how an enterprise works as a collection of people, process, and technologies is often descriptive, ad hoc, or pre-scientific [2]. It is often a collection of heuristics which are not applicable in all circumstances. Enterprise architecture as a discipline has emerged to provide the theoretical foundations for designing and representing the enterprise in a scientific fashion. Using standard based ontologies to model enterprise is one of the core aspects of enterprise architecture.

Ontologies are of particular importance in the computer science and information systems area on account of their ability to model/represent knowledge as a set of concepts and the relationship between these concepts in a given domain. If an ontology is formulated in a crowdsourced/collaborative manner using a formal language then one can arrive at a formal unambiguous model/representation of the knowledge (referred to as ontology) about the given domain. Ontologies have developed for a variety of things like enterprise modeling [2], in-vivo biological cell types [3], marketing in relation to brand management [4], and socialism [5].

An enterprise is defined by a host of characteristics— processes, inputs, outputs, controls, enabling mechanisms including people (organizations) and technology. There are meaningful and dynamic relationships among these elements that affect cost and time as well as value and assets [1]. In the enterprise architecture domain an ontology (model) can account for all elements in the organization: its people, process, and technologies. The ontology can form the basis of common or shared understanding of the given domain can be used by internal constituents and partners of the enterprise for a variety of purposes like process integration etc. This shared conceptualization can also form the basis for design of information systems that can help run the enterprise more efficiently, and multi-enterprise collaboration using automated tools like intelligent agents. With regards to the latter Gubric and Fan provide an analysis of six supply chain ontologies [6]. Boeing’s Boeing Technical Libraries developed a technical thesaurus in the form of a semantic network incorporating 37,000 concepts with an additional 19,000 synonym concept names, and 100,000 links [7-9] to promote common understanding between various partners involved in the manufacturing and design process.

It is well understood that that a modern enterprise must be data driven and all decisions should be based on information [1]. The process of preparing data for transformation into information and presenting it for action depends upon ontology. The process of associating information with experience, methods, and algorithms also depends on ontology. Given a problem domain within the context of an enterprise the first step would to represent the domain using an ontology. The ontology representation (syntax and semantics used to state the concepts and their relationships) should be based on standards especially if the domain spans across several enterprises. There are many standards available for representing an ontology [1] and one of the popular standard is the OWL 2 Web Ontology Language [10] by W3C.

In this paper we present a problem domain related to aircraft maintenance and provide description of the preliminary work done towards representing the problem domain by arriving at an ontology using the OWL ontology language.

2. Military Maintenance, Repair, and Overhaul (MRO)

The military maintenance, repair, and overhaul (MRO) activities refer to the maintenance functions required to sustain an active aircraft fleet such as the Sikorsky UH- 60 [11]. The amount of maintenance required is directly related to the total number and usage of active aircraft. In other words, the greater the air time, the greater the maintenance demand, and the greater the MRO market. The MRO involves various constituents and complex relationships. Regulatory environment plays a key role in how the activities are carried out.

This is also an illustration of the complexity of the issues, and hence the requirement for an ontology that can promote shared understanding. MRO industry requires licenses from their suppliers. A key business segment for MRO firms involves obtaining PMA licenses. PMA licenses were enacted for two purposes. First, they monitor the quality of MRO replacement or modification parts for type-certified aircraft such as the Sikorsky UH-60. Second, they ensure a supply of MRO parts for all aircraft, both military and civilian. In a recent survey conducted by A.T. Kearney’s Aerospace and Defense Practice [12], it was found that 96% of MRO respondents believed PMA parts to be among the top 10 issues facing the aerospace industry [13].

Sikorsky is the contractor and producer of the UH-60 helicopters series [12]. After each successful manufacturing, then the end product will be delivered to the military departments, who are its primary customers. However, each military department uses the helicopters for different types of missions and in different operating environments. Nevertheless, the DoD itself is able to exploit the Army facility to function as the central repair facility for all the UH-60 helicopter models. As mentioned before MRO is a complex operation involving many parties interacting in a complex fashion and therefore leads to several issues.

One of the key issues is that Sikorsky has little visibility on keeping track of each individual UH-60 record, because each military service records information differently in various flight data and maintenance log books [14]. The data is then captured as represented on forms. Each service has different form designs and records different data in terms of differences in methods and locations. Thus the Army and Sikorsky have difficulty in tracking the use and maintenance of the Navy and Army helicopters. When those helicopters arrive at the Army depot for repair, history and configuration management are investigated for security clearance. If Army does not have reliable data about those arriving helicopters at its depot, it will definitely create unnecessary and redundant replacements and exchange of parts, which will increase the operating costs and time.

In addition the Sikorsky’s UH-60 is actually subject to the minimal time required constraint. In other words, adding more human resources and additional capital to the entire project will not lead to shorter MRO time. If more resources are added to the project, it will only increase the complexity and uncertainty of the whole project because more and more factors will be accumulated, and it is very hard to identify the underlying problems because groupthink phenomena will occur if there are redundant employees are hired for a project.

There are several ways to improve Sikorsky’s UH-60 project and MRO. From a standards perspective, the government customer may adopt a top-down strategy and attempt to direct all of the services to adopt a single Information System. However, first, it has to recognize that for the Army, Navy, and Sikorsky to replace all of the disparate legacy systems is not possible, and it has to be noninvasive as possible. Alternatively, the solution would be a system of data exchange among all parties that assures accessibility to actionable data. By creating a data exchange mechanism like Enterprise Application Integration (EAI), an Enterprise Bus, or Service Oriented Architecture (SoA), a host or system neutral exchange mechanism can be provided. Such exchange mechanism would of course need unambiguous data definitions at the interface amongst other things. Sikorsky, Army, and Navy would be able to map the data required for exchange to any other qualified user in the aircraft community. Moreover, the standardization is a critical factor for the success of the whole integration process. In this case, one may use the ISO 13030, which is the Product Life Cycle Support Standard (PLCS) in defining and standardizing all the complications into one unifying and collaboration processing system. PLCS would alleviate the some discrepancies between the public sectors and the private sectors in transmitting the information.

Due to the different organizations involved in the MRO process and it complexity, it is important to arrive at the same shared conceptualization of the MRO domain between different participants. This conceptualization will be made conformant to the PLCS standard. As discussed before the domain can be represented with an ontology. This ontology can be constructed using a standards compliant language like OWL. The ontology can then be used to design information systems (for of data exchange and process standardization) across various partners involved in the Sikorsky UH-60 MRO to resolve the issues faced.

The following assumptions are made:

1) We have to assume that all the involved entities would be willing to use common models as a medium for data exchange that is applicable to most defense enterprise integration problems centered on exchanging information based on rigid standards and interfaces. For example, the Aircraft Maintenance Records entity from the ontology will have the data come from the Air Force Logistics Command (WR-ALC), Navy Air (NAVIR), Army Command (AMCOM), Suppliers, Depots, and Program Management Office (PMO).

2) The Army, the subcontractors, and the external suppliers are able to accommodate to the operating characteristics of the Navy environment in providing the manufacturing, maintenance, and restorative services. Furthermore, we have to assume that Sikorsky will still maintain a different system for its internal operating environment, because it will provide some level of flexibility for Sikorsky in servicing those non-governmental contracts. Additionally, the military services are autonomous for its culture and it may have difficulty to embrace common processes and common needs.

3) The defense industrial business information objects can be completely converted into PLCS data exchange objects (DEX) without any errors. Besides that, there are some critical improvements in the data exchange between the dependent organizations. For instance, the data exchange capabilities will be elevated between Army and Sikorsky, Navy and Army, as well as Navy with Sikorsky. Moreover, we have to assume that we have 100% knowledge about the exact scope, product information, usage characteristics, and minimum requirements of the entire aircraft industries, which appropriately comply with the standards defined by the H60 Helicopter Program and Aviation Maintenance, the Federal Aviation Administration (FAA), and the Joint Aviation Authorities (JAA).

4) The Army, Navy and Sikorsky will adopt a standard and flexible data exchange utility, which enables seamless exchange without disrupting the respective application environments.

5) The data exchange processes are human-less processes, which mostly performed by autonomous computer system. There are no duplicated data or redundancy in database reporting, the responses to the request are almost spontaneous, and the involved data exchange utilities are flexible and reworkable at minimal efforts and costs.

6) This proposed aircraft MRO ontology is general and broad enough to cover the entire aircraft industry for Army, as well as Navy. This is needed for ensuring that the ontology is still useful and can be adapted to at least other similar aircrafts.

3. Aircraft Class Hierarchy

The ontology presented here is preliminary and a work in progress. In addition this work is primarily for research purposes and not oriented towards implementation. The complexity and scope of the problem precludes a complete presentation. It however provides a good illustration of the process of constructing an ontology using OWL Language and Protégé tool [15]. Protégé is a free, open source ontology editor and a knowledge acquisition system. Like Eclipse, Protégé is a framework for which various other projects suggest plugins. It is written in Java and heavily uses Swing to create the rather complex user interface. Protégé recently has over 160,000 registered users. Protégé is being developed at Stanford University in collaboration with the University of Manchester and is made available under the Mozilla Public License 1.1. The development of the aircraft ontology starts with the identification of the aircraft we identified for the case. Actually more aircraft types and classes can be added to this existing ontology we have developed as long as they shared common attributes, which can be linked to other entities. In our case, we only choose Boeing 777 (refer to Figure 1) and Sikorsky’s UH-60 helicopter as our primary subjects for the development of the aircraft ontology. From the diagram below, we manipulated a variable, which is called Part_Type to connect the two different types of plane we investigated. It is because Sikorsky_UH-60 and Boeing_777 entities have recorded the information about the parts required for the maintenance purposes, which we will use in the later stage.

After we developed the major entities for the aircraft types, we will then further develop the sub-entities of Boeing 777 (refer to Figure 2) so that we will clearly observe the flow of the parts that are required to manufacture and to repair a Boeing 777 airplane. As we mentioned before, all the attributes (required parts and specifications) are linked to the Part_Type entity for the expansion of the entire ontology. The other aircraft type we have included for this aircraft ontology is the Sikorsky’s UH-60 helicopter (refer to Figure 3). Similar to the Boeing 777 aircraft, we derive all the relative part levelby-level from Sikorsky_ UH-60 to the Tail_Section and the Front_Section, and then those two are further divided into sub-sub-parts or components. Similarly, all the attributes (required parts and specifications) are linked to the Part_Type entity for the expansion of the entire ontology.

4. Object and Data Properties

We begin the process of capturing the domain knowledge pertinent to the repairable parts by focusing on the primary information flow. The primary objects in this partial ontology (refer to Figure 4) include air bases, air planes, types of parts, facilities and remote supply requests and

depots. As we are required to understand the exact quantities of items such as parts and aircraft, but it is necessary to create a Quantity_Of class that permits the association of a numeric count with a specific plane or part type. In this way we can say that a particular facility has a Quantity_Of instance relating a particular item with a specific number. It was also necessary to be able to associate each air base with an ordered list of remote supply facilities available to provide additional parts, which can be achieved using an Remote_Supply_Requests structure (will be connected to other variables later in the complete ontology).

Simulated data was constructed for this scenario consisting of the inventory of aircraft and parts at from different air bases and different remote supply bases taken at various times. Each event contained facility-specific information such as the quantity of good aircraft of each type, the quantity of aircraft parts in stock, and the quantity of fixable parts in stock along with the current need for parts that needed to be replaced on aircraft undergoing repair. In addition to this event data, a file of annotations was created containing descriptions of the various aircraft types and the parts that make them up, while another annotation file was constructed to provide descriptions of the specific air bases, their aircrafts and their remote supply facilities. In other words, the constructed entity relationship diagrams above will illustrate the six interrogatives of what, when, who, where, why and how, described by the Zachman Framework [16].

After understanding how the information flow between the internal aspects of the Army’s, Navy’s, and Sikorsky’s information systems, the next step we have to configure the external working environments for the maintenance requests to be delivered to the suppliers and the appointed subcontractors. First, we will implement a SCM system, which acts as a middleware for information exchange between the buyer side and the seller side. It pretty much links all the variables such as Facility, Air_ Base, Remote_Supply_Requests, Aircraft_Maintenance_ Records, SCM_Data_Repository, Distributors, and PLCS (will discuss in later section).

The topology of this SCM is defined by entities and connectors (refer to Figure 5). The entities interact with each other through the connectors as an order is fulfilled in a supply chain. Each entity performs five main actions with regard to the order life cycle, which are the creation, placement, processing, shipping, and finally receiving. Those orders are initiated based on the Remote_Supply_ Requests, placed by the Army, or the private sectors. The order transport is to be assumed with some level of processing delays. Once the requests are initiated, the order will be shipped from the supplier side to the initiation entity. Whenever the orders are received, they will be consummated immediately (no inventory for stock items).

We basically have identified the primary supply chain agents in the SCM system, and they are distributors, assemblers, Manufacturers, and suppliers (refer to Figure 6). Each connector between those entities serves as the

tracking and coordination utility for the flow of material, information, and finance in the supplier-customer network.

We will further develop the supplier network by identifying all the participating suppliers, which will contribute to the manufacturing and maintenance of the aircrafts (refer to Figure 7). In our case, we develop an interactive supplier database system for all the participating suppliers for the bidding activities to take place. Suppliers who comply with the PLCS specifications will be chosen to be the prime contractors for the Army, Navy, and Sikorsky.

Next, we have to impose the Product Life Cycle Support Standard (PLCS), ISO 10303, to map the order specifications against the aircraft maintenance records by the military users (refer to Figure 8). Thus, PLCS serves as the catching mechanism to filter the data redundancy and faulty parts, which are not appropriately, comply with the PLCS specifications. PLCS entity contains the PLCS_Data_Repository, which consists on all kinds of forms for internal processing purposes. It is needed for data exchange, visibility, and flexibility.

In addition to that, we have to consider that sometimes Army from the air bases and facilities may employ outside contractors to perform the maintenance activities, when the Army side lacks of latest knowledge and expertise. Once again, those subcontractors will be interacted with the SCM systems, to comply with the PLCS standards (refer to Figure 9), and to follow the Aircraft_ Maintenance_Records specifications from various air bases, different facilities, and at different time. Thus, we have to establish interrelated connectors between those entities.

As we connect all the partial ontologies for the maintenance of the aircraft by the Army for the Navy people, we will be able to understand the overall picture of the complete aircraft ontology (refer to Figure 10). First, we will realize that all the significant entities are actually interrelated, interoperated, and dependent in nature. Second, as we discover more factors, we have to actually increase the entities in the ontology, which in turn, increase the complexity of the ontology. Moreover, we will

be able to observe the critical path factors in the aircraft ontology that we have created, from the number of connectors that an entity has.

5. Conclusions and Future Work

An ontology can present the knowledge about a domain in a scientific and unambiguous fashion. This representation can be used for a common shared understanding by different constituents of the domain including various stakeholders and can also be used as the basis for designing information systems. Here we have presented an ontology that modifies the current domain to be standard compliant and therefore provides a solution that may alleviate some issues through design of appropriate information systems. With reference to the example issue that was discussed model-driven data exchange may be implemented as a replacement for point-to-point and hub-spoken connectivity. Additionally international standard framework for data exchange may be used so that open interoperability may be achieved and entire ontology can be expanded.

The ontology presentation in this paper is somewhat limited fashion due to issues of scope and functionality. The ontology is preliminary based on available information and may be improved. To improve the proposed ontology, more recent data would be gathered so that some unsolved exceptions can be handled effectively. Additional development spirals for the ontology and associated information systems, could be undertaken from time to time through gathering of more performance data and learned-from-experienced data from the customer satisfaction reports. Next one may focus on the efficiency and improvement of planning, problem solving, sense making, and the decision making of the maintenance activities and through timely and reliable forecasts on the arrival of those aircrafts to the maintenance facilities.

REFERENCES