Experiment management support systems

Abstract

A system for controlling experiment execution. The system includes an instrument electronic device and a workflow electronic device. The workflow electronic device includes an electronic processor. The electronic processor is configured to receive a submission request via a web application. The submission request includes an experiment design including an acquisition task. The electronic processor is also configured to receive an acquisition rule including pass criteria and an action to take when acquired data does meet not the pass criteria. The electronic processor is further configured to associate the acquisition rule with the acquisition task generate a request to perform the acquisition task, and send, to the instrument electronic device, the request to acquire data. The electronic processor is also configured to determine whether the acquired data meets the pass criteria and, in response to determining the acquired data does not meet the pass criteria, perform the action.

Description

EXPERIMENT MANAGEMENT SUPPORT SYSTEMSRELATED APPLICATIONS

[0001] This application claims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional Patent Application No. 63 / 653,330 filed May 30, 2024, the entire disclosure of which is incorporated by reference.BACKGROUND

[0002] Modern scientific environments often include scientific instruments that generate large amounts of data. Managing that data to enable scientific progress is a significant challenge, particularly in view of the practical constraints of computing technology and the business and regulatory constraints for different kinds of scientific endeavors.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example, not by way of limitation, in the figures of the accompanying drawings.

[0004] FIG. 1 is a block diagram of a system 100 for executing an experiment and controlling experiment execution, in accordance with various embodiments.

[0005] FIG. 2 is an example block diagram of components included in the workflow electronic device of the system of FIG. 1, in accordance with various embodiments.

[0006] FIG. 3 is an example flow diagram of a method for executing an experiment, in accordance with various embodiments.

[0007] FIG. 4 is an example block diagram of software components included in the system of FIG. 1 and example communications occurring between the software components when the functionality described in relation to FIG. 3 is performed, in accordance with various embodiments.

[0008] FIGs. 5-7 are example swim lane diagrams illustrating communications that occur between software components of the system 100, in accordance with various embodiments.

[0009] FIG. 8 is an example block diagram of software components included in an experiment management application service, in accordance with various embodiments.

[0010] FIG. 9 is an example associated objects view in a graphical user interface (GUI), in accordance with various embodiments.

[0011] FIG. 10 is an example block diagram illustrating the functionality performed in the implementations described herein regarding associated objects, in accordance with various embodiments.

[0012] FIG. 11 is an example flowchart of a method 1100 for controlling experiment execution, in accordance with various embodiments.

[0013] FIG. 12 includes an example block diagram of data transmitted between software components to implement the functionality described in relation to data acquisition rules, in accordance with various embodiments.

[0014] FIG. 13 is an example GUI in which selections may be made to create acquisition rules, in accordance with various embodiments.

[0015] FIG. 14 is an example GUI including assignments of acquisition rules to acquisition tasks, in accordance with various embodiments.

[0016] FIG. 15 is an example GUI including a summary of IRC status for each acquisition task, in accordance with various embodiments.

[0017] FIG. 16 is an example GUI including a brief summary of the status of the IRC rules for a single acquisition task after the acquisition task is completed, in accordance with various embodiments.

[0018] FIGs. 17-34 are example GUIs displayed via a web application by which one or more selections for creating an experiment design may be made.

[0019] FIGs. 35-37 are example GUIs displayed via a web application by which status updates regarding data processing and status updates regarding data acquisition are displayed.

[0020] FIG. 38 is a block diagram of an example scientific instrument support module for performing support operations, in accordance with various embodiments.

[0021] FIG. 39 is an example of a graphical user interface that may be used in the performance of some or all of the support methods disclosed herein, in accordance with various embodiments.

[0022] FIG. 40 is a block diagram of an example computing device that may perform some or all of the scientific instrument support methods disclosed herein, in accordance with various embodiments.

[0023] FIG. 41 is a block diagram of an example scientific instrument support system in which some or all of the scientific instrument support methods disclosed herein may be performed, in accordance with various embodiments.DETAILED DESCRIPTION

[0024] Disclosed herein are scientific instrument support systems, as well as related methods, computing devices, and computer-readable media. For example, these systems may take the form of any of the embodiments disclosed herein.

[0025] The scientific instrument support embodiments disclosed herein may achieve improved performance relative to conventional approaches. For example, various ones of the embodiments disclosed herein may allow for the integration of different software programs within a lab environment (e.g., instrument control programs, data acquisition programs, data analysis programs, data reporting programs) into a unified platform and allow for the automation of one or more experiment-related tasks across different software applications, for example. In at least one instance, an experiment management application service is employed to interact with data acquisition systems (instrument electronic devices) and data processing systems (processing electronic devices) allowing a user to submit experiment profiles and the experiment management application to automate the performance of the experiment for the user.

[0026] Frequently, multiple software applications are required to generate the relevant information necessary for decision-making. This overall process typically involves executing a series of tasks sequentially across various software applications with multiple inputs from the user on different software. For enhanced efficiency and flexibility, the embodiments disclosed herein enable users to remotely submit these tasks from a unique web application (e.g., an experiment management application), providing the flexibility to submit all tasks simultaneously or at differing times, for example.

[0027] The embodiments disclosed herein provide the capability to trigger data collection on various instruments, followed by subsequent data processing using different software applications. Moreover, the embodiments disclosed herein allow users the ability to initiate data processing on multiple software platforms by using previously acquired data. The status of each step is recorded and exhibited to a user through the web application, for example. Users also have the option to cancel individual tasks (spread across one or more different software programs) or the overall process, or experiment, (spread across one or more different software programs) as per their requirements.

[0028] The embodiments disclosed herein can increase productivity, reduce human effort and errors, reduce sample waste, increase throughput through automated end to end workflow accessible both locally and remotely from a web browser, for example. The embodiments disclosed herein provide a platform that allows users to remotely submit tasks to various software applications on various electronic devices. The platform is versatile and can accommodate different types of data collection and processing requirements. The platform is scalable, capable of supporting a single instrument electronic device or multiple, and the same applies to the processing electronic devices. Simplified and consistent user experience with a streamlined interface is provided that allows non-experts to setup complex workflows spanning multiple analysis types, types of acquisition applications, types of processing applications, and the like. Users may not need to have experience in the acquisition or processing software to successfully perform an experiment. The embodiments disclosed herein provide the ability to control and monitor the progression of data collection and processing across multiple instruments and processing software from a single web-based user interface. The embodiments disclosed herein allow for intelligent run control based on real time data acquisition.

[0029] The embodiments disclosed herein thus provide improvements to scientific instrument technology (e.g., improvements in the computer technology supporting such scientific instruments, among other improvements).

[0030] Various ones of the embodiments disclosed herein may improve upon conventional approaches to achieve the technical advantages of integrating many different software platforms and systems to allow for greater control of lab equipment by a user by providing an integrated software platform such as those disclosed herein. The integrated software platform may utilize inputs from many different software platforms to automatically trigger data acquisition with one or more instrument electronic devices, data processing with one or more processing electronic devices, and / or data reporting events. Such technical advantages are not achievable by routine and conventional approaches, and all users of systems including such embodiments may benefit from these advantages (e.g., by assisting the user in the performance of a technical task by means of a guided human-machine interaction process). The technical features of the embodiments disclosed herein are thus decidedly unconventional in the field of lab equipment control, as are the combinations of the features of the embodiments disclosed herein. As discussed further herein, various aspects of the embodiments disclosed herein may improve the functionality of a computer itself. The computational and user interface features disclosed herein do not only involve the collection and comparison of information, but apply new analytical and technical techniques to change the operation of the control of scientific instruments and different software in the context of data acquisition, data processing, and data reporting, for example. The present disclosure thus introduces functionality that a human could not efficiently perform.

[0031] Accordingly, the embodiments of the present disclosure may serve any of a number of technical purposes, such as controlling a specific technical system or process such as an experiment, or workflow, spanning across one or more different scientific instruments and / or one or more software applications for data acquisition, data processing, and / or data reporting for example; determining from measurements how to control a machine; digital audio, image, or video enhancement or analysis; optimizing load distribution in a computer network; reducing the amount of sensor data to be processed; or providing a faster processing of sensor data.

[0032] The embodiments disclosed herein thus provide improvements to data acquisition, processing, and reporting and instrument control technology.

[0033] One example implementation provides a system for controlling experiment execution. The system includes an instrument electronic device and a workflow electronic device. The workflow electronic device is connected to the instrument electronic device via a communication network. The workflow electronic device includes an electronic processor. The electronic processor is configured to receive a submission request via a web application. The submission request includes an experiment design and the experiment design includes an acquisition task. The electronic processor is also configured to receive an acquisition rule. The acquisition rule includes pass criteria and an action to take when acquired data does meet not the pass criteria. The electronic processor is further configured to associate the acquisition rule with the acquisition task, based on the experiment design, generate a request to perform the acquisition task to send to the instrument electronic device, the request associated with operating instructions for the instrument electronic device to perform an experiment on a sample to acquire data, and send, to the instrument electronic device via the communication network, the request to acquire data. The electronic processor is also configured to, in response to the data being acquired and uploaded to a location by the instrument electronic device according to the request to acquire data, determine whether the acquired data meets the pass criteria and, in response to determining the acquired data does not meet the pass criteria, perform the action.

[0034] Another example implementation provides a method for controlling experiment execution. The method includes receiving a submission request via a web application. The submission request includes an experiment design and the experiment design includes an acquisition task. The method also includes receiving an acquisition rule. The acquisition rule includes pass criteria and an action to take when acquired data does not meet the pass criteria. The method further includes associating the acquisition rule with the acquisition task, based on the experiment design, generating a request to perform the acquisition task to send to an instrument electronic device, the request associated with operating instructions for the instrument electronic device to perform an experiment on a sample to acquire data, and sending, to the instrument electronic device, the request to acquire data. The method also includes, in response to the data being acquired by the instrument electronic device according to the request to acquiredata, determining whether the acquired data meets the pass criteria and, in response to determining the acquired data does not meet the pass criteria, performing the action.

[0035] In the following detailed description, reference is made to the accompanying drawings that form a part hereof wherein like numerals designate like parts throughout, and in which is shown, by way of illustration, embodiments that may be practiced. It is to be understood that other embodiments may be utilized, and structural or logical changes may be made, without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense.

[0036] Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the subject matter disclosed herein. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order from the described embodiment. Various additional operations may be performed, and / or described operations may be omitted in additional embodiments.

