Accessing large data structures generated by scientific instruments

Abstract

Scientific instrument support systems and related methods, computing devices, and computer readable media are disclosed herein. In one example, an automated method performed via a computing device to provide scientific instrument support includes transmitting a portion of a data structure collected with a detector of a scientific instrument to a client device, the data structure stored in a data storage connected to the computing device via a network; identifying a portion of the data structure based on a data access pattern in the sequence of data requests; downloading the portion from the data storage to a storage device locally connected to the computing device; when the requested portion of the data structure belongs to the portion downloaded to the storage device via the computing device, the data transmission path of the client device is terminated to the storage device from the data storage.

Description

[0001] Cross-reference to related applications This application claims priority to U.S. Nonprovisional Application No. 18 / 307,463, filed April 26, 2023, entitled “Access to Large Data Structures Generated by Scientific Instruments,” the entire disclosure of which is incorporated herein by reference. Background Technology

[0002] This application generally relates to data delivery systems, and more specifically, but not exclusively, to data access and buffering.

[0003] Scientific instruments, such as imaging instruments and spectrometers, typically consist of a complex arrangement of components, sensors, detectors, input and output ports, power sources, and consumable elements. Some of these scientific instruments generate relatively large amounts of data during operation, which can impact memory requirements and efficient data access. Attached Figure Description

[0004] The 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. The embodiments are shown in the accompanying drawings by way of example rather than limitation. Figure 1 A block diagram illustrating a data structure that can be generated via scientific instruments according to some implementation schemes.

[0005] Figure 2 A block diagram of a scientific instrument support system according to some implementation schemes is shown.

[0006] Figure 3 To illustrate the use according to certain implementation schemes Figure 2 A flowchart illustrating the method by which a scientific instrument support system delivers data to client devices.

[0007] Figure 4 illustrates the involvement of some implementation schemes. Figure 2 A block diagram illustrating the communication and data flow of an exemplary component of a data delivery service in a scientific instrument support system.

[0008] Figure 5 To illustrate according to some implementation schemes Figure 2 A block diagram illustrating the interaction between data delivery services, data access applications, and networked data storage in a scientific instrument support system.

[0009] Figure 6 A block diagram illustrating a scientific instrument support module for performing scientific instrument support operations according to various implementation schemes.

[0010] Figure 7To show a block diagram of an example computing device that can perform some of the scientific instrument support methods and / or functions disclosed herein, according to various embodiments.

[0011] Figure 8 To show a block diagram of an example scientific instrument support system in which some or all of the scientific instrument support methods and / or functions disclosed herein can be performed, according to various embodiments. DETAILED DESCRIPTION

[0012] Scientific instrument support systems and related methods, computing and storage devices, and computer readable media are disclosed herein. For example, in some embodiments, an apparatus for support of a scientific instrument includes a first logic component, a second logic component, and a third logic component. The first logic component is configured to transmit portions of a data structure acquired with one or more detectors of a scientific instrument to a client device, the data structure stored in a data storage device connected to the first logic component via a network, and the portions identified to the first logic component according to a sequence of data requests received from the client device. The second logic component is configured to identify the portions of the data structure based on at least one of a data access pattern in the sequence of data requests and a buffer size of a storage device locally connected to the first logic component. The third logic component is configured to download the portions from the data storage device to the storage device, wherein the first logic component is configured to switch a data transmission path of the client device from terminating to the data storage device to terminating to the storage device when the requested portion of the data structure belongs to the portions downloaded to the storage device via the third logic component. In one example, a client application requests to view mass spectrometer scan X of a raw data file stored in the cloud. The request will be sent to a corresponding data delivery service running in the cloud. The data delivery service determines that the data is not available locally and picks the best performing reader from a set of available data readers for accessing the data. At the same time, the data delivery service downloads the raw data to a local storage device for use by the service. The data delivery service sends the requested data along with other data determined using a predictive reading algorithm (e.g., grouping related data together), which can reduce the number of subsequent calls or eliminate the need for such calls altogether.

[0013] The scientific instrument support implementations disclosed herein can achieve performance improvements over conventional approaches and, for example, can enable performance improvements for time-of-flight (TOF) mass spectrometers, quadrupole rod mass spectrometers, ion trap mass spectrometers, and instruments that include multiple spectrometers and / or detectors (e.g., including ultraviolet (UV) detectors, diode array detectors (DAD, such as photodiode array detectors (PDA)), mass spectrometry (MS) detectors, and liquid and / or gas chromatography detectors). For illustrative purposes and without any implied limitation, some example implementations are described below with reference to mass spectrometers. From the provided description, those of ordinary skill in the relevant art will be able to create and use other support implementations for scientific instruments that employ other types of spectrometers, detectors, devices, and various combinations thereof, without any need for undue experimentation.

[0014] TOF mass spectrometry (TOFMS) is a mass spectrometry method that determines the mass-to-charge ratio of ions by measuring the time of flight. Ions are accelerated by a known intensity electric field. This acceleration causes the ions to have the same kinetic energy as any other ion of the same charge. The speed of the ions depends on the mass-to-charge ratio, so a heavier ion of the same charge obtains a lower speed than a lighter ion. The time required for the ions to subsequently reach a downstream detector is measured. This time depends on the speed of the ions and thus can provide a measure of the mass-to-charge ratio of the ions. From the measured TOF mass spectrum and other known experimental parameters, the composition of the analyte can be determined.

[0015] A TOF mass spectrometer can include a mass analyzer and an ion detector. An ion source (pulsed or continuous) is used to generate ions from an analyte. The mass analyzer can be a linear flight tube or a reflectron. In various examples, the ion detector is a microchannel plate (MCP) detector or a secondary electron multiplier (SEM). An electrical signal from the ion detector is digitized using a time-to-digital converter (TDC) or an analog-to-digital converter (ADC). A TDC is a counting detector, and ion counts performed thereby can be accompanied by summation of a large number (e.g., hundreds) of individual mass spectra, sometimes referred to as histogram processing. When a TDC is used, the corresponding mass analyzer can operate at a repetition frequency of 5 kHz to 20 kHz to generate enough mass spectra to be summed. An ADC can operate at a speed of about 10 gigasamples / second to digitize a pulsed ion stream from the ion detector over discrete time intervals. In various examples, the ADC has a dynamic range of 8 bits to 12 bits. Use of an ADC (versus a TDC) can be more advantageous for certain specific types of TOF mass spectrometers, such as for matrix-assisted laser desorption / ionization (MALDI)-TOF instruments that have relatively high peak currents.

[0016] The raw data detected by a mass spectrometer is typically distributed in the form of signals across a range of m / z (mass-to-charge ratio) values for which ions are detected. Centroid data contains raw data processed by a suitable algorithm, retaining only local maxima within the mass range of each detected ion. Such centroid data is often referred to as a“centroid scan”.

[0017] In some examples, a raw data file generated by a TOF mass spectrometer is approximately 1 GB to 100 GB in size and contains data from multiple scans and / or multiple channels in an unseparated binary form in a file or storage format that is specifically optimized for the recording, transmission, and packaging of experimental data corresponding to a single analysis of an analyte sample. In representative data storage systems, such binary data files or storage formats enable a corresponding data reader associated with the instrument (e.g., provided by the instrument manufacturer) to extract selected scan and / or channel data for further processing, e.g., in response to a request from a client device.

[0018] In example implementations, a raw data reader (sometimes also referred to as a“data layer”) does not directly access the“last byte” of data from any particular location. Instead, the raw data reader“knows” (extracts) a“data view” and treats such data views from multiple detectors as a“collection of views”. This collection of views exposes only limited information to the raw data reader, e.g.,“performance hints”. Data view extraction allows the raw data reader to access data in any medium that can be addressed in the form of“get x bytes from location y of the nth data view”. However, the corresponding data reading mechanism typically relies on“system calls”, which can add significant overhead for small reads. In some examples, reading 1 byte and reading 10 KB can take approximately the same time due to system call overhead. The corresponding data access latency can disadvantageously cause significant hindrance to users and operators of the corresponding scientific instrument and / or system and lead to inefficient use of computational resources, including, e.g., memory, processing cycles, bandwidth, or a combination thereof.

