WO1992012480A1

WO1992012480A1 - Transaction system emulator

Info

Publication number: WO1992012480A1
Application number: PCT/US1992/000144
Authority: WO
Inventors: Danny O. Kannady; William Mcpherson Horner; Srinivasan Rao
Original assignee: Verifone, Inc.
Priority date: 1991-01-09
Filing date: 1992-01-09
Publication date: 1992-07-23
Also published as: AU1196192A

Abstract

A transaction system emulator serves to emulate various transaction system peripherals, replacing each emulated hardware peripheral by a corresponding software counterpart and an interconnection between the computer performing emulation and the transaction system hardware. Thus, one or more input devices (102) are replaced with logs of input data (105) such that the system being emulated can be tested without requiring a significant amount of input test data to be manually entered. Sets of test data may be captured either utilizing the emulator system with actual peripheral input devices (102), or obtained from an actual transaction system including such input devices. Alternatively, input test data logs (105) are created by other means, such as by a program, text editor, or the like. An output log of data resulting from input test data is created and, if desired, compared against a log of known, valid data corresponding to the input test data.

Description

TRANSACTION SYSTEM EMULATOR

CROSS-REFERENCE TO RELATED APPLICATIONS

The following co-pending applications are related to this application, and are hereby incorporated by eference:

Background

This invention pertains to transaction systems, such as point of sale terminals, inventory control systems, and the like. More specifically, this

invention pertains to an emulator for use with a

transaction system such that one or more peripherals are simulated by the emulator, allowing training and

development to be accomplished without the need for all hardware components to be in place in the system.

DESCRIPTION OF THE PRIOR ART

Transaction systems are well known and include familiar supermarket checkout systems which include a cash register and various peripherals such as printers, change machines, UPC scanners, and scales. When

developing hardware and application software for such systems, a system including all peripherals pertaining to the hardware and application software being tested is used, corrections and possible improvements are then noted, the application software is debugged and modified on a software development system, and modified software is loaded into the transaction system hardware for retesting. Similarly, hardware testing and debugging is typically performed on an actual transaction system including all necessary peripherals.

Furthermore, if a new peripheral is desired, it must be obtained and interfaced to the transaction system in order to fully test application software and interface hardware associated with that new peripheral.

Such prior art systems are typically rather limited in the types of peripherals which may be used, and their application software. Nonetheless, an emulator would prove beneficial for such systems, and even more so for more sophisticated systems which include many more options for tailoring the transaction system to

particular customer needs.

SUMMARY OF THE INVENTION

In accordance with the teachings of this invention, a transaction system emulator serves to emulate various transaction system peripherals, replacing each such emulated hardware peripheral by a corresponding software counterpart and a test circuit for interconnecting the computer performing the emulation to the transaction system hardware. In accordance with the teachings of this invention, one or more input devices (such as UPC scanner, keyboard, display printer, etc.) are replaced with one or more logs of input data such that the system being emulated can be tested without requiring a

significant amount of input test data to be manually entered. In one embodiment of this invention, one or more such sets of test data are captured either

utilizing the emulator system with actual peripheral input devices, or obtained from an actual transaction system including such input devices. Alternatively, one or more of such input test data logs are created by other means, such as by a program, a text editor, or the like. In one embodiment, an output log of data

resulting from the input test data is created and, if desired, compared against a log of known, valid data corresponding to the input test data.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram depicting an emulator constructed in accordance with the teachings of this invention utilized with a transaction system; and

Figure 2 is a block diagram depicting the

interconnection between the computer performing the emulation and the transaction terminal.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

Figure 1 is a block diagram depicting one

embodiment of emulator 104 constructed in accordance with the teachings of this invention. Emulator 104 includes means for the emulation of input devices 106 which is interfaced with transaction terminal 101 to provide emulated input data to transaction terminal 101. Emulator 104 also includes means for the emulation of output devices 107 which is interfaced to transaction terminal 101 in order to receive output data from transaction terminal 101. Transaction terminal 101 is also capable of receiving input data from actual input devices 102 and provide output data to actual output devices 103.

Emulator 104 serves to emulate one or more input devices and one or more output devices such that

