Aircraft Hardware Component Rotability Classification Using Machine Learning

This application is a continuation application of U.S. patent application Ser. No. 18/884,418, filed Sep. 13, 2024, the contents of which are hereby incorporated by reference in its entirety.

The disclosure generally relates to the field of machine learning, and more particularly relates to rotability classification of aircraft hardware components.

Aircraft hardware components may be rotable or consumable, where rotable components can be repaired and re-used on aircraft, and consumable components are discarded after a single use. Whether a component is rotable or consumable is not typically listed by original equipment manufacturer specifications, and data tends to be opaque on rotability of a given component. Given the opacity and inconsistency of the data, training examples do not exist that map signals to determinations of rotability, therefore impeding the ability of developing a supervised classifier to draw determinations of rotability of any given aircraft hardware component.

Systems and methods are disclosed herein for training, deploying, and harmonizing multiple rotability classifiers based on different historical signals for aircraft components, thereby enabling a robust prediction of whether a given aircraft component is rotable. Rotability may be indicated for searched aircraft components, resulting in an improved user interface with improved data resolution during aircraft component searches.

In some embodiments, an application extracts a plurality of features of a hardware component of an aircraft. Different subsets of features are input into respective different rotability classifiers. The application harmonizes the outputs from the rotability classifiers to obtain a final determination of whether the hardware component is rotable. The application adds a data structure for the hardware component with the final determination in a searchable database and includes rotability indications with search results for aircraft hardware components.

The Figures (FIGS.) and the following description relate to preferred embodiments by way of illustration only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of what is claimed.

Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying figures. It is noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

