- 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.
To remove a function mapper in a module:
Note: Only one function mapper may be removed at a time.
Yes it is possible to add your own hierachy labels. Just open the module’s properties panel and enter the new hierarchy label in the combo-box. Click Ok to apply the changes. The hierachy label will be added to the bottom of the list next time the drop-down list is displayed.
Hint: To add the new hierarchy label to multiple modules, open the module batch editor and apply it to all the applicable modules.
To map a function in a module: