TECHNICAL FIELD

[001] Embodiments disclosed herein relate to the field of hardware test automation, and more particularly to a tool that eliminates requiring any knowledge of coding or programming to perform hardware test automation.

BACKGROUND

[002] Traditionally, hardware testing is performed using a plurality of development environments. In order to use a development environment, a user may need to be proficient in the programming language associated with the development environment. Moreover, the development environment used for testing one type of hardware may not be suitable for testing a different type of hardware. As the programming language for each development environment may vary, this can lead to entities that manufacture multiple types of hardware to bear additional costs as they may need to employ workers that are proficient in a plurality of programming languages. Therefore, it is desirable to have a tool that can uniformly work across several types of hardware and allows a user to perform the hardware testing without the user having any background knowledge in programming.

OBJECTS

[003] The principal object of embodiments herein is to disclose systems and methods for implementing a tool that eliminates a knowledge requirement of coding or programming in hardware test automation.

[004] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating at least one embodiment and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

BRIEF DESCRIPTION OF FIGURES

[005] Embodiments herein are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[006] FIG. 1 illustrates a system for implementing the tool for automated testing of a hardware equipment, according to embodiments as disclosed herein;

[007] FIG. 2 illustrates the architecture of the tool for automated testing of the hardware equipment, according to embodiments as disclosed herein;

[008] FIGs. 3A and 3B illustrate example screenshots of the database and keyword architecture of the tool, according to embodiments as disclosed herein;

[009] FIG. 4 illustrates an example screenshot of a test report generated by the tool, according to embodiments as disclosed herein; and

[0010] FIG. 5 illustrates a method for performing the automated testing of the hardware equipment using the tool, according to embodiments as disclosed herein. DETAILED DESCRIPTION

[0011] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0012] The embodiments disclosed herein enable automated testing of hardware equipment without requiring a user to have any knowledge of coding or programming. The instrumentation and measurement suit (IMS) is a tool that comprises a plurality of application programming interfaces (APIs) to enable hardware test automation in hardware manufacturing, design and development, and validation and verification industry. A user may input to the IMS a test plan that includes instructions. The instructions in the test plan may be provided by the user in a specific format that the IMS may be able to interpret. Based on the interpretation of the instructions in the specific format, the IMS may perform certain actions associated with the instructions on the hardware device. The user may be informed, through a manual or an information sheet, about the instructions to be provided and the format in which the instructions may need to be in for the IMS to correctly interpret the instructions. The instructions and the format of the instructions can be such that a layperson (a person without any background knowledge in programming or coding) can understand, and accordingly include in the test plan to be input to the IMS. [0013] An advantage of the IMS over traditional integrated development environments (IDEs) is that it can be easier to implement as the end user need not be well versed with any programming knowledge, which is required for traditional IDEs. Another advantage is that it can be cost- effective for hardware/equipment manufacturers. Since different IDEs may require knowledge of different programming languages, it can be expensive for any hardware/equipment manufacturer to find an employee/employees that are proficient across various programming languages. The IMS can uniformly work across multiple kinds of hardware devices/equipment as the application programming interfaces (APIs) in the IMS can support a plurality of communication protocols to communicate with multiple kinds of hardware devices/equipment. Compared to traditional IDEs, the IMS may offer quicker development to deployment lead-time due to its simplistic nature that enables a layman to utilize it.

[0014] Referring now to the drawings, and more particularly to FIGS. 1 through 5, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.

[0015] FIG. 1 illustrates a system 10 for facilitating the IMS 100 to perform automated testing of hardware equipment 108 (also referred to as “hardware devices” herein), according to embodiments as disclosed herein.

[0016] The system 10 comprises a user computing device 102. The user computing device 102 (UCD 102) may comprise a memory 112 and a processor 122. Examples of the UCD 102 can be a personal computer (PC), a desktop computer, a laptop computer, a notebook, a smartphone, or the like. Depending on the kind of UCD 102, the memory 112 may vary. Examples of the memory 112 can be, but is not limited to, volatile (for example random access memory (RAM)), non-volatile (for example readonly memory (ROM)), flash memory, or any other memory technology that can be used to store information and can be accessed by the UCD 102. The memory 112 may be configured to store the test plan 106 that is input to the

IMS 100.