[0037] For the purposes of the present disclosure, the phrases "A and / or B" and "A or B" mean (A), (B), or (A and B). For the purposes of the present disclosure, the phrases "A, B, and / or C" and "A, B, or C" mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). Although some elements may be referred to in the singular (e.g., “a processing device”), any appropriate elements may be represented by multiple instances of that element, and vice versa. For example, a set of operations described as performed by a processing device may be implemented with different ones of the operations performed by different processing devices. As used herein, the phrase “based on” should be understood to mean “based at least in part on,” unless otherwise specified.

[0038] The description uses the phrases "an embodiment," “various embodiments,” and "some embodiments," each of which may refer to one or more of the same or different embodiments. The description also uses the phrases "an implementation," “various implementations,” and "some implementations," each of which may refer to one or more of the same or different implementations. Furthermore, the terms "comprising," "including," "having," and the like, asused with respect to embodiments of the present disclosure, are synonymous. When used to describe a range of dimensions, the phrase "between x and y" represents a range that includes x and y. As used herein, an “apparatus” may refer to any individual device, collection of devices, part of a device, or collections of parts of devices. The drawings are not necessarily to scale.

[0039] Unless the context of their usage unambiguously indicates otherwise, the articles “a,” “an,” and “the” should not be interpreted as meaning “one” or “only one.” Rather these articles should be interpreted as meaning “at least one” or “one or more.” Likewise, when the terms “the” or “said” are used to refer to a noun previously introduced by the indefinite article “a” or “an,” “the” and “said” mean “at least one” or “one or more” unless the usage unambiguously indicates otherwise.

[0040] It should also be understood that although certain drawings illustrate hardware and software located within particular devices, these depictions are for illustrative purposes only. In some embodiments, the illustrated components may be combined or divided into separate software, firmware and / or hardware. For example, instead of being located within and performed by a single electronic processor, logic and processing may be distributed among multiple electronic processors. Regardless of how they are combined or divided, hardware and software components may be located on the same computing device or may be distributed among different computing devices connected by one or more networks or other suitable communication links.

[0041] Thus, in the claims, if an apparatus or system is claimed, for example, as including an electronic processor or other element configured in a certain manner, for example, to make multiple determinations, the claim or claim element should be interpreted as meaning one or more electronic processors (or other element) where any one of the one or more electronic processors (or other element) is configured as claimed, for example, to make some or all of the multiple determinations. To reiterate, those electronic processors and processing may be distributed.

[0042] FIG. 1 is a block diagram of a system 100 for executing an experiment and controlling experiment execution, in accordance with various embodiments. As illustrated in FIG. 1, the system 100 includes a plurality of instrument personal computer (IPC)s 104 (also referred toherein as instrument electronic devices) connected over a communication connection or network120. One or more devices 108 are connected to each IPC 104. Devices 108 are physical entities that perform some function of sample preparation and / or sample analysis. For example, devices 108 may be physical devices having a serial number, a means of communicating with other external entities, and may include processors, memory, and firmware. Devices 108 may include, for example, sensors, detectors, actuators, spectrometers, spectrograms, oscilloscopes, electrometers, interferometers, and the like. The IPCs 104 may also include one or more instruments 112. Instruments 112 are logical containers that include a collection of devices 108. For example, devices 108 work together to perform operations and produce results. The logical collection of devices 108 (e.g., the instrument 112) prepares or analyzes inputs, such as blood samples or other biological samples, semiconductors, chemical compounds, solutions, food and drug samples, and the like. Each IPC 104 is connected to its respective device(s) 108 and may be configured to communicate uni-directionally or bi-directionally with the connected device(s) 108. Each IPC 104 may be connected to the device(s) 108 via wired or wireless communication mediums and / or protocols. Each IPC 104 may transmit commands to the connected device(s) 108, receive status signals from the device(s) 108, receive measurements from the device(s) 108, and the like, as described below in more detail. The IPCs 104, the devices 108, and the instruments 112 may be more generally referred to as service components. The instruments 112 may include, for example, liquid chromatography instruments, gas chromatography instruments, ion chromatography instruments, mass spectrometry instruments, trace elemental instruments(e g., inductively coupled plasma mass spectrometry, inductively coupled plasma optical emission spectroscopy, atomic absorption, etc.), capillary electrophoresis instruments, spectroscopy instruments, and the like. However, it should be understood that instruments 112 are not limited to those described herein, and other types of instruments are contemplated. For example, any type of instrument configured to follow or interact with the defined user interfaces may be supported and may be automatically detected (as described below) and managed within the system 100. Furthermore, as also described in more detail below, in some embodiments, the system 100 is configured to enable a user to manually add an instrument for management within the system 100. The system 100 may also include a plurality of processing electronic devices121, a database 124, a workflow electronic device 128, and a user device 130 communicatively coupled with the plurality of IPCs 104 (and with each other) through the communication network120. In other embodiments, the plurality of IPCs 104, the plurality of processing electronic devices 121, the workflow electronic device 128, and the database 124 communicate via one or more dedicated wire connections or other forms of wired or wireless electronic communication. In some implementations, the workflow electronic device 128 is a server. It should be understood that the system 100 may include fewer or additional components than those illustrated in FIG. 1. For example, the system 100 may include fewer or more IPCs 104, fewer or more processing electronic devices 121, multiple workflow electronic devices 128, multiple databases 124, multiple user devices 130, or a combination thereof. In some instances, rather than including an independent database, the storage functionality of the database 124 is provided by the workflow electronic device 128. The components of the system 100 may also communicate through one or more intermediary devices not illustrated in FIG. 1.

[0043] The workflow electronic device 128 may serve as a “control hub” for the plurality of IPCs 104 based on an experiment design received from the user device 130 via a web application. For example, the workflow electronic device 128 communicates with each of the IPCs 104 by sending commands to the IPCs 104 to perform data acquisition over a wired connection, a wireless connection, or a combination thereof. In some implementations, the workflow electronic device 128 may communicate with one or more of the plurality of IPCs 104 through one or more intermediary devices (for example, the server 122). Additionally, the workflow electronic device 128 receives measurements and statuses of device(s) 108 and instrument s) 112 from their respective IPCs 104 over a wired connection, wireless connection, or a combination thereof. The database 124 may store data indicating the status of components within the system 100. For example, the database 124 may store a current status of the IPCs 104, historical statuses of the IPCs 104, and the like. In some implementations, the storage functionality described as being performed by the database 124 may be performed by multiple databases included in the system 100. For example, experiment designs may be stored in an experiments design database, acquired data may be stored in an acquired data database, and processed data may be stored in a processed data database.

[0044] The workflow electronic device 128 serves as a “control hub” for the plurality of processing electronic devices 121 based on an experiment design received from the user device 130. For example, the workflow electronic device 128 communicates with each of theprocessing electronic devices 121 by sending commands to the processing electronic devices 121 to perform data processing over a wired connection, a wireless connection, or a combination thereof. In some implementations, the workflow electronic device 128 may communicate with one or more of the plurality of processing electronic devices 121 through one or more intermediary devices. Additionally, the workflow electronic device 128 receives processed results from the processing electronic devices 121 over a wired connection, wireless connection, or a combination thereof. As mentioned above, the database 124 stores data indicating the status of components within the system 100. For example, the database 124 may store a current status of the processing electronic devices 121, historical statuses of the processing electronic devices 121, the results of the data processing performed by the processing electronic devices 121, and the like.

[0045] FIG. 2 is an example block diagram of the workflow electronic device 128. In the example illustrated in FIG. 2, the workflow electronic device 128 include an electronic processor 200 and a memory 205. In some implementations, the electronic processor 200 is similar to the processing device 5002 described below in relation to FIG. 41 and the memory 205 is similar to the storage device 5004 described in relation to FIG. 41. In some implementations, the memory 205 includes a server-based platform 210 (described in further detail below).

[0046] FIG. 3 is an example flowchart of a method 300 for executing an experiment, in accordance with various embodiments. Although the operations of the method 300 may be illustrated with reference to particular embodiments disclosed herein (e.g., the scientific instrument support modules 1500 discussed herein with reference to FIG. 38, the GUI 3000 discussed herein with reference to FIG. 39, the computing devices 4000 discussed herein with reference to FIG. 40, and / or the scientific instrument support system 5000 discussed herein with reference to FIG. 41), the method 300 may be used in any suitable setting to perform any suitable support operations. Operations are illustrated once each and in a particular order in FIG. 3, but the operations may be reordered and / or repeated as desired and appropriate (e.g., different operations performed may be performed in parallel, as suitable). According to various embodiments, a data acquisition and data processing experiment workflow example is described below.

[0047] While the method 300 is described and illustrated as including both data acquisition and data processing, in some implementations, only requests to acquire data may be generated based on the experiment design. In other implementations, only requests to process data data may be generated based on the experiment design. For example, data processing may be performed on data that was acquired in a previously executed experiment.

[0048] In some implementations, the method 300 begins at block 305 when the electronic processor 200 receives a submission request via a web application. In some implementations, the submission request includes an experiment design. In some implementations, the web application may be included in the server-based platform 210 and, when the web application is executed by the electronic processor 200, a user interface for creating an experiment design may be displayed on a display device (for example, a display device similar to the display device 4010 described below in relation to FIG. 40) of a user device (for example, the user device 130). In some implementations, the electronic processor 200 saves the experiment design in a database (for example, the database 124). The experiment design may include a factor and associated value, an instrument method, a processing method, a molecular sequence, a report template, an intelligent run control rule, a combination of the foregoing, or the like.

[0049] In some implementations, the experiment design is based on selections made by a user via a web application. For example, creation of an experiment design may include selecting an acquisition system, selecting a processing application, selecting a type of processing system, matching a processing system, defining study factors and sample metadata, setting up a data acquisition sequence (for example, open / import existing template and / or create from scratch from sequence table editing), setting up analyses for data processing tasks, a combination of the foregoing, and the like.

[0050] In some implementations, at block 310, the electronic processor 200 validates the experiment design included in the submission request. For example, the electronic processor 200 may compare the experiment against one or more predetermined rules to determine whether an experiment design is complete and capable of being performed. In some implementations, when an experiment design is validated, the experiment design is added to an experiment queue and is later dequeued from the experiment queue. In some implementations, a submission requestincludes an incomplete experiment design. For example, a user may wish to save a partially completed experiment design and complete the experiment design at a later time.

[0051] In some implementations, in response to validating the experiment design, the electronic processor 200, at block 315, based on the experiment design, generates a request to acquire data to send to the instrument electronic device, the request associated with operating instructions for the instrument electronic device 104 to perform an experiment on a sample to acquire data. In some implementations, at block 320, the electronic processor 200 sends, to the instrument electronic device 104 via the communication network 120, the request to acquire data

[0052] In some implementations, prior to performing the functionality described in relation to block 315 one or more instrument electronic devices 104 may be registered with the server-based platform 210. In some implementations, one or more processing electronic devices 121 are also registered with the server-based platform 210.

[0053] FIG. 4 is an example block diagram of software included in the server-based platform 210, the instrument electronic devices 104, and the processing electronic devices 121. FIG. 4 also illustrates examples of communications occurring between software components when the functionality described in relation to FIG. 3 is performed. FIGs. 5-7 are example swim lane diagrams illustrating communications that occur between software components of the serverbased platform 210, the instrument electronic devices 104, and the processing electronic devices 121. The server-based platform 210 may be implemented as a cloud-based platform or using a private server (e.g., on the premises of a lab). The server-based platform 210 may include one or more instrument application services 400. The instrument application services 400 may include one or more services for registering IPCs 104 with the server-based platform 210 and communicating with the IPCs 104.

[0054] For example, the instrument application services 400 includes an instrument discovery service (“IDS”) 402. The one or more IPCs 104 may register with the server-based platform by communicating with the IDS 402 via, for example, the communication network 120. In some implementations the IDS 402 maintains a list of IPCs 104 registered with the server-based platform 210. For example, the IDS 402 may maintain a list of unique identifiers. Each uniqueidentifier of the list of unique identifiers is associated with an instrument service fagade (“ISF”) (described in further detail below) included in a registered IPC 104.

[0055] In another example, the instrument application services 400 includes an instrument listener service (“ILS”) 405 communicatively coupled (e.g., over the network 120) to an instrument service fagade (“ISF”) 410 included in each IPC 104 associated with an instrument 112. In some implementations, the ILS 405 receives, using the ISF 410, information associated with each IPC 104, such as, for example, the device(s) 108, the instrument 112, or other components of each IPC 104, status updates, and the like. The information may include an identifier of an instrument associated with the IPC 104 or the instrument 112 (a type identifier, a unique identifier, or a combination thereof), a network connection status of the IPC 104, realtime data acquisition status of the IPC 104, instrument configuration information, a scientific instrument group identifier, an owner of the instrument 112, a model of the instrument, a lab name associated with the IPC 104, a location of the IPC 104, a combination thereof, or the like. The real-time data acquisition status may include a status of an operation currently being performed, previously performed, or pending performance by the device(s) 108, the IPC 104, the instrument 112, or a combination thereof The information may also include device details associated with each device 108 such as, for example, a device name, a device serial number, a device model number, a device firmware version, a device warranty expiration date, a device warranty status, a device service provider, a service status, a contract expiration date, or a combination thereof. The asset information may also include other status logs associated with the device(s) 108, the IPC 104, and / or the instrument 112, such as, for example, error logs or operation history.

[0056] In some instances, each instrument 112, IPC 104, or both has one or more connectivity services installed, such as, for example, an instrument service fagade service, a device integration service, a device registry service, a proxy client service, or a combination thereof that listens to instrument changes and reports such instrument changes to the ILS 405 installed on the workflow electronic device 128. For example, a proxy client service can be installed and running in each IPC 104 to send information from each IPC 104 to a proxy server service running in the workflow electronic device 128 that will route the information to other services running in the workflow electronic device 128, such as, for example, the ILS 405.

[0057] The server-based platform 210 may also include a persisted messaging framework (“PMF”) 415 and a message broker 420. The ILS 405 may publish status updates from each IPC 104 to the PMF 415. The PMF 415 outputs status updates to the message broker 420, which enables the workflow electronic device 128 to provide the status updates to, for example, the web application for display on a web application user interface (“UI”) 425.

[0058] Some or all of the asset information described above may be acquired using, for example, the ILS 405 of the server-based platform 210. For example, in some instances, the ILS 405 only acquires a data acquisition status associated with each IPC 104, and the server-based platform 210 is configured to read other asset information (e.g., scientific instrument group names, lab names, locations, etc.) from the database 124. The server-based platform 210 may be configured to update asset information in the database 124 according to, for example, user input received through the web application.

[0059] In some implementations, the server-based platform 210 includes an analysis service 427, platform data services 430, platform-based processing services 435, and an experiment management application service 440. In some implementations, experiment management application service 440, when executed, creates a list of acquisition requests and processing requests based on a validated experiment design. In some implementations, the experiment management application service 440 determines an order associated with the determined requests. The order may include an ordered list of requests and, in some implementations, criteria that must be met before a request is sent. In some implementations, the experiment management application service 440 sends the acquisition requests to the instrument electronic devices 104 directly and the processing requests to the processing electronic devices 121 directly. In other implementations, the experiment management application service 440 sends the acquisition request and the processing requests through an intermediary service. For example, the experiment management application service 440 may send processing requests to the analysis service 427 and the analysis service 427 may send the processing requests to processing electronic devices 121. In some implementations, the analysis service 427 sends a processing request to one of the platform processing services 435 included in the server-based platform 210 rather than to a processing electronic device 121 and the electronic processor 200 processes the acquired data according to the processing request when executing the platformprocessing service 435. In some implementations, the analysis service 427 publishes status updates from each processing electronic device 121 to the PMF 415. In some implementations, the platform data services 430 manage the storage of acquired data and processed results. FIG. 8 is an example block diagram of components included in the experiment management application service 440. In the example illustrated in FIG. 8, the experiment management application service 440 includes an experiment management application 445, an experiments manager 450, and a workflow manager 455. In some implementations, experiment management application 445 is the web application and when the electronic processor 200 executes the experiment management application 445 the GUIS described herein are generated. When executing the experiment management application 445, the electronic processor 200 may also send the experiment design to the database 124.

[0060] In some implementations, the experiment management application service 440 sends an acquisition request to a digital instrument interface (DII) included in the instrument electronic device 104 via a Lunar proxy server (LPS) and a Lunar proxy client (LPC).

[0061] In some implementations, when an experiment design is validated, the electronic processor 200, executing the experiments manager 450, determines a plurality of generated requests (for example, one or more requests to acquire data to send to one or more instrument electronic devices 104 and one or more requests to process acquired data to send to one or more processing electronic devices 121) for the experiment design. In some implementations, the electronic processor 200, executing the experiments manager 450, retrieves the experiment design from the experiments queue.

[0062] In some implementations, the electronic processor 200, when executing the workflow manager 455, determines an order in which to send the request determined using the experiment manager 450 and sends each generated request of the plurality of generated requests to an instrument electronic device 104 or a processing electronic device 121. In some implementations, the electronic processor 200, when executing the workflow manager 455, determines one or more conditions that must be satisfied before a request is sent to an instrument electronic device 104 or a processing electronic device 121.

[0063] The electronic processor 200, when executing the workflow manager 455, may also determine which instrument electronic device 104 or processing electronic device 121 to send a request to. In some implementations, the electronic processor 200 automatically determines an instrument electronic device 104 to send a request to acquire data to. For example, the electronic processor 200, determines, from a list of instrument electronic devices registered with the workflow electronic device 128 (for example, the list maintained by the IDS 402 included in the instruments application service 400), one or more instrument electronic devices 104 capable of performing the request to acquire data. In some implementations, each instrument electronic device included in the list of instrument electronic devices 104 registered with the workflow electronic device 128 is associated with a real-time availability status. In other implementations, the real-time status of the instrument electronic devices 104 registered with the workflow electronic device 128 is retrieved from the database 124.

[0064] In some implementations, the electronic processor 200 determines, based on the list of instrument electronic devices 104 registered with the workflow electronic device 128, whether an instrument electronic device 104 of the one or more instrument electronic devices 104 is available to perform the request to acquire data. In response to determining the instrument electronic device 104 is available, the electronic processor 200 sends the request to acquire data to the available instrument electronic device 104.

[0065] In some implementations, the electronic processor 200 automatically determines a processing electronic device 121 to send a request to process data to. For example, the electronic processor 200, determines, from a list of processing electronic devices registered with the workflow electronic device 128, one or more processing electronic devices capable of performing the request to process data. In some implementations, each processing electronic device included in the list of processing electronic devices 121 registered with the workflow electronic device 128 is associated with a real-time availability status. In other implementations, the real-time availability status of processing electronic devices 121 registered with the workflow electronic device 128 is retrieved from the database 124. In some implementations, the list of processing electronic devices registered with the workflow electronic device 128 is created and maintained by the analysis service 427.

[0066] In some implementations, the electronic processor 200 determines, based on the list of processing electronic devices registered with the workflow device, whether a processing electronic device of the one or more processing electronic devices to perform the request to process data. In response to determining the processing electronic device is available, the electronic processor 200 may send the request to process data to the available processing electronic device.

[0067] In other implementations, the electronic processor receives a selection of an instrument electronic device 104 or a processing electronic device 121 to send a request to. For example, the electronic processor 200 generates, for display via the web application (for example, displayed on a display device of the user device 130), a list of registered instrument electronic devices. In some implementations, the electronic processor 200 receives, for example, from the user device 130, a selection of an instrument electronic device 104 from the list of registered instrument electronic devices. In some implementations, the selection of the instrument electronic device 104 is included in the submission request (for example, included in the experiment design).

[0068] In another example, the electronic processor 200 generates, for display via the web application (for example, displayed on a display device of the user device 130), a list of registered processing electronic devices and, for each registered processing electronic device, a processing workflow supported by the registered processing electronic device. In some implementations, a processing workflow includes a processing type. In some implementations, the electronic processor 200 receives, for example, from the user device 130, a selection of the processing electronic device and processing workflow from the list of registered processing electronic devices. In some implementations, the selection of the processing electronic device and processing workflow is included in the submission request (for example, included in the experiment design).

[0069] Returning to FIGs. 5-7, FIG. 5 illustrates an example swim lane diagram of acquisition and processing orchestration at a high level. As illustrated in FIG. 5 the server-based platform 210 may include a listener 456. The listener 456, when executed by the electronic processor 200, may notify the workflow manager 455 when status updates are published to the PMF 415.In some instances, the listener 456, when executed by the electronic processor 200, may send the status updates published to the PMF 415 to the workflow manager 455. In some implementations, in response to receiving a status update, the workflow manager 455, when executed by the electronic processor 200, creates a new workflow instance (represented by block 457) to update the experiment (represented by block 458). For example, when a request to acquire data is completed, the request may be marked as completed in memory. In some implementations, when the workflow manager 455 receives a status update that acquired data is sent to the server-based platform 210 by an IPC 104, the electronic processor 200, executing the workflow manager 455 creates a workflow instance to process the acquired data (represented by block 459) and sends a request to process acquired data to the analysis service 427.

[0070] FIG. 6 and FIG. 7 are example swim lane diagrams of data acquisition. In some implementations, the platform data services 430 includes a platform document service 460 and a platform sequence service 465. In some implementations, when an experiment design is received and validated, the electronic processor 200, executing the experiment management application service 440, determines information included in the experiment design that may be required for an instrument electronic device 104 to perform a request to acquire data and sends the information to the platform data services 430. When an instrument electronic device 104 receives a request to acquire data, the instrument electronic device 104, may retrieve from the platform data services 430 information required for an instrument electronic device 104 to perform request. For example, an instrument electronic device 104, in response to receiving a request to acquire data, retrieves from a cache 470 included in the server-based platform 210 a sequence and experimental method required to perform the request to acquire data. In some implementations, the sequence is written to the cache 470 from the platform sequence service 465 and the experimental method is written to the cache 470 from the platform document service 460. In some implementations, prior to be retrieved from the cache 470 the sequence and experimental method are converted to instructions specific to the instrument electronic device 104 performing the request to acquire data. In some implementations, the instrument electronic device 104 translated the instructions retrieved from the cache 470 to instructions specific to the instrument 112 performing a task in order to acquire data.

[0071] Returning to FIG. 3, at block 325, the electronic processor 200 determines whether data is acquired and uploaded to a location by the instrument electronic device 104 according to the request to acquire. The location may be accessible to the workflow electronic device 128. For example, the acquired data may be uploaded to the database 124. In some implementations, the acquired data may be sent from the instrument electronic device 104 to the platform data services 430 and uploaded to the database 124 by the electronic processor 200, executing the platform data services 430. In some implementations, the storage location that the acquired data is uploaded to is defined in the experiment design.

[0072] In some implementations, in response to determining data is acquired and uploaded to a location by the instrument electronic device 104 according to the request to acquire data, the electronic processor 200, at block 330, based on the experiment design, generates a request to process acquired data to send to the processing electronic device 121. In some implementations, the request to process acquired data is associated with computer executable instructions for the processing electronic device 121 to process the acquired data. At block 335, the electronic processor 200 sends, to the processing electronic device 121 via the communication network 120, the request to process the acquired data.

[0073] In some implementations, at block 340, during or after processing of the acquired data according to the request to process the acquired data, the electronic processor 200 provides, for display via the web application, the acquired data, processed result, or both. The processed result may be the result of processing the acquired data. In some implementations, the electronic processor 200 generates, according to the submission request, a report based on the report template (for example, the report template included in the experiment design) or processed result for display via the web application.

[0074] As mentioned above, status updates may be received from the instrument electronic devices 104 and the processing electronic devices 121. For example, after sending a request to acquire data to an instrument electronic device 104, the electronic processor 200 may receive, in real-time, one or more status updates regarding data acquisition from the instrument electronic device 104. For example, as described above the status update may be received via the ILS 405, published to the PMF 415, and output to the message broker 420. In some implementations, astatus update from an instrument electronic device 104 may include an indication of whether a request to acquire data is being performed, a progress associated with a request to acquire data (for example, a task included in a data acquisition queue being performed), whether the instrument electronic device 104 is available, whether a request to acquire data is complete, a combination of the foregoing, and the like. In some implementations, the electronic processor 200, executing the message broker 420, generates, based on the status update regarding data acquisition, an acquisition update for display via the web application (for example, on a display device of the user device 130).

[0075] In another example, after sending a request to process acquired data to a processing electronic device 121, the electronic processor 200 may receive, in real-time, a status update regarding data processing from the processing electronic device 121. For example, as described above the status update from the processing electronic device 121 may be received via the analysis service 427, published to the PMF 415, and output to the message broker 420. In some implementations, a status update from a processing electronic device 121 may include an indication of whether a request to process acquired data is being performed, whether the processing electronic device 121 is available, whether a request to process acquired data is complete, a combination of the foregoing, and the like. In some implementations, the electronic processor 200, executing the message broker 420 generates, based on the status update regarding data processing, a processing update for display via the web application (for example, for display on a display device of the user device 130).

[0076] In some implementations, a graphical user interface (GUI) including high level experiment status (for example, experiment pending, acquisition complete, processing complete) information may be displayed via the web application. In some implementations, an experiment status GUI including individual processing updates and acquisition updates, real-time plots, and a results link is displayed via the web application.

[0077] In some implementations, the electronic processor 200 maintains a list of objects associated with the experiment design. The list of associated objects may include, for each associated object, a version of the associated object in use in the experiment design. For example, the experiment design includes instructions for data acquisition by instrumentelectronic devices 104 and the processing of acquired data by processing electronic devices 121 . These instructions may include various inputs and outputs that are associated objects. For example, associated objects may include instrument methods, processing methods, molecular sequences, intelligent run control rules, report templates, raw data generated by instrument electronic devices, processed results, detailed reports, or the like.

[0078] In some implementations, the electronic processor 200 generates, for display via the web application, the list of associated objects and an indication of whether an updated version of an associated object is available. FIG. 9 is an example associated objects view 900 in a graphical user interface (GUI). The column 905 includes associated objects, the column 910 indicates the type of associated object, the column 915 indicates the version of the associated object in use in the experiment design, the column 920 indicates the object was associated manually or automatically, the column 925 indicates whether an updated version of an associated object is available. In some implementations, the associated object view 900 GUI includes links that, when selected, cause the electronic processor 200 to display, via the web application, a location in an information view GUI, acquisition list view GUI, analysis view GUI, or the like corresponding to the associated object.

[0079] In some implementations, the electronic processor 200 receives, via the web application, a selection of the updated version of the associated object. In response to receiving the selection of the updated version of the associated object, data is acquired or processed using the updated version of the associated object. For example, the requests to acquire data or process acquired data may include an indication that the updated version of the associated object is to be used in the data acquisition or processing. Notifying a user via the web application that new versions of associated objects become available and enabling users to choose whether to adopt the updated version of an associated object or retain the version originally included in the experiment design ensures that consistency is maintained or the latest updates are integrated depending on the needs of the user and progress made in conducting the experiment. For example, if half of the acquired data has been processed using an original version of an associated object but a new version of an associated object exists, a user may wish to continue to utilize the original version of the associated object to process acquired data so that the acquired data is processed consistently.

[0080] As noted above, objects can be associated with an experiment design either automatically or manually. Automatic association occurs when objects are included in the experiment design received in the submission request. For example, an instrument method is automatically associated with an experiment design when it is selected in an injection list view GUI displayed via the web application. Automatic associations ensure relevant methods and protocols are seamlessly included in the experiment's framework without requiring additional user intervention. Manual association permits additional objects to be associated with an experiment after, for example, an experiment design is validated. Manual associations may be made based on one or more selections received by the electronic processor via the web application (for example, when the associated objects view GUI is displayed).

[0081] In some implementations, the electronic processor 200 creates or updates a list of associated objects based on the experiment design. In some implementations, the electronic processor 200 may add or remove associated objects based on a selection received via the associated objects view 900 GUI. For example, the electronic processor 200 receives, via the web application, a selection of an associated object to add to the list of associated objects or a selection of an associated object to remove from the list of associated objects. In some implementations, in response to receiving the selection of the associated object to add to the list of associated objects, the electronic processor 200 adds the associated object selected for addition to the list of associated objects. In response to receiving the selection of the associated object to remove to the list of associated objects, the electronic processor 200 may determine whether associated object selected for removal has been utilized to process or acquire data. In response to determining the associated object selected for removal has not been used to process or acquire data, the electronic processor 200 removes the associated object selected for removal from the list of associated objects.

[0082] FIG. 10 is an example block diagram illustrating the functionality performed in the implementations described herein regarding associated objects. In some implementations, multiple GUIs may be displayed via the web application. As illustrated in FIG. 10, the web application may display an associated objects view 1000 GUI, an information view 1005 GUI, an acquisition list view 1010 GUI, and analysis view 1015 GUI in an experiment view container 1020. In some implementations, a view controller 1025, when executed by the electronicprocessor 200, coordinates view updates (for example, alters the associated objects view 1000 GUI when a new version of an associated object becomes available), extracts associations from the experiment design, and calls a data access component 1030 to persist the experiment design including changes made to associations objects (for example, when a selection to remove an associated object is received)

[0083] In some implementations, the experiment management application service 440, supports the web application and interacts with other services (for example, the platform data services 430), to retrieve, persist, and update the experiment design including associated objects. Object association data may be stored in an application database or in another location via the platform data services 430.

[0084] In some implementations, acquisition queue management may be performed via the web application. For example, the electronic processor 200 may receive, via the web application a selection to pause or modify queued requests to acquire data. In such implementations, the electronic processor 200 sends instructions to the instrument electronic device 104 to pause or modify an acquisition queue according to the selection. In some implementations, the electronic processor 200 provides a response (for example, “queue paused,” “queue modified,” or the like) from the instrument electronic device 104 for display via the web application. In some implementations, the instrument electronic device 104 may include an input device and receive a selection from a user to pause of modify an acquisition queue. In response to receiving a selection to pause or modify the acquisition queue via the input device, the instrument electronic device 104 may send a notification to the workflow electronic device 128 regarding the selection to pause or modify the queue.

[0085] In some implementations, processing queue management may be performed via the web application. For example, the electronic processor 200 may receive via the web application a selection to pause or modify queued requests to process data. In some implementations, in response to receiving the selection to pause or modify queued requests to process data, the electronic processor validates the selection (for example, in a manner similar to validating the experiment design). In response to validating the selection, the electronic processor 200 modifies or pauses the processing queue according to the selection. In some implementations,the electronic processor 200 provides an updated queue status (for example, “queue paused,” “queue modified,” or the like) for display via the web application. In some implementations, the processing electronic device 121 may include an input device and receive a selection from a user to pause of modify a processing queue. In response to receiving a selection to pause or modify the processing queue via the input device, the processing electronic device 121 may send a notification to the workflow electronic device 128 (specifically, the electronic processor 200) regarding the selection to pause or modify the queue.

[0086] In data acquisition, it is crucial to ensure the quality of the data collected. Traditional systems often lack mechanisms to dynamically assess acquired data and react to potential issues during data acquisition. Thus, in traditional systems manual review of acquired data is necessary to ensure quality, which is time-consuming and inefficient. Additionally, if issues with data acquisition are not identified in real-time, low-quality data may be acquired and data acquisition may have to be repeated to acquire higher quality data. Repeating data acquisition wastes physical resources and instrument time (for example, wasting processing time and power of instrument electronic devices 104).

[0087] Therefore, in some implementations, Intelligent Run Control (IRC) rules may be received by the electronic processor 200 via the web application. IRC rules may be used to dynamically monitor and manage data acquisition for chromatography and hyphenated chromatography systems with mass spectrometers during execution.

[0088] Therefore, the IRC functionality described below allows for real-time or near real-time assessment of acquired data. Users can define multiple rules with specified criteria and actions based on raw data attributes or derived information, enabling flexible and complex setups. Users may leverage existing data to create rules and criteria, and once data acquisition has been completed, summary information and visualizations may be provided via a web application to facilitate easy data quality review. The IRC functionality described herein may be applied not only in laboratory data acquisition systems but also to perform quality control in manufacturing processes, in automated scientific research data collection, in environmental monitoring systems, in clinical diagnostics and research, in pharmaceutical development and testing, in food and beverage safety testing, and in forensic analysis.

[0089] FIG. 11 is an example flowchart of a method 1100 controlling experiment execution. Although the operations of the method 1100 may be illustrated with reference to particular embodiments disclosed herein (e.g., the scientific instrument support modules 1500 discussed herein with reference to FIG. 38, the GUI 3000 discussed herein with reference to FIG. 39, the computing devices 4000 discussed herein with reference to FIG. 40, and / or the scientific instrument support system 5000 discussed herein with reference to FIG. 41), the method 1100 may be used in any suitable setting to perform any suitable support operations. Operations are illustrated once each and in a particular order in FIG. 11, but the operations may be reordered and / or repeated as desired and appropriate (e.g., different operations performed may be performed in parallel, as suitable). According to various embodiments, a data acquisition and data processing experiment workflow example is described below.

[0090] In some implementations, the method 1100 begins at block 1105 when the electronic processor 200 receives a submission request via the web application, wherein the submission request includes an experiment design and the experiment design includes an acquisition task. At block 1110, the electronic processor 200 may receive an acquisition rule (also referred to herein as an IRC rule). For example, the acquisition rule may be received via the web application. In some implementations, the acquisition rule may be included in the experiment design. In some implementations, multiple acquisition rules are received. The acquisition rule may include pass criteria and an action to take when acquired data does not meet the pass criteria. In some implementations, at block 1115, the electronic processor 200 associates the acquisition rule with the acquisition task.

[0091] In some implementations, the pass criteria includes one or more variables and one or more conditions. Each variable may be associated with a condition. In one example a variable is an instrument parameter or summary information that may be derived from acquired data. Instrument parameters may include metrics such as spray voltage, spray current, or the like. Summary information derived from acquired data may include total ion chromatograms (TIC), base peak chromatograms (BPC), extracted ion chromatograms (XIC), or the like. In instrument electronic devices 104 that support complex processing, such as the identification of small molecules, peptides, oligonucleotides, and the like, a variable may be a small molecule, peptide, oligonucleotide, or the like.

[0092] In some implementations, at block 1 120, the electronic processor 200, based on the experiment design, generates a request to perform the acquisition task to send to an instrument electronic device 104. In some implementations, the request is associated with operating instructions for the instrument electronic device 104 to perform an experiment on a sample to acquire data. In some implementations, the request also includes the acquisition rule associated with the acquisition task.

[0093] In some implementations, the electronic processor 200 sends, to the instrument electronic device 104, the request to acquire data. In some implementations, the functionality described in relation to blocks 1125-1130 is performed by the electronic processor 200. In other implementations, the functionality described in relation to blocks 1125-1130 is performed by an electronic processor included in the instrument electronic device 104 that receives the request generated at block 1120.

[0094] In implementations, where the functionality described in relation to blocks 1125-1130 is performed by the electronic processor 200, at block 1125, the electronic processor 200 determines whether data has been acquired and uploaded to a location by the instrument electronic device 104 according to the request to acquire data. At block 1130, in response to data being acquired and uploaded to a location (for example, the platform data services 430) by the instrument electronic device 104 according to the request to acquire data, the electronic processor 200 determines whether the acquired data meets the pass criteria. In response to determining that the acquired data does not meet the pass criteria, the electronic processor 200 performs the action included in the acquisition rule.

[0095] In implementations, where the functionality described in relation to blocks 1125-1130 is performed by an electronic processor included in the instrument electronic device 104, at block 1125, the electronic processor included in the instrument electronic device 104 determines whether data has been acquired by the instrument electronic device 104 according to the request to acquire data. At block 1130, in response to data being acquired by the instrument electronic device 104 according to the request to acquire data, the electronic processor included in the instrument electronic device 104 determines whether the acquired data meets the pass criteria. In response to determining that the acquired data does not meet the pass criteria, the electronicprocessor included in the instrument electronic device 104 performs the action included in the acquisition rule.

[0096] In some implementations, the pass criteria is met when a value determined by the instrument electronic device 104 for the variable satisfies the condition. In some implementations, the acquired data includes a value for a parameter of the instrument electronic device 104.

[0097] In some implementations, the determination of whether the acquired data meets the pass criteria is made during performance of the acquisition task (for example, when the acquisition task is partially completed). In other implementations, the determination of whether the acquired data meets the pass criteria is performed in response to the acquisition task completing.

[0098] In some implementations, in response to determining the acquired data meets the pass criteria or receiving a status update from the instrument electronic device 104 meets the pass criteria, the electronic processor 200 generates a pass update for display via the web application.

[0099] In some implementations, the request to acquire data is added to a queue (for example, an acquisition queue). In some implementations, the queue includes a plurality of requests. In some implementations, the action included in an acquisition rule is adding requests to the queue, removing requests from the queue, or pausing the queue. In other implementations, the action is generating a failure update for display via the web application and the failure update includes an explanation regarding failure to meet the pass criteria. For example, the failure update may be generated based on a status update received from the instrument electronic device 104. In other implementations, the action is sending to the instrument electronic device 104 a request to adjust a setting of the instrument electronic device 104. In some implementations, the action is an electronic processor included in the instrument electronic device 104 sending a request to adjust a setting of an instrument 112 to the instrument 112.

[0100] In some implementations, IRC rules may be applied to multiple data acquisitions. For example, a set of IRC rules based on trending analysis or comparison analysis may be utilized across multiple acquired samples. Additionally, existing data that has been collected may leveraged to aid in generating acquisition rules (for example, generating pass criteria). Forexample, already acquired data may be displayed in the web application for a user to review and make one or more selections for acquisition rules based on.

[0101] In some implementations, summary information including an explanation as to why acquired data passed or failed (met or did not meet pass criteria). In some implementations, to facilitate simple post-acquisition review of acquired data and to better interrogate the quality of the acquired data manually, using an acquisition rule as a starting point, acquired data may be displayed in a web application in a manner that visualizes why the acquired data met or did not meet the pass criteria. For example, when a particular ion is being monitored (for example, the particular ion is the variable included in the acquisition rule), an extracted ion chromatogram that monitors the particular ion and shows the integration of the peak used to determine if the ion met or did not meet the pass criteria of the acquisition rule may be displayed via the web application. This facilitates simple post-acquisition review of the data to better interrogate the quality of the data manually, using the rule as a starting point.

[0102] FIG. 12 includes an example block diagram of data transmitted between software applications to implement the functionality described in relation to data acquisition rules. In some implementations, the web application generates one or more GUIs to allow users to make selections to create acquisition rules, associate acquisition rules with data (for example, one or more experiment designs), and, as described above send submission requests to the workflow electronic device 128. In some implementations, the experiment management application service 440 exposes a Representational State Transfer (REST) interface allowing the web application to interact with the server-based platform 210 via the communication network 120 (for example, using hypertext transfer protocol (HTTP)). In some implementations, the platform data services 430, when executed, allow information to be persisted for later retrieval.Information includes update statuses, experiment designs, acquisition rules, acquired data, processing results, a combination of the foregoing, and the like. In some implementations, the acquisition application orchestrates the instruments 112 / devices 108 involved in the acquiring data according to a request received from the workflow electronic device 128. In some implementations, the data download service 1200, when executed, provides REST endpoints downloading information required to perform data acquisition according to a request (for example, experiment methods, acquisition rules, and the like). In some implementations, theIRC processing application 1205, when executed, performs functionality similar to that described in relation to blocks 1130-1140 of FIG. 11.

[0103] The IRC rule editor GUI is displayed via the web application and allows users make selections to create or edit the criteria and actions of acquisition rules. Acquisition rules may be associated with, for example, one or more acquisition tasks included in one or more experiment designs.

[0104] In response to receiving a selection to send a submission request to the workflow electronic device 128, the web application may call the REST endpoint exposed by the experiment management application service 440 and pass the experiment design in an HTTP request payload to the experiment management application service 440. The experiment design may include different types of information, and each type of information may be persisted in different data storage locations (for example, different databases). In some implementations, the experiment management application service 440 when executed by the electronic processor 200 calls the appropriate platform data service 430 to persist each type of information. The saving of the experiment design may be orchestrated such that distributed transactions are possible across services and compensation can be executed to ensure consistency in case of failures. In some implementations, saga pattern is used, but other patterns may be used where appropriate.

[0105] In some implementations, a submission request associated with a saved experiment design may be sent to the workflow electronic device. In some implementations, the web application, when executed, invokes a submit REST endpoint exposed by the experiment management application service 440. The experiment management application service 440 may invoke the submit REST endpoint exposed by the acquisition application through a secured tunneling communication channel. The secured tunneling communication channel may be required because the server-based platform 210 may not be a part of the same intranet as the instrument electronic device 104.

[0106] In response to receiving a request to acquire data, the acquisition application, when executed, may retrieve information required to acquire the data through the data download service 1200. The data download service 1200, when executed, retrieves the required information from a storage location through the appropriate platform data services 430. In someimplementations, the data download service 1200 interacts with multiple platform data services 430 to retrieve all information required to perform data acquisition.

[0107] In some implementations, the acquisition application, when executed, orchestrates the data acquisition according to the request to acquire data received from the workflow electronic device 128. In some implementations, there are multiple acquisitions tasks for an instrument electronic device 104 to perform and each acquisition task is included in the acquisition queue. During each acquisition, the acquisition application may send status updates to the workflow electronic device 128 through calls to the platform data services 430. Once an acquisition task is complete, the acquisition application, when executed, may send the acquired data to the platform data services 430 for storage. In some implementations, the acquisition application requests IRC processing (for example, determination of whether acquired data meets pass criteria) by the IRC processing application 1205 at the beginning of a data acquisition. In other implementations, when an acquisition task is complete, the acquisition application sends a request to the IRC processing application 1205 to perform IRC processing on the acquired data. In some implementations, the IRC processing application 1205 performs parallel processing. For example, the IRC processing application 1205, when executed, determines whether different acquired data meets pass criteria simultaneously. In other implementations, the IRC processing application 1205, when executed, compares acquired data to pass criteria sequentially. For example, an IRC rule queue may be maintained by the acquisition application or the IRC processing application 1205 side to ensure IRC rule processing is performed sequentially.

