JP2019502222A - Extending the virtual model - Google Patents

Abstract

A method is provided for automatically generating an extended model of a physical component. The method includes reading an input model into a processor, the input model describing a nominal operating mode for a physical component modeled by the input model, and analyzing the input model by the processor Generating the analysis result, analyzing the analysis result of the input model by the processor, and automatically expanding the input model for the physical component based on the analysis result by the processor. Writing to a model, the extended model comprising: (i) the nominal mode of operation of the modeled physical component; and (ii) at least one alternative operation for the modeled physical component An alternative operation mode different from the nominal operation mode. It is intended to describe the person. The analysis step is preferably performed according to at least one of the first approach and the second approach. The first approach is that the input model is sensitive to one or more of the types of faults including (i) critical, (ii) power flow, and (iii) parameter type faults. The second approach operates to match specific aspects of the component's dynamic behavior and to appropriately modify the relevant aspects to reflect the dynamic behavior of the failure mechanism. [Selection] Figure 1

Description

Cross-reference of related applications

  This application claims benefit based on US Provisional Patent Application No. 62 / 273,719 filed with 2015/12/31 and US Provisional Patent Application No. 62 / 273,767 filed with 2015/12/31. Both of which are incorporated herein by this reference.

  The present subject matter relates to the technology of cyber physics component and / or system modeling. In particular, but not limited to, it is relevant to object-oriented and / or other similar modeling computer languages such as Modelica. For this reason, the present specification makes particular reference to this occasionally. However, it should be understood that aspects of the present subject matter are equally suitable for other similar applications and / or environments.

  Modeling languages, such as Modelica, are generally used to generate and / or simulate physical components and / or virtual models of systems intended for design, analysis, and / or testing. For example, the modeled physical system and / or components are fairly complex or rather simple and may include, for example, electrical circuits or automobiles or other physical systems. For example, the Open Source Modelica Standard Library (MSL) contains models of about 1280 components contained in several domains, such as electrical, mechanical, and fluid. Cyber-physical components are built or depend on the synergistic effects of system controllers that implement control software on a hardware platform as found in computational and physical components such as automobiles, assembly lines and other engineered systems. For example, the Modelica_LinearSystems2 library contains models for continuous and discrete controllers. The MSL itself includes models of various variants of proportional, integral and differential (PID) controllers. These Modelica models and the like are increasingly being used in various projects. The term “physical component” in this disclosure is used to mean one or both of the “physical” and “cyber physics” components.

  In practice, however, the MSL model etc. generally describes and / or represents one of the operational modes for the component being modeled, ie the nominal (nominal) or correct behavior (behavior) of the component being modeled. Only. That is, such models generally do not describe failure or other non-nominal (non-nominal) behavior. For example, the failure mode may be a short circuit or open circuit, or a motor that does not work or a brake that is slipping. Any number of difference mechanisms, such as wear, material fatigue, corrosion, etc., can lead to malfunction of the modeled component. It is often desirable to test and / or analyze a component that has failed or is operating in a non-nominal mode, for example, for diagnostic purposes. However, conventional MSL models and the like generally do not describe such faulted or non-nominal modes, so that diagnosis of modeled components operating in such faulty or non-nominal modes and / or Or other tests can cause problems.

  In addition, the damage process model represents damage due to active failure mechanisms in system components, with each service environment as a function of parameters such as load, material properties, and dimensions. Running a reliable simulation under specific system configurations and usage conditions can be excessively time and / or labor intensive.

  One of the efforts related to this specification, which is hereby expressly incorporated by reference in its entirety, is the US patent application Ser. No. 13 / 967,503 of Saha et al., Filed Aug. 15, 2013. It is.

  In general, new and / or improved methods and / or systems or devices are disclosed herein that automatically and / or semi-automatically generate component models that include non-nominal behavior modes. Is for. It also enables investigation of the effects of component failures at the system level, which can be used to improve system design in terms of possible robustness, resiliency, and reliability. can do.

  A brief description is provided below to introduce concepts related to the subject matter of the present invention. The summary is not intended to identify basic features of the claimed subject matter, nor is it intended to be used to determine or limit the scope of the claimed subject matter. The embodiments described below are not intended to be exhaustive, nor are they intended to limit the invention to the precise form disclosed in the following detailed description. Rather, the embodiments have been chosen and described so that others skilled in the art can appreciate and understand the principles and practices of the present inventive subject matter.

According to one embodiment, a method for automatically generating an extended model of a physical component is provided. The method includes reading an input model into a processor, the input model describing a nominal operating mode for a physical component modeled by the input model;
Analyzing the input model by the processor and generating an analysis result;
Analyzing the analysis result of the input model with the processor;
The processor automatically writes from the input model to the extended model for the physical component based on the analysis result, the extended model comprising: (i) the modeled physical component It describes both the nominal mode of operation and (ii) at least one alternative mode of operation for the modeled physical component that is different from the nominal mode of operation. The analysis step is preferably performed according to at least one of the first approach and the second approach. The first approach is that the input model is sensitive to one or more of the types of faults including (i) critical, (ii) power flow, and (iii) parameter type faults. Works to detect
The second approach operates to correspond to a specific viewpoint of the dynamic behavior of the component, and appropriately corrects the corresponding viewpoint to reflect it in the dynamic behavior of the failure mechanism.

According to another embodiment, a system for automatically generating an extended model of a physical component is provided. The system is a processor operable to:
Read the input model, the input model describes the nominal operating mode for the physical component modeled by the input model,
Analyzing the input model and generating the analysis results,
Analyzing the analysis result of the input model;
Based on the analysis results, the input model automatically writes to the extended model for the physical component, the extended model comprising: (i) the nominal operating mode of the modeled physical component; and (ii) ) Describes both at least one alternative mode of operation for the modeled physical component that is different from the nominal mode of operation;
Having a processor. The analysis of the analysis result is preferably performed according to at least one of the first approach and the second approach. The first approach is that the input model is sensitive to one or more of the types of faults including (i) critical, (ii) power flow, and (iii) parameter type faults. It works to detect.

  The second approach operates to match specific aspects of the dynamic behavior of the component and to appropriately modify the relevant aspects to reflect the dynamic behavior of the failure mechanism.

  Numerous features and advantages of the present inventive subject matter in this disclosure will become apparent to those skilled in the art upon a reading and understanding of this specification. However, the detailed descriptions of various embodiments and specific examples, while indicating preferred and / or other embodiments, are given by way of example and are not meant to be limiting. Absent. Many changes and modifications within the scope of the present invention may be made without departing from the spirit thereof, and the invention is intended to embrace all such modifications.

