Instrument health data workflow

Abstract

The invention provides a scientific instrument support device. The scientific instrument support device comprises a first logic component, a second logic component and a third logic component, the first logic component subscribes to an event from a device driver, receives a signature data event including a generated signature event, generates signature data having a specified signature identifier in response to the generated signature event, and transmits the signature data to the second logic component. The second logic component receives the signature data from the first logic component, processes the signature data, writes the processed signature data into an instrument health database, and transmits the signature data to a cloud-based database. The third logic component presents a graphical user interface based on the processed signature data. The device is capable of efficiently collecting, processing and presenting scientific instrument data, thereby improving monitoring and analysis.

Description

Background Technology

[0001] Scientific instruments can comprise complex arrangements of movable components, sensors, input and output ports, power sources, and consumable components. Failure or alteration of any part of this arrangement can result in a "failed" instrument—an instrument that cannot perform its intended function. Scientific instruments include the ability to extract or transmit data used to monitor the health of the instrument. Attached Figure Description

[0002] Various embodiments will be readily understood through the following detailed description taken in conjunction with the accompanying drawings. For ease of this description, the same reference numerals denote the same structural elements. Embodiments are shown in the accompanying drawings by way of example rather than limitation. Figure 1 is a block diagram of an example scientific instrument support system according to various implementation schemes, in which some or all of the scientific instrument support methods disclosed herein can be performed.

[0003] Figure 2 is a block diagram of an example scientific instrument support system for performing support operations according to various implementation schemes.

[0004] Figure 3 is a block diagram of an example scientific instrument support module for performing support operations according to various implementation schemes.

[0005] Figure 4A Figure 4D shows example data structures implemented within the scientific instrument support system of Figure 2 according to various implementation schemes.

[0006] Figure 5 illustrates example graphical user interfaces according to various implementation schemes, which can be used to perform some or all of the supported methods disclosed herein.

[0007] Figure 6 is a flowchart of example methods for performing support operations according to various implementation schemes.

[0008] Figure 7 is a block diagram of an example computing device that can perform some or all of the scientific instrument support methods disclosed herein, according to various implementation schemes.

[0009] Figure 8 is a block diagram of another example scientific instrument support system according to various implementation schemes, in which some or all of the scientific instrument support methods disclosed herein can be performed. Detailed Implementation

[0010] Modern laboratory systems comprise a vast array of medical and research equipment and instruments across large facilities. Furthermore, during the research and use of these instruments, users in one facility can utilize equipment or instruments in another facility connected via wireless or wireless communication networks (e.g., via the cloud). While these technological advancements have improved interoperability and provided new means of conducting research, the diverse array of instruments with varying quantities and types of configurations and health data makes effective monitoring of the health of laboratory systems challenging. Instruments of different categories or manufacturers may generate, store, and transmit data in different ways. Moreover, each device can have a data inventory comprising tens of thousands of attributes. Consequently, operators of such systems lack a single platform to monitor the health and performance of their systems.

[0011] Therefore, the implementation schemes described herein provide systems, methods, and apparatuses for instrument health data workflows. The implementation schemes presented herein provide structured, standardized data across multiple instruments over time. Using such implementation schemes, operators of scientific instruments can establish a unified framework to achieve a complete end-to-end instrument health data workflow, including definition, generation, transmission, processing, storage, and utilization. Using the implementation schemes provided herein, device drivers collect data inventories, process these inventories using specifications and schemas to generate signed data in a single format, which can be stored locally, in the cloud, or used to provide comprehensive instrument health data to operators using web-based applications.

[0012] Operators may wish to view a health status view of all devices provided in the research system. The implementation described herein provides a user interface that offers a summary view of the devices in the research system. Devices and their statuses can be represented on the user interface using various shapes, icons, colors, patterns, etc. Operators can interact with devices using the user interface to view more detailed information about the devices and adjust their characteristics.

[0013] This article discloses scientific instrument support systems, as well as related methods, computing devices, and computer-readable media.

[0014] In some aspects, the technology described herein relates to a scientific instrument support device comprising: a first logic component for: subscribing to events from a device driver; receiving, based on the event subscription, a signature data event from the device driver, the signature data event including a generated signature event; and, in response to receiving the generated signature event, generating signature data having a specified signature identifier; and transmitting the signature data to a second logic component; a second logic component for: receiving the signature data from the first logic component; processing the signature data; writing the processed signature data to an instrument health database; and transmitting the signature data to a cloud-based database; and a third logic component for presenting a graphical user interface based on the processed signature data.

[0015] In some respects, the technology described herein relates to a scientific instrument support method comprising: receiving a subscription request, including a device identifier and a signature identifier, via a driver module; sending a data list to a data performance metrics module based on the device identifier and the signature identifier; generating signature data by the data performance metrics module based on the data list and a specification document identified by the signature identifier; transmitting the signature data to the driver module via the data performance metrics module; and transmitting the processed signature data to an instrument monitoring service.

[0016] The scientific instrument support implementation scheme disclosed herein achieves improved performance compared to conventional methods. The proposed implementation scheme can provide longitudinal data for "health" systems and objective data for different consumers. A consistent data framework allows operators to query the database to concisely report recent events and provide self-recovery. This reduces downtime, avoids service calls, and improves the consistency of system performance. Furthermore, a reliable data workflow improves product development / improvement and efficiency. Therefore, the implementation scheme disclosed herein provides improvements to scientific instrument technology (e.g., improvements to the computer technology supporting such scientific instruments, and others).