[0017] The test plan 106 may be a set of instructions, provided by the user, to be interpreted by the IMS 100. The user may provide the IMS 100 with the test plan 106 through the UCD 102 or through a test plan database 116. The user may input the test plan 106 to the UCD 102 through an input device in the UCD 102, such as, but not limited to, a keyboard, a mouse, a sound input device, a touch input device etc. Depending on the manner of providing input, for example a keyboard, the test plan 106 may be stored in the UCD 102 in a standard file format, such as, but not limited to, a spreadsheet file format, a database file format, a plain text file format etc. If the user inputs the test plan 106 through a sound input device, the test plan 106 may be stored in the UCD 102 in an audio file format. The IMS 100 may access the test plan 106, which may be provided to the IMS 100 by the user. The test plan 106 may contain instructions that are provided to it by the user in a specified manner or format that can be interpreted by the IMS 100 to perform one or more functions. In other embodiments, the test plan 106 may be stored in a test plan database 116, which the IMS 100 can access. The test plan 106 can be stored in any standard database file format. In some embodiments, the IMS 100 may have a feature that allows the user to manually select the tests to be performed, the hardware device 108 on which the action is to be performed, any desired range of values, and any other input. The user may be able to perform the selection based on a list provided to the user by the IMS 100. The user’s selection(s) may be considered as the test plan 106 having the instructions to carry out the user’s selections.

[0018] Based on the interpretation of the instructions, the IMS 100, with the help of a processor 122, may perform a series of actions, associated with the interpretation of the instructions in the test plan 106, on a hardware device 108. The IMS 100 may be configured to check for at least one specific term in the test plan 106 and may also be configured to associate that at least one specific term with one or more actions. For example, if a user provides a verbal or written input of an instruction such as “SET P0.1 TRUE” then the IMS 100 may interpret the first term, “SET,” as being instructed to perform the operation of setting a value. The second term, “P0.1,” may be interpreted by the IMS 100 as the device 108 or the part of the device 108 on which any operation is to be performed. In this particular example, the IMS 100 may interpret it as performing an operation of setting a value for the general- purpose input output (GPIO) pin P0.1 of an integrated circuit (IC) (an example of the hardware device 108). The third term, “TRUE,” can be interpreted by the IMS 100 to determine what value is to be set, which in this example would be to enable the GPIO pin P0.1. In this specific example, the format of the instructions may be provided in the order of: a) action to be performed b) the device 108 on which the action is to be performed, and c) the value, if any, of any action that is to be performed.

[0019] Another example can be when a user provides a verbal or written output of an instruction such as “MEASURE SERIAL C0M6” when a digital multimeter (an example of the hardware device 108), is communicating with the IMS 100 through the serial communication port 6. In response to this instruction, the IMS 100 may output the value of the measured voltage. The hardware device 108 may communicate with the IMS 100 either directly, or through the user computing device 102. The above examples regarding the format of the instructions provided by the user or the interpretation by the IMS 100 are merely illustrative and is not to be construed as limiting the format of the instructions or limiting the IMS 100 to only being to interpret the instructions in the example formats.

[0020] Once the IMS 100 has performed the actions associated with the instructions in the test plan 106, the IMS 100 may output a test result 110 indicating the result of the action(s) performed. The test result 110 can be made available to the user through, such as, but not limited to, a graphical user interface (GUI) 202 on the IMS 100, a report generated by the IMS 100 that may be stored in a file format in the UCD 102 or a test result database 120, or a notification made to the user by any visual or sound output devices available in the UCD 102. In some embodiments, a single database may be used to accommodate the test plan 106 and any generated report having the test result 110.

[0021] The IMS 100 may be embodied such as, but not limited to, a website, a web application, a desktop application, or a mobile application compatible with the UCD 102. Depending on the embodiment of the IMS 100, the UCD 102 may communicate with the IMS 100 through different kinds of network. Examples of the network can be the Internet, WAN, MAN, or LAN. They network may use standard communication technologies and/or protocols.

[0022] FIG. 2 illustrates the architecture of the IMS 100 for automated testing of the hardware equipment 108, according to embodiments as disclosed herein. The IMS 100 may have a GUI 202 to display the various features offered by the IMS 100. The IMS 100 may further comprise a plurality of application programming interfaces (APIs) 204. The IMS 100 may have an instrumentation API with various communication protocols such as, but not limited to, LXI, USB, Serial, RS485, RS422, and GPIB, for communicating with the hardware device 108. Examples of the hardware devices 108 that may be applicable to the instrumentation API can be testing equipment, such as, but not limited to, a digital multimeter, a power supply, a cathode ray oscilloscope, and any radio frequency (RF) equipment.

