Multi-version processing using a monitor subsystem

Abstract

Versions of a sequencing system can be monitored to enable changing versions of server subsystems operating the sequencing system to service requests from client subsystems for performing analysis of sequencing data. A monitor subsystem can be used to receive and authorize requests from client subsystems. The monitor subsystem can identify a version associated with a server subsystem operating the sequencing system to be implemented to service the request. The monitor subsystem can allow access to the server subsystem to service the request from the client subsystem when the version associated with the client subsystem and the version associated with the server subsystem are compatible. The monitor subsystem can prevent the server subsystem from being accessed when the version associated with the client subsystem and the version associated with the server subsystem are not compatible.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 408,235, filed September 20, 2022, which is incorporated herein by reference in its entirety. Background Technology

[0003] The sequencing platform provides rapid and accurate secondary and tertiary genomic analysis of sequencing data. The platform can span hardware and software to deliver complete sequencing solutions. In a single-process (SP) environment, a single application can run on a single field-programmable gate array (FPGA) mounted on a server device at a time. A single version of the software can be installed on the server device at a given time. Users with specific version requirements can install their desired software version and run their applications.

[0004] In a multi-process (MP) environment, multiple applications can run simultaneously on a set of FPGA hardware. Several users can run sequencing jobs concurrently. Because sequencing solutions can span multiple layers of software and hardware, it is difficult to support different versions of client software applications running sequencing software on server devices. Summary of the Invention

[0005] This document describes systems, methods, and apparatus for monitoring the version of a sequencing system to enable the modification of the version of a server subsystem operating the sequencing system to serve requests from client subsystems for performing analysis of sequencing data. A monitoring subsystem can be used to receive requests from client subsystems. Requests may include the version associated with the client subsystem from which the request is received. The monitoring subsystem can identify the version to be implemented to serve the request associated with the server subsystem operating the sequencing system. When the version associated with the client subsystem and the version associated with the server subsystem are compatible, the monitoring subsystem can allow access to the server subsystem to serve the request from the client subsystem. When the version associated with the client subsystem and the version associated with the server subsystem are incompatible, the monitoring subsystem can prevent access to the server subsystem. The monitoring subsystem can identify changes to the version associated with the server subsystem to authorize requests from client subsystems that were previously blocked from accessing the server subsystem due to version incompatibility.

[0006] The monitoring subsystem can continue to authorize requests from client subsystems associated with the compatible version, while the server subsystem continues to operate the same version of the sequencing system. When the monitoring subsystem determines that the server subsystem or processes operating on it are idle, it can cause the server subsystem to change the version used to handle requests from client subsystems operating using a different version of the sequencing application. The change from version one to version two involves dismantling and building at least one software layer in the vertical solution stack.

[0007] Each version of the server subsystem may include different features for bioinformatics components associated with processing different requests. Different bioinformatics components can be utilized by loading them into one or more field-programmable gate arrays (FPGAs). Different versions of the server subsystem may support loading different bioinformatics components onto one or more FPGAs to support the same or different sequencing tasks. Sequencing tasks may include tasks performed in secondary or tertiary analyses of sequencing data. Secondary or tertiary analyses include alignment, sorting, or variant detection based on sequencing data.

[0008] The monitoring subsystem can be a daemon. The server subsystem can be a daemon that operates at least partially on the client device or the server device. A daemon can be one of several predefined daemons within the server subsystem.

[0009] The monitoring subsystem can prevent the server subsystem from being accessed by the client subsystem by preventing the access key from being transmitted to the client subsystem or by preventing the establishment of a connection between the client subsystem and the server subsystem. The monitoring subsystem can also allow the server subsystem to be accessed by the client subsystem by providing the access key to the client subsystem. Furthermore, the monitoring subsystem can notify the server subsystem that the access key has been provided to the client subsystem.

[0010] The client subsystem may receive a message indicating that it is blocked. The client subsystem may wait for an indication from the monitoring subsystem that the request can be processed. The client subsystem may receive an access key and transmit a message to the server subsystem including the access key used to establish a connection with the server subsystem.

[0011] The request can be received from the client subsystem via a socket by the monitoring subsystem. Access to the server subsystem can be granted via a socket using an access key. The monitoring subsystem can monitor signals from child processes to detect terminal signals used to restart child processes. Attached Figure Description

[0012] Figure 1A A schematic diagram of the system environment is shown.

[0013] Figure 1B This is a diagram illustrating a system including a monitor subsystem that can be used to manage requests from client sequencing applications operating on client subsystems of different versions.

[0014] Figure 1C An example of one or more bioinformatics subsystems is shown, which can be implemented by a sequencing system operating on a server subsystem for performing sequencing analyses in the form of secondary and / or tertiary sequencing.

[0015] Figure 2 This is a flowchart depicting an exemplary process for monitoring the version of the server subsystem and processing requests from compatible client subsystems.

[0016] Figure 3 This is a block diagram of an exemplary computing device. Detailed Implementation

[0017] Figure 1A A schematic diagram of a system environment (or “environment”) 100 as described herein is shown. As shown, environment 100 includes one or more server devices 102 connected via network 112 to one or more client devices 108 and sequencing devices 114.

[0018] like Figure 1A As shown, server device 102, client device 108, and sequencing device 114 can communicate with each other via network 112. Network 112 can include any suitable network on which computing devices can communicate. Network 112 can include wired and / or wireless communication networks. Exemplary wireless communication networks can include one or more types of radio frequency (RF) communication signals using one or more wireless communication protocols, such as cellular communication protocols, wireless local area network (WLAN) or Wi-Fi communication protocols, and / or another wireless communication protocol. As a supplement to or alternative to communication across network 112, server device 102, client device 108, and / or sequencing device 114 can bypass network 112 and can communicate directly with each other.

[0019] like Figure 1A As further illustrated, environment 100 may include database 116. Database 116 may store information accessible to devices in environment 100. Server device 102, client device 108, and / or sequencing device 114 may communicate with database 116 (e.g., directly or via network 112) to store and / or access information.