[0017] The embodiments disclosed herein provide a means for identifying equipment malfunctions and monitoring system health in large laboratory environments. Furthermore, among other things, the various embodiments disclosed herein offer improvements to graphical user interface (GUI) technologies. For example, the GUI provided herein offers a structured view supporting the status of all components within the system, such as equipment and scientific instruments.

[0018] The various implementations of the embodiments disclosed herein improve upon conventional methods, achieving a technical advantage in increasing experimental throughput by identifying instrument malfunctions and delaying the execution of operations until the system recovers from the errors and delays. Such technical advantages cannot be achieved through conventional and traditional methods, and all users of systems incorporating such implementations can benefit from these advantages (e.g., by assisting users in performing technical tasks, such as identifying stalled instruments and failed command paths through guided human-computer interaction processes). Therefore, the technical features of the embodiments disclosed herein are clearly unconventional in the field of laboratory communication systems, as are the combinations of features of the embodiments disclosed herein. The computational and user interface features disclosed herein involve not only the collection and comparison of information but also the application of new analytical and technical techniques to alter the operation of instrument support systems. Therefore, this disclosure introduces functionality that is impossible for conventional computing devices and humans to perform.

[0019] Therefore, embodiments of this disclosure can serve any of a variety of technical purposes, such as controlling a particular technical system or process; determining how to control a machine based on measurement results; optimizing load distribution in a computer network; simulating the behavior of a technical project or process; or providing faster sensor data processing.

[0020] In the following detailed description, reference is made to the accompanying drawings, which form part of the detailed description, wherein like reference numerals always indicate like parts, and practical embodiments are illustrated in the drawings by way of illustration. It should be understood that other embodiments may be utilized, and structural or logical changes may be made, without departing from the scope of this disclosure. Therefore, the following detailed description should not be regarded as limiting.

[0021] The various operations can be described sequentially as multiple discrete actions or operations in a manner most conducive to understanding the subject matter disclosed herein. However, the described order should not be construed as implying that these operations must depend on the order. Specifically, these operations may not be performed in the order presented. The described operations may be performed in a different order than the described embodiments. Various additional operations may be performed, and / or the described operations may be omitted in additional embodiments.

[0022] For the purposes of this disclosure, the phrases “A and / or B” and “A or B” mean (A), (B), or (A and B). For the purposes of this 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 represented in the singular (e.g., “processing device”), any suitable element may be represented by multiple instances of that element, and vice versa. For example, a set of operations described as being performed by a processing device may be implemented as different operations among those operations performed by different processing devices.

[0023] This specification uses the phrases “implementation,” “various embodiments,” and “some embodiments,” each of which can refer to one or more embodiments of the same or different implementations. Furthermore, the terms “comprising,” “including,” “having,” etc., used with respect to embodiments of this disclosure are synonymous. When used to describe a range of dimensions, the phrase “between X and Y” indicates a range including both X and Y. As used herein, “apparatus” can mean any single device, a collection of devices, a portion of a device, or a collection of portions of devices. The drawings are not necessarily drawn to scale.

[0024] Figure 1 is a block diagram of a scientific instrument support system 100 (hereinafter referred to as support system 100) for performing support operations according to various embodiments. As shown in Figure 1, support system 100 includes multiple instrument control personal computers (ICPs) 105 connected via a communication network 120. Each ICP 105 is connected to one or more devices 110. Device 110 is a physical entity that performs some function of sample preparation and / or sample analysis. For example, device 110 may be a physical device with a serial number that is capable of communicating with other external entities, and may include a processor, memory, and firmware. Device 110 may include, for example, sensors, detectors, actuators, spectrometers, spectrum analyzers, oscilloscopes, electrometers, interferometers, etc. ICP 105 may also include one or more instruments 112. Instrument 112 is a logical container that includes a set of devices 110. For example, devices 110 work together to perform operations and produce results. The logical set of devices 110 (e.g., instruments 112) prepares or analyzes inputs such as blood samples. Each ICP 105 is connected to its corresponding device 110 and is capable of one-way or two-way communication with the connected device 110. Each ICP 105 may connect to the device 110 via wired or wireless communication methods and / or protocols. Each ICP 105 may transmit commands to the connected device 110, receive status signals from the device 110, receive measurement results from the device 110, etc., as described in more detail below. ICP 105, device 110, and instrument 112 may be more generally referred to as service components.

[0025] Support system 100 includes a database 125 and a server 115, which are communicatively coupled to multiple ICPs 105 (and to each other) via a communication network 120. In other embodiments, the multiple ICPs 105, server 115, and database 125 communicate via one or more dedicated wired connections or other forms of wired or wireless electronic communication. It should be understood that support system 100 may include fewer or more components than those shown in FIG. 1. For example, support system 100 may include fewer or more ICPs 105, multiple servers 115, multiple databases 125, or combinations thereof. In some cases, the storage functionality of database 125 is provided by server 115, rather than including a separate database. Components of support system 100 may also communicate via one or more intermediate devices not shown in FIG. 1.

[0026] Server 115 acts as a "control center" for multiple ICPs 105. For example, server 115 communicates with each of the ICPs 105 by sending commands to perform the methods described herein via wired connection, wireless connection, or a combination thereof. Furthermore, server 115 receives measurement results and statuses of devices 110 and instruments 112 from the respective ICPs 105 via wired connection, wireless connection, or a combination thereof. Database 125 stores data indicating the status of components within supporting system 100. For example, database 125 may store the current status of devices 110 and instruments 112, the historical status of devices 110 and instruments 112, measurement results recorded by devices 110 and instruments 112, etc.