In the following detailed description, reference is made to the accompanying drawings. However, the inventive subject matter disclosed herein may have various components and arrangements of components, as well as various processes and arrangements of steps. The drawings are only for purposes of illustrating exemplary and / or preferred embodiments and are not to be construed in a limiting sense. Further, it should be understood that the drawings are not drawn to scale.
FIG. 1 is a schematic diagram illustrating an exemplary model transformation system suitable for practicing aspects of the present subject matter. FIG. 2 is a flowchart illustrating an exemplary method for performing a model transformation process in accordance with an aspect of the present inventive subject matter. FIG. 3 illustrates an exemplary workflow in accordance with an aspect of the present subject matter, which uses MBD analysis to determine component fatigue life conditioned to mission usage and design configuration. FIG. 4 is a graphical representation of a simulation test course, with the course height along the vertical axis (inch) and the course distance along the horizontal axis (inch). FIG. 5A shows the acceleration time history of the sample for groove crossing. FIG. 5B shows a sample acceleration time history for a 1 meter wall descent. FIG. 6 shows a sample von Mises stress contour for an exemplary 4 × 4 × 4 bracket. FIG. 7 shows the maximum acceleration in the X direction as a function of velocity and bracket stiffness in the bracket. FIG. 8 shows the maximum acceleration in the Y direction as a function of velocity and bracket stiffness in the bracket. FIG. 9 shows the maximum acceleration in the Z direction as a function of speed and bracket stiffness for the bracket. FIG. 10 shows the percentage error for maximum lateral acceleration as a function of vehicle speed and power pack mass scaling factor. FIG. 11 shows the percentage error for maximum longitudinal acceleration as a function of vehicle speed and power pack mass scaling factor. FIG. 12 shows the percentage error for maximum vertical acceleration as a function of vehicle speed and power pack mass scaling factor.

  For the sake of clarity and simplicity, the description herein includes structural and / or functional elements generally known in the art, relevant criteria, algorithms, and / or protocols, and other components, algorithms, methods. , And / or steps without reference to each configuration or operation in detail, based on and / or correspondingly to the preferred and / or other embodiments shown herein. This does not apply to changes or modifications. Further, the devices and methods disclosed herein will be described in detail by way of example and with reference to the figures. Unless otherwise noted, the use of similar numbers in the figures indicates that reference is made to the same, similar or corresponding elements throughout the figures. It will be appreciated that the examples, arrangements, configurations, components, elements, equipment, methods, materials, etc. disclosed and described may be varied and may be desirable for a particular application. In this disclosure, any information identifying specific materials, techniques, arrangements, etc. relates to specific examples of such materials, techniques, arrangements, etc., or is merely a general description. Information identifying specific details or examples is not intended to be essential or limiting unless otherwise specified, and should not be construed as such. Some examples of apparatus and methods are disclosed and detailed below with reference to the figures.

  In general, disclosed herein is a method, system, and / or apparatus operable to extend a model of a physical system component with faults and / or other non-nominal modes based on at least one embodiment. To do. Where appropriate, the model including the fault and / or other non-nominal modes is automatically or semi-automatically generated from a component model that usually describes only the nominal or correct behavior of the component. In this specification, FAME is an acronym for Fault-Augmented Model Extension (Failure augmentation model extension function). However, the extended (augmented) model can be expanded as described herein to include other alternative modes that are not strictly related to “failure”, but rather to other non-nominal Or it should be understood that this relates to alternative modes of operation.

  According to one suitable embodiment, existing open source libraries (eg, Modelica Standard Library (MSL), libraries developed by third parties, and other libraries) can fail to a particular model instance. When not introduced, the existing nominal behavior specifications can be used, but the failure model has been expanded to be introduced in a compact manner. More specifically, a basic set of non-nominal behavior models has been created that scales up to a library of nominal component models, such as MSL, libraries developed by third parties, and / or other similar libraries. In that methodology, fault models can be inserted into new components generated by various third-party and / or other Modelica library developers.

  In the FAME model conversion process, a failure is inserted into the nominal component model library by utilizing the JModelica Modelica parser framework and the JastAdd technology that are the basis of the FAME model. A Java (registered trademark) program that implements JastAdd and JModelica runs on the supplied library, recognizes the component model affected by the failure, rewrites it as necessary, and provides the behavior of the failure and is modified Output the new library to a new location.

The following is a simple model class for capacitors included in Modelica, affected by both ElectricalOpen and ElectricalShort failures.

  The above is an example of an unexpanded or simple capacitor model.

  To analyze the above, the appropriate embodiments are operated to detect or determine which faults are affected and rewrite them to simulate those faults with instances of this class. In general, one embodiment operates to look for three classes of faults: (i) critical, (ii) power flow, and (iii) parameter faults. A serious failure usually changes the dynamic behavior of the component to something completely different. For example, a common critical failure in the electrical domain is an open circuit. A power flow failure affects one or more of the power flows to and from the component. For example, a common power flow failure in the electrical domain is some degree of short circuit. A parameter failure usually reflects a shift in parameters that should be fixed. For example, the capacitance in the case of a capacitor.

  Once a fault affecting the component is identified, a behavior description is added to the component for each identified fault. The fault severity can then be specified by running the model for any of these failure modes, and for conditions without a critical failure.

  When it comes to fault insertion, one appropriate approach relies on an understanding of the power flow pattern in a system built with that component, and makes the model specified very abstractly inconsistent. It has the advantage of being used in modeling. This approach is described as the “external” approach below. If appropriate, this external approach can be extended with a manually created declarative specification list of desirable parameter faults, and this declarative specification list is automatically inserted. This enables more specific and accurate fault modeling.

  Another suitable approach relies on matching certain aspects of the component's dynamic behavior and appropriately modifying those aspects to reflect the dynamic behavior of the failure mechanism. In contrast to the external approach, this method is called the “internal” approach. This can provide more detailed fault behavior modeling, but is more difficult to specify accurately.

  JModelica is an open source Modelica tool chain. JModelica consists of a Java / JastAdd parser for the Modelica language and various simulation and analysis tools, both written in Java® and Python.

  JustAdd is Java (registered trademark) base code of an attribute grammar by Knuth, and an abstract syntax tree (AST) node can have an attribute whose value is defined by an expression. Each attribute is either synthesized (defined by an expression embedded in the node itself) or inherited (defined by an ancestor node expression). JastAdd supports a reference attribute, which is an attribute having another node in the AST as its value. Thereby, an arbitrary graph can be interwoven through AST. It is also possible to parameterize the attribute, which means having an unbound variable that binds to the parameter when the expression is evaluated. This also allows for collection attributes, ie attributes with multiple values contributed by other various AST nodes. And circular reference attributes that provide a way to break the reference cycle are also supported.

Since JastAdd is Java (registered trademark) based, expressions are implemented as Java (registered trademark) methods, and attribute access is performed through invocations of those methods. Various constructs, especially J
Ava (registered trademark) itself is extended. The JastAdd aspect supports intertype declarations for AST classes. An intertype declaration is a declaration that appears to be in an aspect file but actually belongs to an AST class (like an attribute expression). The JastAdd system reads the aspect file and interleaves the intertype declaration into the appropriate AST class. The JastAdd system supports both declarative aspects (.jrag files) and imperative aspects. The declarative aspect adds new attributes, expressions, and rewrites, and the imperative aspect adds only Java methods and variables. AST rewriting can also be specified and is optional only if the type A AST node is replaced with a type B node and some condition C is true. A new AST subtree can be created and specified as an attribute value (“non-terminal attribute”).

In a preferred embodiment, the so-called external approach, after analyzing each library file using the JModelica parser, each model class found in the following connector class parse tree (non-partial Modela class definition in constraint model), for example Check out.

  These are instances of the Modelica connector class containing two variables, one of which is an effort type, such as voltage or pressure, and the other is a flow type, such as current or mass flow. The analysis introduces both the direct components of the model class as well as the components of each inherited class used by the model class as appropriate. When any of the above components is found, an analysis tree related to the replacement class of the model class is created, and the analysis tree of the model class is replaced with the new analysis tree.

  Finally, JModelica's “FormattedPrettyPrint” aspect is used to re-create Modelica source code that is currently fault-responsive for models from AST.