[0020] like Figure 1AAs indicated, sequencing device 114 may include equipment for sequencing biological samples. Biological samples may include human and / or non-human deoxyribonucleic acid (DNA) to determine individual nucleotide bases of the nucleic acid sequence (e.g., by synthetic sequencing). Biological samples may include human and / or non-human ribonucleic acid (RNA). Sequencing device 114 may analyze nucleic acid fragments and / or oligonucleotides extracted from the sample to generate nucleotide reads and / or other data directly or indirectly on sequencing device 114 using the computer-implemented methods and systems described herein. More specifically, sequencing device 114 may receive and analyze nucleic acid sequences extracted from the sample within a nucleotide sample slide (e.g., a flow cell). Sequencing device 114 may utilize synthetic sequencing (“SBS”) to sequence nucleic acid fragments into nucleotide reads.

[0021] like Figure 1A As further indicated, server device 102 can generate, receive, analyze, store, and / or transmit digital data, such as data used to determine nucleotide base detection or to sequence nucleic acid polymers. Figure 1A As shown, sequencing device 114 can generate and send (and server device 102 can receive) nucleotide reads and / or other sequencing data for analysis by server device 102 for base detection and / or variant detection. Server device 102 can also communicate with client device 108. Specifically, server device 102 can send data, including sequencing data or other information, to client device 108, and server device 102 can receive input from a user via client device 108.

[0022] Server device 102 may include a distributed collection of servers, comprising multiple server devices distributed across network 112 and located in the same or different physical locations. Further, server device 102 may include a content server, application server, communication server, web hosting server, or another type of server.

[0023] like Figure 1A As further illustrated, server device 102 and / or sequencing device 114 may include server subsystem 104. Server subsystem 104 may include software and / or hardware used by server device 102 to process sequencing requests and / or data, as described herein. Server subsystem 104 may be included in a single server device 102 or sequencing device 114, or may be distributed across multiple devices. Server subsystem 104 may include a sequencing system spanning multiple layers of software and / or hardware for serving requests for sequencing services at server subsystem 104.

[0024] Server subsystem 104 can analyze nucleotide reads and / or other data, such as sequencing metrics, received from sequencing device 114 to determine the nucleotide base sequence of nucleic acid polymers. For example, server subsystem 104 can receive raw data from sequencing device 114 and determine the nucleotide base sequence of nucleic acid fragments. Server subsystem 104 can process sequencing data to determine the sequence of nucleotide bases in DNA and / or RNA fragments or oligonucleotides. In addition to processing and determining sequences for biological samples, server subsystem 104 can also generate files for processing and / or transfer to other devices.

[0025] Each client device 108 can generate, store, receive, and / or transmit digital data. Specifically, client device 108 can receive sequencing metrics from sequencing device 114. Furthermore, client device 108 can communicate with server device 102 to receive one or more files containing nucleotide base detections and / or other metrics. Client device 108 can present or display information related to nucleotide base detection to the user associated with it within a graphical user interface.

[0026] Figure 1A The illustrated client device 108 may include various types of client devices. For example, client device 108 may include non-mobile devices, such as desktop computers or servers, or other types of client devices. In other examples, client device 108 may include mobile devices, such as laptops, tablets, mobile phones, or smartphones.

[0027] like Figure 1A As further illustrated, each client device 108 may include one or more client subsystems 110. Server device 102 and / or sequencing device 114 may also, or alternatively, include one or more client subsystems. Each client subsystem 110 may include software and / or hardware used by client processes to handle sequencing requests and / or data, as described herein. Client subsystems 110 may span multiple layers of software and / or hardware. Client subsystems 110 may be included in a single device or may be distributed across multiple devices.

[0028] The client subsystem 110 may include a sequencing application. The sequencing application may be a remote application or a local application stored and executed on a local device. The sequencing application may include instructions that, when executed, cause the client device 108 to receive data from the sequencing device 114 and / or the server device 102, and to present the data to the user of the client device 108 for display at the client device 108.

[0029] Multiple client requests from client subsystem 110 can be received at server subsystem 104 for performing sequencing services. Client subsystem 110, which is transmitting requests, can operate using different versions of a sequencing application used to analyze sequencing data. In one example, different versions of the sequencing application can support different types of analysis for the same or different types of sequencing devices 144. Server subsystem 104 of server device 102 can load and execute different versions of the sequencing system to support client sequencing applications operating on different versions of software at client subsystem 110. Different versions of the sequencing system can span multiple layers of software and / or hardware of server subsystem 104. For example, different versions of the sequencing system can span multiple software and / or hardware layers of a vertical solution stack.

[0030] The monitoring subsystem can be used to properly manage requests received at the server subsystem 104 from the client subsystem 110, which operates on different versions of the software. Figure 1B This is an illustration of a system 100a including a monitoring subsystem 120, which can be used to manage requests from client sequencing applications operating on client subsystems 110a and 110b in different versions. For example, the monitoring subsystem 120 can receive a request 150 from client subsystem 110a and a request 152 from client subsystem 110b. Client subsystems 110a and 110b may each communicate with monitor subsystem 120 via standard Berkley (BSD) sockets, addresses (e.g., IP addresses and ports), or another communication interface accessible via function calls as endpoints for sending and / or receiving information. Client subsystems 110a and 110b may execute sequencing applications operating on different versions of the software. Monitor subsystem 120 may be a daemon or other background process executing on one or more server devices 102, one or more sequencing devices 114, one or more client devices 108, and / or distributed across server device 102, sequencing device 114, and / or client device 108. Monitor subsystem 120 may be able to manage requests 150 and 152 for services to be performed by server subsystem 104, allowing server subsystem 104 to load and execute different versions of the software used to operate the sequencing system to support the services in each of requests 150 and 152.

[0031] Requests 150 and 152 may each include a version identifier, a product identifier, or other information associated with the respective client subsystems 110a and 110b and / or the sequencing application from which each request 150 or 152 is received. Monitor subsystem 120 may use the version identifier, product identifier, and / or other information in request 150 to identify the version of the operation that client subsystem 110a is using to perform the sequencing application on it. Monitor subsystem 120 may use the version identifier, product identifier, and / or other information in request 152 to identify the version of the operation that client subsystem 110b is using to perform the sequencing application on it.