[0027] Figure 2 illustrates various aspects of the support system 100 in more detail. In the example shown in Figure 2, the support system 100 includes one or more ICPs 105, a server 115, and a cloud component 202. The cloud component 202, described below, is a cloud computing instance located remotely from other components of the support system 100 and accessible via one or more intermediate data networks. In some respects, the server 115 may be located on a local network physically close to the ICP 105 (e.g., as part of a local area network within a building or campus). In other respects, the server 115 may be located remotely from the ICP 105 (e.g., as part of a wide area network or provided by cloud infrastructure).

[0028] For ease of description, Figure 2 illustrates a single ICP 105 and server 115. However, the method described herein is applicable to instances of a support system 100 with various combinations of multiple ICPs, multiple servers, and multiple cloud instances. In some examples, server 115 is configured to support one or more ICPs of a single entity (e.g., a laboratory of a business or academic organization). In other examples, server 115 may support multiple groups of ICPs, each operated by a different entity.

[0029] The components of ICP 105 shown in Figure 2 may be software, hardware, or a combination of both, and are executed by one or more processing devices and / or stored in one or more storage devices, each of which is described herein with respect to Figure 7.

[0030] As shown in Figure 2, ICP 105 includes a Data Performance Metrics Module (DPM) 204, which communicates with the driver module 206 to receive data lists from one or more devices 110. As described herein, DPM 204 processes the data lists according to specification document 208 to generate signature data based on a pattern. As shown in Figure 2, DPM 204 can also store signature data in a local database 212.

[0031] Driver module 206 can implement one or more digital device interfaces and digital instrument interfaces. Driver module 206 communicates with Instrument Monitoring Service (ILS) 214 running on server 115. Other components shown in ILS 214 and server 115 can be software, hardware, or a combination of both, and are executed by one or more processing devices and / or stored in one or more storage devices, each as described herein with reference to Figure 7. ILS 214 is configured to receive requests and receive signature data from one or more ICPs 105, and pass the signature data to Instrument Health Service (IHS) 216. IHS 216 processes the signature data and stores it in IHS database 218. As shown in Figure 2, the IHS database is integrated with server 115. In some examples, IHS database 218 is located outside of server 115 and is accessible by one or more servers other than server 115.

[0032] In the example shown, IHS database 218 provides data to data insight application 220, which is executed by server 115, to provide operators with understandable and actionable data on relevant instruments and equipment (e.g., via a graphical user interface described herein with respect to Figure 5).

[0033] As shown in Figure 2, IHS 216 can also transmit signature data to cloud component 202. Cloud component 202 stores the signature data in cloud database 222 and provides access to the data via cloud-based application 224, which operates similarly to data insight application 220. In some respects, data insight application 220 provides access to a single entity, while cloud-based application 224 provides secure access to the data of multiple entities.

[0034] Figure 3 is a block diagram of a scientific instrument support module 300 for performing support operations according to various embodiments. The scientific instrument support module 300 may be, for example, a server 115. The scientific instrument support module 300 may be implemented by circuitry (e.g., including electrical and / or optical components), such as a programmable computing device. The logical components of the scientific instrument support module 300 may be included in a single computing device, or may be distributed across multiple computing devices communicating with each other, depending on the situation. Examples of computing devices that can implement the scientific instrument support module 300 individually or in combination are discussed herein with reference to the computing device 900 of Figure 7, and examples of systems of interconnected computing devices are discussed herein with reference to the scientific instrument support system 1000 of Figure 8, wherein the scientific instrument support module 300 may be implemented across one or more computing devices.

[0035] Scientific instrument support module 300 may include a first logic element 302, a second logic element 304, and a third logic element 306. As used herein, the term "logic element" may include means for performing a set of operations associated with the logic element. For example, any of the logic elements included in support module 300 may be implemented by one or more computing devices programmed with instructions to cause one or more processing devices of the computing device to perform an associated set of operations. In a particular embodiment, a logic element may include one or more non-transitory computer-readable media having instructions that, when executed by one or more processing devices of the one or more computing devices, cause the one or more computing devices to perform an associated set of operations. As used herein, the term "module" may refer to a collection of one or more logic elements that together perform the functions associated with the module. Different logic elements in a module may take the same form or may take different forms. For example, some logic elements in a module may be implemented by a programmed general-purpose processing device, while other logic elements in the module may be implemented by an application-specific integrated circuit (ASIC). In another example, different logical elements in a module may be associated with different sets of instructions executed by one or more processing devices. A module does not necessarily include all the logical elements depicted in the associated figures; for example, a module may include a subset of the logical elements depicted in the associated figures when it is to perform a subset of the operations discussed herein with reference to that module.

[0036] First logic unit 302 may include means for sending a request to a device driver (e.g., device module 206) to subscribe to events from the device driver. The events relate to signed data transmitted from the device driver to first logic unit 302. In some aspects, the request may identify an event for a specific device or instrument. For example, as shown in Figure 2, server 115 implements ILS 214, which can send (e.g., using a REST API) subscription network hooks to issue subscription requests. The request may include a device identifier that can be used to identify a specific device, set of devices, or instruments corresponding to the data request. The request may include a signature identifier that may include information identifying a specification document (e.g., specification document 208) used when processing the requested data. The specification document defines what information to collect from a range of instruments and how to collect it. In some examples, the specification document is a JavaScript Object Notation (JSON) file containing properties (for the instrument family) that the operator wants to collect at the frequency they want to collect.

