Glossary of Diagnostic Modeling Terms
Structural Model – A model that represents only connectivity and parts, usually imported from a CAD/CAE tool using a net list or a transfer format such as EDIF. The pin-outs of parts are usually identified, although their flow direction (input, output, bidirectional) may not be. Also, power and ground pins are not always enumerated within the structural model. Lacking signal flow, a structural model is not a dependency model.
Topological Model – A model that supplements a structural model with information about signal flow (both between components and within components). A high-quality CAD/CAE import can often derive a topological model directly from engineering data, provided that flow information or additional part libraries are available upon which to create the flow. Although a topological model can be represented in dependency model format, it is not in and of itself a diagnostic model, since it contains no information about testing.
Non-Topological Model – A model that represents elements of a system, device or process without representing the relationships between those elements. Although easier to develop than topological models, non-topological models (when used for diagnostic applications) force the user to model test coverage explicitly. Because of this, non-topological models are mostly useful for documenting legacy or fully-developed diagnostic designs, since the lack of topology renders these models more or less useless as an aid for determining test coverage. Non-topological models are sometimes also used for modeling "black box" devices, when engineering details are not available.Although a non-topological model can be represented in dependency model format (so, for example, the model could be utilized by a model-based diagnostic engineering tool), the resulting model will consist of a set of unrelated first-order dependency statements. In other words, there would be no upstream or downstream relationships between the different elements in the model. Like topological models, non-topological models are not diagnostic models in and of themselves, since they contain no information about tests.
Diagnostic Model – A model that supplements a topological or non-topological model with information about how different signals can be tested.
Diagnostic Dependency Model– A single or multi-dimensional dependency model that collectively represents the relationships between testable events and the agents (functions or failure modes) responsible for those events. Because they must abstractly and conditionally account for dependencies beyond simple functionality, diagnostic models are sometimes difficult to correlate directly to a specific drawing of a system, device or process.
Function – In dependency modeling, an entity in a dependency model that represents the specific mechanism of a system, device or process that allows it to operate in a particular manner.
Function Space – The space comprised of the set of entities (functions) that collectively describe how a system, design or process is expected to work.
Negative Function Space – A function space that is comprised of a set of functions that represent the absence of specific failure modes.
Functional Diagnostic Model – A diagnostic model whose agents are based exclusively on function space. Although a functional diagnostic model may include elements based on negative function space, it lacks the ability to correlate members of the two spaces. Functional diagnostic models are particularly useful as a tool for influencing a diagnostic design during early design phases (since functional descriptions of a design can be developed before the implementation specifics have been worked out). Functional diagnostic models can then be supplemented with lower-level data (sometimes imported directly from CAD/CAE databases) as it becomes available. The biggest disadvantages of functional diagnostic models are that they are not easily mapped to FMECA data and that they must sometimes be translated into failure mode diagnostic models before they can be used to implement run-time diagnostics.
Functional Diagnostic Dependency Model – A functional diagnostic model that has been represented using a single or multi-dimensional dependency model.
Fault – A defect or flaw in an agent (hardware, software, human, etc.) that results in a failure.
Failure – The loss of ability of a system, device or process to perform a required function. The manifestation of a fault. (See also Hardware Failure and Software Failure).
Failure Mechanism – The process that results in a failure to a system, device or process.
Failure Mode – The characteristic manner in which a failure occurs. Within a failure mode diagnostic model, failure modes represent specific ways in which a system, device or process can fail. (Also see Object Failure Mode).
Failure Space – The space comprised of the set of entities (failure modes) describing how a system, device or process is expected to fail.
Negative Failure Space – A failure space that is comprised of a set of failure modes that represent the absence of specific functions.
Functional Failure Mode – A term frequently used to identify members of a negative failure space.
Failure Mode Diagnostic Model – A diagnostic model whose agents are based exclusively on failure space. Although a failure mode diagnostic model may include elements based on negative failure space, it lacks the ability to correlate members of the two spaces. Although failure mode diagnostic models provide a useful link between FMECA analysis and run-time diagnostics, their usefulness as a tool for influencing a diagnostic design is severely limited (since failure mode diagnostic models cannot be developed until relatively late in the design process, when specific failure modes have been identified).
Failure Mode Diagnostic Dependency Model – A failure mode diagnostic model that has been represented using a single or multi-dimensional dependency model.
Hierarchical Diagnostic Model – An extension of diagnostic dependency modeling that allows for the representation of the relationships between components, functions and tests at multiple levels of a design's hierarchy. Because the relationships between higher-level (parent) and lower-level (child) functions are modeled, for example, these models can be used to support hierarchical diagnostic inference (for example, when a parent function is proven good, all of its child functions can be inferred to be good; conversely, when all of a function's children have been proven good, then the parent can be inferred to be good).
Hybrid Diagnostic Model – An extension of diagnostic dependency modeling that allows the inter-relationships between tests, functions and failures to be captured within a single representation of a system, device or process. Although a hybrid diagnostic model draws agents from both function and failure spaces, it is more sophisticated than a classic diagnostic dependency model in that it also represents the inter-relationships between functions and failure modes (rather than only the relationships between these agents and tests). Because of this, these models can be used to support hybrid diagnostic inference. Hybrid Diagnostic Models embrace the advantages of both functional and failure mode diagnostic models, allowing the same model to be utilized for early diagnostic design influence, FMECA development/assessment, diagnostic performance predictions, and run-time diagnostic development.
Single-Signal Modeling – A simplistic approach to dependency modeling in which the diagnostic model is comprised exclusively of first-order dependency statements in which individual agent (function or failure mode) dependencies are always associated with the same first-order event dependencies. With this approach, signals are always dependent upon all upstream agents; furthermore, the number of signals of which each agent can be a dependency is constrained by the modeled topology. Single-Signal Models are typically only used for trivial classroom examples and can rarely be applied successfully to real-world applications.
Multi-Signal Modeling – An approach to dependency modeling in which individual agents (functions or failure modes) may appear in multiple first-order or nth-order dependency statements in a diagnostic model (representing different signals) with differing event dependencies. This approach, which does not necessarily require a multi-dimensional dependency model, provides the ability to trace signals through a path of components without involving every failure mode in the path. Although the term Multi-Signal Modeling appeared in the late 1990s, it represents a modeling approach that has been in use since the inception of dependency modeling in the 1950s. The biggest drawback of this approach is that multi-signal models are often time-consuming to develop and consist of large amounts of low-level data that is not easy to modify as the design changes. This effectively relegates modeling to a role of diagnostic performance prediction (typically performed relatively late in the design process), rather than early diagnostic design influence (which demands models that can be updated iteratively with relative ease). One alternative to multi-signal modeling is the more proactive approach of Passive-Active Flow Modeling.
Passive-Active Flow Modeling – An alternative to Multi-Signal Modeling that begins with a Topological Model and then, by propagating input signals along the various signal flow paths using active and passive propagation, generates a full representation of signal propagation. When combined with Test Overlay Modeling, Passive-Active Flow Modeling can generate the same complex dependency models that are produced by Multi-Signal Modeling, yet without the time-consuming signal definition task that renders most Multi-Signal Modeling efforts unsuitable for diagnostic design influence. Moreover, because Passive-Active Flow Modeling involves automatic signal propagation, it can be easily utilized with a variety of graphic representational schemes. This means that the graphical representation of a model can more closely resemble a schematic, management diagram, or picture of the system, device or process—thereby facilitating communication with engineers, managers, and customers/end users.
Test Overlay Modeling – A method of creating a diagnostic dependency model by overlaying short-hand test definitions upon a topological model. Each test definition (which contains information such as the test location, monitored stimuli, test symmetry, interference handling and exceptions) are applied as constraints upon the signal flow represented within the Topological Model, resulting in a full-order dependency statement for that test. The full set of dependency statements derived in this manner collectively comprise a Diagnostic Dependency Model. When combined with Passive-Active Flow Modeling, Test Overlay Modeling can generate the same complex models produced by Multi-Signal Modeling—with a fraction of the effort. Furthermore, if the Topological Model is supplemented with information relating failure modes to their affected functions, then Test Overlay Modeling can be used to generate a Hybrid Diagnostic Model. Test Overlay Modeling is an extremely effective way of reducing the time needed to develop and update detailed, low-level Diagnostic Dependency Models (thus allowing these models to be feasibly employed within an iterative design evaluation process).
eXpress Modeling – The diagnostic modeling methodology implemented within DSI International's eXpress tool. Using both Passive-Active Flow Modeling and Test Overlay Modeling techniques to reduce the time burden associated with multi-signal modeling, eXpress automatically generates full diagnostic dependency models to support its internal diagnostic development and assessment routines. This approach makes eXpress modeling uniquely suitable for analysis tasks in which a design will be updated or elaborated over time (a sore spot for traditional dependency modeling). The nature of the diagnostic models that are automatically generated by eXpress is largely dependent upon the type of data included in the eXpress model. For example, if an eXpress model contains asymmetric tests, object states or operating modes, then the resulting diagnostic model will be based on a multi-dimensional dependency model. If there are multiple design levels modeled in eXpress, then a hierarchical diagnostic model will be created. If both functional and failure information has been modeled within eXpress, then the automatically generated model will also be a Hybrid Diagnostic Model.
Model Verification – The process of evaluating a model to determine whether it meets identified specifications. Model Verification—which attempts to answer the question "Are we building the model right?"—confirms 1) the internal validity of a given model, and 2) that the model accurately represents the target system, device or process. Verification needs to be performed at the conclusion of each model phase to ensure requirements are being met.
Model Validation – The process of evaluating a model at the end of the development effort to ensure the model effectively meets the overall project objectives. Model Validation—which attempts to answer the question "Are we building the right model?"—confirms that a given model can be effectively applied to the task at hand (diagnostic design influence, diagnostic performance prediction, run-time diagnostic generation, etc.).
