- About Us
When creating a model, the individual subassemblies are created as modules. The models of these modules can be shared with little or no modification across multiple systems. This means that if a subassembly is shared across multiple systems, it only needs to be modeled once. Thus, the models are nearly as reusable as the underlying system components!
A TEAMS model captures the many-to-many mapping between causes (things that fail, i.e., faults) and effects (things that detect failures, i.e., tests and symptoms). If you know these relationships, you can import them in as a spreadsheet. Otherwise, you lay out the system and its interconnections, and TEAMS will propagate the faults along those paths to generate the mapping.
Tests can only detect failures, and can declare something as good only by elimination — i.e., when it did not find anything bad. Therefore, by definition, the PASS outcome cannot declare something GOOD that the FAIL outcome cannot declare as BAD
Before 11.6, we did not enforce this constraint, and that got modelers into trouble. For example, before you could model a TEST T as follows:
PASS outcome detection A and B, and
FAIL outcome detecting ONLY A
Well, not only is this contrary to the basic definition of a test — it also leads to some very illogical outcomes — B will be eliminated from the list of SUSPECTS, no matter what the outcome of the TEST T! Here is why — if Test T PASSes, you would declare A and B as GOOD, that is fine! However, if test T FAILS, then also you would declare B as GOOD (under single fault assumption) since A is faulty, and therefore B cannot be faulty! So, you do not have to see the outcome of TEST T, you can eliminate B!! So, why bother running TEST T, just eliminate B:-)
By default a test is assigned two outcomes, a pass outcome and a fail outcome. To add further outcomes to a test, select the Functions tab in the test-point properties panel. Click on the Edit button that is next to the Outcome Name drop-down list. A dialog with a list of outcomes attached to the test will be displayed. To add another outcome to the test, just click on the Add button and enter the name of the new outcome. The outcome will be added to the bottom of the list, making it a fail outcome. To make it the pass outcome of the test, select it and use the up arrow to move it to the top of the list. Keep in mind that a test only has one pass outcome and one or more fail outcomes.
Yes, many of our customers use TEAMS to manage very complex mechanical and fluidic systems. The requirement for TEAMS is twofold. First, that the instrument is equipped with electronic sensors or observations to identify component failures or degraded performance and second, that this information can be passed to either an agent or directly to the TEAMS system. This can be run remotely using TEAMS-RDS.
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.
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.
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.
Function-mappings consists of a single destination function and one or more source functions. A function-mapping will be applied if any of the source functions defined in a function-mapping reach any of the input ports of a failure mode and are not being blocked. For example, if a function-mapping defines three source functions then any of the three functions will be mapped to the destination function. The mapped function will be propagated to all the output ports of the failure mode.
When computing function propagation, blockers are applied first and then function mappings are applied. For example, if function-1 is blocked and is also defined in a function mapper as a source function, TEAMS-Designer will not apply the function mapper to the already blocked function.
To remove a function mapper in a module:
Note: Only one function mapper may be removed at a time.