[0037] The first logic unit 302 also receives signature data events from the device driver based on an event subscription. Signature data events may include a generate signature event. A generated signature event is a request to generate signature data with a specified signature identifier. The first logic unit 302 generates signature data in response to receiving a generate signature event. As described below with respect to method 600, the signature data is generated by DPM 204 using specification document 208. The first logic unit transmits the signature data to a second logic unit 304, which may include means for receiving signature data from the first logic unit 302. The second logic unit 304 processes the signature data. For example, the data may be parsed, chunked, binned, normalized, or similar operations may be performed for later use (e.g., by data insight application 220). The second logic unit 304 writes the processed signature data to an instrument health database (e.g., IHS database 218) and transmits the signature data to a cloud-based database (e.g., cloud database 222). In some examples, the second logic unit 304 transmits the raw signature data to the cloud-based database. In another example, the second logic unit 304 transmits the processed signature data to a cloud-based database, or transmits both the original signature data and the processed signature data simultaneously.

[0038] The third logic component 306 may include means for presenting a graphical user interface based on signature data (e.g., in some cases, processed signature data). For example, server 115 implements graphical user interface 500 via data insight application 220. Graphical user interface 500 may display the results of data analysis (e.g., the results of analyzing signature data and / or other data). For example, data insight application 220 may display the status of components within supporting system 100.

[0039] As mentioned above, data signatures can be in a text-based format for storing data retrieved from devices and instruments. Data signatures utilize Resource Description Framework (RDF) to store instrument health data. Data signatures are generated based on specification documents and can be formatted according to one of several schemas.

[0040] For example, Figure 4A shows an example of a device claim signature 400. The example signature 400 defines the instrument (mass spectrometer) and all the devices that make up the instrument, providing a unique identifier for each device. This claim can be used by the support system 100 to process subsequent data received from the mass spectrometer, or it can be used by the data insight application 220.

[0041] In another example, Figure 4B shows an example of state signature 402. A state signature can be used to identify the current state of a device or to indicate a change in the state of the device, as shown in Figure 4B.

[0042] In another example, Figure 4C shows an example of observation signature 404. Observation signatures provide aggregated data over a specified time period. In the example shown, the pump vacuum pressure observations are represented as minimum / maximum / average values ​​over 24 hours.

[0043] In another example, Figure 4D shows an example using signature 406. The signature indicates the duration of use for a specific device function. In the example shown, the heating electrospray ionization source is used for 82,800 seconds.

[0044] Other examples of signature patterns include setting patterns (e.g., device configuration settings), activity patterns (e.g., what the device is doing), and event patterns (e.g., an indication that a process on the device has started or stopped).

[0045] Figure 5 illustrates a GUI 500 according to various embodiments, which can be used to perform some or all of the supporting methods disclosed herein. As described above, the data insight application 220 can provide the GUI 500 on the computing device (e.g., the computing device 900 discussed herein with reference to Figure 7) of a scientific instrument support system (e.g., the scientific instrument support system 1000 discussed herein with reference to Figure 8) or the display device (e.g., the display device 910 discussed herein with reference to Figure 7). Users can interact with the GUI 500 using any suitable input device (e.g., any of the input devices included in the other I / O devices 912 discussed herein with reference to Figure 7) and input technologies (e.g., cursor movement, motion capture, facial recognition, gesture detection, speech recognition, button driving, etc.).

[0046] GUI 500 may include a settings area 502 and a data display area 504. The specific number and arrangement of areas depicted in Figure 5 are for illustrative purposes only, and any number and arrangement of areas (including any desired features) may be included in GUI 500.

[0047] The settings area 502 allows operators to select and filter data to be displayed in the data display area 504. The settings area may include a type sub-area 502a and a date selection sub-area 502b. The type sub-area 502a allows operators to select and / or filter data based on, for example, location, system type, system name, project, user, or a combination thereof. The date selection sub-area 502b allows operators to filter the data to be displayed based on a date range.

[0048] Data display area 504 displays data in data display sub-area 504b. Data display area 504 may display data generated by scientific instruments (e.g., scientific instrument 1010 discussed herein with reference to Figure 8), or it may display data associated with the status of components within support system 100. For example, data display area 502 may display tables or charts providing the status of components within support system 100, an example of which is shown in Figure 5. In some examples, data display area 504 may include tab 504a, which allows an operator to select a dataset from multiple datasets to display in data display sub-area 504b.

[0049] Figure 6 is a flowchart of a method 600 for performing support operations according to various embodiments. While the operation of method 600 may be illustrated with reference to specific embodiments disclosed herein (e.g., the scientific instrument support module 300 discussed herein with reference to Figure 6, the GUI 500 discussed herein with reference to Figure 5, the computing device 900 discussed herein with reference to Figure 7, and / or the scientific instrument support system 1000 discussed herein with reference to Figure 8), method 600 can be used in any suitable setup to perform any suitable support operation. The operations are each shown once in a specific order in Figure 6, but the operations may be reordered and / or repeated as needed and as appropriate (e.g., different operations may be performed in parallel where appropriate).

[0050] At box 602, method 600 includes receiving a subscription request via driver module 206, including a device identifier and a signature identifier. The device identifier identifies one or more devices and / or instruments for which data is to be collected. The signature identifier identifies information used to identify a specification document that defines what information about a set of instruments associated with the device identifier is to be collected and how that information is to be collected.

[0051] At box 604, method 600 includes sending a data manifest to a data performance metrics module (e.g., DPM 204) based on a device identifier and a signature identifier. The data manifest is generated by the device and may include key-value pairs of some or all of the data generated by the device. In some cases, data is sent to DPM 204 using a push method (e.g., sending data periodically when data is reported from the device). In other cases, data is sent to DPM 204 in response to a pull request from DPM 204.

