An Operational Check (Opscheck) test is a type of test that may be used to verify the repair at the end of a diagnostic session.  They are useful in verifying the repair completed correctly addresses the symptom being diagnosed.   The Operation Check is part of a test’s type settings.  The setting is found under the Properties tab in the test-point properties dialog.  There are four different types of tests: tests, symptoms, operational checks, and acceptance tests.  By default when a test is created, it is just a diagnostic test.  These tests form the set of viable tests that may be used in the diagnosis phase of a session. If a test is also marked as an Operational Check test, it will be added to the set of tests that may be used during the operational check phase of the diagnostic session.  If a test is marked only as an Opscheck test, it will not be used in the diagnosis phase of the the session.  If the test is to be included in the diagnosis phase as well, ensure the test is of type Test as well.

In order to enable the operational checks in Testability Analysis, go to the Service Policy tab and enable the Operational Check phase.  The extent of Operational Checks after the repair can be, either to check the “Entire System” after repairs, or only those failure modes that are the results of the “Intersection of selected symptoms”, or only those failure modes that are the result of the “Union of selected Symptoms’, or only those failure modes under the “Repaired Components”.

In order to enable Operational Check test in TEAMS-RDS, ensure the option is enabled in the RDS Diagnostic Options page.  Note a TEAMS-RDS administrator is required to enable the option.

Notes:

• Operational checks are shown only with passed outcomes.
• Operational check tests can be included or excluded in the diagnosis phase by enabling/disabling the Test checkbox under the Type attribute in the Properties tab.

There are many reasons why a test may not be used for diagnosis, lets begin by looking at a diagnostic session.   A diagnostic session has three basic phases: the acceptance phase, the diagnosis phase and the operation check phase.  Each phase has a set of viable tests that may be used during the session.  These phases may sound familiar because a test’s type may be: test, symptom, operational check and acceptance test.  Depending on the test’s type, it may or may not be used in the diagnostic session.   A test will be added to a set if the test’s type for that particular set is enabled.  For example if a test is marked as a Operational Check test it will be added to the set of viable tests used during the operational check phase.

Tests that are marked as symptoms appear in the beginning of a diagnostic session.  Tests marked only as “symptom” will not be used in any of the phases.

Notes:

Prior to TEAMS-Designer 11.5, tests that were marked other than type “Test” were also included in the diagnostic phases.  This behavior has been changed as described above.  To retain a model’s diagnostic tree, ensure all of the tests are of type “Test” as well.

To generate a dependency matrix report, simply go to Tools -> Options…, enable the Generate D-Matrix Spreadsheet Report option then go to Analysis -> Testability Analysis… or Analysis -> Serviceability Analysis…, depending on your license.

TEAMS-Designer will generate a CSV and Microsoft Excel file containing the dependency matrix.  The files are located in the REPORTS sub-folder under the model’s folder.  The REPORTS folder contains a list of time-stamp folders for each analysis completed.  TEAMS-Designer creates a file formatted using the following convention <model_name>_D-Matrix.xls in each folder.

The System Modes and Technologies tab in the analysis options dialog allows users to filter out modules by technologies.  The analysis can either include or exclude the modules containing the technologies selected in the list.  To add a technology to a module, open its properties panel and select the Advanced tab.

Notes

• If you are adding a technology to a module with hierarchy, you will be prompted to add the technology to all of its sub-modules.
• When adding a technology to a sub-module, the technology will also be added to all of its parent modules.

Under the Basic tab in the analysis options dialog, users can filter tests by several ways:

• Test Labels
• Test Levels
• Test Methods
• User Roles
• Resources

Test Labels, Test Levels, Test Methods and User Roles

To edit any of these attributes, select the Properties tab in the test-point properties dialog for a test.  For example, if you wish to use a specific sub-set of tests that measure pressure readings, just apply a test label such as “Pressure” to all of them and select the test label in the analysis options dialog.

Resources

To edit the resources of a test, select the Setups and Resources tab in the test-point properties dialog.  The test resource properties are located in the bottom on the property page.  Just like the other test attributes, you can assign test’s resources and filter them using the resource filter option in the analysis options dialog.

Notes

• You may only filter out tests by either test labels or test levels, but not both during an analysis.
• You may include unlabeled tests by selecting the option underneath the list of test labels.
• If a test contains at least one of the labels selected, it is included in the analysis.
• All the resources of a test must be selected in order for the test to be included in the analysis.