[0032] The monitoring subsystem 120 can be started upon startup of the sequencing system and / or the device on which it is installed. The monitoring subsystem 120 can monitor the version of the sequencing system installed on the server subsystem 104 (which may be referred to as the version of server subsystem 104) to determine whether the version of the sequencing system installed on server subsystem 104 is compatible with the versions of client subsystems 110a, 110b and / or applications executing on them that are receiving requests 150, 152 from them. Compatible versions can be stored in a file in memory for the monitoring subsystem 120 to reference. When a newer version of the sequencing system is installed in memory on one or more devices on which the server subsystem is installed, the file can be updated to identify the compatible version of the client subsystem. The monitoring subsystem 120 can communicate with one or more processes on server subsystem 104 to identify versions of one or more layers of software and / or hardware installed in the sequencing system. For example, server subsystem 104 can program each layer of software and / or hardware in a vertical solution stack according to different versions of the sequencing system.

[0033] In one example, the software layer of server subsystem 104 may include a daemon 160 to which monitoring subsystem 120 can communicate. Daemon 160 may be a background process executing on one or more devices (e.g., server device 102, sequencing device 114, and / or client device 108). Daemon 160 may manage the hardware on one or more devices (e.g., server device 102, sequencing device 114, and / or client device 108) in response to requests from client subsystems operating with a compatible version of the sequencing application. Daemon 160 may be a subservice of monitoring subsystem 120, started by monitoring subsystem 120. Monitoring subsystem 120 may start and monitor its subprocesses during its operation. If any subprocess dies unexpectedly, monitoring subsystem 120 may detect the loss and restart the subprocess. Monitoring subsystem 120 is able to tear down and build services at each layer during version switching by sending commands to one or more subprocesses (e.g., daemon 160, daemon licensing process 163, and / or daemon 164). The monitoring subsystem 120 can query the daemon 160 for the versions of the software and / or hardware layers in the vertical solution stack. Alternatively, the monitoring subsystem 120 can receive push notifications for the versions of the software and / or hardware layers in the vertical solution stack.

[0034] Server subsystem 104 may include other software processes. For example, server subsystem 104 may include other background daemons in a vertical solution stack. Server subsystem 104 may include daemon licensing process 163. Daemon licensing process 163 may communicate with monitor subsystem 120 and / or daemon 160 to coordinate licenses used by server subsystem 104. For example, daemon 160 may coordinate with daemon licensing process 163 to verify licenses on behalf of client subsystem 110. Monitor subsystem 120 may start daemon 160 and / or daemon licensing process 163 and monitor these services as described herein. Server subsystem 104 may also or alternatively include daemon huge page process 164. Daemon huge page process 164 may communicate with daemon 160 and / or huge page control process 166 to manage huge pages for direct memory access (DMA) transfers between main memory and external hardware (e.g., external FPGA hardware). For example, daemon 160 may coordinate with daemon huge page process 164 on behalf of client subsystem 110. The monitoring subsystem 120 may start daemon 160 and / or giant page process 164 and monitor these services as described herein. Daemon license process 163 and daemon giant page process 164 may be sub-services of the monitoring subsystem 120 started by the monitoring subsystem 120.

[0035] Server subsystem 104 may include a loadable kernel driver 162. For example, the loadable kernel driver 162 may be included in a vertical solution stack. The loadable kernel driver 162 may be a memory-residing application that facilitates interaction between one or more parts of the hardware and one or more parts of the software. For example, the loadable kernel driver 162 may communicate with a daemon 160 and / or one or more parts of the programmable hardware used to serve the sequencing system. The loadable kernel driver 162 may support one or more field-programmable gate arrays (FPGAs) including a partially reconfigured bitstream 168. For example, the loadable kernel driver 162 may support one or more FPGAs via a Fast Peripheral Component Interconnect (PCIe) or another type of serial expansion bus for connection to one or more peripheral devices.

[0036] The hardware layer in server subsystem 104 may include programming for one or more hardware layers in a vertical solution stack, such as an FPGA including partially reconfigured bitstream 168 and / or shell 170. Shell 170 may be a hardware layer including low-level code for controlling the hardware functionality on one or more devices (e.g., server device 102, sequencing device 114, and / or client device 108) on which server subsystem 104 operates. The FPGA may include higher-level code, such as the partially reconfigurable bitstream 168 for controlling the bioinformatics components of the sequencing system. Different bioinformatics components are uploaded to the partially reconfigured bitstream 168 of the FPGA via server subsystem 104, and different sequencing features can be used to serve requests to the sequencing system. For example, different images of the partially reconfigured bitstream 168 can be uploaded to perform different forms of secondary and / or tertiary sequencing analyses. Different versions of bioinformatics components are uploaded via the partially reconfigured bitstream 168 of the FPGA via server subsystem 104, and different sequencing features can be used to serve requests to the sequencing system. Different sequencing features may include different algorithms and / or optimizations relative to other versions. Each server subsystem 104 may include one or more FPGAs, which may be independently and partially reconfigured for board management using custom hardware and / or their own enclosure 170.

[0037] Figure 1C Examples of one or more bioinformatics subsystems are shown, which can be implemented by a sequencing system operating on server subsystem 104 for performing secondary and / or tertiary sequencing analyses. Figure 1CAs shown, the sequencing system can implement a mapper subsystem 122, a sorter subsystem 124, and / or a variant detector subsystem 126. Each bioinformatics subsystem can perform different sequencing tasks. The mapper subsystem 122 can be implemented to compare reads in sequencing data received from and / or stored at one or more devices (e.g., server device 102, sequencing device 114, and / or client device 108) on which the server subsystem 104 operates. Reads in sequencing data generated and / or generated by the sequencing device 114 and stored in files in memory.

[0038] It may not be included in a single sequence containing all DNA information. Instead, sequencing data generated by sequencing device 114 and / or generated in a file stored in memory may include multiple short subsequences or reads containing partial DNA information. Read alignment may be performed by mapper subsystem 122 to map reads to a reference genome and identify the location of each individual read on the reference genome.

[0039] After read alignment is performed at mapper subsystem 122, the aligned sequencing data can be passed downstream to sorting subsystem 124 to sort reads by reference positions, and polymerase chain reaction (PCR) or optical repeats can be optionally labeled. The initial sorting stage can be performed by sorter subsystem 124 on the aligned reads returned from RAM 125. When mapping is complete, final sorting and repeat labeling can begin.

[0040] The variant detector subsystem 126 can be used to detect variants from aligned and sorted reads in sequencing data. For example, the variant detector subsystem can receive a sorted BAM file as input and process the reads to generate variant information that will be included in a variant detection file (VCF) or a genome variant detection format (gVCF) file as output from the variant detector subsystem 126.