In another embodiment (ie, an internal approach), each generic failure or alternative mode, eg, “electrical short”, is modeled with an aspect that provides a more versatile class, eg, a “Fault” subclass. Each of the Fault or alternative mode subclasses provide, for example, the following predicates:

Thus, given FullClassDecl (a node that represents the definition of the Modela class in JModelica AST), it describes whether the FullClassDecl is affected by this fault (or otherwise the alternative mode is Applied).

  As appropriate, the implementation of the “may_occur_with” predicate relies on the matching of some pattern defined for the failure or alternative mode to the analysis of the model given by the AST FullClassDecl node.

Also, each of the Fault or alternate mode subclasses contributes their instance to the FullPositiveDecl's “possibleFaults” collection attribute, as appropriate, for example using the JustAdd “contributes” mechanism if the FullClassDecl is affected. For example, with respect to the Fault subclass Electrical Short, there is a possibility as follows.

  In practice, more faults or alternative modes can be added by adding aspects to the collection of fault aspects and recompiling the program.

Where appropriate, the JModelica FullClassDecl node type is extended to include some additional attributes to insert faults and / or alternative modes, for example:

Then, using the JaddAdd “rewrite” capability, for example, the model, the AST representing the FullClassDecl node can be rewritten, and failure behavior can be added to the model. For example, the rewrite rule may be as follows.

  Where appropriate, this rewriting is automatically applied as part of the analysis process when appropriate, resulting in fault or alternative behavior clauses being inserted into the analysis of the model. In practice, the formula rewriting method, rewriteEquationsToAddFaults () takes a nominal formula for the model, encloses the formula in a branch of Modelica's if formula, and each if formula for a possible failure or alternative mode Add an expression for the additional branch and its failure or alternative mode. In a suitable embodiment, these faults or alternative formulas are obtained by invoking methods relating to the faults and / or alternative subclass instances. In Modelica, the if expression is a general method for implementing a conditional expression.

  Finally, JModelica's “FormattedPrettyPrint” aspect and / or capability can be used, for example, to recreate Modelica source code that is currently fault-enabled for a model from AST.

For example, with either approach, in one suitable embodiment, the entire program that inserts faults and / or alternative modes into the model can be as follows (in pseudocode):

Once the failure and / or alternative modes are added, each model effect can be evaluated using normal Modelica simulations. In practice, the extended model can be used for a wide variety of diagnostic applications. Where appropriate, all extended models are written in standard Modelica. This allows all initial values, parameters, and failure or alternative modes to be set in the Modelica wrapper. For example, some of the uses of the new model for both design and diagnostic purposes include, but are not limited to:
Determine whether system requirements are met for a given set of initial conditions, parameter values, and faults.
* For a given set of initial conditions, failures, and component ages, determine the conditional probability that the system meets the requirements.
Determine the age of the remaining components for a given set of initial conditions, failures, observations, and age of all components except one.
* Standard model based diagnosis.
* Failure mode and effect analysis.
* Failure mode and effect risk analysis.
* Determine which component damage will have the most impact on whether the system meets the requirements.
* Determine MTTF.

  Where appropriate, the definition of each model class that includes a fault is replaced with a new class definition, namely a Modelica model class that includes the original model class and adds a declarative behavior to allow fault simulation.

If a class model is found to be affected by one or more failures, the class is rewritten. The encapsulated and listed types are defined, listing the various failure modes of that class along with the “nominal” mode. This new type of discrete mode parameter is defined to define the mode in which an instance of the class is operating. An if expression is added so that each mode of operation can define its own dynamic behavior. For example, this can be:

  The set of expressions applied in each failure mode is represented by the appropriate branch of the if expression. Since the operation mode type is a Modelica parameter, the selected branch does not change during simulation and the compiler can optimize the expression.

  Optionally, each new class connects an instance of that class of power interface component via an additional variable power dissipation component that does not dissipate power in nominal mode. For example, if the original model class is an electrical component and its power interface instance is an instance of class Pin, a suitable power dissipation component is FAME. Dynamic Dampers. It becomes an instance of Electrical.

  The new class may also include a variable power conductivity component that connects each pair of compatible connector components that are set to nominally conduct no power if they include multiple power interfaces of the same type. Connector components are “compatible” if they are of the same type or inherit the same type. For example, if the original model class is an electrical component that includes an instance “p” of the connector type PositivePin and an instance “n” of the connector type NegativePin, both subtypes are Pin and the two instances are connected The amount of bridging is set to Modelica. Constants. FAME.set to a very small value of eps. Bridges. There will be an instance of Electrical.

  The process also flattens the model superclass into a rewritten class as appropriate, and introduces two new components FAME_operating_mode and FAME_fault_mount that can be recognized from the outside, and a list of types that give this component a possible failure.

  Faults that appear as power flow anomalies are modeled by simple changes in these two variables. For example, as can be seen from the above, the electrical short-circuit is performed by changing FAME_operating_mode to FAME_OperatingModes. Modeling can be done by setting Electrical_Short and FAME_fault_mount to 1.

For example, an unexpanded or simple capacitor referenced above can be as follows (ie, an expanded capacitor model) when performing the external approach.

  In one optional embodiment, the system reads, for example, a parameter fault table, each row of which describes a specific fault whose parameters that should be fixed change during component operation. This provides a Modelica representation that describes the change of the parameter as a function of the failure mode, Modelica class, specific parameter components of the class, Modelica type of the parameter, and variable FAME_fault_mount for each fault. Optionally, parameter failures are handled by introducing a new continuous variable with the prefix “FAME_”. An expression for setting this variable is added to the value calculated by the function specified by the failure table. Where appropriate, the reference to the original parameter is replaced with an expression with a reference to this new variable.

  The so-called internal approach works by detecting patterns in the dynamic behavior of the model class, which indicates susceptibility to specific faults. If such sensitivity is detected, the equation describing the dynamic behavior of the model can be rewritten to model the fault.

In a suitable embodiment, a susceptibility or applicability pattern is specified for each fault and / or alternative mode, indicating that the class may exhibit the fault when matched by a model class. In practice, these patterns are defined as appropriate in appropriate languages that describe the types of components that the class may have and how they relate to each other. For example, clutch or brake slip due to surface wear results in torque loss through the clutch or brake, but the system represents torque 2 to describe a failure common to clutch or brake slip. Look for a model class with one variable, one of which is the product of the other variable that represents the friction component. For example, this can be:

  In the equation, “tau1” represents a first torque variable, “tau2” represents a second torque variable, “friction” represents a component of a friction variable, and “eq1” is an equation relating the above variables to each other. Represents.

  In response, the system considers any model class that meets these four constraints as appropriate to be affected by this sliding failure mode. That is, when the above constraints are detected in a model class, the model class is considered to be affected by the designated failure mode and is appropriately rewritten.

  Note that the names assigned to the variables in the pattern are appropriately unrelated to the names assigned to the variables in the Modelica source code. The pattern name constraint is maintained in case matching is used in the modification of the model dynamic behavior.

  Optionally, before matching, the Modelica model class is flattened, i.e., all superclasses are extended, and all record and connector subcomponents are extended.

  In general, the pattern language may be fairly simple. For example, there are two operators, a component and an expression, which match the component and the expression, respectively.

