| Alarm | A signal that some pre-set threshold or level has been exceeded. Alarms can be valid (True) or invalid (False). |
| Annotation | In eXpress, an annotation is an object that can be placed within a design without impacting its diagnostic and reliability characteristics. Annotations are non-functional objects that are used exclusively for annotating the design. |
| Ambiguity [7] | In fault isolation, an ambiguity exists when the failure(s) in a system have not been localized to a single diagnostic unit. |
| Ambiguity Group [7] | 1) The collection of all diagnostic units that are in ambiguity. 2) A collection of functions or failure modes for which diagnostics can detect a fault and can isolate the fault to that collection, yet cannot further isolate the fault to any subset of the collection. |
| Ambiguity Group Size | The number of unique repair items that are associated with the functions and failure modes that comprise a given ambiguity group. |
| Application Program Interface (API) | Provides a commonly used means of passing information between programs, in particular, between an application program and an operating system. APIs provide predefined calls for accomplishing this. |
| Assembly | 1) Two or more parts or subassemblies joined together to form a complete unit, structure, or other article. 2) In eXpress, an assembly is an object that inherits detailed lower-level designs into an upper-level design. An assembly is a component that has been hierarchically linked to a lower-level design. |
| Assessment | An estimate or determination of the value of a process against a scale of “goodness”. |
| Asymmetric Test | In eXpress, a test that, when it fails, indicts more than its coverage; a test that accounts for interference. |
| Asynchronous | Applies to computational or communication processes that operate independent of each other until they need to interact. When interaction is required, one process may interrupt the other. |
| Attribute, Object Attribute | In eXpress, A measurable physical or abstract property of an entity.An identifiable association between an object and a value. For example, an object (circuit card) may have a part number. The part number is an attribute assigned to the object. |
| Automatic Self-Test | Self-test to that degree of fault detection and isolation which can be achieved entirely under computer control, without human intervention. |
| Automatic Test | That performance assessment, fault detection, diagnosis, isolation, and prognosis which is performed with a minimum of reliance on human intervention. (MIL-STD-1309C) |
| Automatic Test Equipment (ATE) | Computer-driven hardware that has been designed to test integrated circuits. Sometimes referred to as “the tester.” |
| Availability | The probability a piece of equipment, subsystem or system when used under specified conditions, operate satisfactorily and effectively as required. Computed as uptime divided by both uptime plus downtime. Availability can be most easily improved by increasing Reliability or decreasing the Maintenance Turn Time. |
| Backlog Maintenance | Preventative Maintenance that is necessary to prevent the deterioration of the asset or its function, but which has not been carried out. |
| Baseline | A configuration identification document or a set of such documents, formally designated and fixed at a specific time during a configuration item’s life cycle. |
| Benign Failure | A failure whose severity is slight enough to be outweighed by the advantages to be gained by normal use of the system |
| Bidirectional Flag | In eXpress, a bidirectional flag is an I/O flag that represents bidirectional input/output to a design. An I/O flag with at least one bidirectional port or mixed input and output ports. |
| Bill of Materials | A listing of all subassemblies, intermediate parts, and raw materials that are needed to produce one unit of a finished product. |
| Birnbaum Importance Measure | As pertaining to Fault Tree Analysis (FTA), the Birnbaum Importance Measure (sometimes called Marginal Importance Factor) represents the degree to which changes to a particular element’s reliability impact the overall probability of critical failure. (See Notes 1&2 below) This metric is calculated in the eXpress FTA reports and is useful for identifying elements that are system-critical because they partially mitigate (are in the same minimal cut sets as) other, relatively likely failures. Note 1: For any element, the Critical Importance Factor can be derived by multiplying the Birnbaum Importance by the Individual Probability of Failure and then dividing it by the overall probability of critical failure. Note 2: For systems with a large number of failures, the calculation of the following metrics can be unreasonably time-consuming: Birnbaum, CIF, RAW & DIF. It is recommended that, for large systems, Contributing PoF, RRW or Fussel-Vesely be used instead (since these metrics are calculated more efficiently). |
| Black Box | A system or component whose inputs, outputs, and general function are known but whose contents or implementation are unknown or irrelevant. (See also white box, grey box, and glass box). |
| Block Diagram | A diagram of a system, computer, or device in which the principal parts are represented by suitably annotated geometrical figures to show both the functions of the parts and their functional relationships. (IEEE 610.12-1990) |
| Block Replacement | A method of repairing an isolated ambiguity group by replacing all suspected repair items as a block. |
| Bottom-Up | Pertaining to a method or procedure that starts at the lowest level of abstraction and proceeds towards the highest level. |
| Boundary Scan | A technique of testing dense electronics circuits created by the Joint Test Action Group (JTAG), whose name is often used synonymously with Boundary Scan, that creates “virtual test-points” on a board that does not have test point access physically built in. Boundary Scan was adopted as standard IEEE 1149.1. |
| Built-In Self-Test (BIST) | Tiny tester models that allow an integrated circuit to test itself. |
| Built-In Test (BIT) | An internal automatic or semiautomatic feature in a system or subsystem designed to detect, diagnose or isolate system failures by interrogating a system or monitoring system performance. |
| Built-In Test Equipment (BITE) | Any device which is part of an equipment or system and is used for the express purpose of testing the equipment or system. (MIL-STD-1388-1). Hardware which is identifiable as performing the built-In test function; a subset of BIT (MIL-STD-2165). |
| Can Not Duplicate (CND) | A fault indicated by BIT, or another sensor or health management reasoner, which cannot be confirmed at the first level of maintenance. (Compare with Retest OK). |
| Case Based Reasoning (CBR) | Case-based reasoning is a problem-solving methodology that finds solutions to new problems by analyzing previously solved problems, called cases. At the center of a CBR system is a collection of solved cases, a case-base. Given a new problem to be solved, the most similar problems from the case-base are retrieved. Their solutions may be directly applicable to the new problem, or some adaptation of the solution may be required to better fit the new problem. The proposed solution may then be reviewed by a subject matter expert, and if it is confirmed it is added to the case-base. |
| Case Study | A study designed to study intensely one set (or unit) of something as a distinct whole, with the goal of understanding the set as a distinct whole in its particular context. |
| Catastrophic failure [4] | Sudden, unexpected failure of a system resulting in considerable damage to the system and/or associated system or components. |
| Certification | The process of confirming that a system or component complies with its specified requirements and is acceptable for operational use. |
| Class | A construct of object-oriented programming. A class is the generalized description of the characteristics of objects which belong to the class. Subclasses may also be defined in order to build a hierarchical class structure. |
| Commercial Off-The-Shelf (COTS) | 1) Existing or previously developed commercial or military items. The use of COTS saves research and development costs, shortens fielding time and reduces the risk associated with new development. 2) A special case of non-developmental item (NDI) that has been developed to meet a commercial strategy and is available for general purchase. |
| Common Cause | 1) In diagnostics, an event or mechanism that can cause two or more failures or failure indications to occur simultaneously. 2) In safety and risk assessment, common cause can refer to a subset of dependent failures in which two or more component fault states exist at the same time, or within a short time interval, as a result of a shared cause. |
| Common Cause Analysis (CCA) | Common Cause Analysis in eXpress is used during fault isolation when diagnostics are generated under the Single-Fault Assumption, when it is assumed that only a single malfunction exists at the time that diagnostics are performed. More specifically, this inference rule assumes that all “failed” tests can be attributed to a single malfunction. |
| Common Cause Isolation | Also called Single Fault Isolation. A method of fault isolation that proceeds under the assumption that all “failed” tests in a diagnostic session are due to a single malfunction or fault. Although frequently used as the basis for diagnostic analyses (such as testability) during the design phase, common cause isolation cannot consistency produce accurate results when multiple components are simultaneously malfunctioning during diagnosis. The degree to which diagnostic accuracy suffers depends on the likelihood of multiple failures (taking into consideration the possibility of dependent failures and the length of the interval between diagnostic sessions) and the extent to which single failures can produce the same test signature as multiple failures. (Compare with Multiple Failure Isolation). |
| Common Mode Failure | A failure of apparently independent components or communication links due to an initiating event that affects them all. |
| Compatibility | (1) The ability of two or more systems or components to perform their required functions while sharing the same hardware or software environment. (2) The ability of two or more systems or components to exchange information (see Interoperability). |
| Compensating Features | Special inspections, tests, controls, instructions, drawing notes or other provisions applied to a single point failure mode item to improve reliability and lessen chances of failure. |
| Compensating Provisions | Actions that are available or can be taken to negate or mitigate the effect of a failure on a system. |
| Component | One of the parts that make up a system. An object in eXpress that contains internal port dependency definitions that establish the relationships between inputs and outputs. Components are the most basic of the five eXpress object types. |
| Computerized Maintenance Management System (CMMS) | A CMMS is software that helps maintenance teams keep a record of all assets they are responsible for, schedule and track maintenance tasks, and keep a historical record of work they perform. |
| Concept of Operations Document (CONOPS) | A document identifying the ways in which a system or piece of equipment will operate, including any limitations, restrictions, safety factors, reporting capabilities, etc. |
| Concept Phase | The identification and exploration of alternative solutions or solution concepts to satisfy a validated need. |
| Concurrent Engineering | 1) The application of multiple engineering disciplines to develop requirements in several different but related areas at the same time so the requirements and solutions are coordinated and mutually supportive. 2) An approach to product development that fosters a unified, collaborative effort by and integrates inputs from business, engineering, manufacturing, and management specialists across the traditionally segregated phases of product development. |
| Conditional Probability | The probability of an event, given that another event is known to have occurred. |
| Condition-Based Maintenance (CBM) | 1) A form of Predictive Maintenance initiated as a result of knowledge of the condition of an item from routine or continuous monitoring. 2) A maintenance philosophy in which equipment or system is maintained only when there is objective evidence of an impending failure. |
| Conditional Probability | The probability of an event, given that another event is known to have occurred. |
| Configuration Item (CI) | An item under development that is designated for configuration management. |
| Configuration Management (CM) | The process of evaluating, approving or disapproving and coordinating changes to configuration items. |
| Configuration Management Plan (CMP) | The document defining how configuration management will be implemented (including policies and procedures) for a particular acquisition or program. |
| Connector | A specialized object in the eXpress tool that is a cross between an I/O flag and a component. Like components, connectors have functions, attributes (including failure rates) and are considered by diagnostic and reliability calculations to be a possible source of failure. Like I/O flags, connectors have no port-to-port dependencies; every port on a connector is isolated. |
| Continuous Coverage | In eXpress, a test coverage that includes all upstream functions and / or failure modes that contribute to the measure behavior. |
| Contract Data Requirements List (CDRL) | A form used as the sole list of data and information which the contractor will be obligated to deliver under the contract. |
| Contributing Probability of Failure (PoF) | As pertaining to Fault Tree Analysis (FTA), the portion of a particular element’s individual Probability of Failure (PoF) that is included in the overall probability of critical failure. In the eXpress FTA module, this term is related to Q (unreliability) and is useful for identifying elements that, when they fail, are most likely to result in a critical failure. Note: For any element, the Fussell-Vesely Importance can be derived by dividing the Contributing Probability of Failure by the overall probability of critical failure. See Individual PoF and Fussell-Vesely Importance Measure. |
| Corrective Action | An identification or actions, automatic or manual, which can be taken to circumvent a failure. Also, a documented design, process, procedure, or materials change implemented and validated to correct the cause of failure or design deficiency. |
| Corrective Maintenance (CM) [3] | 1) Tasks that correct unsatisfactory conditions, restore lost functionality following a functional failure, or restore failure resistance. 2) A Maintenance Event performed in response to a failure. Also called Fault-Induced or Reactive Maintenance. Although this “run it until it breaks” maintenance mode is still practiced, it is very inefficient and contributes to not only a high life cycle cost and low operational availability, but also to the risk of possible damage through secondary failures. |
| Correlated or Sympathetic Failure | The inability of two or more items to perform their function as the result of some single event, thus possibly negating redundancy and acting as a single point failure mode. |
| Cost as an Independent Variable (CAIV) | An engineering approach in which analyses center around the ability to meet stated cost objectives. |
| Cost of Ownership (COO) | The purchase price of equipment plus the cost of operating this equipment over its projected life span. |
| CND (Could Not Duplicate) | A maintenance code which indicates that a particular fault condition which was registered during operation could not be reproduced during diagnostic testing. |
| Critical Design Review (CDR) | A review conducted to determine that the detailed design satisfies the performance and engineering requirements of the development specification. |
| Critical Importance Factor (CIF) | As related to Fault Tree Analysis, the Critical Importance Factor represents the expected degree to which a particular failure will impact the overall probability of critical failure. (See Notes 1&2 below). This metric is calculated in the eXpress FTA reports and is useful for identifying elements which should be treated as a priority for maintenance both due to their own unreliability and because they partially mitigate (are in the same minimal cut sets as) other, relatively likely failures. Note 1: For any element, the Critical Importance Factor can be derived by multiplying the Birnbaum Importance by the Individual Probability of Failure and then dividing it by the overall probability of critical failure. Note 2: For systems with a large number of failures, the calculation of the following metrics can be unreasonably time-consuming: Birnbaum, CIF, RAW & DIF. It is recommended that, for large systems, Contributing PoF, RRW or Fussel-Vesely be used instead (since these metrics are calculated more efficiently). |
| Criticality | A relative measure that combines both the consequences (i.e., severity) of a particular failure mode and its frequency of occurrence. |
| Criticality Analysis (CA) | A procedure by which each potential failure mode is ranked according to the combined influence of severity and probability of occurrence. |
| Criticality Matrix | A graphical representation of the failure mode and effects, usually graphed as probability of occurrence vs. severity level. |
| Cut Set | A qualitative analysis which includes a listing taken directly from the Fault Tree of the events, ALL of which must occur to cause the TOP Event to happen |
| Data Requirements List (DRL) | A list of data and information to which completion of an engineering effort is judged. |
| Deferred Maintenance | Preventative or Corrective Maintenance that has been deferred until a future budget cycle, or postponed until funds or parts become available. This leaves the system, by definition, in a partially degraded state, but one in which the system is Partially Mission Capable. |
| Degradation [4] | 1) Progressive failure. 2) The decline in a system or subsystem’s performance. |
| Degradation Analysis | Analysis involving the measurement and extrapolation of degradation or performance data that can be directly related to the presumed failure of the product in question. |
| Degraded Mode | A mode in which the system is Partially Mission Capable, due to either complete or partial failure of one or more components. This may be due to a range of performance parameters that fall outside the normal acceptance value but have not resulted in a fault condition. This degraded mode covers the parameter range of a time domain failure mode from the beginning of normal wear degradation to the limit of the operational acceptance. A degraded mode may be used both as a simulation parameter and to provide design knowledge for prognostics development. |
| Dependability | The probability that a system can be used to perform task when desired (including the impact of downtime due to any type of maintenance). |
| Dependency | The relationship between a given element (event or agent) and another element upon which it is causally dependent. The term is also used to refer to an individual element in its role as a cause of a given element (e.g., “agent x is a dependency of event z”). |
| Dependency Model | A representation of the causal relationships between events and the other elements (events and agents) that enable those events. Dependency models are comprised of multiple dependency statements that collectively represent the causal interrelationships within a system, device or process. |
| Dependency Modeling | The process of generating a dependency model by separately defining its constituent dependency statements. In many applications, the individual events and agents within a dependency model may be represented at such a low level that the model is most easily manipulated using higher-level constructs and abstractions (such as those used in Passive-Active Flow Modeling and Test Overlay Modeling). |
| Dependency Statement | A representation of the first-order and/or nth-order dependencies of a given event. Individual dependency statements almost never exist in isolation, but rather appear as constituent statements within a dependency model. |
| Derating | A method of altering the failure rate of a component based on stresses caused by operating the component beyond its specifications. |
| Design Phase | The period of time during which the designs for architecture, components, interfaces, and data are created, documented, and verified to satisfy requirements. |
| Design Review | A determination of the technical adequacy of the systems engineering and design efforts in meeting system requirements. |
| Design for Diagnosability (DFD) | The engineering discipline through which the integrated diagnostic capability of a system or device is developed, assessed and optimized to ensure the final product can be efficiently, effectively and accurately diagnosed. |
| Design for Test (DFT) | The practice of adding hardware hooks to integrated circuits in order to facilitate effective, inexpensive testing. |
| Design for Testability | The aspects of the product design process whose goal is to ensure that the testability of the end product is competently and sufficiently developed. |
| Detection | See “fault detection.” |
| Detection Mechanism | The means of methods by which a failure can be discovered by an operator under normal system operation or can be discovered by the maintenance crew by some diagnostic action. |
| Determinism, Deterministic | The ability to define a system as being in a single unique state; the exact state of the system is knowable. Contrast with stochastic, which applies to systems that have states that can only be described in a probabilistic sense. |
| Dependency | The relationship between a given element (event or agent as in the legacy DSI STAT tool) and another element upon which it is causally dependent. The term is also used to refer to an individual element in its role as a cause of a given element (e.g., “agent x is a dependency of event z”). |
| Dependency Model | A representation of the causal relationships between events and the other elements (events and agents as related to the legacy DSI STAT tool) that enable those events. Dependency models are comprised of multiple dependency statements that collectively represent the causal interrelationships within a system, device or process. |
| Dependency Modeling | The process of generating a dependency model by separately defining its constituent dependency statements. In many applications, the individual events and agents within a dependency model may be represented at such a low level that the model is most easily manipulated using higher-level constructs and abstractions (such as those used in Passive-Active Flow Modeling and Test Overlay Modeling). |
| Depot Level Maintenance | Maintenance in which the faulty SRU is tested to determine the cause of the malfunction. Faulty components are removed and replaced, and the SRU is verified ready for service by successful performance tests at the depot or sent to the factory for test and repair. In both two and three-level approaches to maintenance, D-Level Maintenance typically constitutes the last maintenance level. |
| DiagML | Diag-ML is a human-readable, open format, based on XML. The format is a non-proprietary language for describing diagnostic procedures, designs, tests and data and represents a superset of information, providing enough knowledge to re-reason diagnostic conclusions from the tests. |
| Diagnosis [2] | 1) identification of a particular evolving failure based on the observables sensed on a piece of mechanical equipment, 2) identify, localize, and determine the severity of an evolving fault condition. 3) The process of identifying the nature or cause of a phenomenon. |
| Diagnostic Accuracy | A measure of the ability of a diagnostic strategy or procedure to detect and isolate failures correctly across all of the potential fault combinations for a given system, device or process. Diagnostic Accuracy—which takes into consideration the possibility of simultaneously malfunctioning components—is expressed as the probability-weighted ratio of fault combinations for which all faults can be detected and isolated to fault groups that contain them, to the total number of possible fault combinations. (Compare with Isolation Accuracy) |
| Diagnostic Ambiguity | The situation that arises when diagnostics are able to detect a fault, but the smallest fault group to which that fault can be isolated contains more than one repair item. |
| Diagnostic Coverage | The ratio of failures detected (by a given test program, test procedure, or set of tests) to the entire theoretically-detectable failure population, expressed as a probability-weighted percentage. Also called Fault Coverage or Fault Detection Coverage. |
| 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. |
| Diagnostic Engineering | The engineering discipline through which the diagnostic capability of a system or device is developed, assessed and optimized. |
| Diagnostic Health Monitoring | A method of performing diagnostics in which status data (sensor readings, test results, etc.) gathered from a health management system (e.g., IVHM) is used as a batch to “seed” a dynamic diagnostic session, to automatically respond to tests in a static diagnostic procedure, or to develop a customized diagnostic procedure to be applied to the given fault combination. |
| Diagnostic Inference Engine | An inference engine that draws diagnostic conclusions. |
| Diagnostic Model | A model that supplements a topological or non-topological model with information about how different signals can be tested. |
| Diagnostic Procedure [7] | A structured combination of tasks, tests, observations, and other information used to localize a fault or faults. |
| Diagnostics, Prognostics & Health Management | A method to enable proactive maintenance decision-making. |
| Diagnostic Reasoner | A reasoning system used to perform diagnostics. |
| Diagnostic Sequence | In eXpress, a diagnostic sequence is a step-by-step troubleshooting path through a diagnostic tree. The path or sequence through the tree, is determined by test outcomes and results. |
| Diagnostics | 1) For a given field of application, the sum of all techniques associated with making assessments of the root cause of poor health. 2) The process of correlating the results of multiple tests to determine overall system status and generating hypotheses for maintenance and/or remediation. |
| Diagnostic Importance Factor | As related to Fault Tree Analysis, the Diagnostic Importance Factor (DIF) is the probability, given that a critical failure has occurred, that a particular element has failed. (See Notes 1&2 below) This metric is provided in the eXpress FTA reports and can be useful when prioritizing diagnostic activities. Note 1: For any element, the Diagnostic Importance can be derived by multiplying the Risk Achievement Worth by the Individual Probability of Failure. Note 2: For systems with a large number of failures, the calculation of the following metrics can be unreasonably time-consuming: Birnbaum, CIF, RAW & DIF. It is recommended that, for large systems, Contributing PoF, RRW or Fussel-Vesely be used instead (since these metrics are calculated more efficiently). |
| Diagnostic Inference | An inference pertains to the steps in reasoning, moving from premises to conclusions. It follows that Diagnostic Inference systematically relates failure effects to failure cause(s). A diagnostic reasoner correlates the results of one or more tests and produces a diagnosis based on the results of those tests. In the simplest case, this amounts to little more than a process of elimination. For example, if a failed test indicates that there is a fault within a set of three components and a passed test proves that two of those components are functioning properly, then the diagnostic reasoner can easily determine that the third component is faulty. More complex forms of inference allow the diagnostic reasoner to determine the status of a component based on tests at various levels of hierarchical indenture, mixed functional and failure-based testing, and different assumptions about the number of components that are simultaneously malfunctioning during diagnosis. |
| Diagnostic Session | The single application of a diagnostic procedure or diagnostic reasoner to diagnose a fault. (See also iterative diagnostics). |
| Diagnostic Strategy | The computational logic associated with making automated diagnostic assessments from a set of observations or data. |
| Discrete Coverage | Test coverage comprised only of functions and/or failure modes that are directly evaluated by a test. |
| Downstream | A term used to describe the topological relationship between a given element (event or agent) in a dependency model and another element that contains the given element among its nth-order dependencies (e.g., “a terminal event is downstream from those events and agents that have an effect upon it.”) |
| Downtime | The amount of time a system or equipment is unable to perform its expected function due to scheduled or unscheduled maintenance. |
| Durability | A measure of useful life. |
| Duty Cycle | The percentage of time that a system, device or component is active. |
| Dynamic Diagnostics | Diagnostics in which the order of testing is determined during run time based on the current mission objectives, component MTTFs, and available resources (test equipment, personnel). Fault groups are also developed dynamically, with the diagnostics interpreting each test as it is performed. Although dynamic diagnostics offer great flexibility and efficiency, they can only be verified inductively. (Compare with Static Diagnostics and Semi-Dynamic Diagnostics). |
| Embedded Diagnostics | Any portion of the system’s diagnostic capability that is an integral part of the prime system or support system. |
| Emergency Maintenance | Preventative or Corrective Maintenance carried out at the highest priority to prevent a critical situation from occurring or continuing to occur. |
| End Effect | In a FMEA, the consequence(s) of a failure mode on the operation, function, or status of the highest indenture level. (Compare with Local Effect and Next Higher Level Effect). |
| End of Useful Life [2] | that point in the failure evolution in which the owner would choose not to start the next mission if the true condition were known. |
| Engineering and Manufacturing Development (EMD) | That phase of acquisition during which the concepts validated in the previous phase are transformed to system and manufacturing process design. |
| Environment | A set of elements outside of the system, which may influence or may be influenced by the system. |
| Environmental Consequences [8] | A failure mode has environmental consequences if it causes a loss of function or other damage which could lead to the breach of any known environmental standard or regulation. |
| Equipment Lifetime [1] | Span of time over which the equipment is expected to fulfill its intended purpose. |
| Event | A phenomenon that follows and is caused by some previous phenomenon. One of the elements in a dependency model. |
| Expected Remaining Life | A prediction of the remaining useful life of a system/device. |
| Expert systems [2] | knowledge-based systems and information-based systems that can mimic many human decision making processes and are used to give advice, diagnose problems, and recommend solutions. Decision processes are modeled in a symbolic framework. |
| Explanation, Explanation Facility | A description of the algorithms and rules used to produce a diagnosis, health, or prognostic assessment. |
| Exponential Distribution | The most widely known and used distribution in reliability evaluation of systems, most often used where the rate at which events occur does not vary. A Weibull Distribution reduces to an exponential distribution when the beta (slope) parameter is set to 1.0. |
| EXPRESS [7] | A standard information modeling language developed by ISO 10303-11. |
| eXpress | eXpress is a comprehensive model-based diagnostics engineering software application providing an environment for the design, capture, integration, evaluation and optimization of complex or large-scale system diagnostics, prognostics health management (PHM), systems testability engineering, failure mode and effects analysis and system safety analysis. eXpress is uniquely suited to influence the diagnostic development for new designs or to exploit the diagnostic challenges of existing legacy systems. Its robust structure facilitates the capture of extensive interdisciplinary design knowledge providing an unmatched ability to corroborate, reuse and repurpose expert knowledge in performing standardized testability, reliability and maintainability analyses. |
| 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. |
| Extensible Markup Language | See “XML.” |
| External Diagnostics | Any portion of the entire system’s diagnostic capability that is not embedded. |
| Fail Operational | The ability to sustain a failure and retain sufficient operational capability for save mission continuation. |
| Fail Safe | The ability to sustain a failure and retain the capability to successfully terminate the mission. |
| 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 Analysis | The logical, systematic examination of a system to identify the probability, causes, and consequences of potential failures. |
| Failure Cause | The circumstances during design, manufacturing or use which have induced or activated a failure mechanism. The basic reason(s) for a failure. (Compare with Failure Mechanism). |
| Failure Distribution | A mathematical model that describes the probability of failure occurring over time. Also known as a probability density function (pdf), this function can be utilized to determine the probability that a failure takes place in a given time interval |
| Failure Effect | The consequences a failure has on the operation, function, or status of a device. (See also Object Failure Effect and Design Failure Effect). |
| Failure, Evident [8] | A failure which will eventually be detected when it occurs independent of other failures. |
| Failure, Functional [4,8] | Inability of an item to meet a specified performance standard. Failure is an event as distinguished from fault, which is a state. |
| Failure Latency | The elapsed time between fault occurrence and failure indication. (MIL-STD-2165) |
| Failure Mechanism | The physical, chemical, electrical, thermal or other process that results in failure. For a system, the failure mechanism is the process of error propagation following a component failure which leads to a system failure. (Compare with Failure Cause). |
| Failure Mode | 1) Defines the reason that a system/assembly/ component fails to meet its functional requirements (e.g. electrical short, broken, worn, loose, leaky). 2) 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 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. |
| Failure Modes and Effects Analysis (FMEA) [4] | 1) A structured procedure to determine equipment functions and functional failures. Each failure is assessed as to the cause of the failure and the effects of the failure on the system. The technique may be applied to a new system based on analysis or an existing system based on historical data. 2) An inductive, bottom-up method of analyzing the system effects of individual failure modes. |
| Failure Modes Effects and Criticality Analysis (FMECA) | A FMEA that also includes criticality calculations for each failure mode and the severity of effect of the failure. |
| Failure Modes Effects and Diagnostic Analysis (FMEDA) | A FMEDA is a systematic analysis technique to obtain subsystem / product level failure rates, failure modes and diagnostic capability. The FMEDA technique considers: • All components of a design, • The functionality of each component, • The failure modes of each component, • The effect of each component failure mode on the product functionality, • The ability of any automatic diagnostics to detect the failure, • The design strength (de-rating, safety factors) and • The operational profile (environmental stress factors). |
| Failure, Potential [8] | An identifiable physical condition which indicates that a functional failure is about to occur or in the process of occurring. |
| Failure Rate [4] | 1) The number of failures within a population, divided by the number of life units used by that population. 2) A function that describes the number of failures to a system, device or component that can be expected to take place over a given unit of time, most often expressed as the number of failures per million hours. It can be computed as the inverse of MTBF. |
| Failure Reporting and Corrective Action System (FRACAS) | A process by which failures are identified and analyzed so that corrective actions can be implemented back into the design and/or manufacturing process. |
| Failure Space | The space comprised of the set of entities (failure modes) describing how a system, device or process is expected to fail. |
| False Alarm [7] | 1) An indicated fault where no fault exists. 2) A warning reported by a diagnostic or health management system indicating the existence of an operational fault when that fault does not exist. False alarms can be reduced or sometimes completely eliminated by a full and accurate diagnostic analysis and validated run-time diagnostics / health management process. |
| False Alarm Rate (FAR) | The ratio of the number of alarms that have no identifiable anomaly/fault/failure associated with them to the total number of alarms over some period of time. |
| False Negative | A case when an alarm is not triggered, or a rule is not fired, but the actual system behavior would indicate that there is a fault, or a developing failure. |
| False Positive | The triggering of an alarm, or firing of a rule, when the actual system behavior would indicate that the action is not warranted. |
| False Removal | The removal of a good part suspected as being defective due to inconclusive diagnostics (e.g., diagnostic ambiguity), inaccurate diagnostic information, inefficient IETM information, or inadequate maintainer training. False removals contribute to high spares consumption, high turn-around times, low operational availability, and high RTOK rates. |
| Fault | 1) A defect or flaw in an agent (hardware, software, human, etc.) that results in a failure. 2) An operating condition or device state which is abnormal or unexpected. |
| Fault Avoidance | Actions taken to assure a fault cannot occur. |
| Fault Code | A identifier or code used to reference a detected fault or set of faults. |
| Fault Combination | The set of faults that exist at the time of a diagnostic session. |
| Fault Coverage | The ratio of failures detected (by a given test program, test procedure, or set of tests) to the entire theoretically-detectable failure population, expressed as a probability-weighted percentage. Also called Diagnostic Coverage or Fault Detection Coverage. |
| Fault Detection | 1) The identification of a problem in equipment, system or process, the classification of the operating condition or state as abnormal. 2) The process of identifying and reporting the presence of one or more faults within a system, device or process. |
| Fault Detection Coverage | The ratio of failures detected (by a given test program, test procedure, or set of tests) to the entire theoretically-detectable failure population, expressed as a probability-weighted percentage. Also called Diagnostic Coverage or Fault Coverage. |
| Fault Detection (FD) Metrics | Metrics that quantify the likelihood of a fault being detected, including Fault Coverage. |
| Fault Detection, Isolation and Remediation (FDIR) Metrics | Metrics that quantify the likelihood that a fault will be detected, isolated and remediated. |
| Fault Determination | the identification of the specific component or process state which is operating abnormally. |
| Fault Frequency [4] | A frequency associated with a specific fault, may be associated with a particular physical failure mode which the fault tracks. |
| Fault Group | A set of suspected faults (in terms of functions or failure modes) at some stage of a diagnostic session. (See also Isolated Fault Group) |
| Fault Injection | A technique whereby the effectiveness of tests and diagnostics can be assessed by creating a simulated fault in a design and seeing the effect of that simulated fault on circuit outputs, test results, and diagnostic conclusions. |
| Fault Isolation [7] | 1) The process of reducing the number of anomalies that comprise a diagnosis. Identification of an object of repair or anomalies to a degree sufficient to undertake an appropriate corrective action. 2) The process of determining the location of a fault to the extent necessary to effect repair. (MIL-STD-721C) |
| Fault Isolation (FI) Metrics | Metrics that quantify the likelihood of a fault being isolated to a single component. |
| Fault-Induced Maintenance | A Maintenance Event performed in response to a failure. Also called Corrective or Reactive Maintenance. Although this “run it until it breaks” maintenance mode is still practiced, it is very inefficient and contributes to not only a high life cycle cost and low operational availability, but also to the risk of possible damage through secondary failures. |
| Fault Localization [7] | The reduction of ambiguity by the application of tests, observations, or other information. The process of determining the approximate location of a fault. (MIL-STD-721C) |
| Fault Management | Those aspects of the system design which cover fault monitoring (detection), fault response, fault storage and fault annunciation, for both operational and maintenance purposes. |
| Fault Resolution | The process of resolving a fault, taking into account both the diagnostics (testing) and maintenance philosophy (replacement). |
| Fault Resolution (FR) Metrics | Metrics that quantify the likelihood of a fault being resolved with a single replacement. |
| Fault Template | A fault template consists of a list of fault codes or failures which are used as an entry point for a diagnostic / troubleshooting session. |
| Fault Tolerance | The built-in capability of a system to provide continued correct execution in the presence of one or more failures. |
| Fault Tree [7] | 1) An ordered arrangement of tests that are intended to lead to the localization of faults. 2) A tree-like representation of failure causes that can be used to determine the probability of the outcomes of those failures. |
| Fault Tree Analysis | An analysis approach in which each potential system failure is traced back to all faults that could cause the failure. It is a top-down approach, whereas the FMEA is a bottom-up approach. |
| Figure of Merit (FOM) | A method to score and compare testability effectiveness between more than one design. |
| First-Order Dependency | A dependency that represents a direct causal relationship (e.g. if agent x produces event z, we say that “x is a first-order dependency of z”). |
| Fully Mission Capable (FMC) | The system is in full working order, capable of performing any of its assigned missions. |
| Full-Order Dependency Statement | A dependency statement that represents all dependencies that are directly or indirectly responsible for a given event. |
| Function [4] | 1) The appropriate action of any equipment or part of a system. The actions and activities assigned to or required or expected of an equipment or system. 2) 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. |
| Functional Analysis | The process of identifying and determining performance of the functions necessary to achieve mission requirements. Also, the process of examining the characteristics of a defined function to identify all of the sub-functions necessary to the accomplishment of that function. |
| Functional Diagnostic Dependency Model | A functional diagnostic model that has been represented using a single or multi-dimensional dependency model. |
| 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 Failure Mode Effects Analysis (Functional FMEA or FFMEA) | A FMEA that identifies the potential impact of each functional failure mode on mission success. |
| Functional Hazard Analysis (FHA) | An analysis of the effects, risk, severity and probability of potential faults that is performed during the specification and design stages, typically before failure modes are identified. The FHA then becomes the baseline for the FMECA’s developed later. |
| Functional Testing | A testing methodology that focuses on the expected functionality of the item being tested (as opposed to focusing on failures reported by BIT). Also known as behavioral testing. |
| Fussell-Vesely Importance Measure | As related to Fault Tree Analysis (FTA), the Fussell-Vesely Importance Measure is the probability, given that a critical failure has occurred, that at least one minimal cut set containing a particular element contributed to that failure. (See Notes 1&2 below). This metric is calculated and provided in the eXpress FTA reports. Because this metric identifies the failures that most likely to lead to a critical failure, it is often used for the selection of candidates for improvement. Note 1: For any element, the Fussell-Vesely Importance can be derived by dividing the Contributing Probability of Failure by the overall probability of critical failure. Note 2: For any element, the Risk Reduction Worth can be derived from the Fussell-Vesely Importance using the following formula: RRW = 1/(1-FV). |
| Generalized Maintainer [2] | 1) the concept of a maintenance-oriented system designed to support human maintainers, enabling them to serve as “generalists” capable of maintaining/repairing a variety of systems and components. 2) A human maintainer who has been cross-trained as a “generalist” to perform maintenance and repair on a wide variety of systems and components with the help of Generalized Maintenance aids. |
| Glass Box | A system or component whose purpose or function is fully disclosed, yet for which implementation details are not available. Offers the diagnostic visibility of a white box, with the design protection of a black box. (See also grey box). In some arenas, the term glass box is used synonymously with white box. |
| Government Off the Shelf (GOTS) | an item typically designed and developed by the technical staff of the government agency for which it is created. It is sometimes developed by an externally but funded and specifications are provided by the government agency. |
| Grey Box | A system or component for which some, but not all, knowledge of how it behaves (beyond the interface) has been disclosed. A grey box stands in the middle ground between black boxes and white boxes. (See also glass box). |
| GUI (Graphical User Interface) | The software which comprises a graphical interface for I/O for the computer user. Also may be used to describe the hardware and software for a specialized I/O device. |
| Hardware Failure | The inability of the equipment to perform its expected functions due to a condition caused by operational, maintenance, physical or other environments. (Compare with Software Failure). |
| Health Management (HM) | The capability of monitoring real-time sensors to determine the health and performance of a system, subsystem, device or process. It may or may not be hosted on the system being monitored. |
| Hierarchical Diagnostic Inference | An inference about a function based on its relationship to functions at another indenture level. For example, if a function of an assembly is determined to be fully operational, then all child functions on components operating within that assembly can be inferred to be fully operational. Conversely, a function on an assembly can be inferred to be fully operational when all child functions on components within that assembly have been determined to be fully operational. |
| Hierarchy [2] | entities meaningfully treated as wholes comprise smaller entities which are themselves wholes. |
| 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). |
| Hierarchy of Systems [2] | A breakdown from the highest level of mechanical equipment integration to the lowest equipment constituent: Plant/Site/Platform, System, Subsystem, Assembly/Component, Element, Material. |
| Hybrid Diagnostic Inference | An inference about a function based on its relationship to failure modes that affect that function. Likewise, an inference about a failure mode based on its relationship to functions affected by that failure mode. For example, if a function is determined to be fully operational, then all failure modes that always or exclusively affect that function can be inferred to be non-present. Conversely, when all failure modes that can possibly affect a function have been determined to be non-present, then that function can be inferred to be fully operational. |
| 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. |
| Indenture Level | a designation which identifies an item’s relative complexity as an assembly or function. In a system, the first indenture level is the system. Examples of lower indenture levels could be system segments (level 2), prime items (level 3), subsystems (level 4), components (level 5), subassemblies or circuit cards (level 6), and parts (level 7). |
| Individual Probability of Failure PoF (Q) | The Individual Probability of Failure represents the likelihood that a particular element will fail within the specified exposure time. This metric is useful for identifying the elements that are most likely to fail. |
| Inference Engine | The component of a reasoning system that draws conclusions based on available information and knowledge. |
| Inherent Availability (AI) | The probability a system will be ready for operational use when required, based on the design characteristics only. Calculated as the ratio of mean time between downing events and the mean downtime (not including Logistics Delay Time). Compare with Operational Availability, which takes Logistics Delay Time into account. |
| Inherent Reliability [8] | With respect to a particular functional requirement, the level of reliability established by the design and by how the device is manufactured. |
| Initial Event | An event within a dependency model that is represented by a dependency statement that contains no dependencies. The initial events within a dependency model correspond to the inputs of the system, device or process that is represented by that model. |
| Integrated Diagnostics (ID) | A structure design and management process to achieve the maximum effectiveness of a system’s diagnostic capability by considering and integrating all related pertinent diagnostic elements. The process includes interfaces between design, engineering, testability, reliability, maintainability, human engineering, and logistic support analysis. |
| Integrated Electronic Technical Manual (IETM) | A tool providing information a technician needs to perform a maintenance action, including (but not restricted to) test and repair procedures, parts information and theory. The U.S. DoD has identified the following six classes of IETM: Class 0 (Print or hardcopy) Paper tech manuals with multiple volumes that are not linked or integrated. The maintainer uses an index or table of contents to find data. Use of a Class 0 IETM typically results in high false removal rates. Class 0 IETMs are difficult to update and maintain. Classes I / II Page-turning/scrolling documents with some indexing and hyperlinking. The maintainer searches for data. Use of a Class I or II IETM often results in high false removal rates. Class III SGML or XML tagged documents, with some level of intelligence added, hyperlinking through a linear structure. The maintainer searches for data. Use of a Class III IETM often results in high false removal rates. Class IV Tech manuals authored directly into a database for interactive electronic output. Typically organized hierarchically, this class of IETM is authored for maximum viewing ease. With the use of a Class IV IETM, false removal rates are minimized. Class V an IETM linked to or embedded within the equipment’s operating system and/or maintenance network, integrating with equipment diagnostics and dynamic diagnostic test strategies to expedite troubleshooting, spares ordering, and maintenance planning. The use of a Class V IETM minimizes false removal rates and increases equipment availability. |
| Integrated Health Management | A health management process that has been integrated into the system, or device whose health is being monitored/managed. |
| Integrated Vehicle Health Management (IVHM) | Vehicle health management. A term first used by NASA to indicate the integrated health management system on a space vehicle. |
| Intermittent Fault | A fault which is indicated sporadically over a period of time. |
| Intermediate Maintenance (I-Level Maintenance) | Maintenance in which the malfunctioning assembly is tested to determine the cause of the malfunction and isolate the failure to a SRU. Repair is effected by removal and replacement of the faulty SRU and successful performance of the LRU to verify that it is ready for service. In three-level approaches to maintenance, I-Level Maintenance (which is sometimes called shop-level maintenance) is typically the second level of maintenance. In two-level approaches to maintenance, this level is sometimes eliminated. |
| Internal Output Flag | In eXpress, an output flag connected to a net that is connected to at least one input, control or bidirectional part on another object. Although an internal output flag can be represented as an event within a dependency model, it cannot be represented as a terminal event. |
| Interoperability | The ability of two or more systems or elements to exchange information and to use the information that has been exchanged. |
| Interval Based Maintenance | See “Preventive Maintenance.” |
| Input Flag | In eXpress an I/O flag is used to represent a design input. An I/O flag with only output ports. |
| I/O Flag | An eXpress object that describes how signals enter or leave a design. An I/O flag represents an input or output of a design. I/O flags differ from connectors in that diagnostic and reliability calculations exclude them as a source of failure. The ports on an I/O flag have no inter-dependencies. |
| Isolated Fault Group | A fault group that represents the final results of a diagnostic session. In testability analysis, an isolated fault group is referred to as an ambiguity group. |
| Isolation Accuracy | A measure of the ability of a diagnostic strategy or procedure to isolate detected failures correctly across all of the potential fault combinations for a given system, device or process. Isolation Accuracy—which takes into consideration the possibility of simultaneously malfunctioning components—is expressed as the probability-weighted ratio of fault combinations for which all detected faults can be detected and isolated to fault groups that contain them, to the total number of possible fault combinations containing at least one detected fault. (Compare with Diagnostic Accuracy) |
| Iterative Diagnosis | The process of diagnosing a system by iteratively running a diagnostic engine and taking the appropriate corrective action for the fault identified by each iteration. Iterative diagnostics do not attempt to isolate all known failures with each iteration, but rather to isolate a single failure to the extent necessary to effect repair. |
| Lambda Search | 1) An ordered approach used when diagnostic tests are not able to isolate the failure to a single item and systematic removal and replacement begins with the highest failure rate item (based on reliability or historical data) in the group. Troubleshooting proceeds until the failure item has been replaced. 2) A method for prioritizing the replacement of repair items in an isolated ambiguity group, based on isolated failure probability. Testability analyses often include both fault isolation metrics (based on testing only, without the use of lambda search) and fault resolution metrics (which take into consideration both testing and serial replacement prioritized using a technique like lambda search). |
| Level of Maintenance | The enterprise level at which diagnostics can operate (e.g., maintenance depot, factory, in the field). |
| Life Cycle | the life cycle of a system includes the design & development phase, the production, test and deployment phase and the operational / sustainment phase. |
| Life Cycle Cost (LCC) | The total cost of acquisition, owning, operating, and maintaining a system over its useful life, including such costs as fuel, energy, labor, maintenance, repair and replacement components. Includes the costs associated with end of life disposal. |
| Life Cycle Cost Analysis | The object of LCC analysis is to choose the most cost-effective approach from a series of alternatives so the long-term cost of ownership is minimized. LCC analysis helps engineers justify equipment and process selection based on total costs rather than the initial purchase price of equipment or projects. http://www.barringer1.com/lcc.htm |
| Life Unit | A generic term for a standard time-based or event-based unit of measure, against which operational conditions are evaluated. Typical life units include flying hours, operating hours, sorties and calendar or clock time. |
| Likelihood | Synonym for probability. |
| Limit Checking | The periodic process of comparing operating states (conditions) to preset limits or alarm values. |
| Line Replaceable Unit (LRU) | A component within a system where all of the maintenance actions required to replace component can be performed without having to return the system to a maintenance facility. Typically, this requires that the maintenance actions do not require heavy industrial tools. |
| Local Effect | In a FMEA, the consequence(s) of a failure mode on the operation, function, or status of the specific item being analyzed. (Compare with Next Higher Level Effect and End Effect). |
| Logic Modeling (LogMod) | The name used by Ralph A. De Paul, Jr. to refer to the causal modeling technique that he invented in the 1950s and which would later become known as dependency modeling. |
| Logistics Footprint | Typically the Logistics Footprint refers to the size of ‘in theater’ (operationally deployed) logistics support needed to move and sustain a warfighting force. The footprint includes all the necessary support needed to maintain the force such as fuels, parts, support equipment, transportation, and people. |
| Logistics Delay Time | The downtime incurred as a result of waiting for equipment, facilities or other logistics resources to become available in order to support a maintenance event. |
| Logistics Requirements | Equipment, facilities, personnel, technical data or other resources required to support the maintenance concept. |
| Logistics Related Reliability | The probability that no corrective (or unscheduled) maintenance, unscheduled removals, and/or unscheduled demands for spare parts will occur following the completion of a specific mission profile. |
| Logistics Reliability | The ability of a system to perform failure free, under specified operating conditions and time without demand on the support system, measured as a mean time between maintenance actions. Also, a measure of a system’s ability to operate without logistics support. All failures, whether the mission is or can be completed, are counted. |
| Logistics Supports Analysis (LSA) | A systems engineering and design process selectively applied during all life cycle phases of the system/equipment to help ensure supportability objectives are met. (MIL-STD-1785) |
| Lognormal Distribution | A failure distribution similar to the Normal distribution except that the logarithm of the values of random variables, rather than the values themselves, are assumed to be normally distributed. |
| LSA Record (LSAR) | That portion of LSA documentation consisting of detailed data pertaining to the identification of logistic support resource requirements of an equipment. |
| Maintainability [4] | 1) The ability of an item to be retained in, or restored to, a state in which it can perform the required function(s). 2) Describes the ease with which an item to be retained in, or restored to, a specified condition when maintenance is performed by personnel having specified skills using prescribed procedures and resources at each prescribed level of maintenance and repair. See also Software Maintainability. |
| Maintenance [2] | 1) All routine and extraordinary actions necessary to keep the systems and their components in reliable working order to maximize operational availability. 2) All actions necessary for retaining an item in or restoring it to a specified condition. |
| Maintenance Action | One, of possibly many, elements of a maintenance event. |
| Maintenance Event | The performing of those maintenance actions, including troubleshooting and diagnostics, required to restore a system to working order. |
| Maintenance Event Time | The sum of unscheduled and scheduled maintenance action times spent on a specific maintenance event. |
| Maintenance Hours per Life Unit | The maintenance hours required divided by the appropriate life unit. |
| Maintenance Planning | An systematic planned approach to ensure all maintenance events and activities throughout the life cycle of the system are accounted for and that required resources, manpower, facilities, spares, training, etc. are allocated and in place when needed. This planned approach is usually captured and documented in a Maintenance Plan |
| Maintenance Ratio | A measure of the total maintenance manpower burden required to maintain a system. The ratio is expressed as the cumulative number of man hours of maintenance expended divided by the cumulative number of end item operating hours during the same time. |
| Maintenance Repair Level | Depending on the maintenance concept, equipment or systems may typically be repaired within a 2 or 3 level maintenance infrastructure. Two level maintenance consists of Organizational and Depot repair while Three level maintenance includes an Intermediate repair level; Organizational>Intermediate>Depot |
| Maintenance Schedule | A predetermined schedule, set of intervals, or by which maintenance events are carried out. |
| Maintenance Tracking | An established methodology and system to track, record and trend maintenance actions and activities whether they are unscheduled/unplanned or scheduled/planned events. |
| Maintenance Turn Time | The time required to service and return to a system to mission-ready. This includes any setup required to prepare the system for its next mission. |
| Maintainers [2] | Generally considered to be humans who are charged with maintaining systems or equipment (see “Generalized Maintainer” and “Personalized Maintainer.” |
| Mean Downtime (MDT) | The average elapsed time between losing Mission Capable status and restoring the system to at least partially mission capable status. Calculated as the ratio of total downtime over the number of downing event smost often, the total maintenance time over the number of maintenance events. |
| Mean Mission Duration (MMD) | For on-orbit space systems, the average time the system is operational before a missional critical failure occurs. The mean mission duration is equivalent to mean time to failure for non-repairable ground systems. |
| Mean Repair Time (MRT) | The average corrective maintenance time in an operational environment, calculated as the total corrective maintenance time over the number of corrective maintenance events. |
| Mean Time Between Critical Failure (MTBCF) | The mean time between failures of mission-essential functions, calculated as the ratio of active hours (those excluding scheduled maintenance) and the number of critical failures. |
| Mean Time Between Downing Events (MTBDE) | A measure calculated as the total uptime over the number of downing events. |
| Mean Time Between Failures (MTBF) | 1) For a large sample population, MTBF represents the mean time between subsequent failures. MTBF is typically applied to replaceable components. 2) The mean equipment operating time between failures of any type, calculated by dividing uptime by the total number of failures. |
| Mean Time Between Maintenance Actions (MTBMA) | A ratio of the total uptime over the number of scheduled and unscheduled maintenance events. |
| Mean Time Between Preventative Maintenance (MTBPM) | A ratio of the total uptime over the number of preventative maintenance events. |
| Mean Time Between Repairs (MTBR) | For a large sample population, MTBR represents the mean time between repair tasks. Repair tasks may include: on-condition, scheduled, and unscheduled repairs. |
| Mean Time Between Scheduled Maintenance (MTBSM) | A ratio of the total uptime over the number of scheduled maintenance events. |
| Mean Time Between Unscheduled Maintenance (MTBUM) | A ratio of the total uptime over the number of unscheduled maintenance events. |
| Mean Time to Failure (MTTF) | A system, subsystem or device’s mean time to failure, as calculated at a specific point in time. This differs from MTBF in that it changes over time as the system is maintained. |
| Mean Time to First Failure (MTTFF) | The Mean Time to Failure starting from when the system is first made to be Mission Capable. |
| Mean Time to Isolate (MTTI) | The mean time to perform fault isolation on a system. MTTI is a factor in the overall MTTR and can affect operational availability. |
| Mean Time to Repair (MTTR) | The total amount of time spent performing all corrective maintenance repairs divided by the total number of those repairs. The reliability weighted mean of repair times for an operational end item This includes test time, access time, fault isolation time, remove and replace or repair time, checkout time, and access secure time. |
| Metrics | A set of parameters against which the performance of a system (or piece of equipment) is judged. |
| Military Off the Shelf | an existing item designed and in service in other military projects. Also called Non-Developmental Item. |
| Minimal Cut Set | A listing, derived from the Fault Tree Cut Sets and reduced by Boolean Algebra, which is the smallest list of events that is necessary to cause the Top Event to happen. |
| Mission | A particular business (enterprise), technological or military objective, or a combination of related objectives. |
| Mission Capable (MC) | An assessment of a system’s ability to perform its required tasks, in either a Fully Mission Capable (FMC) or Partially Mission Capable (PMC) status. |
| Mission Life Prediction [2] | The prediction with a pre-defined probability that a particular equipment item in a weapons system will complete the next mission. |
| Mission Planning | The process by which the current capability of business (enterprise) assets is compared with the high-level business (enterprise) objectives, in order to optimally schedule tasks, and to optimize the assignment of assets to those tasks. |
| Mission Readiness | The ability of an organization to assign qualified assets to a given mission at a given point in time. |
| Mission Reliability | The probability that the system is operable and capable of performing its required function for a stated mission duration or for a specified time into a mission. (Compare with Basic Reliability and Logistics Reliability). |
| Mixed Weibull Distribution | A variation of the Weibull Distribution used to model data with distinct subpopulations that may represent different failure characteristics over the lifetime of a product. Each subpopulation has a separate Weibull parameters calculated and the results are combined in a mixed Weibull distribution to represent all of the subpopulations in one function. |
| Model Based | An approach to condition monitoring, diagnostics, or prognostics, in which a physical model of a system is used as a basis of the assessment to be made. |
| Model-Based Diagnostics | Diagnostics performed using a Model-Based Reasoner. Not to be confused with diagnostics based on a Diagnostic Dependency Model. |
| Model-Based Reasoner (MBR) | An algorithm that creates diagnostic conclusions by comparing measured values against propositions created from a model that is dynamically adjusted to match changes to the system. |
| 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.). |
| 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. |
| Monte Carlo Simulation | A method of generating values from a known distribution for the purposes of experimentation. This is often accomplished by generating uniform random variables and using them in an inverse reliability equation to produce failure times that would conform to the desired input distribution. |
| Multi-dimensional Dependency Model | A dependency model that contains multiple, alternative sets of dependency statements (or a single set of dependency statements that are modified dynamically) in order to support conditional causality. In a diagnostic application, a multi-dimensional dependency model can be used to represent test asymmetry and changes to dependencies that result from system state dynamics. Not to be confused with multi-signal modeling. |
| Multi-Purposing | The proactive re-purposing (planned use of data, information & knowledge) in multiple efforts and tasks. These can include all phases of the life cycle including design, development, production, test, deployment, sustainment and decommissioning. For example, the use of attributes in the eXpress modeling tool can provide “hooks” or gateways to use the same data created during the design phase and then transitioned (re-purposed) to the sustainment phase to support optimized diagnostics and troubleshooting procedures. |
| Multiple Failure | The failure of two devices which have the same (or redundant) function in a system. |
| Multiple-Failure Isolation | A method of fault isolation that takes into consideration the possibility of multiple, simultaneous malfunctions during diagnostics. The likelihood of multiple faults existing during diagnostics is influenced by several criteria: the failure rates associated with individual faults, the likelihood of dependent failures, and the length of the time interval between diagnostic sessions. The diagnostic accuracy of procedures that incorporate multiple-failure isolation is generally higher than those based on common cause isolation. Although multiple-failure isolation can result in greater diagnostic ambiguity than does common cause isolation, the ambiguity groups that result from multiple-failure isolation often lend themselves to prioritized replacement, thereby negating or reducing the effect of multiple-failure isolation upon diagnostic performance. |
| 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. |
| Negative Failure Space | A failure space that is comprised of a set of failure modes that represent the absence of specific functions. |
| Negative Function Space | A function space that is comprised of a set of functions that represent the absence of specific failure modes. |
| Next Higher Level Effect | In a FMEA, the consequence(s) of a failure mode on the operation, function, or status of the items in the next indenture level above the indenture level under consideration. (Compare with Local Effect and End Effect). |
| Nth-Order Dependency | A dependency that represents an indirect causal relationship (e.g. if agent w generates event x which triggers agent y to produce event z, we say that “w is a nth-order dependency of z”). |
| Non-Developmental Item (NDI) | an existing item designed and in service in other military projects. Also called Military Off-the-Shelf. |
| 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. |
| Normal Distribution | A widely used distribution that is symmetric, allowing the curve to be defined by a mean and a standard deviation. |
| Noise | Any signal content which does not aid in the detection or analysis of the phenomenon under study. Sometimes referred to as signal interference. |
| Object | An eXpress symbol that has been added to a design. Although they are created from symbols, objects differ in that they possess additional characteristics that are automatically added as they are added to a design. There are five types of objects: components, assemblies, connectors, I/O flags and annotations. |
| Off-line Testing | The testing of an item with the item removed from its normal operational environment. A testing approach that requires a system to be taken out of service while tests are performed. |
| On-Condition Maintenance [8] | condition assessments are used to detect potential failures, so that action can be taken to prevent the functional failure, or to avoid the consequences of the functional failure. |
| On-line Testing | The testing of a system item using active processing to detect faults while the system as a whole continues to provide its normal services. |
| Operating & Support (O&S) | The phase of a system’s life cycle during which it is operated and maintained. |
| Operational Availability (Ao) | The probability a system will be ready for operational use when required in an operational environment. Calculated as the ratio of mean time between downing events and the mean downtime (including Logistics Delay Time). Compare with Inherent Availability, which does not take Logistics Delay Time into account. |
| Operational Dependability (Do) | The ratio of the Mean Time Between Critical Failures (MTBCF) over the sum of the MTBCF and the Mean Time to Restore Function (MTTRF). This measure is used to determine the degree to which the system satisfies the need for critical management information. |
| Operational Effectiveness | The ratio of successful missions and the total number of missions attempted. |
| Operational Maintenance (O-Level Maintenance) | Maintenance in which the repair action consists of the removal and replacement of the malfunctioning assembly (LRU, black box, equipment). In both two and three-level approaches to maintenance, O-Level Maintenance typically constitutes the first level. |
| Operational Sustainability | A measure of the degree to which a system can continue to maintain the necessary level of support for a specified duration of operations beyond its initial deployment period. |
| Operational R&M | The reliability and maintainability achieved in actual use. |
| Operational Readiness | The probability that the system is operating satisfactorily at any point in time, excluding downtime for scheduled maintenance or training. |
| Output Flag | In eXpress an I/O flag is used to represent a design input. An I/O flag with only input ports. |
| Partially Mission Capable (PMC) | The system is operating in an impaired condition. It can perform at least one, but not all of its assigned missions. |
| 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 and end users. |
| Periodic (or Scheduled) Maintenance | A form of Planned Maintenance where the prescheduled events are predictably spaced throughout the system’s life unit, typically at intervals of time or number of operations. |
| Pipelines Spares | The spares in a logistics supply chain (on-the-self, in-transit, in-repair, etc.) that will provide sufficient replacement quantities, reduce equipment/system downtime and support the operational availability requirement. For example, the spares in the pipeline between the intermediate maintenance level and the depot repair facility must balance with the number of failures and the amount of cycle time for the repaired spare to available for replacement. |
| Planned Maintenance | A form of Preventative Maintenance characterized by maintenance events that are prescheduled that prevent one or more failure mechanisms from occurring. |
| Predictive Maintenance | A form of Preventative Maintenance where maintenance is only performed when a failure is predicted to be highly probable and imminent, in an attempt to achieve the maximum availability without impacting mission reliability. Predictive Maintenance typically makes use of equipment maintenance records to focus attention on key failures that lead to equipment availability and downtime. The field of Predictive Maintenance is currently being reassessed through the development of Prognostics to more accurately predict failures based on time domain failure trends. |
| Preventative Maintenance (PM) | A Maintenance Event performed prior to a failure in order to prevent its occurrence. May be based on Scheduled or Predictive Maintenance. Preventative Maintenance is employed to increase mission reliability, at the expense of availability and (arguably) maintenance costs. Preventative maintenance is planned so that any required resources are available. |
| Prioritized Replacement | Also called Serial Replacement. A method of repairing an isolated ambiguity group by replacing suspected repair items one at a time and then retesting to determine if a fault has been corrected. Prioritized replacement is used to improve maintenance costs (sometimes at the expense of a higher Mean Time to Repair). |
| Proactive Maintenance | Activities and actions applied to environment prior to and during operations to prevent problems, gain greatest reliability, and minimize failure. (Compare with Preventative Maintenance). |
| Probabilistic-Based Risk Assessment (PBRA) | An approach for documenting risk profiles based on the failures. Also referred to as Probabilistic Risk Assessment (PRA) |
| Probabilistic Risk Assessment (PRA) | An approach for documenting risk profiles based on the failures. Also referred to as Probabilistic-Based Risk Assessment (PBRA) |
| Probability Density Function | A mathematical model that describes the probability of failure occurring over time. This function can be utilized to determine the probability that a failure takes place in a given time interval. |
| Probability of Failure (PoF) | The likelihood that a system, assembly or component will fail within the specified exposure time. In the eXpress FTA module, this term is related to Q (unreliability) and is useful for identifying elements that are most likely to fail. See Individual PoF and Contributing PoF. |
| Prognostics, or Predictive Diagnostics | The process of predicting the occurrence of failures to a system, device or process based on predictable time domain failures (such as mechanical wear). This is in contrast to non-time domain, random failures that cannot be prognosed using known technology (such as electronic failures). |
| Prognostic Health Management (PHM) | An approach to Health Management that incorporates prognostic, as well as diagnostic, techniques. |
| Portability [6] | An application running on a platform developed by one manufacturer should be able to be ported directly to a different platform implemented by a different manufacturer. |
| Predictive Diagnostic | The prediction that a particular failure mode will occur in the future. |
| Predictive Maintenance [4] | A type of condition-based maintenance emphasizing early prediction of failure using non-destructive techniques such as vibration analysis, thermography, and wear debris analysis. The first objective is to predict when equipment failure may occur, and secondly, to prevent occurrence of the failure by performing maintenance in advance of the failure(s). Monitoring using sensors, threshold analysis and performance trending for future failure allows maintenance to be planned before the failure occurs. |
| Preventive Maintenance (PM) [1,8] | Maintenance which is conducted at scheduled intervals established to avoid failure based on statistically anticipated lifetime. Includes on-condition tasks, restoration tasks, and discard tasks. |
| Probabilistic Risk Assessment (PRA) | Provides a systematic approach for transforming failures, termed initiating events, into risk profiles. The PRA provides the resulting probabilities of each risk. http://www.innovsw.com/pra.htm |
| Probabilistic Safety Assessment (PSA) | Provides a systematic approach for transforming safety related failures into risk profiles. The PSA provides the resulting probabilities of each risk. http://www.innovsw.com/pra.htm |
| Probability [11] | Probability is a weight (a real number ranging from 0 to 1) that evaluates the likelihood of the occurrence of an event. |
| Prognosis [2] | A reliable and sufficiently accurate prediction of an event of interest (e.g., the remaining operational time to end-of-useful life of equipment in service). |
| Prognostics | The technology associated with projecting from a current operational state of health, to a future state of health. |
| Protocol [7] | A set of conventions or rules that govern the interactions of processes or applications within a computer system or network. |
| Rayleigh Distribution | A Weibull distribution whose beta (slope) value is equal to 2.0. |
| Readiness | The ability of the system to perform the tasks, for which it was designed, without unacceptable delays. |
| Reactive Maintenance (RM) | A Maintenance Event performed in response to a failure. Also called Fault-Induced or Corrective Maintenance. Although this “run it until it breaks” maintenance mode is still practiced, it is very inefficient and contributes to not only a high life cycle cost and low operational availability, but also to the risk of possible damage through secondary failures. |
| Real Time Diagnostics | A type of diagnostic algorithm that generates diagnostic conclusions rapidly enough to provide an immediate benefit to a system during operation. Where algorithms become too complex for real-time response, predictive diagnostics can be used to supplement the process. |
| Reasoning System | A system that can combine elements of information and knowledge to draw conclusions. (IEEE 1232-2002) |
| Redundancy | The existence of backup equipment that can be used to perform primary functions, in the event that the primary equipment should fail. Also, the existence of more than one way of performing a function. |
| Relevant Failure | Anything that affects functional performance. |
| Reliability (R) | The probability that a system will perform satisfactorily for a given time when used under specified operating conditions. More generally, reliability is the capacity of parts, components, equipment, products and systems to perform their required functions for desired periods of time without failure, in specified environments and with a desired confidence. (See also Basic Reliability and Mission Reliability). Also, the engineering discipline concerned with predicting, monitoring, testing, and improving the reliability of a system, device or process. |
| Reliability, Availability & Maintainability (RAM) | A requirement imposed on acquisition systems to ensure they are operationally ready for use when needed, will successfully perform assigned functions, and can be economically operated and maintained within the scope of logistics concepts and policies. May also refer to a function organization or group with disciplines in the specialty engineering domains. Other variations are RMA, RMAT, RM&T. |
| Reliability (Basic Reliability) | The duration or probability of failure-free performance under stated conditions. (Compare with Logistics Reliability and Mission Reliability) |
| Reliability Analysis | A quantification of the sources of failures in a system, with emphasis on the most significant contributors towards the overall system unreliability, in order to correct them and therefore improve the reliability of the fielded system. |
| Reliability Block Diagram (RBD) | A diagram the represents how the components (represented by “blocks”) are arranged and related reliability-wise in a larger system. This is often, but not necessarily, the same as the way that the components are physically related. |
| Reliability Centered Maintenance (RCM) [8] | A process used to determine what must be done to ensure that any physical asset continues to fulfil its intended functions in its present operating context. |
| Reliability Distribution Curve | A curve that characterizes the changes to the probability of failure over time. |
| Reliability Engineering | The set of design, development and manufacturing tasks by which reliability is achieved. |
| Reliability Growth | The improvement in a reliability parameter caused by successfully correcting design or manufacturing deficiencies. |
| Reliability Prediction | The primary calculation in Reliability Analysis, referred to as the Failure Rate or number of failures during a period of time. |
| Remediation | The act of correcting an operational failure through switching to a redundant system or a comparable function, or changing the operational characteristics (such as a mission plan). Maintenance of the failure functional item is deferred to a more suitable time (such as during ground support). |
| Remote Diagnostics | A type of external diagnostics where the diagnostic decision-making is done remotely to where the testing is performed. |
| Repair Item | One or more parts considered as a single part for the purposes of replacement and repair due. |
| Repair Time | The corrective maintenance time, calculated as either a mean or maximum time, that is required to return a system or part to operational status. Repair time includes set-up, access, troubleshooting, disassembly, repair, reassembly, repair verification, system test, and readying procedures. |
| Replaceable Unit [7] | A collection of one or more parts considered as a single part for the purposes of replacement and repair due to physical constraints of the unit under test (UUT). |
| Resource [7] | Any capability that must be scheduled, assigned, or controlled by the underlying implementation to assure non-conflicting usage by processes. |
| Restoral Time | The maximum maintenance downtime incurred as part of restoring a system to Mission Capable status. |
| Retest OK (RTOK) | A maintenance event where the failure that triggered the event performs satisfactorily at the off-equipment maintenance level, or at the next higher level of maintenance. As a result of this event, personnel may return the item to service without taking corrective action. The RTOK rate is the percentage of items removed from an end item as a result of BIT or another sensor or health management reasoner, that subsequently pass all related testing at the next maintenance level. (Compare with Can Not Duplicate). |
| Request for Proposal (RFP) | A formal process by which the government asks contractors to submit proposals for satisfying a procurement or acquisition requirement. |
| Risk Achievement Worth (RAW) | As related to Fault Tree Analysis (FTA), the Risk Achievement Worth (sometimes called Risk Increase Factor) represents how much the probability of critical failure increases when a particular element fails. (See Notes 1&2 below). This metric is calculated in the eXpress FTA reports and is useful for identifying elements that should be prevented from failing using prognostics, planned maintenance or some other failure avoidance method. Note 1: For any element, the Diagnostic Importance can be derived by multiplying the Risk Achievement Worth by the Individual Probability of Failure. Note 2: For systems with a large number of failures, the calculation of the following metrics can be unreasonably time-consuming: Birnbaum, CIF, RAW & DIF. It is recommended that, for large systems, Contributing PoF, RRW or Fussel-Vesely be used instead (since these metrics are calculated more efficiently). |
| Risk Assessment [4] | The process of balancing risk with cost, schedule, and other management considerations; consists of identifying risks, assessing those risks, determining a course of action and tracking the effectiveness of the decision. |
| Risk Decrease Factor (RDF) | See Risk Reduction Worth (RRW) |
| Risk Increase Factor (RIF) | See Risk Achievement Worth (RAW) |
| Risk Priority Number (RPN) | A Risk Priority Number is a numeric assessment of the risk assigned to a process or steps in a process as part of FMEA in which a team assigns each failure mode number a value that quantifies the likelihood of occurrence, occurrence of detection or severity of impact. |
| Risk Reduction Worth (RRW) | As related to Fault Tree Analysis (FTA), the Risk Reduction Worth (sometimes called Risk Decrease Factor) represents how much the probability of critical failure decreases when it is presumed that a particular element will not fail. (See Note below). This metric is calculated in the eXpress FTA reports and is useful for identifying areas of the design that, if they were either improved or maintained aggressively, would result in the greatest reduction of risk. Note: For any element, the Risk Reduction Worth can be derived from the Fussell-Vesely Importance using the following formula: RRW = 1/(1-FV). |
| Robustness | Defines the general usefulness of an algorithm (diagnostic/prognostic approach) for a problem or problems, subject to variations in the operating parameters. |
| Root Cause | A fundamental cause of failure of a machine, system, or piece of equipment. The first event (or failure) in a chain of events leading to a functional failure. |
| Root Cause Analysis (RCA) [4] | After a failure, the logical systematic examination of an item, its construction, application, and documentation to identify the failure mode and determine the failure mechanism and its basic cause. |
| Root Cause Corrective Action (RCCA) | An effective tool for finding the true or actual cause of events, facilitating effective corrective action and preventing their recurrence. |
| Root Cause Failure Analysis (RCFA) [4] | After a failure, the logical systematic examination of an item, its construction, application, and documentation to identify the failure mode and determine the failure mechanism and its basic cause. |
| Run-Time Diagnostics | Diagnostics performed to diagnose faults in a fielded system, device or process. |
| Safety Case | A final study that provides proof that the system will remain acceptably safe for a particular failure scenario. |
| Safety Consequences [8] | A failure mode has safety consequences if it causes a loss of function or other damage which could hurt or kill someone. |
| Scalability | the ability to increase system resources as the demand increases, by means of replication of resources or increasing the capacity of individual resources. |
| Scheduled Maintenance [2] | Maintenance performed according to a predetermined plan or guideline. See “Preventative Maintenance” |
| Semi-Dynamic Diagnostics | Diagnostics in which fault groups are developed dynamically (during run-time), yet which contains no mechanism for dynamically selecting the order of testing. Although semi-dynamic diagnostics may be based on a predetermined test order, the maintainer may skip tests, postpone tests, or otherwise perform tests out of order without impacting diagnostic accuracy. Although not as flexible as dynamic diagnostics, semi-dynamic diagnostics are more adaptable to changing maintenance environments than are statistic diagnostics. Furthermore, like static diagnostics, the predetermined test order allows the diagnostics to be relatively easily verified. |
| Sensor | A device which generates a quantifiable output in response to a physical phenomenon. |
| Severity | The worst potential consequence of a failure, determined by the degree of injury, property damage, or system damage that could ultimately occur. |
| Serial Replacement | Also called Prioritized Replacement. A method of repairing an isolated ambiguity group by replacing suspected repair items one at a time and then retesting to determine if a fault has been corrected. Serial replacement is used to improve maintenance costs (sometimes at the expense of a higher Mean Time to Repair) and typically employs the use of lambda search methodologies. |
| Shop Replaceable Unit (SRU) | A component where one or more maintenance actions cannot be performed in the field, forcing the system to return to a maintenance facility. |
| Single-Dimensional Dependency Model | A dependency model that contains a single set of dependency statements and which is used for modeling a system, device or process in which conditional causality does not come into play. Not to be confused with single-signal modeling. |
| Single Fault Isolation | Also called Common Cause Isolation. A method of fault isolation that proceeds under the assumption that all “failed” tests in a diagnostic session are due to a single malfunction or fault. Although frequently used as the basis for diagnostic analyses (such as testability) during the design phase, single fault isolation cannot consistency produce accurate results when multiple components are simultaneously malfunctioning during diagnosis. The degree to which diagnostic accuracy suffers depends on the likelihood of multiple failures (taking into consideration the possibility of dependent failures and the length of the interval between diagnostic sessions) and the extent to which single failures can produce the same test signature as multiple failures. (Compare with Multiple-Failure Isolation). |
| Single Point Failure (SPF) | Any single hardware failure or software error which results in irreversible degradation of item mission performance below contractually specified levels. The failure of an item which would result in failure of the system and is not compensated for by redundancy or alternative operational procedures. |
| Single Point Failure Mode (SPFM) | The way or manner in which the single point failure of an item occurs. |
| 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. |
| Software Failure | The inability of the software to perform any further functions as the result of a software fault. (Compare with Hardware Failure). |
| Software Fault | A bug or defect in the code that causes the software to perform incorrectly. |
| Software Maintainability | The ease in which software modifications are made as enabled by documentation, manuals, source listings, and other support documents. |
| Software Maturity | A measure of the evolution of software to satisfy operational requirements, as indicated by the number and severity of required changes. |
| Software Reliability | The probability that software will contribute to failure-free system performance for a specified time under specified conditions. The probability depends on information input into the system, system use, and the existence of software faults encountered during input. Calculated as the total CPU processing time over the number to software failures. |
| Static Diagnostics | Diagnostics which are based on a predetermined test order and for which the diagnostic conclusions associated with each possible test signature have been pre-computed. With static diagnostics, tests may not be skipped, postponed, or otherwise performed out of order. The main benefit of static diagnostics is that they are relatively easily verified. (Compare with Dynamic Diagnostics and Semi-Dynamic Diagnostics). |
| Statistical methods | The use of probability distributions to describe the expected range of behavior of a population. |
| Steady-State Failure Rate | The constant failure rate after one year of operation. |
| 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. |
| Subsystem Utilization Rate | The percentage of life unit time that the subsystem will operate, including time in standby mode. |
| Sustainability | The ability to support a system, including all Logistics Requirements, in order to maintain the necessary level and duration of operations to achieve varying mission objectives. |
| Symbol | In eXpress, a symbol is a picture that helps convey information about an element in a system, device or process. Symbols are stored in symbol libraries. Once dropped into a design, a symbol becomes an object; until then, a symbol has no function and no purpose. |
| Symbol Library | A eXpress collection of related symbols that can be used to build objects in eXpress. |
| Symmetric Test | A test that, when it fails, indicts only its coverage; a test with no interference. |
| Symptom [4] | A symptom is a perception, made by means of human observations or measurements (descriptors) which indicate the presence of one or more faults with a certain probability. |
| System [7] | 1) A collection of entities to be processed by applying a top-down, hierarchical approach. 2) A collection of interacting, interrelated, or interdependent elements forming a collective, functioning entity. 3) A set of objects or phenomena grouped together for classification or analysis. 4) A collection of hardware or software components necessary for performing a high-level function. |
| Systems Engineering | The process of transforming user needs and requirements into an integrated system design solution through concurrent considerations of all life cycle needs including development, test and integration, production, operation and full integration support. Cost and risk reduction are an integral part of Systems Engineering. |
| System Health Management (SHM) | The capability of monitoring real-time sensors to determine system health and performance. |
| System Safety | The degree to which system operates in the absence of failures that contribute to equipment damage, injury or loss of life. |
| Terminal Event | An event within a dependency model that is not listed as a dependency within another dependency statement. The terminal events within a dependency model correspond to the outputs of the system, device or process that is represented by that model. |
| Terminal Output Flag | An eXpress output flag connected to a net that is only connected to output ports on other objects. A terminal output flag can be represented as a terminal event within a dependency model. |
| Test [7] | A set of stimuli, either applied or known, combined with a set of observed responses and criteria for comparing these responses to a known standard. |
| Test Coverage | In the eXpress tool, test coverage refers to the functions and failure modes which are tested by a particular test. It can also refer to a test set or group of tests associated the functions and failure modes those tests address. |
| Test Coverage Interference | In the eXpress tool, test coverage interference refers to the functions and failure modes which may not have originally been the primary purpose of the test(s) but are considered as possible contributing factors and may exonerate or indict other functions or failure modes. |
| Test Interference | In eXpress, the set of additional functions and/or failure modes that, although they are not part of a test’s coverage, they can also cause that test to fail. |
| 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). |
| Test Plan | A mapping of the tasks and timing associated with a specific implementation of a test strategy. |
| Test Program Set (TPS) | The combination of test program, interface device, test program instruction, and supplementary data required to initiate and execute a given test of a UUT. (MIL-STD-2165) |
| Test Requirements Document (TRD) | An item specification that contains the required performance characteristics of a UUT and specifies the test conditions, values (and allowable tolerances) of the stimuli, and associated responses needed to indicate a properly operating UUT. (MIL-STD-2165) |
| Test Signature | The set of test results (Pass/Fail) that are generated when diagnostics are performed for a given fault combination. |
| Test Strategy [7] | 1) An approach taken to combine factors including constraints, goals, and other considerations to be applied to the testing of a unit under test (UUT). 2) The approach taken to the evaluation of a UUT by which a result is obtained. 3) The requirements and constraints to be reflected in test and diagnostic strategies. |
| Test Subject [7] | The entity to be tested. It may range from a simple to a complex system, e.g., a unit under test or a human patient. |
| Testability | 1) Testability is the ability to observe internal characteristics of equipment by external observation, given the application of suitably applied stimulus to the equipment, which elicits different responses under different internal states. Testability is viewed as the existence or non-existence of a satisfactory test [strategy], as a function of the applicable resources and constraints. 2) A design characteristic which allows the status (operable, inoperable, or degraded) of an item to be determined and the isolation of faults within the item to be performed in a timely manner (MIL-STD-2165). A design characteristic that allows its operational status to be determined and the isolation of faults to be performed efficiently (IEEE Std 1522). |
| Testability Analysis | The engineering practice associated with evaluating the testability of a system, device or process. |
| Testing | The process of inferring behavioral properties of a product on the basis of execution in a known environment with selected inputs and checking results. |
| 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. |
| Total Cost of Ownership | See “Owning and Operating Cost.” |
| Trade Study | A structured process which compares options using predefined performance criteria, to result in the selection of the best design that satisfies all requirements. Trade studies are highly iterative and are used during all development phases to ensure that all factors which might impact a function or requirement are considered. |
| Trending | The process of interpolation or extrapolation, accompanied by smoothing, to estimate an unknown state of a system, or to estimate the trajectory of the system between known and unknown state points. |
| Undetectable Failure | A postulated failure mode in a FMEA for which there is no failure detection method by which the operator is made aware of the failure. |
| Uniform Distribution | A simple failure calculation algorithm where a random number is simply limited to a range. |
| Unit Under Test (UUT) [7] | The entity to be tested. It may range from a simple diagnostic unit to a complete system; An item for which testability design and diagnostics must be developed. |
| Unplanned Downtime | Downtime which is due to a functional failure. |
| Unplanned Maintenance | Maintenance carried out to no predetermined plan. |
| Upstream | A term used to describe the topological relationship between a given element (event or agent) in a dependency model and another element that is a nth-order dependency of the given element (e.g., “an initial event is upstream from those events and agents that it affects”). |
| Uptime | The total time in which the system is considered operational. |
| Unreliability (Q) | The inverse of Reliability. |
| Vehicle Health Management (VHM) | An integrated health management system on a vehicle that monitors/manages that vehicle’s health. |
| Voting | A decision fusion method based on tallying the classification results from individual sensors (or algorithms). |
| Web-Based Diagnostics | A type of remote diagnostics where interaction with the diagnostic engine is achieved through a web interface. |
| Weibull Distribution | A statistical distribution that is widely used for matching field data, due to its versatility and the fact that the Weibull probability density function can assume different shapes based on the parameter (beta factor) values. |
| Weighted Decisions, Weighted Voting | A data fusion method based on voting where weights are given to the individual contributors based on expert judgement, confidence, etc. |
| White Box | A system or component whose contents and implementation are fully disclosed. (See also black box, grey box and glass box). |
| XMI (XML Meta-data Interchange format) | A format for open exchange of UML and other information assets |
| XML (Extensible Markup Language) | An open, text-based markup language that provides structural and semantic information to data. XML is a subset of the SGML (Standard Generalized Markup Language) standard |
Glossary References
[1] John Mitchell EAM Handbook, Appendix A.
[2] ONR Terminology Related to Condition-Based Maintenance, Prognostics, and Generalized/Personalized Maintainer
[3] OPNAV 4890.16 Definitions
[4] ISO – 13372.2/WD “Terminology for the fields of condition monitoring and diagnostics of machines,” ISO draft standard dated 10/4/99.
[5] CORBA IIOP Specification, version 2.3.1
[6] Blair, G.S., and J.-B. Stefani, Open distributed processing and multimedia, Harlow, England: Addison-Wesley, 1997.
[7] AI Estate Definitions, adopted in-part from: IEEE 1232-1995, IEEE 1232.1-1997, and IEEE Std. 1232.2-1998.
[8] Moubray, John, Reliability-centered Maintenance, New York: Industrial Press, 1992.
[9] Maynard, Kenneth, “Interstitial Processing: The Application of Noise Processing to Gear Fault Detection,” Proceedings of the International Conference on Condition
Monitoring, University of Wales, Swansea, UK, April, 1999.
[10] Broesch, James D., Digital Signal Processing Demystified, Eagle Rock, Virginia: LLH Technology Publishing, 1997.
[11] Walpole, Ronald E. and Myers, Raymond H., Probability and Statistics for Engineers and Scientists, Pirtle, Robert W. 5th ed. New York: Macmillan Publishing
Company, 1993.
[12] Erdley, J.D., and Hall, D. L., “Improved Detection using Multisensor Data Fusion,” Prognosis of Residual Life of Machinery and Structures, Proceedings of the 52nd
meeting of the Society for Machinery Failure Prevention Technology, Virginia Beach, VA, March 30-April 3, 1998.
[13] Hall, D.L., Mathematical Techniques in Multisensor Data Fusion, Boston: Artech House, 1992.
[14] Russell, S., and Norvig, P., Artificial Intelligence A Modern Approach, New Jersey: Prentice Hall, 1995.
