Tests that Represent Diagnostic Procedures

Special “diagnostic procedure” tests can now be used to represent secondary procedures that are launched from within a main diagnostic procedure. Simply define a test for each of the expected outcomes of the secondary diagnostic procedure and then group them all into a single test. Next, on the Test Interpretation panel for that test, select “Diagnostic Procedure” as the group type:

Diagnostic procedure test can be defined as:

• Linked – associated with another study that represents where diagnostics pick up after that procedure.
• Unlinked – additional diagnostics are calculated in the same diagnostic study and then exported as separate diagnostic procedures.

BIT Tests

A new BIT test type has been added to eXpress to address situations where interference is desired for a test with enumerated coverage. BIT tests are coverage-based tests, meaning that they are defined by specifying the test’s coverage. By default, interference is then calculated to include (initially) all functions upstream from the covered elements.

Fault Template Tests

Fault templates are not only a container for data associated with isolated fault groups. They can also be used to represent a prior diagnosis for which a troubleshooting process must be created. To do this, you can define tests in eXpress that map to previously-isolated fault groups and then use these tests as starting points for additional diagnostics.

Failure Effect Tests

A new test type allows tests to be created for defined failure effects (either design or object effects). This allows tests to be easily created for symptoms derived from imported FMECA data. In the diagnostics, the coverage for each “Test for Effect” is calculated as the root (lowest-level) failure mode causes of the associated failure effect.

Even if you do not include FMECA data in your models, this new test type provides a useful way to define upper-level test coverage in terms of failure modes in one or more lower-level models—without having to inherit (or re-inherit) tests hierarchically. In the past, tests with discrete, yet dispersed lower-level coverage would have to be modeled by creating tests in multiple lower-level designs, creating hierarchical tests at each higher level, and then grouping the final tests together at the top. Now, simply model the propagated effects of the root failure modes and then create one test at the top (in fact, to prevent the inefficient use of this new test type, you are prohibited from inheriting these tests hierarchically). Modifying test coverage is as simple as updating the list of causes for the appropriate failure effect (at any level of the design) and then saving hierarchically (if the effect is defined within a lower-level model).

Multiple Outcome Tests

Multiple outcome tests define tests with three or more outcomes. To support this new feature—which may seem very simple from afar—many areas of the tool needed to be modified. Basically, a multiple-outcome test is a special type of group test in which each of the grouped subtests represents a different way in which a test can fail. So, when we say Multiple Outcomes, we really mean Multiple Failure Outcomes (if you count the “Pass” outcome on each test, then eXpress has always handled two outcomes per test).