[0052] A data list is a large collection of raw data. Therefore, at box 606, method 600 includes generating signature data from the list data via a data performance metrics module. The signature data is a simplified set of the list data, formatted in a specific manner based on the data list and the specification document identified by the signature identifier. For example, DPM 204 can parse the list to extract and / or summarize the data required in the specification. In some cases, the signature identifier further specifies a signature pattern. The signature pattern specifies the type of signature data, as described in part with respect to Figures 4A through 4D. In this case, the signature data is generated according to the signature pattern.

[0053] At box 608, method 600 includes (e.g., via DPM 204) transferring signature data to driver module 206. This can be accomplished using a network hook. In some examples, in addition to returning the signature data to the driver module, DPM 204 also stores the signature data in a local database (e.g., database 212).

[0054] At box 610, method 600 includes transmitting the signature data to an instrument monitoring service (e.g., ILS 214). For example, driver module 206 can send the signature data using a REST API.

[0055] Figure 7 is a block diagram of a computing device 900 that can perform some or all of the scientific instrument support methods disclosed herein, according to various embodiments. In some embodiments, the scientific instrument support module 300 (e.g., server 115) may be implemented by a single computing device 900 or multiple computing devices 900. Furthermore, as discussed below, the computing device 900 (or multiple computing devices 900) implementing the scientific instrument support module 300 may be part of one or more of the scientific instrument 1010 of Figure 8, the user local computing device 1020, the service local computing device 1030, or the remote computing device 1040.

[0056] The computing device 900 of Figure 7 is shown as having multiple components, but any or more of these components may be omitted or repeated depending on the application and setup requirements. In some embodiments, some or all of the components included in the computing device 900 may be attached to one or more motherboards and encapsulated 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., the SoC may include one or more processing devices 902 and one or more storage devices 904). Furthermore, in various embodiments, the computing device 900 may not include one or more of the components shown in Figure 7, but may include interface circuitry (not shown) for coupling to 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 suitable interface). For example, computing device 900 may not include display device 910, but may include display device interface circuitry (e.g., connectors and driver circuitry) to which display device 910 may be coupled.

[0057] Computing device 900 may include processing device 902 (e.g., one or more processing devices). As used herein, the term "processing device" can refer to any device or part of a device that processes electronic data from registers and / or memory to convert that electronic data into other electronic data that can be stored in registers and / or memory. Processing device 902 may include one or more digital signal processors (DSPs), application-specific integrated circuits (ASICs), central processing units (CPUs), graphics processing units (GPUs), cryptographic processors (dedicated processors that execute cryptographic algorithms within hardware), server processors, or any other suitable processing device.

[0058] Computing device 900 may include storage device 904 (e.g., one or more storage devices). Storage device 904 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 bridged RAM (CBRAM) devices), hard disk drive-based memory devices, solid-state memory devices, network drives, cloud drives, or any combination of memory devices. In some embodiments, storage device 904 may include memory sharing a die with processing device 902. In such embodiments, the memory may be used as cache memory and may include, for example, embedded dynamic random access memory (eDRAM) or spin-transfer torque magnetic random access memory (STT-MRAM). In some embodiments, storage device 904 may include a non-transitory computer-readable medium having instructions thereon that, when executed by one or more processing devices (e.g., processing device 902), cause computing device 900 to perform any suitable method or portion thereof of the methods disclosed herein.

[0059] Computing device 900 may include interface device 906 (e.g., one or more interface devices 906). Interface device 906 may include one or more communication chips, connectors, and / or other hardware and software to manage communication between computing device 900 and other computing devices. For example, interface device 906 may include circuitry for managing wireless communication used to transfer data with computing device 900. The term "wireless" and its derivatives can be used to describe circuits, devices, systems, methods, techniques, communication channels, etc., that can transmit data through a non-solid medium using modulated electromagnetic radiation. This term does not imply that the associated device does not contain any wires, although in some embodiments it may not contain any wires. The circuitry included in interface device 4006 for managing wireless communications may implement any of a number of wireless standards or protocols, including but not limited to Institute of Electrical and Electronics Engineers (IEEE) standards, including Wi-Fi (IEEE 802.11 series), IEEE 802.16 standards (e.g., IEEE 802.16-2005 amendments), Long Term Evolution (LTE) projects, and any amendments, updates, and / or revisions (e.g., Advanced LTE projects, Ultra Mobile Broadband (UMB) projects (also known as “3GPP2”), etc.). In some implementations, the circuitry included in interface device 4006 for managing wireless communications may operate according to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed ​​Packet Access (HSPA), Evolved HSPA (E-HSPA), or LTE networks. In some embodiments, the circuitry included in interface device 4006 for managing wireless communications may operate according to Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN). In some embodiments, the circuitry included in interface device 4006 for managing wireless communications may operate according to Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Digital Enhanced Wireless Communication (DECT), Evolved Data Optimization (EV-DO) and its derivatives, and any other wireless protocol designated 3G, 4G, 5G, and higher. In some embodiments, interface device 906 may include one or more antennas (e.g., one or more antenna arrays) to receive and / or transmit wireless communications.

[0060] In some embodiments, interface device 906 may include circuitry for managing wired communications, such as electrical communication protocols, optical communication protocols, or any other suitable communication protocol. For example, interface device 906 may include circuitry supporting communication based on Ethernet technology. In some embodiments, interface device 906 may support both wireless and wired communications, and / or may support multiple wired communication protocols and / or multiple wireless communication protocols. For example, a first set of circuitry for interface device 906 may be dedicated to short-range wireless communication such as Wi-Fi or Bluetooth, while a second set of circuitry for interface device 906 may be dedicated to long-range wireless communication such as Global Positioning System (GPS), EDGE, GPRS, CDMA, WiMAX, LTE, EV-DO, etc. In some embodiments, a first set of circuitry for interface device 906 may be dedicated to wireless communication, while a second set of circuitry for interface device 906 may be dedicated to wired communication.