[0023] The IMS 100 may have a hardware device communication API for communicating with the hardware devices 108 through protocols such as, but not limited to, MODUS, ANSIC12.0, DLMS/COSEM, SPI, i2C, UART, Serial, RS485, RS422, USB, LAN, Bluetooth, Wi-Fi, and GSM. Examples of hardware devices 108 that may be applicable to the hardware device communication API can be an electronic printed circuit board (PCB) assembly, an electronic product, and a mechanical product with/without electronics.

[0024] The IMS 100 may further comprise an IC/Microchip programming protocol API for communicating with programmable devices, such as, but not limited to, microcontrollers/microprocessors, FPGA, complex programmable logic devices (CPLD), digital signal processors (DSPs), system on a chip (SOC), ROM, and Flash. Examples of protocols that may be used are joint test access group (JTAG), compact JTAG (cJTAG), serial wire debug (SWD), and USB. The IC/Microchip programming protocol API may also be used to load any firmware or OS onto a microchip/IC.

[0025] The IMS 100 may further comprise a hardware multiplexing and switching API for communicating with the hardware device 108 using protocols such as, but not limited to, peripheral component interconnect (PCI), PCI express (PCIe), USB, Ethernet, and Serial Communication. Examples of hardware devices 108 that may be application to the hardware multiplexing and switching API may be digital input/output devices, analog input/output devices, and switching and multiplexing devices.

[0026] The IMS 100 may further comprise a file input/out (I/O) API or a database communication API to receive and interpret the instructions in the test plan 106. Based on the interpretation of the instructions, the IMS 100 may initiate communication with the hardware devices 108 in a parallel or serial thread, and perform a series of actions associated with the instructions in the test plan 106. Examples of the series of actions can be testing the hardware device 108, outputting a test result 110, which can be generating a user customized test report for each iteration of testing. A custom test report generation API may be used to generate a user customized test report. This customized test report may be made available in the memory 112 of the UCD 102, or in a test result database 120 that the UCD 102 may access. There may be a user alert API to output the test result 110 through a notification that a user may receive through any visual or sound output devices in the UCD 102. An example of this notification can be an alarm.

[0027] FIGs. 3A and 3B illustrate example screenshots of the database and keyword architecture of the tool 100, according to embodiments as disclosed herein. The screenshots in FIGs. 3A and 3B illustrate a table with a plurality of columns. Regarding FIG. 3 A, the column with the text “testPlanCode” can display to the user a unique identifier associated with the test plan 106. The column with the text “testName” can display to the user the type of test that would be performed, and the column with the text “testID” can display to the user a unique identifier associated with the test being performed. The column with the text “testDescription” can provide a description that includes details regarding the test being performed.

[0028] Regarding FIG. 3B, depending on the pin as indicated by the column with the text “dioPin,” the user may request the IMS 100 to output the value of one or more pins. If the output value of the one or more pins is in a desired range, the status of the test may indicate the result of the test as a pass or a success. In FIG. 3B, the columns with the text “lowerLimif ’ and “upperLimif ’ can indicate the desired range of output values of the one or more pins. The output value of the one or more pins may be indicated in the column with the text “nominal Value.” The IMS 100 can check if the output value is in the desired range, and if so, the column with the text “testStat” can indicate with a letter “Y” if the values in the “nominal Value” column is in the range of the values in the “lowerLimit” and “upperLimit” columns. The values that may be input to the IMS 100 may be represented in integers (0, 1, 2, 3....) with or without decimal points, or as binary inputs (0 or 1 / TRUE or FALSE). In some embodiments, where a desired range is not set, the values in the “upperLimit” column and “lowerLimit” column may be blank or include a reference for non-applicability.

[0029] FIG. 4 illustrates an example screenshot of a test report generated by the tool, according to embodiments as disclosed herein. The test report may have a column that indicates the total number of tests performed and the sequence in which one or more tests were performed. For each type of test performed, there may be at least one column that indicates a unique identifier for the test performed and a description of the test performed. The report can also include a test result 110 that indicates a result of the test performed. The result 110 may be displayed as a “PASS” or a “FAIL” if the test performed is one to check if a device 108 or a part of device 108 is working properly or if the test performed was an operation to enable a pin of the device 108. In case the test performed was a measurement test where a value was to be displayed, the test result 110 may display the measured value. If the test result 110 is a “PASS” or if the test result 110 is a measured value that is in a desired range, then the test result 110 may be indicated in a shade of green color. If the test result 110 is a “FAIL” or if the test result 110 is a measured value that is outside of a desired range, then the test result 110 may be indicated in a shade of red color. There may be another column for including any remarks by the IMS 100 regarding a test that was performed, For example, if the test result 110 was a “FAIL,” then the remarks can include the reason for the failure of the test.