terminal 101 operates as if those devices were

physically present. Emulation of input devices 106 receives input directly, for example from a mouse or a keyboard, or from input log 105. The emulation of output devices 107 provides output data to a display such as a CRT screen, and/or stores data to one or more output logs 108. Output logs 108 are capable of being analyzed in order to determine whether the system is properly functioning in response to input data. In one embodiment, as shown in Figure 1, a standard output log 109 is used such that known valid data stored in standard output log 109 is compared with the actual received data stored in output log 108 by log analyzer 110, and in response to this analysis a display is provided by analysis display 111. In one embodiment of this invention, one or more such sets of test data are captured either utilizing the emulator system with actual peripheral input devices, or obtained from an actual transaction system including such input devices. Alternatively, one or more of such input test data logs are created by other means, such as by a program, a text editor, or the like.

Such input test data logs 105 are useful in order to test peripherals and application software. For example, when either a new peripheral or application software program, or modifications to peripheral or application software, are desired, simulation can be performed utilizing a large amount of input test data in order to verify accurate results. One or more output data logs 108 can, if desired, be maintained so that test results can be verified and, if necessary, the exact location of an error determined. Alternatively, output data is verified on the fly. In one embodiment, a combined input data/output data log is provided such that input test data is utilized and known valid output data is provided for comparison purposes. If desired, an error log is maintained, or errors are presented to the user, for example via a CRT or printer.

In accordance with the teachings of this invention, hardware peripherals may be replaced in different patterns giving a wide variety of testing and

development situations. A major use is for testing application software. Another important use for the emulator of this invention is for testing additional peripherals and interface circuitry. For example, a new version of a peripheral is tested by connecting the new peripheral to the emulator system with other peripherals being emulated. In this manner, a complete transaction system including the new peripheral is emulated in order to determine whether the new peripheral, its interface circuitry, and software will operate properly in actual transaction system.

An emulator of this invention provides great flexibility by allowing various types of replacement. Examples of basic functions which are capable of being performed in accordance with the teachings of this invention include: • Replacing an input device with a

program emulating that device

• Replacing an input device with a log

of input data

• Replacing an output device with a

program emulating that device

• Supplementing the output emulation

with capturing the data in a log

file

• Replacing operator interpretation of

output with software comparison of

one output file with another output file

Among the advantages of the emulator of this invention are:

• a device may be emulated when it is

not actually available or physical

properties of the device impose

limitations, such as a device for controlling a hazardous substance,

such as gasoline, or a phone line for calling a credit card

authorization or verification

service, which you may not wish to call during testing, and for which you wish to provide known response during testing. • a device may be emulated to handle

high volume of data or provide high accuracy for standard tests

• logged output data may be carefully

analyzed in conjunction with the

logged input data and compared with previously validated output data

In one embodiment of this invention, Microsoft Windows is used as an environment for the emulator of this invention. As is well known, Microsoft Windows provides multi-tasking features and a graphical, object oriented interface. This embodiment includes, for each peripheral capable of being emulated, a window which provides the I/O facilities specific to that peripheral. For example, the keyboard window displays the keypad, and a key value is input via the PC keyboard or via a mouse. In one embodiment, the emulator has been

developed under Microsoft C using Windows Software

Development Kit (SDK). Furthermore, in this embodiment, the emulator runs on a MS DOS machine, such as an IBM AT personal computer, or a clone thereof. The transaction system application software is run on a Motorola 68302 microprocessor system. Naturally, the teachings of this invention apply equally regardless of what platform the emulator runs on, and what platform the application software runs on. The choice of an MS DOS machine to run the emulator was made due to the wide availability and popularity of such machines and the choice of the Motorola 68302 microprocessor to run application

software was made because a particular embodiment of the system sought to be emulated utilizes the Motorola 68300 family of devices.

The peripheral hardware depends on which devices are being emulated. Figure 2 shows a setup with only emulated peripherals. The maximum number of peripherals emulated is less than or equal to the number of serial ports ("com ports") on the machine running the emulator, as each peripheral interfaces to application software platform 101 via the RS-232 serial interface of the MS DOS machine. As shown in Figure 2, emulator 104

emulates keyboard 104-1, display 104-2, printer 104-3, magnetic stripe reader 104-4, and bar code reader 104-N. Emulations 104-1 through 104-4 are connected through com ports on the computer running emulator 104. Test tiles 201-1 through 201-4 serve to interface the various com ports of the computer running emulator 104 and the internal bus of transaction terminal 101. Also as shown in Figure 2, bar code reader 104-N is connected via a com port on the computer running emulator 104 to a com port available on transaction terminal 101. Thus, emulator 104 is capable of emulating peripherals

regardless of whether those peripherals are

interconnected with the internal bus of terminal 101, or to a com port of terminal 101.

Types of Emulator Operation

Testing applications: In this type of testing the focus is on verifying that the application software is working properly. This is particularly useful when developing new application software and when modifying existing application software. This is beneficial whether or not this application software is being developed or modified in response to a new or modified peripheral. Testing peripherals: Comparing the operation of a physical device with its software emulation serves as a test for both. Creation of Test Cases: This involves recording input keystrokes and recording outputs. These may involve large volumes of input data and output data.

Running automatic comparisons of test results with previously recorded results: In one embodiment of this invention, a script format is used for providing an input data log in which lines are delineated by a CR; keys are delineated by a comma or a space; key names are alphanumeric ASCII strings as defined in a KEYNAME.H file; and each line is identified with a four character ASCII string to correlate the input script with the output log.

In one embodiment of this invention, as a test is running from a script, the inputs are individually identified as they are received by the emulator and listed in the window. In this embodiment, script files are identified by the suffix .GSC to a user supplied or default filename. Furthermore, in this embodiment, script files may contain elements not present in "real" input data, such as PAUSE and REMARK commands.

Display window output may be captured for later analysis and automatic comparison with other captured output, our output generated in any convenient manner, e.g. via suitable computer program. One embodiment of this invention, the display format is chosen by the user, for example, from a menu, in order to allow the use of a wide choice of easily analyzed data output formats.

In one embodiment, the display function utilizes pseudo windows. These are not windows as defined within MS Windows, but their appearance on the screen is the same as on the actual peripheral device being emulated. If desired, long lines will truncate rather than wrap around. The emulated display function receives display lines from the application software just as the actual peripheral display device would receive display

information.

Display window output may be captured for later analysis and automatic comparison with other captured output, or known valid output data.

Each of the above features of this invention pertaining to displays are also applicable to the emulation of various printers.

The analysis function accepts as input two log files created during two different sessions. Normally, one log file 109 is a trusted version of known valid data that serves as a standard. A second output log file 108 stores the actual output data of the

emulation. The two log files are compared character for character, line by line. Inequalities are brought to the attention of the operator and require manual

intervention to continue. An inequality can be bypassed and the comparison continued by stepping one or both of the log files beyond the records which caused the break. The compare function is sensitive to the record formats, and in one embodiment does not cause an inequality break for date or time discrepancies.

Appendix I entitled "GemStone™ Transaction

SuperSysterns™ - An Introduction to the Gemulator™" is a document providing additional information pertaining to one embodiment of an emulator constructed in accordance with the teachings of this invention.

Appendix II is a software listing of C code

suitable for compilation and running on an MS DOS platform to function as an emulator in accordance with one embodiment of this invention.

All publications and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication or patent application was specifically and individually indicated to be incorporated by reference.

The invention now being fully described, it will be apparent to one of ordinary skill in the art that many changes and modifications can be made thereto without departing from the spirit or scope of the appended claims.

GemStone™ Transaction SuperSystems™

An Introduction to the Gemulator™

This document contains VeriFone's confidential and proprietary information. Use of this document is prohibited except as authorized by VeriFone, Inc.

This document is subject to change without notice.

GemStone^™ Transaction SuperSystems^™

An Introduction to the Gemulator^™

VeriFone Manual Part Number xxxxx. Revision x

Manual Revision 0.01

Published Draft: December 1990

VeriFone^™, Inc.

Technical Publications Group

100 Kahelu Avenue

