Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F30/00—Computer-aided design [CAD]
  • G06F30/20—Design optimisation, verification or simulation
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2111/00—Details relating to CAD techniques
  • G06F2111/10—Numerical modelling

Definitions

• the present inventive subject matter relates generally to the art of cyber- physical component and/or system modeling. Particular but not exclusive relevance is found in connection with object-oriented and/or other like modeling computer languages, e.g., such as Modelica, etc.
• object-oriented and/or other like modeling computer languages e.g., such as Modelica, etc.
• the present specification accordingly makes specific reference thereto at times.
• aspects of the present inventive subject matter are also equally amenable to other like applications and/or environments.
• Modeling languages are commonly used to generate virtual models of and/or to simulate physical components and/or systems for design, analysis and/or testing purposes.
• the physical systems and/or components that are modeled may be fairly complex or rather simple and can include, e.g., electrical circuits or automotive vehicles or other physical systems.
• the open source Modelica Standard Library (MSL) includes models of approximately 1280 components in domains, e.g., such as electronics, mechanics and fluids.
• Cyber-physical components are built from or depend upon the synergy of computational and physical components, such as system controllers that implement control software on hardware platforms, as found in vehicles, assembly lines and other engineered systems.
• the Modelica_LinearSystems2 library includes models for continuous and discrete controllers.
• the MSL itself includes models for different variants of Proportional, Integral and Differential (PID) controllers.
• PID Proportional, Integral and Differential
• These Modelica models and the like have come to be widely used more and more in various projects.
• the term "physical component” is used to mean either or both "physical” and "cyber-physical component”.
• the MSL models and the like generally describe and/or represent only one mode of operation for the component being modeled, namely, the nominal or correct behavior of the component being modeled. That is to say, such models commonly do not describe faulty or other non-nominal behaviors.
• a fault mode may be a short or open circuit or a motor that fails to run or a slipping brake, etc.
• Any number of difference mechanisms e.g., such as wear, material fatigue, corrosion, etc., may lead to the faulty operation of a modeled component.
• diagnostics and/or other testing of modeled components operating in such faulty and/or otherwise non-nominal modes can be problematic.
• damage process models express damage due to failure mechanisms that are active in system components because of their service environments as a function of, for example, such parameters as loads, materials' properties, and dimensions.
• Running reliability simulations under specific system configurations and usage conditions can be overly time and/or labor intensive.
• a new and/or improved method and/or system or apparatus for automatically and/or semi-automatically generating component models including non-nominal behavior modes. Additionally, it allows investigation of the effect of component fault at the system level that may possibly be used to improve the system design in terms of robustness, resiliency and reliability.
• a method for automatically generating an augmented model of a physical component.
• the method includes: reading an input model into a processor, the input model describing a nominal mode of operation for a physical component modeled by the input model; parsing with the processor the input model to generate a parse thereof; analyzing with the processor the parse of the input model; and automatically writing with the processor an augmented model for the physical component from the input model based on the analysis, the augmented model describing both (i) the nominal mode of operation for the modeled physical component and (ii) at least one alternate mode of operation for the modeled physical component which is different from the nominal mode of operation.
• the analyzing is conducted according to at least one of a first approach and a second approach.
• the first approach operates to detect if the input model is susceptible to one or more kind of fault including: (i) catastrophic, (ii) power flow, and (iii) parametric kinds of faults; and the second approach operates to match specific facets of a component's dynamic behavior, and appropriately modify those matched facets to reflect the dynamics of a fault mechanism.
• a system for automatically generating an augmented model of a physical component.
• the system includes: a processor operative to: read in an input model, the input model describing a nominal mode of operation for a physical component modeled by the input model; parse the input model to generate a parse thereof; analyze the parse of the input model; and automatically write an augmented model for the physical component from the input model based on the analysis, the augmented model describing both (i) the nominal mode of operation for the modeled physical component and (ii) at least one alternate mode of operation for the modeled physical component which is different from the nominal mode of operation.
• analyzing the parse is conducted according to at least one of a first approach and a second approach.
• the first approach operates to detect if the input model is susceptible to one or more kind of fault including: (i) catastrophic, (ii) power flow, and (iii) parametric kinds of faults; and the second approach operates to match specific facets of a component's dynamic behavior, and appropriately modify those matched facets to reflect the dynamics of a fault mechanism.
• FIGURE 1 is a diagrammatic illustration showing an exemplary model transformation system suitable for practicing aspects of the present inventive subject matter.
• FIGURE 2 is a flow chart showing an exemplary method for performing a model transformation process in accordance with aspects of the present inventive subject matter.
• FIGURE 3 shows an exemplary workflow in accordance with aspects of the present inventive subject matter, using MBD analysis for determining component fatigue life conditioned on mission usage and design configuration.
• FIGURE 4 shows a graphical representation of a simulation test course, with the course height along the vertical axis (in inches) and the course distance along the horizontal axis (in inches).
• FIGURES 5A and 5B illustrate sample, acceleration time histories for a trench crossing and 1 meter wall step down.
• FIGURE 6 shows a sample von Mises stress contour of an exemplary 4 x 4 x 4 bracket.
• FIGURES 7, 8 and 9 show the maximum accelerations at the bracket in X, Y, and Z directions respectively as functions of speed and bracket stiffness.
• FIGURES 10, 11 and 12 show the percentage errors for the maximum lateral, longitudinal and vertical accelerations as a function of vehicle speed and Power Pack mass scaling factor.
• any identification of specific materials, techniques, arrangements, etc. are either related to a specific example presented or are merely a general description of such a material, technique, arrangement, etc. Identifications of specific details or examples are not intended to be, and should not be, construed as mandatory or limiting unless specifically designated as such. Selected examples of apparatuses and methods are hereinafter disclosed and described in detail with reference made to the figures.
• a method, system and/or apparatus which is operative to augment models of physical system components with fault and/or other non-nominal modes.
• models including the fault and/or other non-nominal modes are automatically or semi- automatically generated from models of the components which otherwise describe only the nominal or correct behaviors of the components.
• FAME is an acronym for Fault-Augmented Model Extension.
• the augmented models may be extended as described herein to include other alternate modes that are not "fault" related strictly speaking, but are rather related to other non- nominal or alternate operating modes.
• existing open source libraries e.g., the Modelica Standard Library (MSL), libraries developed by third parties and other libraries
• MSL Modelica Standard Library
• libraries developed by third parties and other libraries are extended to allow the compact introduction of fault models while preserving the availability of existing nominal behavior specifications when no fault has been introduced into a specific instance of a model.
• MSL Modelica Standard Library
• the methodology allows fault models to be inserted into new components created by various third parties and/or other Modelica library developers.
• the FAME model transformation process leverages the JModelica Modelica parser framework, and the JastAdd technology on which it is built, to inject faults into the nominal component model library.
• a Java program incorporating JastAdd and JModelica runs over the supplied library, recognizes fault-susceptible component models, re-writes them as appropriate to provide fault behavior, and outputs the modified library to a new location.
• Modelica for an electrical capacitor, which is susceptible to both ElectricalOpen and ElectricalShort faults.
• a suitable embodiment operates to detect or otherwise determine what faults it is susceptible to, and rewrite it so that these faults could be simulated in instances of this class.
• an exemplary embodiment operates to look for three classes of faults: (i) catastrophic, (ii) power flow, and (iii) parametric.
• Catastrophic faults typically change the dynamics of a component into something completely different.
• the common catastrophic fault is an open circuit.
• Power flow faults affect one or more of the power flows to or from the component.
• a common power flow fault is a short circuit of some magnitude.
• Parametric faults typically reflect the shifting of a supposedly fixed parameter. For example, in the case of a capacitor, the capacitance.
• Another suitable approach relies on matching specific facets of a component's dynamic behavior, and appropriately modifying those facets to reflect the dynamics of fault mechanisms. In contrast to the external approach, this method is referred to as an "internal” approach. It can provide more detailed modeling of the fault behaviors, but it can be more difficult to specify accurately.
• JModelica is an open-source Modelica tool chain.
• JModelica consists of a Java/JastAdd parser for the Modelica language, along with various simulation and analysis tools, written in both Java and Python.
• JastAdd is a Java-based implementation of Knuth's attribute grammars, in which nodes in the abstract syntax tree (AST) can have attributes, the values of which are defined by equations. Each attribute can be either synthesized (defined by an equation attached to the node itself), or inherited (defined by an equation in an ancestor node). JastAdd supports reference attributes, which is an attribute that has as its value another node in the AST. This allows arbitrary graphs to be woven through the AST.
• JastAdd is Java-based, so equations are implemented as Java methods, and attribute access is via calls to those methods. It also extends Java itself with various constructs, notably aspects. JastAdd aspects support intertype declarations for AST classes. An intertype declaration is a declaration that appears in an aspect file, but that actually belongs to an AST class (like an attribute equation). The JastAdd system reads the aspect files and weaves the intertype declarations into the appropriate AST classes. It supports both declarative aspects (.jrag files), and imperative aspects (.jadd files). Declarative aspects add new attributes, equations, and rewrites; imperative aspects add only Java methods and variables.
• Rewrites of the AST can also be specified; they replace an AST node of type A with a node of type B, optionally only when some condition C is true.
• New AST subtrees can be created and specified as attribute values ("non-terminal attributes").
• the JModelica parser is used to parse each library file, then examine each model class (non-partial Modelica class definitions with the restriction model) found in l e parse tree for instances of the following connector classes:
• Modelica connector classes which contain two variables, one of an effort type, such as voltage or pressure, and another of a flow type, such as current or mass flow rate.
• the analysis suitably incorporates both direct components of the model class, as well as components of each inherited class used by the model class. If any of the above components are found, the parse tree for a replacement class for the model class is created, and the model class's parse tree is replaced with that new parse tree.
• each generic fault or alternate mode e.g., such as an "electrical short" is modeled with an aspect which provides a subclass of a more generic class, e.g., "Fault”.
• Each Fault or alternate mode subclass provides a predicate, e.g., such as: static boolean may_occur_with (FullClassDecl klass);
• the implementation of the "may_occur_with" predicate is dependent on matching some pattern defined for the fault/alternate mode against the parse of the model, as given by the FullClassDecl node of the AST.
• each Fault or alternate mode subclass suitably contributes an instance of itself to the "possibleFaults" collection attribute on FullClassDecl, if that FullClassDecl is susceptible to it, using, e.g., the JastAdd "contributes" mechanism.
• FullClassDecl contributes (ElectricalShort(this))
• JModelica FullClassDecl node type is extended to include a number of additional attributes, e.g., in the following manner: coll Set ⁇ Fault> FullClassDecl. possibleFaults()
• the "rewrite" capability of JastAdd may be used to re-write the AST representing the model, the FullClassDecl node, to add fault behavior to that model.
• the rewrite rule may look something like the following: rewrite FullClassDecl ⁇ when (faultEligibleQ) // faults possible for this type? to FullClassDecl ⁇
• this rewrite may be applied automatically as part of the parsing process, where appropriate, which will result in the fault/alternate behavior clauses being injected into the parse of the model.
• the equation re-writing method rewriteEquationsToAddFaults(), takes the nominal equations for the model, and wraps them in one branch of a Modelica if-equation for that case, then adds additional branches to the if-equation for each possible fault/alternate mode, along with the equations for that fault/alternate mode.
• those fault/alternate equations may be obtained by calling a method on the Fault and/or alternate subclass instance.
• an if-equation is a common way of implementing a conditional equation.
• the JModelica "FormattedPrettyPrint” aspect and/or capability may be used to recreate the now-fault-enabled Modelica source code for the model from the AST.
• the overall program for injecting faults and/or alternate modes into the models may be something like the following (in pseudo-code): for file in recurseOver (libraryTree) :
• parsedVersion parseFile (file)
• the augmented models can be used for a wide variety of diagnostic applications.
• all the augmented models are written in standard Modelica.
• the initial values, parameters and fault/alternate modes can all be set in a Modelica wrapper.
• some uses of the new models for both design and diagnostic purposes include, but are not limited to:
• every model class definition which contains faults is replaced with a new class definition, namely, a Modelica model class subsuming the original model class and adding declarative behavior to allow simulation of the faults.
• a class model is found to be susceptible to one or more faults, then the class is re-written.
• An encapsulated enumerated type is defined, listing the various fault modes of the class, along with the "nominal" mode.
• a discrete mode parameter of this new type is defined, defining the mode in which an instance of the class is operating.
• each new class connects its instance of a power interface component through an added variable power dissipation component which in nominal mode dissipates no power.
• the original model class is an electrical component
• the power interface instance is an instance of the class Pin
• the appropriate power dissipation component would be an instance of FAME. DynamicDampers. Electrical, with the damping parameter set to 0.
• the new class may also contain variable power conductance components connecting each pair of compatible connector components, nominally set to conduct no power.
• Connector components are "compatible" if they are of the same type, or inherit from the same type.
• the original model class is an electrical component which contains an instance "p" of the connector type PositivePin and an instance "n” of the connector type NegativePin, both of which are subtypes of Pin, there would be an instance of FAME.Bridges.Electrical connecting those two instances, with the bridging amount set to the very small value of Modelica.Constants.eps.
• the process may also suitably flatten the superclasses of the model into the rewritten class, and introduce two new externally visible components, FAME_operating_mode and FAME_fault_amount, as well as an enumerated type giving the possible faults for this component, FAME_OperatingModes.
• Faults which manifest as power flow anomalies are modeled by a simple change to these two variables. For instance, as seen above, an electrical short can be modeled by setting FAME_operating_mode to FAME_OperatingModes.Electrical_Short, and FAME_fault_amount to 1.
• Modelica Electrical .Analog . Interfaces . PositivePin ;
• FAME_operating_mode FAME_OperatingModes .Nominal ;
• v _damper_p ,port_b . v-_damper_n . port_b . v;
• 0 _damper_p .port_b . i+_damper_n . port_b . i ;
• FAME C C* (1.0-FAME_fault_amount) ;
• dam ing FAME_fault_amount ;
• damping FAME_fault_amoun ;
• bridging FAME_fault_amount ;
• the system reads in a table of parametric faults, for example, each row of which describes a particular fault in which a supposedly fixed parameter changes during the operation of the component. For each fault, this provides the fault mode, the Modelica class, the specific parameter component of the class, the Modelica type of the parameter, and a Modelica expression describing the change in the parameter as a function of the variable FAME_fault_amount.
• parametric faults are handled by introducing a new continuous variable, prefixed with "FAME_”. An equation is added to set this variable to the value computed by the function specified by the fault table. Accordingly, references to the original parameter are replaced with an expression with references to this new variable.
• the so called internal approach functions by detecting patterns in the dynamics of the model class, which indicate its susceptibility to a particular fault. Where such susceptibility is detected, the equations describing the dynamics of that model are then re-written in such a way as to allow that fault to be modeled.
• a susceptibility/applicability pattern is specified that, when matched by a model class, indicates that the class may exhibit the fault.
• these patterns are suitably defined in an appropriate language that describes the kinds of components the class may have, and how those components are interrelated.
• the system suitably deems any model class satisfying these four constraints to be potentially subject to this slippage fault mode. That is to say, when the foregoing constrains are detected in a model class, that model class is deemed to be subject to the designated fault mode and accordingly rewritten.
• the names assigned to variables in the patterns are suitably independent of the names assigned to the variables in the Modelica source code.
• the pattern name bindings are preserved in the case of a match to be used in the modification of the model dynamics.
• the Modelica model class is flattened, i.e., all superclasses are expanded, and all record and connector subcomponents are expanded.
• the pattern language can be fairly simple. For example, there are two operators, component and equation, which match components and equations, respectively.
• the component operator has the form:
• component cname qualifier-list where cname is an identifier to be assigned to the matching component (not the name defined by the component declaration), and qualifier-list is a comma-separated list of qualifiers which when matched result in the constraint being satisfied.
• qualifiers which may be specified are type, which is the fully-qualified name of a Modelica class, or prefix, which is the type prefix for the component declaration.
• Equation operator for example, may have the form:
• instances of rhs-expression may be just a cname, or built up with the following primitives:
• each fault and/or alternate mode suitably contains a description of an "edit program", used to modify the class to add the ability to simulate that fault.
• edit programs may be written in the following primitives:
• a class model is found to be susceptible to one or more faults, the class is re-written.
• An encapsulated enumerated type is defined, listing the various fault modes of the class, along with the "nominal" mode.
• a discrete mode parameter of this new type is defined, defining the mode in which an instance of the class is operating.
• the set of equations for the class are replaced with a single if-equation, e.g., of the form:
• Modelica.Constants.eps which is Modelica's notion of a very small value
• Modelica.Constants.inf is Modelica's idea of a very large value. This used this to avoid numerical instability associated with the use of zero, in the simulation phase.
• the library 20 may include a collection of models 22, in which each model 22 describes and/or otherwise represents a physical component, e.g., including the operation and/or behavior of the component.
• the library 20 may include one or more such models 22, e.g., representing components that are to be employed and/or interact together in a system, or the library 20 may include some other suitable collection of such models 22.
• each model 22 in the input library 20 may comprise and/or be represented by lines of code (e.g., written in the Modelica language or another such suitable language) or the like stored in a file or otherwise in a suitable memory or other data storage device accessible by the computer or processor 10.
• at least one of the models 22 (but alternately more or all of the models 22) in the library 20 describes or otherwise simulates only a nominal operation and/or behavior of the physical component modeled thereby, e.g., such nominal operation and/or behavior may correspond to the correct operation and/or behavior of the modeled component.
• the library 20 may include only one model 22, and in more complex examples, it may include a great many models 22.
• a second library 30 may include a collection of salient alternate modes and/or mechanisms 32 applicable to the modeled components of the library 20.
• each alternate mode and/or mechanism 32 of the library 30 may describe and/or represent a fault mode and/or mechanism or some other non-nominal or alternate mode of operation and/or behavior.
• each alternate mode 32 may be applicable to one or more modeled components in the library 20, while potentially not being applicable to others.
• a short circuit fault mode may be applicable to a number of different electronic components (e.g., such as a capacitor and/or inductor), while not being applicable to mechanical components (e.g., such as a brake).
• each alternate mode 32 in the input library 30 may comprise and/or be represented by lines of code (e.g., written in the Modelica language or another such suitable language) or the like stored in a file or otherwise in a suitable memory or other data storage device accessible by the computer or processor 0.
• a fault mechanism can be used to express an underlying cause of a fault
• a fault mode can be used to express the abnormal operation or behavior of a component being modeled.
• the exemplary fault mechanisms of a rusty shaft and a disconnected lead wire in relation to a motor which is being modeled may be a shaft that is harder to turn (i.e., as compared to when the motor is otherwise operating normally) and a motor that simply does not run, respectively.
• fault modes and mechanisms may be captured and/or otherwise identified for each subject component being modeled. These may be organized, optionally along with fault probabilities, in a suitable taxonomy so that corresponding behavioral models can be built consistently. Accordingly, a fault mechanism behavior schema may in turn be developed in view of the aforementioned taxonomy. For example, the schema may define faulty behavior at the highest abstraction level in a generic sense and use the concept of inheritance to specify behavior for the lower-level fault mechanisms. This approach allows for flexibility in defining behavior for subclasses of fault mechanisms.
• This may represent a high-level category of different subclasses of wear, e.g., such as abrasive, impact or corrosive wear.
• the subclasses (of wear in this example) inherit and expands upon the higher-level behavior.
• the behavior of wear representing a loss of material is expanded to include, e.g., the frictional behavior in the subclass of abrasive wear.
• fault modes for different components can call upon the same fault mechanism, i.e., underlying faulty behavioral model.
• these subclasses may cover the expression of a fault mechanism in different domains, e.g., such as mechanical, hydraulic, electronic, etc.
• an alternate mode may not represent faulty operation and/or behavior at all but rather may simply represent some other non-nominal operation and/or behavior of the component being modeled.
• each model 42 in the output library 40 may comprise and/or be represented by lines of code (e.g., written in the Modelica language or another such suitable language) or the like output to a file or otherwise which is stored in a suitable memory or other data storage device accessible by the computer or processor 10.
• an augmented component model 42 is output for each input nominal component model 22 from the library 20, with the augmented component models 42 including a description and/or representation of not only the nominal operation and/or behavior of the modeled component but also including a description and/or representation of one or more or all of the alternate modes of operation and/or behavior applicable to the component being modeled.
• the output augmented component models 42 of the library 40 are fully compatible with their corresponding input nominal component models 22, e.g., in terms of their interfaces, inputs, outputs and parameters.
• the augmented component models 42 may simply be plugged-in to and/or replace the nominal component models 22 for testing and/or analysis of fault and/or other alternative modes of operation and/or behavior of various components.
• the computer and/or processor 10 may execute a computer program or the like (e.g., stored in a suitable memory or other data storage device accessible by the computer/processor 10) to carry out the aforementioned model transformation process.
• FIGURE 2 is a flow chart illustrating steps of one suitable embodiment of the model transformation process 100.
• the aforementioned program executed by the computer/processor 10 may be written in a general-purpose, class-based, object-oriented computer programming language, e.g., such as a Java or the like, which incorporates the JModelica platform or the like and the Java/JastAdd parser or the like.
• the program runs over the input library 20 and recognizes those nominal component models 22 which are susceptible the various faults and/or alternate modes 32 of the library 30, e.g., by identifying specified patterns associated with the respective alternate modes 32 in the variables, equations and/or other content of the models 22.
• the model transformation process 100 suitably begins at step 102, with the reading in of one of the models 22 from the library 20.
• a given model 22 is parsed, and at step 106, the parsed model is examined and/or analyzed to look for specified content, patterns and/or clues therein which are associated with an alternative mode 32.
• a given model 22 will generally comprises one or more lines of code, including, e.g., equations, parameters, variables and/or other content, which defines the component being modeled along with its nominal operation and/or behavior. From this content, clues and/or patterns can be detected and/or discerned which match (e.g., within some degree of tolerance) certain content, clues and/or patterns associated with faults and/or other non-nominal or alternate modes.
• the content may include elements, clues or patterns which suggest that a given model 22 describes an electrical component, e.g., such as a capacitor.
• the model 22 may include an equation or parameter or other content from which it can be determined that the model 22 is in fact a capacitor.
• this type of component i.e., an electrical component in general and more specifically a capacitor, is susceptible to certain faults and/or certain alternate modes are applicable thereto, e.g., a short or an open circuit, etc. That is to say, the content of the model 22 sufficiently matches a pattern associated with the respective fault and/or alternate mode 32.
• step 108 if no pattern and/or clues are found which sufficiently match those sought, then the process 100 branches to step 110, otherwise if a pattern is found, then the process 100 continues to step 112.
• the model 22 is essentially left unaltered. That is to say, the model 22 may be essentially left as is. In this case, the corresponding model 42 in the output library 40 will be essentially the same as the input model 22.
• the model 22 is rewritten and/or edited into a new model 42 so as to describe, not only the nominal mode of operation originally contained in the model 22, but also to describe the alternate mode associated with matched pattern.
• each model 22 of the input library 20 is so processed, e.g., in turn or in parallel.
• each model 22 may be susceptible to zero or one or more of the faults and/or alternate modes 32 described in the library 30. That is to say, the content of the model 22 may match none or one or more different patterns associated with the various faults and/or other alternate modes 32.
• the description of and/or code for each applicable alternate mode may be injected or otherwise inserted into the model.
• that description or code may be obtained from the applicable alternate modes 32 and may include one or more equations and/or functions which represent and/or model the alternate mode in question.
• every model class definition which contains faults or alternate modes is replaced with a new class definition, e.g., a Modelica model class subsuming the original model class and adding behavior to allow simulation of the faults and/or alternate modes.
• the augmented model 42 is provided with a control mechanism and/or suitable code to permit the selection of the particular mode in which the model 42 will operate for a given simulation. That is to say, the aforementioned control mechanism and/or code allows the augmented model 42 to be selectively run in any one of the modes, be it the nominal mode from the original model 22 or one of the alternate modes added by the rewrite/editing. In this way, alternative dynamics are enabled for each operating mode.
• an input model 22 of a capacitor may look something like the aforementioned un-augmented or simple capacitor model (written in the Modelica language). Accordingly, the output augmented model 42 (also written in the Modelica language) generated from such an input model 22 may look like the aforementioned augmented capacitor model.
• an encapsulated "enumerate" type is defined in which the alternate modes labeled as Drift, ElectricaLShort, Electrical_Leak and ElectricaLBreak are listed along with the Nominal mode.
• a discrete mode parameter of this new type is defined, defining the mode in which an instance of the class is operating.
• a conditional equation is then employed and/or written to permit dynamic selection of a particular operating mode.
• a set of equations which apply in each alternate mode is expressed in the appropriate branch of this conditional equation.
• the operating mode type is, e.g., a Modelica parameter
• the selected branch generally will not change during simulation and compilers can optimize this equation.
• the power flow analysis may depend on identification of standard power interfaces represented in the input model 22.
• these are instances of Modelica connector classes and/or the like, e.g., such as the Pin class in Modelica's package of analog electrical interface types.
• power interfaces generally contain two variables, one of an "effort” type, such as "Voltage” or "Pressure,” and another of a "flow” type, such as "Current” or "MassFlowRate.”
• the analysis examines both the directly defined components of the model class as well as components of each inherited class used by the model class.
• every model class definition which contains such an instance is wrapped in a "shell" class definition, which is, e.g., a new Modelica model class containing the original model class, and containing an instance of that model class, as well as instances of each connector component, parameter component and constant component found in that original class.
• a "shell" class definition which is, e.g., a new Modelica model class containing the original model class, and containing an instance of that model class, as well as instances of each connector component, parameter component and constant component found in that original class.
• the system (e.g., the computer or processor 10) can optionally read in a table of parametric faults and/or alternate modes, each row of which describes a particular fault or alternate mode in which a supposedly fixed parameter changes during the operation of the component.
• the table or row thereof provides the fault/alternate mode, the Modelica class, the specific parameter component of the class, the Modelica type of the parameter, and a Modelica expression describing the change in the parameter as a function of a variable, e.g., such as FAME_fault_amount.
• the aforementioned table or the like may reside is a file or the like stored or otherwise saved in a memory or other suitable data storage device that is accessible by the computer or processor 10.
• each new shell class connects its instance of a power interface and/or connector component to the original power interface and/or connector component in its instance of the original model class, through an added variable power dissipation component, e.g., which in the nominal mode is set to dissipate no power.
• an added variable power dissipation component e.g., which in the nominal mode is set to dissipate no power.
• the appropriate power dissipation component may be an instance of FAME.DynamicDampers.Electrical, with the damping parameter set to 0.
• the shell class may also contain variable power conductance components connecting each pair of compatible connector components, nominally set to conduct no power.
• connector components are deemed “compatible” if they are of the same type, or inherit from the same type.
• the original model class is an electrical component which contains an instance "p" of the connector type PositivePin and an instance "n” of the connector type NegativePin, both of which are subtypes of Pin, there would be generated an instance of FAME.Bridges.Electrical connecting those two instances, with the conductance or bridging amount set to a very small value of Modelica.Constants.eps. W
• the augmented model 42 contains an example of a capacitor model with the aforementioned dampers and bridges added.
• the model transformation process also flattens (removes all hierarchy) the superclasses of the model into the rewritten class, and introduces two new externally visible components, FAME_operating_mode and FAME_fault_amount, as well as an enumerated type giving the possible faults and/or alternate operating modes for this component, FAME_OperatingModes.
• faults and/or other alternate modes which manifest as power flow anomalies can be modeled by a change to these two variables.
• an electrical short may be modeled by setting FAME_operating_mode equal to FAME_OperatingModes.Electrical_Short, and FAME_fault_amount equal to 1.
• a damage process models express damage due to failure mechanisms that are active in system components because of their service environments as a function of, for example, such parameters as loads, materials' properties, and dimensions.
• the damage state of a component reflects the service usage and history derived from context models. Uncertainties about parameters derived from context and component models and about damage process model parameters are characterized and incorporated in stochastic simulations.
• the parameterized simulation results are represented as damage- parameter maps (e.g., tables) that are then used to look up the expected damage in a user-specified component for a user-specified usage context without running the underlying stochastic damage process simulations again.
• One example of a system component for which a failure risk or reliability analysis may be performed is an engine/drivetrain mounting bracket of a vehicle. Such brackets are subject to fatigue failure due to time-varying loads resulting from traveling over rough terrain, vibration, or impacts. In practice, other failure mechanisms may also be analyzed and/or different system components may likewise be analyzed. Suitably, the analyses involve the use different engineering analysis tools and/or software. For example, an evaluation of the risk of fatigue failure of a mounting bracket may include:
• a backend workflow 200 (which is optionally invisible to the user) in accordance with aspects of the present inventive subject matter is shown in FIGURE 3.
• the workflow 200 is described herein in conjunction with a seed design vehicle (SDV) based on a given set of design parameters.
• SDV seed design vehicle
• the workflow 200 may be otherwise employed to achive similar results for other applications.
• the backend workflow 200 may progress as follows:
• a MBD simulation model 202 is first developed.
• the SDV that was developed included springs that represented the brackets that attached an engine and transmission assemblies to a hull. More generally, design configurations 204 and mission definitions 206 may be given as inputs to the workflow 200.
• mass properties are gathered, for example, from a computer aided design (CAD) model.
• CAD computer aided design
• the MBD model is created based on the CAD model, for example, of the SDV and its components.
• suspension spring/damping characteristics and mounting bracket location and stiffness are determined, and along with the selection of terrain/obstacle profiles, reasonable vehicle speed(s) are also determined.
• the design parameters 208 (such as the foregoing) are obtained from the design configurations 204.
• the design parameters 206 are used in the generation one or more parameterized maps 300, e.g., such as a parameterized fatigue map.
• the MBD simulation model 202 and mission definitions 206 are employed to achieve a set of results 210, namely, according to the present example, acceleration/force time histories at points-of-interest.
• the results for are post- processed, e.g., including power pack mounting brackets for the current effort.
• a mission force history is defined by concatenating the force histories that are generated from the MBD simulation. For example, in the present case, the SDV is driven over: Perryman 3, 12" high half round bump, a 30" step down, and a 96" wide trench crossing.
• DADS Dynamic Analysis and Design System
• a class of angle brackets for 2 materials and 3 angle dimensions and varying angle and gusset thicknesses were defined.
• linear static Finite Element (FE) analyses were performed to derive the maximum stress in the brackets due to the highest force in the bracket mission history.
• An allowable stress factor for each bracket was calculated by dividing the yield stress of the material by the maximum stress in that bracket.
• An outcome of the FE analyses were the bracket stiffness in the three directions. Stiffnesses were represented via springs in the DADS vehicle simulation analyses.
• a fatigue failure simulation model was modified to generate damage parameter maps for given values of Allowable Stress Factor (ASF), for a given material of the bracket due to the bracket force mission histories derived from the DADS simulations.
• the ASF equations for bracket thicknesses t a and t g were derived by curve fitting the bracket FE analyses results. Bracket stiffness equations were also derived in a similar fashion.
• FIGURE 4 shows a graphical representation of the course, with the course height along the vertical axis (in inches) and the course distance along the horizontal axis (in inches).
• FIGURES 5A and 5B illustrates sample, acceleration time histories for the trench crossing and 1 meter wall step down.
• a fatigue model generates damage parameter maps at different probabilities of occurrence for a component, e.g., given its cyclic load history, geometry, material properties and certain uncertainties.
• the fatigue model is based on strain vs. life ( ⁇ vs. N) behavior of the material due to cyclic loads.
• the inputs to the fatigue model are the force history, the material data and the governing parameters for the component, e.g., for the bracket in the present case.
• Monte-Carlo (M-C) loops are performed for a number of random trials to derive the damage at desired probabilities of occurrence for a set of parameter values. In a single M-C trial, damage is derived by the following steps.
• the input load history is first transformed to a stress time history using a load-to-stress transformation described by the geometry or ASF.
• the stress range and number of cycles are identified, e.g., using a rainflow counting technique or algorithm. If the stress range of a cycle is above the yield strength, the total strain, ⁇ , will include the elastic and plastic strain.
• Neuber's rule is used to transform the elastic stress to a total strain range using the stress-strain curve for the material.
• the Walker relation is then used to correct the total strain range to account for the mean strain of the cycle.
• the damage due to total strain is derived using the strain vs. life model. Finally, the total damage due to each cycle is accumulated using Miner's rule to find the damage due to the entire force history.
• FIGURE 6 shows a sample von Mises stress contour of a 4 x 4 x 4 bracket.
• the maximum stress of 39.4 ksi is due to the largest force of 18300 lbs and the yield stress for stainless steel 17-4PH is 170 ksi.
• stainless steel 17-4PH H900 and aluminum 6061 -T6 materials where used in the bracket damage simulations.
• the properties of the materials used in the bracket damage simulations were obtained from MIL-HNDBK-5J (Department of Defense Handbook: Metallic Materials and Elements for Aerospace Vehicle Structures (31 Jan 2003)) and other suitable material's data files.
• the stress rupture properties given in Table 1 are the yield strengths for alloys.
• the A and B "basis" values for these materials were used to derive the mean, standard deviation, and the coefficient of variations for the yield stress and describe the strength uncertainty.
• the total strain vs. life data are used in the bootstrapping materials model approach to capture fatigue life uncertainty implied by the data set.
• the damage-parameter map allows a system designer or design tester, to explore the reliability consequences of different design choices, and to assess the probability of catastrophic fatigue failure as a result of mission stress.
• the approach and/or system described herein aids in discovering the answers to the following questions:
• this multidimensional sampling space means that the number of simulations grows exponentially with the number of distributions to sample from. However, this can be countered by speed up methods developed for Monte Carlo simulations.
• the system is further adapted to interpolate over a cloud of MBD point simulations over a desired set of points-of-interest to determine the acceleration at those points-of-interest for an unknown set of design or operational parameters. More specifically, MBD simulations are conducted to numerically determine the loads (accelerations) on points of interest in a system (e.g., suspension components in a car) based on the operation environment (e.g., terrain/road) and the operational parameters (e.g., speed). These loads are subsequently used in damage process models to determine the probability of failure in components at any given level of usage (e.g., suspension failure after 100K miles over potholed roads using city drive profiles).
• a system e.g., suspension components in a car
• the operational parameters e.g., speed
• MBD analyses help in fast exploration of reliability in large design spaces.
• MBD analysis is useful for determining component fatigue life conditioned on mission usage and design configuration.
• the ability is provided to determine component loads at arbitrary locations within a design configuration (e.g., front-engine vs mid- or rear-engine configuration for a car).
• a design configuration e.g., front-engine vs mid- or rear-engine configuration for a car.
• the 125-point cloud considers MBD simulations quantized by the following 3 simulation parameters:
• o Bracket vertical stiffness the values simulated are 3.49x105, 8.55 x105, 1.71 x106, 2.14 x106, and 2.83 x106 lb/in;
• FIGURES 7, 8 and 9 show the maximum accelerations at the bracket in X, Y, and Z directions respectively as functions of speed and bracket stiffness.
• FIGURES 10, 11 and 12 show the percentage errors for the maximum lateral, longitudinal and vertical accelerations as a function of vehicle speed and Power Pack mass scaling factor. Given the relatively low errors (i.e., most errors less than 5%), the interpolation approach to determining 3-axis accelerations for an arbitrary point design from a pre-simulated multi-dimensional cloud of 3-axis accelerations is considered valid.
• processor 10 may be embodied by a computer or other electronic data processing device that is configured and/or otherwise provisioned to perform one or more of the tasks, steps, processes, methods and/or functions described herein.
• a computer or other electronic data processing device embodying the processor 10 may be provided, supplied and/or programmed with a suitable listing of code (e.g., such as source code, interpretive code, object code, directly executable code, and so forth) or other like instructions or software or firmware, such that when run and/or executed by the computer or other electronic data processing device one or more of the tasks, steps, processes, methods and/or functions described herein are completed or otherwise performed.
• code e.g., such as source code, interpretive code, object code, directly executable code, and so forth
• other like instructions or software or firmware such that when run and/or executed by the computer or other electronic data processing device one or more of the tasks, steps, processes, methods and/or functions described herein are completed or otherwise performed.
• the listing of code or other like instructions or software or firmware is implemented as and/or recorded, stored, contained or included in and/or on a non- transitory computer and/or machine readable storage medium or media so as to be providable to and/or executable by the
• suitable storage mediums and/or media can include but are not limited to: floppy disks, flexible disks, hard disks, magnetic tape, or any other magnetic storage medium or media, CD-ROM, DVD, optical disks, or any other optical medium or media, a RAM, a ROM, a PROM, an EPROM, a FLASH-EPROM, or other memory or chip or cartridge, or any other tangible medium or media from which a computer or machine or electronic data processing device can read and use.
• non-transitory computer-readable and/or machine-readable mediums and/or media comprise all computer-readable and/or machine-readable mediums and/or media except for a transitory, propagating signal.
• any one or more of the particular tasks, steps, processes, methods, functions, elements and/or components described herein may be implemented on and/or embodiment in one or more general purpose computers, special purpose computer(s), a programmed microprocessor or microcontroller and peripheral integrated circuit elements, an ASIC or other integrated circuit, a digital signal processor, a hardwired electronic or logic circuit such as a discrete element circuit, a programmable logic device such as a PLD, PLA, FPGA, Graphical card CPU (GPU), or PAL, or the like.
• any device capable of implementing a finite state machine that is in turn capable of implementing the respective tasks, steps, processes, methods and/or functions described herein can be used.

Landscapes

• Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Computer Hardware Design (AREA)
• Evolutionary Computation (AREA)
• Geometry (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Test And Diagnosis Of Digital Computers (AREA)

Priority Applications (3)

Applications Claiming Priority (4)

Publications (1)

Family

ID=59225985

Family Applications (1)

Country Status (4)

Cited By (4)

Families Citing this family (2)

Citations (4)

Family Cites Families (4)

• 2017
  • 2017-01-03 WO PCT/US2017/012049 patent/WO2017117607A1/en not_active Ceased
  • 2017-01-03 EP EP17733946.2A patent/EP3398094A4/de not_active Withdrawn
  • 2017-01-03 JP JP2018553853A patent/JP2019502222A/ja active Pending
  • 2017-01-03 CN CN201780005412.6A patent/CN108496168A/zh active Pending

Patent Citations (4)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events