[0041] For each of the subsystems (e.g., mapper subsystem 122, sorter subsystem 124, and variant detector subsystem 126), different images can be loaded from disk 123 on server device 102 into random access memory (RAM) 125. For example, RAM 125 may include field-programmable gate array (FPGA) board dynamic RAM (DRAM) on server device 102, on which different images are loaded from disk 123 for performing different types of analysis using the corresponding subsystem.

[0042] Depending on the different versions of the server subsystem 104 that process requests from client subsystems 110a and 110b, different versions of the subsystem can be loaded into RAM 125 to support bioinformatics analysis. See again Figure 1B Different versions of each subsystem can be loaded onto the FPGA as part of a reconfigured bitstream 168 so that the server subsystem 104 can perform analysis according to different bioinformatics subsystems (e.g., mapper subsystem 122, sorter subsystem 124, and variant detector subsystem 126).

[0043] like Figure 1B As shown, daemon 160 can receive requests from authorized client subsystems 110a, 110b and communicate with other daemons 163, 164 and / or loadable kernel driver 162 to update partially reconfigured bitstream 168, thereby performing sequencing analysis in response to the request. When monitor subsystem 120 determines that a request is being received from client subsystem 110a operating a sequencing application with a version compatible with the current version of server subsystem 104, the request can be authorized by monitor subsystem 120. The version of server subsystem 104 can be updated by updating the versions of one or more components of server subsystem 104. For example, the version of server subsystem 104 can be updated by updating one or more layers of a vertical solution stack, which may include daemon 160, daemon licensing process 163, daemon 164, massive page control process 166, loadable kernel driver 162, partially reconfigured bitstream 168, and / or shell 170.

[0044] The monitoring subsystem 120 can send commands to the daemon 160 to start, stop, and / or restart one or more processes, drivers, and / or layers. The monitoring subsystem 120 can send commands to the daemon 160 to select a version of the sequencing system and load it into memory for operation on the server subsystem 104. The monitoring subsystem 120 can send commands to the daemon 160 to load a version of the loadable kernel driver 162 and / or a version of the massive page control process 166.

[0045] The monitoring subsystem 120 can be responsible for authorizing client subsystems 110a and 110b to send requests 154 and 156 to the daemon 160. When the server subsystem 104 is implementing a version of the sequencing system compatible with the version of the sequencing application running on the client subsystems 110a and 110b from which requests 150 and 152 are received, the monitoring subsystem 120 can authorize client subsystems 110a and 110b to send requests 154 and 156 to the daemon 160. Requests 150 and 152 can be triggered by a checkout from higher-level software that can provide a full path or a standard script that determines the path based on the version number of the sequencing application. This trigger can cause requests 150 and 152 to be sent to the monitoring subsystem 120 to request permission to continue running. Requests 150 and 152 can be a blocking checkout returned when permission is granted or denied. Requests 150 and 152 may each include a product identifier, a version identifier, and / or other information associated with the corresponding client subsystems 110a and 110b from which requests 150 and 152 are received. Monitor subsystem 120 may determine from the information in requests 150 and 152 whether to authorize client subsystems 110a and 110b to access daemon 160.

[0046] In one example, client subsystem 110a and client subsystem 110b may be operating using different versions of a sequencing application. Monitor subsystem 120 may receive request 150 from client subsystem 110a and determine that client subsystem 110a is operating a version of the sequencing application that is compatible with the current version of the sequencing system operating on server subsystem 104. Monitor subsystem 120 may authorize client subsystem 110a to send request 154 to daemon 160 for access to daemon 160 and / or have the request serviced by server subsystem 104. If monitor subsystem 120 determines that the version of client subsystem 110a receiving request 150 is compatible with the version of server subsystem 104, monitor subsystem 120 may send authorization message 151 to client subsystem 110a to grant access to server subsystem 104 and / or daemon 160. The authorization message may include an acknowledgment in response to the request, or monitor subsystem 120 may send an acknowledgment of receipt of each request without providing authorization. The authorized client subsystem 110a may register in memory with the monitor subsystem 120 as authorized to be served by the server subsystem 104. The authorization message 151 may include an access key for accessing the server subsystem 104 and / or the daemon 160. The access key may also be provided to the daemon 160 in a notification message informing it that the client subsystem 110a has been authorized, enabling the daemon 160 to recognize the authorized client subsystem 110a. Alternatively, the monitor subsystem 120 may provide the daemon 160 with an identifier of the client subsystem 110a or other information associated with the client subsystem 110a to indicate that the client subsystem 110a has been authorized. The daemon 160 may receive a request 154 and recognize that the request was received from the authorized client subsystem 110a (e.g., based on the access key or other information in the request 154). After daemon 160 recognizes that it is receiving request 154 from authorized client subsystem 110a, daemon 160 may establish a connection with client subsystem 110a, register client subsystem 110a in memory, and begin servicing request 154 by communicating with other processes, drivers, and / or layers of the vertical solution stack in server subsystem 104. This connection may be established via a standard Berkeley (BSD) socket or another communication interface, address (e.g., IP address and port), or another communication interface accessible via function calls as endpoints for sending and / or receiving information.

[0047] Daemon 160 can communicate with loadable kernel driver 162 to serve one or more requests from client subsystems. For example, loadable kernel driver 162 may have one or more FPGAs under its control. Loadable kernel driver 162 can be located via one or more PCIe-enabled FPGAs. Bioinformatics subsystems (e.g., mapper subsystem 122, sorter subsystem 124, and variant detector subsystem 126) can be loaded into each FPGA to process requests. Different bioinformatics subsystems can be loaded into different FPGAs to process different requests simultaneously. This allows requests to be processed in batches using parallel processing across multiple FPGAs. Each bioinformatics subsystem can operate in a version compatible with the version of the request from the client subsystem. Upon receiving a corresponding request, daemon 160 can perform workload management and dispatch client jobs to the FPGAs. Loadable kernel driver 162 can enumerate these devices and provide communication paths between daemon 160 and the appropriate FPGA.

[0048] The monitoring subsystem 120 can receive a request 152 from the client subsystem 110b and determine that the client subsystem 110b is operating a sequencing application with a version incompatible with the current version of the sequencing system operating on the server subsystem 104. Because the client subsystem 110b is operating a sequencing application with a version incompatible with the current version of the server subsystem 104, the client subsystem 110b can be blocked and / or request 152 can be queued for later service. Requests compatible with a different version of the currently loaded server subsystem can be queued in a different queue or the same queue. The client subsystem 110b can be blocked and / or request 152 can be queued until the sequencing system of the server subsystem 104 is operating a version compatible with the version of the sequencing application operating on the client subsystem 110b. The monitoring subsystem 120 may fail to provide an access key to the client subsystem 110b, thereby preventing the client subsystem 110b from accessing the daemon 160 of the server subsystem 104 until the server subsystem 104 is operating a version compatible with the version of the sequencing application operating on the client subsystem 110b. The monitoring subsystem 120 may send a message to the client subsystem configured to cause the client subsystem to wait for authorization and / or transmit subsequent requests at a later time.

[0049] The monitoring subsystem 120 can monitor the status of the server subsystem 104 to determine the appropriate time for authorized client subsystem 110b to access the server subsystem 104. For example, the monitoring subsystem 120 can monitor the status of client subsystems (such as client subsystem 110a) that have been authorized to access the server subsystem 104 and / or that have been registered in memory as authorized. The monitoring subsystem 120 can monitor the status of one or more child processes (e.g., daemon 160, daemon license process 163, and / or daemon 164) that are processing requests from client subsystems that have been authorized to access the server subsystem 104, and identify termination signals from one or more child processes that are serving requests from client subsystems. Termination signals can identify the completion of a service being requested from the server subsystem 104 (e.g., completion of the service and / or task identified in request 154) or the abnormal termination of a requested service that has failed to complete. If any child process terminates without the monitoring subsystem 120 explicitly notifying it of termination by sending a signal, the monitoring subsystem 120 is notified of the termination of the child process by another service. For example, monitoring subsystem 120 can receive a PID (Process Identifier) ​​and termination reason from other services operating on the same device. Monitoring subsystem 120 can log the PID and / or the termination reason and restart the process. If monitoring subsystem 120 identifies an abnormal termination, it can automatically reset the software and / or hardware managed by server subsystem 104. For example, monitoring subsystem 120 can signal daemon 160 to reset hardware, child processes of monitoring subsystem 120, processes, drivers, and / or other software in the vertical solution stack. The hardware and / or software can be restarted to operate with the same version of software loaded into server subsystem 104 prior to the restart. After the hardware and / or software has been restarted, server subsystem 104 can continue to serve requests compatible with the current version of server subsystem 104.

[0050] While one or more processes in server subsystem 104 are serving requests from authorized client subsystems (such as client subsystem 110a), the server subsystem can operate in an active state. While server subsystem 104 is active and serving request 154 from client subsystem 110a, monitoring subsystem 120 can continue to receive requests from other client subsystems. Requests from client subsystems operating the sequencing application with a version incompatible with server subsystem 104 can continue to be blocked and / or queued for later service. Requests from client subsystems operating the sequencing application with a version compatible with server subsystem 104 can continue to be authorized (e.g., while request 152 from client subsystem 110b is queued), and server subsystem 104 can remain active until a termination signal is recognized. When the activity of each of the previously authorized client subsystems has terminated, server subsystem 104 and / or one or more of its processes can enter an idle state.

[0051] The monitoring subsystem 120 can communicate with one or more processes of the server subsystem 104 to determine whether the server subsystem 104 and / or one or more of its processes are active or idle. In one example, the monitoring subsystem 120 can communicate with the daemon 160 to determine the active and idle status of the server subsystem 104 and / or one or more of its processes. The monitoring subsystem 120 can send commands to the daemon 160 to request the current status of processing for each request from the client subsystem. The monitoring subsystem 120 can send commands to the daemon 160 to query the current version of the server subsystem 104.

[0052] The monitoring subsystem 120 can determine from the daemon 160 when the daemon 160 and / or other processes or layers in the vertical solution stack are active or idle. When the monitoring subsystem 120 determines from the daemon 160 that the daemon 160 and / or other processes or layers in the vertical solution stack have stopped serving the client subsystem and entered an idle state for a period of time, the monitoring subsystem 120 can change the version of the sequencing system being operated by the server subsystem 104 and authorize requests from the client subsystem operating the sequencing application according to the compatible version.

[0053] The monitoring subsystem 120 can select the next version of the sequencing system. In response to user input from client device 108, the monitoring subsystem 120 can select the next version of the sequencing system. The user input identifies the selected version of the server subsystem. User input can be sent in response to a query from the monitoring subsystem 120. The monitoring subsystem 120 can automatically select the next version based on versions previously received from the client subsystem. The monitoring subsystem 120 can select a version based on versions blocked and / or queued in the first request. For example, the monitoring subsystem 120 can select a version of server subsystem 104 to be loaded into memory that is compatible with a version identified in request 152 received from client subsystem 110b, which was previously determined to be incompatible. The monitoring subsystem 120 can continue to select versions based on the order in which requests have been blocked and / or queued. The monitoring subsystem 120 can select a version based on the number of requests that have been blocked and / or queued. For example, the monitoring subsystem 120 can select the next version to be loaded into the memory of the server subsystem 104 by identifying versions compatible with the maximum number of blocked or queued requests from the client subsystem.

[0054] Monitor subsystem 120 can communicate with one or more processes of server subsystem 104 to coordinate changes in the version of the sequencing system operating on server subsystem 104. In one example, monitor subsystem 120 can communicate with daemon 160 to restart one or more parts of the hardware and / or software to change the version of server subsystem 104. One or more layers (e.g., each layer) of the vertical solution stack of server subsystem 104 can be dismantled and rebuilt for the next version. Monitor subsystem 120 can send commands to daemon 160 to cause the daemon to delete one or more processes, drivers, and / or layers currently loaded into memory. Commands from monitor subsystem 120 can be received by one or more child processes (e.g., daemon 160) to cause one or more layers to dismantle the current version of the service by shutting down the service supporting the current version before switching to another version. Monitor subsystem 120 can send commands received by one or more child processes (e.g., daemon 160) to cause one or more layers to be rebuilt by restarting the service for the next version to support the next version. For example, the monitor subsystem 120 may send one or more commands to one or more subprocesses (e.g., daemon 160) that communicate with one or more other layers of the vertical solution stack to dismantle and rebuild services supported by each layer. One or more subprocesses (e.g., daemon 160) may reset the FPGA and / or load new programmable hardware into the FPGA to implement a complete solution that includes version changes in hardware and / or software.

[0055] Processes, drivers, and / or layers that are dismantled and / or rebuilt when a version changes can be predefined or dynamically selected. For example, monitor subsystem 120 can select processes, drivers, and / or layers to be dismantled and / or rebuilt based on previous and next versions of server subsystem 104. Each version of the sequencing system can be stored in memory along with a version file accessible by monitor subsystem 120 to identify portions of server subsystem 104 to be dismantled and / or built to support the next version of the sequencing system operated by server subsystem 104. Each version of the sequencing system may include metadata or other information that can be read by monitor subsystem for selecting processes, drivers, and / or layers of the vertical solution stack to be loaded into memory. For example, each version of the sequencing system can provide a list that monitor subsystem 120 can use to select processes, drivers, and / or layers to be loaded into memory for each version. Each list may include a version number corresponding to the version of the sequencing system for which the list is provided. The list may include the list version itself, as each list may have a different version. The manifest may include versions of one or more processes and / or drivers used to load into memory to build a vertical solution stack. For example, the manifest may include versions of daemon 160, daemon licensing process 163, and / or daemon huge page process 164 that support a version of server subsystem 104. The manifest may include driver versions for loadable kernel driver 162 and / or the location of kernel objects. For example, the location of kernel objects may include a version directory or alternative location (e.g., when multiple versions of kernel drivers are supported). The manifest may include versions of client subsystems compatible with a version of server subsystem 104 and / or sequencing applications operating on them. The manifest may include versions of partially reconfigured bitstream 168 and / or subsystems that can be loaded into it (e.g., mapper subsystem 122, sorter subsystem 124, and / or variant detector subsystem 126). The manifest may include a version of shell 170. Some processes, drivers, and / or layers may remain static from one version to another, which can support backward compatibility with legacy systems. For example, loadable kernel drivers 162 and / or shells 170 can remain static between versions to support processes in other layers of the vertical solution stack.

[0056] After the monitoring subsystem 120 selects the version of the sequencing system being operated by the server subsystem 104 and loads the processes, drivers, and / or layers of the selected version of the sequencing system, the process can be started and / or the driver can be loaded into the vertical solution stack to serve requests compatible with the selected version of the sequencing system. In one example, when the monitoring subsystem 120 determines that the version of the sequencing system running on the server subsystem 104 is compatible with the version of the sequencing application of the client subsystem 110b, the monitoring subsystem 120 can authorize the client subsystem 110b to access the server subsystem 104 and / or one or more processes on it. The monitoring subsystem 120 can authorize the client subsystem 110b to send a request 156 to the daemon 160 for access to the daemon 160 and / or have the request served by the server subsystem 104. After monitoring subsystem 120 determines that the version of client subsystem 110b receiving request 152 from it is compatible with the version of server subsystem 104, monitoring subsystem 120 may send authorization message 153 to client subsystem 110b to grant access to server subsystem 104 and / or daemon 160. The authorization message may include an acknowledgment in response to the request, or monitoring subsystem 120 may send an acknowledgment of receipt of each request without providing authorization. Authorized client subsystem 110b may register in memory with monitoring subsystem 120 as authorized to be served by server subsystem 104. Authorization message 153 may include an access key for accessing server subsystem 104 and / or daemon 160. The access key may also be provided to daemon 160 in a notification message informing daemon 160 that client subsystem 110b has been authorized, enabling daemon 160 to recognize the authorized client subsystem 110b. For example, the monitoring subsystem 120 can provide the daemon 160 with the identifier of the client subsystem 110b or other information associated with the client subsystem 110b to indicate that the client subsystem 110b has been authorized. The daemon 160 can receive request 156 and recognize that the request is received from an authorized client subsystem 110b (e.g., based on the access key or other information in request 156). After the daemon 160 recognizes that it is receiving request 156 from an authorized client subsystem 110b, the daemon 160 can establish a connection with the client subsystem 110b, register the client subsystem 110b in memory, and begin servicing request 156 by communicating with other processes, drivers, and / or layers of the vertical solution stack in the server subsystem 104. For example, the daemon 160 can use an inter-process communication (IPC) messaging protocol over BSD sockets to communicate with its clients. Each client can register with the daemon 160 by connecting to a Unix domain socket address.The channel can be open so that clients can send messages to daemon 160, which can then respond to the message after fulfilling the client's request.

[0057] Figure 2 This is a flowchart depicting an exemplary process 200 for monitoring a version of a server subsystem and processing requests from a compatible client subsystem. One or more portions of process 200 may be executed by one or more computing devices or systems. For example, one or more portions of process 200 may be executed by one or more server devices, one or more sequencing devices, and / or one or more client devices. One or more portions of process 200 may be stored in memory as computer-readable or machine-readable instructions executable by the processor of one or more computing devices. One or more portions of process 200 may be executed by one or more subsystems operating on client devices, sequencing devices, and / or server devices. For example, one or more portions of the process may be executed by a client subsystem, a server subsystem, and / or a monitoring subsystem, as described herein. Although portions of process 200 may be described herein as being executed by a monitoring subsystem, process 300 or portions thereof may be executed by another subsystem operating on a computing device or distributed across multiple computing devices, such as one or more client computing devices, one or more sequencing devices, and / or one or more server computing devices.

[0058] Process 200 can begin at point 202. For example... Figure 2As shown, at 202, the monitoring subsystem can receive one or more requests from one or more client subsystems. These requests can be received individually or in batches for processing by the sequencing system of the server subsystem. The request may include a product identifier, a version identifier, and / or other information associated with the client subsystem from which the request is received. At 204, the monitoring subsystem can determine the version associated with the client subsystem from which the request is received. For example, the monitoring subsystem can determine the version based on the product identifier, version identifier, or other information associated with the client subsystem. At 206, the monitoring subsystem can determine whether the version associated with the server subsystem is compatible with the version associated with the client subsystem. For example, the monitoring subsystem can receive an indication of the version of the sequencing system operating on the server subsystem to determine whether the version of the sequencing system is compatible with the version of the sequencing application operating on the client subsystem. The indication of the version of the sequencing system operating on the server subsystem can be received from a daemon operating on the server subsystem (e.g., in response to a request). Compatible versions can be indicated by the same version number / identifier, or by a different version number / identifier indicated in memory as compatible with one or more features of another version number / identifier. A version can be a version of one or more processes, drivers, and / or layers in a vertical solution stack. If the version associated with the server subsystem and the version associated with the client subsystem are compatible, at 210, the client subsystem may be granted access to the server subsystem and / or one or more processes on it used to process the request. The request can be processed by loading one or more bioinformatics subsystems (e.g., mapper subsystem, sorter subsystem, and / or variant detector subsystem) into one or more FPGAs for performing secondary and / or tertiary analysis of the sequencing data.