For example, the component operator takes the following form:
・ Component cname qualifier-list
Where cname is an identifier assigned to the matching component (not the name defined in the component declaration), and the modifier list is a comma-separated list of modifiers that, when matched, result in the constraints Is satisfied. For example, two qualifiers that may be specified are a type that is the fully qualified name of the Modelica class, or a prefix that is a type prefix for component declarations.

The expression operator can take the following form, for example.
・ Equation name cname rhs-expression
Where name is an identifier assigned to the matching component, cname is constrained in one of the component operators, and the rhs expression defines a partial constraint on the right side of the matching expression.

In practice, an instance of the rhs expression may be only cname or may be constructed with the following primitive variables:
• product cname-or-exp [cname-or-exp. . . ] —Products of named components or sub-expressions (other elements, including other components, may be involved in the product, but they may be ignored)
Sum cname-or-exp [cname-or-exp. . . ] —Sum of named components or subexpressions (other elements, including other components, may be involved in the sum, but they may be ignored)
Quotient number-cname-or-exp denominator-cname-or-exp-expression formed by dividing numerator by denominator, and / or-difference minend-cname-or-exp subhendend-cname-or-exp An expression formed by subtracting the subtractor ・ literal modela-literal—literally Modelica expression ・ function name-or-exp [cname-or-exp. . . ] —Any optional function of the specified cname-or-exp element.

In addition to the patterns used to identify affected or applicable classes, each fault and / or alternative mode includes a description of “edit program” as appropriate, which is the ability to modify the class to simulate the fault Used to add For example, these editing programs may be written with the following primitive variables:
Add-component cname type—adds a new component of the specified Modelica type, internally called cname (the actual Modelica name is generated by the editor program). The scope of this variable is “protected”.
Replace-component cname1 cname2 [cname] —Replaces the instance of the variable referenced by metaname cname1 with the variable referenced by metaname cname2 in all expressions. If an optional cname is specified, it simply modifies the expression referenced by its metaname.
Add-equation name cname exp—adds a new expression internally called ename, which binds cname to the specified exp. The operator for exp uses the same primitive variables as defined for the pattern language above.
Remove-equation name—Removes the expression referenced by the meta variable ename.
Type cname—Returns the Modelica type of the variable referenced by the metaname cname.

For example, the clutch or brake wear fault editing program described above may take the following form:

As another example, a complete failure pattern can be as follows: Failure ElectricalOpen (open circuit).

According to one embodiment, if a class model is found to be affected by one or more failures, the class is rewritten. The encapsulated and listed types are defined, listing the various failure modes of that class along with the “nominal” mode. This new type of discrete mode parameter is defined to define the mode in which an instance of the class is operating. The set of expressions for the class is replaced with a single if expression, eg of the form

