ARGOS Computer Systems Automated Test and Alarm Facility (ATAF) that can be used in conjunction with ARGOS Voice Response systems. The purpose of ATAF is to ensure that:
- The IVR is operational
- All lines servicing that VRU are operational
- Selected database serviced by the IVR are online and valid
- Issue warnings upon failure
- Provide information on network and IVR performance
ATAF is a script running ARGOS Voice Response System, built on the standard ARGOS voice response platform, that operates in conjunction with the customer's IVR application, to allow for automated testing of the IVR and network. ATAF consists of four parts:
- A special script and databases that contain information that ATAF can use to "poll" selected telephone numbers at specified times.
- Modifications to the VRU script that recognize the ATAF call and respond with touch tone rather than voice
- An alarm script and associated databases, running in ATAF. The alarm script is activated under predetermined conditions
- A special set of reports to collate and report on information gathered during the "polling" process.
Theory of Operation
The key to operation of ATAF is that the VRU script is modified to recognize a call, and then respond with touch tones rather than voice. This allows ATAF to actually perform inquiries and validate responses, rather than simply tally "completed calls".
For example, a typical VRU starts with a menu offering four to five options. An additional option would be added, but not spoken. While the normal options are usually single digits, this new, hidden option, would be several digits long. After being directed to this "special" leg, the VRU script would be designed to respond to ATAF inquiries in a prearranged manner. The fact that the script reaches the point of responding at all, provides quite a bit of information by itself, but the intent of ATAF is to provide more information than a simple "successful" connect.
Most network vendors provide connect information, but can't tell you what you have connected to. ACDs can tell you when calls arrived, and how quickly they were serviced, but don't tell you anything about VRU response time or accuracy of VRU data files. The VRU tells you what it got, but after the fact. Finally, since each vendor only services part of the picture, information on VRU performance is in many different places and frequently hard to organize coherently. ATAF is designed to provide an end to end test of the VRU system.
The recommended ATAF implementation is one in which it can perform inquiries on predictable data. This data could be entered in the ATAF files each day, but a better technique is to look for predictable data. For example, for a mutual fund:
- A test fund could be created with a fixed value
- Audit accounts could be created with a known, unchanging, share balance
The ATAF and VRU scripts could be designed so that ATAF goes to the "special" menu leg, generates an inquiry against the audit account, and checks the result. It can verify the accuracy of the result as well as the response time.
This can be turned into a true end to end test of a VRU system.
ATAF Alarms
Knowing that there is a problem is half the battle. Getting the word out is the other half. Once ATAF encounters a condition defined as an "alarm", e.g. incorrect data in an audit account, it stops polling and goes into alarm mode.
In alarm mode, ATAF accesses a list of telephone numbers and tries to obtain help. Each telephone number has an associated action, or "type". These actions are:
- The telephone number is a beeper. Enter a call back number.
- The telephone number is a beeper. Enter a pin and then a call back number.
- The telephone number is a person. When the call is answered, speak a message.
Once ATAF "delivers" its message. It waits for a call back. (The person making the call back must have a touch tone telephone.) The call back will serve as confirmation of delivery as well as tell ATAF whether to shut down or resume operations.
ATAF Operating Environment
Since ATAF is written on the ARGOS voice response platform, it can be operated in various modes. It can be part of the customer VRU, it can be part of the backup VRU, or it can operate in a VFE in a standalone environment. ARGOS strongly recommends the standalone VFE environment. There are several reasons for this:
- Having code within the VRU to test the VRU is not a very good test. At the very least, it invalidates all of the performance statistics, at the worst, it is susceptible to the very failures it is supposed to detect.
- Running the test program in the test VRU is better, but still a problem. Depending on what you are trying to detect (e.g. power outages), this is still susceptible to error. In addition, test environments are notoriously "fickle" and constantly changing. The ATAF should be considered "production".
- The equipment that serves the VRU best is not always the equipment that will serve the ATAF best. For example, the most important requirement for the VRU is voice quality and a good recording. The most important requirement for the ATAF is to be able to recognize that a call has connected. These can be conflicting conditions.
- Our VFE is portable. The most reliable test environment would be to have the VFE in a different state than the VRU. This is a much better network test and it avoids the embarrassing problem of having a power or telephone outage take down the VRU and the ATAF.
- Since the VFE is portable, it can be moved from time to time to compare network performance from different parts of the country.
Reports
ATAF is meant to be an alarm, but during the process of testing the VRU it can also gather considerable information on network and system performance. The following stats are gathered during each "test" call:
- Date and time of call
- ATAF line number
- VRU telephone number
- Time from start of dial to VRU connect
- Time from initial inquiry to response
- Number of Rings before answer - Alarm parameter
If the call failed to connect, the reason for the failure will be stored. The hardware and software version for the VFE and of ATAF can distinguish between:
- Busy
- No Answer
- No ringing
- Operator intercept
The actual data reported will vary from application to application, but the "generic" ATAF report provides all of the above information by number dialed and by time as well as on a whole network basis.
The following items are customer depended and presented as additional features that could be added.
- Verify that Updates and file down load have taken place
- Host link - Heart Beat Transaction to host and applications
- Line Status validation. - CTI Validations
- Netview Alerts - Postings
- FAILSAFE notification from a battery backed unit to send alarms
| 
