Description:Technical Field
[001] This disclosure relates generally to ventilators, and more particularly to a method, a system, and a graphical user interface (GUI) for testing the ventilators.

Background
[002] Ventilators are medical devices long known to have been used to provide supplemental oxygen support to patients. The ventilators include a source of pressurized oxygen which is fluidly connected to the patient through a conduit. Further, some ventilators are designed to automatically adjust to changes in a patient's respiration. The rise in respiratory diseases especially after the pandemic due to the novel Corona Virus (2020) has spurred a huge demand for the ventilators. As such, manufacturing of ventilators has seen surge as well.
[003] The ventilator includes several components, and manufacturing the ventilator includes assembling these components. These components may include the pneumatic assembly, mechanical components, electronic hardware boards and supporting circuitry, software releases particular to respective hardware, firmware release, backend releases, BSP releases, and User Interface (UI) releases. Manufacturing further includes testing, which can be a time consuming and labor-intensive process, that makes repeated testability of the ventilators extremely challenging.
[004] In the development stage, in some scenarios, whenever there is a software release, the developer is required to check the software on a single machine. Further, there is limited availability for the extended testing. In other scenarios, when the machine is getting tested at the production level, the quality assurance (QA) team has to individually setup each ventilator manually to work in specified environment and further have to keep a check on them manually and record the status. However, this sometimes can result into missed abrupt behavior, which may have low reproducibility.
[005] There is, therefore, a need for an improved method and system for testing of the ventilators.

SUMMARY
[006] A method of testing ventilators is disclosed. In some embodiments, the method may include receiving a test input corresponding to one or more tests to be executed on a plurality of ventilators. Each of the plurality of ventilators may be communicatively coupled to the testing server over a first communication network. The method may further include, based on test input, executing the one or more tests on each of the plurality of ventilators. The one or more tests may be executed via one of: a predefined custom test template and a mode-specific test script. The method may further include obtaining test results data from each of the plurality of ventilators, in response to the execution on each of the plurality of ventilators. The method may further include generating a report based on the test results data associated with each of the plurality of ventilators.
[007] In some embodiments, receiving the test input may include receiving, via a test-mode User Interface (UI), a selection of at least one of: a predefined custom test template and a mode-specific test script. In some embodiments, receiving the test input may further include receiving an identity of the selected at least one of the predefined custom test template and the mode specific test script and fetching the at least one of the predefined custom test template and the mode specific test script from a data repository. In some embodiments, the report may be one of: a csv format-based report, a graphical image-based report, and a tabular format-based report. The method may further include analyzing the test results data associated with each of the plurality of ventilators, using Artificial Intelligence/Machine Learning model and generating a suggestion in association with the predefined test template or the mode-specific test script, based on the analysis. In some embodiments, the testing server may implement a Continuous Integration and Continuous Deployment (CI/CD) pipeline, and wherein the CI/CD pipeline is implemented via Jenkins application.
[008] Further, a testing server for testing ventilators is disclosed. The testing server includes a processor and a memory communicatively coupled to the processor. The memory stores a plurality of processor-executable instructions, which on execution by the processor, cause the processor to: receive a test input corresponding to one or more tests to be executed on a plurality of ventilators. Each of the plurality of ventilators is communicatively coupled to the testing server over a first communication network. The plurality of processor-executable instructions further causes the processor to execute the one or more tests on each of the plurality of ventilators based on the received test input. The one or more tests may be executed via one of: a predefined custom test template and a mode-specific test script. The plurality of processor-executable instructions further causes the processor to obtain test results data from each of the plurality of ventilators, in response to the execution on each of the plurality of ventilators and generate a report based on the test results data associated with each of the plurality of ventilators.
[009] Furthermore, a graphical user interface (GUI) client for testing ventilators is disclosed. The GUI client may be configured to receive a test input corresponding to one or more tests to be executed on a plurality of ventilators. The one or more tests may be executed on each of the plurality of ventilators based on the test input. Further, the one or more tests may be executed via one of: a predefined custom test template and a mode-specific test script. The GUI client may be further configured to obtain a report from a testing server and display the report. The report may be generated based on test results data associated with each of the plurality of ventilators in response to the execution the one or more tests on each of the plurality of ventilators.
[010] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[011] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles.
[012] FIG. 1 is a block diagram of a system for testing ventilators, in accordance with an embodiment.
[013] FIG. 2 is a functional block diagram of a testing server of the system for testing ventilators, in accordance with an embodiment.
[014] FIG. 3 is a functional block diagram of a system for testing ventilators, in accordance with an embodiment.
[015] FIG. 4 is a flowchart illustrating a method of testing ventilators, in accordance with an embodiment.

DETAILED DESCRIPTION
[016] Exemplary embodiments are described with reference to the accompanying drawings. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims. Additional illustrative embodiments are listed below.
[017] One or more techniques are disclosed for testing ventilators, using automation techniques for executing test scripts on the ventilators. The testing is performed by a testing server which is connected to a plurality of ventilators over a communication network. The testing server implements a CI/CD pipeline, for example, via Jenkins application. The testing server receives one or more tests from a developer or a tester who may provide the selection of the tests using a graphical user interface (GUI) client. The tests include predefined custom test template or mode-specific test script. A custom test mode may be implemented into the UI application, which helps users (developer or a tester) to either choose a template or a mode-specific test script to execute. The test mode in the UI can have another mode i.e., mode-specific testing mode. For example, if the user still wishes to run tests on a particular mode, which can be invasive or non-invasive, the user can do that going into the mode-specific testing modes. The mode-specific testing mode can have very specific testing conditions templates for these modes. Optionally, if there are any user-defined test scripts, then these user-defined test scripts are executed; otherwise, the regular specified test routines may be executed.
[018] The test results data is constantly logged for the current mode in progress, including the errors or issues which might have occurred during the test run. Once the tests the successfully executed, a report is generated which may be presented in a csv format, or plotted graph images, etc., that can then be exported to the testing server from where the reports can be retrieved and analyzed. The test data results may be continuously processed and analyzed, using Artificial Intelligence/Machine Learning model. Further, suggestions may be generated in association with the predefined test template or the mode-specific test script, based on the analysis.
[019] In one embodiment, a block diagram of a system 100 for testing ventilators is illustrated in FIG. 1, in accordance with an embodiment. The system 100 may include a testing server 102. The testing server 102 may be a computing device having data processing capability. In particular, the testing server 102 may have capability for performing interaction with a human, a robot, a computing device, or a virtual character. Examples of the testing server 102 may include, but are not limited to a desktop, a laptop, a notebook, a netbook, a tablet, a smartphone, a mobile phone, an application server, a web server, or the like. In some example embodiments, the testing server 102 may be a cloud-based computing system.
[020] The system 100 may further include a data storage 104. For example, the data storage 104 may store various types of data required by the testing server 102 for testing ventilators. The testing server 102 may be communicatively coupled to the data storage 104 via a communication network 108. The communication network 108 may be a wired or a wireless network and the examples may include, but are not limited to the Internet, Wireless Local Area Network (WLAN), Wi-Fi, Long Term Evolution (LTE), 5G, Worldwide Interoperability for Microwave Access (WiMAX), and General Packet Radio Service (GPRS).
[021] As will be described in greater detail in conjunction with FIG. 2 to FIG. 4, in order to perform testing of the ventilators, the testing server 102 may receive a test input corresponding to one or more tests to be executed on a plurality of ventilators. Each of the plurality of ventilators may be communicatively coupled to the testing server 102 over the communication network 108 (also referred to as first communication network in this disclosure). The testing server 102 may further execute the one or more tests on each of the plurality of ventilators based on test input. The one or more tests may be executed via one of a predefined custom test template and a mode-specific test script. The testing server 102 may further obtain test results data from each of the plurality of ventilators, in response to the execution on each of the plurality of ventilators. The testing server 102 may further generate a report based on the test results data associated with each of the plurality of ventilators.
[022] In order to perform the above-discussed functionalities, the testing server 102 may include a processor 110 and a memory 112. The memory 112 may store instructions that, when executed by the processor 110, cause the processor 110 to perform testing of the ventilators, as discussed in greater detail in FIG. 2 to FIG. 4. The memory 112 may be a non-volatile memory or a volatile memory. Examples of the non-volatile memory may include, but are not limited to, a flash memory, a Read Only Memory (ROM), a Programmable ROM (PROM), Erasable PROM (EPROM), and Electrically EPROM (EEPROM) memory. Examples of volatile memory may include, but are not limited to, Dynamic Random Access Memory (DRAM), and Static Random-Access memory (SRAM). The memory 112 may also store various data (e.g. test data, test results data, etc.) that may be captured, processed, and/or required by the system 100.
[023] The testing server 102 may further include one or more input/output devices 114 through which the testing server 102 may interact with a user and vice versa. By way of an example, the input/output device 114 may be used to display a report generated based on the test results data, etc., as will be discussed later. The system 100 may interact with one or more external devices 106 over the communication network 108 for sending or receiving various data. Examples of the one or more external devices 106 may include, but are not limited to a remote server, a digital device, or another computing system.
[024] The system 100 may further include one or more ventilators 116-1, 116-2, … 116-N (hereinafter also collectively referred to as one or more ventilators 116 or simply ventilators 116). The testing server 102 may be communicatively coupled to the one or more ventilators 116 via the communication network 108. Testing server 102 may be configured to perform one or more tests on each of the one or more ventilators 116. The one or more tests may be executed via a predefined custom test template or and a mode-specific test script.
[025] Referring now to FIG. 2, a functional block diagram of the testing server 102 for testing the ventilators 116 is illustrated, in accordance with an embodiment of the present disclosure. In some embodiments, the testing server 102 may include a test input receiving module 202, a test executing module 204, a test results data obtaining module 206, a report generating module 208, and a test results data analyzing module 210.
[026] The test input receiving module 202 may receive a test input corresponding to one or more tests to be executed on a plurality of ventilators 116. As mentioned above, each of the plurality of ventilators 116 may be communicatively coupled to the testing server 102 over the first communication network 108. The testing server 102 may implement a Continuous Integration and Continuous Deployment (CI/CD) pipeline. The CI/CD pipeline, for example, may be implemented via Jenkins application.
[027] It should be noted that receiving the test input may include receiving a selection of at least one of a predefined custom test template and a mode-specific test script. It should be further noted that the selection of the predefined custom test template or the mode-specific test script may be received from a user via a test-mode User Interface (UI). Further, in some embodiments, receiving the test input may further include receiving an identity of the selected at least one of the predefined custom test template and the mode specific script test script and fetching the at least one of the predefined custom test template and the mode specific test script from a data repository. By way of an example, the identity of the selected at least one of the predefined custom test template and the mode specific script test script may be obtained from a user, for example, a tester or a developer. In other words, the tester or the developer may provide an identity of the predefined custom test template or the mode specific script test, via User Interface (UI). The UI may provide multiple options of the predefined custom test templates or the mode specific script tests to the tester or the developer to select from. Accordingly, the test input receiving module 202 may fetch the predefined custom test template or the mode specific test script from a data repository, using the identity of the predefined custom test template or the mode specific script test.
[028] The test executing module 204 may execute the one or more tests on each of the plurality of ventilators 116, based on the test input. As such, the one or more tests may be executed via one of the predefined custom test template and the mode-specific test script.
[029] The test results data obtaining module 206 may coordinate with the test executing module 204 to obtain test results data from each of the plurality of ventilators 116, in response to the execution of the one or more tests on each of the plurality of ventilators 116. The test results data may be received by the test results data obtaining module 206 from the plurality of ventilators 116 via the communication network 108 over which the testing server 102 is connected to the plurality of ventilators 116. For example, this communication network 108 may be a wired or a wireless connection.
[030] The report generating module 208 may generate a report based on the test results data associated with each of the plurality of ventilators 116. By way of an example, the report generated by the report generating module 208 may be a csv format-based report, or a graphical image-based report, or a tabular format-based report.
[031] In some embodiments, additionally, the test results data analyzing module 210 may analyze the test results data associated with each of the plurality of ventilators 116, using an Artificial Intelligence or a Machine Learning model. The test results data analyzing module 210 may further generate a suggestion in association with the predefined test template or the mode-specific test script, based on the analysis.
[032] Referring now to FIG. 3, a functional block diagram of a system 300 (corresponding to the system 100) for testing ventilators is illustrated, in accordance with an embodiment of the present disclosure. In some embodiments, the system 300 may include a testing server 302 which may test a plurality of ventilators 304.
[033] For testing, each of the plurality of ventilators 304 may be communicatively coupled to the testing server 302 over a communication network 108. The communication network 108 may be wired or wireless, for example, via Ethernet or Wi-Fi. The testing server 302 may implement a CI/CD pipeline. Further, the CI/CD pipeline may be implemented via the Jenkins application. As will be appreciated by those skilled in the art, Jenkins is a tool to manage the CI/CD pipeline processes.
[034] The system 100 may implement a version control module 310 that may be configured to keep track of new versions of the software applications that are released and meant for the ventilators. Once a new software application version is detected by the version control module 310, that software application version may be forwarded by the version control module 310 to the testing server 302.
[035] The testing server 302 may implement various modules for performing testing the ventilators 304. For example, a receiving module 312 may receive a test input corresponding to one or more tests to be executed on the plurality of ventilators 304. Further, the receiving module 312 may detect changes with respect to releases of new software applications and check for relevant test templates. Each of the ventilators 304 may include various modes, for example, one of the modes being a test mode. Further, in the test mode, there may exist two types of settings, namely pre-defined custom templates and mode-specific testing.
[036] The test input may be provided by a user (a developer 306 or a tester 308) via a test-mode User Interface (UI) application. For example, the user may provide a selection of the predefined custom test template or the mode-specific test script, via the test-mode UI. In particular, a custom test mode may be implemented into the UI application, which will help the user to either choose a template or some mode-specific test to be run. The template can be provided by the developer 306 or the tester 308 as an input via some script over the communication network 108. The templates can be pre-decided as per the testing criteria, for example, from a testing and validating (T&V) team. The user can trigger the tests by simply selecting the entry from template list.
[037] Once the one or more tests are received. The one or more tests may be sent to the ventilators 304 via a firmware building module 314 and a flashing tool 316 via a flashing hardware 318. Further, a test trigger module 320 may trigger execution of the one or more tests on the ventilators 304.
[038] A logging module 322 may operate at the backend, and may constantly log data for the current mode in progress, during testing. It should be noted that a strategy of how logging may happen can be decided based on the need. The logging module can continuously log the current operating behavior of the ventilators 304, including the errors or issues which might have occurred during the test run.
[039] Further, in some exemplary embodiments, data from the logging module 322 may be converted into a specific format, for example, a csv format, plotted graph images, etc., that can then be exported to the testing server 302 or a specified Internet-connected node (having an IP address) from where the data can be retrieved and analyzed.
[040] As mentioned above, the test input may be received as a selection of the mode-specific test script. The test script, as will be appreciated, may be custom built for providing more power to the developers 306 and the testers 308. The test script may be in a pre-defined syntax which can be written by the developer 306 or the tester 308 to customize the test running process in a particular way. For example, the developer 306 or the tester 308 can create the test script to run all modes one after another for certain number of hours, with specific parameter one after another.
[041] It should be noted that the test mode in the UI can have another mode - mode-specific testing mode. For example, if the user still wishes to run tests on a particular mode, which can be invasive or non-invasive, the user can do that going into the mode-specific testing modes. The mode-specific testing mode can have very specific testing conditions templates for these modes.
[042] The developer 306 may ensure that the code is good to release for testing and validating (T&V) or for production. Once the developer 306 creates a new release, an action can be triggered using the CI/CD pipeline to flash all the ventilators with the specified release. Optionally, if there are any user-defined test scripts, then these user-defined test scripts are executed; otherwise, the regular specified test routines may be executed. Further, if a failure or an issue is reported in the test executing, then such failure or issue may be reported back to the testing server 302 along with logs where the developer 306 can see them, to debug them further. This ensures that the developer 306 has prolonged testing results, and further, this ensures repeatability and stability for the release for certain feature or bug fixing. Further, this can leverage the T&V team if they want to execute checks for the standard compliance and implementation as per the requirements, that can provide a bigger coverage in terms of units, thereby reducing the test timings.
[043] The system 100 may include an analyzing module 324 which may, for example, be implemented on a cloud server. The analyzing module 324 may continuously process the test data results received from the ventilators 304 and provide test results. The analyzing module 324 may analyze the test results data associated with each of the plurality of ventilators 304, using Artificial Intelligence or Machine Learning model. Further, the analyzing module 324 may generate a suggestion in association with the predefined test template or the mode-specific test script, based on the analysis. For example, the suggestion may include charts, failure trends, possible corrective suggestions, etc.
[044] Referring now to FIG. 4, a flowchart of a method 400 of testing ventilators, is disclosed in accordance with some embodiments. The method 400 is explained in conjunction with FIG. 1. Accordingly, the method 400 may be performed by the testing server 102.
[045] At step 402, a test input may be received, corresponding to one or more tests to be executed on the plurality of ventilators 116. Each of the plurality of ventilators 116 may be is communicatively coupled to the testing server 102 over the first communication network 108. The testing server 102 may implement a Continuous Integration and Continuous Deployment (CI/CD) pipeline. Further, the CI/CD pipeline may be implemented via Jenkins application.
[046] In some embodiments, receiving the test input may include receiving a selection of at least one of the predefined custom test template and the mode-specific test script. It should be noted that the selection may be received via the test-mode User Interface (UI). Further, in some embodiments, receiving the test input may further include receiving an identity of the selected at least one of the predefined custom test template and the mode specific script test script. Further, the receiving may include fetching the at least one of the predefined custom test template and the mode specific test script from a data repository.
[047] At step 404, the one or more tests may be executed on each of the plurality of ventilators, based on the test input. The one or more tests may be executed via one of: a predefined custom test template, and a mode-specific test script. At step 406, test results data may be obtained from each of the plurality of ventilators 116, in response to the execution of the one or more tests on each of the plurality of ventilators 116. At step 408, a report may be generated, based on the test results data associated with each of the plurality of ventilators 116. By way of example, the report may be a csv format-based report, a graphical image-based report, or a tabular format-based report.
[048] Additionally, in some embodiments, at step 410, the test results data associated with each of the plurality of ventilators 116 may be analyzed, for example, using an Artificial Intelligence or a Machine Learning model. Further, at step 412, a suggestion may be generated in association with the predefined test template or the mode-specific test script, based on the analysis.
[049] Further, a graphical user interface (GUI) client for testing ventilators is disclosed. In some embodiments, the GUI client may be implemented as a computer application, specifically for performing one or more actions for testing ventilators 116. The GUI client may be configured to receive a test input corresponding to one or more tests to be executed on the plurality of ventilators 116. The one or more tests may be executed on each of the plurality of ventilators 116 based on the test input. The one or more tests may be executed via a predefined custom test template or a mode-specific test script. The GUI client may be further configured to obtain a report from a testing server, in response to the execution of the one or more tests on the plurality of ventilators 116. Further, the GUI client may display the report. As mentioned above, the report may be generated (by the testing server 102) based on test results data associated with each of the plurality of ventilators 116 in response to the execution the one or more tests on each of the plurality of ventilators 116.
[050] As will be also appreciated, the above-described techniques may take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, solid state drives, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
[051] The disclosed methods and systems may be implemented on a conventional or a general-purpose computer system, such as a personal computer (PC) or server computer. It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
[052] The above techniques for testing ventilators provide for automation solution for testing multiple ventilators. The techniques provide allow for achieving more testability in a limited amount of time for the ventilators. Further, by providing different tools, it is possible to reduce a lot of manual work while performing testing of ventilators on the production line.
[053] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims. , Claims:1. A method of testing ventilators, the method comprising:
receiving, by a testing server, a test input corresponding to one or more tests to be executed on a plurality of ventilators, wherein each of the plurality of ventilators is communicatively coupled to the testing server over a first communication network;
based on test input, executing, by the testing server, the one or more tests on each of the plurality of ventilators, wherein the one or more tests are executed via one of:
a predefined custom test template, and
a mode-specific test script;
obtaining, by the testing server, test results data from each of the plurality of ventilators, in response to the execution on each of the plurality of ventilators; and
generating, by the testing server, a report based on the test results data associated with each of the plurality of ventilators.

2. The method as claimed in claim 1, wherein receiving the test input comprises:
receiving, via a test-mode User Interface (UI), a selection of at least one of:
the predefined custom test template, and
the mode-specific test script.

3. The method as claimed in claim 2, wherein receiving the test input further comprises:
receiving an identity of the selected at least one of the predefined custom test template and the mode specific script test script; and
fetching the at least one of the predefined custom test template and the mode specific test script from a data repository.

4. The method as claimed in claim 1, wherein the report is one of:
a csv format-based report,
a graphical image-based report, and
a tabular format-based report.

5. The method as claimed in claim 1, further comprising:
analyzing the test results data associated with each of the plurality of ventilators, using Artificial Intelligence/Machine Learning model; and
generating a suggestion in association with the predefined test template or the mode-specific test script, based on the analysis.

6. The method as claimed in claim 1, wherein the testing server implements a Continuous Integration and Continuous Deployment (CI/CD) pipeline, and wherein the CI/CD pipeline is implemented via Jenkins application.

7. A testing server for testing ventilators, the testing server comprising:
a processor; and
a memory communicatively coupled to the processor, wherein the memory stores a plurality of processor-executable instructions, which on execution by the processor, cause the processor to:
receive a test input corresponding to one or more tests to be executed on a plurality of ventilators, wherein each of the plurality of ventilators is communicatively coupled to the testing server over a first communication network;
based on the received test input, execute the one or more tests on each of the plurality of ventilators, wherein the one or more tests are executed via one of:
a predefined custom test template, and
a mode-specific test script;
obtain test results data from each of the plurality of ventilators, in response to the execution on each of the plurality of ventilators; and
generate a report based on the test results data associated with each of the plurality of ventilators.

8. The testing server as claimed in claim 8, wherein the receiving the test input comprises:
receiving, via a test-mode User Interface (UI), a selection of at least one of:
a predefined custom test template, and
a mode-specific test script;
receiving an identity of the selected at least one of the predefined custom test template and the mode specific script test script; and
fetching the at least one of the predefined custom test template and the mode specific test script from a data repository.

9. The testing server as claimed in claim 8, wherein executing the one or more tests on each of the plurality of ventilators comprises executing at least one of:
the predefined custom test template on each of the plurality of ventilators; and
the mode-specific test script on each of the plurality of ventilators.

10. A graphical user interface (GUI) client for testing ventilators, the GUI client configured to:
receive a test input corresponding to one or more tests to be executed on a plurality of ventilators, wherein, the one or more tests is executed on each of the plurality of ventilators based on the test input, wherein the one or more tests are executed via one of:
a predefined custom test template, and
a mode-specific test script;
obtain a report from a testing server;
display the report;
wherein, the report is generated, by the testing server, based on test results data associated with each of the plurality of ventilators in response to the execution the one or more tests on each of the plurality of ventilators.