For example, the capacitor referenced above can be rewritten to simulate a short circuit and an open circuit fault as follows.

  It should be noted that Modelica. Constants. eps is used, which represents a very small value in Modelica, Modelica. Constants. Same as inf. This is used to avoid numerical instability associated with the use of zero in the simulation phase.

  Referring now to FIG. 1, there is shown generally a computer 10 or other similar processor that performs or implements a model conversion process, for example, automatically or semi-automatically. The input there is the first library 20 of the nominal component model 22. For example, the library 20 can include a collection of models 22, where each model 22 describes and / or represents a physical component, including, for example, the behavior and / or behavior of the component. Optionally, the library 20 can include one or more such models 22, eg, those that represent components that are used and / or interact with each other in the system, or the library 20 Any such suitable collection of models 22 can be included. In practice, each model 22 in the input library 20 is a multi-line code stored in a file or suitable memory or other data storage device accessible by the computer or processor 10 (e.g., Modelica language or its). Written in another suitable language, etc.) and / or represented by this. Optionally, at least one of the models 22 in the library 20 (or more or all of the models 22) describes or only the nominal behavior and / or behavior of the physical component modeled thereby. For example, such nominal behavior and / or behavior corresponds to the correct behavior and / or behavior of the modeled component. In one simple example, only one model 22 can be included in the library 20, and in a more complex example, more models 22 can be included.

  As another input, the second library 30 can include a collection of key alternative modes and / or mechanisms 32 that can be applied to the modeled components of the library 20. For example, each alternative mode and / or mechanism 32 of the library 30 may describe and / or represent a failure mode and / or mechanism or some other non-nominal or alternative operating mode and / or behavior. In practice, each alternative mode 32 can be applied to one or more modeled components in the library 20 while others may not be applicable. For example, the short-circuit failure mode can be applied to several different electronic components (eg, capacitors and / or inductors), but not mechanical components (eg, brakes). Optionally, each alternative model 32 in the input library 30 is a file accessible by the computer or processor 10 or multiple lines of code stored in an appropriate memory or other data storage device (eg, Modelica language or such). Written in another suitable language) and / or represented by this. For example, a failure mechanism can be used to represent the cause underlying the failure, while a failure mode can be used to represent the abnormal behavior or behavior of the modeled component. For purposes of illustration, consider an exemplary failure mechanism for a rusted shaft and unconnected leads in connection with the motor being modeled. Correspondingly, the failure modes caused by the above mechanism can each be a shaft that is more difficult to rotate (ie, compared to when the motor is operating normally) and a motor that simply does not operate.

  In a suitable embodiment, for example, failure modes and mechanisms are captured and / or identified for each component being modeled. These are configured with appropriate classification, optionally with failure probabilities, so that the corresponding behavior model can be constructed in a consistent manner. Accordingly, the failure mechanism behavior schema is developed in consideration of the classification. For example, this schema can generically define failure behavior at the highest level of abstraction, and use inheritance concepts to specify lower level failure mechanism behavior. This approach provides the flexibility of defining the behavior of subclasses of failure mechanisms. Consider the case of a failure mechanism identified as “wear”. This can represent various subclasses of wear, for example high-level categories of wear, impact wear, or corrosive wear. If appropriate, then the subclass (of wear in this example) inherits a higher level of behavior and extends it. For example, the wear behavior that represents material loss is extended to include, for example, the friction behavior in a subclass of wearable. As a result of this process, failure modes of various components can invoke the same failure mechanism, ie the underlying failure behavior model. Furthermore, these subclasses can be directed to the representation of failure mechanisms in different domains, such as mechanical, hydraulic or hydraulic, electronic, etc.

  Of course, in a broader sense, the alternative mode may not represent any faulty behavior and / or behavior, but rather simply represent some other non-nominal behavior and / or behavior of the modeled component.

  In either case, the processor 10 generates and / or outputs a library 40 of extended component models 42. In practice, each model 42 in the output library 40 is output to a file accessible by the computer or processor 10 or stored in a suitable memory or other data storage device (eg, multiple lines of code). Written in the Modelica language or another such appropriate language) and / or represented by this. Optionally, based on a model transformation process performed by the computer and / or processor 10, an extended component model 42 is output for each input nominal component model 22 from the library 20, and these extended component models 42 are modeled. A description and / or representation of the nominal behavior and / or behavior of the component, as well as one or more or all descriptions and / or representations of alternative modes and / or behaviors applicable to the modeled component Including. Where appropriate, the output extended component model 42 of the library 40 is fully compatible with the corresponding input nominal component model 22 for each interface, input, output, and parameter, for example. Thus, for example, the extended component model 42 is simply plugged into and / or plugged into the nominal component model 22 for testing and / or analysis of various component failures and / or other alternative operating modes and / or behaviors. Can be replaced.

  In one exemplary embodiment, the computer and / or processor 10 implements a computer program or the like to perform the model transformation process (eg, suitable memory or other accessible to the computer / processor 10). May be stored in the data storage device. FIG. 2 is a flowchart illustrating the steps of one suitable embodiment for the model conversion process 100. Optionally, the program executed by the computer / processor 10 may be written in a computer programming language that incorporates the JModelica platform or the like and a Java / JastADD parser or the like, such as Java. . The program runs on the input library 20 and is susceptible to various defects by identifying specific patterns associated with each alternative mode 32 in the variables, equations, and / or other content of the model 22. It is desirable to recognize the nominal component model 22 and / or the alternative mode 32 of the library 30. That is, if a variable, equation, and / or other content of a given model 22 matches a particular pattern associated with a given alternative mode 32 (eg, within tolerance), that alternative mode 32 is It is considered that the present invention can be applied to the model 22. As a result, model 22 is basically rewritten to include a description of its applicable alternative mode 32 and a new augmented model 42 is output.

  Further, with particular reference to FIG. 2, the model conversion process 100 begins appropriately at step 102 and reads one of the models 22 from the library 20.

  The model 22 is parsed at step 104 and the parsed model is examined and / or analyzed at step 106 to search for specific content, patterns, and / or cues associated with the alternative mode 32. In practice, a given model 22 typically has one or more lines of code (eg, equations, parameters, variables, and / or other) that define the modeled component, along with nominal operations and / or actions. Content). From this content, clues and / or patterns that match (within certain tolerances) specific content, cues, and / or patterns associated with bad and / or other non-named or alternative modes are detected and / or Or can be identified. Specifically, the content may include elements, cues, or patterns that indicate that a given model 22 describes an electrical component (eg, a capacitor). In fact, the model 22 may include equations, parameters, or other content that allow it to be determined that the model 22 is actually a capacitor. Continuing with the description of this example, such types of components (generally electrical components, specifically capacitors) are susceptible to certain failures (eg, short circuit, open circuit, etc.), and It is known that certain alternative modes are applicable. That is, the content of the model 22 matches the pattern associated with each defect and / or alternative mode 32 well.

  If, at decision step 108, a pattern and / or clue that sufficiently matches the pattern and / or clue being sought is not obtained, process 100 branches to step 110, and once the pattern is obtained, process 100 proceeds to step 112. And continue.

  In step 110, the model 22 remains essentially unchanged. That is, the model 22 may basically be left as it is. In this case, the corresponding model 42 in the output library 40 is basically the same as the input model 22.

  Conversely, at step 112, the model 22 is rewritten to a new model 42 to describe not only the nominal operating mode originally included in the model 22, but also alternative modes associated with the matched pattern, and / or Or edited.

  In practice, it should be understood that each model 22 of the input library 20 is preferably processed, for example, sequentially or in parallel. In addition, it should be understood that in practice, each model 22 may be affected by zero or more defects and / or alternative modes 32 described in the library 30. That is, the content of the model 22 may not match the patterns associated with various defects and / or other alternative modes 32, or may match one or more different patterns.

  In rewriting (or editing) the model 22 to include alternative modes (ie, to achieve a corresponding augmented model 42), each applicable alternative mode description and / or code is injected into the model. Or it is desirable to be inserted. For example, such a description or code may be obtained from applicable alternative mode 32 and may include one or more equations and / or functions that display and / or model the alternative mode in question. In fact, any model class definition that includes a bad or alternative mode will all include a new class definition, eg, a Modelica model class that includes the first model and adds behavior that allows simulation of the bad and / or alternative modes. Is replaced by In addition, the augmented model 42 is provided with a control mechanism and / or appropriate code that allows the selection of a particular mode for the model 42 to operate in a given simulation. That is, the control mechanism and / or code is selectively executed by the extended model 42 in any one of the modes (a nominal mode from the first model 22 or one of the alternative modes added by rewriting / editing). Make it possible. With such a method, alternative dynamic characteristics are possible in each operating mode.

  For example, the capacitor input model 22 may look like the non-extended model (written in Modelica language) described above or a simple capacitor model. Thus, the output extension model 42 (also written in Modelica language) generated from such an input model 22 may look like the augmented capacitor model described above.

  More specifically, it can be seen that in the above example, four defects and / or alternative modes have been found applicable to the initial model. In particular, in the extended model 42, a summary “enumeration” type is defined, where Lift, Electrical_Short, Electrical_Leak, and Electrical_Break are listed with a nominal mode. This new type of discrete mode parameter is defined and defines the mode in which instances of the class operate. Accordingly, conditional expressions are then utilized and / or written to allow dynamic selection of specific operating modes. A set of equations applied in each alternative mode is preferably represented in the appropriate branch of this conditional expression. For example, as a mode of operation type in the Modelica parameter, the selected branch does not generally change during the simulation and the compiler can optimize this equation.

  In one embodiment (as referenced above), power flow analysis may rely on the identification of standard power interfaces shown in the input model 22. Such an interface is preferably an instance of a Modelica connector class and / or the like (such as a pin class in a Modelica package of similar electrical interface type). In practice, such power interfaces typically include two variables, one of which is an “acting force” type such as “voltage”, “pressure” and the other is “current”, “mass”. “Flow” type such as “flow rate”. In one suitable embodiment, the analysis examines both directly defined model class components as well as each inherited class component used by the model class. All model class definitions that contain such instances are “shell” class definitions (eg, the first model class and instances of that model class and each connector component, parameter component, and secure configuration found in that first class). Wrapped in a new Modelica model class containing elements).

  In addition, the system (e.g., computer or processor 10) may provide a table of parameter failures and / or substitution modes (each row of which is a particular failure or substitution mode in which parameters that should be fixed change during component operation). Can be read at will. For each bad or alternate mode in it, the table or its row contains a variable function that defines the bad / alternate mode, the Modelica class, the specific parameter component of the class, the model type of the parameter, and the change of the parameter. Provide a Modelica expression described as (e.g., FAME_fault_mount). The above table or the like is preferably present in a file stored / stored in memory or other suitable data storage accessible by the computer or processor 10.

  In one suitable embodiment, each new shell class has its power interface and / or connector configuration through an added variable power dissipation component (eg, set to not dissipate power in nominal mode). Connect the instance of the element to the first power interface and / or connector component in the instance of the first model class. For example, if the first model class is an electrical component and the power interface instance is an instance of a class, the appropriate power dissipation component is FAME. Dynamic Dampers. It may be an instance of Electrical (attenuation parameter is set to zero).

  In addition, if the shell class includes multiple power interfaces and / or connector components of the same type, it is each pair of compatible connector components (which is nominally set not to carry power) May include a variable power conductance component for connecting. In general, connector components are considered “compatible” if they are of the same type or inherited from the same type. For example, if the first model class is an electrical component including an instance “p” of the connector type PositivePin and an instance “n” of the connector type NegativePin, the FAME. Bridges. An instance of Electrical is generated, and the conductance or bridge amount is determined by Modelica. Constants. It will be set to a very small value of eps.

  As described above, the extended model 42 includes an example of a conductor model to which the above-described damper and bridge are added. The model transformation process flattens the model superclass into a rewrite class (removes the entire hierarchy), two new externally visible components, FAME_operating_mode and FAME_fault_mount, and potential faults and / or An enumeration type of FAME_OperatingModes that gives alternative modes of operation is also introduced. Defects and / or other alternative modes that appear as power flow anomalies are preferably modeled by changes to these two variables. For example, as shown in the output extension model 42 described above, the electrical short circuit may be set to FAME_operating_mode.FAME_OperatingModes. Modeling may be done by setting equal to Electrical_Short and setting FAME_fault_mount equal to 1.

