Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
2000-05-31
2001-01-30
Beausoliel, Jr., Robert W. (Department: 2785)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S046000, C714S738000
Reexamination Certificate
active
06182246
ABSTRACT:
TECHNICAL FIELD
This invention relates to product quality assurance and to test systems and methods for validating operating systems provided in computerized products. More particularly, the present invention relates to product quality assurance and to test systems and methods for validating an operating systems during the development of computerized products. Even more particularly, the present invention relates to product quality assurance and to test systems and methods for validating operating systems, such as Windows CE, manufactured and sold by Microsoft, Incorporated of Redmond, WA, typically provided in computerized products.
BACKGROUND OF THE INVENTION
Increasingly, developers are embedding operating systems, such as Windows CE, into many different types of computerized products, including set-top boxes, gaming systems, bar-code scanners, and factory automation systems. As Windows CE has grown, so too has the need for “off-the-shelf” software development tools. Although many tools and “off-the-shelf” software kits have been on the market for saving device design time, leading to speedy device development, no fast testing system or method existed to verify compatibility of these new products, especially at the final stages of device development.
Traditionally, only two operating system device testing options have been available: (1) in-house writing of the test code, or (2) out-sourcing the custom code development to another firm. To complete the testing project in-house, Original Equipment Manufacturers (OEMs) must spend months training their staff, more months developing the test codes, and yet even more months of preparation before their product can be tested using such codes. Likewise, an out-source custom code development house would spend months writing the code. Thus, both options are time-consuming and, therefore, costly.
In related art quality assurance device testing systems, several network protocols are used which suspend program execution while waiting for an acknowledgment of a sent message. For example, Transmission Control Protocol (TCP), at a low level, blocks program execution until certain sent messages are acknowledged by the remote end of a “connection.” Most protocols are implemented in an O/S-independent manner. As such, sent messages requiring an acknowledgment must be maintained in a list which cross-references the identification of a sent message with an execution thread, such thread waiting for such acknowledgment. Such related art systems follow a lengthy sequence: creating a message ID prior to sending the initial message; adding an element in a list associating the execution thread with the message ID; sending the message; blocking the sending thread of the execution until the receiving code unblocks it; acknowledging, by the remote process, the sent message by sending back an ACK message containing the original message ID; receiving ACK message by the sending machine; parsing for the message ID of the originally sent message; looking-up the message ID in the list; determining which execution thread to release from the list; and finally, releasing the original sending thread of execution to continue program execution.
These time consuming operating system device testing options have created a long-felt need for a consolidated testing system and method, utilizing a protocol acknowledgment between homogeneous systems, for improving product quality, imparting time and cost savings of many person-months, and streamlining of the product development process. In particular, a system and method for testing and validating devices having an embedded Windows CE operating system installed is needed to overcome the foregoing problem and thus provide a system and method which improves product quality, imparts time and cost savings of many person-months, and streamlines the product development process resulting in a fully automated design verification package for device designers. In particular, a need exists for a system which uses O/S-provided events, an O/S-internally-maintained event list, and an O/S-internally-maintained blocking threads (i.e. sending threads) list. Thus, unlike related art protocol acknowledgment methods, several steps need to be eliminated (e.g., adding an element which associates the execution thread with the message ID in a list, cross-referencing the message ID in a list, and determining which execution thread to release from a list entry).
Thus, a code which is simpler, shorter, and less error-prone via an alternative method of processing ACKs would be beneficial where a plurality of actions could be executed upon reception of an acknowledgment message (e.g., multiple cross-referencing and attendant delays elimination, code for the reception of ACK which is largely identical with a single-thread case, priority data which need not be maintained in a sent message list if multiple threads are prioritized, and an ID list which need not be entirely scanned to determine a thread-release priority as an O/S restarts all threads with an appropriate priority). A beneficial system would also be able to implement multiple pending threads of execution which are waiting for an ACK message, the threads needing merely to use the O/S-provided function of waiting for an event handle which was embedded by the initial “send” in the protocol header. Likewise advantageous, multiple threads of execution should be triggered, without additional cross-reference processing, by an ACK for any message of a plurality of sent messages.
BRIEF SUMMARY OF THE INVENTION
Accordingly, the present invention, to be commercially available under applicant's assignee's trademark of CEValidator™, is an operating system validator, (herein also referred to as O/S Validator, and designated in the Figures with the numeral “
1
,” which solves the foregoing problems by providing a test system encompassing an automated test suite method for testing a port of an operating system, such as Windows CE, in a target device's hardware and/or software being newly developed. The O/S Validator comprises a comprehensive code base, specifically developed to purposefully stress the O/S, device driver, OEM Adaptation Layer (OAL), and hardware interaction through the use of a unique contemporaneous multithreaded execution methodology for acknowledging protocol between homogeneous systems. The provided test suites focus on identifying three primary defects: hardware design, hardware programming (drivers/OAL), and operating system interaction. Special diagnostic emphasis is placed on Windows CE subsystems which have historically shown the most problems. The test suites comprise nearly 1500 tests which include system stress-testing routines, as well as feature-and-function tests, providing a complete analysis of a Windows CE port. These tests are grouped by the O/S Validator. The O/S Validator includes both test source codes and executable programs for all tests.
To simplify execution of test suites and collection of logging results, an intuitive user interface for the O/S Validator host component, such as a standard Windows application leveraging the Microsoft Windows user interface, is utilized. The O/S Validator distributes test suites as a client/server application. A graphical user interface (GUI) interacts with a small application, CEHarness.exe, which is running on a target device. Because this communication may occur over Ethernet, at least one host may run suites against at least one target device.
The O/S Validator generates useful error information when a target device fails a test. While the suites are running, results are displayed in a plurality of dynamically created log windows as well as in a configuration's summary tab. The logging windows contain the full text of a given test's results. Failures are color-coded red to ease identification. Navigation buttons in the logging window allow the user to quickly move from one failure to another. The logging APIs in the tests also cause a prolog and an epilog to be generated in each result file. Information
Boyce David Matthew
Ding Jie H.
Gregory Peter R.
Lucas Shawn Michael
Sample Ian
Baderman Scott T.
Beausoliel, Jr. Robert W.
Bsquare Corporation
Laiviere, Grubman & Payne, LLP
LandOfFree
Protocol acknowledgment between homogeneous system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Protocol acknowledgment between homogeneous system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Protocol acknowledgment between homogeneous system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2527574