Emulator for a Telephone System

In the past, telephone systems have been provided having an automatic call distributor (ACD). In one form, the ACD has a reporting system with output devices for supplying reports and information to the user. When the software is being developed for the reporting system, it is necessary to obtain information from the ACD in order to test and debug the program for the reporting system. However, it is difficult to control the ACD such that it supplies the desired data type and data rate for checking the software of the reporting system.

A principal feature of the present invention is the provision of an emulator for a telephone system.

The emulator comprises an automatic call distributor, and a reporting system for receiving information from the call distributor and having at least one output device.

A feature of the invention is the provision of a simulator for supplying simulated information of the call distributor to the reporting system when requested and at random time intervals.

Another feature of the invention is that the type and rate of data can be controlled on the simulator.

Thus, a feature of the invention is that the simulator may be used to test the software of the reporting system in a simplified manner.

Further features will become more fully apparent in the following description of the embodiments of the invention, and from the appended claims.

In the drawings:

FIG. 1 is a block diagram of an emulator for a telephone system of the present invention; and

FIG. 2 is a flow chart of the simulator of FIG. 1.

FIG. 3 is a block diagram of the simulator of FIG. 1;

FIG. 4 is a flow chart depicting process steps of the simulator of FIG. 3; and

FIG. 5 is a flow chart depicting process steps of the emulator of FIG. 3.

Referring now to FIG. 1, there is shown an emulator generally designated 10 for a telephone system. The emulator 10 has an automatic call distributor (ACD) 11, and a reporting system 12 comprising a computer for the ACD. The reporting system 12 prepares reports for the user, such as by a printer 14, a screen 16, and optical drives 18 for the archives of data. The ACD supplies information to the reporting system 12, and the reporting system 12 may request information from the ACD.

As shown, the emulator 10 has a simulator 20 comprising a computer for supplying simulated information of the ACD to the reporting system 12, and the reporting system 12 can request information from the simulator 20 over an X.25 communication link. Thus, the ACD need not be connected in the emulator 10 when the simulator 20 is in use. The simulator 20 supplies the type of information and rate of information, such as periodic and real time, to the reporting system 12, which the ACD would normally supply to the reporting system 12 during normal operation of the telephone system. The type and rate of data supplied by the simulator 20 to the reporting system 12 may be controlled by commands issued to the simulator 20 by the user.

A flow chart of the operation of the emulator 10 is given in FIG. 2. As shown in box 22, first the reporting system 12 is started, and in box 24 the simulator 20 is started, after which the data links come up in box 26 to verify that the communication is stable. Next, the simulator 20 sends configuration data in box 28 which comprises the initialization of data. In box 30, the reporting system 12 requests data from the simulator 20.

In box 32, commands are issued by the user to the simulator 20 for controlling the type of data sent and data rate sent, for example, periodic data and real time data. In box 34, the simulator 20 sends periodic data at the periodic boundary, and in box 36 the simulator 20 sends event data in real time. Finally, in box 38 it is verified that the reporting system 12 is operating properly by using the simulator 20 instead of the ACD.

Thus, in accordance with the present invention, a simulator 20 is used to emulate data normally issued by the ACD in order to test and debug the software in the reporting system 12, with the type of test data given to the reporting system 12 being controlled by the commands given by the user to the simulator 20 in a simplified manner.

FIG. 3 is a block diagram of the simulator 20. Included within the simulator 20 is an event processor 60 which functions to control data send to the reporting system 12. For example, upon start-up a switch configuration generator functions to generate a data set defining the type of switch which the simulator 20 will simulate. The event processor 60, upon receiving the data set, transfers it to the report generator 12.

The switch configuration generator 62 functions to retrieve data from a configuration look-up table in memory 58, format that data and transfer that data through the event processor 60 to the reporting system 12. The data set generated by the switch configuration generator 62 describes the basic configuration of the switch (e.g., number of agent stations, number of trunks connected to the PSTN, etc.).

The periodic data generator 64 similarly functions to format and deliver data to the event processor 60 for transfer to the reporting system 12. One difference, however, it that the simulator 20 responds with periodic data only when requested by the reporting system 12.

The periodic data which the simulator may include within a response to the reporting system 12 may include agent group data, trunk data, overflow-in data, overflow-out data, application vector data, application vector step data, intercept vector data, feature vector data, DNIS data, receiver group data, vector application data, agent information group data, or ANI data. The volume of each type of data is also selectable by a user and stored in a periodic data look-up table in memory.

The time synch generator 54 functions to provide time synchronization data to the reporting system 12. Time synchronization data is transmitted under control of the user terminal 56 either periodically, or upon entry of a specific command by the user.

