- 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!
The modeling effort can be broken in four phases:
1. Getting to know the system being modeled, the different ways it can fail, and how the failures manifest themselves (symptoms, error-codes, tests).
2. Capturing the relationships in the TEAMS tool (the actual modeling).
3. Adding reference material and instructions on how to perform individual steps of troubleshooting.
4. Verification and validation of the diagnosis and troubleshooting strategy generated by the reasoner.
Different customers take different amount of time at the various steps — especially since some of the steps are related to how well the organization captures and documents knowledge, and how accessible the information is to the modeler. Based on our experience, a typical system takes one or two man-months to model. As a rule of thumb, each test or fault takes one hour to model, and therefore, a typical system with up to three hundred error codes and manual tests will take under 2 person-months.
Diagnosis is the process of determining the system health from observed effects. Typically, over 50% of the cases, the corrective action can be diagnosed unambiguously by reasoning on the presence and absence of error codes. For those cases, troubleshooting can be completely eliminated. For the rest, the diagnosis from observed effects reduces the list of suspects to a small set, and the reasoner can generate an optimized sequence of (troubleshooting) steps to identify the corrective action.
This is contrast to the traditional troubleshooting practice, which relies on past case history to identify a list of possible corrective actions that the service agent should try until problem appears to be fixed.
With TEAMS, even an inexperienced service agent can find and fix problems as good as an expert!
Most service organizations do not make optimal use of available information to diagnose the problem. For example, presence of multiple error codes can actually help narrow down the set of possible suspects, and the absence of an error code can be used to downplay or eliminate many suspects. The power in TEAMS comes when you use all available information (both passing and failing test results or error codes) to isolate the cause. The reasoned uses all this information to determine which components are good, bad or suspect.
Guided troubleshooting is an optimized set of steps dynamically generated by the reasoner that the Service Agent follows to identify, correct and resolve a reported problem. This can begin by querying the operator of the system and continue with the field service agent. By querying the operator you minimize the task of the field service agent by quickly narrowing in on the problem, thus reducing his troubleshooting time and parts dispatched.
A malfunction in a systems (the cause) will generate one or more manifestations (the effects). The reasoner is an algorithm that uses the many-to-many relationship between causes and effects (as captured in a TEAMS model) to identify the root cause(s) that best fits the observed effects. If the observed effects are not sufficient to pinpoint the root cause, the reasoner can identify the troubleshooting steps required to gather additional information and identify the root cause. This process of identifying what’s wrong in the system is very similar to what your smartest experts will use to troubleshoot complex problems.
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.
QSI TEAMS is a model based approach, as opposed to knowledge, history or case based (all of which require accurate legacy data). QSI TEAMS does not require legacy data. It can produce accurate results immediately. 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).
While the system experts may be good at solving problems, they are not necessarily the best choice to model. They tend to model solutions (to specific problems or symptoms) and not the problem space (i.e., what fails, how you detect failures and their relationships). Someone who is knowledgeable with how the system works is usually a better candidate to model. We can supply you with a good job description if needed.