To create a system in TEAMS-RDS:

• Log in with a user that has the “supervisor” role assigned.
• Select Create/Delete Systems from the left menu.
• Enter a name and revision for the system.
• Select a model from the “Model Name” drop-down list.
• Select the revision of the model from the “Model Revision” drop-down list.  By default the latest revision is selected but a previous revision may be assigned as well.
• Click on Create to finish.

Knowledge Management Systems are very good at retrieving “best known solutions”. However, these are solutions that are known best (because they were documented by service agents or experts) but are not necessarily the best or optimal solutions. Further, they are typically not good at providing the single right solution for a particular problem, instead providing a list of close matches for similar problems. To make things worse, these close matches are ranked by frequency of occurrence, implying a difficult but rare problem where the service agent needs most help is invariably at the bottom of the list, and the most common solutions that every service agent is familiar with is ranked at the top.  They tend to promote solving problems by trial and error, and may increase cost of service over the long run.

QSI TEAMS applies logic to solve troubleshooting problems. QSI TEAMS does not past service history or documented cases. It excels when an error or symptom has many causes or faults manifest into many symptoms. It can be deployed at the machine level, the call center, the field or automatically from machine to machine (M2M).

To understand how TEAMS works, think of your GPS navigation system. It is great for visiting places you never been before! And it is also great at finding the optimal route for that day, given the road and traffic conditions. The GPS and TEAMS solution share two important attributes: it applies algorithms or logic to solve new problems (instead of trying to utilize past experience or solutions), and it recognizes yesterday’s solution might not be the best solution today.

Taking the analogy further, think of the GPS software as the TEAMS reasoner, and the maps are the cause-effect relationships – i.e., which faults trigger with error code or test failure – in your system. The TEAMS reasoner applies logic and optimization algorithms to rule-in and rule-out possible causes and guides the technician through additional information gathering, until it determines the root cause. It then guides the service agent through the corrective action and the verification steps, all the while logging each of the steps automatically, and learning from it. Just like the GPS can route you through various options (e.g., avoid toll roads or ferries), the TEAMS reasoner can guide service agents with different levels of skills, certifications, support equipment — generating a different troubleshooting path based in his or her ability.

Simply put, it is the kind of technology that helps a 19 year old kid fix a F16!

The TEAMS system can scale up to handle extremely large and complex systems. For example, the complete model of a system-of-systems setup, such as the Launch System at NASA Kennedy Space Center (KSC) is likely to involve models  with 50,000 failure modes and 50,000 tests. TEAMS-RDS can diagnose such systems in real-time, as has been demonstrated on the Launch Control Systems at KSC. TEAMS-RT can also scale down to small-scale flight computers and process over 10,000 tests per seconds, as would be typical in a complex space vehicle. TEAMS-Designer can model and analyze such systems on a typical desktop computer. As a point of reference, most of our commercial customers have systems that typically have on order-of-magnitude less number of failure modes and tests for their systems. Thus most customers will never run into any scalability limitations with the TEAMS soluton.

All diagnostic tests, test results, and problem resolutions are recorded by the TEAMs system as the Service Agent uses it. This information is fed back into the TEAMS system model. Background processes running on the system use this information to refine and optimize the model to improve diagnostic accuracy and speed. For example, if a specific step takes too long, or a part fails too often, TEAMS may reorder the sequence of steps to improve the troubleshooting time.

Root Cause Analysis is a problem solving strategy that attempts to identify the fundamental or root cause of a problem. This is in contrast to other strategies that look to eliminate a problem’s symptoms, not its true cause. The latter is like resetting the check engine light in your car, sooner or later the problem reappears and another service call is required. TEAMS strength is that it defines the steps and assets needed to find and resolve the route cause.

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.

Several components of the TEAMS system are designed to run in standalone mode without any network connection. TEAMS-RT is an embedded reasoner that can run directly on the instruments on-board computer. Running on a laptop or mobile device, both the TEAMATE and PackNGo applications are designed to run completely in standalone mode. All the required troubleshooting information is downloaded to these devices prior to dispatch.

This is a proactive strategy that empowers service agents to identify problems up front, at the lowest cost level. Once understood, support personnel can then dispatch an asset or an on-service agent with the correct skills, material, knowledge, and tools to resolve the issue. This approach reduces truck rolls, unresolved issues, and return customer site visits and helps to dramatically reduce the cost of materials.

The place to start is by looking at each instrument and defining the optimum service strategy for that particular unit. Then review your cost structure and get a complete understanding of the type of common problems you’re experiencing, the level at which they can be solved, and the need to transfer problems to the correct service level for resolution.  All service to remote devices can be improved with a Remote Service strategy; it is very costly and difficult to dispatch the correct assets (skills, material, knowledge, and tools) without a good up front triage process.

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.