Multiple aspects maintenance ontology system and method

Abstract

A Multiple Aspects Maintenance Ontology platform was developed to facilitate data acquisition from maintenance management systems, online monitoring systems, fault detection and discrimination tools, risk assessment tools, decision-making tools, and component identification tools, and accelerate the implementation and verification of contemporary maintenance optimization models and algorithms. The exemplary platform consists of a multiaspect maintenance ontology with critical information for maintenance optimization and application interfaces for collecting information from various data sources, such as fault prognosis tools, online monitoring tools, risk assessment tools, and decision-making algorithms. In addition, a heuristic method was developed for integrating concepts and properties from other existing ontologies into the exemplary platform when the existing ontology is not fully compatible with the ontology under construction.

Description

Attorney docket no.103361-567WO1 T2023-414 MULTIPLE ASPECTS MAINTENANCE ONTOLOGY SYSTEM AND METHOD Related Application

[0001] This PCT application claims priority to, and the benefit of, U.S. Provisional Patent Application No.63 / 513,970, filed July 17, 2023, entitled, “Multi Aspects Maintenance Ontology MuAMO-based Intelligent Maintenance Optimization Platform for Safety-Critical Systems,” which is incorporated by reference herein in its entirety. Background

[0002] Maintenance optimization is a process for improving the efficiency of maintenance strategies and activities, considering various aspects of the target system and components, such as the probabilities of system failures and the cost of repair and replacement of a failed component. The improvement of maintenance optimization algorithms generally requires information from various data sources. For example, it may require the system risk information derived from risk analysis tools or the residual lifetime of a component from fault prognosis tools. The requirements of data acquisition and aggregation pose new challenges for maintenance management systems that implement and use these maintenance optimization systems and methods. Summary

[0003] An exemplary maintenance optimization platform is disclosed to facilitate the establishment of a maintenance management system, which may require information related to online monitoring, reliability analysis, and risk analysis from a plurality of data sources.

[0004] The exemplary platform may operate on ontology objects or repositories that include critical information for maintenance optimization and application interfaces for collecting information from various data sources, such as fault prognosis tools, online monitoring tools, risk assessment tools, etc. In addition, the exemplary platform performs a heuristic method for merging concepts and properties from a plurality of ontology objects into other pluralities of ontology objects. The exemplary platform may be implemented for maintenance optimization for various safety-critical systems, such as nuclear power plants, avionics, and electric vehicles.