[0059] If the version associated with the server subsystem and the version associated with the client subsystem are incompatible, at 208, the monitoring subsystem may cause the client subsystem to wait for the request to be processed. For example, the monitoring subsystem may block the request to prevent access to the server subsystem and / or queue the request for later processing. At 212, the monitoring subsystem may determine if an additional request has been received while the server subsystem is operating its sequencing system with the current version. For example, while the server subsystem is processing one or more requests from a client subsystem that has already been granted access at 210 and / or before the server subsystem has changed its version, additional requests may continue to be received by the monitoring subsystem. If the monitoring subsystem receives an additional request at 212, the request may be processed at 204 to determine the version associated with the client subsystem so as to determine at 210 whether access to the request should be granted. At 214, the monitoring subsystem may determine if the server subsystem is idle. The server subsystem can be determined to be idle when one or more processes operating the sequencing system on it are determined to be idle. The monitoring subsystem may request the status of one or more processes of the server subsystem. In one example, the monitoring subsystem can send messages to the server subsystem's daemon to determine the processing status of requests from client subsystems. The daemon can send a termination signal when processing requests from one or more client subsystems is complete. The monitoring subsystem can monitor the status of requests and identify termination signals for each previously authorized request. If the server subsystem is determined to still be active and processing requests from client subsystems, the monitoring subsystem can continue monitoring for additional requests at 212 and / or monitor the server subsystem at 214 to identify idle states.

[0060] If the server subsystem and / or one or more processes operating on it are determined to be idle, at 215, the monitoring subsystem may determine whether to change the version associated with the server subsystem. The monitoring subsystem may identify an instruction to change the version associated with the server subsystem before making a change. For example, if an additional request associated with an incompatible version that has been blocked and / or queued has been received from the client subsystem, the monitoring subsystem may determine to change the version associated with the server subsystem. The monitoring subsystem may also, or alternatively, determine to change the version associated with the server subsystem if user input instructing the monitoring subsystem to change the version of the server subsystem has been received from a sequencing application operating on a client device. If the monitoring subsystem decides to maintain the version associated with the server subsystem (e.g., because no instruction to change the version associated with the server subsystem has been identified), process 200 may end.

[0061] If the monitoring subsystem decides to change the version associated with the server subsystem, at 216, the monitoring subsystem can cause the server subsystem to change the version used to handle requests from client subsystems compatible with another version of the server subsystem. The monitoring subsystem can send commands to the server subsystem and / or one or more processes operating on it to cause the server subsystem to stop executing one or more processes before changing the version. The monitoring subsystem can also send commands to the server subsystem and / or one or more processes operating on it to cause the server subsystem to change the version used to handle requests from client subsystems. Commands can be sent to daemons operating on the server subsystem to cause the versions of one or more processes, drivers, and / or layers in the vertical solution stack to change according to the next version. The next version can be selected by the monitoring subsystem. For example, the next version can be selected based on user input received from client devices operating the sequencing application. The next version can also be automatically selected, or alternatively, based on the version of previously blocked and / or queued requests from client subsystems. The monitoring subsystem may select a version based on the versions blocked and / or queued in the first request, or the order in which blocked and / or queued requests are received. The monitoring subsystem may also select a version based on the number of blocked and / or queued requests. For example, the monitoring subsystem may select the next version to be loaded into the server subsystem's memory by identifying a version compatible with the maximum number of blocked and / or queued requests from the client subsystem.

[0062] After the version associated with the server subsystem has been changed to the next version, the monitoring subsystem may send a command to the server subsystem and / or one or more processes (e.g., daemons) on it to begin execution. At 218, the monitoring subsystem may determine whether a previous request that has been blocked and / or queued for processing by the server subsystem has been received. If no previous request for processing by the server subsystem has been received, process 200 may terminate. If a previous request that has been blocked and / or queued has been received, at 204, the monitoring subsystem may determine whether the version of one or more previous requests is compatible with the server subsystem. The monitoring subsystem may send a message to the client subsystem to notify it that the server subsystem is ready to serve its request. The monitoring subsystem may send a request requiring the client subsystem to resend its request for processing. At 210, the monitoring subsystem may grant access to process requests associated with client subsystems determined to be compatible. After the current version associated with the server subsystem has been changed, the monitoring subsystem may continue to block and / or queue requests that are incompatible with that current version. The process can end after each request in the request has been processed as described in this article.

[0063] Figure 3 This is a block diagram illustrating an exemplary computing device 300 (or computing system). One or more computing devices (such as computing device 300) may implement one or more features for monitoring and / or changing a version of a sequencing system to serve requests from sequencing applications, as described herein. For example, computing device 300 may include... Figure 1A One or more of the sequencing device 114, client device 108, and / or server device 102 shown. Figure 3 As shown, computing device 300 may include a processor 302, a memory 304, a storage device 306, an I / O interface 308, and a communication interface 310, which can be communicatively coupled via communication infrastructure 312. Computing device 300 may include... Figure 3 The components shown have fewer or more components.

[0064] Processor 302 may include hardware for executing instructions, such as those that constitute a computer application or system. In the example, to execute instructions for operations as described herein, processor 302 may retrieve (or fetch) instructions from internal registers, internal cache, memory 304, or storage device 306, and decode and execute the instructions. Memory 304 may be volatile or non-volatile memory for storing data, metadata, computer-readable or machine-readable instructions, and / or programs executed by the processor to operate as described herein. Storage device 306 may include a storage means for storing data or instructions for performing the methods described herein, such as a hard disk, flash drive, or other digital storage device.

[0065] I / O interface 308 allows a user to provide input to computing device 300, receive output from computing device, and / or otherwise send and receive data to and from computing device. I / O interface 308 may include a mouse, keypad or keyboard, touchscreen, camera, optical scanner, network interface, modem, other known I / O devices, or combinations of such I / O interfaces. I / O interface 308 may include one or more devices for presenting output to a user, including but not limited to a graphics engine, display (e.g., a screen), one or more output drivers (e.g., display drivers), one or more audio speakers, and one or more audio drivers. I / O interface 308 may be configured to provide graphical data to the display for presentation to the user. The graphical data may represent one or more graphical user interfaces and / or any other graphical content.