As noted above, parameter failures and / or other similar alternative modes are handled by introducing new continuous variables, for example with the prefix “FAME_”. An equation is preferably added to set this variable to a calculated value according to the function specified by the parameter failure and / or alternative mode table described above. Thus, the reference to the first parameter is replaced with an expression that refers to this new variable. For example, as shown in the example above, the parameter C (of the input model 22) is replaced by the expression C ^* (1-FAME_fault_mount) (of the output extension model 42).

  In general, according to at least one further embodiment, the present specification includes a method, system, and / or method operable to generate a damage parameter map and use it as a surrogate for a damage process model. An apparatus is disclosed.

  In general, as disclosed herein, a damage process model is a function of parameters such as load, material properties, and dimensions, for example, due to failure mechanisms active in system components due to the service environment. Express as The damage state of the component reflects service usage and history derived from the context model. Uncertainties regarding parameters derived from the context and component models as well as damage process model parameters are characterized and embodied in the estimated statistical simulations. In one suitable embodiment, the parameterized simulation results are displayed as a damage parameter map (e.g., a table) that is then user-specific without rerunning the underlying stochastic statistical damage process simulation. Is used to examine the predicted damage in the component for any user specific use.

System components for failure risk or reliability analysis may be performed on the vehicle engine / drivetrain mounting bracket. Such brackets are susceptible to fatigue failure due to time-varying loads resulting from undulating terrain driving, vibration, or impact. In practice, other failure mechanisms may be analyzed and / or different system components may be analyzed as well. It is desirable to use various optical analysis tools and / or software for the analysis. For example, the assessment of the risk of fatigue failure of the mounting bracket may include:
・ Generation of bracket force history using Multi-Body Dynamics (MBD) software ・ Acquisition of bracket stress using Finite Element Analysis (FEA) software ・ Lifetime using Material Probabilistic Fatigue Analysis (PFA) software and life expectancy using PFA probability bracket According to one suitable embodiment, a back-end workflow 200 (optionally invisible to the user) according to aspects of the present inventive subject matter is shown in FIG. A seed design vehicle (SDV) related workflow 200 based on a predetermined set of design parameters is described herein. However, in practice, the workflow 200 may be used to achieve similar results in other applications. In one suitable embodiment, the backend workflow 200 may be implemented as follows.

  As shown, the MBD simulation model 202 is first developed. In the current example, the developed SDV included a spring representing the bracket that attaches the engine and transmission assembly to the vehicle body. More generally, the design configuration 204 and mission definition 206 may be provided as inputs to the workflow 200.

  In particular, for example, mass properties were collected from computer aided design (CAD) models. As shown, CAD information is obtained from the design configuration 204 by the MBD model 202. Or you may estimate by assuming a uniform density box, for example. The MBD model is preferably manufactured based on, for example, a CAD model of SDV and its components. For the current example, the suspension spring / damping characteristics and the location and stiffness of the mounting bracket are determined, along with the choice of terrain / obstacle profile, the reasonable vehicle speed (s) are also determined. In general, design parameters 208 (as described above) are obtained from design configuration 204. As shown, design parameters 206 are used to generate one or more parameterized maps 300 (eg, parameterized fatigue maps).

  As shown, the MBD simulation model 202 and mission definition 206 are used to achieve a set of results 210, ie, an acceleration / force time history at the point of interest, according to the current example. The results are post-processed (including, for example, a bracket that attaches to a power pack for the current effort). According to the current example, the mission power history is defined by concatenating the power history generated from the MBD simulation. For example, in the current example, for SDV operation, Perryman 3, a 12 inch high semi-circular bulge, a 30 inch drop, and a 96 inch wide groove crossing were performed. Using Dynamic Analysis and Design System (DADS) software, the force history (eg, the force history of the bracket in the current example) was derived, for example, from a DADS simulation of SDV. The processed result 210 is then used to generate a parameter display map 300. In the current example, parameter display map 300 is used to determine component lifetime 302.

  In the current example, a class of angle brackets for two materials, three angular dimensions, various angles, and gusset thicknesses were defined. For each bracket design, a linear steady Finite Element (FE) analysis was performed to derive the maximum stress due to the maximum force in the bracket mission history. The allowable stress factor for each bracket was calculated by dividing the yield stress of the material by the maximum stress for that bracket. The result of the FE analysis was bracket stiffness in three directions. Stiffness was displayed through springs in the DADS vehicle simulation analysis.

Next, the fatigue failure simulation model was modified to generate a damage parameter map for a predetermined value of Allowable Stress Factor (ASF) for a predetermined material of the bracket based on the bracket force mission history derived from the DADS simulation. By curve fitting the bracket FE analysis results led to the ASF equations for thickness t _a and t _g of the bracket. The bracket stiffness equation was derived in the same way.

  Bracket force history for damage simulation was derived from SDV MBD simulation using DADS software. The mission force history was defined by concatenating the bracket force history generated from Perryman 3, a 12-inch high semicircular ridge, a 30-inch descent, and a 96-inch wide groove crossing (SDV DADS simulation). FIG. 4 shows a graphic display of the course, with the course height (inches) along the vertical axis and the course distance (inches) along the horizontal axis.

  From the four bracket histories that support the engine and transmission assembly, the front left (Front Left (FL)) bracket histories (due to having a maximum force peak) were selected for mission definition. In accordance with the Fast Adaptive Next-Generation (FANG) vehicle program, one exemplary mission was defined as a distance of 28,800 miles based on 1200 hours of operation. In the usage history, 28 seconds Perryman 3 was repeated over the entire period (21826 times), and wall climbing, descent and groove crossing events were repeated every 10 miles (2880 times). Figures 5A and 5B show sample acceleration time histories for groove crossing and 1 meter wall descent.

  In one suitable embodiment, the fatigue model generates a damage parameter map with different occurrence probabilities (eg, based on its repeated weighted history, geometry, material properties, and specific uncertainties) for the component. The fatigue model is based on the strain versus life (ε vs. N) behavior of the material due to repeated loading. The fatigue model inputs are the force history, material data, and governing parameters for the component (in this case brackets). A Monte Carlo (MC) loop is performed on the random test to derive damage at the desired probability of occurrence for a set of parameter values. In one MC test, damage is derived in the following steps. First, an input load history is converted to a stress time history using a load-to-stress conversion described by geometry or ASF. Next, the stress range and the number of cycles are identified using, for example, a rainflow calculation method or algorithm. If the stress range of the cycle exceeds the yield stress, the total strain ε includes elastic strain and plastic strain. Neuber's rule is used to convert elastic stresses to total strains using the component stress strain curves. Next, to explain the average strain of the cycle, the total strain range is corrected using the Walker relationship. Derives damage due to total strain using a strain versus life model. Finally, all damage from each cycle is accumulated using minor rules to obtain damage from full power history.

  FIG. 6 shows a 4 × 4 × 4 bracket sample von Mises stress contour. The maximum stress of 39.4 ksi results from a maximum force of 18300 pounds, and the yield stress of stainless steel 17-4PH is 170 ksi. Therefore, ASF = 170 / 39.4 = 4.31.