[0061] The computing device 900 may include a battery / power circuit 908. The battery / power circuit 908 may include one or more energy storage devices (e.g., batteries or capacitors) and / or circuitry for coupling components of the computing device 900 to a power source (e.g., AC line power) that is separate from the computing device 900.

[0062] The computing device 900 may include a display device 910 (e.g., multiple display devices). The display device 910 may include any visual indicator, such as a head-up display, computer monitor, projector, touch screen display, liquid crystal display (LCD), light-emitting diode display, or flat panel display.

[0063] The computing device 900 may include other input / output (I / O) devices 912. Other I / O devices 912 may include, for example, one or more audio output devices (e.g., speakers, headphones, earphones, alarm clocks, etc.), one or more audio input devices (e.g., microphones or microphone arrays), positioning devices (e.g., GPS devices that communicate with satellite-based systems to receive the location of the computing device 900, 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 mice, styluses, trackballs, or touchpads), barcode readers, quick-response (QR) code readers, or radio frequency identification (RFID) readers.

[0064] The computing device 900 can have any suitable form factor for its application and setup, such as a handheld or mobile computing device (e.g., a mobile phone, smartphone, mobile internet device, tablet, laptop, personal digital assistant (PDA), etc.), a desktop computing device, a server computing device, or other networked computing component.

[0065] 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. Figure 8 is a block diagram of an example scientific instrument support system 1000 according to various embodiments, in which some or all of the scientific instrument support methods disclosed herein may be executed. The scientific instrument support modules and methods disclosed herein (e.g., scientific instrument support module 300 of Figure 3 and method 600 of Figure 6) may be implemented by one or more of the scientific instrument 1010, user local computing device 1020, service local computing device 1030, or remote computing device 1040 of the scientific instrument support system 1000. The scientific instrument support system 1000 may be a system operating within the support system 100 of Figure 1, the scientific support system 200 of Figure 2, or alternatively, a stand-alone system implementing the support methods described herein. For example, scientific instrument 1010 may be example instrument 112, and the operation of ICP 105 and server 115 may be distributed among user local computing device 1020, service local computing device 1030 and remote computing device 1040.

[0066] Any of the scientific instrument 1010, the user local computing device 1020, the service local computing device 1030, or the remote computing device 1040 may include any embodiment of the computing device 900 discussed herein with reference to FIG. 7, and any of the scientific instrument 1010, the user local computing device 1020, the service local computing device 1030, or the remote computing device 1040 may take the form of any suitable embodiment of the computing device 900 discussed herein with reference to FIG. 7.

[0067] Scientific instrument 1010, user local computing device 1020, service local computing device 1030, or remote computing device 1040 may each include processing device 1002, storage device 1004, and interface device 1006. Processing device 1002 may take any suitable form, including any of the processing device forms of processing device 902 discussed herein with reference to FIG. 7, and the processing devices 1002 included in different devices of scientific instrument 1010, user local computing device 1020, service local computing device 1030, or remote computing device 1040 may take the same or different forms. Storage device 1004 may take any suitable form, including any of the storage device forms of storage device 1004 discussed herein with reference to FIG. 7, and the storage devices 1004 included in different devices of scientific instrument 1010, user local computing device 1020, service local computing device 1030, or remote computing device 1040 may take the same or different forms. Interface device 1006 may take any suitable form, including any of the interface device forms discussed herein with reference to FIG7, and the interface device 1006 included in different devices such as scientific instrument 1010, user local computing device 1020, service local computing device 1030 or remote computing device 1040 may take the same or different forms.

[0068] Scientific instrument 1010, user local computing device 1020, service local computing device 1030, and remote computing device 1040 can communicate with other elements of scientific instrument support system 1000 via communication path 1008. As shown, communication path 1008 can communicatively couple interface devices 1006 of different elements among the components of scientific instrument support system 1000, and can be a wired or wireless communication path (e.g., any communication technology discussed herein according to interface device 906 of computing device 900 with reference to FIG. 7). The particular scientific instrument support system 1000 depicted in FIG. 8 includes communication paths between each pair of devices among scientific instrument 1010, user local computing device 1020, service local computing device 1030, and remote computing device 1040; however, this “fully connected” implementation is merely illustrative, and various communication paths in communication path 1008 may not exist in various embodiments. For example, in some implementations, the serving local computing device 1030 may not have a direct communication path 1008 between its interface device 1006 and the interface device 1006 of the scientific instrument 1010, but may instead communicate with the scientific instrument 1010 via a communication path 1008 between the serving local computing device 1030 and the user local computing device 1020 and a communication path 1008 between the user local computing device 1020 and the scientific instrument 1010.

[0069] User-local computing device 1020 may be a user-local computing device of scientific instrument 1010 (e.g., any embodiment of the computing device 900 discussed herein). In some embodiments, user-local computing device 1020 may also be located locally to scientific instrument 1010, but this is not always the case; for example, user-local computing device 1020 located in a user's home or office may be remote from scientific instrument 1010 but communicate with it, allowing the user to use user-local computing device 1020 to control and / or access data from scientific instrument 1010. In some embodiments, user-local computing device 1020 may be a laptop, smartphone, or tablet device. In some embodiments, user-local computing device 1020 may be a portable computing device. In some embodiments, user-local computing device 1020 may be ICP 105.