[0019] The above-referenced problems and possibly other related problems in the art can be beneficially addressed using various examples, aspects, features, and implementations of the systems and methods for accessing scientific instrument data disclosed herein. In representative examples, a record buffer management system is designed and configured to efficiently manage large collections of records. In some examples, the record buffer management system operates in a cloud or enterprise environment to provide fast data access to client applications. In various examples, respective algorithms handle records of fixed or variable size and can work in coordination with a variety of different readers (e.g., independent of the type of reader). At least some implementations beneficially reduce data access latency associated with some previous data access solutions. For example, some implementations disclosed herein can enable improved access (e.g., faster selective access) to scientific instrument data (e.g., mass spectrometer scans) relative to conventional approaches.

[0020] Thus, implementations disclosed herein provide improvements to scientific instrument technology (e.g., improvements in computer technology aspects that support such scientific instruments, among other improvements). One example implementation provides an automated method performed via a computing device to provide scientific instrument support. The method includes transmitting a portion of a data structure collected with one or more detectors of a scientific instrument to a client device, the data structure stored in a data store connected to the computing device over a network, and the portion identified to the computing device according to a sequence of data requests received from the client device. The method also includes identifying the portion of the data structure based on at least one of a data access pattern in the sequence of data requests and a buffer size of a storage device locally connected to the computing device, and downloading the portion of the data from the data store to the storage device. The method further includes switching a data transmission path of the client device from terminating to the data store to terminating to the storage device when the requested portion of the data structure is among the portions downloaded to the storage device via the computing device. Advantageous examples of such automated methods include, but are not limited to, (i) reducing or eliminating long startup delays that can occur when downloading or transmitting data (e.g., in a cloud environment); (ii) reducing data access latency (e.g., latency before initial data is displayed); (iii) improving data access performance, e.g., shortening the time required to receive data corresponding to complex requests (e.g., encompassing large data sets).

[0021] Various of the embodiments disclosed herein can improve upon conventional approaches by recording buffer management systems and performing improved data operations in conjunction with predictive data access and buffering, thereby realizing technical advantages. These technical advantages can not be realized by conventional and traditional approaches, and all users of systems incorporating such embodiments can benefit from these advantages (e.g., by accelerating technical tasks such as processing and analysis of experimental data). Accordingly, the technical features of the embodiments disclosed herein are decidedly unconventional in the field of instrument-related data storage, as are various combinations of the features disclosed herein. As discussed further herein, various aspects of the embodiments disclosed in this document can improve computer functionality itself, e.g., by operating instrument-related data storage devices in an optimized manner, thereby increasing levels of productivity. The computing features disclosed herein relate not only to the collection and comparison of information, but also to the application of new analytical and technical tools to alter the operation of instrument-related data storage devices. Accordingly, the present disclosure introduces at least certain functionality that neither conventional computing devices nor humans can perform.

[0022] Accordingly, embodiments of the present disclosure can be used for any of a number of technical purposes, such as controlling a particular technical system or process; determining how to control or configure a machine based on measurements; or increasing the throughput of a data pipeline. Some examples disclosed herein provide solutions to technical problems, including but not limited to improvements to liquid chromatography-mass spectrometry (LC-MS) instruments, gas chromatography-mass spectrometry (GC-MS) instruments, and time-of-flight mass spectrometers (TOFMS), for example, improvements to computer technology supporting such instruments, and other improvements.

[0023] In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which are shown by way of illustration embodiments in which the subject matter disclosed herein can be practiced. The embodiments are not intended to be limited to the embodiments set forth in the figures, but can be practiced with other embodiments. There can be many variations to the embodiments described herein, and these are contemplated as falling within the scope of the present disclosure. Therefore, the following detailed description is not to be considered in a limiting sense as the scope of the present disclosure is limited only by the claims.

[0024] Various operations can be described as multiple discrete actions or operations in turn, in a manner that can most closely represent the manner in which the subject matter disclosed herein can be practiced. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations can not be performed in the order of presentation. Operations described can be performed in a different order than the described embodiments. Various additional operations can be performed and / or described operations can be omitted in additional embodiments.

[0025] For purposes of this disclosure, the phrases "A and / or B" and "A or B" mean (A), (B), or (A and B). For 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 can be shown in singular form (e.g., "processing device"), any appropriate number of instances of such elements can be represented by a single instance of that element, and vice versa. For example, a set of operations described as being performed by a processing device can be implemented by different processing devices performing different ones of the operations.

[0026] This description uses the phrases "implementation," "one implementation," "various implementations," and "some implementations," which each can refer to one or more of the same or different things. Also, the terms "comprising," "containing," "having," and the like as used with respect to an implementation of the present disclosure means "including." The phrase "between X and Y" indicates a range that includes X and Y when used to describe a range of values. As used herein, "device" can refer to any individual device, collection of devices, portion of a device, or collection of portions of a device. The drawings are not necessarily to scale.

[0027] Figure 1 A block diagram of a data structure (record collection) 1000 that can be generated via a scientific instrument is shown in accordance with one implementation. In various examples, the data structure 1000 has a more complex structure than a single file on a disk. More specifically, in some examples, the data structure 1000 is represented as a collection of stream files, or as a set of objects for a corresponding object storage mechanism. In some examples, the data structure 1000 is represented as one folder on a Linux server, with each data stream saved in a separate file collection, e.g., including index record files, data record files, etc. At least some implementations disclosed herein are designed to be applicable to different storage mechanisms and the corresponding different organization of the data structure 1000 therein; that is, such implementations do not depend on the organization of the data streams or data blocks of the data structure 1000 in a particular data storage system, as long as the data reader "knows" the implemented data organization.

[0028] In the illustrated example, the data structure 1000 includes a metadata block 1100, a data package block 1200 for a respective MS device, and a device data block 1300. The metadata block 1100 includes a header field 1110, a sequence field 1120, an auto-sample field 1130, an original file information field 1140, and a method field 1150. The data package block 1200 includes one or more spectral data packages 1210. The device data block 1300 includes one or more data fields corresponding to different particular devices of the scientific instrument used in the respective experiment. In the illustrated example, the device data block 1300 has five such device-specific data fields, labeled 1310-1350. In other examples, the device data block 1300 can have a different number (not five) of device-specific data fields, depending on the configuration of the respective scientific instrument.

[0029] In some examples, the header field 1110 includes a checksum, specifies a format version of the data structure 1000, and also includes a signature and an associated timestamp. The sequence field 1120 includes sample name, type, volume, and injection ID. The auto-sample field 1130 includes configuration of sample storage location in the autosampler of the scientific instrument and tray information. The original file information field 1140 includes device type (e.g., MS, UV, etc.) and data location for each device. The method field 1150 includes a description of the experimental method used, e.g., in the form of header information, descriptive information, and method ID.

[0030] The spectral data package 1210 contains a number of fields, including: a data package header 1211, a mass range array 1212, a profile spectrum blob 1213, a centroid blob 1214, and a default function array 1215. In this context, the term "blob" (or "binary large object") refers to a collection of binary data stored as a single entity. In some examples, blobs are used in NoSQL (not only structured query language) databases, e.g., in key-value storage databases like Redis. Certain programming languages, like JavaScript, allow blobs to be manipulated at runtime.