In one example, stainless steel 17-4PH H900 and aluminum 6061-T6 materials were used for bracket damage simulation. The properties of the material used for the bracket damage simulation were obtained from MIL-HNDBK-5J (Department of Defend Handbook: Metallic Materials and Elements for Aerospace Vehicle Structures (3J) data from Prof. 31). The stress rupture properties listed in Table 1 are the yield strengths for the alloys. A and B “baseline” values were used to derive the mean deviation, standard deviation, and coefficient of variation for yield stress, and to describe the strength uncertainty. Total strain versus life data is used in the bootstrap material model method to obtain the fatigue life uncertainty indicated by the data set.

Table 1: Sample Damage Parameter Map for 17-4PH900 Steel Bracket The damage parameter map explores the results of various reliable design choices and evaluates the probability of serious fatigue failure as a result of mission stress This is possible for system designers or design examiners. For example, according to the bracket examples described herein, the approaches and / or systems described herein can help find answers to the following questions:
If a bracket is used to support an SDV engine and the vehicle has run the terrain profile described above, for example for 1200 hours, what is the probability of fatigue failure of the bracket?
• What differences will occur if the bracket dimensions or material are changed?

  In the Monte Carlo framework incorporating the use range expected in the effective period of uncertainty (material selection and geometry), as well as components of the design, physical model estimates statistical fault is simulated how pre It was mentioned above. The results are preferably stored as a damage parameter map which is then indexed based on model material, geometric parameters, and usage levels. According to one suitable embodiment, the above-described approach and / or system is extended to account for material properties as well as manufacturing process variances (ie tolerance analysis). The extended process is similar to the process described above, but when it comes to simulation settings, the system is not only from design choices (material and geometry) but also material properties and geometry due to manufacturing process variations. The sample will also be explained from the dimensional dispersion.

  In practice, a multidimensional sample space means that the number of simulations grows exponentially with the number of variances of the sample object. However, this can be dealt with by a speed-up method developed for Monte Carlo simulation.

  In one suitable embodiment, the system is further adapted to interpolate an MBD point simulation cloud for the point of interest to determine acceleration at the desired set of points of interest for the unknown set of design or operational parameters. . Specifically, a load (acceleration) at a point of interest in a system (eg, a car suspension component) is numerically determined based on the operating environment (eg, terrain / road) and operating parameters (eg, speed). Therefore, the MBD simulation is executed. Such loads are then to determine the probability of component failure (eg, suspension failure after traveling 100,000 miles on a holey road using an urban driving profile) at any given usage level. Used in damage process model. In practice, such simulations can be computationally and labor intensive to set up and run. Thus, conventionally only a few points of interest in the system and only a few operation profiles have been simulated. However, this limited simulation test may cause unexpected failures in the deployed system. Thus, according to one exemplary embodiment of the systems and / or methods used herein, the load and / or the desired set of points of interest with respect to an unknown set of design (eg, vehicle) or operating parameters. Alternatively, a process of interpolating the MBD point simulation cloud for the point of interest is performed to determine the acceleration. The system and / or method utilizes the linear structural dynamics of the mass / spring / damper based MBD model to interpolate pre-calculated accelerations at system interest points with respect to a uniformly sampled parameter set from the parameter space. Is desirable.

  MBD analysis is useful for rapid exploration of reliability in large design spaces. In particular, MBD analysis helps determine the fatigue life of components conditioned on mission use and design configuration.

  In accordance with one exemplary embodiment, it is desirable to provide the ability to determine component loads at any location within the design configuration (eg, front engine configuration of a car versus mid or rear engine configuration). Users can search the entire design space in a more systematic and comprehensive way by interpolating the MBD point simulation cloud, resulting in a more efficient, reliable and superior design. .

  The following evidence uses interpolation in determining triaxial acceleration for any point design based on a multidimensional cloud of triaxial acceleration derived from MBD simulation for a set of point designs over the entire range of test design points It shows the value in doing. In the cross-validation test presented here, it is assumed that all point designs under consideration belong to the tracked personnel carrier class. The point of interest for calculating acceleration is the bracket element that connects the power pack to the chassis. It is assumed that there are four identical brackets that support the power pack.

In the current example, consider an MBD simulation where a 125 point cloud is quantified by the following three simulation parameters:
Vehicle speed on Perryman 3 terrain: Simulated values are 5, 8, 11, 14, and 17 mph.
• Vertical stiffness of the brackets: Simulated values are 3.49x105, 8.55x105, 1.71x106, 2.14x106, and 2.83x106 lb-in.
Power pack mass scaling factor: The simulated values are 0.5, 0.75, 1, 1.25, and 1.5 (x nominal)
7, 8, and 9 show the maximum acceleration in the X, Y, and Z directions at the bracket as a function of velocity and bracket stiffness, respectively.

  3D spline interpolation was used to estimate the acceleration at a known simulation point (ie, for a given set of simulation parameters), and the error for the simulated value was calculated as a percentage of the simulated value. 10, 11, and 12 show the percentage error for maximum lateral acceleration, maximum longitudinal acceleration, and maximum vertical acceleration as a function of vehicle speed and power pack mass scaling factor. Since the error is relatively small (ie, most errors are less than 5%), it is reasonable to use interpolation to determine 3-axis acceleration from a multi-dimensional cloud of pre-simulated 3-axis acceleration for any point design It is thought that.

  The above methods and / or apparatus have been described with respect to particular embodiments. However, it should be understood that certain modifications and / or changes are contemplated.

  In any case, specific structural and / or functional features may be incorporated into the defined elements and / or components in connection with the particular exemplary embodiment (s) described herein. It should be understood that it is described as However, it is envisioned that such features may be similarly incorporated into other elements and / or components where applicable for the same or similar benefits. Where applicable, different aspects of the exemplary embodiments may be selectively utilized to achieve other alternative embodiments suitable for the desired application (in which case such other alternative embodiments may be used accordingly). It is also to be understood that each feature of the incorporated aspects is realized).

  Any one or more of the specific tasks, steps, processes, methods, functions, elements, and / or components described herein may be performed through hardware, software, firmware, or combinations thereof. It should also be understood that this is desirable. In particular, the processor 10 is a computer or other configured and / or provided to perform one or more of the tasks, steps, processes, methods, and / or functions described herein. It may be embodied by the electronic data processing apparatus. For example, a computer or other electronic data processing device that embodies the processor 10 is provided or provided with a list of suitable code (eg, source code, interpreted execution code, object code, directly executable code, etc.). And / or programmed with a computer or other electronic data processing device, such code, or other similar instructions, software, or firmware (the computer or other electronic One or more of the tasks, steps, processes, methods, and / or functions described herein are completed or performed when performed and / or performed by a data processing device). A list of codes or other similar instructions, software, or firmware may be implemented as non-transitory computer and / or machine-readable storage media and / or recorded, stored, contained, or included in it Preferably, it can be provided to and / or executed by a computer or other electronic data processing device. For example, suitable recording medium (s) include, but are not limited to, a usable floppy disk, flexible disk, hard disk, magnetic tape or other readable and usable computer, mechanical data processing device, or electronic data processing device. Any magnetic storage medium (s), CD-ROM, DVD, optical disk or any other optical medium (s), RAM, ROM, PROM, EPROM, FLASH-EPROM or other memory, chip, or It may include a cartridge, or any other tangible medium (s). Basically, non-transitory computer readable and / or machine readable media as used herein includes all computer readable and / or machine readable media except for temporarily propagated signals. Is included.

  Optionally, the particular tasks, steps, processes, methods, functions, elements, and / or components described herein may be one or more general purpose computers, dedicated computer (s), programmed microprocessors, or Microcontrollers and peripheral integrated circuit elements, ASICs or other integrated circuits, digital signal processors, hard-wired electronic or logic circuits (such as discrete element circuits), programmable logic devices (PLD, PLA, FPGA, graphics card CPU (GPU) ), PAL, etc.) and / or the like. In general, any apparatus capable of executing a finite state machine capable of performing each task, process, process, method, and / or function described herein can be used.

  In addition, it should be understood that some elements described and incorporated herein may be stand-alone elements or may be split under appropriate circumstances. . Similarly, a plurality of specific functions described as being performed by one specific element may be performed by a plurality of individual elements that function to perform the individual functions independently, or Several individual functions may be divided and performed by multiple individual elements that function together. In addition, some of the elements or components described and / or shown herein as separate from one another may be physically or functionally combined where applicable.

  In short, the present specification has been described with reference to the preferred embodiments. Obviously, modifications and variations will become apparent to practitioners who have read and understood this specification. The present invention should be construed to include all such modifications and changes as fall within the scope of the appended claims or their equivalents.