[0030] FIG. 5 illustrates a method 500 for performing the automated testing of the hardware equipment using the IMS 100, according to embodiments as disclosed here.

[0031] At step 502, the IMS 100 may receive the test plan 106. The IMS 100 may receive this test plan 106 from the user either through the UCD 102 or through the test plan database 116. [0032] At step 504, the IMS 100 may interpret the instructions in the test plan 106. The instructions in the test plan 106 may be provided by the user in a specific format that enables the IMS 100 to interpret the actions.

[0033] At step 506, the IMS 100 may initiate communication with one or more hardware devices 108, on which any actions associated with the instructions in the test plan 106 need to be performed.

[0034] At step 508, the IMS 100 may perform the one or more actions based on the interpretations of the instructions in the test plan 106 on the one or more hardware devices 108.

[0035] The various actions in method 500 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 5 may be omitted.

[0036] In some embodiments, prior to performing any actions on the one or more hardware devices 108, the IMS 100 may perform a verification of the actions to be performed, incase there is an error in the IMS’ 100 interpretation of the instructions in the test plan 106. In one verification method, the IMS 100 may display or indicate to the user a message with the description of the tests to be performed, and this message may further require an input from the user to confirm or deny if the description of the tests that would be performed is accurate. If the user confirms that the descriptions of the tests are accurate, the IMS 100 may proceed with performing the one or more tests associated with the interpretations. If the user finds that the description of the test to be performed is inaccurate, there may be a feature for the user to manually select at least one test that is to be performed, which the user may select from a drop-down list that includes the various tests that can be performed by the IMS 100.

[0037] In some embodiments, the IMS 100 may verify the status of the actions performed, in order to determine whether the actions were successfully performed or if there was any failure. For example, if the test or action to be performed was to enable a certain pin, then upon enabling the pin, the IMS 100 can measure the value of the pin to see if it is enabled. Based on this, the IMS 100 can conclude that the test or action was successfully performed.

[0038] The IMS 100 may provide the user with a test result 110, which can indicate to the user with details related to the actions performed, such as, but not limited to, the action that was performed and the result or values of the action performed. For example, the IMS 100 may inform the user that it measured the speed of a microprocessor and also output the value of the speed of the microprocessor. The IMS 100 may provide the user with the test result 110 through a GUI 202, a report generated by the IMS 100 that may be stored in a file format in the UCD 102 or the test result database 120, or a notification made to the user by any visual or sound output devices available in the UCD 102.

[0039] In some embodiments, the IMS 100 may also verify the test result 110. In a first method, the IMS 100 can check if the test result 110 falls within a desired range of values, and if so, the IMS 100 may conclude that the test result 110 is accurate. In a second method, the IMS 100 may perform the same test a second time and check if the test result 110 is the same in the first time of the performance of the test and the second time of the performance of the test. If the test result 110 is the same in both times, the IMS 100 may conclude that the test result 110 is accurate. For example, if the test was pertaining to measuring the output value from a pin, if the output value is the same when measured both times, the IMS 100 may conclude that the output value is accurate. In some embodiments, an average value for multiple measurements of an analog hardware device 108 may be calculated to calibrate the accuracy of the analog hardware device 108. Examples of analog hardware devices 108 are multimeter and energy meter. [0040] Description of the embodiments disclosed herein use the term “test” and “action” interchangeably to refer to an operation that is performed on the hardware device 108.

[0041] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements.

[0042] The embodiments disclosed herein describe systems and methods for automated hardware testing without requiring any background knowledge in programming or coding. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in at least one embodiment through or together with a software program written in e.g. Very high speed integrated circuit Hardware Description Language (VHDL) another programming language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of portable device that can be programmed. The device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs.

[0043] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of embodiments and examples, those skilled in the art will recognize that the embodiments and examples disclosed herein can be practiced with modification within the spirit and scope of the embodiments as described herein.