Milliani, Hawaii 96789

(808) 623-2911

Printed in the United States of America

No part of this publication may be copied,

distributed, stored in a retrieval system, translated into any human or computer language, transmitted, in any form or by an means, without the prior written consent of VeriFone, Inc.

VeriFone^™, GemStone^™, Transaction SuperSystems^™, and

Gemulator™ are trademarks of VeriFone, Inc.

IBM® and IBM PC® are registered trademarks of

International Business Machines.

MS-DOS^™ is a trademark of Microsoft Corporation. Table of Contents

The Gemulator^™

Advantages of Using the Gemulator^™.........1

Environment ................................1

Software Environment ...................1

Hardware Environment...................3

Keyboard Emulation..........................4

Scanner Input...............................4

Display Emulation ...........................4

Printer Emulation...........................4

Printer/Display Playback and Analysis ......5

The Gemulator^™

In the GemStone^™ System, the ability to test applications and peripherals without the actual use of physical hardware is performed by the Gemulator^™. The Gemulator^™ imitates any GemStone™ hardware peripheral using a software counterpart.

Peripherals may be replaced in different configurations, allowing a wide variety of testing and development situations. The Gemulator^™ process provides great

flexibility by combining various types of replacement, such as:

• Replacing an input device with a

program emulating that device.

• Replacing an input device with a log file emulating that device.

• Replacing an input device with a

program emulating that device.

• Supplementing output data through the Gemulator^™ by capturing the data in a log file.

• Replacing operator interpretation of output with software comparisons of one output file to another output file.

Refer to Figure 1 for an overall diagram of the emulation process.

Advantages of Using

the Gemulator^™ The following are just a few of the

advantages of using the emulsion process:

• A device may be emulated when it is not physically available or physical properties of the device impose limitations.

• A device may be emulated to handle high volumes of data or provide high accuracy for standard tests.

• Logged output data may be carefully analyzed in conjunction with the logged input data and compared with previously validated output.

Environment The Gemulator^™ environment consists of both software and hardware. Software Equipment The software environment for the Gemulator^™ process is Microsoft^™ Windows, which

provides multi-tasking features and a graphical, object-oriented interface. A window for each peripheral provides the input/output facilities specific to that peripheral. For example, the keyboard window displays the keyboard and a key value is input via the "mouse" device.

Note : The Gemulator^™ was developed under Microsoft C using the Windows Software

Development Kit .

SU

GemStone™ Transaction SuperSystems™ Programmer's Manual

Keyboard Emulation

• Input through the Windows-emulated keyboard may be entered directly using a mouse or read offofa script.

• A script may be created by capturing mouse input to a window or by using a text editor.

• The format ofa script is as follows:

• Lines are delineated by a CR (carriage return);

• Keys are delineated by a comma or a space;

• Key names are alphanumeric ASCII strings as defined in KEYNAME.H;

• Each line is identified with a 4-character ASCII string to correlate the input script with the output log.

• While a test is running from a script, the keys will be individually identified as they are received by the Gemulator™ and listed in the window.

• Script files will be identified by the suffix. GSC to a user-supplied or default

filename.

• Script files may contain elements not present in "real" input, such as PAUSE and

REMARK commands.

Scanner Input

Scanner input is emulated by reading a text file. There are standard scanner test files that can be modified or replaced using a text editor. The test files include

information occurring in first and last entries in blocks and files.

Display Emulation

• Display windows output may be captured for later analysis and automatic comparison.

• The Display format is chose by the user from a menu.

• The display function accommodates the pseudo windows as defined with the

GemStone™ applications. These will not be windows as defined within Microsoft™ Windows, however, their appearance on the screen will be the same as on the physical device. Long lines are truncated rather than wrapped around. GemStone™ Transaction SuperSystems™ Programmer's Manual

• The display function receives display lines from the applications.

• Files recording the display lines will be suffixed by .GDS to a user-supplied or

default filename.

Printer Emulation

• The printer window output may be captured for later analysis and automatic

comparison with other captured output.

• The printer function emulates the printer chose by the user from a menu.

• The printer function receives print lines from the applications.