[0066] Communication interface 310 may include hardware, software, or both. In any case, communication interface 310 may provide one or more interfaces for communication (such as, for example, packet-based communication) between computing device 300 and one or more other computing devices and / or networks. Communication may be wired or wireless. By way of example and not limitation, communication interface 310 may include a network interface controller (NIC) or network adapter for communicating with Ethernet or other wired networks, or a wireless NIC (WNIC) or wireless adapter for communicating with wireless networks such as Wi-Fi.

[0067] Additionally, the communication interface 310 facilitates communication with various types of wired or wireless networks. The communication interface 310 also facilitates communication using various communication protocols. The communication infrastructure 312 may also include hardware, software, or both, that couples the components of the computing device 300 to each other. For example, the communication interface 310 may use one or more networks and / or protocols to enable multiple computing devices connected through a particular infrastructure to communicate with each other to perform one or more aspects of the processes described herein. For illustration, the sequencing process may allow multiple devices (e.g., client devices, sequencing devices, and server devices) to exchange information such as sequencing data and error notifications.

[0068] In addition to what has been described herein, the methods and systems may also be implemented in computer programs, software, or firmware incorporated in one or more computer-readable media for execution by, for example, a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and transient / non-transitory computer-readable storage media. Examples of transient / non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), removable magnetic disks, and optical media such as CD-ROM disks and digital versatile disks (DVDs).

[0069] While this disclosure has been described according to certain embodiments and commonly associated methods, changes and substitutions to the embodiments and methods will be apparent to those skilled in the art. Therefore, the above description of exemplary embodiments does not limit this disclosure. Other changes, substitutions, and modifications are possible without departing from the spirit and scope of this disclosure.

Claims

1. A system comprising: At least one memory, wherein computer-readable instructions are stored in the at least one memory; and At least one processor, the at least one processor being configured to perform the following operations in response to the computer-readable instructions: The system receives requests from the client subsystem via the monitor subsystem, wherein the requests are requests to perform secondary or tertiary analysis of sequencing data, and wherein the requests include a version associated with the client subsystem. Determine the first version of the server subsystem to be implemented to serve the request; It is determined that the version associated with the client subsystem is incompatible with the first version associated with the server subsystem currently implemented to serve the request; In response to the determination that the version associated with the client subsystem is incompatible with the first version associated with the server subsystem, access to the server subsystem by the client subsystem is prevented. After processing each request from the client subsystem associated with the compatible version, the server subsystem is identified as idle; This causes the server subsystem to perform changes from the first version to the second version; Determine that the second version associated with the server subsystem and the version associated with the client subsystem are compatible; as well as The client subsystem is allowed to access the server subsystem to serve the request.

2. The system of claim 1, wherein the request from the client subsystem is a first request, and wherein the client subsystem is a first client subsystem, and the at least one processor is further configured to perform the following operations in response to the computer-readable instructions: The monitoring subsystem receives a second request from the second client subsystem, wherein the second request includes a version associated with the second client subsystem; When the server subsystem operates with the first version, it is determined that the version associated with the second client subsystem is compatible with the first version associated with the server subsystem; and The second request allows the server subsystem to be accessed by the second client subsystem.

3. The system of claim 1, wherein each version of the server subsystem includes different features of bioinformatics components associated with processing different requests for the secondary analysis or the tertiary analysis.

4. The system of claim 1, wherein different bioinformatics components are utilized by loading different bioinformatics components into one or more field-programmable gate arrays (FPGAs).

5. The system of claim 1, wherein the change from the first version to the second version includes removing and building at least one software layer in the vertical solution stack.

6. The system of claim 5, wherein the first version and the second version support loading different bioinformatics components onto one or more FPGAs to support the same or different sequencing tasks.

7. The system of claim 6, wherein the sequencing task includes a task performed for the secondary or tertiary analysis of the sequencing data.

8. The system of claim 1, wherein the secondary analysis or the tertiary analysis comprises alignment, sorting or variant detection based on the sequencing data.

9. The system of claim 1, wherein the monitor subsystem is a daemon process.

10. The system of claim 1, wherein the server subsystem is a daemon, and wherein the server subsystem is configured to manage hardware on the system to serve sequencing applications operating on one or more client subsystems.

11. The system of claim 10, wherein the daemon process is one of a plurality of predefined daemons in the server subsystem.

12. The system of claim 1, wherein the at least one processor is configured to prevent the server subsystem from being accessed by the client subsystem in response to the request, further comprising the at least one processor being configured to: Prevent the access key from being transmitted to the client subsystem or prevent the establishment of a connection between the client subsystem and the server subsystem.

13. The system of claim 1, wherein the at least one processor is configured to allow the server subsystem to be accessed by the client subsystem, further comprising the at least one processor being configured to: The monitoring subsystem provides the access key to the client subsystem; and The monitoring subsystem notifies the server subsystem that the access key has been provided to the client subsystem.

14. The system of claim 13, wherein the at least one processor is configured to notify the server subsystem, and the at least one processor is further configured to provide the access key to the server subsystem.

15. The system of claim 13, wherein the processor is further configured via the computer-readable instructions to perform the following operations: The client subsystem receives a message indicating that it is blocked; and Waiting to receive an indication from the monitor subsystem via the client subsystem that the request can be processed.

16. The system of claim 13, wherein the processor is further configured via the computer-readable instructions to perform the following operations: The access key is received via the client subsystem; and A message including the access key for establishing a connection with the server subsystem is transmitted to the server subsystem.

17. The system of claim 1, wherein the processor is further configured via the computer-readable instructions to send an acknowledgment to the client subsystem in response to the request.

18. The system of claim 1, wherein the processor is further configured via the computer-readable instructions to receive the request from the client subsystem via a socket and to grant access to the server subsystem via the socket via an access key.

19. The system of claim 1, wherein the processor is further configured via the computer-readable instructions to perform the following operations: The monitor subsystem monitors signals from at least one subprocess; Detecting terminal signals via at least one subprocess; and Automatically restart at least one of the child processes.

Images