[0070] The servicing local computing device 1030 can be a computing device that serves the physical locality of the scientific instrument 1010 (e.g., any implementation of the computing device 900 discussed herein). For example, the servicing local computing device 1030 can be a local device of the manufacturer of the scientific instrument 1010 or a third-party service company. In some implementations, the servicing local computing device 1030 can communicate with the scientific instrument 1010, the user local computing device 1020, and / or the remote computing device 1040 (e.g., via direct communication path 1008 or via multiple “indirect” communication paths 1008, as discussed above) to receive data regarding the operation of the scientific instrument 1010, the user local computing device 1020, and / or the remote computing device 1040 (e.g., self-test results of the scientific instrument 1010, calibration coefficients used by the scientific instrument 1010, measurement results of sensors associated with the scientific instrument 1010, etc.). In some implementations, the service local computing device 1030 may communicate with scientific instrument 1010, user local computing device 1020, and / or remote computing device 1040 (e.g., via direct communication path 1008 or via multiple “indirect” communication paths 1008, as discussed above) to transmit data to scientific instrument 1010, user local computing device 1020, and / or remote computing device 1040 (e.g., to update programming instructions (such as firmware) in scientific instrument 1010, initiate the execution of test or calibration sequences in scientific instrument 1010, update programming instructions (such as software) in user local computing device 1020 or remote computing device 1040, etc.). Users of scientific instrument 1010 may use scientific instrument 1010 or user local computing device 1020 to communicate with service local computing device 1030 to report problems with scientific instrument 1010 or user local computing device 1020, request technicians to come to the site to improve the operation of scientific instrument 1010, order consumables or replacement parts associated with scientific instrument 1010, or for other purposes.

[0071] Remote computing device 1040 may be a computing device located remotely from scientific instrument 1010 and / or user local computing device 1020 (e.g., any embodiment of the computing device 900 discussed herein). In some embodiments, remote computing device 1040 may be included in a data center or other large-scale server environment. In some embodiments, remote computing device 1040 may include network-attached storage (e.g., as part of storage device 1004). Remote computing device 1040 may store data generated by scientific instrument 1010, perform analysis on data generated by scientific instrument 1010 (e.g., according to programming instructions), facilitate communication between user local computing device 1020 and scientific instrument 1010, and / or facilitate communication between service local computing device 1030 and scientific instrument 1010. Remote computing device may be server 115. In some embodiments, the operation of server 115 is distributed between remote computing device 1040 and service local computing device 1030.

[0072] In some embodiments, one or more of the elements of the scientific instrument support system 1000 shown in FIG8 may be absent. Furthermore, in some embodiments, multiple elements of the various elements of the scientific instrument support system 1000 of FIG8 may be present. For example, the scientific instrument support system 1000 may include multiple user local computing devices 1020 (e.g., different user local computing devices 1020 associated with different users or located in different locations). In another example, the scientific instrument support system 1000 may include multiple scientific instruments 1010, all of which communicate with a serving local computing device 1030 and / or a remote computing device 1040; in such embodiments, the serving local computing device 1030 may monitor the multiple scientific instruments 1010, and the serving local computing device 1030 may cause updates, or other information may be simultaneously “broadcast” to the multiple scientific instruments 1010. Different scientific instruments in the scientific instrument support system 1000 (scientific instrument 1010) can be close to each other (e.g., in the same room) or far from each other (e.g., on different floors of a building, in different buildings, in different cities, etc.). In some embodiments, scientific instrument 1010 can be connected to an Internet of Things (IoT) stack that allows commanding and controlling scientific instrument 1010 via web-based applications, virtual or augmented reality applications, mobile applications, and / or desktop applications. Any of these applications can be accessed by a user operating a user-local computing device 1020 that communicates with scientific instrument 1010 via an intermediate remote computing device 1040. In some embodiments, scientific instrument 1010 can be sold by a manufacturer along with one or more associated user-local computing devices 1020 as part of a local scientific instrument computing unit 1012.

[0073] In some implementations, the different scientific instruments among the scientific instruments 1010 included in the scientific instrument support system 1000 can be of different types; for example, one scientific instrument 1010 can be a spectrometer, while another scientific instrument 1010 can be an interferometer. In some such implementations, a remote computing device 1040 and / or a user-local computing device 1020 can combine data from the different types of scientific instruments 1010 included in the scientific instrument support system 1000.

[0074] The following paragraphs provide various examples of the implementation schemes disclosed herein.

[0075] Example 1. A scientific instrument support device comprising: a first logic component, the first logic component being configured to: subscribe to events from a device driver; receive signature data events from the device driver based on the event subscription, the signature data events including a generated signature event; and, in response to receiving the generated signature event, generate signature data having a specified signature identifier; and transmit the signature data to a second logic component; a second logic component, the second logic component being configured to: receive the signature data from the first logic component; process the signature data; write the processed signature data into an instrument health database; and transmit the signature data to a cloud-based database; and a third logic component, the third logic component being configured to present a graphical user interface based on the processed signature data.

[0076] Example 2. The scientific instrument support device according to Example 1, wherein the first logic component, the second logic component, and the third logic component are implemented by a common computing device.

[0077] Example 3. A scientific instrument support device according to any one of Examples 1 and 2, wherein at least one of the first logic component, the second logic component, and the third logic component is implemented by a computing device located remotely from the scientific instrument.

[0078] Example 4. A scientific instrument support device according to any one of Examples 1 to 3, wherein the designated signature identifier indicates a specification file to be used by the device driver to generate the signature data.

[0079] Example 5. A scientific instrument support apparatus according to Example 4, wherein the specification document is applied to a data list to generate the signature data.

[0080] Example 6. A scientific instrument support device according to Example 4, wherein the specification file is a JSON file.

[0081] Example 7. A scientific instrument support device according to any one of Examples 1 to 6, wherein the signature data is formatted according to a signature pattern selected from a group consisting of device declaration mode, status mode, observation mode, usage mode, setting mode, activity mode, and event mode.