• Files recording the print lines will be suffixed by .GPR to a user-supplied or default filename.

Printer/Display Playback and Analysis

• The analysis function accepts as input two log files created during two separate tests.

Normally, one log file tested and found to be coπect is used as a standard.

• The two log files are compared character-for-character, line-by-line. Inequalities are brought to the attention of the operator and require manual intervention in order to continue.

• An inequality can be bypassed and the comparison continued by stepping one or both of the log files beyond the records causing the break.

• The compare function is sensitive to the record formats and does not cause an

inequality break for data or time discrepancies.



to





Claims

WHAT IS CLAIMED IS:

1. A transaction system emulator comprising:

a transaction system CPU including means for communicating with one or more peripheral devices, selected from one or more of high speed synchronous serial bus, serial com port, parallel bus;

means for emulating one or more peripheral devices, each as a separate multitasking task;

means for providing communication between each of said emulated peripheral devices and said means for communication of said transaction system CPU.

2. A transaction system as in claim 1 wherein selected ones of said tasks are capable of communicating with each other without the necessity of communicating via said transaction system CPU.

3. A transaction system emulator as in claim 1 wherein a selected one or more of said emulated

peripherals comprise input devices to said transaction system CPU, and wherein said emulator further comprises means for obtaining user input data to control said emulated peripherals provide input data to said

transaction system CPU.

4. A transaction system emulator as in claim 1 wherein a selected one or more of said emulated

peripherals comprise input devices to said transaction system CPU, and wherein said emulator further comprises one or more input data logs for causing said selected one or more of said emulated peripherals to provide input data to said transaction system CPU. S. A transaction system emulator as in claim 1 wherein a selected one or more of said emulated

peripherals comprise output devices to said transaction system CPU, and wherein said emulator further comprises means for the output data in response to data received from said transaction system CPU, and for providing responses to said transaction system CPU. 6. A transaction system emulator as in claim 1 wherein a selected one or more of said emulated

peripherals comprise output devices to said transaction system CPU, and wherein said emulator further comprises one or more output data logs for storing output data from said selected one or more of said emulated

peripherals in response to said transaction system CPU.

7. A transaction system emulator as in claim 6 which further comprises means for validating the data stored in said one or more output logs.

8. A transaction system emulator as in claim 7 wherein said means for validating comprises:

one or more standard output logs for storing known valid data corresponding to said input data stored in said one or more input logs; and

comparison means for comparing said known valid output data with said emulated output data. 9. A transaction system emulator as in claim 4 which further includes means for providing said one or more input data logs in response to actual data entry made to said transaction system emulator. 10. A transaction system emulator as in claim 6 which further includes means for providing said one or more output data logs in response to output data generated in response to actual data entry made to said transaction system emulator.

11. A transaction system emulator as in claim 1 wherein a selected one or more of said emulated

peripherals comprise output devices to said transaction system CPU, and wherein said emulator further comprises means for validating the output data from said emulated peripherals. 12. A transaction system emulator as in claim 9 wherein said means for validating comprises:

one or more standard output logs for storing known valid data corresponding to expected output data from said one or more selected peripherals; and

comparison means for comparing said known valid output data with said emulated output data.

13. A transaction system emulator as in claim 1 wherein:

a selected one or more of said emulated peripherals comprise input devices to said transaction system CPU; said emulator further comprises one or more input data logs for causing said selected one or more of said emulated peripherals to provide input data to said transaction system CPU;

a selected one or more of said emulated peripherals comprise output devices to said transaction system CPU; said emulator further comprises one or more output data logs for storing output data from said selected one or more of said emulated peripherals in response to said transaction system CPU;

said emulator further comprises means for

validating the data stored in said one or more output logs, said means for validating comprising:

14. A transaction system emulator as in claim 11 which further includes means for providing said one or more output data logs in response to output data generated in response to actual data entry made to said transaction system emulator.

15. A transaction system emulator as in claim 11 which further comprises:

means for generating said input data log from data gathered from a transaction system in actual use.

16. A transaction system emulator as in claim 13 which further comprises:

means for generating said standard output log from said data gathered from said transaction system in actual use.