[0031] Each of the device-specific data fields 1310-1350 has a two-part structure as shown in bubble diagram 1301. The two parts of the structure are a common part block 1360 and a device-specific data block 1370. The common part block 1360 has the same overall structure for all devices. The device-specific data block 1370 includes a number of fields, the structure and number of which depend on the device type. For illustration purposes, an example structure of the device-specific data block 1370 corresponding to an MS device is shown in expanded diagram 1302. The MS device data block 1370 contains the following fields: a scan event field 1371, a trailer header field 1372, a tuning data header field 1373, a tuning data field 1374, a scan index field 1375, and a trailer additional data field 1377.

[0032] The data structure 1000 is generally created by a respective scientific instrument. In some examples, the data structure 1000 has an indexed binary file format. Each of the data blocks 1100, 1200, 1300 has a respective particular byte layout of different constituent data substructures or records. Data is read from the data structure 1000 using a respective configured data reader. In some examples, data queries take the form of requests for scans and chromatograms, rather than a SQL-like. Metadata of the metadata block 1100 is collected prior to sample injection, e.g., based on a scan's bar code. Detector data is collected by the respective scientific instrument from all connected (various technology) detectors. The collected data has a variable format (based on detector technology) and variable length, with an arbitrary number of "data packets" per set of timed readings. In this document, a set of readings at a given time is referred to as a "scan." Figure 1 The illustrated diagram shows a basic indexing scheme of the data structure 1000. Various supplements and / or modifications to the illustrated basic indexing scheme can be implemented to reflect functional and / or hardware differences between different particular scientific instruments.

[0033] Figure 2 A block diagram of a scientific instrument support system 2000 is shown to illustrate, in accordance with some embodiments. The system 2000 is network-connected with a scientific instrument 2100 over a network 2300, and includes a data storage platform 2400. In some examples, the scientific instrument 2100 has a computing device 2200, e.g., a personal computer (IPC) of the instrument, through which the scientific instrument 2100 is connected to the network 2300. In some other examples, the computing device 2200 is integrated into the scientific instrument 2100 and does not exist as a separate component. In the latter examples, the scientific instrument 2100 can be said to be directly connected to the network 2300.

[0034] In some embodiments, the data storage platform 2400 is a cloud platform. However, various embodiments are not limited thereto. Various additional embodiments of the data storage platform 2400 include network-based object storage (e.g., object storage provided through Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, or similar services), enterprise data storage platforms, and microservices platforms. Some microservices platforms can take the form of computing devices, server racks, or on-premises data storage.

[0035] In the illustrated example, the data storage platform 2400 includes a data storage subsystem 2410, a data archival service 2430, and a data delivery service 2450. In some examples, the data storage subsystem 2410 includes a network-attached storage (NAS) that enables multiple users and heterogeneous client devices to retrieve data from the constituent storage capacity. Users in a local area network (LAN) can access the NAS through a standard Ethernet connection. NAS devices typically have no keyboard or display, but are configured and managed through browser-based utilities. In an example configuration, the NAS resides on the LAN as a standalone network node, defined by its own unique IP address. In some other examples, the data storage subsystem 2410 includes a storage area network (SAN). SANs are commonly used to provide multiple computers and servers with access to a shared pool of storage. Such storage appears as direct-attached storage to the computers on the network. In an example configuration, a SAN eliminates the storage responsibility of individual servers and collects data in a central location that can be accessed, managed, and protected. By connecting storage to servers over a network separate from the traditional LAN, storage traffic can be used, for example, to optimize storage traffic performance because the corresponding storage traffic does not compete with the LAN bandwidth for servers and workloads. In some examples, NAS is preferred for handling substantially unstructured data, while SAN is preferred for block storage within databases or to serve enterprise applications.

[0036] In some examples, the data archival service 2430 runs on a server or other suitable computing device 2432. The corresponding program code causes the computing device 2432 to appropriately organize and transfer various instances of the data structure 1000 collected via the scientific instrument 2100 for storage in the data storage subsystem 2410. In some examples, the data delivery service 2450 runs on a server or other suitable computing device 2452. The computing device 2452 has a local storage device 2454 connected thereto. In operation, in response to a data request received from the client device 2900, the data delivery service 2450 operates to provide data from one or more data structures 1000 stored in the data storage subsystem 2410 to the client device 2900. In some examples, the data request is generated by the client device 2900 using the data access application 2910. Reference is made to the following figures.Figures 3 to 8 Various example embodiments of the data delivery service 2450 are described in more detail.

[0037] In this document, the term“local storage” refers to a storage device directly connected to the computing device 2452. In some examples, the local storage device 2454 does not rely on a network to send data to or receive data from the computing device 2452. In various examples, the physical hardware of the local storage device 2454 includes a flash drive, a hard disk drive (HDD), a solid state drive (SDD), and / or a compact disc (CD) drive. Once data is stored in the local storage device 2454, the data therein is only accessible by the computing device 2452. For example, data stored in the local storage device 2454 is generally not accessible when the computing device 2452 is off. In some examples, the physical distance between the computing device 2452 and the local storage device 2454 is less than about 10 meters. In some examples, the local storage device 2454 is integrated in the computing device 2452. In some examples, the local storage device 2454 has one or more of the following characteristics. The local storage device 2454 does not require, have, use, or rely on an Ethernet connection. The local storage device 2454 is configured to be used as virtual memory by an operating system (OS), e.g., a pagefile system file used by the Windows operating system. Because local storage is part of the paging system, OS-level page management can make memory mapping on such storage more efficient. For remote or network-connected storage devices, e.g., the data storage subsystem 2410, software can configure or select to use an alternative read technique (e.g., a random access file reader, as shown below).

[0038] In operation, the scientific instrument 2100 generates one or more data structures 1000 by acquiring experimental data corresponding to one or more analytes via its one or more detectors. In some specific examples, the scientific instrument 2100 is a TOF MS or LC-MS instrument. As described above, to conduct data acquisition, ions generated by the ion source of the instrument are directed through the mass analyzer and detected by the one or more detectors of the instrument. Accordingly, the scientific instrument 2100 can acquire data under one or more settings of the mass analyzer and the detector. The scientific instrument 2100 can then incorporate one or more parameters associated with the settings into the corresponding data structure 1000.

[0039] For example, the scientific instrument 2100 can apply automated processing to the collected raw detector data. Such automated processing typically includes generating metadata blocks 1100 of the corresponding data structure 1000 based on one or more parameters associated with the settings of the scientific instrument 2100 and its various detectors. In some examples, the automated processing includes some or all of the following operations: (a) combining different data portions of a raw data stream into records; (b) dividing different data streams of a raw data file into one or more record streams; (c) further grouping data streams. The data archival service 2430 then processes the transfer of records assembled into the corresponding data structure 1000 from the scientific instrument 2100 to the data storage subsystem 2410 of the data storage platform 2400. In various examples, such record transfer occurs via the computing device 2200 or directly from the scientific instrument 2100 itself.

[0040] Figure 3 is a flowchart illustrating a method 3000 of delivering data to a client device 2900 with the system 2000, in accordance with some embodiments. The method 3000 is described below with continued reference to Figure 2 When the data delivery service 2450 receives a data request from the client device 2900, the method 3000 is initiated in start block 3002. The received data request typically identifies a requested portion of a corresponding data structure 1000.

[0041] The method 3000 includes the data delivery service 2450 determining whether the requested data is available locally (i.e., in the local storage device 2454) in decision block 3010. When the requested data is not available locally (“No” at decision block 3010), the method 3000 performs the operations of block 3020. When the requested data is available locally (“Yes” at decision block 3010), the method 3000 performs the operations of block 3060.

[0042] In block 3020, the data delivery service 2450 initiates a background download in which specified data blocks are downloaded from the data storage subsystem 2410 to the local storage device 2454. In various examples, the specified data blocks typically include the data requested in start block 3002. In some examples, the specified data blocks include more data than requested in start block 3002, where the additional data is determined using a predictive read algorithm. Various examples of predictive read algorithms are described below, e.g., with reference to Figure 5 .