[0082] Example 8. A scientific instrument support device according to any one of Examples 1 to 7, wherein subscribing to events from a device driver includes a transport subscription network hook.

[0083] Example 9. A scientific instrument support device according to any one of Examples 1 to 8, wherein the first logical component implements a REST API.

[0084] Example 10. A method for supporting scientific instruments, comprising: receiving a subscription request including a device identifier and a signature identifier via a driver module; sending a data list to a data performance metrics module based on the device identifier and the signature identifier; generating signature data by the data performance metrics module based on the data list and a specification document identified by the signature identifier; transmitting the signature data to the driver module via the data performance metrics module; and transmitting the processed signature data to an instrument monitoring service.

[0085] Example 11. The method according to Example 10 further includes: receiving the signature data through the instrument monitoring service; transmitting the signature data to an instrument health service; processing the signature data by the instrument health service to generate processed signature data; and storing the processed signature data in a database.

[0086] Example 12. The method according to Example 11 further includes: transmitting the signature data to a cloud-based platform by an instrument health service.

[0087] Example 13. The method according to Example 12 further includes: presenting the data to a user via a graphical user interface.

[0088] Example 14. The method according to any one of Examples 10 to 13, further comprising: storing the signature data in a local database via the data performance metrics module.

[0089] Example 15. The method according to any one of Examples 10 to 14, wherein: the signature identifier further specifies a signature pattern; and the generation of the signature data is further based on the signature pattern.

[0090] Example 16. The method according to Example 15, wherein the signature mode is selected from the group consisting of device declaration mode, state mode, observation mode, usage mode, setting mode, activity mode and event mode.

[0091] Example 17. The method according to any one of Examples 10 to 16, wherein the subscription request includes a subscription network hook.

[0092] Example 18. The method according to any one of Examples 10 to 17, wherein the instrument monitoring service implements a REST API.

[0093] Example 19. The method according to any one of Examples 10 to 18, wherein sending the data list to the data performance metrics module is performed as part of a push action initiated by the driver module or in response to a pull action initiated by the data performance metrics module.

[0094] Example 20. One or more non-transitory computer-readable media having instructions thereon that, when executed by one or more processing devices of a scientific instrument support apparatus, cause the scientific instrument support apparatus to perform the method according to any one of Examples 10 to 19.

Claims

1. A scientific instrument support device, comprising: A first logic component, the first logic component being used for: Subscribe to events from the device driver; Based on event subscription, signature data events are received from the device driver, the signature data events including generated signature events; and In response to receiving a signature generation event, generate signature data with the specified signature identifier; and The signature data is transmitted to the second logic component; The second logic component is used for: Receive the signature data from the first logic component; Process the signature data; The processed signature data is written into the instrument health database; and The signature data is transmitted to a cloud-based database; and A third logic component is used to present a graphical user interface based on the processed signature data.

2. The scientific instrument support device according to claim 1, wherein the first logic component, the second logic component, and the third logic component are implemented by a common computing device.

3. The scientific instrument support device according to claim 1, wherein at least one of the first logic component, the second logic component, and the third logic component is implemented by a computing device located remotely from the scientific instrument.

4. The scientific instrument support device of claim 1, wherein the designated signature identifier indicates a specification file to be used by the device driver to generate the signature data.

5. The scientific instrument support device according to claim 4, wherein the specification document is applied to the data list to generate the signature data.

6. The scientific instrument support device according to claim 4, wherein the specification file is a JSON file.

7. The scientific instrument support device according to claim 1, wherein the signature data is formatted according to a signature pattern selected from the group consisting of device declaration mode, status mode, observation mode, usage mode, setting mode, activity mode and event mode.

8. The scientific instrument support device of claim 1, wherein subscribing to events from the device driver includes a transport subscription network hook.

9. The scientific instrument support device according to claim 1, wherein the first logic component implements REST API.

10. A method for supporting scientific instruments, comprising: The driver module receives subscription requests, including device identifiers and signature identifiers. A data list is sent to the data performance metrics module based on the device identifier and the signature identifier; The data performance index module generates signature data based on the data list and the specification file identified by the signature identifier; The signature data is transmitted to the driver module via the data performance index module. as well as The processed signature data is transmitted to the instrument monitoring service.

11. The method of claim 10, further comprising: The signature data is received through the instrument monitoring service. The signature data is transmitted to the instrument health service; The signature data is processed by the instrument health service to generate processed signature data; as well as The processed signature data is stored in a database.

12. The method of claim 11, further comprising: The signature data is transmitted to a cloud-based platform by the instrument health service.

13. The method of claim 12, further comprising: The data is presented to the user via a graphical user interface.

14. The method of claim 10, further comprising: The signature data is stored in a local database through the data performance metrics module.

15. The method of claim 10, wherein: The signature identifier further specifies the signature mode; and The signature data is generated further based on the signature pattern.

16. The method of claim 15, wherein the signature mode is selected from the group consisting of device declaration mode, state mode, observation mode, usage mode, setting mode, activity mode, and event mode.

17. The method of claim 10, wherein the subscription request includes a subscription network hook.

18. The method of claim 10, wherein the instrument monitoring service implements a REST API.

19. The method of claim 10, wherein sending the data list to the data performance metrics module is performed as part of a push action initiated by the driver module or in response to a pull action initiated by the data performance metrics module.

20. One or more non-transitory computer-readable media having instructions thereon that, when executed by one or more processing devices of a scientific instrument support apparatus, cause the scientific instrument support apparatus to perform the method according to claim 10.

Images