[0108] In some implementations, in response to a determination that pass criteria is not met, the acquisition application, when executed, performs the action specified in the acquisition rule. The acquisition application may send the IRC result (for example, whether or not pass criteria was met) and the action performed to the platform data services 430 for storage. The IRC result and action may be published to the PMF 415 and output to the message broker 420. The IRC result and action may be displayed via the web application.

[0109] FIG. 13 is an example GUI in which selections may be made to create acquisition rules. FIG. 14 is an example GUI including the assignment of acquisition rules to acquisition tasks. FIG. 15 is an example GUI including a summary of IRC status (for example, an explanationregarding a failure to meet pass criteria) for each acquisition task. FIG. 16 is an example GUI including a brief summary of the status of the IRC rules for a single acquisition task after the acquisition task is completed.

[0110] In some implementations, the functionality described in relation to acquisition rules enables near immediate identification and management of issues during data acquisition. An acquisition queue may be paused to avoid wasting samples if an instrument or device is not performing as expected. Users may be able to select variables and set up simple or complex processing rules, including but not limited to, the identification of specific molecules, proteins, and sequence coverage. IRC rules may be customized to applications related or not related to acquiring data. The implementations described herein provide intuitive IRC rule management and detailed post-acquisition summaries. Implementations described herein may be seamlessly integrated with existing acquisition list views and data management systems. In the implementations described herein, users may leverage existing data to develop IRC rules, enhancing the accuracy and relevance of the assessment.[OHl] FIGs. 17-34 are example GUIs displayed via a web application by which one or more selections for creating an experiment design may be made.

[0112] FIGs. 35-37 are example GUIs displayed via a web application by which status updates regarding data processing and status updates regarding data acquisition are displayed.

[0113] FIG. 38 is a block diagram of a scientific instrument support module 1500 for performing support operations, in accordance with various embodiments. The scientific instrument support module 1500 may be implemented by circuitry (e.g., including electrical and / or optical components), such as a programmed computing device. The logic of the scientific instrument support module 1500 may be included in a single computing device, or may be distributed across multiple computing devices that are in communication with each other as appropriate. Examples of computing devices that may, singly or in combination, implement the scientific instrument support module 1500 are discussed herein with reference to the computing device 4000 of FIG. 40, and examples of systems of interconnected computing devices, in which the scientific instrument support module 1500 may be implemented across one or more of the computingdevices, is discussed herein with reference to the scientific instrument support system 5000 of FIG. 41.

[0114] The scientific instrument support module 1500 may include one or more logic elements. As used herein, the term “logic” may include an apparatus that is to perform a set of operations associated with the logic. For example, any of the logic elements included in the support module 1500 may be implemented by one or more computing devices programmed with instructions to cause one or more processing devices of the computing devices to perform the functionality described herein. In a particular embodiment, a logic element may include one or more non- transitory computer-readable media having instructions thereon that, when executed by one or more processing devices of one or more computing devices, cause the one or more computing devices to perform at least some of functionality described herein. As used herein, the term “module” may refer to a collection of one or more logic elements that, together, perform a function associated with the module. Different ones of the logic elements in a module may take the same form or may take different forms. For example, some logic in a module may be implemented by a programmed general-purpose processing device, while other logic in a module may be implemented by an application-specific integrated circuit (ASIC). In another example, different ones of the logic elements in a module may be associated with different sets of instructions executed by one or more processing devices. A module may not include all of the logic elements required to implement the functionality described herein; for example, a module may include a subset of the logic elements required to implement the functionality described herein when that module is to perform a subset of the operations discussed herein with reference to that module.

[0115] The scientific instrument support methods disclosed herein may include interactions with a human user (e.g., via the user local computing device 5020 discussed herein with reference to FIG. 41). These interactions may include providing information to the user (e.g., information regarding the operation of a scientific instrument such as the scientific instrument 5010 of FIG. 41, information regarding a sample being analyzed or other test or measurement performed by a scientific instrument, information retrieved from a local or remote database, or other information) or providing an option for a user to input commands (e.g., to control the operation of a scientific instrument such as the scientific instrument 5010 of FIG. 41, or to control theanalysis of data generated by a scientific instrument), queries (e.g., to a local or remote database), or other information. In some embodiments, these interactions may be performed through a graphical user interface (GUI) that includes a visual display on a display device (e.g., the display device 4010 discussed herein with reference to FIG. 4) that provides outputs to the user and / or prompts the user to provide inputs (e.g., via one or more input devices, such as a keyboard, mouse, trackpad, or touchscreen, included in the other I / O devices 4012 discussed herein with reference to FIG. 40). The scientific instrument support systems disclosed herein may include any suitable GUIs for interaction with a user.

[0116] FIG. 39 depicts an example GUI 3000 that may be used in the performance of some or all of the support methods disclosed herein, in accordance with various embodiments. Various examples of GUIs for use with the systems and methods disclosed herein can be seen in FIGS. 9 and 13-37, for example. As noted above, the GUI 3000 may be provided on a display device (e.g., the display device 4010 discussed herein with reference to FIG. 40) of a computing device (e.g., the computing device 4000 discussed herein with reference to FIG. 40) of a scientific instrument support system (e.g., the scientific instrument support system 5000 discussed herein with reference to FIG. 41), and a user may interact with the GUI 3000 using any suitable input device (e.g., any of the input devices included in the other I / O devices 4012 discussed herein with reference to FIG. 40) and input technique (e.g., movement of a cursor, motion capture, facial recognition, gesture detection, voice recognition, actuation of buttons, etc.).

[0117] The GUI 3000 may include a data display region 3002, a data analysis region 3004, a scientific instrument control region 3006, and a settings region 3008. The particular number and arrangement of regions depicted in FIG. 39 is simply illustrative, and any number and arrangement of regions, including any desired features, may be included in a GUI 3000.

[0118] The data display region 3002 may display data generated by a scientific instrument (e g., the scientific instrument 5010 discussed herein with reference to FIG. 41). For example, the data display region 3002 may display any of the data disclosed herein.

[0119] The data analysis region 3004 may display the results of data analysis (e.g., the results of analyzing the data illustrated in the data display region 3002 and / or other data). For example, the data analysis region 3004 may display data analysis results, for example. In some embodiments,the data display region 3002 and the data analysis region 3004 may be combined in the GUI 3000 (e.g., to include data output from a scientific instrument, and some analysis of the data, in a common graph or region).

[0120] The scientific instrument control region 3006 may include options that allow the user to control a scientific instrument (e.g., the scientific instrument 5010 discussed herein with reference to FIG. 41). For example, the scientific instrument control region 3006 may include any of the parameters disclosed herein.

[0121] The settings region 3008 may include options that allow the user to control the features and functions of the GUI 3000 (and / or other GUIs) and / or perform common computing operations with respect to the data display region 3002 and data analysis region 3004 (e g., saving data on a storage device, such as the storage device 4004 discussed herein with reference to FIG. 40, sending data to another user, labeling data, etc.). For example, the settings region 3008 may include any of the settings disclosed herein.

[0122] As noted above, the scientific instrument support module 1000 may be implemented by one or more computing devices. FIG. 40 is a block diagram of a computing device 4000 that may perform some or all of the scientific instrument support methods disclosed herein, in accordance with various embodiments. In some embodiments, the scientific instrument support module 1000 may be implemented by a single computing device 4000 or by multiple computing devices 4000. Further, as discussed below, a computing device 4000 (or multiple computing devices 4000) that implements the scientific instrument support module 1500 may be part of one or more of the scientific instrument 5010, the user local computing device 5020, the service local computing device 5030, or the remote computing device 5040 of FIG. 41.

[0123] The computing device 4000 of FIG. 40 is illustrated as having a number of components, but any one or more of these components may be omitted or duplicated, as suitable for the application and setting. In some embodiments, some or all of the components included in the computing device 4000 may be attached to one or more motherboards and enclosed in a housing (e g., including plastic, metal, and / or other materials). In some embodiments, some of these components may be fabricated onto a single system-on-a-chip (SoC) (e.g., an SoC may include one or more processing devices 4002 and one or more storage devices 4004). Additionally, invarious embodiments, the computing device 4000 may not include one or more of the components illustrated in FIG. 40, but may include interface circuitry (not shown) for coupling to the one or more components using any suitable interface (e.g., a Universal Serial Bus (USB) interface, a High-Definition Multimedia Interface (HDMI) interface, a Controller Area Network (CAN) interface, a Serial Peripheral Interface (SPI) interface, an Ethernet interface, a wireless interface, or any other appropriate interface). For example, the computing device 4000 may not include a display device 4010, but may include display device interface circuitry (e.g., a connector and driver circuitry) to which a display device 4010 may be coupled.

[0124] The computing device 4000 may include a processing device 4002 (e.g., one or more processing devices). As used herein, the term "processing device" may refer to any device or portion of a device that processes electronic data from registers and / or memory to transform that electronic data into other electronic data that may be stored in registers and / or memory. The processing device 4002 may include one or more digital signal processors (DSPs), applicationspecific integrated circuits (ASICs), central processing units (CPUs), graphics processing units (GPUs), cryptoprocessors (specialized processors that execute cryptographic algorithms within hardware), server processors, or any other suitable processing devices.

[0125] The computing device 4000 may include a storage device 4004 (e.g., one or more storage devices). The storage device 4004 may include one or more memory devices such as random access memory (RAM) (e.g., static RAM (SRAM) devices, magnetic RAM (MRAM) devices, dynamic RAM (DRAM) devices, resistive RAM (RRAM) devices, or conductive-bridging RAM (CBRAM) devices), hard drive-based memory devices, solid-state memory devices, networked drives, cloud drives, or any combination of memory devices. In some embodiments, the storage device 4004 may include memory that shares a die with a processing device 4002. In such an embodiment, the memory may be used as cache memory and may include embedded dynamic random access memory (eDRAM) or spin transfer torque magnetic random access memory (STT-MRAM), for example. In some embodiments, the storage device 4004 may include non- transitory computer readable media having instructions thereon that, when executed by one or more processing devices (e.g., the processing device 4002), cause the computing device 4000 to perform any appropriate ones of or portions of the methods disclosed herein.