Claims (17)

A method for automatically generating an extended model of a physical component,
Reading an input model into a processor, wherein the input model describes a nominal operating mode for a physical component modeled by the input model;
Analyzing the input model by the processor and generating an analysis result;
Analyzing the analysis result of the input model with the processor;
The processor automatically writes from the input model to the extended model for the physical component based on the analysis result, the extended model comprising: (i) the modeled physical component Describing both the nominal mode of operation and (ii) at least one alternative mode of operation for the modeled physical component that is different from the nominal mode of operation. ,
The analyzing step is performed according to at least one of a first approach and a second approach;
The first approach is that the input model is sensitive to one or more of the types of faults including (i) critical, (ii) power flow, and (iii) parameter type faults. Works to detect
The second approach operates to match specific aspects of the dynamic behavior of the component and to appropriately modify the relevant aspects to reflect the dynamic behavior of the failure mechanism.   The method of claim 1, wherein (i) a critical type of failure represents a change in the dynamic behavior of the component such that the component functions as completely different from the component, and (ii) power flow Type faults affect one or more of the power flows to and from the component, and (iii) parameter type faults are a shift of a parameter that should be fixed for the component. The way that reflects. The method of claim 1, wherein analyzing according to the first approach comprises:
For example, when the analysis result of at least one of a power interface or a connector class is searched and at least one of a power interface or a connector class is found, an alternative mode related thereto is described in the extended model. A method comprising the steps of: The method of claim 1, wherein analyzing according to the second approach comprises:
When a pattern corresponding to a target pattern associated with the substitution mode to be described in the extended model is detected in the analysis result and a pattern corresponding to the target pattern is detected, the associated substitution A method comprising causing a mode to be described in the extended model. The method according to claim 1, wherein the writing step includes the steps of:
A method comprising: providing a control mechanism, whereby one of the operational modes described in the extended model is selected for use in a simulation using the extended model. The method of claim 1, further comprising:
Obtaining a mission definition for a system of one or more components;
Obtaining a design configuration representing the system of components;
Extracting design parameters from the design configuration;
Extracting information from the design parameters;
Establishing a Multi-Body Dynamics (MBD) simulation model based on the extracted information and executing the MBD simulation model using the mission definition to achieve a result set;
Generating at least one parameter map based on the achieved result set and the extracted design parameters. The method of claim 6, wherein the parameter map reflects fatigue of components in the system, the method further comprising:
Determining the fatigue life of the component from the parameter map.   8. The method of claim 7, wherein the parameter map includes: (i) a probability of fatigue failure of the component as a result of stress applied by placing the component in a condition reflected by the mission definition; A method that is associated with a parameter array. 9. The method of claim 8, wherein the MBD simulation model is executed multiple times to produce a multi-point cloud result, wherein the points in the point cloud represent different design parameter arrays, the method further comprising:
A method comprising the step of interpolating the result value between points in the point cloud. A system that automatically generates an extended model of a physical component,
A processor operable to:
Read the input model, the input model describes the nominal operating mode for the physical component modeled by the input model,
Analyzing the input model and generating the analysis results,
Analyzing the analysis result of the input model;
Based on the analysis results, the input model automatically writes to the extended model for the physical component, the extended model comprising: (i) the nominal operating mode of the modeled physical component; and (ii) ) Describes both at least one alternative mode of operation for the modeled physical component that is different from the nominal mode of operation;
Have a processor,
The analysis of the analysis result is performed according to at least one of the first approach and the second approach,
The first approach is that the input model is sensitive to one or more of the types of faults including (i) critical, (ii) power flow, and (iii) parameter type faults. Works to detect
The second approach is a system that operates so as to correspond to a specific viewpoint of the dynamic behavior of the component, and appropriately corrects the corresponding viewpoint to reflect the dynamic behavior of the failure mechanism.   11. The system of claim 10, wherein (i) a critical type of failure represents a change in the dynamic behavior of the component such that the component functions as completely different from the component, and (ii) power flow Type faults affect one or more of the power flows to and from the component, and (iii) parameter type faults are a shift of a parameter that should be fixed for the component. A system that reflects. The system of claim 10, wherein analyzing according to the first approach comprises:
For example, when the analysis result of at least one of a power interface or a connector class is searched and at least one of a power interface or a connector class is found, an alternative mode related thereto is described in the extended model. A system that has a process to perform. The system of claim 10, wherein analyzing according to the second approach comprises:
When a pattern corresponding to a target pattern associated with the substitution mode to be described in the extended model is detected in the analysis result and a pattern corresponding to the target pattern is detected, the associated substitution A system comprising the steps of allowing modes to be described in the extended model. The system of claim 10, wherein the processor further comprises:
Get mission definitions for a system of one or more components,
Obtain a design configuration representing the system of components,
Extracting design parameters from the design configuration;
Extracting information from the design parameters;
Establishing a multi-body dynamics (MBD) simulation model based on the extracted information, executing the MBD simulation model using the mission definition to achieve a result set;
A system operable to generate at least one parameter map based on the achieved result set and the extracted design parameters. 15. The system of claim 14, wherein the parameter map reflects fatigue of components in the system, the method further comprising:
Determining the fatigue life of the component from the parameter map.   16. The system of claim 15, wherein the parameter map includes: (i) a probability of fatigue failure of the component as a result of stress applied by placing the component in conditions reflected by the mission definition; A system that is associated with a parameter array. 17. The system of claim 16, wherein the MBD simulation model is executed multiple times to yield a multipoint cloud result, the points in the cloud represent different design parameter arrays, the method further comprising:
A system comprising a step of interpolating the result value between points in the point cloud.

Images