[0043] In decision block 3030 of the method 3000, the data delivery service 2450 monitors the progress of the background download started in block 3020. When it is determined that the background download is still in progress (not complete; "No" at decision block 3030), the method 3000 performs the operations of block 3040. When the download is complete ("Yes" at decision block 3030), the method 3000 performs the operations of block 3060.

[0044] In block 3040, the data delivery service 2450 uses an appropriately selected data reader to read the portion of data corresponding to the request received in starting block 3002 from the data storage subsystem 2410. The data delivery service 2450 then transmits the obtained portion of data to the client device 2900.

[0045] In decision block 3050 of the method 3000, the data delivery service 2450 monitors the progress of the reading and transmitting operations in satisfying the data request, i.e., until all of the requested data is transmitted to the client device 2900. When the reading and transmitting operations have not been completed ("No" at decision block 3050), the method 3000 is directed back to perform the operations of block 3030. When the reading and transmitting operations are complete ("Yes" at decision block 3050), the method 3000 is terminated.

[0046] In block 3060, the data delivery service 2450 uses an appropriately selected data reader to read the portion of data corresponding to the request received in starting block 3002 from the local storage device 2454. The data delivery service 2450 then transmits the obtained portion of data to the client device 2900. Note that the data reader selected for reading from the local storage device 2454 in block 3060 is typically different from the data reader selected for reading from the data storage subsystem 2410 in block 3030. Depending on the processing route that the method 3000 takes to reach the operations of block 3060, the reading and transmitting operations of block 3060 can contain all of the requested data (e.g., for the route from decision block 3010) or less than all of the requested data (e.g., for the route from decision block 3030). When the reading and transmitting operations of block 3060 are complete, the method 3000 is terminated.

[0047] In some examples, the data delivery service 2450 has a dynamic data reader selector 2456 (see FIG. 3B) that selects the data reader to use for reading from the data storage subsystem 2410 or the local storage device 2454 based on the data request received in starting block 3002. Figure 2), the data delivery service 2450 uses the selector to select an appropriate data reader from a plurality of available data readers (e.g., for blocks 3040 and 3060). In operation, the dynamic data reader selector 2456 can determine and select a reader that is close to optimal performance for a particular data access path. For example, as already noted above, different respective data readers are typically selected for reading from the data storage subsystem 2410 and for reading from the local storage device 2454. In some examples, the operation of the dynamic data reader selector 2456 switches from one data reader to a different data reader when the operation of the method 3000 is redirected from block 3040 to block 3060 via decision blocks 3050 and 3030. The data access application 2910 running on the client device 2900 is typically unaware of such data reader switching, as the data delivery service 2450 and its dynamic data reader selector 2456 are better able to achieve respective performance improvements for the benefit of the data request user.

[0048] In some examples, the dynamic data reader selector 2456 is implemented using a plug-in framework, based on which different data readers can be provided as different application plug-ins to the data delivery service 2450. The plug-in framework enables the data delivery service 2450 to be customized and adapted to handle a variety of different storage technologies. The plug-in framework also provides a standard interface for loading custom data readers into an existing data reading system. Representative examples of data reader plug-ins that can be used with the dynamic data reader selector 2456 include, but are not limited to, (i) a storage array reader plug-in; (ii) a memory-mapped file reader plug-in; (iii) an S3 reader plug-in; (iv) a random access file reader plug-in.

[0049] For example, Simple Storage Service (S3) is an object storage service with good scalability, security, and performance. An object storage service stores data as objects in buckets. An object is a file associated with any metadata that describes the file. A bucket is a container that stores objects. To store data in S3, first create a bucket and specify the name and storage class of the bucket. The program to save the object depends on the browser and operating system. For example, Amazon's S3 is a key-value store, which is one of the categories of NoSQL databases, used to accumulate large amounts of, mutable, unstructured, or semi-structured data. Uploaded objects are referenced in it by a unique key, which can be a string.

[0050] For another example, a memory-mapped file contains the contents of a file in virtual memory. The mapping between the file and the memory space enables applications (e.g., including multiple processes) to modify the file by directly reading from and writing to memory. There are two types of memory-mapped files: persistent and non-persistent. A persistent file is a memory-mapped file associated with a source file on disk. When the last process completes a file operation, the data is saved to the source file on disk. These memory-mapped files are suitable for processing large source files. A non-persistent file is a memory-mapped file that is not associated with a file on disk. When the last process completes an operation on the file, the data is lost and the memory space can be reclaimed through garbage collection. These files are suitable for creating shared memory for inter-process communication. To work with a memory-mapped file, a view of the entire memory-mapped file or a relevant portion thereof needs to be created. Multiple views can be created, for example, when the file is larger than the size of the logical memory space available to the application for memory mapping. There are two types of views: a stream access view and a random access view. A stream access view is used for sequential access and is recommended for non-persistent files and inter-process communication. A random access view is the preferred method for working with persistent files. Memory-mapped files are accessed through the memory manager of the operating system, and the file is automatically divided into pages and accessed as needed.

[0051] FIG. 4 is a block diagram illustrating communications and data flows involving example components of the data delivery service 2450, according to some embodiments. In at least some examples, the communications and data flows illustrated in FIG. 4 can conform to the method 3000. For example, FIG. 4 illustrates certain operations of the data delivery service 2450 in response to data requests 4010, 4040, and 4060 received from the client device 2900 at respective different times.

[0052] In the illustrated example, the data delivery service 2450 includes the following functional modules: raw data operator 4100, download manager 4200, and storage manager 4300. The raw data operator 4100 communicates with the download manager 4200 to initiate operations, select and operate appropriate data readers, send requested data to the client device 2900, and is responsible for at least some of the operations of block 3040, block 3060 of the method 3000. The download manager 4200 and the storage manager 4300 communicate with the raw data operator 4100 and are responsible for at least some of the operations of block 3020, block 3030 of the method 3000.

[0053] In response to the data request 4010 received from the client device 2900, the data delivery service 2450 performs initialization 4110, 4210, and 4310 of respective instances of the raw data operator 4100, the download manager 4200, and the storage manager 4300. After these initializations 4110, 4210, and 4310 are completed, the raw data operator 4100 sends a message 4112 requesting the availability status of the data corresponding to the data request 4010. In response to the message 4112, the download manager 4200 sends a corresponding message 4212 instructing the storage manager 4300 to determine the availability status of the requested data in the local storage device 2454. Upon making the corresponding determination 4312, the storage manager 4300 sends a status report message 4214 to the download manager 4200, which further sends a corresponding report message 4114 to the raw data operator 4100. According to a specific example, the availability status reported by the messages 4214, 4114 is either "available" or "unavailable".

[0054] When the reported availability status is "available", the raw data operator 4100 makes a selection 4120 to select a suitable data reader for reading the requested data from the local storage device 2454. In some examples, the data reader selected via the selection 4120 is an optimal data reader, e.g., a data reader that provides near-optimal performance. The raw data operator 4100 then performs a memory read operation 4122 using the selected data reader to read the requested data from the local storage device 2454. The raw data operator 4100 directs the obtained data to the client device 2900 via the data stream 4020.

[0055] When the reported availability status is "unavailable", the raw data operator 4100 makes a selection 4124 to select a suitable data reader for reading the requested data from the data storage subsystem 2410. The raw data operator 4100 then performs a memory read operation 4126 using the selected data reader to read the requested data from the data storage subsystem 2410. The raw data operator 4100 directs the obtained data to the client device 2900 via the data stream 4030.