The random event generator 50 functions to generate a random interrupt to the event processor 60. The random interrupt may be programmed to operate completely randomly or with the delivery of a fixed number of events falling anywhere within a fixed or variable time period. The fixed time period and number of events may be entered by the user through the user terminal 56 and stored in a simulator set-up table in memory 58. Limits on the variable time period may also be entered by a user through the terminal 56 into memory 58. The use of a random number generator operating within a fixed or variable time period allows the simulator 20 to more thoroughly test a reporting system 12 under the type of random conditions that an ACD 11 would experience in everyday use.

Upon receipt of an interrupt from the random event generator 50, the event processor 60 transmits event data to the reporting system 12. Event activity may include agent activity information, agent performance information, call records or transaction records.

Each event may include a number of fields. For example, agent activity may include such fields as; aa.sub.-- staff, aa.sub.-- staff.sub.-- version, aa.sub.-- time.sub.-- stamp, aa.sub.-- type, aa.sub.-- link.sub.-- id, aa.sub.-- line.sub.-- instance, aa.sub.-- rec.sub.-- disposition, aa.sub.-- digit.sub.-- type, aa.sub.-- digits, aa.sub.-- dnis.sub.-- digits, aa.sub.-- dnis.sub.-- version, aa.sub.-- call.sub.-- duration, aa.sub.-- talk.sub.-- time, aa.sub.-- hold.sub.-- time, aa.sub.-- appl.sub.-- id, aa.sub.-- appl.sub.-- id.sub.-- version, aa.sub.-- vect.sub.-- id, aa.sub.-- vect.sub.-- id.sub.-- version, aa.sub.-- agrp.sub.-- id and aa.sub.-- agrp.sub.-- id.sub.-- version.

Agent activity event records (as well as agent performance information, call records or transaction records) can be generated within the event processor 60 based upon data stored within each field of an agent activity event look-up table in memory 58. By editing ASCII data within each field, a user (through the user terminal 56) can manipulate specific data elements in order to test and debug specific software components of the reporting system 12.

To use the simulator, the user programs the respective look-up tables with periodic and event processing information. For example, the user may enter a value into the memory 58 specifying the number of each type of event per time period (e.g., every 10 ms, 500 ms, etc.). For example, the user may enter a value of "1" for each of the agent activity information, agent performance information, call records and transaction records. As such, the event processor may send one of each type of record during each time period.

Further, the event processor 60 may also function to determine a proportion of each type of event and maintain that proportion during transmission of events. For example where the first event has a value of "100" and the second event has a value of "25", then the event processor 56 may function to maintain a proportion of 4 to 1 in the sequence of events transferred.

FIG. 4 is a flow chart of the steps that may be executed by the simulator 20 in sending event data to the reporting system 12. As shown each time the event processor 60 receives a random prompt 100, it retrieves 102 the next event of the agent activity information, agent performance information, call records or transaction records. The event processor then determines what proportion this particular event is to form of the total events. If the proportion is greater than zero 104 (i.e., the event is to be transmitted as simulated information), the processor 56 determines whether the proportion of this type of event is in the proper ratio. If it does not exceed the proportional threshold 106, the event is generated 108 and transferred 110.

As the simulator 20 processes events, it also monitors for data requests that may be transferred from the reporting system 12 at logging boundaries. At a logging boundary, the reporting system 12 may transmit a data request to the simulator 20. In response, the simulator 20 transmits back a simulated set of logged events.

FIG. 5 depicts a flow chart of steps that may be executed at a logging boundary. As shown, at a logging boundary, the simulator 20 receives a data request 112. Upon receiving a data request 112, the event processor 60 retrieves 114 a number of each type of record that is to be transmitted from memory 58. If the number is greater than zero 116, the event processor 60 formulates 118 that number of records and transfers them 120 to the reporting system 12.

The simulator 20 then checks 122 to see whether this is the last record. If it is not, the simulator 20 retrieves 114 the next record and the process repeats until each record type has been processed.

To further test the reporting system 12, the user of the simulator 20 may also enter a burst mode where events may be transferred at an elevated rate. Through the user terminal 56, the user may enter the command "BURST -cp -10 -ap -5-aa -3". Entry of this command may be used to send ten call records per second, 5 agent performance records per second and 3 agent activity records per seconds to the reporting system 12.

Alternatively, the command "BURST -ap -aa -cp -tr" could be send. Entry of this command would send agent performance records, agent activity records, call records and transaction records on a continuous basis. Similarly, entry of the command "BURST -aa" would cause the continuous transmission of only agent activity records.

The foregoing detailed description is given for clearness of understanding only, and no unnecessary limitations should be understood therefrom, as modifications will be obvious to those skilled in the art.