[0126] The computing device 4000 may include an interface device 4006 (e.g., one or more interface devices 4006). The interface device 4006 may include one or more communication chips, connectors, and / or other hardware and software to govern communications between the computing device 4000 and other computing devices. For example, the interface device 4006 may include circuitry for managing wireless communications for the transfer of data to and from the computing device 4000. The term "wireless" and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communications channels, etc., that may communicate data through the use of modulated electromagnetic radiation through a nonsolid medium. The term does not imply that the associated devices do not contain any wires, although in some embodiments they might not. Circuitry included in the interface device 4006 for managing wireless communications may implement any of a number of wireless standards or protocols, including but not limited to Institute for Electrical and Electronic Engineers (IEEE) standards including Wi-Fi (IEEE 802.11 family), IEEE 802.16 standards (e.g., IEEE 802.16- 2005 Amendment), Long-Term Evolution (LTE) project along with any amendments, updates, and / or revisions (e.g., advanced LTE project, ultra mobile broadband (UMB) project (also referred to as "3GPP2"), etc.). In some embodiments, circuitry included in the interface device 4006 for managing wireless communications may operate in accordance with a Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Evolved HSPA (E- HSPA), or LTE network. In some embodiments, circuitry included in the interface device 4006 for managing wireless communications may operate in accordance with Enhanced Data for GSM Evolution (EDGE), GSM EDGE Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN). In some embodiments, circuitry included in the interface device 4006 for managing wireless communications may operate in accordance with Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Digital Enhanced Cordless Telecommunications (DECT), Evolution-Data Optimized (EV-DO), and derivatives thereof, as well as any other wireless protocols that are designated as 3G, 4G, 5G, and beyond. In some embodiments, the interface device 4006 may include one or more antennas (e.g., one or more antenna arrays) to receipt and / or transmission of wireless communications.

[0127] In some embodiments, the interface device 4006 may include circuitry for managing wired communications, such as electrical, optical, or any other suitable communication protocols. For example, the interface device 4006 may include circuitry to support communications in accordance with Ethernet technologies. In some embodiments, the interface device 4006 may support both wireless and wired communication, and / or may support multiple wired communication protocols and / or multiple wireless communication protocols. For example, a first set of circuitry of the interface device 4006 may be dedicated to shorter-range wireless communications such as Wi-Fi or Bluetooth, and a second set of circuitry of the interface device 4006 may be dedicated to longer-range wireless communications such as global positioning system (GPS), EDGE, GPRS, CDMA, WiMAX, LTE, EV-DO, or others. In some embodiments, a first set of circuitry of the interface device 4006 may be dedicated to wireless communications, and a second set of circuitry of the interface device 4006 may be dedicated to wired communications.

[0128] The computing device 4000 may include battery / power circuitry 4008. The battery / power circuitry 4008 may include one or more energy storage devices (e.g., batteries or capacitors) and / or circuitry for coupling components of the computing device 4000 to an energy source separate from the computing device 4000 (e.g., AC line power).

[0129] The computing device 4000 may include a display device 4010 (e.g., multiple display devices). The display device 4010 may include any visual indicators, such as a heads-up display, a computer monitor, a projector, a touchscreen display, a liquid crystal display (LCD), a lightemitting diode display, or a flat panel display.

[0130] The computing device 4000 may include other input / output (I / O) devices 4012. The other I / O devices 4012 may include one or more audio output devices (e.g., speakers, headsets, earbuds, alarms, etc.), one or more audio input devices (e.g., microphones or microphone arrays), location devices (e.g., GPS devices in communication with a satellite-based system to receive a location of the computing device 4000, as known in the art), audio codecs, video codecs, printers, sensors (e.g., thermocouples or other temperature sensors, humidity sensors, pressure sensors, vibration sensors, accelerometers, gyroscopes, etc ), image capture devices such as cameras, keyboards, cursor control devices such as a mouse, a stylus, a trackball, or a touchpad,bar code readers, Quick Response (QR) code readers, or radio frequency identification (RFID) readers, for example.

[0131] The computing device 4000 may have any suitable form factor for its application and setting, such as a handheld or mobile computing device (e.g., a cell phone, a smart phone, a mobile internet device, a tablet computer, a laptop computer, a netbook computer, an ultrabook computer, a personal digital assistant (PDA), an ultra mobile personal computer, etc.), a desktop computing device, or a server computing device or other networked computing component.

[0132] One or more computing devices implementing any of the scientific instrument support modules or methods disclosed herein may be part of a scientific instrument support system. FIG. 41 is a block diagram of an example scientific instrument support system 5000 in which some or all of the scientific instrument support methods disclosed herein may be performed, in accordance with various embodiments. The scientific instrument support modules and methods disclosed herein (e.g., the scientific instrument support module 1500 of FIG. 38, the method 300 of FIG. 3, the method 1100 of FIG. 11) may be implemented by one or more of the scientific instrument 5010, the user local computing device 5020, the service local computing device 5030, or the remote computing device 5040 of the scientific instrument support system 5000.

[0133] Any of the scientific instrument 5010, the user local computing device 5020, the service local computing device 5030, or the remote computing device 5040 may include any of the embodiments of the computing device 4000 discussed herein with reference to FIG. 40, and any of the scientific instrument 5010, the user local computing device 5020, the service local computing device 5030, or the remote computing device 5040 may take the form of any appropriate ones of the embodiments of the computing device 4000 discussed herein with reference to FIG. 40.

[0134] The scientific instrument 5010, the user local computing device 5020, the service local computing device 5030, or the remote computing device 5040 may each include a processing device 5002, a storage device 5004, and an interface device 5006. The processing device 5002 may take any suitable form, including the form of any of the processing devices 4002 discussed herein with reference to FIG. 40, and the processing devices 5002 included in different ones of the scientific instrument 5010, the user local computing device 5020, the service local computingdevice 5030, or the remote computing device 5040 may take the same form or different forms. The storage device 5004 may take any suitable form, including the form of any of the storage devices 4004 discussed herein with reference to FIG. 40, and the storage devices 5004 included in different ones of the scientific instrument 5010, the user local computing device 5020, the service local computing device 5030, or the remote computing device 5040 may take the same form or different forms. The interface device 5006 may take any suitable form, including the form of any of the interface devices 4006 discussed herein with reference to FIG. 40, and the interface devices 5006 included in different ones of the scientific instrument 5010, the user local computing device 5020, the service local computing device 5030, or the remote computing device 5040 may take the same form or different forms.

[0135] The scientific instrument 5010, the user local computing device 5020, the service local computing device 5030, and the remote computing device 5040 may be in communication with other elements of the scientific instrument support system 5000 via communication pathways 5008. The communication pathways 5008 may communicatively couple the interface devices 5006 of different ones of the elements of the scientific instrument support system 5000, as shown, and may be wired or wireless communication pathways (e.g., in accordance with any of the communication techniques discussed herein with reference to the interface devices 4006 of the computing device 4000 of FIG. 40). The particular scientific instrument support system 5000 depicted in FIG. 41 includes communication pathways between each pair of the scientific instrument 5010, the user local computing device 5020, the service local computing device 5030, and the remote computing device 5040, but this “fully connected” implementation is simply illustrative, and in various embodiments, various ones of the communication pathways 5008 may be absent. For example, in some embodiments, a service local computing device 5030 may not have a direct communication pathway 5008 between its interface device 5006 and the interface device 5006 of the scientific instrument 5010, but may instead communicate with the scientific instrument 5010 via the communication pathway 5008 between the service local computing device 5030 and the user local computing device 5020 and the communication pathway 5008 between the user local computing device 5020 and the scientific instrument 5010.

[0136] The scientific instrument 5010 may include any appropriate scientific instrument, such as a charged particle microscope, mass spectrometer, chromatography instrument, or any other suitable instrument.

[0137] The user local computing device 5020 may be a computing device (e.g., in accordance with any of the embodiments of the computing device 4000 discussed herein) that is local to a user of the scientific instrument 5010. In some embodiments, the user local computing device 5020 may also be local to the scientific instrument 5010, but this need not be the case; for example, a user local computing device 5020 that is in a user’s home or office may be remote from, but in communication with, the scientific instrument 5010 so that the user may use the user local computing device 5020 to control and / or access data from the scientific instrument 5010. In some embodiments, the user local computing device 5020 may be a laptop, smartphone, or tablet device. In some embodiments the user local computing device 5020 may be a portable computing device.

[0138] The service local computing device 5030 may be a computing device (e.g., in accordance with any of the embodiments of the computing device 4000 discussed herein) that is local to an entity that services the scientific instrument 5010. For example, the service local computing device 5030 may be local to a manufacturer of the scientific instrument 5010 or to a third-party service company. In some embodiments, the service local computing device 5030 may communicate with the scientific instrument 5010, the user local computing device 5020, and / or the remote computing device 5040 (e.g., via a direct communication pathway 5008 or via multiple “indirect” communication pathways 5008, as discussed above) to receive data regarding the operation of the scientific instrument 5010, the user local computing device 5020, and / or the remote computing device 5040 (e.g., the results of self-tests of the scientific instrument 5010, calibration coefficients used by the scientific instrument 5010, the measurements of sensors associated with the scientific instrument 5010, etc.). In some embodiments, the service local computing device 5030 may communicate with the scientific instrument 5010, the user local computing device 5020, and / or the remote computing device 5040 (e.g., via a direct communication pathway 5008 or via multiple “indirect” communication pathways 5008, as discussed above) to transmit data to the scientific instrument 5010, the user local computing device 5020, and / or the remote computing device 5040 (e.g., to update programmed instructions,such as firmware, in the scientific instrument 5010, to initiate the performance of test or calibration sequences in the scientific instrument 5010, to update programmed instructions, such as software, in the user local computing device 5020 or the remote computing device 5040, etc.). A user of the scientific instrument 5010 may utilize the scientific instrument 5010 or the user local computing device 5020 to communicate with the service local computing device 5030 to report a problem with the scientific instrument 5010 or the user local computing device 5020, to request a visit from a technician to improve the operation of the scientific instrument 5010, to order consumables or replacement parts associated with the scientific instrument 5010, or for other purposes.

[0139] The remote computing device 5040 may be a computing device (e.g., in accordance with any of the embodiments of the computing device 4000 discussed herein) that is remote from the scientific instrument 5010 and / or from the user local computing device 5020. In some embodiments, the remote computing device 5040 may be included in a datacenter or other large- scale server environment. In some embodiments, the remote computing device 5040 may include network-attached storage (e.g., as part of the storage device 5004). The remote computing device 5040 may store data generated by the scientific instrument 5010, perform analyses of the data generated by the scientific instrument 5010 (e.g., in accordance with programmed instructions), facilitate communication between the user local computing device 5020 and the scientific instrument 5010, and / or facilitate communication between the service local computing device 5030 and the scientific instrument 5010. The remote computing device may allow a user to configure and submit experiments, for example, remotely.