[0056] The "unavailable" status reported via the message 4214 also causes the download manager 4200 to send a message 4216 requesting the storage manager 4300 to initiate a background download (see also Figure 3Response to message 4216, storage manager 4300 makes selection 4318 to select a suitable downloader for use in downloading the data block from data storage subsystem 2410. Storage manager 4300 then performs data download operation 4320 using the selected downloader to read the data block from data storage subsystem 2410. As noted in the description of block 3020 above, the data block includes at least the data requested in data request 4010. In some examples, the data block includes more data than requested in data request 4010, with the additional data determined using a predictive read algorithm. Once download operation 4320 is initiated, storage manager 4300 sends message 4218 reporting to download manager 4200 that the download event is in progress, which is then forwarded to original data operator 4100 as message 4118. When data download operation 4320 is complete, storage manager 4300 sends message 4254 reporting to download manager 4200 that the download event is complete, which is then forwarded to original data operator 4100 as message 4154.

[0057] In the illustrated example, data requests 4040 and 4060 both request data encompassed by download operation 4320. The respective times of data requests 4040 and 4060 are before and after the time of reporting message 4254 / 4154. Thus, for data request 4040, the availability status of the requested data is “unavailable.” Thus, original data operator 4100 proceeds to read the requested data from data storage subsystem 2410, and then operates to direct the obtained data to client device 2900 via data stream 4050. In contrast, for data request 4060, the availability status of the requested data is “available.” Thus, original data operator 4100 proceeds to read the requested data from local storage device 2454, and then operates to direct the obtained data to client device 2900 via data stream 4070. Original data operator 4100 implements the respective switching 4158 of data reader and data access path upon receiving reporting message 4154, and then uses the local data reader and path to satisfy data request 4060.

[0058] The general concept of predictive reads described above can be illustrated using the following example: assume that a data retrieval algorithm is performing one million MS scans, one at a time, each containing approximately 10 KB. Approximately 100 MS scans can be read in one system call. When the client device 2900 requests a number of these one hundred MS scans, the predictive read mechanism is effective. Since the raw data processing algorithm running on the client device 2900 is configured to scan the set sequentially forward, from the perspective of the MS data processing algorithm, a predictive pre-read mechanism can be employed to speed up data delivery. For example, while processing MS scans 101-200, MS scans 201-300 can be read predictively. In some examples, the batch size is dynamic. In various examples, the records retrieved can be of multiple types, such as scans, scan indices, status logs, etc. In some cases, this pre-read range can be longer, for example, allowing for predictive reads of MS scans 301 through 400 while processing any data in ranges 1-100, 101-200, 201-300 until a built-in limit is reached, such as “3 buffer ranges.” In some cases, the total amount of data for all scans in a file can not exceed the sum of “the size of all saved buffers” and “the size of the predicted buffer.” In an example that allows for 3 delivered buffers and 1 predicted buffer, memory is reserved for 4 buffers at any time. This leads to a simplification, “if all data < 4 buffers, then save all data in memory.” In cases where the algorithm processes the data multiple times, saving all data in memory can be an advantage.

[0059] Figure 5 is a block diagram illustrating the interaction of the data delivery service 2450 with the data access application 2910 running on the client device 2900 and with the data storage subsystem 2410, in accordance with some embodiments. Figure 5 The block diagram of explicitly demonstrates the predictive algorithm module 5100 of the data delivery service 2450 and its other components described above (i.e., Figure 2the data structure 1000 (e.g., 2454, 2456 in FIG. 4; 4100, 4200, 4300 in FIG. 4). The data access application 2910 communicates with the raw data operator 4100 to request and receive data stored in various instances of the data structure 1000. The raw data operator 4100 selects the appropriate data reader plug-in via the dynamic data reader selector 2456. For example, the raw data operator 4100 can use a respective different data reader plug-in to read data from the cloud-based data storage subsystem 2410 and the local storage device 2454, e.g., as described above. The download manager 4200 and the storage manager 4300 communicate with the raw data operator 4100 and implement background downloads from the cloud-based data storage subsystem 2410 to the local storage device 2454 (e.g., as described above) to enable the raw data operator 4100 to switch data delivery routes between the network path 5200 and the local path 5300. The prediction algorithm module 5100 is used to select data blocks for background download, e.g., as described in more detail below.

[0060] Suppose the data structure 1000 has 1 million MS scans. On one hand, reading these MS scans one by one is inefficient; on the other hand, having the data delivery service 2450 cache all 1 million MS scans is not only inefficient, but even technically infeasible. Thus, the prediction algorithm module 5100 is used to determine an optimal number of MS scans for background download to ensure that the requested MS scans are efficiently delivered to the data access application 2910. The prediction algorithm 5100 is invisible to the calling code of the data access application 2910, which typically operates to request MS scans on demand. In various examples, the amount of memory allocated to background download (e.g., buffer size) per call read can be adjusted based on details of the respective data read protocol, the data structure 1000, and other relevant configuration parameters.

[0061] In some examples, the prediction algorithm module 5100 is configured to determine the buffer size based on several factors. For example, a hint (e.g., “suggested buffer size” (unit: bytes)) can come from the read accessor. Thus, S3 read and local disk read can hint different buffer sizes, respectively. In some examples, the prediction algorithm module 5100 operates using a combination of information from the “suggested buffer size” and “estimated average record length” of the selected data reader. In particular, the prediction algorithm module 5100 estimates how many records can fit in each buffer based on the suggested buffer size and the average record length. In some examples, the buffer size roughly corresponds to the respective background downloaded data block size.

[0062] In some examples, one or more buffers are shared among multiple concurrent read threads. Example implementations employ spin locks or similar concurrency support mechanisms depending on the specific programming language used. For example, a spin lock can be appropriate when the data delivery service 2450 is attempting to find an available record block containing a requested record. No high-cost work (such as memory allocation) is done within a spin lock. Only a relatively small number (e.g., three) of buffers remain active at any time. Thus, a general form of the search "is the requested record in any loaded buffer?" is relatively fast.

[0063] In this context, a spin lock is a low-level synchronization mechanism suitable for shared memory multiprocessors. When a calling thread requests a spin lock that is already held by another thread, the second thread will loop spinning to test whether the lock is available. When a spin lock is acquired, it is held for only a short time because spinning wastes processor cycles. The caller unlocks the spin lock before invoking other operations to enable other threads to acquire the spin lock.

[0064] In some examples, the prediction algorithm module 5100 is configured to discover and analyze patterns in the stream of data requests from the data access application 2910. When the next data request conforms to one of the discovered patterns, the prediction algorithm module 5100 operates to predict the future data request based on the pattern. Then, for example, as described above, a corresponding background download can be initiated based on the prediction and the data block size corresponding to the prediction. When the next data request does not conform to one of the discovered patterns, no new prediction is made, and the original data operator 4100 continues to read the requested data without a new prediction.

[0065] For example, when the data access application 2910 requests MS scan X1, the prediction algorithm module 5100 can prompt the data delivery service 2450 to also fetch MS scans X2 and X3 based on patterns detected in the corresponding stream of data requests. The prediction is made based on mass spectrometry-specific properties (e.g., parameters and / or criteria), such as scan order in a mass spectrometry scan sequence, requested mass range sequence, scan timing relative to a selected chromatographic peak or sequence of chromatographic peaks, etc. While certain CPU architectures sometimes employ a cache prefetch mechanism, such a cache prefetch mechanism is not related to mass spectrometry-specific parameters or criteria, nor is it based on such parameters. For example, prefetching in CPU architectures is typically related to CPU instructions and memory blocks, and not to mass spectrometry scans, mass ranges, or chromatographic peaks.

[0066] ​In some examples, the data structure 1000 can contain approximately one million MS scans. Analysis of a single sample can involve searching for approximately one thousand or even several thousand compounds from a corresponding "compound library." Representative examples of compound libraries are libraries of known contaminants and libraries of banned substance metabolites (e.g., in doping control testing). In an LC-MS instrument, these library compounds can elute at different times. The elution time of each compound can be estimated using a generally expected elution time under standard conditions and a time window added to the expected elution time, the width of the time window accounting for uncontrollable environmental differences or deviations from standard conditions. In practice, the time windows representing different compounds can overlap. In some examples, the prediction algorithm module 5100 is configured to use the list in the relevant library to identify the time window required for MS scans loaded for analysis of the corresponding sample. In other words, the prediction algorithm module 5100 can trigger a background download, enabling fast scan analysis of the relevant compound library if the data access application 2910 is instructed to use the relevant compound library. In various examples, such an instruction can be given to the prediction algorithm module 5100 via an explicit message from the data access application 2910 or inferred from a pattern detected in the corresponding sequence of data requests.

[0067] Figure 6 A block diagram of a scientific instrument support module 6000 for performing scientific instrument support operations in accordance with various embodiments is shown. The scientific instrument support module 6000 can be implemented by circuitry (e.g., including electrical and / or optical components), such as a programmed computing device. The logical components of the scientific instrument support module 6000 can be contained in a single common computing device, or can be distributed as appropriate across multiple computing devices in communication with one another. Examples of computing devices that can implement the scientific instrument support module 6000, alone or in combination, are discussed herein with reference to the computing device 7000 of Figure 7 Examples of systems of interconnected computing devices in which the scientific instrument support module 6000 can be implemented across one or more computing devices are discussed herein with reference to the scientific instrument support system 8000 of Figure 8 Examples of systems of interconnected computing devices in which the scientific instrument support module 6000 can be implemented across one or more computing devices are discussed herein with reference to the scientific instrument support system 8000 of

[0068] As discussed above, the scientific instrument support module 6000 can be implemented by a computing device, such as the computing device 7000 of Figure 6As shown, the scientific instrument support module 6000 includes a first logic component 6002, a second logic component 6004, and a third logic component 6006 for performing support methods as described herein on a scientific instrument 2100 (e.g., a TOF MS or LC-MS instrument). As used herein, the term “logic component” can include a device configured to perform a set of operations associated with the logic. For example, any of the logic elements included in the scientific instrument support module 6000 can be implemented by one or more computing devices programmed with instructions to cause one or more processing devices of the computing device to perform the associated set of operations. In particular embodiments, a logic element can include one or more non-transitory computer-readable media having instructions thereon that, when executed by one or more processing devices in one or more computing devices, cause the one or more computing devices to perform the associated set of operations. As used herein, the term “module” can 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 can take the same form or can take different forms. For example, some of the logic components in a module can be implemented by a programmed general-purpose processing device, while other logic components in the module can be implemented by an application-specific integrated circuit (ASIC). In another example, different ones of the logic elements in a module can be associated with different sets of instructions executed by one or more processing devices. A module can not include all of the logic elements depicted in the associated figure; for example, when a module is to perform a subset of the operations discussed herein with reference to that module, the module can include a subset of the logic elements depicted in the associated figure.

[0069] The first logic component 6002 can transmit portions of the data structure 1000 collected with one or more detectors of the scientific instrument 2100 to the client device 2900. As described above, the data structure 1000 is stored in the data storage subsystem 2410, which can be connected to the first logic component 6002 over a network. The portions of the data structure 1000 for transmission are identified to the first logic component 6002 according to data request sequences received from the client device 2900. In some examples, the first logic component 6002 is configured to perform at least some of the functions of the raw data operator 4100.

[0070] The second logic component 6004 can identify and select certain portions (data blocks) of the data structure 1000 based on at least one of data access patterns in the data request sequences from the client device 2900 and buffer sizes of the local storage device 2454. In some examples, the second logic component 6004 is configured to perform at least some of the functions of the prediction algorithm module 5100.

[0071] The third logic component 6006 can download portions (data blocks) of the data structure 1000 identified and selected by the second logic component 6004 from the data storage subsystem 2410 to the local storage device 2454. In some examples, the third logic component 6006 is configured to perform background downloads to download such portions concurrently with the transmission of one or more portions of the data structure 1000 from the data storage subsystem 2410 to the client device 2900 via the first logic component 6002. In some examples, the third logic component 6006 is configured to perform at least some of the functions of the download manager 4200 and the storage manager 4300 (see also FIG. 4).

[0072] Figure 7 A block diagram of a computing device 7000 that can perform at least some of the scientific instrument support functions and / or methods disclosed herein in accordance with various embodiments is shown. In some embodiments, the data delivery service 2450 can be implemented using a single computing device 7000 or multiple computing devices 7000. Other instances of the computing device 7000 (or multiple computing devices 7000) can be used to implement portions of one or more of the scientific instrument 2100, the computing device 2200, the client device 2900, and the data archive service 2430.

[0073] Figure 7 The computing device 7000 is shown with multiple components, but any one or more of these components can be omitted or repeated in application- and / or setup-dependent ways. In some embodiments, some or all of the components included in the computing device 7000 can 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 can be manufactured onto a single system on a chip (SoC) (e.g., the SoC can include one or more processing devices 7002 and one or more storage devices 7004). Additionally, in various embodiments, the computing device 7000 can not include one or more of the components shown in FIG. 7, but can include interface circuitry (not explicitly 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, the computing device 7000 can not include the display device 7010, but can include display device interface circuitry (e.g., a connector and drive circuitry) for coupling to an external display device 7010. Figure 7 The computing device 7000 is shown with multiple components, but any one or more of these components can be omitted or repeated in application- and / or setup-dependent ways. In some embodiments, some or all of the components included in the computing device 7000 can 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 can be manufactured onto a single system on a chip (SoC) (e.g., the SoC can include one or more processing devices 7002 and one or more storage devices 7004). Additionally, in various embodiments, the computing device 7000 can not include one or more of the components shown in FIG. 7, but can include interface circuitry (not explicitly 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, the computing device 7000 can not include the display device 7010, but can include display device interface circuitry (e.g., a connector and drive circuitry) for coupling to an external display device 7010.

[0074] The computing device 7000 can include a processing device 7002 (e.g., one or more processing devices). As used herein, the term “processing device” can refer to any device or portion of a device that manipulates electronic data based on instructions provided by a register and / or memory to transform that electronic data into other electronic data that can be stored in a register and / or memory. The processing device 7002 can include one or more digital signal processors (DSPs), application-specific integrated circuits (ASICs), central processing units (CPUs), graphics processing units (GPUs), cryptographic processors (specialized processors that perform cryptographic algorithms within hardware), server processors, or any other suitable processing devices.

[0075] The computing device 7000 can include a storage device 7004 (e.g., one or more storage devices). The storage device 7004 can include one or more memory devices, such as random access memory (RAM) devices (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-hdd-based memory devices, solid-state memory devices, network drives, cloud drives, or any combination of memory devices. In some embodiments, the storage device 7004 can include memory that shares a die with the processing device 7002. In such embodiments, the memory can function as cache memory and can include, for example, embedded dynamic random access memory (eDRAM) or spin-transfer torque magnetic random access memory (STT-MRAM). In some embodiments, the storage device 7004 can include a non-transitory computer-readable medium having instructions thereon that, when executed by one or more processing devices (e.g., the processing device 7002), cause the computing device 7000 to perform any suitable method or portion of a method disclosed herein.

[0076] The computing device 7000 can include an interface device 7006 (e.g., one or more interface devices 7006). The interface device(s) 7006 can include one or more communication chips, connectors, and / or other hardware and software to manage communications between the computing device 7000 and other computing devices. For example, the interface device(s) 7006 can include circuitry to manage wireless communications, such as to transmit and receive data between the computing device 7000 and other computing devices. In this document, the term “wireless” and its derivatives can be used to describe circuits, devices, systems, methods, techniques, communications channels, and / or the like that can communicate data through the use of modulated electromagnetic radiation through a non-solid medium. The term does not imply that the associated devices do not contain any wires, although in some embodiments they might not. The circuitry to manage wireless communications included in the interface device(s) 7006 can implement any of a number of wireless standards or protocols, including but not limited to IEEE standards including the 802.11 family of standards (e.g., that is, 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ad, 802.11ax, and / or 802.11be), the 802.16 standard (e.g., 802.16-2005 Amendment), the Long-Term Evolution (LTE) project

[0077] In some embodiments, the interface device 7006 can include circuitry for managing wired communications, such as electrical communication protocols, optical communication protocols, or any other suitable communication protocols. For example, the interface device 7006 can include circuitry that supports communications in accordance with Ethernet technology. In some embodiments, the interface device 7006 can support both wireless and wired communications, and / or can support multiple wired communication protocols and / or multiple wireless communication protocols. For example, a first set of circuitry of the interface device 7006 can be dedicated to short-range wireless communications such as Wi-Fi or Bluetooth, while a second set of circuitry of the interface device 7006 can be dedicated to long-range wireless communications such as Global Positioning System (GPS), EDGE, GPRS, CDMA, WiMAX, LTE, EV-DO, and so on. In some embodiments, a first set of circuitry of the interface device 7006 can be dedicated to wireless communications, and a second set of circuitry of the interface device 7006 can be dedicated to wired communications.

[0078] The computing device 7000 can include a battery / power supply circuit 7008. The battery / power supply circuit 7008 can include one or more energy storage devices (e.g., batteries or capacitors), and / or circuitry for coupling components of the computing device 7000 to an energy source separate from the computing device 7000 (e.g., an AC line power supply).

[0079] The computing device 7000 can include a display device 7010 (e.g., a plurality of display devices). The display device 7010 can include any visual indicator, such as a heads-up display, a computer monitor, a projector, a touchscreen display, a liquid crystal display (LCD), a light-emitting diode display, or a flat-panel display.

[0080] The computing device 7000 can include other input / output (I / O) devices 7012. The other I / O devices 7012 can include, for example, one or more audio output devices (e.g., speakers, headphones, earbuds, an alarm, and so on), one or more audio input devices (e.g., microphones or microphone arrays), a positioning device (e.g., a GPS device that communicates with satellite-based systems to receive a location of the computing device 7000 as known in the art), an audio codec, a video codec, a printer, a sensor (e.g., a thermocouple or other temperature sensor, a humidity sensor, a pressure sensor, a vibration sensor, an accelerometer, a gyroscope, and so on), an image capture device such as a camera, a keyboard, a cursor control device such as a mouse, a stylus, a trackball, or a touchpad, a barcode reader, a quick response (QR) code reader, or a radio frequency identification (RFID) reader.

[0081] The computing device 7000 can have any suitable form factor for its application and setting, such as a handheld or mobile computing device (e.g., a cell phone, a smartphone, a mobile Internet device, a tablet computer, a notebook 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.

[0082] In some examples, the computing device 7000 is implemented using multiple groups of containers (Kubernetes clusters). One representative Kubernetes cluster is composed of multiple computer nodes, which can be configured to host multiple groups of containers, each of which acts as a virtual machine. In various deployments, multiple instances of a microservice can be run on a single group of containers or multiple groups of containers. In some examples, better performance can be obtained when some of the groups of containers are distributed across different computer nodes.

[0083] Figure 7 is a block diagram of an example scientific instrument support system 8000 in which some or all of the scientific instrument support methods disclosed herein can be performed, in accordance with various embodiments. The scientific instrument support modules and methods disclosed herein can be implemented by one or more of the scientific instrument 2100, the user local computing device 2200, the service computing device 8030, or the remote computing device 8040 of the scientific instrument support system 2000.

[0084] Any of the scientific instrument 2100, the user local computing device 2200, the service computing device 8030, or the remote computing device 8040 can include any embodiment of the computing device 7000 discussed herein with reference to Figure 7 The scientific instrument 2100, the user local computing device 2200, the service computing device 8030, and / or the remote computing device 8040 can each include a respective processing device 7002, a respective storage device 7004, and a respective interface device 7006. The processing device 7002 can take any suitable form, including any of the forms of the processing device 7002 discussed herein with reference to Figure 7 The processing device 7002 included in the scientific instrument 2100, the user local computing device 2200, the service computing device 8030, or the remote computing device 8040 can take the same form or different forms. The storage device 7004 can take any suitable form, including any of the forms of the storage device 7004 discussed herein with reference to Figure 7The form of any of the storage devices 7004 at issue, and included in different devices of the scientific instrument 2100, the user local computing device 2200, the service computing device 8030, or the remote computing device 8040, can be the same or different. The interface devices 7006 can take any suitable form, including the forms discussed above with reference to Figure 7 The form of any of the interface devices 7006 at issue, and included in different devices of the scientific instrument 2100, the user local computing device 2200, the service computing device 8030, or the remote computing device 8040, can be the same or different.

[0085] The scientific instrument 2100, the user local computing device 2200, the service computing device 8030, and the remote computing device 8040 can communicate with other elements of the scientific instrument support system 8000 via communication paths 8008. As shown, the communication paths 8008 can communicatively couple the interface devices 7006 of different ones of the elements of the scientific instrument support system 8000, and can be wired or wireless communication paths (e.g., according to any of the communication technologies discussed above with reference to the interface devices 7006 of the computing devices 7000). Figure 8 Figures 1 to 8 The particular scientific instrument support system 8000 depicted in FIG. 8 includes communication paths between each pair of the scientific instrument 2100, the user local computing device 2200, the service computing device 8030, and the remote computing device 8040, but such a “fully connected” implementation is merely illustrative, and in various embodiments, various ones of the communication paths 8008 can not be present. For example, in some embodiments, the service computing device 8030 can not have a direct communication path 8008 between its interface device 7006 and the interface device 7006 of the scientific instrument 2100, but can communicate with the scientific instrument 2100 via the communication path 8008 between the service computing device 8030 and the user local computing device 2200 and the communication path 8008 between the user local computing device 2200 and the scientific instrument 2100. The scientific instrument 2100 can comprise any appropriate scientific instrument, such as a TOF MS or LC-MS instrument.

[0086] According to the example embodiments disclosed above, for example with reference to Figures 1 to 8 ​Any one or some or all of the above, provide a support apparatus for a scientific instrument, the support apparatus comprising: a first logic configured to transmit portions of a data structure collected with one or more detectors of the scientific instrument to a client device, the data structure stored in a data storage device connected to the first logic via a network, and the portions identified to the first logic according to a sequence of data requests received from the client device; a second logic configured to identify the portions of the data structure based on at least one of a data access pattern in the sequence of data requests and a buffer size of a storage device locally connected to the first logic; a third logic configured to download the portions from the data storage device to the storage device, wherein the first logic is configured to switch a data transmission path of the client device from terminating to the data storage device to terminating to the storage device when a requested portion of the data structure belongs to a portion downloaded to the storage device via the third logic.

[0087] In some embodiments of the above apparatus, the scientific instrument comprises at least one of a mass spectrometer and a chromatography system.

[0088] In some embodiments of any of the above apparatus, the second logic is configured to identify the portions of the data structure using a prediction algorithm configured to detect a data access pattern in a space defined by one or more attributes selected from a group of attributes, the attributes comprising: a scan order in a sequence of mass spectrometer scans, a mass range sequence, a relative time of a mass spectrometer scan to a chromatographic peak in a corresponding chromatogram, and a library of compounds.

[0089] In some embodiments of any of the above apparatus, the size of the structure is in a range of 1 GB to 100 GB and comprises data from multiple groups of mass spectrometer scans and detector channels corresponding to a single analyte injection.

[0090] In some embodiments of any of the above apparatus, the third logic is configured to perform a background download to download the portions, the background download concurrent with the transmission of the one or more portions from the data storage device to the client device via the first logic.

[0091] In some embodiments of any of the above apparatus, the first logic is configured to dynamically select a suitable data reader from a plurality of data readers based on the data transmission path.

[0092] In some embodiments of any of the above apparatus, the plurality of data readers comprises: a first data reader adapted to read data from the data storage device; and a second, different data reader adapted to read data from the storage device.

[0093] In some embodiments of any of the above-described apparatuses, the plurality of data readers are implemented as a plurality of application plug-ins.

[0094] In some embodiments of any of the above-described apparatuses, the data storage apparatus is selected from the group consisting of: a network-based object storage, an enterprise data storage platform, a microservices platform, a network-attached storage, and a storage area network.

[0095] In some embodiments of any of the above-described apparatuses, in response to receiving a subsequent data request from the client device, the first logic component is configured to: obtain an availability status of a subsequent portion of the data structure specified in the subsequent data request; when the availability status is “available”, transfer the subsequent portion of the data structure from the storage device to the client device; when the availability status is “unavailable”, transfer the subsequent portion of the data structure from the data storage apparatus to the client device.

[0096] In some embodiments of any of the above-described apparatuses, the first logic component is configured to switch the data transfer path in response to a message from the third logic component reporting a download completion event.

[0097] In some embodiments of any of the above-described apparatuses, the data structure has a binary format suitable for recording, packaging, and transferring experimental data collected via a plurality of detectors of a scientific instrument.

[0098] According to another exemplary embodiment disclosed above, e.g., with reference to any one of Figures 1 to 8 According to another exemplary embodiment disclosed above, e.g., with reference to any one of

[0099] In some embodiments of the above-described method, the scientific instrument comprises at least one of a mass spectrometer and a chromatography system.

[0100] In some embodiments of any of the above methods, the method further comprises identifying portions of the data structure using a prediction algorithm configured to detect data access patterns in a space defined by one or more attributes selected from a group of attributes, the attributes comprising: scan order in a mass spectrometer scan sequence, mass range sequence, relative time of a mass spectrometer scan to a chromatographic peak in a corresponding chromatogram, and a library of compounds.

[0101] In some embodiments of any of the above methods, downloading comprises performing a background download concurrently with transmitting one or more portions of the data structure from the data store to the client device via the computing device.

[0102] In some embodiments of any of the above methods, the method further comprises dynamically selecting an appropriate data reader from a plurality of data readers based on a data transmission path.

[0103] In some embodiments of any of the above methods, the plurality of data readers are implemented as a plurality of application plug-ins.

[0104] In some embodiments of any of the above methods, the data structure has a binary format suitable for recording, packaging, and transmitting experimental data collected via a plurality of detectors of a scientific instrument.

[0105] According to yet another exemplary embodiment of the above disclosure, for example, with reference to any one or some or any combination of all of ​ there is provided one or more non-transitory computer readable media having instructions thereon that, when executed by one or more computing devices for providing support for a scientific instrument, cause the one or more computing devices to perform any of the above automated methods.

Claims

1. A support device for a scientific instrument, the support device comprising: A first logic unit is configured to transmit a portion of a data structure acquired using one or more detectors of a scientific instrument to a client device, the data structure being stored in a data storage device connected to the first logic unit via a network, and to identify the portion to the first logic unit in a sequence of data requests received from the client device. The second logical component is configured to identify portions of a data structure based on at least one of the data access pattern in the data request sequence and the buffer size of a storage device locally connected to the first logical component. and A third logic component is configured to download the portion from the data storage device to the storage device. The first logic component is configured to switch the data transmission path of the client device from termination to data storage device to termination to storage device when the requested portion of the data structure is downloaded to the storage device via the third logic component.

2. The support device according to claim 1, wherein the scientific instrument includes at least one of a mass spectrometer and a chromatography system.

3. The support device of claim 2, wherein the second logic component is configured to identify portions of a data structure using a prediction algorithm, the prediction algorithm being configured to detect data access patterns in a space defined by one or more attributes selected from an attribute group, the attribute group comprising: The scanning sequence in a mass spectrometer scan sequence. Quality range sequence, The relative time of mass spectrometry scans and the corresponding chromatographic peaks in the chromatograms, and A library of chemical compounds.

4. The support device according to claim 2, wherein, The data structure has a size ranging from 1 GB to 100 GB and includes data from multiple mass spectrometer scans and detector channels corresponding to a single analyte injection.

5. The support apparatus of claim 1, wherein the third logic unit is configured to perform a background download to download the portion, the background download occurring concurrently with the transmission of one or more portions of a data structure from a data storage device to a client device via the first logic unit.

6. The support device of claim 1, wherein the first logic component is configured to dynamically select a suitable data reader from a plurality of data readers based on the data transmission path.

7. The support device according to claim 6, wherein the plurality of data readers comprises: The first data reader is suitable for reading from data storage devices; and Different second data readers are available for reading from storage devices.

8. The support device according to claim 6, wherein, The multiple data readers are implemented as multiple application plugins.

9. The support device according to claim 1, wherein the data storage device is selected from the group consisting of: Web-based object storage devices Enterprise data storage platform Microservice platform Network attached storage device, and Storage Area Network (SLAN).

10. The support device according to claim 1, wherein, In response to a subsequent data request received from the client device, the first logic component is configured to: Obtain the availability status of the subsequent part of the data structure specified in the subsequent data request; When the availability status is "available", the subsequent part of the data structure is transferred from the storage device to the client device; as well as When the availability status is "unavailable", the subsequent part of the data structure is transferred from the data storage device to the client device.

11. The support apparatus of claim 1, wherein the first logic component is configured to switch the data transmission path in response to a message from the third logic component reporting a download completion event.

12. The support device of claim 1, wherein the data structure has a binary format suitable for recording, encapsulating, and transmitting experimental data acquired by multiple detectors in a scientific instrument.

13. An automated method for providing support for scientific instruments, executed via a computing device, the method comprising: Transmit a portion of the data structure collected using one or more detectors of a scientific instrument to the client device; The data structure is stored in a data storage device connected to the computing device via a network, and the portion is identified to the computing device in a sequence of data requests received from the client device. Parts of the data structure are identified based on at least one of the data access pattern in the data request sequence and the buffer size of the storage device locally connected to the computing device. Download the portion from the data storage device to the storage device; as well as When the requested portion of the data structure is downloaded to the storage device via the computing device, the data transmission path of the client device is switched from being terminated to the data storage device to being terminated to the storage device.

14. The automation method of claim 13, wherein the scientific instrument comprises at least one of a mass spectrometer and a chromatography system.

15. The automation method of claim 14, further comprising a portion of identifying a data structure using a prediction algorithm configured to detect data access patterns in a space defined by one or more attributes selected from an attribute group, the attribute group comprising: The scanning sequence in a mass spectrometer scan sequence. Quality range sequence, The relative time of mass spectrometry scans and the corresponding chromatographic peaks in the chromatograms, and A library of chemical compounds.

16. The automated method of claim 13, wherein the download includes concurrently performing a background download with the transfer of one or more portions of a data structure from a data storage device to a client device via a computing device.

17. The automation method of claim 13 further includes dynamically selecting a suitable data reader from a plurality of data readers based on the data transmission path.

18. The automation method according to claim 17, wherein, The multiple data readers are implemented as multiple application plugins.

19. The automation method of claim 13, wherein the data structure has a binary format suitable for recording, encapsulating, and transmitting experimental data acquired by multiple detectors in a scientific instrument.

20. One or more non-transitory computer-readable media having instructions thereon that, when executed by one or more computing devices for providing scientific instrument support, cause the one or more computing devices to perform the automated method according to claim 13.

Images