[0005] In an aspect, a non-transitory computer readable medium having instructions stored thereon for a maintenance management system, wherein execution of the instructions by aAttorney docket no.103361-567WO1 T2023-414 processor causes the processor to provide a first maintenance ontology object having classes of maintenance objects and properties from a first configuring process, wherein the maintenance ontology object includes data classes organized in a hierarchical structure of the maintenance objects and properties, including (i) a first node associated with a first class associated with properties and maintenance objects and (ii) a second node associated with a second class associated with properties and maintenance objects; receive a data from a database to add as a second maintenance ontology object to be merged with the first maintenance ontology object, wherein the received data includes at least one of maintenance objects and properties, corresponding to a field of the database; generate one or more classes of the maintenance objects and properties defined in the received data into at least a third node and a fourth node in a second hierarchical structure; merge the second maintenance ontology object into the first maintenance ontology object using a heuristic operation to generate a combined maintenance ontology object, wherein the heuristic operation includes, at least one: (i) assigning the third node or fourth node as a child of the first node or second node; (ii) assigning the other of the third node or fourth node as a parent to the first node or second node; and (store the combined ontology object to be used for subsequent query by the maintenance management system, wherein the subsequent query is related to maintenance of a platform.

[0006] In some embodiments, the first node and second node of the first maintenance ontology object include at least one of a component class, a maintenance activity class, a maintenance operation class, a failure mode class, a risk class, and a cost class.

[0007] In some embodiments, the third node and fourth node of the first maintenance ontology object include at least one of basic formal ontology (BFO) elements, Domain-specific, Open Access, Reference Ontology (ROMAIN) elements, Information Artifact Ontology (IAO) elements, and Information Entity Ontology (IEO) elements.

[0008] In some embodiments, the instructions to execute an operation with respect to the combined ontology object, or an associated repository, include instructions to provide a plurality of decision-making algorithms in the first maintenance ontology object; select, via a decision- making algorithm (e.g., look-up table), an optimal maintenance activity using a maintenance optimization operations of the first maintenance ontology object, a list of maintenance activities first maintenance ontology object, a failure mode information first maintenance ontology object, and a risk mode information first maintenance ontology object, wherein the selection employsAttorney docket no.103361-567WO1 T2023-414 presence of maintenance optimization, failure mode, risk mode; and transmit via a software interface the selected optimal maintenance activity to a maintenance management system (e.g., software platform).

[0009] In some embodiments, an ontology creation operation comprises, for each noun in the received data from the database, comparing the noun with each class in the first maintenance ontology object to determine if the noun has the same meaning as a class name, or a name associated therefrom (e.g., alias), of the respective class; link the noun to an element of the first maintenance ontology object based on the noun comparison; for each verb in the received data from the database, compare the verb with each links between classes in the first maintenance ontology object to determine if the verb has the same meaning with a link name, or a name associated therefrom (e.g., alias), of the respective link; and link the verb to an element of the first maintenance ontology object based on the verb comparison.

[0010] In some embodiments, the heuristic operation includes, for each noun in the received data from the database, comparing the noun with each class in the first maintenance ontology object to determine if the noun has the same meaning as a class name, or a name associated therefrom (e.g., alias), of the respective class; and generate an axiom in Semantic Web Rule Language of the noun and an element of the first maintenance ontology object based on the noun comparison.

[0011] In some embodiments, the heuristic operations include instructions to remove contradictions or consistencies using one or more built-in reasoner rules.

[0012] In some embodiments, the heuristic operation includes (i) assigning the third node of the second ontology as a child of the second node of the first ontology, wherein the second node is a child of the first node, and wherein the fourth node is a child of the third node; (ii) assigning the third node of the second ontology as a child of the first node of the first ontology, wherein the third node is a parent of the second node and the third node is a child of the first node, and wherein the fourth node is a child of the third node; (iii) assigning the third node of the second ontology as a child of the first node of the first ontology, wherein the second node is a child of the first node and the fourth node is a child of the second node, wherein the fourth node is a child of the third node; (iv) assigning the third node of the second ontology as a parent of the first and the second node of the first ontology, wherein the fourth node is a child of the second node, wherein the fourth node is a child of the third node; and (v) assigning the third node of theAttorney docket no.103361-567WO1 T2023-414 second ontology as a child of the first node of the first ontology, wherein the fourth node is a child of the third node and third node is a child of the first node, wherein the fourth node is a child of the third node.

[0013] In some embodiments, the hierarchical structure includes at least one of: (i) a tree structure including one or more nodes, wherein each node has at least one of a child node, a parent node, or a combination thereof; or (ii) a list structure including a prior node, a later node, or a combination thereof.

[0014] In some embodiments, the subsequent query executed by a different processor comprises receiving a query (e.g., SQWRL query) from a user or an API call, the query having one or more classes for a maintenance-related analysis that are linked to one or more other classes in the combined maintenance ontology object; matching the one or more classes of the subsequent query to nodes in the hierarchical structure of the combined maintenance ontology object; and generating or storing a value from the subsequent query.

[0015] In some embodiments, the subsequent query executed by the different processor comprises a second query, wherein the second query comprises receiving one or more values generated by the execution of the subsequent query for the maintenance-related analysis; receiving a second subsequent query (e.g., SQWRL query) from the user or another API call, the second query having a second of one or more classes for a second maintenance related analysis that are linked to the one or more other classes in the combined maintenance ontology object; matching the one or more classes of the second subsequent query to nodes in the hierarchical structure of the combined maintenance ontology object; and generating or storing a value from the second subsequent query.

[0016] In some embodiments, the value from the second subsequent query includes at least one of (i) components or subsystems to be maintained in the system; (ii) available maintenance activities for a component; (iii) a failure mode's cost (e.g., risk); (iv) a most efficient maintenance activity; (v) a most critical part of the system and / or component; (vi) feasible maintenance activities for a budget; and (vii) a maximum obtainable improvement of system safety.

[0017] In some embodiments, the maintenance objects and properties of the data classes include component state information, monitoring technology information, signal information, performance level information, data acquisition (DAG) information, risk information, initiatingAttorney docket no.103361-567WO1 T2023-414 event information, accident condition information, accident sequence information, event tree information, and fault tree information. Brief Description of the Drawings

[0018] FIG.1 shows an example development and implementation of the exemplary maintenance optimization platform.

[0019] FIG.2 shows an example ontology object (i.e., repository).

[0020] FIG.3 shows an example operational flow of the exemplary platform.

[0021] FIG.4 shows an example maintenance ontology.

[0022] FIGs.5A – 5C show an example algorithm for collecting data from ontology object / repository and evaluating maintenance activities.

[0023] FIGs.6A – 6G show information queries addressing competency questions and selecting information of interest from properties and concepts in ontology objects / repositories.

[0024] FIGs.7A – 7E show example ontology development methodologies combining ontology objects.

[0025] FIG.8A shows an example architecture of the exemplary platform.

[0026] FIG.8B shows example dependencies between various platform concepts (i.e., views).

[0027] FIGs.9A – 9B show an example experiment testing the exemplary platform on a solenoid-operated valve (SOV). Detailed Description

[0028] Some references, which may include various patents, patent applications, and publications, are cited in a reference list and discussed in the disclosure provided herein. The citation and / or discussion of such references is provided merely to clarify the description of the disclosed technology and is not an admission that any such reference is “prior art” to any aspects of the disclosed technology described herein. In terms of notation, “[n]” corresponds to the nth reference in the list. For example, [1] refers to the first reference in the list. All references cited and discussed in this specification are incorporated herein by reference in their entirety and to the same extent as if each reference was individually incorporated by reference.Attorney docket no.103361-567WO1 T2023-414

[0029] Fig.1 shows the development and implementation of the exemplary platform. Specifically, the ontology development methodology 102 includes merging a plurality of ontology objects / repositories to create a combined ontology object / repository.

[0030] Maintenance ontology algorithms 104 then collect data from various data sources 106 (e.g., databases, data acquisition systems, etc.) and records the data in the combined ontology object. Information queries 108 (e.g., failure mode’s cost query, etc.) then derive the information of interest from the combined ontology object.

[0031] The exemplary platform develops ontology objects / repositories using various methods and derives information from ontology objects / repositories. An ontology object / repository, as shown in Fig.2, generally has a tree structure - a collection of nodes connected by directed or directed links. In an ontology object, classes (i.e., nodes) are connected with one another by properties (i.e., links).

[0032] Fig.3 shows the operation flow 300 of the exemplary platform, which generally includes 4 steps. At step 302, the exemplary platform provides a first ontology object having classes of concepts and properties from a first training / configuring process.

[0033] At step 304, the exemplary platform receives a data from a database to add as a second ontology object to be merged with the first ontology object.

[0034] At step 306, the exemplary platform generates one or more classes of the concepts and properties defined in the received data into at least a third node and a fourth node in a second ontology object.

[0035] At step 308, the exemplary platform stores the combined ontology object to be used for subsequent queries, wherein the subsequent queries are related to maintenance.

[0036] Example implementation of maintenance optimization platform:

[0037] Tools and Interfaces. The MuAMO may be implemented by a plurality of tools to provide maintenance recommendations to users. Fig.4 shows an example of maintenance ontology implemented in an ontology editor (e.g., Protégé) with built-in reasoners that implemented the MuAMO in the exemplary platform. Protégé supported the Semantic Web Rule Language (SWRL)

[0027] for defining the hierarchical structure 400A between the classes (i.e., concepts) and properties in an ontology object. The example maintenance ontology shows the class and properties of the maintenance ontology in relation to an inquiry, e.g., of Fig.6C.Attorney docket no.103361-567WO1 T2023-414

[0038] In Fig.4, Protégé demonstrates all failure modes of a maintainable component (not shown) in the system as the structure 400A. In the structure 400A (i.e., ontology object), the “Failure Mode” class 402 (also referred to as 402’) is a direct parent of a plurality of classes including “Filter Failure Mode” class 404, “Sensor Failure Mode” class 406, and “Valve Failure Mode” class 408 (also referred to as 408’). The “Valve Failure Mode” class 408 is a direct parent of a plurality of classes including “leafspring decrease of stiffness” class 410 and “seal wearing out” class 412 (also referred to as 412’), which indicates that the “Failure Mode” class 402 is an indirect parent of the “leafspring decrease of stiffness” class 410 and “seal wearing out” class 412.

[0039] In Fig.4, Protégé was utilized to develop the MuAMO by reusing the existing ontologies, adding and managing new concepts (i.e., classes), and checking for inconsistencies that may occur during the insertion of new concepts and properties. Specifically, the “Description” window 400B was utilized to generate ontology classes in the structure 400A including the “Failure Mode” class 402’, the “seal wearing out” class 412’, and the “Valve Failure Mode” class 408’. The “Property assertions” window 400C was utilized to generate and manage the properties (i.e., relationships) between the classes in the structure 400A, including “has risk” 414, “cause loss” 416, and “has failure rate” 418. Additionally, the “Annotations” window 400D was utilized to generate annotations for each class (i.e., concepts) in the structure 400A.

[0040] The interfaces of the exemplary platform were implemented using the Python programming language and the OWLReady2 library

[0035] . OWLReady2 provided packages for modifying and saving ontologies and performing reasoning. The library was optimized for managing an ontology repository with a large number of classes and instances. OWLReady2 included an API for connecting to external databases, and the library was used

[0020] as a default reasoner. A plurality of technical solutions (e.g., pipelines, network sockets, file systems) was used with the APIs provided by the OWLReady2 library to implement the interactions with external tools. For example, a reinforcement learning-based maintenance optimization algorithm

[0049] may be executed in a process running in parallel with the exemplary platform. By using the APIs of the OWLReady2 library, a well-formatted file may be generated, which includes all the parameters required by the optimization algorithm (e.g., the information on components and online monitoring data). The exemplary platform may prepare the required file and launch theAttorney docket no.103361-567WO1 T2023-414 algorithm. After the execution of the algorithm, the output result was fed to the ontology object through the APIs as well. For example, the output file with the optimal maintenance activity was parsed by the APIs and then recorded by the ontology repository. For the maintenance management view, when the existing maintenance management system was running remotely, i.e., running on another computer with network connections, an adapter may be implemented by using the APIs to feed information to the ontology platform. Meanwhile, the adapter may use the interfaces provided by the maintenance management system to obtain the required information. In practice, any algorithms or tools providing automation interfaces may be integrated with the exemplary platform.

[0041] Various embodiments may be performed in a pipeline or in a manual set of operations.

[0042] Example Information Processing Algorithms. The exemplary platform includes information processing algorithms to collect information for various views defined by MuAMO and provide maintenance recommendations to the users.

[0043] Fig.5A shows a maintenance algorithm 500A that runs periodically to change the maintenance strategies dynamically. The algorithm may be triggered using a fixed period (e.g., every second or every minute) depending on the type of the component being maintained or by specific events (e.g., new online monitoring data is received in interrupt-based systems).

[0044] Specifically, the maintenance algorithm 500A starts by receiving a list of maintainable components in a target system using function 502.

[0045] For each maintenance component (mc) in the list of maintainable components, function 504 collects maintenance activities that may be applied to the target system.

[0046] Function 506 collects decision-making (DM) algorithms that may be applied to the target system using the mc and the maintenance activities.

[0047] Function 508 then checks whether a system failure information is required. When the system failure information is required, function 510 calculates the failure information using the DM algorithms and the mc.

[0048] Function 512 then checks whether risk information is required. When the risk information is required, function 514 calculates the risk information using the DM algorithms and the mc.Attorney docket no.103361-567WO1 T2023-414

[0049] Function 516 selects an optimal maintenance activity using the DM algorithms, the maintenance activities, the failure information, and the risk information.

[0050] When the optimal maintenance activity is not null, function 518 updates a maintenance strategy using the optimal maintenance activity.

[0051] Fig.5B shows algorithm 500B, which calculates the failure information for function 510 in the algorithm 500A. The algorithm 500B receives the DM algorithms and the cm as its inputs from the algorithm 500A.

[0052] The algorithm 500B starts with functions 520, 522, and 524. Specifically, function 520 collects a list of functions related to the cm. Function 522 collects a list of measures required by the DM algorithm. Function 524 creates an empty list.

[0053] For each function (fn) in the list of functions related to the cm, function 526 collects a list of failure modes. For each failure mode (“fm”) from the list of failure modes, function 528 calculates a list of measure values using the list of measures from function 522.

[0054] When the list of measure values is not null, function 530 adds a tuple of three, including the fn, the fm, and the list of measure values, to the empty list created by function 524. The algorithm 500B returns the list of tuples as an output to the algorithm 500A.

[0055] Fig.5C shows an algorithm 500C that calculates the risk information for function 512 in the algorithm 500A. The algorithm 500C receives the DM algorithms and the cm as its inputs from the algorithm 500A.

[0056] The algorithm 500C starts with functions 532 and 534. Specifically, function 532 generates a list of event trees for the system. An event tree includes subsequent events that occur in the system. Function 534 generates a list of fault trees for the system. A fault tree includes cause events that occur in the system.

[0057] For each event tree (et) in the list of event trees, function 536 extracts a list of initial events from the et. For each initial event (“ie”) of the et, function 538 updates the probability of the initial event.

[0058] For each fault tree (ft) in the list of fault trees, function 540 extracts a list of basic events from the ft. For each basic event (be) from the list of basic events, function 542 updates the probability of the basic event.Attorney docket no.103361-567WO1 T2023-414

[0059] Function 544 obtains system risk information using the list of event trees and the list of fault trees. The algorithm 500C then returns the system risk information to the algorithm 500A as the output.

[0060] Generally, the functions 502, 504, 506, 508, 510, 512, 514, 516, 518,520, 522, 524, 526, 528, 530, 532, 534, 536, 538, 540, 542, and 544 are implemented by directly inquiring about the ontology repository or calling the interfaces of the views in MuAMO.

[0061] Example Information Queries. The exemplary platform should use information queries to select information of interest from the data collected by the algorithms 500A – C from the ontology object / repository. This is because the collected data may not directly be used by maintenance optimization systems or be referenced by the users for decision-making.

[0062] In some embodiments, the ontology employed SQWRL, an SWRL-based information query language

[0027] , for eliciting data from ontology repositories. SQWRL provides basic arithmetic and Boolean operators, which may be used to acquire data based on logic expressions. Generally, an ontology query engine, e.g., HermiT

[0020] may parse the SQWRL expressions and can derive the associated results.

[0063] Figs.6A – 6G show SQWRL information queries addressing competency questions to derive information of interest of a system (e.g., solenoid valve) from an ontology object or repository. A competency question determines a requirement that a query should satisfy. A query may comprise a plurality of expressions, wherein each expression may present a class instance (e.g., “Component,, “Maintenable_Item,” etc.) or a relationship (e.g., “has a,” “is a,” “causes,” “requires a,” etc.). An output expression (i.e., the expression on the right of “ ^”) of a query may be used in other subsequent queries.

[0064] Additionally, expressions in the queries shown in Figs.6A – 6G use one or more variables (i.e., parameters) including (i) “a” representing all activities in the system, (ii) “f” representing a failure mode, (iii) “r” representing a corresponding risk associated with the failure mode, (iv) “q” representing the failure quotient (i.e., probability) at which a failure mode will occur, (v) “l” representing the loss caused by the failure mode, (vi) “s” representing system safety, (vii) “v” representing system value, (viii) “m” representing maintenance activities, (ix) “e” representing equipment, and (x) “x” representing the components / subsystems that need to be maintained in the system.Attorney docket no.103361-567WO1 T2023-414

[0065] Fig.6A shows a query 600A retrieving maintainable components / subsystems in the system (e.g., solenoid valve) from the ontology object / repository. The query 600A should address a competency question: “Which components / subsystems need to be maintained in the target system?”. In other words, the query 600A retrieves components or subsystems that need to be maintained (i.e., under analysis) in the system when a list of maintainable items (e.g., components, subsystems) from the ontology object has one or more components or subsystems.

[0066] In the query 600A, expression 602 identifies all instances (e.g., components) of the class “Component,” expression 604 identifies all instances (e.g., items) of the class “Maintenable_Item,” expression 606 computes a result of the “has a” relationship between the system and components (i.e., the system has any components), and output expression 608 identifies all the components that are under analysis (i.e., components that need maintaining) in the system. After the expressions 602, 604, and 606 are executed, the output expression 608 will run.

[0067] Fig.6B shows a query 600B retrieving available maintenance activities for a component from the ontology object / repository using the output expression 608 from query 600A. The query 600B should address a competency question, “What are the available maintenance activities for the target component?”. In other words, the query 600B searches for the maintenance activities whose target component is one of the target system’s components.

[0068] The query 600B contains the expressions related to equipment and people since some of the maintenance activities may require specific equipment or people to conduct them. Specifically, expression 610 identifies all instances (e.g., activities) of the class “Maintenance_Activity”, expression 612 computes a result of the “has a” relationship between the system and the maintenance activity (i.e., the system and the maintenance activity has a shared target component), expression 614 identifies all instances (e.g., equipment) of the class “Maintenance_Equipment”, expression 618 computes a result of the “requires a” relationship between the maintenance activity and the equipment (i.e., the maintenance activity requires the equipment), expression 620a identifies a total count of the equipment using a built-in SQWRL function “count”, expression 620b identifies a total count of staff (i.e., workers) using the built-in SQWRK function “count”, expression 622 identifies all instances (e.g., teams) of the class “Maintenance_Team”, expression 623 computes a result of the “requires a” relationship between the maintenance activity and the staff (i.e., the maintenance activity require a team of staff), andAttorney docket no.103361-567WO1 T2023-414 output expression 624 identifies all the applicable maintenance activities in the system. After the expressions 610, 612, 614, 618, 620a, 620b, 622, and 623 are executed, the output expression 624 will run.

[0069] Fig.6C shows a query 600C retrieving a cost / risk of a failure mode from the ontology object / repository using the output expression 608 from query 600A. The query 600C should address a competency question: “What is each failure mode’s cost (i.e., risk)?”. In other words, the query 600C calculates a failure mode’s cost (i.e., risk) for every component that needs to be maintained (i.e., under analysis) in the system.

[0070] A cost (i.e., risk) associated with an occurrence of particular failure modes may be acquired from the connection relationship between a failure view and a risk view. In the query 600C, the expressions together calculated the risk by multiplying a failure rate and a financial loss (dollars / year). Specifically, expression 632a computes a multiplication of risk, failure quotient, and loss, wherein (i) the risk is identified by expression 626 as a result of the “has a” relationship between the system and the failure mode (i.e., the system has a failure mode), (ii) the failure quotient is identified by expression 628 as a result of the “has a” relationship between the failure mode and the failure rate (i.e., the failure mode has a failure rate), and (iii) the loss is identified by expression 630 as a result of the “causes a” relationship between the failure mode and the loss (i.e., the failure mode causes a loss). Output expression 634 computes a result of the “has a” relationship between the system, the failure mode, and the risk (i.e., the system has a cost or risk associated with the failure mode). The output expression 634 will run after the expressions 608, 626, 628, 630, and 632a are executed.

[0071] A maintenance activity is the most efficient maintenance activity (MEMA) when it decreases the risk of the target system in the system’s on-going state the most. Assume that in the on-going state, the failure rates of some subsystems (e.g., seal, leaf spring, etc.) are both one failure / year and that inspecting a component does not impact its failure rate, and replacing a component restores its failure rate to its initial value, so MEMA may be calculated per Equation 1. ^^ ^^ ^^ ^^ ൌ ^^ ^^ ^^ ^^ ^^ ^^ ൬^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ െ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^^(Eq.1)Attorney docket no.103361-567WO1 T2023-414

[0072] Fig.6D shows a query 600D that retrieves the MEMA from the ontology object / repository using the output expression 608 from query 600A, the output expression 624 from query 600B, and the output expression 634 from query 600C. The query 600D should address a competency question, “What is the most efficient maintenance activity?”. In other words, the query 600D computes the MEMA based on Equation 1 using the output expressions from the queries 600A – 600C.

[0073] The query 600D uses the outputs produced from the output expressions 608, 624, 634, and additional expression 635 as the variables (i.e., parameters) in built-in multiply function 632b, built-in subtract function 636, and built-in divide function 638. Specifically, the query 600D calculates the risk before maintenance and risk after maintenance using function 632b, then subtracts the risk after maintenance from the risk before maintenance using function 636. The query 600D then divides the subtraction result by the maintenance cost using function 638 before finding the MEMA using function 640 on the division result. The final calculation result will be stored and displayed by an output expression 642. Additionally, the additional expression 635 used in the query 600D computes a result of the “has a” relationship between the failure mode and the maintenance cost (i.e., the failure mode has a maintenance cost).

[0074] Each query 600A, 600B, 600C, and 600D addresses a corresponding competency question. However, when the queries 600A, 600B, 600C, and 600D are used sequentially together to generate a concatenated query, the concatenated query addresses an overall competency question: “To decrease the risk of the target system, what is the most efficient applicable maintenance activity?”.

[0075] The most critical part of a component may contribute the most risk to the system or lead to the costliest maintenance. The exemplary platform defines the criticality of a component by the sum of the risks and maintenance costs related to the component.

[0076] Fig.6E shows a query 600E retrieving the most critical part of a component from the ontology object or repository using the output expression 608 from query 600A and the output expression 634 from query 600C. The query 600E should address a competency question: “Considering maintenance costs and system risks, what is the most critical part of the target system / component?”. In other words, the query 600E identifies the most critical part of the system by computing the sum of risk and maintenance costs of every component in the system and choosing the component with the highest sum.Attorney docket no.103361-567WO1 T2023-414

[0077] In addition to the output expressions 608, 624, and 634 from the previous queries 600A – 600C and the additional expressions 612 and 626, the query 600E uses expression 637 to compute a result of the “has a” relationship between a maintenance activity and the system value and expression 644 to compute a result of the “has a” relationship between the system and the part (i.e., the system has a critical composite part). The query 600E also uses built-in functions 640 and 648 to compute the most critical component part in an output expression 650. The output expression 650 will run after the expressions 608, 624, 612, 626, 634, 637, 640, 644, and 648 are executed.

[0078] Fig.6F shows a query 600F retrieving the feasible maintenance activities for a given budget from the ontology object / repository using the output expression 608 from query 600A and the output expression 624 from query 600B. The query 600F should address a competency question: “What are the feasible maintenance activities for a given budget?”. In other words, the query 600F selects maintenance activities that share a target component with the system and have a maintenance cost within a provided budget.

[0079] In addition to the output expressions 608, 624, and 637 from the previous queries, the query 600F uses a built-in function 654 to compare the maintenance cost with the provided budget. The output expression 656, containing all eligible maintenance activities, may run after the expressions 608, 624, 637, and 654 are executed.

[0080] Fig.6G shows a query 600G deriving the maximum improvement of system safety from the ontology object / repository using the expression 642 from the query 600D and the expression 656 from the query 600F. The query 600G should address a competency question: “What is the maximum improvement of system safety that can be obtained at this time?”. In other words, the query 600G selects the most efficient maintenance activity at the time using the output expressions 608, 624, and 634 from the queries 600A – 600C. The query also used additional expressions 626, 634, 635, and 630 and built-in functions 632b, 640, and 644b are also included in the previous queries. An output expression 658 will run after all the expressions and built-in functions in the query are executed.

[0081] Each query 600F, 600G addresses a corresponding standalone competency question. However, when the queries 600F and 600G are used sequentially together to generate a concatenated query, the concatenated query addresses an overall competency question: “What isAttorney docket no.103361-567WO1 T2023-414 the best improvement to system safety in terms of all feasible maintenance activities for a given budget?”.

[0082] Example ontology development methodology:

[0083] An ontology development methodology is used for establishing the exemplary platform. The method for creating classes and properties is based on existing standards and reports. The outcome of the ontology development method is the maintenance ontology platform with its associated views.

[0084] The ontology development methodology defines the steps and the pathway to design, implement, and verify a domain-specific ontology. The development of the maintenance ontology follows an ontology engineering approach which includes the following steps

[0041] .

[0085] Step 1 – Determine the domain and scope of the ontology.

[0086] Generally, an ontology is developed to solve a series of problems for a specific type of target system or a specific domain

[0041] . Based on the ontology engineering approach

[0041] , the ontologies should support maintenance optimization and related tasks per Table 1. Table 1 Extract and record information generated during the phase of system design (e.g., , g

[0087] Since the ontology facilitates the development of the exemplary platform, the ontology also should address the following competency questions that are used as necessaryAttorney docket no.103361-567WO1 T2023-414 criteria for verifying the completeness of the ontology, e.g., per Table 2, as a non-limited set of examples. Other questions and inquiries can be addressed. Table 2 To decrease the risk of the target system, what is the most efficient maintenance activity? Considering maintenance costs and system risks what is the most critical part of the targetp g g g .

[0089] Plurality of domain ontologies was developed to solve knowledge representation and sharing issues. Reusing existing ontologies may save time and maximize compatibility with other existing ontologies. However, reusing terms in one domain may cause inconsistencies or contradictions since the terms commonly used in different domains may have different meanings and explanations.

[0090] There may be benefits in reusing existing ontologies and integrating existing ontologies into MuAMO, including (1) unifying terms and concepts that are accepted by experts and professionals, (2) reusing the concepts and constraints defined by other ontologies, and (3) making MuAMO being easily integrated into other ontologies or easily reused by other ontologies. Additionally, there may be several disadvantages of reusing existing ontologies and integrating existing ontologies into MuAMO, including (1) accepting predefined terms that lead to loss of flexibility, (2) causing inconsistencies and contradictions, and (3) introducing a large number of unused concepts and terms.

[0091] By considering the problems that may be encountered, existing ontologies are carefully evaluated to ensure their compatibility with the field of maintenance. Table 3 summarizes the domain ontologies considered for reuse in the exemplary platform. Upper-level ontologies are also investigated for consideration in the MuAMO since these ontologies provide meta-concepts and properties useful for bridging concepts defined in different domain ontologies. Table 3 Domain Descriptions Existing OntologiesAttorney docket no.103361-567WO1 T2023-414 System The ontologies represent ^ Industrial Maintenance Management Ontology Maintenance maintenance strategies, (IMAMO)

[0030] – an ontology for general y f tAttorney docket no.103361-567WO1 T2023-414 Upper-Level The ontologies define high- ^ Basic Formal Ontology (BFO) [6] - an upper- Ontologies level concepts that guarantee level (formal, domain-neutral) ontology to supportp y g p g g knowledge between research domains, such as The Basic Formal Ontology (BFO)

[0045] , The Suggested Upper Merged Ontology (SUMO)

[0040] , Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE)

[0019] , etc. Since the plurality of reused ontologies are compatible with BFO, the exemplary platform may also be built based on BFO

[0045] .

[0093] Since some of the ontologies do not use BFO

[0045] as their meta ontology (i.e., some of the ontologies are not compatible with BFO), the existing ontology integration methods may not be applicable; hence reusing and integrating the concepts and relations in such ontologies requires extra efforts to prevent inconsistencies and conflicts. Therefore, a heuristic method to integrate portions of the existing domain ontologies into the MuAMO was developed to minimize the changes in the relations between the concepts in MuAMO and the concepts in the integrated ontology.

[0094] Assume that the ontology of the exemplary platform ^^ = { ^^, ^^} contains a set of concepts ^^ = { ^^1, …, ^^m} (i.e., classes) and properties ^^ = {r1, …, rn} (i.e., links), wherein ^^ represents a class and ^^ represents a property (i.e., a link). If ^^ is the set of all “is_a” links between two classes, the notation ^^( ^^i, ^^j) or ^^i,jdenotes that an “is_a” link exists between class ^^iand class ^^j, i.e., class ^^i is the parent class of class ^^j. The heuristic method requires the following definitions:

[0095] Definition 1: Function ℒ ( ^^i, ^^j): ^^ x ^^ → ^^ returns the set of links ^^ which starts at ^^iand ends at ^^j. Based on this definition, the notation ℒ ( ^^i, *) represents the set of links starting from ^^i, and ℒ (*, ^^j) represents the set of links ending at ^^j.Attorney docket no.103361-567WO1 T2023-414

[0096] Definition 2: Function ^^( ^^i): ^^→ ^^ returns the descendants of class ^^i. The descendants include all the subclasses of class ^^i, all the subclasses of these subclasses, and so on.

[0097] Definition 3: Function ^^S( ^^i): ^^→ ^^ returns the direct descendants (children) of class ^^i. The direct descendants include only the subclasses of class ^^i.

[0098] Definition 4: Function ^^( ^^i): ^^→ ^^ returns the ancestors of class ^^i. The ancestors include all the parent classes of class ^^i, all the parent classes of these parent classes, and so on.

[0099] Definition 5: Function ^^S( ^^i): ^^→ ^^ returns the direct ancestors (parents) of class ^^i.

[0100] Definition 6: Top Nodes ^^( ^^) returns the set of top classes in the class set ^^ so that ∀ ^^ ∈ ^^, ^^ ∈ ^^( ^^) if ^^S( ^^) = ∅.

[0101] Definition 7: Block ^^ = { ^^, ^^}, ^^ ⊆ ^^, ^^ ⊆ ^^, ℒ ( ^^i, ^^j) ≠ ∅, ^^ℎ ^^ ^^ ^^ ^^i ∈ ^^, ^^j ∈ ^^, ^^i ≠ ^^j. The notation means that all the classes in a block are linked, i.e., there is at least one from or ending at every concept. Generally, an ontology ^^ can be divided into various block sets ^^ = { ^^1, …, ^^l}. For each ^^iin ^^, ^^( ^^i) = { ^^T} has only one element, which is the top class in block ^^i.

[0102] Definition 8: Minmax block set ^^^^is a block set in which there is no link between the concepts belonging to different blocks. ^^^^= { ^^1, …, ^^l}, ℒ ( ^^i, ^^j) = ∅, ^^i∈ ^^x, ^^j∈ ^^y, ^^x ∈ ^^ ^^, ^^y ∈ ^^ ^^, ^^ ≠ ^^.

[0103] Assume that the new ontology with new concepts and links ^^′ = { ^^′, ^^′} will be integrated into the ontology ^^ = { ^^, ^^}. The Minmax block set of the new ontology ^^′ is ^^’ ^^ = { ^^’1, …, ^^’l}. Then, the integration process may be classified into the following cases:

[0104] Case 1: for each ^^’i in ^^’ ^^, no common class between ^^’i and ^^ exists, i.e., ^^′ ∩ ^^ = ∅, ^^′ ∈ ^^’i. In this case, the top class ^^( ^^’i) is selected first to be integrated into the ontology ^^. Identify the concept ^^0that is closely related to the top class ^^( ^^’i) and add the top class as the subclass of ^^0by adding the relation ^^( ^^0, ^^( ^^’i)). Then, the other classes and relations in ^^’imay be added to the ontology ^^.

[0105] Fig.7A shows an example case 1 where a block of classes ^^’i(referred to as second ontology) is integrated into the existing ontology ^^ (referred to as first ontology). The block ^^’i = { ^^′, ^^′} contains six classes ^^′ = { ^^^ᇱ, … , ^^^ᇱ} and their relations (referred to as links) ^^′ = { ^^^ᇱ,ଶ, ^^^ᇱ,ଷ, ^^ଶᇱ,ସ, ^^ଶᇱ,ହ, ^^ଷᇱ,^}. The top class ^^( ^^’i) = { ^^^ᇱ}. In this case, the top-class ^^^ᇱcan beAttorney docket no.103361-567WO1 T2023-414 integrated into the ontology ^^ first. In Fig.7A, the class ^^ଷis selected as the parent class of ^^^ᇱ, then the relation ^^( ^^ଷ, ^^^ᇱ) is added into the ontology ^^. Finally, the set of classes and relations of block ^^’iare added to the ontology ^^.

[0106] Additionally, the class ^^^ᇱmay never be the top class of the ontology ^^ since the ontology ^^ defined by the platform uses BFO

[0045] as the meta ontology.

[0107] Case 2: a common class ^^^ᇱexists between ^^’i and ^^, ^^′ ∩ ^^ = { ^^^ᇱ^, ^^′ ∈ ^^’i. This case may be further classified into two cases: case 2.1 - { ^^^ᇱ^ = ^^( ^^’i) (i.e., ^^^ᇱis a top class of block ^^’i), and case 2.2 - { ^^^ᇱ^ ≠ ^^( ^^’i) (i.e., ^^^ᇱis not a top class of block ^^’i). Table 4 Case 2.1 { ^^^ᇱ^ = ^^( ^^’i). In this case, the other classes { ^^ଶᇱ, … , ^^^ᇱ} and relations (i.e., li k i ^^’ h l ^^ f ll i h i e ,

[0108] Case 3: more than one common class exist between ^^ and ^^, ^^′ ∩ ^^ = { ^^^ᇱ, … , ^^௧ᇱ}, ^^′ ∈ ^^’i. This case may be further classified into two following cases: Table 4BAttorney docket no.103361-567WO1 T2023-414 Case 3.1∄rᇱ൫c^ᇱ, c୨ᇱ൯, c୧ᇱ∈ C, c୨ᇱ∈ C, r൫c^ᇱ, c୨ᇱ൯ ∈ ℛ (i.e., no common link exists in both^^’i (referred to as second ontolo ) and ^^ (referred to as first ontolo )) , . o

[0009] Step 3 – numerate important terms in the ontology.

[0110] Since the MuAMO is used to model and manage knowledge for maintenance optimization, the terms describing concepts and relations related to this target need to be included in the ontology. This step collects and determines the important terms widely used in the target domain.

[0111] Step 3 may be further divided into a plurality of smaller steps.

[0112] Step 3.1: Locate descriptions of key concepts, definitions, restrictions, or dependencies in the target document.

[0113] Step 3.2: Select the terms denoting the key concepts or relations in the target domain.

[0114] Step 3.3: Iterate on the selected terms ^^0. Table 4C Step 3.3.1 For each noun, compare it with the classes ^^ already in the ontology ^^.Attorney docket no.103361-567WO1 T2023-414 meaning is closest to the new term and define the new term as a subclass of it ℒ(ci, ^^0) = { ^^( ^^i, ^^0)}. d

[0115] Example for steps 3.1-3.3: the sentence …Maintenance techniques can also check the status of components that are not malfunctioning and seek to increase the interval of inspection ...” is extracted from a maintenance optimization document and is selected since it contains key concepts and relations in the maintenance domain.

[0116] In step 3.1, the key terms “Maintenance techniques,” “components,” “status of components,” “malfunctioning,” “inspection,” “interval of inspection,” “check,” “seek,” and “increase” are included in the sentence. In step 3.2, the terms “Maintenance technique”, and “component” are already defined in the exemplary platform. The term “status of component” is defined as an alias for “state of component,” and the term “malfunctioning” is defined as an alias of “failure.” The term “inspection” is defined as a child class of “Maintenance activity,” and the term “interval of inspection” is already defined by the class “Maintenance time interval” based on an expert’s knowledge. The term “check” builds the relationship between the concepts of “maintenance technique” and “status of components” initially. But later, this relationship can be revised to be the link between the concepts “maintenance team” and “maintainable item” in Step 3.3. The terms “seek” and “increase” are pruned since these relations are already represented by other links in the proposed ontology.Attorney docket no.103361-567WO1 T2023-414

[0117] Step 3.4: Refine the established ontology. Table 4D Step 3.4.1 Remove contradictions or inconsistencies by using the ontology built-in reasoners

[0020] . (Inconsistencies may exist between different documents; n e[ ] tep . : a ate t e esta s e onto ogy. ec a t e ey concepts, rules and constraints have been covered.

[0119] An important concept or relation generally appears multiple times in a standard or document. Sentences or paragraphs containing the key concepts, definitions, restrictions, or dependencies described using nouns or verbs may be selected. When there is no sentence or paragraph that describes the important concepts, definitions, restrictions, or dependencies using nouns or verbs, the sentence or paragraph may be rewritten, and the above steps may be applied.

[0120] Step 3 identifies the terms and relations that need to be integrated into the MuAMO. The following steps perform the integration in which the corresponding classes, properties, and facets are defined.

[0121] Step 4 – Define classes, properties, and facets.

[0122] Several terms and concepts are collected by applying steps 2 and 3 to the industrial standards and guidelines, and their corresponding ontology classes are established.

[0123] The properties and facets link the classes established in MuAMO and define constraints for using these classes. MuAMO reuses several properties defined by the existing ontologies, e.g., Fault Ontology (FO)

[0012] , Domain-specific, Open Access, Reference Ontology (ROMAIN)

[0029] , Information Artifact Ontology (IAO) [9], etc.

[0124] Step 5 – Create instances.Attorney docket no.103361-567WO1 T2023-414

[0125] Creating instances for an ontology is applying the ontology to a practical problem.

[0126] Example structure of maintenance optimization platform:

[0127] Using the exemplary ontology development methodology, a maintenance optimization platform may be created to collect, represent, manage, and maintain the knowledge that will be used, synthesized, inferred, and verified during the maintenance optimization process. Fig.8A illustrates the architecture of the exemplary maintenance optimization platform with its related external tools or algorithms. In Fig.8A, the maintenance optimization platform 800A consists of MuAMO 802 (i.e., the maintenance optimization ontology) and a plurality of interfaces (referred to as IF). The concepts in the MuAMO 802 are categorized into six views, including the Asset & Component View (ACV) 804, the Function & Failure View (FFV) 806, the Online Monitoring View (OMV) 808, the Risk Assessment View (RAV) 810, the Decision- Making View (DMV) 812, and the Maintenance Management View (MMV) 814.

[0128] Knowledge and information are shared between these views. One view may include several concepts that depend on the concepts in other views. For example, the maintenance costs included by various maintenance strategies and the system risk caused by system failures recorded by the MMV 814 and the RAV 810, respectively, may be required by the decision-making algorithms in the DMV 812 to select the most efficient maintenance activity. In the exemplary platform 800A, the failures of system components and the maintenance activities may be correlated through the concepts related to risk assessment.

[0129] In detail, the failures of system components are quantified by their probabilities and further quantified by the risk caused by these failures. On the other hand, maintenance activities may impact the failure rates of the components under maintenance and further impact the risk after each maintenance activity. However, the exemplary platform implemented the information flow through these concepts and recorded / updated the corresponding information in real-time. The quantification involved in the information flow, such as the calculation of the failure rates of the components under maintenance, is performed by external tools. This mechanism provides flexibility in the integration of various tools related to maintenance optimization.

[0130] Each view in the exemplary platform possesses an application programming interface (API) that implements the communications between the MuAMO ontology and other external tools or algorithms. Fig.8B shows an example of dependencies between various viewsAttorney docket no.103361-567WO1 T2023-414 using a portion of the critical concepts in each view. In addition to reused classes from other ontologies, Table 5 shows some of the critical classes defined in the MuAMO. Table 5 Class Name Parent Class Description MuAMO:Component ROMAIN:State The state concept is extended to component g d t, sAttorney docket no.103361-567WO1 T2023-414 MuAMO:Event Tree IAO:Directive A quantifiable, logical network that begins Information Entity with an initiating event or condition and s. g

[0131] EXPERIMENTAL RESULTS AND ADDITIONAL EXAMPLESAttorney docket no.103361-567WO1 T2023-414

[0132] A study was conducted to develop a maintenance optimization platform to facilitate data acquisition from maintenance management systems, online monitoring systems, fault detection and discrimination tools, risk assessment tools, decision-making tools, and component identification tools and accelerate the implementation and verification of contemporary maintenance optimization models and algorithms. The exemplary platform includes a multi-aspect maintenance ontology (i.e., MuAMO) with information for maintenance optimization from various data sources.

[0133] The exemplary maintenance optimization platform was verified using solenoid- operated valves (SOVs) in a hardware-in-the-loop (HIL) experimental setup. Solenoid-operated valves (SOVs) were used in nuclear power plants (NPPs) in pneumatic circuits that were utilized to control and operate important actuators, such as those used to move and position control rods. Fig.9A shows a hardware-in-the-loop experimental system emulating the feedwater system on the secondary side of a pressurized water reactor (PWR). The target component, a solenoid- operated proportional flow control valve (i.e., SOV), acted as the feedwater flow control valve. The SOVs in the system were flow control valves and were not pressure control valves.

[0134] Components and structures. Fig.9B shows the structure and the components of the SOV 900B, including seal 902, leaf spring 904, inlet port 906, base 908, and plunger 910. The study developed several failure modes and calculated the initial failure rate for each failure mode of the solenoid valves. Specifically, example failure modes are provided in Table 6. Table 6 Failure ModesAttorney docket no.103361-567WO1 T2023-414 while due to exposure to the fluid medium. A detached seal may interfere with the flow through the valve. e e s

[0035] e study s mp ed t e ca cuatons re ated to r s assessment, nc ud ng ( ) only one system failure is considered, which will cause a financial loss equivalent to $2E3, and (2) any failure mode of the valve will cause the system failure with a probability 100%. This information is modeled by the exemplary platform.

[0136] The study sampled several measurements from the SOV 900B, including (1) the input current to the valve, (2) the volume flowrate through the valve, (3) the plunger leaf spring deformation, and (4) the weight of the plunger with the seal.

[0137] The input current may be the control signal of the target component. The volume flowrate measurement may indicate the health of the spring. The plunger leaf spring deformation may be measured using images. The weight measurement of the plunger quantified the water absorption level and material loss in the seal.

[0138] Maintenance activities. The maintenance process view of the exemplary platform defined the total costs (i.e., worker salary and component cost) and work durations for several maintenance activities, including (1) inspecting the whole valve 900B, (2) inspecting coil only (not shown), (3) testing spring 904 compressions only, (4) weighing the plunger 910 and seal 902 only, (5) replacing the spring 904, (6) replacing the seal 902, and (7) replacing the whole valve.

[0139] Specifically, inspecting the whole valve 900B had a total cost of $200 and a work duration of 0.5 hours, inspecting the coil (not shown) only had a total cost of $150 and a workAttorney docket no.103361-567WO1 T2023-414 duration of 0.16 hours, testing spring 904 compression had a total cost of $120 and a work duration of 0.25 hours, weighing the plunger 910 and seal 902 had a total cost of $100 and a work duration of 0.08 hour, replacing the spring 904 had a total cost of $650 and work duration of 0.5 hour, replacing the seal 902 had a total cost of $200 and work duration of 0.75 hour, and replacing the whole valve 900B had a total cost of $650 and work duration of 0.5 hour.

[0140] The decision-making algorithm then referenced this information to select an optimal maintenance activity.

[0141] Results and achievements. By executing the information queries, the study received the outputs from the ontology object / repository for the SOV 900B. Table 7 shows the ontology repository’s outputs and answers for some competency questions. In the results, the components’ names with the number 1 denote that they are instances of components, not the component classes. Table 7 Competency questions? Outputs of the platform “ ” “ ” “ ” “ ”Attorney docket no.103361-567WO1 T2023-414 Considering maintenance costs and “Valve_1, Leafspring” system risks, what is the most criticalp y q p y o be maintained in the target system?” included all the components that need to be maintained in the target system. The answer to the competency question “What are the available maintenance activities for the target component?” includes the available maintenance activities for the target component “Valve_1”. According to the answer to the competency question “What is the most efficient maintenance activity” the most efficient maintenance activity is “replace the seal,” which decreases the risk by 9.9 (dollar loss per year / dollars of maintenance cost). Also, the most critical part of the solenoid valve is the leaf spring, as shown by the answer to the competency question, “Considering maintenance costs and system risks, what is the most critical part of the target system / component?”

[0143] Assume that the failure of any part of the valve will fail the valve. According to the feasible maintenance activities identified by the competency question “What is the maximum improvement of system safety?”, the best system safety improvement can only be achieved by the activity “replace the whole valve,” which reduces the risk by 1980.

[0144] Discussion

[0145] The study developed a maintenance optimization platform for supporting the development of a maintenance optimization system. The exemplary platform may facilitate the tasks that need to be performed during the development of every maintenance optimization system. These tasks included using the exemplary platform for optimization model selection. A maintenance optimization model usually contains one or more optimization algorithms thatAttorney docket no.103361-567WO1 T2023-414 require various inputs. For example, a maintenance optimization model for a feed water system may require the flow rates through the pipelines in the system to be sampled in real-time by different sensors, the predicted residual lifetime of the regulating valves from a fault diagnosis tool, as well as the risk of system failures from a risk assessment tool. The exemplary platform may be used to quickly identify whether the requirements of the optimization algorithm may be satisfied. The identification may be achieved by using ontology query languages, e.g., SPARQL

[0037] , or by defining the prerequisite rules using SWRL

[0027] . The optimization algorithms with unsatisfiable requirements should be filtered out.

[0146] The task also included using the exemplary platform to implement a maintenance optimization model may be more straightforward than the traditional development process since the exemplary platform provided a standardized API that may supply the required information to the optimization model. As a result, the developers of the optimization model may not need to implement the functions related to data sampling and formatting, and the time for model implementation may be reduced.

[0147] As a data provider for the maintenance optimization model, the exemplary platform may provide online data for the optimization model. Also, it may be configured to provide test data to the model for model evaluation. For example, the online monitoring view may be configured to connect to a database that recorded a series of benchmark data. Meanwhile, when two optimization models were implemented based on the API provided by the platform, the platform may launch both algorithms using the same monitoring data, and their outcomes may be compared and evaluated.

[0148] Although the exemplary platform itself may not perform critical tasks required by system maintenance, such as system diagnosis and risk assessment, it provided various APIs that may be reused by external tools to provide the results of such tasks to the ontology repository. For example, by using the APIs provided by the component view, the system structure information represented by a system modeling diagram, such as Piping & Instruments Diagrams (P&ID) may be modeled and reused by other views. The interface developed for this view may be connected to an image identification tool to update the system components and structural information automatically

[0050] . The monitoring view may search and select data sampled from real systems. External diagnosis or health management tools may use these data to perform diagnosis and prognosis. The risk assessment view may interact with external risk analysis toolsAttorney docket no.103361-567WO1 T2023-414 to acquire risk evaluation results. The view may provide information about the event trees, fault trees, and the distributions and probabilities for various events.

[0149] In the exemplary platform, the classes of failure modes and applicable maintenance activities were manually defined by domain experts. The classes of failure modes and the classes of maintenance activities were linked by the types of components (i.e., specific failure modes) were linked to specific types of components, and the same was true for the maintenance activities. In this case, the validity of failure modes and maintenance activities was ensured by expert knowledge. Domain experts may add failure modes for specific target systems to the ontology repository or identify the failure modes that may be reused. In the future, the conditions and constraints for validating failure modes and maintenance activities may be predefined using the ontology platform so that the ontology reasoner may automatically identify their applicability to various target systems.

[0150] In addition, the study described a method for reusing existing ontologies and minimizing the modifications to the existing ontologies. However, conflicts between the classes in two different ontologies may exist. The existence of conflicts between two or more ontologies means that classes or properties given the same name in these ontologies may have different interpretations or that mistakes may exist in these ontologies. For example, the class “orange” may be a subclass of “fruit” in the fruit ontology but may also be a subclass of “color” in the color ontology. The proposed ontology integration method may not prevent such semantic heterogeneity between existing ontologies. However, some ontology inference engines, e.g., HermiT

[0020] , may detect these types of conflict automatically.

[0151] As an effective way for standardizing and sharing information, ontologies became increasingly valuable tools in computer science for their utility in enabling a thorough and well- defined discourse and for building logical models of systems. Ontology was applied to various system engineering processes, such as collaborative assembly design

[0032] , engineering knowledge modeling

[0026] and maintenance [1], and project management

[0047] . However, these ontologies were developed for the development stages of industrial systems and may not support the tasks performed in the maintenance stage.

[0152] For system maintenance and optimization, some ontologies were developed for specific industrial fields. For example, Elhdad et al. developed an ontology for process monitoring and maintenance in petroleum plants

[0017] , which may enhance maintenanceAttorney docket no.103361-567WO1 T2023-414 decisions based on the knowledge gathered through the process of monitoring. This monitoring process was based on signals which are triggered during the plant safety shutdown process, which ensured that decision-makers have sufficient information to make the right decision at the right time. Ebrahimipour & Yacout developed an ontology-based schema to support maintenance knowledge representation for physical components

[0015] . The schema may overcome the problems of heterogeneity and inconsistency in maintenance records. A bond graph model (BGM) was employed to model the structure of equipment functions involved in fault propagation at the part-component level. In addition, this method provided a generic technical understanding, which enriched semantic extraction and knowledge discovery in a typical maintenance report. Anquetil et al. developed an ontology for software maintenance optimization [4]. They defined two common maintenance scenarios and considered the industrial issues associated with them. Campos developed an ontology for asset management for mechanical systems [7], which recorded the data structure and information needed for the maintenance management of the industrial assets with their objects, attributes, and relationships. Dimitrova et al. developed PADTUN

[0013] , an intelligent decision support system that assisted with pathology diagnosis and assessment of tunnels with respect to their disorders and diagnosis influencing factors. Nevertheless, these ontologies were designed for specific industrial fields or for a specific type of industrial systems.

[0153] For the purposes of generalization, the Industrial Maintenance Management Ontology (IMAMO)

[0030] was developed for industrial maintenance, ensuring semantic interoperability and generating new knowledge that supports decision-making in the maintenance process. ROMAIN

[0029] was a domain-specific ontology for the maintenance management domain. It constrains the classes that were unique to the maintenance management practice, such as maintenance strategy, degradation, and work order management. Emmanouilidis et al. conducted a study of maintenance ontologies from the viewpoint of reliability-oriented context information management and developed a baseline context information management ontology aligned with the needs of maintenance services for connected production machines

[0018] . This ontology is applied to an industrial case study relevant to maintenance services for a distributed fleet of connected industrial printers. Canito et al. developed an ontology to bridge the gap between data sampling from different types of sensors and equipment for predictive maintenance [8]. It also provided interface for machine learning algorithms to train data mining models.Attorney docket no.103361-567WO1 T2023-414

[0154] Compared to the existing ontologies or methodologies designed for system maintenance, MuAMO covered all the aspects related to maintenance optimization (e.g., maintenance activities, asset management, failures, monitoring, risk, cost, and decision making).

[0155] Conclusion

[0156] It must also be noted that, as used in the specification and the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Ranges may be expressed herein as from “about” or “ 5 approximately” one particular value and / or to “about” or “approximately” another particular value. When such a range is expressed, other exemplary embodiments include one particular value and / or the other particular value.

[0157] By “comprising” or “containing” or “including,” is meant that at least the name compound, element, particle, or method step is present in the composition or article or method but does not exclude the presence of other compounds, materials, particles, method steps, even if the other such compounds, material, particles, method steps have the same function as what is named.

[0158] In describing example embodiments, terminology will be resorted to for the sake of clarity. It is intended that each term contemplates its broadest meaning as understood by those skilled in the art and includes all technical equivalents that operate in a similar manner to accomplish a similar purpose. It is also to be understood that the mention of one or more steps of a method does not preclude the presence of additional method steps or intervening method steps between those steps expressly identified. Steps of a method may be performed in a different order than those described herein without departing from the scope of the present disclosure. Similarly, it is also to be understood that the mention of one or more components in a device or system does not preclude the presence of additional components or intervening components between those components expressly identified.

[0159] The following patents, applications and publications as listed below and throughout this document are hereby incorporated by reference in their entirety herein. [1] Ajit, S., Sleeman, D., Fowler, D. W., & Knott, D. (2008). Constraint capture and maintenance in engineering design. Artificial Intelligence for Engineering Design, Analysis and Manufacturing: AIEDAM, 22(4), 325–343. https: / / doi.org / 10.1017 / S089006040800022XAttorney docket no.103361-567WO1 T2023-414 [2] Alaswad, S., & Xiang, Y. (2017). A review on condition-based maintenance optimization models for stochastically deteriorating system. Reliability Engineering and System Safety, 157, 54–63. https: / / doi.org / 10.1016 / j.ress.2016.08.009 [3] Alkahtani, M., Choudhary, A., De, A., & Harding, J. A. (2019). A decision support system based on ontology and data mining to improve design using warranty data. Computers and Industrial Engineering, 128(April 2018), 1027–1039. https: / / doi.org / 10.1016 / j.cie.2018.04.033 M., & Dias, M. G. B. (2006). Software maintenanceand Software Technology, 153–173. https: / / doi.org / 10.1007 / 3-540-34518-3_5 . Risk based maintenance optimization: FoundationalSafety, 67(3), 285–292. https: / / doi.org / 10.1016 / S0951-8320(99)00068-X . Building Ontologies with Basic FormalOntology. In Building Ontologies with Basic Formal Ontology. https: / / doi.org / 10.7551 / mitpress / 9780262527811.001.0001 In IFAC Proceedings Volumes(IFAC-PapersOnline) (Vol.1, Issue PART 1). IFAC. https: / / doi.org / 10.3182 / 20071002-mx-4- 3906.00007 A., Corchado, J., & Marreiros, G. (2021). Bridging the Gap Between Domain Ontologies for Predictive Maintenance with Machine Learning. Advances in Intelligent Systems and Computing, 1366 AISC, 533–543. https: / / doi.org / 10.1007 / 978-3-030-72651-5_51 [9] Ceusters, W. (2012). An information artifact ontology perspective on data collections and associated representational artifacts. Studies in Health Technology and Informatics, 180, 68–72. https: / / doi.org / 10.3233 / 978-1-61499-101-4-68. Ontology construction and application in practice case study of health tourism in Thailand. SpringerPlus, 5(1). https: / / doi.org / 10.1186 / s40064-016-3747-3

[0011] de Jonge, B., & Scarf, P. A. (2020). A review on maintenance optimization. European Journal of Operational Research, 285(3), 805–824. https: / / doi.org / 10.1016 / j.ejor.2019.09.047Attorney docket no.103361-567WO1 T2023-414

[0012] Diao, X., Pietrykowski, M., Huang, F., Mutha, C., & Smidts, C. (2022). An ontology-based fault generation and fault propagation analysis approach for safetycritical computer systems at the design stage. Artificial Intelligence for Engineering Design, Analysis and Manufacturing: AIEDAM, 36. https: / / doi.org / 10.1017 / S0890060421000342

[0013] Dimitrova, V., Mehmood, M. O., Thakker, D., Sage-Vallier, B., Valdes, J., & Cohn, A. G. (2020). An ontological approach for pathology assessment and diagnosis of tunnels. Engineering Applications of Artificial Intelligence, 90. https: / / doi.org / 10.1016 / j.engappai.2019.103450 Nuclear Facility Maintenance Managementhttps: / / doi.org / DOE G 433.1-1A

[0015] Ebrahimipour, V., & Yacout, S. (2015). Ontology-based schema to support maintenance knowledge representation with a case study of a pneumatic valve. IEEE Transactions on Systems, Man, and Cybernetics: Systems, 45(4), 702–712. https: / / doi.org / 10.1109 / TSMC.2014.2383361 Ontology for Construction Knowledge. Journal ofConstruction Engineering and Management, 139(7), 768–784. https: / / doi.org / 10.1061 / (asce)co.1943-7862.0000646(2013). An ontology-based framework for process monitoring and maintenance in petroleum plant. Journal of Loss Prevention in the Process Industries, 26(1), 104–116. https: / / doi.org / 10.1016 / j.jlp.2012.10.001

[0018] Emmanouilidis, C., Gregori, M., & Al-Shdifat, A. (2020). Context ontology development for connected maintenance services. IFAC-PapersOnLine, 53, 10923–10928. https: / / doi.org / 10.1016 / j.ifacol.2020.12.2833C., & Oltramari, A. (2003). Sweetening WORDNET with DOLCE. AI Magazine, 24(3), 13. https: / / doi.org / 10.1007 / 3-540-45810-7

[0020] Glimm, B., Horrocks, I., Motik, B., Stoilos, G., & Wang, Z. (2014). HermiT: an OWL 2 reasoner. Journal of Automated Reasoning, 53(3), 245–269.

[0021] Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition, 5(2), 199–220. https: / / doi.org / 10.1.1.101.7493Attorney docket no.103361-567WO1 T2023-414

[0022] Grüninger, M., Fox, M. S., & Gruninger, M. (1995). Methodology for the Design and Evaluation of Ontologies. International Joint Conference on Artificial Inteligence (IJCAI95), Workshop on Basic Ontological Issues in Knowledge Sharing, 1–10.

[0023] Gruninger, M., & Uschold, M. (1996). Ontologies: Principles, Methods and Applications. Knowledge Engineering Review, 11(2). http: / / www.aiai.ed.ac.uk / publications / documents / 1996 / 96-ker-intro-ontologies.pdf Y. X. & K. . on maintenance method intelligentpower Energy Engineering Conference, APPEEC, September, 96–100. https: / / doi.org / 10.1109 / APPEEC.2009.4918824 X. (2013). A maintenance optimization modelsystems on degradation. Reliability Engineering and System Safety, 111, 183–194. https: / / doi.org / 10.1016 / j.ress.2012.10.015

[0026] Harrison, R., & Chan, C. W. (2009). A dynamic knowledge modeler. Artificial Intelligence for Engineering Design, Analysis and Manufacturing: AIEDAM, 23(1), 53–69. https: / / doi.org / 10.1017 / S0890060409000109 F., Boley, H., Tabet, S., Grosof, B., & Dean, M.(2004). SWRL : A Semantic Web Rule Language Combining OWL and RuleML. In W3C Member submission 21 (Issue May 2004, pp.1–20). http: / / www.w3.org / Submission / SWRL /

[0028] IAEA. (2018). Maintenance Optimization Programme for Nuclear Power Plants.

[0029] Karray, M. H., Ameri, F., Hodkiewicz, M., & Louge, T. (2019). ROMAIN: Towards a BFO compliant reference ontology for industrial maintenance. Applied Ontology, 14(2), 155– 177. https: / / doi.org / 10.3233 / AO-190208

[0030] Karray, M. H., Chebel-Morello, B., & Zerhouni, N. (2012). A formal ontology for industrial maintenance. In Applied Ontology (Vol.7, Issue 3). https: / / doi.org / 10.3233 / AO-2012- 0112

[0031] Kethavarapu, U. P. K., & Saraswathi, S. (2016). Concept Based Dynamic Ontology Creation for Job Recommendation System. Procedia Computer Science, 85, 915–921. https: / / doi.org / 10.1016 / j.procs.2016.05.282& Ellis, R. D. (2009). Ontology-based modeling and integration of morphological characteristics of assembly joints for network-basedAttorney docket no.103361-567WO1 T2023-414 collaborative assembly design. Artificial Intelligence for Engineering Design, Analysis and Manufacturing: AIEDAM, 23(1), 71–88. https: / / doi.org / 10.1017 / S0890060409000110

[0033] Kobbacy, K. A. H. (2004). On the evolution of an intelligent maintenance optimization system. Journal of the Operational Research Society, 55(2), 139–146. https: / / doi.org / 10.1057 / palgrave.jors.2601696

[0034] Kornyshova, E., & Deneckère, R. (2010). Decision-making ontology for information system engineering. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 6412 LNCS(i), 104–117. https: / / doi.org / 10.1007 / 978-3-642-16373-9_8 oriented programming in Python withconstructs for biomedical ontologies. Artificial Intelligence In Medicine, 80, 11–28.

[0036] Lee, J., Ni, J., Singh, J., Jiang, B., Azamfar, M., & Feng, J. (2020). Intelligent Maintenance Systems and Predictive Manufacturing. Journal of Manufacturing Science and Engineering, Transactions of the ASME, 142(11). https: / / doi.org / 10.1115 / 1.4047856

[0037] López, M. F., Gómez-Pérez, A., Sierra, J. P., & Sierra, A. P. (1999). Building a chemical ontology using methontology and the ontology design environment. IEEE Intelligent Systems and Their Applications, 14(1), 37–46. https: / / doi.org / 10.1109 / 5254.747904

[0038] Mohammad, M. A., Kaloskampis, I., Hicks, Y., & Setchi, R. (2015). Ontology-based framework for risk assessment in road scenes using videos. Procedia Computer Science, 60(1), 1532–1541. https: / / doi.org / 10.1016 / j.procs.2015.08.300

[0039] A Look Back and a Look Forward. A. Musen, Mark, 1(4), 4–12.

[0040] Niles, I., & Pease, A. (2001). Towards a Standard Upper Ontology. The 2nd International Conference on Formal Ontology in Information Systems (FOIS-2001), 2–9. https: / / doi.org / 10.1145 / 505168.505170L. (2017). Ontology Development 101: A guide to creating your first ontology. Sustainability (Switzerland), 9(12), 1–25. https: / / doi.org / 10.3390 / su9122317D., Cains, M., & Hoffman, B. (2015). Towards a human factors ontology for cyber security. CEUR Workshop Proceedings, 1523, 26–33.Attorney docket no.103361-567WO1 T2023-414

[0043] Qu, C., Liu, F., Yu, H., Yuan, R., & Wang, A. (2016). User oriented semi-automatic method of constructing domain ontology. Communications in Computer and Information Science, 575, 553–561. https: / / doi.org / 10.1007 / 978-981-10-0356-1_58

[0044] Sharma, A., Yadava, G. S., & Deshmukh, S. G. (2011). A literature review and future perspectives on maintenance optimization. Journal of Quality in Maintenance Engineering, 17(1), 5–25. https: / / doi.org / 10.1108 / 13552511111116222

[0045] Smith, B. (1998). Basic concepts of formal ontology. Formal Ontology in Information Systems. IOS Press, 19–28.

[0046] Wang, L., Chu, J., Mao, W., & Fu, Y. (2006). Advanced maintenance strategy for power plants - Introducing intelligent maintenance system. Proceedings of the World Congress on Intelligent Control and Automation (WCICA), 2, 7444–7448. https: / / doi.org / 10.1109 / WCICA.2006.1713411 Chen, M., & Wang, X. (2021). Ontologicalknowledge base for concrete bridge rehabilitation project management. Automation in Construction, 121. https: / / doi.org / 10.1016 / j.autcon.2020.103428

[0048] Yuan, X. X., Higo, E., & Pandey, M. D. (2021). Estimation of the value of an inspection and maintenance program: A Bayesian gamma process model. Reliability Engineering and System Safety, 216(July), 107912. https: / / doi.org / 10.1016 / j.ress.2021.107912

[0049] Zhao, Y., & Smidts, C. (2022). Reinforcement learning for adaptive maintenance policy optimization under imperfect knowledge of the system degradation model and partial observability of system states. Reliability Engineering and System Safety, 224(September 2021), 108541. https: / / doi.org / 10.1016 / j.ress.2022.108541

[0050] Gao, Wei, Yunfei Zhao, and Carol Smidts. “Component detection in piping and instrumentationdiagrams of nuclear power plants based on neural networks.” Progress in Nuclear Energy 128 (2020): 103491.

Claims

Attorney docket no.103361-567WO1 T2023-414 What is claimed:

1. A non-transitory computer-readable medium having instructions stored thereon for a maintenance management system, wherein execution of the instructions by a processor causes the processor to: provide a first maintenance ontology object having classes of maintenance objects and properties from a first configuring process, wherein the maintenance ontology object includes data classes organized in a hierarchical structure of the maintenance objects and properties, including (i) a first node associated with a first class associated with properties and maintenance objects and (ii) a second node associated with a second class associated with properties and maintenance objects; receive data from a database to add as a second maintenance ontology object to be merged with the first maintenance ontology object, wherein the received data includes at least one of the maintenance objects and properties, corresponding to a field of the database; generate one or more classes of the maintenance objects and properties defined in the received data into at least a third node and a fourth node in a second hierarchical structure; merge the second maintenance ontology object into the first maintenance ontology object using a heuristic operation to generate a combined maintenance ontology object, wherein the heuristic operation includes, at least one: (i) assigning the third node or fourth node as a child of the first node or second node; (ii) assigning the other of the third node or fourth node as a parent to the first node or second node; and store the combined ontology object to be used for subsequent queries by the maintenance management system, wherein the subsequent query is related to the maintenance of a platform.

2. The non-transitory computer-readable medium of claim 1, wherein the first node and second node of the first maintenance ontology object include at least one of a component class, a maintenance activity class, a maintenance operation class, a failure mode class, a risk class, and a cost class.

3. The non-transitory computer-readable medium of claim 2, wherein the third node and fourth node of the first maintenance ontology object include at least one of basic formal ontologyAttorney docket no.103361-567WO1 T2023-414 (BFO) elements, Domain-specific, Open Access, Reference Ontology (ROMAIN) elements, Information Artifact Ontology (IAO) elements, and Information Entity Ontology (IEO) elements.

4. The non-transitory computer-readable medium of any one of claims 1 - 3, wherein the instructions to execute an operation with respect to the combined ontology object, or an associated repository, includes instructions to: provide a plurality of decision-making algorithms in the first maintenance ontology object; select, via a decision-making algorithm, an optimal maintenance activity using a maintenance optimization operation of the first maintenance ontology object, a list of maintenance activities first maintenance ontology object, a failure mode information first maintenance ontology object, and a risk mode information first maintenance ontology object, wherein the selection employs presence of maintenance optimization, failure mode, risk mode; and transmit via a software interface the selected optimal maintenance activity to a maintenance management system.

5. The non-transitory computer-readable medium of any one of claims 1 – 4, wherein: for each noun in the received data from the database, compare the noun with each class in the first maintenance ontology object to determine if the noun has the same meaning with a class name, or a name associated therefrom, with the respective class; link the noun to an element of the first maintenance ontology object based on the noun comparison; for each verb in the received data from the database, compare the verb with each links between classes in the first maintenance ontology object to determine if the verb has the same meaning with a link name, or a name associated therefrom, of the respective link; and link the verb to an element of the first maintenance ontology object based on the verb comparison.

6. The non-transitory computer readable medium of any one of claims 1 - 5, wherein the heuristic operation includes:Attorney docket no.103361-567WO1 T2023-414 for each noun in the received data from the database, compare the noun with each class in the first maintenance ontology object to determine if the noun has the same meaning with a class name, or a name associated therefrom, with the respective class; and generate an axiom in Semantic Web Rule Language of the noun and an element of the first maintenance ontology object based on the noun comparison.

7. The non-transitory computer-readable medium of any one of claims 1 - 6, wherein the heuristic operation includes instructions to remove contradictions or inconsistencies using one or more ontology built-in reasoner rules.

8. The non-transitory computer-readable medium of any one of claims 1 - 7, wherein the heuristic operation includes: (i) assigning the third node of the second ontology as a child of the second node of the first ontology, wherein the second node is a child of the first node, and wherein the fourth node is a child of the third node; (ii) assigning the third node of the second ontology as a child of the first node of the first ontology, wherein the third node is a parent of the second node and the third node is a child of the first node, and wherein the fourth node is a child of the third node; (iii) assigning the third node of the second ontology as a child of the first node of the first ontology, wherein the second node is a child of the first node and the fourth node is a child of the second node, wherein the fourth node is a child of the third node; (iv) assigning the third node of the second ontology as a parent of the first and the second node of the first ontology, wherein the fourth node is a child of the second node, wherein the fourth node is a child of the third node; and (v) assigning the third node of the second ontology as a child of the first node of the first ontology, wherein the fourth node is a child of the third node and the third node is a child of the first node, wherein the fourth node is a child of the third node.

9. The non-transitory computer-readable medium of any one of claims 1 - 8, wherein the hierarchical structure includes at least one of:Attorney docket no.103361-567WO1 T2023-414 (i) a tree structure including one or more nodes, wherein each node has at least one of a child node, a parent node, or a combination thereof; or (ii) a list structure including a prior node, a later node, or a combination thereof.

10. The non-transitory computer-readable medium of any one of claims 1 - 9, wherein the subsequent query executed by a different processor comprises: receiving a query from a user or an API call, the query having one or more classes for a maintenance related analysis that are linked to one or more other classes in the combined maintenance ontology object; matching the one or more classes of the subsequent query to nodes in the hierarchical structure of the combined maintenance ontology object; and generating or storing a value from the subsequent query.

11. The non-transitory computer-readable medium of claim 10, wherein the subsequent query executed by the different processor comprises a second query, wherein the second query comprises: receiving one or more values generated by the execution of the subsequent query for the maintenance-related analysis; receiving a second subsequent query from the user or another API call, the second query having one or more classes for a second maintenance-related analysis that is linked to one or more other classes in the combined maintenance ontology object; matching the one or more classes of the second subsequent query to nodes in the hierarchical structure of the combined maintenance ontology object; and generating or storing a value from the second subsequent query.

12. The non-transitory computer-readable medium of claim 11, wherein the value from the second subsequent query includes at least one of (i) components or subsystems to be maintained in the system; (ii) available maintenance activities for a component; (iii) a failure mode's cost; (iv) a most efficient maintenance activity;Attorney docket no.103361-567WO1 T2023-414 (v) a most critical part of the system and / or component; (vi) feasible maintenance activities for a budget; and (vii) a maximum obtainable improvement of system safety.

13. The non-transitory computer-readable medium of any one of claims 1 - 12, wherein the maintenance objects and properties of the data classes include: component state information, monitoring technology information, signal information, performance level information, data acquisition (DAG) information, risk information, initiating event information, accident condition information, accident sequence information, event tree information, and fault tree information.

14. A system comprising: a database configured to have classes of objects and properties; and a non-transitory computer-readable medium having instructions stored thereon for a maintenance management system, wherein execution of the instructions by a processor causes the processor to: provide a first maintenance ontology object having classes of maintenance objects and properties from a first configuring process, wherein the maintenance ontology object includes data classes organized in a hierarchical structure of the maintenance objects and properties, including (i) a first node associated with a first class associated with properties and maintenance objects and (ii) a second node associated with a second class associated with properties and maintenance objects; receive data from a database to add as a second maintenance ontology object to be merged with the first maintenance ontology object, wherein the received data includes at least one of the maintenance objects and properties corresponding to a field of the database; generate one or more classes of the maintenance objects and properties defined in the received data into at least a third node and a fourth node in a second hierarchical structure; merge the second maintenance ontology object into the first maintenance ontology object using a heuristic operation to generate a combined maintenance ontology object, wherein the heuristic operation includes at least one:Attorney docket no.103361-567WO1 T2023-414 (i) assigning the third node or fourth node as a child of the first node or second node; (ii) assigning the other of the third node or fourth node as a parent to the first node or second node; and (iii) storing the combined ontology object to be used for subsequent queries by the maintenance management system, wherein the subsequent query is related to the maintenance of a platform.

15. The system of claim 14, comprising the maintenance management system.

16. The system of claim 14 or 15 comprising one or more additional databases having stored thereon at least one of basic formal ontology elements, Domain-specific, Open Access, Reference Ontology elements, Information Artifact Ontology elements, and Information Entity Ontology elements.

17. The system of any one of claims 14 - 16 comprising: a query interface, the query interface is configured to: provide a plurality of decision-making algorithms in the first maintenance ontology object; select, via a decision-making algorithm, an optimal maintenance activity using a maintenance optimization operation of the first maintenance ontology object, a list of maintenance activities first maintenance ontology object, a failure mode information first maintenance ontology object, and a risk mode information first maintenance ontology object, wherein the selection employs presence of maintenance optimization, failure mode, risk mode; and transmit via a software interface the selected optimal maintenance activity to a maintenance management system.

18. A method comprising: providing a first maintenance ontology object having classes of maintenance objects and properties from a first configuring process, wherein the maintenance ontology object includesAttorney docket no.103361-567WO1 T2023-414 data classes organized in a hierarchical structure of the maintenance objects and properties, including (i) a first node associated with a first class associated with properties and maintenance objects and (ii) a second node associated with a second class associated with properties and maintenance objects; receiving data from a database to add as a second maintenance ontology object to be merged with the first maintenance ontology object, wherein the received data includes at least one of the maintenance objects and properties, corresponding to a field of the database; generating one or more classes of the maintenance objects and properties defined in the received data into at least a third node and a fourth node in a second hierarchical structure; merging the second maintenance ontology object into the first maintenance ontology object using a heuristic operation to generate a combined maintenance ontology object, wherein the heuristic operation includes, at least one: (i) assigning the third node or fourth node as a child of the first node or second node; (ii) assigning the other of the third node or fourth node as a parent to the first node or second node; and storing the combined ontology object to be used for subsequent queries by a maintenance management system, wherein the subsequent query is related to the maintenance of a platform.

19. The method of claim 18, wherein: for each noun in the received data from the database, comparing the noun with each class in the first maintenance ontology object to determine if the noun has the same meaning with a class name, or a name associated therefrom, of the respective class; linking the noun to an element of the first maintenance ontology object based on the noun comparison; for each verb in the received data from the database, comparing the verb with each link between classes in the first maintenance ontology object to determine if the verb has the same meaning with a link name, or a name associated therefrom, of the respective link; and linking the verb to an element of the first maintenance ontology object based on the verb comparison.Attorney docket no.103361-567WO1 T2023-414 20. The method of claim 18 or 19, wherein the heuristic operation includes: (i) assigning the third node of the second ontology as a child of the second node of the first ontology, wherein the second node is a child of the first node, and wherein the fourth node is a child of the third node; (ii) assigning the third node of the second ontology as a child of the first node of the first ontology, wherein the third node is a parent of the second node and the third node is a child of the first node, and wherein the fourth node is a child of the third node; (iii) assigning the third node of the second ontology as a child of the first node of the first ontology, wherein the second node is a child of the first node, and the fourth node is a child of the second node, wherein the fourth node is a child of the third node; (iv) assigning the third node of the second ontology as a parent of the first and the second node of the first ontology, wherein the fourth node is a child of the second node, wherein the fourth node is a child of the third node; and (v) assigning the third node of the second ontology as a child of the first node of the first ontology, wherein the fourth node is a child of the third node, and the third node is a child of the first node, wherein the fourth node is a child of the third node.

21. The method of any one of claims 18 – 20, wherein the method employs the non-transitory computer-readable medium of any one of claims 1-13.

22. The system of any one of claims 14 – 17, wherein the system employs the non-transitory computer-readable medium of any one of claims 1-13.

Images