[0140] In some embodiments, one or more of the elements of the scientific instrument support system 5000 illustrated in FIG. 41 may not be present. Further, in some embodiments, multiple ones of various ones of the elements of the scientific instrument support system 5000 of FIG. 41 may be present. For example, a scientific instrument support system 5000 may include multiple user local computing devices 5020 (e.g., different user local computing devices 5020 associated with different users or in different locations). In another example, a scientific instrument support system 5000 may include multiple scientific instruments 5010, all in communication with service local computing device 5030 and / or a remote computing device 5040; in such an embodiment, the service local computing device 5030 may monitor these multiple scientific instruments 5010,and the service local computing device 5030 may cause updates or other information may be “broadcast” to multiple scientific instruments 5010 at the same time. Different ones of the scientific instruments 5010 in a scientific instrument support system 5000 may be located close to one another (e.g., in the same room) or farther from one another (e.g., on different floors of a building, in different buildings, in different cities, etc.). In some embodiments, a scientific instrument 5010 may be connected to an Intemet-of-Things (loT) stack that allows for command and control of the scientific instrument 5010 through a web-based application, a virtual or augmented reality application, a mobile application, and / or a desktop application. Any of these applications may be accessed by a user operating the user local computing device 5020 in communication with the scientific instrument 5010 by the intervening remote computing device 5040. In some embodiments, a scientific instrument 5010 may be sold by the manufacturer along with one or more associated user local computing devices 5020 as part of a local scientific instrument computing unit 5012.

[0141] In some embodiments, different ones of the scientific instruments 5010 included in a scientific instrument support system 5000 may be different types of scientific instruments 5010; for example, one scientific instrument 5010 may be a charged particle microscope, while another scientific instrument 5010 may be a mass spectrometer. In some such embodiments, the remote computing device 5040 and / or the user local computing device 5020 may combine data from different types of scientific instruments 5010 included in a scientific instrument support system 5000.

[0142] Clause 1. A system for controlling experiment execution, the system comprising: an instrument electronic device; and a workflow electronic device, wherein the workflow electronic device is connected to the instrument electronic device via a communication network and the workflow electronic device includes: an electronic processor, the electronic processor configured to: receive a submission request via a web application, wherein the submission request includes an experiment design and the experiment design includes an acquisition task; receive an acquisition rule, wherein the acquisition rule includes pass criteria and an action to take when acquired data does meet not the pass criteria; associate the acquisition rule with the acquisition task; based on the experiment design, generate a request to perform the acquisition task to send to the instrument electronic device, the request associated with operating instructions for theinstrument electronic device to perform an experiment on a sample to acquire data; send, to the instrument electronic device via the communication network, the request to acquire data; and in response to the data being acquired and uploaded to a location by the instrument electronic device according to the request to acquire data, determine whether the acquired data meets the pass criteria; and in response to determining the acquired data does not meet the pass criteria, perform the action.

[0143] Clause 2. The system according to clause 1, wherein the electronic processor is configured to: in response to determining the acquired data meets the pass criteria, generate a pass update for display via the web application.

[0144] Clause 3. The system according to clause 1, wherein the electronic processor is configured to: determine whether the acquired data meets the pass criteria during performance of the acquisition task.

[0145] Clause 4. The system according to clause 1, wherein the electronic processor is configured to: determine whether the acquired data meets the pass criteria in response to the acquisition task completing.

[0146] Clause 5. The system according to clause 1, wherein the acquired data is chromatography data or mass spectrometry data.

[0147] Clause 6. The system according to clause 1, wherein the pass criteria includes a variable and a condition and the pass criteria is met when a value determined by the instrument electronic device for the variable satisfies the condition.

[0148] Clause 7. The system according to clause 1, wherein the acquired data includes a value for a parameter of the instrument electronic device.

[0149] Clause 8. The system according to clause 1, wherein the electronic processor is configured to: add the request to a queue, wherein the queue includes a plurality of requests and the action includes adding requests to the queue, removing requests from the queue, or pausing the queue.

[0150] Clause 9. The system according to clause 1, wherein the action is generating a failure update for display via the web application and the failure update includes an explanation regarding failure to meet the pass criteria.

[0151] Clause 10. The system according to clause 1, wherein the action is sending to the instrument electronic device a request to adjust a setting of the instrument electronic device.

[0152] Clause 11. A method for controlling experiment execution, the method comprising: receiving a submission request via a web application, wherein the submission request includes an experiment design and the experiment design includes an acquisition task; receiving an acquisition rule, wherein the acquisition rule includes pass criteria and an action to take when acquired data does not meet the pass criteria; associating the acquisition rule with the acquisition task; based on the experiment design, generating a request to perform the acquisition task to send to an instrument electronic device, the request associated with operating instructions for the instrument electronic device to perform an experiment on a sample to acquire data; sending, to the instrument electronic device, the request to acquire data; and in response to the data being acquired by the instrument electronic device according to the request to acquire data, determining whether the acquired data meets the pass criteria; and in response to determining the acquired data does not meet the pass criteria, performing the action.

[0153] Clause 12. The method according to clause 11, the method further comprising: in response to determining the acquired data meets the pass criteria, generate a pass update for display via the web application.

[0154] Clause 13. The method according to clause 11, the method further comprising: determine whether the acquired data meets the pass criteria during performance of the acquisition task.

[0155] Clause 14. The method according to clause 11, the method further comprising: determine whether the acquired data meets the pass criteria in response to the acquisition task completing.

[0156] Clause 15. The method according to clause 11, wherein the acquired data is chromatography data or mass spectrometry data.

[0157] Clause 16. The method according to clause 11, wherein the pass criteria includes a variable and a condition and the pass criteria is met when a value determined by the instrument electronic device for the variable satisfies the condition.

[0158] Clause 17. The method according to clause 11, wherein the acquired data includes a value for a parameter of the instrument electronic device.

[0159] Clause 18. The method according to clause 11, the method further comprising: adding the request to a queue, wherein the queue includes a plurality of requests and the action includes adding requests to the queue, removing requests from the queue, or pausing the queue.

[0160] Clause 19. The method according to clause 11, wherein the action is generating a failure update for display via the web application and the failure update includes an explanation regarding failure to meet the pass criteria.

[0161] Clause 20. The method according to clause 11, wherein the action is sending to the instrument electronic device a request to adjust a setting of the instrument electronic device.

Claims

CLAIMSWhat is claimed is:

1. A system for controlling experiment execution, the system comprising: an instrument electronic device; and a workflow electronic device, wherein the workflow electronic device is connected to the instrument electronic device via a communication network and the workflow electronic device includes: an electronic processor, the electronic processor configured to: receive a submission request via a web application, wherein the submission request includes an experiment design and the experiment design includes an acquisition task; receive an acquisition rule, wherein the acquisition rule includes pass criteria and an action to take when acquired data does meet not the pass criteria; associate the acquisition rule with the acquisition task; based on the experiment design, generate a request to perform the acquisition task to send to the instrument electronic device, the request associated with operating instructions for the instrument electronic device to perform an experiment on a sample to acquire data; send, to the instrument electronic device via the communication network, the request to acquire data; and in response to the data being acquired and uploaded to a location by the instrument electronic device according to the request to acquire data, determine whether the acquired data meets the pass criteria; and in response to determining the acquired data does not meet the pass criteria, perform the action.

2. The system according to claim 1, wherein the electronic processor is configured to: in response to determining the acquired data meets the pass criteria, generate a pass update for display via the web application.

3. The system according to claim 1, wherein the electronic processor is configured to: determine whether the acquired data meets the pass criteria during performance of the acquisition task.

4. The system according to claim 1, wherein the electronic processor is configured to: determine whether the acquired data meets the pass criteria in response to the acquisition task completing.

5. The system according to claim 1, wherein the acquired data is chromatography data or mass spectrometry data.

6. The system according to claim 1, wherein the pass criteria includes a variable and a condition and the pass criteria is met when a value determined by the instrument electronic device for the variable satisfies the condition.

7. The system according to claim 1, wherein the acquired data includes a value for a parameter of the instrument electronic device.

8. The system according to claim 1, wherein the electronic processor is configured to: add the request to a queue, wherein the queue includes a plurality of requests and the action includes adding requests to the queue, removing requests from the queue, or pausing the queue.

9. The system according to claim 1, wherein the action is generating a failure update for display via the web application and the failure update includes an explanation regarding failure to meet the pass criteria.

10. The system according to claim 1, wherein the action is sending to the instrument electronic device a request to adjust a setting of the instrument electronic device.

11. A method for controlling experiment execution, the method comprising: receiving a submission request via a web application, wherein the submission request includes an experiment design and the experiment design includes an acquisition task; receiving an acquisition rule, wherein the acquisition rule includes pass criteria and an action to take when acquired data does not meet the pass criteria; associating the acquisition rule with the acquisition task; based on the experiment design, generating a request to perform the acquisition task to send to an instrument electronic device, the request associated with operating instructions for the instrument electronic device to perform an experiment on a sample to acquire data; sending, to the instrument electronic device, the request to acquire data; and in response to the data being acquired by the instrument electronic device according to the request to acquire data, determining whether the acquired data meets the pass criteria; and in response to determining the acquired data does not meet the pass criteria, performing the action.

12. The method according to claim 11, the method further comprising: in response to determining the acquired data meets the pass criteria, generate a pass update for display via the web application.

13. The method according to claim 11, the method further comprising: determine whether the acquired data meets the pass criteria during performance of the acquisition task.

14. The method according to claim 11, the method further comprising: determine whether the acquired data meets the pass criteria in response to the acquisition task completing.

15. The method according to claim 11 , wherein the acquired data is chromatography data or mass spectrometry data.

16. The method according to claim 11, wherein the pass criteria includes a variable and a condition and the pass criteria is met when a value determined by the instrument electronic device for the variable satisfies the condition.

17. The method according to claim 11, wherein the acquired data includes a value for a parameter of the instrument electronic device.

18. The method according to claim 11 , the method further comprising: adding the request to a queue, wherein the queue includes a plurality of requests and the action includes adding requests to the queue, removing requests from the queue, or pausing the queue.

19. The method according to claim 11, wherein the action is generating a failure update for display via the web application and the failure update includes an explanation regarding failure to meet the pass criteria.

20. The method according to claim 1 1 , wherein the action is sending to the instrument electronic device a request to adjust a setting of the instrument electronic device.

Images