1 FIG. 1 FIG. 100 100 110 111 120 130 140 150 110 130 140 110 130 140 111 Figure (illustrates one embodiment of a system environmentfor operating a hardware component service. As depicted in, environmentincludes client devicewith applicationinstalled thereon, network, hardware component service, input database, and source databases. Client devicemay be any device configured to receive input from a user and communicate with aircraft component serviceand/or input database. Exemplary client devices include personal computers, smartphones, tablets, Internet-of-Things (IOT) devices, laptops, kiosks, and so on. Communications between client deviceand hardware component serviceand/or input databasemay be managed by application.

111 130 130 110 111 120 110 130 120 1 FIG. 1 FIG. Applicationmay be a specialized application (e.g., downloaded from hardware component serviceor provided by aircraft component servicefor download through a third-party system), or may be accessed through a browser installed on client device. Applicationmay be used to enter a search query relating to a hardware component. Networkmay be any network that transmits data communications between at least client deviceand hardware component service. Networkmay transmit data communications between any entity shown in, as well as any entity discussed herein but not shown in. Exemplary data networks include the Internet, a wide area network, a local area network, a WiFi network, and any other network that transfers data between electronic devices.

130 140 130 130 2 4 FIGS.and Hardware component serviceuses both historical and new data entries relating to hardware components to generate a searchable database (e.g., input database). Hardware component servicemay be driven by a machine learning model (or multiple models). Further details about hardware component serviceare described with reference tobelow.

140 130 130 140 110 130 140 130 150 130 Input databasestores one or more searchable databases generated by hardware component service. Hardware component servicemay search input databaseresponsive to receiving a query (e.g., from client device) relating to a given hardware component. While depicted as a separate entity from hardware component service, input databasemay be stored within the boundaries of hardware component service. Source databaseshouse data (e.g., historical and new data entries) relating to hardware components and provide this data to hardware component service.

2 FIG. 2 FIG. 2 FIG. 130 130 231 232 233 234 235 236 237 238 240 241 260 130 110 111 150 140 illustrates one embodiment of exemplary modules and databases used by the hardware component service. As depicted in, hardware component serviceincludes historical data retrieval module, weighting module, training module, new data module, re-training module, searchable database generation module, search module, matching module, cache memory, model database, and rotability determination module. The modules and databases depicted inare merely exemplary; fewer or more modules and/or databases may be used to achieve the functionality described herein. Moreover, some or all functionality of hardware component servicemay be distributed and/or instantiated at client device(e.g., on application), at one or more of the source databases, at input database, or any combination thereof.

231 150 231 150 Historical data retrieval moduleretrieves historical data from any number of databases (e.g., source databases). The historical data includes entries that reference both a particular airplane hardware component, and a value associated therewith. Historical data retrieval modulemay identify source databasesthrough any known means, such as scraping web data having references to known hardware components. The references to known hardware components may be any identifying feature of a hardware component, such as a name, model number, serial number, or any other identifier. Historical data may include any data referencing any known hardware component, regardless of whether it is old data (e.g., 50 or more years old), inaccurate data, or from sources that are disreputable (e.g., based on internally calculated or third-party calculated trust scores relating to the sources).

231 240 240 240 130 Historical data retrieval modulemay store the retrieved historical data in cache memory. Cache memorymay be any memory that stores readily-retrievable data, as distinguished from non-cache memory which stores data having latency that cannot be accessed in less than a given threshold amount of time. Cache memorymay be stored on one or more servers of hardware component serviceand/or may be in whole or in part stored using a third-party service.

232 Weighting moduledetermines weights to apply to values corresponding to hardware components as indicated in each entry of the historical data. In an embodiment, weights may be applied based on heuristics, where the heuristics together are referred to as a weighting model. For example, anomalies and attenuation signals may be pre-defined. The term anomaly, as used herein, may refer to an artifact within a data entry that, if found, causes the data entry to be discarded or fully discounted to a zero weight or a de minimus weight. The term attenuation signal, as used herein, may refer to an artifact within a data entry that, if found, causes the data entry to be discounted—that is, weighted to less than a normal unit of weight.

130 Anomalies and attenuation signals may be defined by an administrator or user of the system. An amount to discount an entry having an anomaly and/or an attenuation signal, or whether to discard a data entry having an anomaly, may be pre-defined by an administrator or user of hardware component service. An exemplary anomaly may be a data entry having an artifact indicative of a source that is known to be fraudulent. Another exemplary anomaly may be a cut-off age where historical data is considered to not be useful (e.g., more than 50 years old). Exemplary attenuation signals may include age (e.g., where certain age ranges of an entry relative to a present time may each be corresponded to a respective discount amount), source (e.g., where different sources have different discount amounts, or no discount amount), and so on.

232 232 In an embodiment, a data entry may have more than one artifact corresponding to an anomaly or an attenuation. In such an embodiment, weighting modulemay discount the data entry based on any or a combination of an artifact corresponding to a largest discount and/or an aggregate of all discounts corresponding to all artifacts within the data entry. In an embodiment, artifacts may be defined by a user or administrator that correspond to a positive signal. The administrator may define an amount of positive weighting that is applied where such artifacts are found in a manner opposite to that of an attenuation signal. Together, the heuristics performed by weighting modulemay be stored in a data structure and may be collectively referred to as weighting model.

232 In an embodiment, weighting modulemay apply some or all of each respective data entry of the historical data into a machine-learned model. The machine-learned model may output a weight. The machine-learned weighting model may be a supervised model or an unsupervised model. Where a supervised model is used, the machine-learned model may be trained using training data having a set of one or more artifacts, where the set is paired with a label representing a weight corresponding to the training data. Thus, the machine-learned model may match each input data entry to a weight based on the training data.

Where an unsupervised model is used, the weighting model may cluster inputs for respective hardware components based on their respective values. The weighting model may determine to not discount values that correspond to clusters, but may determine to discount outlier values that do not fall into clusters. An amount of discount may vary based on distance from a given cluster. A machine-learned model used for weighting in either manner may be referred to herein as a weighting model.

232 232 232 232 232 In an embodiment, two or more weighting models may be used. For example, weighting modulemay determine whether any given data entry of the historical data is suitable for input into the machine-learned weighting model, where suitability may be pre-defined as having pre-defined parameters, such as a pre-defined set of artifacts. As another example, weighting modulemay determine suitability based on whether at least a threshold number of the artifacts within a given data entry match at least a threshold number of artifacts known to be within the training data by which weighting modulewas trained, where a sufficient match yields a determination of suitability. Where suitability is determined, weighting modulemay apply the data entry to the machine-learned weighting model. Where suitability is determined to not exist, weighting modulemay apply the data entry to a heuristic-driven weighting model. A technical advantage in such a hybrid weighting model system is that accuracy is maximized based on selective use of heuristics versus a machine-learned model. Moreover, applying heuristics is more processor-intensive than applying an entry to a machine-learned model, and thus reducing heuristics to scenarios where a machine-learned weighting model reduces the overall computational power required in determining weightings.

Regardless of whether a machine-learned model, a heuristic model, or a hybrid model is used, in an embodiment, the weighting model may consider data entries in an aggregate form when determining weighting. For example, the weighting model may determine how many data entries of the historical data (e.g., optionally filtering out data entries having anomalies first) relate to a given hardware component. The weighting model may determine not to apply a weight (or to apply a weight of one, thus causing no change) for a value of any data entry corresponding to a hardware component that has fewer than a threshold minimum of corresponding entries in the historical data.

233 232 233 233 233 Training moduletrains a database generation model by using the weights determined by weighting moduleas applied to the historical data. Training modulegenerates training data by taking an identifier of the hardware component corresponding to each entry of the historical data and pairing it with a label that matches the value indicated in the data entry. Training moduleapplies the weight to the training data, such that, for a given hardware component, the amount of weight any given training data will be given in terms of its value as a source of ground truth is discounted or augmented based on the weight applied thereto. Training moduletrains the database generation model to take a hardware component identifier as input and to output a corresponding value using the generated training data.

234 130 234 234 In an embodiment, new data modulereceives new data also having a hardware component and a respective value. The term new data, as used herein, may refer to data entries having hardware components and respective values that are received by hardware component serviceafter the initial training is performed using the historical data. New data modulemay continue to receive new data and may batch the new data until a predefined condition is reached. Exemplary predefined conditions may include a threshold amount of new data has been batched, a predefined amount of time has elapsed since a reference point (e.g., a first new data of a batch being received, an interval of time has passed since a last re-training, etc.), and so on. Responsive to determining that the predefined condition has been reached, new data modulemay determine that the database generation model is to be re-trained.

235 232 235 233 235 235 235 235 235 Re-training modulere-trains the database generation model by determining weights for each new data entry using weighting moduleas applied to the new data. Re-training modulethen generates new training data in the same manner training modulegenerated training data from the historical data entries. Re-training modulethen trains the database generation model on the basis of the training data from all historical data (e.g., including any new data from prior re-training sessions) and on the basis of the training data from the new data. In an embodiment, the training data from all historical and new data is pooled and the database generation model is trained on the aggregate pool. Advantageously, in such an embodiment, weighting need not be re-performed on the historical data, as weights may be stored and retrieved for re-training purposes, thus reducing processing power required. In an embodiment, retrieval of historical data is selectively performed depending on whether new types of data and/or signals form part of the new data. For example, re-training modulemay determine whether the new training data includes signals and/or data types that were not considered when the database generation model was trained. Responsive to determining that the new training data includes new data types and/or signals, re-training modulemay generate the aggregate pool using the historical data (e.g., to ensure data relating to that type and/or signal is extracted from the historical data). However, responsive to determining that the new training data does not include new data types and/or signals, re-training modulemay use the new data without the historical data to re-train the database generation model, modifying existing associations within the database generation model based on the new data. Similarly, where the new training data does not include new data types and/or signals, re-training modulemay extract from the last (most recent) version of the searchable data structure values for given hardware types, and may generate training data therefrom that labels the hardware type with the value. This may be performed in place of retrieving the historical data, and may be used in conjunction with the new training data to re-train the database generation model. These manners of selectively retrieving the historical data improve on memory and bandwidth efficiency in avoiding retrieval of historical data unless it is necessary.

236 260 236 236 236 Searchable database generation modulegenerates a searchable database of hardware components as mapped to other parameters, such as a rotability determinations (e.g., from the rotability determination module) and/or one or more values associated with those hardware components. Searchable database generation modulemay generate the searchable database responsive to detecting a trigger. The term trigger, as used herein in this context, may refer to any predefined condition that causes searchable database generation moduleto generate the searchable database. Exemplary triggers include predefined timing conditions (e.g., a threshold amount of time has passed since a last database generation and/or since a reference time (e.g., amount of time since a most recent new data has been received), a threshold amount of new data has been received since a last generation, and so on). A trigger may also be a command manually entered by a user or an administrator. When searchable database generation modulegenerates the searchable database, a prior version may be replaced (e.g., deleted) by the newly generated version, or the prior version may be stored to memory for reference at a later time.

236 260 236 236 260 In some embodiments, searchable database generation modulereceives output from rotability determination modulefor hardware components and generates a searchable data structure from the output. Additionally, or alternatively, searchable database generation moduletakes the known hardware component identifiers from a prior searchable database and inputs those into the trained database generation model. The trained database generation model outputs the hardware component identifiers as mapped to their respective values and optionally other information. The other information may include a confidence value that the respective value for a given hardware component is correct. The other information may include any other information relating to the hardware component (e.g., a rotability determination, expected time to obtain component, expected amount of time between replacements (e.g., if the component is a consumable), expected amount of time to repair (e.g., if the component is rotable), components that may be used to repair the component (e.g., if the component is rotable), identification of similar components, and so on). Database generation modulemay generate a searchable data structure from the output of the trained database generation model as indexed by hardware component. The searchable data structure may be the same or a different structure as the structure that maps output from rotability determination modulewith hardware components.

236 236 236 In an embodiment, responsive to detecting a trigger, database generation moduledetermines whether there is new data to be synthesized prior to generating the searchable data structure. For example, where the trigger is time-based (rather than based on new data being detected), database generation modulemay determine responsive to detecting the trigger whether there is new data to be synthesized. Where there is no new data, database generation modulemay refrain from generating the searchable data structure. This has the technical advantage of improving processing power efficiency, as re-building the searchable database is not needlessly performed where no changes are to be made.

237 237 237 237 237 237 3 FIG. Search modulereceives a query from a user comprising an indicated hardware component. The manner in which the query is generated is described in further detail with respect to. Search modulesearches the searchable database for a result matching the query, e.g., by searching for an entry in the searchable database having a hardware component identifier matching the indicated hardware component. Search moduleoutputs a result comprising a rotability determination for the indicated hardware component. Optionally, search modulealso outputs a confidence that the rotability determination is correct. In some embodiments, search moduleoutputs a result comprising a value for the indicated hardware component. Optionally, search modulealso outputs a confidence that the value is correct. The confidence value may be determined based on a variance of values in the training data. The confidence value may be determined based on a recency, variance of values, and volume in the training data. For example, the training data may be labeled with recency values, and the model may lower confidence where recency is farther out or may lower confidence by a predefined amount corresponding to age as mapped to a deprecation of confidence.

240 130 130 240 232 233 240 241 130 Cache memorystores data for fast access by hardware component service. Fast access is distinguished from slow access, where data is stored in memory remote from hardware component service(e.g., a remote server) or in slower read memory that takes longer to obtain. In an embodiment, historical data (and subsequently, new data) is initially stored in cache memorywhen received until it is used by weighting moduleand/or training module, and then it is removed from the cache memory(e.g., by deleting the data or moving it to slow access memory). Model databasestores models that the hardware component serviceuses, including weighting models and database generation models.

260 260 236 236 236 260 4 5 7 FIGS.-and The rotability determination moduledetermines whether a hardware component is rotable or consumable. As previously described, rotable hardware components can be repaired and re-used on aircraft (e.g., subject to passing inspections and/or regulatory approval), and consumable hardware components are discarded after a single use. Example rotable hardware components include landing gear assemblies, avionics equipment, and engine components. Example consumable hardware components include nuts, bolts, screws, washers, gaskets, and lubricants. A classification for a hardware component output from rotability determination modulemay be referred to as a “rotability determination.” As previously described, searchable databases generated by searchable database generation modulecan include rotability determinations mapped to hardware component identifiers. For example, searchable database generation modulecan receive or retrieve a set of rotability determinations when generating a searchable database. Additionally, or alternatively, searchable database generation modulecan update or modify a previously generated searchable database to include mappings between hardware components and rotability determinations. Rotability determination moduleis further described with respect to.

231 150 234 140 130 Alternative or additional embodiments are possible based on the modules described above. In an embodiment, historical data retrieval moduleretrieves historical data from a plurality of source databases (e.g., source databases) and new data modulereceives new data from a plurality of input databases (e.g., input database) (e.g., again including a respective hardware component identifier and a respective associated value). Hardware component servicemay generate a synthesized set of data by identifying a second subset of data from the historical data. Training data may be generated using the synthesized set.

130 130 130 Hardware component modulemay generate the synthesized set of data by segmenting the historical and new data into any number of segments. In an embodiment, a first subset of the combined new and historical data may be identified that is associated with an anomaly. Anomalies may be identified in any manner described in the foregoing. As an example, in an embodiment, hardware component modulemay input the new data and the historical data into an unsupervised machine learning model, and may receive as output from the unsupervised machine learning model an indication of outlier data (e.g., data that is a threshold distance from any given cluster produced by a clustering model). Hardware component modulemay assign the outlier data to be part of the first subset of data.

130 232 A second subset of the combined new and historical data may be identified that is associated with an attenuation signal. Attenuation signals and entries associated with attenuation signals are subjects that are described in the foregoing and apply equally here. As an example, in an embodiment, hardware component modulemay identify, from the historical data and the new data, stale data that is dated at least a minimum threshold amount of time from a present time, and may assign the stale data to be part of the second subset of data. In such an embodiment, weighting (e.g., performed by weighting module) may weight each entry of the second subset of data based on its respective attenuation signal in a manner that is inversely proportional to a respective amount of time from a present time from a date of the respective entry. A third subset of the combined new and historical data may be identified that includes the remaining data not identified for the first or second subsets.

130 232 233 235 237 238 Hardware component modulemay update the synthesized set of data by discarding (or weighting to 0) the first subset of data from the synthesized set of data, and by weighting (e.g., using weighting module) the second subset of data based on its respective attenuation signal. Where the term “discarding” is used herein, this may refer to either deleting data, or to archiving the data The third subset of data may be not subjected to weighting. Advantageously, this saves on processing power relative to the prior-described embodiment in that weighting, which may be processing-intensive, is only applied to a subset of data, thus improving on processing, memory, and power parameters. Training modulemay then use the synthesized set of data to train a database generation model, which may be used to generate a searchable database using searchable database generation module, with which queries may be processed by search moduleand/or matching moduleaccording to the foregoing.

3 FIG. 3 FIG. 300 310 320 310 310 310 illustrates one embodiment of a user interface showing exemplary manners of searching for hardware components and receiving results. As depicted in, user interfacemay include search tooland/or results. While depicted together, these may be shown in separate screens. Search toolaccepts one or more hardware component identifiers. Optionally, search toolmay accept additional parameters (e.g., a value, where the person submitting the query is seeking to provide a hardware component). While depicted as a drop-down menu, search toolmay accept a hardware component identifier in any known manner (e.g., free text, drop-down, and so on). There may be many ways to identify a hardware component, and any known mechanism may be input (e.g., scan QR code or bar code using a camera sensor, manually input a serial number, inputting a name, and so on).

320 321 322 323 324 324 260 324 260 320 Resultsmay include any data corresponding to a given hardware component identifier. Hardware component sourceis a source from which a hardware component may be obtained. Valueis a value corresponding to the hardware component identifier as determined using the trained database generation model. Confidence scoreis a confidence value by the trained database generation model as determined based on variance in the training data. The rotability determinationis an indicator (e.g., text, image, and/or video) that indicates a determination of whether the hardware component associated with the identifier is rotable or consumable. The rotability determinationmay be generated by the rotability determination module(e.g., previous or responsive to receiving the query) and stored in a searchable database. In some embodiments, the rotability determinationadditionally includes a confidence score for the determination (e.g., also generated by rotability determination moduleand stored in a searchable database). Any other data corresponding to a given hardware component may be included in results(e.g., availability data, lead time to acquire, etc.).

4 FIG. 4 FIG. 4 FIG. 260 260 405 407 410 441 443 130 110 111 150 140 illustrates one embodiment of exemplary modules and databases used by the rotability determination module. As depicted in, rotability determination moduleincludes feature extractor module, model selector module, rotability classification module, model database, and feature database. The modules and databases depicted inare merely exemplary; fewer or more modules and/or databases may be used to achieve the functionality described herein. Moreover, some or all functionality of hardware component servicemay be distributed and/or instantiated at client device(e.g., on application), at one or more of the source databases, at input database, or any combination thereof.

405 405 150 405 405 405 The feature extractor moduleextracts rotable features for hardware components of an aircraft. As used herein, a rotable feature (or just “feature”) for a hardware component may refer to structured data that can be used by a (e.g., machine learned) model to generate a rotable determination for that component. For a given hardware component, feature extractor modulemay extract as many features as possible given the available data (e.g., in the source databases) for that hardware component. However, due to limited and inconsistent data availability for different hardware components, feature extractor modulemay extract different sets of features for different components. For example, for a first component, there may be a large amount of available data such that the feature extractor modulecan extract many features for the first component. However, for a second component, there may be less data available such that the feature extractor modulecan generate only a few features (e.g., only one) for the second component.

405 405 405 150 405 To extract a feature, feature extractor modulereceives data (e.g., via a retrieval process) associated with a hardware component and formats and/or structures that raw data into a feature (which can be input into a model). For example, feature extractor modulereceives raw data, reformats the data, and vectorizes the reformatted data. Examples of formatting, structuring, and vectorizing raw data to form features are described below with respect to the example features. In some embodiments, feature extractor moduleretrieves data from databases (e.g.,) depending on the hardware component. This has the technical advantage of increasing search efficiency as opposed to searching every available database for data on every component, (which may result in feature extractor modulesearching irrelevant resources for information on a component).

405 150 405 150 405 405 231 Feature extractor modulecan receive hardware component data from any number of databases (e.g., source databases). Feature extractor modulemay identify source databasesthrough any known means, such as scraping web data having references to known hardware components. The references to known hardware components may be any identifying feature of a hardware component, such as a name, model number, serial number, or any other identifier. Example data that may be extracted and converted into features by feature extractor moduleis described below with respect to the example features. In some embodiments, feature extractor moduleand historical data retrieval moduleshare functionalities, form a single module, or are the same module.

Example rotable features include text description features, condition code features, exchange indicator features, value features, classification code features, and component prefix features. These features are further described in the following paragraphs.

Text Description Feature. Text description data for a hardware component provides a description of the hardware component. A text description may be useful for making a rotability determination because the descriptions may: (a) directly state whether a component is rotable or consumable, (b) imply whether a component is rotable or consumable, (c) include language or a phraseology that can be correlated with rotability, or (d) any combination thereof.

150 Text description data for a hardware may be taken from any number of databases (e.g., source databases). For example, a database includes a hardware component catalog, and/or listings of hardware components for sale (e.g., from a manufacturer's website or a reseller's website).

150 If there are multiple sources (e.g.,) with text descriptions for a component, those multiple may be combined (e.g., concatenated). The text may be normalized (e.g., removal of stop words, lemmatization, stemming, removal or modification of specific alphanumeric characters or patterns, or any combination thereof). The resulting data may then be vectorized to form a text description feature. In some embodiments, the resulting data is further processed before being vectorized. For example, the frequency of terms is analyzed and the resulting output is then vectorized. For example, a TF-IDF (term frequency-inverse document frequency model converts the resulting data into a numerical format by evaluating the relevance of each term or phrase in the text, where the relevance of each term or phrase increases proportionally to the number of times the term or phrase appears in the text. This conversion results in a text description feature, where each element (e.g., term or phrase) is represented by a TF-IDF score that indicates the relevance.

405 Condition Code Feature. A condition code for a hardware component indicates the condition of the component. Example conditions include: “new” (example code: “N”), “serviceable” (example code: “SV”), “overhaul” (example code “OH”), and “as removed” (example code: “AR”). Serviceable indicates the hardware component should be serviced before being installed on an aircraft (e.g., the component is damaged or broken). Overhaul indicates that the hardware component has been repaired, tested, and can be installed on an aircraft. As removed indicates that the component was removed from an aircraft and the condition of the component is the same as it was when it was removed from the aircraft. A condition code may be useful for making a rotability determination because a condition code may indicate whether a component is rotable or consumable. For example, if a hardware component has (or can have) the condition of serviceable or overhaul, this strongly indicates the component is rotable. Similarly, if a hardware component cannot have the condition of serviceable or overhaul, this indicates the component is consumable. To form a condition code feature, feature extractor modulemay convert a condition code into a vector.

150 Condition codes specified for specific hardware components and condition codes that are possible for hardware components may be taken from any number of databases (e.g., source databases). For example, a database may include listings of hardware components for sale (e.g., from a manufacturer's website or a reseller's website).

Exchange Indicator Feature. The exchange indicator for a hardware component indicates whether the component can be exchanged (e.g., replaced) with another hardware component. More specifically, the exchange indicator indicates whether usable versions (e.g., new versions) of the hardware component are commonly sold by hardware component sellers in exchange for used or worn-out versions of the same hardware component (e.g., that were removed from aircraft). In an exchange, the value of a used or worn-out component may be discounted from the value of the usable version (e.g., new) of the component. If a hardware component is commonly exchanged, this may indicate the used or worn-out components are being serviced and re-sold for use on aircraft, thus suggesting the component is rotable. Example values for an exchange indicator include “true” or “1” if the component is exchangeable and “false” or “0” if the component is not exchangeable).

150 150 405 405 An exchange indicator for a hardware component may be taken from one or more databases (e.g., one or more source databases). For example, a part description (e.g., from a hardware component catalog) states the hardware component is exchangeable. However, an explicit exchange indicator may be uncommon. An exchange indicator for a hardware component may also be generated based on data for the component (e.g., taking from one or more source databases). For example, text descriptions of a hardware component can be analyzed. For example, feature extractor modulesearches text description data for a list of words and phrases that each indicate whether the part is exchangeable (e.g., the list includes synonyms and permutations for the word “exchange”). If the text description includes one or more words or phrases that indicate the part is exchangeable, then the exchange indicator indicates the component is exchangeable. Similarly, if the text description does not indicate the part is exchangeable, or the text description includes one or more words or phrases that indicate the part is not exchangeable, then the exchange indicator indicates the component is not exchangeable. To generate an exchange indicator feature, feature extractor modulemay convert the exchange indicator into a vector.

405 Value Feature. Value data for a hardware component indicates a value of the component. A value may be based on the condition of the component (e.g., the condition code). A value may indicate whether a component is rotable or consumable. For example, rotable components may generally have higher values than consumable components. The value for a component at a given condition may provide a stronger indication of rotability. For example, if the value of an overhauled component is above a predetermined threshold value, the component may be likely rotable. To generate a value feature for a component, feature extractor modulemay convert a value into a vector. The vector may indicate the condition of the component as well (e.g., a condition code).

2 FIG. 237 236 Determining the value of a hardware component was previously described with respect to the modules and databases in. For example, the value of a hardware component be determined by using the database generation model or searching (via the search module) a searchable database generated by searchable database generation module. The value of a component may be the result of a statistical calculation e.g., the average value of the component (e.g., over a threshold time period).

405 Classification code Feature. A classification code for a hardware component classifies the component into a group or category. An entity may generate and apply classification codes to hardware components based on attributes and/or uses of the components, where each code represents a group. Classification codes may be correlated with rotability even if the entity that assigned the codes to hardware components did not consider rotability when assigning the codes. For example, hardware components assigned to a certain classification code may have a 90% likelihood of being rotable. The correlation between classification codes and rotability may be determined e.g., via machine learning or data visualization techniques. To generate a classification code feature for a component, feature extractor modulemay convert a classification code into a vector.

150 Classification codes may be taken from any number of databases (e.g., source databases). For example, a database may include a list of classification codes (mapped to hardware components) retrieved from a hardware component catalog or from a manufacturer's website.

405 Component Prefix Feature. Hardware components are assigned (e.g., unique) identification part numbers that may include alphanumeric characters (e.g., a serial number). A component prefix of a hardware component refers to a threshold number of the first characters of the part number for that component. The prefix of a hardware component may be correlated with the rotability of that component. The correlation may be determined using, for example, via machine learning or data visualization techniques. To generate a component prefix feature for a component, feature extractor modulemay convert the prefix into a vector.

405 443 Features extracted by feature extractor modulemay be stored in feature database.

441 Model databasecan store rotability models. A rotability model can use one or more features to generate a rotability determination. A rotability model may also generate a confidence score indicating the accuracy of the determination (e.g., a probability indicating the rotability determination is correct).

410 410 260 5 FIG. A rotability model may be part of an ensemble model. An ensemble model includes multiple rotability models used in conjunction to generate a final rotability determination. An ensemble model may include individual rotability models that use different combinations of features to generate rotability determinations. As further described with respect to the rotability classification moduleand, an ensemble model includes rotability classification modulethat can receive rotability determinations from the individual rotability models and can generate a final rotability determination based on the rotability determinations. The final rotability determination may be output by rotability determination module.

260 405 Among other advantages, an ensemble model enables rotability determination moduleto generate rotability determinations for a large number of hardware components despite limited and inconsistent data availability for the individual hardware components. For example, even if feature extractor moduleis able to extract only a few features for a given hardware component (due to limited availability of data on the component), the use of an ensemble model enables generation of a rotability determination for that component. Furthermore, an ensemble model may have a better predictive performance than any of the individual rotability models used alone.

Example rotability models are described below. Each rotability model described below may be a machine learned model, a heuristic model, a model with custom logic, or any combination thereof. To generate a model, the correlation between the input feature(s) and a rotability determination may be determined using machine learning or data visualization techniques for known rotable and consumable hardware components. If a rotability model is machine learned, example training methods include random forest and logistic regression. The type of training may be based on which training results in better predictive performance. Training data for a machine learned model may be generated for known rotable and consumable hardware components by labeling a set of one or more features of the component with the known rotability classification (in other words, the label of the known rotability classification is treated as ground truth).

As previously mentioned, the number of known rotable and consumable hardware components is small compared to the total number of hardware components. Knowledge of known rotable and consumable hardware components may be ascertained from industry experts. To increase knowledge rotable and consumable hardware components (e.g., to increase the amount of training data for rotability models), components may be tracked on maintenance reports for aircraft. For example, if a hardware component (with a unique identification number) is removed from an aircraft but that same component (with the unique identification number) is later installed on another aircraft, this may indicate the component is rotable. Similarly, if a hardware component (with a unique identification number) is removed from an aircraft but not installed on another aircraft (e.g., after a threshold amount of time), this may indicate the component is consumable.

Prefix Model. The prefix model receives a component prefix feature as input and outputs a rotability determination. In some embodiments, a prefix model is trained using training data generated by labeling component prefix features for known rotable and consumable hardware components with the known rotability classifications. The prefix model may be generated using custom logic e.g., based on data visualizations. For example, a user reviews prefix features for known rotable and consumable hardware components (e.g., via a graph or plot), determines patterns from their observations, and encodes logic consistent with their determinations. In some embodiments, the prefix model is a machine learned model trained from training data that includes prefix features for known rotable and consumable hardware components labeled with known rotable determinations.

Text Model. The text model receives a text description feature as input and outputs a rotability determination. If the text model is a machine learned model, training data for the text model may include text description features for hardware components (that are known rotable and/or consumable hardware components (and optionally condition code features)) labeled with the known rotable determinations of those components. In embodiments where text description features include the results of a TF-IDF model (or another frequency analysis model), the text model may be a machine learning model trained to correlate TF-IDF scores of the text description features to rotability determinations.

Value Determination Model (also “value model”). The value model receives a value feature as input and outputs a rotability determination. In some embodiments, the value model receives a condition code feature (in addition to a value feature) to generate a rotability determination. The value determination model may be a logistical regression model. If the value determination model is a machine learned model, training data for the value determination model may include value features for hardware components (that are known rotable and/or consumable hardware components (and optionally condition code features)) labeled with the known rotable determinations of those components.

Classification Code Model. The classification code model receives a classification code feature as input and outputs a rotability determination. If the classification code model is a machine learned model, training data for the classification code model may include classification code features for hardware components (that are known rotable and/or consumable hardware components) labeled with known rotable determinations for those components.

Indicator model. The indicator model can receive a condition code feature and/or exchange indicator feature as input and output a rotability determination. Depending on the implementation, the indicator model may additionally, or alternatively, receive other features as input. The indicator model may be a random forest model. If the indicator model is a machine learned model, training data for the indicator model may include condition code features and/or exchange indicator features for hardware components (that are known rotable and/or consumable hardware components) labeled with known rotable determinations for those components.

5 FIG. The example rotability models described above are further described below with respect to.

407 443 405 407 441 407 407 The model selector modulereceives (e.g., via a retrieval process) extracted features for a hardware component (e.g., from feature databaseand/or feature extractor module). Model selector moduleidentifies, given the available features, rotability models (e.g., stored in model database) that can use one or more of the available features to generate rotability determinations. After the identification, the model selector moduleprovides the appropriate features to the corresponding models as input. For example, if the text description feature and the prefix feature are available for a given hardware component, the model selector modulemay identify the text model and prefix model and then input the text description feature into the text model and input the prefix feature into the prefix model.

407 407 260 441 407 In some embodiments, model selector moduleidentifies every available rotability model that can use one or more of the available features for a given hardware component. In other embodiments, model selector modulelimits its identification to rotability models in an ensemble model (or multiple ensemble models) that can use the available features. For example, if rotability determination moduleis using an ensemble model that includes a subset of all the available rotability models (e.g., in model database), model selector modulemay only identify rotability models in the subset that can use the available features for a given hardware component.

508 407 407 5 FIG. In some embodiments, an ensemble model includes the selection of one or more models from a set of models (e.g., see model setin). In these embodiments, model selector modulemay select models in the set based on the available features. In some cases, model selector moduleadditionally selects the one or more models based on the models' reliability or historical performance. For example, use of the value model and the classification code model may be preferred over the indicator model.

410 260 410 410 260 The rotability classification modulereceives one or more rotability determinations for a hardware component (from one or more rotability models) and determines a final rotability determination as output for rotability determination module. As used herein, a “final” rotability determination may refer to a rotability determination made by rotability classification moduleand based on one or more rotability determinations (from one or more rotability models). A rotability determination from a rotability model may be referred to as an “initial” rotability determination. Rotability classification modulemay also determine a confidence score for the final rotability determination (this may also be output for rotability determination module). For example, the confidence score is a probability indicating the rotability determination is correct.

410 410 Rotability classification modulemay be a machine learned model, a heuristic model, a model with custom logic, or any combination thereof. Final rotability determinations may be based on the initial rotability determinations, confidence scores of the initial rotability determinations, reliability or historical performance of the models that generate the initial rotability determinations, or any combination thereof. In a first example, a final rotability determination corresponds to the initial rotability determination with the strongest (e.g., highest) confidence score. In a second example, rotability classification moduleis a weighted sum model with an assigned weight for each rotability determination. Each weight may be based on the model that made the rotability determination (e.g., the reliability or historical performance of the model). In another example, each weight is related to a confidence score for the rotability determination (output by the model that generated the rotability determination).

In some embodiments, the rotability determination from a first rotability model with the lowest reliability or historical performance may be disregarded if a second rotability model (or multiple models) with a higher reliability or historical performance outputs a contradictory rotability determination (e.g., even if the confidence score from the first model is higher than the confidence score from the second model). For example, if the prefix model has a low historical performance score but the text model and the value model have high historical performance scores, the rotability determination from the prefix model (e.g., it determines the component is rotable) may be disregarded or ignored if the text model and the value model output contradictory determinations (e.g., both determine the component is consumable).

410 410 If initial rotability determinations contradict each other (e.g., two rotability determinations (e.g., with the same confidence scores) contradict each other), rotability classification modulemay include custom logic to make a final determination. For example, in the case of a tie, rotability classification moduleinspects one or more reliable features (e.g., the classification code feature or value feature) to determine the final determination.

410 236 Final rotability determinations from rotability classification moduleare added to a searchable database that maps hardware components to their final rotability determinations. More specifically, for a given final rotability determination for a hardware component, a data structure for the hardware component with the final determination is added to a new or preexisting searchable database (e.g., a row or column is added to the searchable database table.). For example, a searchable database is generated to include the data structure for the hardware component with the final determination. A searchable database with the data structures may be generated or modified by searchable database generation module.

260 410 324 300 324 324 260 410 410 410 In some embodiments, rotability determination modulecan update (e.g., retrain) one or more rotability models and/or rotability classification modulebased on feedback from users (e.g., via a retaining module). Feedback from a user may indicate whether a rotability determination (e.g.,) is correct. For example, a user provides feedback by interacting with user interfaceafter a rotability determinationis displayed. If a threshold amount of feedback is received indicating a rotability determination (e.g.,) is incorrect, rotability determination modulemay update (e.g., retrain) rotability classification moduleand/or one or more rotability models used to generate the final rotability determination. For example, the threshold amount of feedback may be used as ground truth data. Whether rotability classification moduleand/or one or more rotability models are updated may depend on the arrangement of the ensemble model, the accuracy of the initial rotability determinations from the individual models, and/or how rotability classification modulemade the final rotability determination.

5 FIG. 500 260 525 523 500 507 509 508 508 511 513 515 407 508 407 407 407 407 511 513 515 407 511 407 513 515 is a diagram that illustrates the flow of inputs and outputs of an example ensemble model(of the rotability determination module) to generate a searchable databasewith a final rotability determinationfor a hardware component. Ensemble modeluses three models (however, an ensemble model may have additional or fewer models). The three models include the prefix model, the text model, and one model from model set(however, an ensemble model may include additional, fewer, or different models). Model setincludes the value model, the classification code model, and the indicator model. Model selector modulemay determine which model from model setis used. For example, model selector moduleselects the model based on the available features for the hardware component. If enough features are available that multiple models from the set may be used, model selector modulemay select all models that can use the available features. Alternatively, model selector modulemay select one of the models from the set e.g., based on model reliability or historical performance. For example, model selector modulemay prefer the models in the following order: value model, classification code model, and indicator model(e.g., based on model reliability or historical performance). In a more specific example, model selector modulechecks if a value feature is available. If so, value modelis used. If not, model selector modulechecks if a classification code feature is available. If so, classification code modelis used. If not, indicator modelis used.

500 508 Ensemble modelmay be structured according to (e.g., typical) data availability for hardware components. In this example, component prefix features and text description features are available for many (e.g., all or most) hardware components, but other features are less available (e.g., the condition code, exchange indicator, value, and classification code features are inconsistently available for components). Thus, the third model may be selected from model setfor each hardware component according to which feature(s) are available for that component. However, if the typically data availability is different, then an ensemble model with a different arrangement and/or different models may be used.

500 407 505 507 503 509 501 508 On the left side, features are input into the models of ensemble model(e.g., by model selector module). More specifically, a component prefix featurefor a hardware component is input into prefix model, a text description featurefor the hardware component is input into text model, and a feature set(of one or more features) is input into the selected model from model set.

517 519 521 410 410 523 The three models each output initial rotability determinations (labeled,, and). The rotability determinations are input into rotability classification module. As previously described, rotability classification moduledetermines a final rotability determination (labeled as).

523 525 525 525 236 Final rotability determinationis added to a searchable databasethat maps hardware components to their final rotability determinations. More specifically, a data structure for the hardware component with the final determination is added to a new or preexisting database. For example, searchable databaseis generated to include the data structure for the hardware component with the final determination. Searchable databasemay be generated or modified by searchable database generation module.

6 FIG. 6 FIG. 600 624 602 FIG. (is a block diagram illustrating components of an example machine able to read instructions from a machine-readable medium and execute them in a set of one or more processors (or controllers). Specifically,shows a diagrammatic representation of a machine in the example form of a computer systemwithin which program code (e.g., software) for causing the machine to perform any one or more of the methodologies discussed herein may be executed. The program code may be comprised of instructionsexecutable by one or more processors. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

624 624 The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a smartphone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions(sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines (e.g., a database cluster and/or a server cluster) that individually or jointly execute instructionsto perform any one or more of the methodologies discussed herein.

600 602 604 606 608 602 600 610 610 600 612 614 616 618 620 608 The example computer systemincludes a set of one or more processors(e.g., one or more central processing units (CPUs), one or more graphics processing units (GPUs), one or more digital signal processors (DSPs), one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), or any combination of these), a main memory, and a static memory, which are configured to communicate with each other via a bus. If the processor setincludes multiple processors, the processors may operate collectively or individually. The computer systemmay further include visual display interface. The visual interface may include a software driver that enables displaying user interfaces on a screen (or display). The visual interface may display user interfaces directly (e.g., on the screen) or indirectly on a surface, window, or the like (e.g., via a visual projection unit). For ease of discussion the visual interface may be described as a screen. The visual interfacemay include or may interface with a touch enabled screen. The computer systemmay also include alphanumeric input device(e.g., a keyboard or touch screen keyboard), a cursor control device(e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a storage unit, a signal generation device(e.g., a speaker), and a network interface device, which also are configured to communicate via the bus.

616 622 624 624 604 602 600 604 602 624 626 620 The storage unitincludes a machine-readable mediumon which is stored instructions(e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions(e.g., software) may also reside, completely or at least partially, within the main memoryor within the processor set(e.g., within a processor's cache memory) during execution thereof by the computer system, the main memoryand the processoralso constituting machine-readable media. The instructions(e.g., software) may be transmitted or received over a networkvia the network interface device.

622 624 624 While machine-readable mediumis shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions (e.g., instructions). The term “machine-readable medium” shall also be taken to include any medium that is capable of storing instructions (e.g., instructions) for execution by the machine and that cause the machine to perform any one or more of the methodologies disclosed herein. The term “machine-readable medium” includes, but not be limited to, data repositories in the form of solid-state memories, optical media, and magnetic media.

7 FIG. 7 FIG. 7 FIG. 130 600 is a flowchart of an example method for generating a rotability determination for a hardware component and for outputting the determination. In the example of, the method is performed by hardware component service. The method can include additional or fewer steps than described herein. Additionally, the steps can be performed in different order or by different components than described herein. In some embodiments, the method is performed by a computing system (e.g.,) executing code stored on a (e.g., non-transitory) computer-readable storage medium that causes the computing system to perform the steps of the method of.

710 130 405 501 503 505 At step, hardware component service(e.g., feature extractor module) extracts a plurality of features (e.g.,,,) of a hardware component of an aircraft.

715 130 407 501 511 At step, hardware component service(e.g., model selector module) inputs a first subset of one or more features of the plurality of features into a first machine learning model (e.g.,input into)

720 130 410 517 At step, hardware component service(e.g., rotability classification module) receives, as output from the first machine learning model, a first determination of whether the hardware component is rotable (e.g.,).

725 130 407 503 509 At step, hardware component service(e.g., model selector module) inputs a second subset of one or more features of the plurality of features into a second machine learning model (e.g.,into).

730 130 410 519 At step, hardware component service(e.g., rotability classification module) receives, as output from the second machine learning model, a second determination of whether the hardware component is rotable (e.g.,).

735 130 410 523 At step, hardware component service(e.g., rotability classification module) determines, based on the first determination and the second determination, a final determination of whether the hardware component is rotable (e.g.,).

740 130 236 525 At step, hardware component service(e.g., searchable database generation module) adds a data structure for the hardware component with the final determination in a searchable database (e.g.,).

745 130 237 237 3 FIG. At step, hardware component service(e.g., search module) receives a query from a user, where the query is associated with the hardware component. For example, see the description with respect to search moduleandand its description.

750 130 237 237 3 FIG. At step, hardware component service(e.g., search module) searches the searchable database for a result matching the query. For example, see the description with respect to search moduleandand its description.

755 130 237 324 237 3 FIG. At step, hardware component service(e.g., search module) outputs a result comprising the final determination of whether the hardware component is rotable (e.g., rotability determination). For example, see the description with respect to search moduleandand its description.

130 405 150 In some embodiments, hardware component service(e.g., feature extractor module) extracting the plurality of features of the hardware component of the aircraft includes: searching a plurality of databases (e.g., source databases) for text corresponding to the hardware component; and transforming the text corresponding to the hardware component into at least some of the plurality of features.

130 511 The method may further include hardware component serviceselecting the first machine learning model from a plurality of candidate first machine learning models by: determining whether the plurality of features comprises a classification (e.g., a classification code feature); and responsive to determining that the plurality of features does not comprise the classification, selecting the first machine learning model to be a value determination model (e.g.,).

503 405 150 509 The second subset of features (e.g.,) may be generated (e.g., by feature extractor module) by: searching a plurality of databases (e.g., source databases) for text corresponding to the hardware component, and concatenating the text from the plurality of databases into a vector; and where the second machine learning model (e.g.,) at least partially bases the second determination on a frequency of terms within the vector. Generating the second subset of features may further include normalizing the text from the plurality of database for use in the vector.

130 407 505 507 130 410 521 523 410 523 521 519 517 The method may further include hardware component service(e.g., model selector module) inputting a third subset of one or more features of the plurality of features into a third machine learning model (e.g.,into); and hardware component service(e.g., rotability classification module) receiving, as output from the third machine learning model, a third determination of whether the hardware component is rotable (e.g.,), where the final determination of whether the hardware component is rotable (e.g.,) is further based on the third determination. The third subset of features may include one or more part number prefixes for the hardware component. The third machine learning model may be trained using training examples of given part number prefixes as labeled by whether a given part number prefix is rotable. In some embodiments, rotability classification moduledetermining the final determination (e.g.,) comprises ignoring the third determination (e.g.,) when the first determination (e.g.,) and the second determination (e.g.,) are consistent and factoring in the third determination when the first determination and the second determination are inconsistent.

Other aspects include components, devices, systems, improvements, methods, processes, applications, computer readable mediums, and other technologies related to any of the above.

Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

Accordingly, the term “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. As used herein, “hardware-implemented module” refers to a hardware module. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.

Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple of such hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).

The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.

Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors or processor-implemented hardware modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.

The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).)

The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.

Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., a computer memory). These algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an “algorithm” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities.

Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

As used herein any reference to “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.

Some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. It should be understood that these terms are not intended as synonyms for each other. For example, some embodiments may be described using the term “connected” to indicate that two or more elements are in direct physical or electrical contact with each other. In another example, some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.

Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims. While hardware components described herein are generally referred to as “aircraft” components, the term aircraft is not intended to be limiting, and hardware components for any other item may be used instead.