Patent Application
20200333772
Computer systems can be used to create, use, and manage data for products and other items. Examples of computer systems include computer-aided design (CAD) systems (which may include computer-aided engineering (CAE) systems), visualization and manufacturing systems, product data management (PDM) systems, product lifecycle management (PLM) systems, and more. These systems may include components that facilitate design and simulated testing of product structures and product manufacture.
Certain examples are described in the following detailed description and in reference to the drawings.
The discussion below refers to conceptual plans and conceptual planning. Conceptual planning (sometimes referred to as conceptual process planning or conceptual design) may refer any evaluation and manufacturing planning with regards to the manufacturability or manufacturing cost of product assemblies in initial design stages. A conceptual plan may refer to any data record that specifies how a product can be manufactured, and may thus include layouts, designs, requisite resources, operational steps, etc. In some instances, a conceptual plan may include a bill of materials (“BoM”) that specifies material elements used to manufacture a given product, a bill of processes (“BoP”) that specifies manufacturing processes used to manufacture the given product, and a bill of resources (“BoR”) that specifies resources used to perform the manufacturing processes to manufacture the given product. As such, conceptual plans may be used to evaluate, design, and configure manufacturing assemblies and BoRs for use in product manufacture.
Conceptual planning may provide a mechanism to assess the manufacturability and cost of production at earlier points of a product design process, which may be important as significant costs may be invested in product specification and design. However, manufacturability decisions in early design stages can be challenging as such decisions may need to account for unpredictable factors in manufacturability, quality, reliability, serviceability, etc. With current technological advances, products are becoming increasingly complex, and can include millions of parts or more. Moreover, ever-increasing manufacturing capabilities and increasing scales of manufacturing processes (e.g., hundreds of non-modular welding robots in a given manufacturing plant to perform a manufacturing process step) can further complicate generation of conceptual plans. Generation of conceptual plans are often heavily dependent on field experts and are often times create manually, thus requiring significant time investment and are prone to human error.
The disclosure herein may provide systems, methods, devices, and logic for semantic modeling and machine learning (“ML”)-based generation of conceptual plans. As described in greater detail herein, various ML techniques may be applied to past conceptual planning data to learn manufacturing constraints (e.g., rules, dependent operations, etc.) for use in automatic conceptual plan generation. In that regard, ML-based generation of conceptual plans may support extraction, capture, and learning of the expertise, experience, and knowledge of human engineers as manifested into prior conceptual plans and modify/populate a semantics definition of the manufacturing process. Such “knowledge” capture may be supported through semantic modeling by using an ontology to define data elements in BoMs, BoPs, and BoRs and denote relationships between defined ontological elements. As such, the various ML-based conceptual plan features described herein may include semantic modeling via ontologies of support the application of ML techniques and automatic conceptual plan generation.
Captured knowledge (e.g., embedded within instance graphs) may be used as training data for machine learning algorithms, by which new conceptual plans can be generated via learned classifiers, learned manufacture rules (e.g., as part of a model or as learned via local data patterns), or via other machine learning applications. In effect, the ML-based conceptual plan generation features described herein may leverage past conceptual planning data (that may be embedded with implicit knowledge made via human decisions) to extract such “knowledge” in the form of semantic models and to use ML-extracted knowledge in a current workflow to produce a new conceptual plan.
These and other ML-based conceptual plan generation features are described in greater detail herein.
As described in greater detail in the present disclosure, the computing system 100 supports ML-based conceptual plan generation. In an insight mode, the computing system 100 may extract “knowledge” from past conceptual plans, which may include representing such conceptual plans according to an insighter ontology. Examples of such representations include instance graphs that the computing system 100 may automatically extract or produce from BoMs, BoPs, and BoRs of previously-manufactured products. The instance graphs may be provided as training data to ML algorithms to learn “knowledge”, e.g., manufacturing constraints, from past conceptual planning data. In a predictor mode, the computing system 100 may apply learned knowledge to automatically generate conceptual plans for variant (e.g., new) products. Instead of time-consuming human-driven design of conceptual plans, the computing system 100 may support automatic, ML-based generation of conceptual plans by leveraging learned manufacturing constraints and insight captured using semantic models from prior designs. Accordingly, the ML-based conceptual plan generation features described herein may improve the effectiveness and speed of conceptual planning processes.
As an example implementation to support the ML-based conceptual plan generation features described herein, the computing system 100 shown in
In operation, the insighter engine 108 may access conceptual plans for previously manufactured products, wherein a given conceptual plan may include a BoM specifying material elements used to manufacture a given product, a BoP specifying manufacturing processes used to manufacture the given product, and a BoR specifying resources used to perform the manufacturing processes to manufacture the given product. The insighter engine 108 may further represent the conceptual plans according to an insighter ontology, the insighter ontology defining elements of the BoM, BoP, and BoR and relationships between the elements and apply machine learning, using the conceptual plans represented according to the insighter ontology as training data, to learn manufacturing constraints not already represented in the conceptual plans. In operation, the predictor engine 110 may access a BoM for a variant product that differs from the previously manufactured products and apply (at least one of) the learned manufacturing constraints to generate a predicted BoP and a predicted BoR for the variant product.
These and other ML-based conceptual plan generation features according to the present disclosure are described in greater detail next.
In
In supporting semantic modeling and ML-based generation of conceptual plans, the insighter engine 108 may support automated analysis of the conceptual plans 210. As such, the insighter engine 108 may implement a capability to generate computer-interpretable representations of domain knowledge or human expertise (e.g., based on past experience and past conceptual plan designs) as manifested in the conceptual plans 210. Such data representation may be supported through semantic modeling using an ontology, such as the insighter ontology 220 shown in
The classification scheme through which the insighter ontology 220 defines ontological elements may vary in form. For instance, the insighter ontology 220 may utilize any of the concepts and features as described in “Towards a Formal Manufacturing Reference Ontology”, Zahid Usman, R. I. M. Young, Nitishal Chungoora, Claire Palmer, Keith Case, and J. A. Harding, International Journal of Production Research, Vol 51, No. 22, pp. 6553-657 (2013), which is incorporated herein by reference in its entirety. By using the insighter ontology 220, the insighter engine 108 may encapsulate raw data (e.g., as specified in BoMs 211, BoPs 212, and BoRs 213 of the conceptual plans 210) into a computer-interpretable form. Explained in a different way, the insighter engine 108 may utilize the insighter ontology 220 to produce representations of the conceptual plans 210 (as defined according to the insighter ontology 220) using consistent data modeling terms from which manufacturing constraints can be learned and extracted via ML techniques.
In some implementations, the insighter engine 108 may represent the conceptual plans 210 according to an insighter ontology 220 in the form of instance graphs. In
To generate the instance graphs 230, the insighter engine 108 may parse conceptual planning data. For instance, the insighter engine 108 may access a given conceptual plan, and parse the BoM 211, BoP 212, and BoR 213 of the given conceptual plan to extract ontological elements (e.g., nodes) as defined by the insighter ontology 220. In such a manner, the insighter engine 108 may construct a respective instance graph for each given conceptual plan, forming edges between ontologically-defined elements extracted from the BoM 211, BoP 212, and BoR 213 based on identified dependencies, constraints, or rules specified in the conceptual planning data.
The insighter engine 108 may apply various ML techniques to conceptual plans 210 represented as the instance graphs 230 according to the insighter ontology 220. For instance, the insighter engine 108 may provide generated instance graphs 230 as training data to any number of ML algorithms. In the example shown in
As an illustrative example, the ML algorithms 240 may implement a ML-based rule induction approach by which the insighter engine 108 may extract, learn, or capture manufacturing constraints from the training data. Other examples for the ML algorithms 240 include association rules mechanisms, rules learning techniques, or any other rules-based ML techniques that the insighter engine 108 may implement through the ML algorithms 240 to support learning and knowledge extraction from the conceptual plans 210. As such, the insighter engine 108 may support the extraction, learning, and capture of “knowledge” embedded in the conceptual plans 210, specifically in the form of learned manufacturing constraints.
As used herein, a manufacturing constraint may refer to any rule, dependency, limitation, or restriction applicable to manufacture of a product. Manufacturing constraints may be represented as one or more edges between different nodes of the instance graphs 230, for example. In some instances, the insighter engine 108 may learn, via application of the ML algorithms 240, manufacturing constraints not already (expressly) represented in the conceptual plans 210. Learned manufacturing constraints may modify expressly-represented constraints from one or more of the conceptual plans 210, whether by removing redundant dependencies or learning variants of existing constraints. In the context of training data provided as the instance graphs 230, the insighter engine 108 may apply the ML algorithms 240 to learn, identify, or extract paths between nodes of the instance graphs 230 with reduced cost, a lesser number of hops, or according to any other valuation metric.
Manufacturing constraints learned via the ML algorithms 240 may take the form of a ML-model determined from the training data, local patterns in the training data, or combinations thereof. In
The insighter engine 108 may store the learned manufacturing constraints 250 in a knowledge database 260, which may be local or remote to the insighter engine 108 (or a computing system 100 implementing the insighter engine 108). The knowledge database 260 may be used to store any form of conceptual planning data, and may thus additionally or alternatively store the conceptual plans 210, BoMs 211, BoPs 212, BoRs 213, the instance graphs 230, the insighter ontology 220, etc. In that regard, the knowledge database 260 may provide repository of expressly-specified conceptual planning data (e.g., the conceptual plans 210, as represented by the instance graphs 230), extracted “knowledge” in the form of learned manufacturing constraints 250, and the like. The knowledge database 260 may be accessed for subsequent generation of conceptual plans, e.g., as described in greater detail below with reference to
By learning and extracting manufacturing constraints from the instance graphs 230 (or any other form of the conceptual plans 210 as represented according to the insighter ontology 220), the insighter engine 108 may support automatic generation of conceptual plans. However, one challenge faced in ML-based conceptual plan generation is that the ML algorithms 240 may require a significant amount of training data. Example features to augment training data for ML-based conceptual plan generation is described next with reference to
To augment training data, the insighter engine 108 may perform data perturbation on past conceptual planning data to produce augmented training data to provide to the ML algorithms 240. In particular, the insighter engine 108 may modify a BoM of a previously manufactured product as a form of data perturbation. In
From a modified BoM 311, the insighter engine 108 may determine an adjusted BoP 312 and an adjusted BoR 313. The insighter engine 108 may make such determinations via a rule-based approach. For instance, the insighter engine 108 may apply user-input rules as provided for specific BoM perturbations applied by the insighter engine 108. In some examples, the insighter engine 108 may apply any number of manufacturing constraints as stored or maintained in the knowledge database 260. As such, the insighter engine 108 may determine the adjusted BoP 312, the adjusted BoR 313, or both by applying one or more learned manufacturing constraints stored in the knowledge database 260. In the specific example shown in
Through BoM perturbation and determination of adjusted BoPs 312 and adjusted BoRs 313, the insighter engine 108 may obtain an adjusted conceptual plan 320. The adjusted conceptual plan may differ from a pre-existing conceptual plan, and may provide another data sample from which the ML algorithms 240 may extract “knowledge” from (e.g., in the form of learned manufacturing constraints). As seen in
In some implementations, the insighter engine 108 may generate augmented training data by directly perturbing instance graphs for previously-manufactured products. In that regard, the insighter engine 108 may directly modify one or more ontological elements (e.g., nodes) of an existing instance graph, such as a node that specifies a particular product component or attribute thereof. Then, the insighter engine 108 may modify any dependent or corresponding nodes to account for the perturbation, e.g., by modifying process or resource ontological elements that depend from the modified material element. In such a way, the insighter engine 108 may support augmentation of training data for ML-based conceptual plan generation.
As yet another training data augmentation feature, the insighter engine 108 may process unstructured conceptual planning data into training data for the ML algorithms 240. Unstructured conceptual planning data can include, as examples, design documents, comments, notes from a human planner during present or prior conceptual planning processes. In such instances, the insighter engine 108 may implement any number of natural language processing (“NLP”) capabilities to classify the unstructured data into specific classes (for e.g., materials, processes, resources, etc.). The insighter engine 108 may do so through a ML-based classifier that the insighter engine 108 may implement, e.g., through a deep neural network. From the NLP classification, the insighter engine 108 may apply the insighter ontology 220 to represent any extracted and classified data in a format interpretable by the ML algorithms 240. In effect, and as a particular example, the insighter engine 108 may convert natural language or unstructured data into instance graph elements in accordance with the insighter ontology 220. In doing so, the insighter engine 108 may further augment training data from which the ML algorithms 240 may extract knowledge and learn manufacturing constraints.
Through any of the various insight mode features described herein, the insighter engine 108 may extract knowledge from past conceptual planning data in the form of learned manufacturing constraints, doing so via machine learning. Through such ML-based constraint extraction processes, subsequent generation of conceptual plans may be automated with increased accuracy and effectiveness. Example features of ML-based generation of conceptual plans via application of learned manufacturing constraints are described next with reference to
In some implementations, the predictor engine 110 may train machine learning models to generate conceptual planning data. For instance, the predictor engine 110 may train the ML model 410 shown in
Via the ML model 410 or in various other ways, the predictor engine 110 may automatically generate conceptual plans. In particular, the predictor engine 110 may automatically generate predicted BoPs and predicted BoRs from input BoMs. To illustrate through
The predictor engine 110 may generate the predicted BoP 430 or the predicted BoR 440 in a template-based manner. For instance, the predictor engine 110 may compare the input BoM 420 to BoMs stored in the knowledge database 260. For any stored BoM that exceeds a similarity threshold from the input BoM 420 (e.g., above a similarity threshold percentage of identical material elements or component properties), the predictor engine 110 may use the corresponding BoP and BoR of the stored BoM as a baseline template to modify into the predicted BoP 430 and predicted BoR 440. In doing so, the predictor engine 110 may identify new requirements, product components, or changes between the input BoM and an identified BoM, adapting the baseline templates of corresponding BoP and BoR to address the changes included in the input BoM. Moreover, the predictor engine 110 may apply one or more learned manufacturing constraints to ensure that any adaptations to the BoP and BoR baseline templates do not violate any identified or learned manufacturing constraints. In other implementations, the predictor engine 110 may generate the predicted BoP 430 or the predicted BoR 440 without reference or reliance on a baseline template, e.g., using the ML model 410 to construct a new BoP or BoR from the input BoM 420.
In a such a manner, the predictor engine 110 may support ML-based automatic generation of conceptual plans. In accordance with the various features described herein, the predictor engine 110 may provide additional or alternative features to process input BoMs 420 and assist in conceptual planning. For example, the predictor engine 110 may automatically search and identify similar or relevant past conceptual planning data from the knowledge database 260, e.g., according to similarity thresholds, and process the input BoM 420 accordingly. As such, the predictor engine 110 may identify one or more processes (in a BoP) that require modification based on the input BoM 420 and suggest BoP and BoR adaptations, including plant resource assignments for the identified processes.
In some implementations, the predictor engine 110 may validate the predicted BoP 430 and predicted BoR 440 generated for a variant product. As a specific example, the predictor engine 110 may evaluate impact and risk of process adaptations specified in the predicted BoP 430 and plant reconfigurations as specified in the predicted BoR 440. The predictor engine 110 may, for example, validate the predicted BoP 430 and the predicted BoR 440 using simulation and according to a selected set of key performance indicators (KPIs). In doing so, the predictor engine 110 may provide an assessment of how an automatically generated conceptual plan (or BoP and BoR components thereof) may perform based on the KPIs or any other configurable validation parameters.
As described herein, ML-based conceptual plan generation features may utilize historic conceptual planning data (e.g., BoM/BoP/BoR data) for learning BoM/BoP/BoR-mappings via semantic models and determining explicit and learned manufacturing constraints in conceptual plans. In that sense, the semantic modeling and ML-based conceptual plan generation features described herein may identify, extract, and capture patterns and knowledge embedded in previous conceptual planning designs and leverage the learned constraints in subsequent conceptual plan generation.
In implementing the logic 500, the insighter engine 108 may access conceptual plans for previously manufactured products (502), and a given conceptual plan may include a BoM specifying material elements used to manufacture a given product, a BoP specifying manufacturing processes used to manufacture the given product, and a BoR specifying resources used to perform the manufacturing processes to manufacture the given product. The insighter engine 108 may further represent the conceptual plans according to an insighter ontology (504), the insighter ontology defining elements of the BoM, BoP, and BoR and relationships between the elements, as well as apply machine learning, using the conceptual plans represented according to the insighter ontology as training data, to learn a manufacturing constraint not already represented in the conceptual plans (506).
In implementing the logic 500, the predictor engine 110 may access a BoM for a variant product that differs from the previously manufactured products (508) and apply the learned manufacturing constraint to generate a predicted BoP and a predicted BoR for the BoM of the variant product (510).
The logic 500 shown in
Additional or alternative steps in the logic 500 are contemplated herein, including according to any features described for the insighter engine 108, predictor engine 110, or any combinations thereof.
The system 600 may execute instructions stored on the machine-readable medium 620 through the processor 610. Executing the instructions (e.g., the insighter instructions 622 and/or the predictor instructions 624) may cause the system 600 to perform any of the semantic modeling and ML-based conceptual plan generation features described herein, including according to any of the features with respect to the insighter engine 108, the predictor engine 110, or a combination of both.
For example, execution of the insighter instructions 622 by the processor 610 may cause the system 600 to access conceptual plans for previously manufactured products, wherein a given conceptual plan may comprise a BoM specifying material elements used to manufacture a given product, a BoP specifying manufacturing processes used to manufacture the given product, and a BoR specifying resources used to perform the manufacturing processes to manufacture the given product. Execution of the insighter instructions 622 by the processor 610 may further cause the system 600 to represent the conceptual plans according to an insighter ontology, the insighter ontology defining elements of the BoM, BoP, and BoR and relationships between the elements, and apply machine learning, using the conceptual plans represented according to the insighter ontology as training data, to learn a manufacturing constraint not already represented in the conceptual plans.
Execution of the predictor instructions 624 by the processor 610 may cause the system 600 to access a BoM for a variant product that differs from the previously manufactured products and apply the learned manufacturing constraint to generate a predicted BoP and a predicted BoR for the BoM of the variant product.
Any additional or alternative features as described herein may be implemented via the insighter instructions 622, predictor instructions 624, or a combination of both.
The systems, methods, devices, and logic described above, including the insighter engine 108 and the predictor engine 110, may be implemented in many different ways in many different combinations of hardware, logic, circuitry, and executable instructions stored on a machine-readable medium. For example, the insighter engine 108, the predictor engine 110, or combinations thereof, may include circuitry in a controller, a microprocessor, or an application specific integrated circuit (ASIC), or may be implemented with discrete logic or components, or a combination of other types of analog or digital circuitry, combined on a single integrated circuit or distributed among multiple integrated circuits. A product, such as a computer program product, may include a storage medium and machine-readable instructions stored on the medium, which when executed in an endpoint, computer system, or other device, cause the device to perform operations according to any of the description above, including according to any features of the insighter engine 108, the predictor engine 110, or combinations thereof.
The processing capability of the systems, devices, and engines described herein, including the insighter engine 108 and the predictor engine 110, may be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems or cloud/network elements. Parameters, databases, and other data structures, including the knowledge database 260, may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may implemented in many ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms. Programs may be parts (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library (e.g., a shared library).
While various examples have been described above, many more implementations are possible.
