State-based machine-based scripting applications and systems

Abstract

We provide state-machine-based scripting applications and systems. [Solution] A system comprising multiple scriptable devices and exposing their interfaces, comprising a medium for storing data indicating the conversion between a scriptable device and a corresponding application command, which includes one or more inputs for providing a mapped device operation from a scriptable device to a corresponding device, and a medium for storing data indicating the conversion between the device operation and the corresponding application command. The medium stores scripts, which include a set of device operations having a corresponding scriptable device from a scriptable device. The system also comprises a computer that repeatedly pre-forms an operation cycle, which includes determining whether an application command should be executed and, when it should be executed, generating a globally unique identifier corresponding to the command and adding the globally unique identifier and the corresponding device operation to a log.

Description

Background Art

[0001] The subject matter discussed in this section should not be construed as prior art merely by virtue of its mention in this section. Similarly, problems mentioned in this section, or problems associated with subject matter provided as background, should not be construed as having been previously recognized in the prior art. The subject matter in this section merely represents different approaches, which approaches may themselves also correspond to implementations of the claimed technology.

[0002] Some currently available techniques for developing applications, such as techniques used in manufacturing and formulating polynucleotide therapeutics (e.g., mRNA therapeutics, etc.), may be incapable of integrating external scripts, such as scripts that can be created by process engineers. Additionally, applications created using such techniques may provide insufficient traceability when errors are encountered during execution or elsewhere. Summary of the Invention

[0003] An improved framework can improve both the development and operation of applications. Structuring an application as a modular non-blocking state machine can advance these goals, and incorporating features such as integration of external scripts and logging of data and application activity can improve traceability and, where applicable, regulatory compliance. Described herein are systems and methods that can be used in creating and operating such applications, including those that can be applied to controlling systems for polynucleotide manufacturing.

[0004] The implementation form relates to a system, which includes: a plurality of scriptable devices, each scriptable device exposing an interface and adapted to perform a predetermined action based on inputs provided through that interface; a non-temporary computer-readable medium storing data that, for each of a plurality of mapped device operations, indicates one or more inputs to be provided to the corresponding device from the plurality of scriptable devices when performing that device operation, and a conversion between the device operation and the corresponding application command; a plurality of scripts, each script having a corresponding scriptable device from the plurality of scriptable devices and comprising a set of device operations; and a computer for performing an action, the action being to perform an action cycle, the action cycle including determining whether an application command should be executed, generating a globally unique identifier corresponding to the application command based on the determination that the application command should be executed, and adding the globally unique identifier corresponding to the application command and the device operation corresponding to the application command to a log; and repeating the action cycle one or more times.

[0005] In some implementations of the system described in the preceding paragraph of this overview, the actions performed by the computer include, for each of the multiple scriptable devices, determining when each device operation from each script for which that device is a corresponding scriptable device is included in the mapped multiple device operations, and generating an error message for each script that contains a device operation for which that device is a corresponding scriptable device and is determined not to be included in the mapped multiple device operations.

[0006] In some implementations of the system, such as those described in either the second or third paragraph of this overview, the non-temporary computer-readable medium further stores data indicating a corresponding device module definition that defines a device module object for executing the corresponding application command for each of the mapped device operations, and for each of the mapped device operations, data indicating the conversion between the device operation and the corresponding application command is included in the device module definition corresponding to that device operation.

[0007] In some implementations of the system as described in the preceding paragraph of this overview, the operation cycle may include receiving execution commands from multiple scripts to execute the scripts; in response to receiving the execution commands, verifying that each device operation from the multiple device operations included in the script is included in the multiple device operations to which it is mapped; and verifying that a device operation with any associated parameters is executable by a device module defined by the device module definition corresponding to that device operation.

[0008] In some implementations of the system, such as those described in any of paragraphs 2 through 5 of this summary, determining whether an application command should be executed when performing an operational cycle may include enqueuing the application command in a queue corresponding to a device corresponding to the device operation of the application command, where the device is referred herein to as the device corresponding to the application command, and checking the state of the thread corresponding to the device corresponding to the application command.

[0009] In some implementations of the system, such as those described in any of paragraphs 2 through 5 of this overview, determining whether an application command should be executed when performing an operation cycle involves receiving instructions via a graphical user interface to control a device corresponding to the device operation of the application command.

[0010] Another implementation form relates to a method, the method comprising: accessing a non-temporary computer-readable medium storing module class definitions; obtaining a plurality of device object definitions, each device object definition corresponding to a physical device, inheriting a module class definition, and specifying for each of a plurality of commands executable by the corresponding physical device of the device object definition, a state corresponding to that command, one or more actions to be performed in the state corresponding to that command, and one or more inputs to be issued to the physical device corresponding to that device; obtaining a plurality of intermediate module definitions, each intermediate module definition inheriting a module class definition, and each containing a reference to a set of device objects corresponding to a device object definition; obtaining a module manager definition, each module manager definition inheriting a module class definition, and each containing a reference to a plurality of intermediate modules corresponding to an intermediate module definition; and launching an application. Invoking an application includes, for each device object definition, allocating memory for the device object corresponding to that device object definition, the device object corresponding to that device object definition having a command queue, allocating the corresponding thread to track the current state of the device object corresponding to that device object definition, to perform one or more actions specified for a command when the current state of the device object corresponding to that device object definition is the same as the state specified in that device object definition, and to execute instructions to determine whether to update the current state of the device object corresponding to that device object definition based on the existence and priority of commands in the command queue contained in the device object object definition, and for each intermediate module definition, allocating memory for the intermediate module corresponding to that intermediate module definition, and assigning the corresponding thread,This includes assigning instructions to execute commands to send commands to device objects that have references contained in the intermediate module corresponding to that intermediate module definition.

[0011] In some implementations of the method described in the preceding paragraph of this overview, each device object definition specifies a set of actions to be performed while the device object defined by that device object definition is idle, and for each device object definition, the corresponding thread is for performing the set of actions specified to be performed while the device object defined by that device object definition is idle.

[0012] In some implementations of the method described in the preceding paragraph of this overview, multiple device object definitions include a temperature controller device object definition, and a set of actions specified by the temperature controller device object definition to be performed while the device object defined by the temperature controller device object definition is idle includes checking the system temperature.

[0013] In some implementations of the method described in any of paragraphs 8 through 10 of this overview, for each device object definition, all loops contained within that device object definition have deterministic termination.

[0014] In some implementations of the method described in any of paragraphs 8 through 11 of this overview, each data object defined by a definition that inherits a module class definition is a state machine having states including idle, stopped, shut down, and boot-up states, and also includes a command queue.

[0015] In some implementations of the methods described in any of paragraphs 8 through 12 of this overview, for each device object definition, the module manager definition includes instructions for controlling the physical device corresponding to that device object definition by action, the action including instantiating a command object and passing the command object to an intermediate module defined by an intermediate module definition, the intermediate module definition including a reference to the device object corresponding to that device object definition, the command object is defined by a command object definition, and both the command object definition and the module class definition inherit from the base object definition.

[0016] In some implementations of the methods described in the preceding paragraph of this overview, the base object definition includes instructions for generating a unique identifier for an object defined by a definition that inherits the base object definition, and for storing the unique identifier as private data in the object, whenever such an object is instantiated.

[0017] Another implementation is a system which stores a plurality of scriptable devices, each scriptable device being a physical device, exposing an interface, and adapted to perform a predetermined action based on inputs provided through that interface; a non-temporary computer-readable medium which, for each of a plurality of mapped device operations, provides one or more inputs to the corresponding device from the plurality of scriptable devices when performing that device operation, a conversion between the device operation and a corresponding application command, a plurality of intermediate module definitions, each intermediate module definition containing a reference to a set of device objects corresponding to one of the scriptable devices; and a plurality of scripts, each script having a corresponding scriptable device from the plurality of scriptable devices and comprising a set of device operations. A time-sensitive computer-readable medium and a computer for performing an action, the action being to launch an application, the launch of the application including, for each scriptable device, allocating memory for the device object corresponding to that scriptable device, assigning the corresponding thread to execute instructions to track the current state of the device object corresponding to that device object definition, to perform one or more actions specified for that command when the current state of the device object corresponding to that device object definition is the same as the state specified in that device object definition, and to determine whether to update the current state of the device object corresponding to that device object definition based on the existence and priority of commands in the command queue contained in the device object corresponding to that device object definition, and for each intermediate module definition, allocating memory for the intermediate module corresponding to that intermediate module definition, and assigning the corresponding thread,A computer comprising: a computer, which includes: starting up, assigning to execute an instruction to send a command to a device object having a reference contained in an intermediate module corresponding to the intermediate module definition; performing an operation cycle, the operation cycle including determining whether an application command should be executed, generating a globally unique identifier corresponding to the application command based on the determination that the application command should be executed, and adding the globally unique identifier corresponding to the application command and the device operation corresponding to the application command to a log; and repeating the operation cycle one or more times.

[0018] In some implementations of the system described in the preceding paragraph of this overview, the actions performed by the computer include, for each of the multiple scriptable devices, determining when each device operation from each script for which that device is a corresponding scriptable device is included in the mapped multiple device operations, and generating an error message for each script that contains a device operation for which that device is a corresponding scriptable device and is determined not to be included in the mapped multiple device operations.

[0019] In some implementations of the system, such as those described in either paragraph 15 or 16 of this overview, the non-temporary computer-readable medium further stores data indicating a corresponding device module definition that defines a device module object for executing the corresponding application command for each of the mapped device operations, and for each of the mapped device operations, data indicating the conversion between the device operation and the corresponding application command is included in the device module definition corresponding to that device operation.

[0020] In some implementations of the system as described in the preceding paragraph of this overview, the operation cycle may include receiving execution commands from multiple scripts to execute the scripts; in response to receiving the execution commands, verifying that each device operation from the multiple device operations included in the script is included in the multiple device operations to which it is mapped; and verifying that a device operation with any associated parameters is executable by a device module defined by the device module definition corresponding to that device operation.

[0021] In some implementations of the system, such as those described in paragraphs 15 through 18 of this overview, the operation cycle, based on determining that an application command should be executed, includes instantiating a command object corresponding to that application command and passing the command object to an intermediate module, where the command object, each device object, and each intermediate module instantiate a class that inherits a common base object definition.

[0022] In some implementations of the system, as described in the preceding paragraph of this overview, the base object definition includes instructions for generating a unique identifier for an object defined by a definition that inherits the base object definition, and for storing that unique identifier as private data in the object, whenever such an object is instantiated.

[0023] In some implementations of the system, such as those described in paragraphs 15 through 20 of this overview, for each scriptable device, all loops contained within the thread corresponding to that scriptable device have deterministic termination.

[0024] It should be understood that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided that such concepts do not contradict each other) are part of the inventive subject matter disclosed herein and are contemplated to achieve the advantages described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Details of one or more implementations are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will be apparent from the description, the drawings, and the claims. [Figure 1] 1 is a schematic diagram depicting an example of a system including a microfluidic process chip. [Figure 2] 2 depicts an exemplary architecture that can be used when implementing an application. [Figure 3] 3 depicts an exemplary process that may be performed in the execution of a module implemented as a state machine. [Figure 4] 4 depicts an exemplary process that may be performed in the execution of a module implemented as a state machine. [Figure 5] 5 depicts an exemplary process that may be implemented and used when converting device operations in a script into uniquely identifiable application commands. [Figure 6] 6 depicts an exemplary process that may be performed to generate, maintain, and operate a graphical user interface. [Figure 7] 7 depicts an exemplary process that can be used when creating a state machine-based module. [Figure 8] 8 depicts an exemplary process that can be used to define operations that may be performed over multiple operating cycles of a state machine. [Figure 9] 9 depicts an exemplary process that can be used to define operations that may be performed over multiple operating cycles of a state machine. [Figure 10]This illustrates an exemplary process that can be used to define actions that may occur over multiple operating cycles of a state machine. [Figure 11] This describes an exemplary architecture that may be used when implementing the application. [Modes for carrying out the invention]

[0026] In some embodiments, apparatus and methods for developing applications that enable integration with external scripts and provide traceability in case of errors are disclosed herein. In particular, these apparatus and methods may provide an object-oriented framework that supports modularity and is configured to reuse integrated structures representing individual devices in complex processes. Objects in such a framework may include objects adapted to run as state machines and objects adapted to encode commands from scripts. These objects may also inherit a base class that provides the ability to automatically generate unique identifiers that can later be used in debugging and / or other error correction. Applications developed using embodiments of the disclosed technology may be used for a variety of purposes, including the synthesis of patient-specific therapeutics, including compounding at point of care (e.g., hospitals, clinics, pharmacies, etc.).

[0027] I. Terminology Throughout this specification and the accompanying claims, unless otherwise interpreted in context, the word “comprise,” and variations such as “comprises” and “comprising,” mean that various components may be used together in methods and articles (e.g., compositions and apparatus including devices and methods). For example, the term “comprising” will be understood to mean including any described element or step, but not excluding any other element or step. Generally, any apparatus and method described herein should be understood to be comprehensive, but all or a subset of components and / or steps may be alternatively exclusive and may be expressed as “consisting of” or alternatively “essentially consisting of” various components, steps, subcomponents, or substeps.

[0028] As used herein, the singular forms "a," "an," and "the" are intended to include the plural form unless the context explicitly indicates otherwise. As used herein, the term "and / or" includes any combination of one or more of the related enumerated items and all combinations thereof, and may be abbreviated as " / ".

[0029] Spatially relative terms such as “under,” “below,” “lower,” “over,” and “upper” may be used herein to facilitate descriptions of the relationship between one element or feature and another, as illustrated in the figures. It will be understood that spatially relative terms are intended to encompass different orientations of a device in use or operation, in addition to the orientation depicted in the figures. For example, if the device in the figure is inverted, an element described as “under” or “beneath” another element or feature will be oriented “over” the other element or feature. Thus, the term “under” may encompass both upward and downward orientations. The device may be oriented in other ways (rotated by 90 degrees or in other orientations), and the spatially relative descriptors used herein will be interpreted accordingly. Similarly, terms such as “upward,” “downward,” “vertically,” and “horizontally” are used herein for descriptive purposes only, unless specifically indicated otherwise.

[0030] In this specification, where a feature or element is referred to as being "on top of" another feature or element, it may be directly on top of the other feature or element, or there may be an intervening feature and / or element. In contrast, where a feature or element is referred to as being "directly on top of" another feature or element, there is no intervening feature or element. Where a feature or element is referred to as being "connected," "attached," or "joined" to another feature or element, it may be directly connected to, attached to, or joined to the other feature or element, or there may be an intervening feature or element. In contrast, where a feature or element is referred to as being "directly connected," "directly attached," or "directly joined" to another feature or element, there is no intervening feature or element. Features and elements described or illustrated in relation to one embodiment may be applicable to other embodiments. It will also be understood by those skilled in the art that a reference to a structure or feature positioned "adjacent" to another feature may have a portion that overlaps with or lies beneath the adjacent feature.

[0031] Where used herein and in the claims, including where used in examples, all numbers may be read as if preceded by the words “about” or “approximately,” even if those words do not explicitly appear, unless otherwise expressly specified. The phrases “about” or “approximately” may be used when describing magnitude and / or location to indicate that the described value and / or location is within a reasonable expected range of the value and / or location. For example, a number may have a value that is ±0.1% of the described value (or range of values), ±1% of the described value (or range of values), ±2% of the described value (or range of values), ±5% of the described value (or range of values), ±10% of the described value (or range of values), and so on. Any number given herein should be understood to include about or approximately that value unless otherwise indicated in the context. For example, if the value “10” is disclosed, “about 10” is also disclosed. Any number range enumerated herein is intended to include all subranges contained therein.

[0032] Furthermore, when a value is disclosed as being "less than or equal to" that value, it is understood that "greater than or equal to" that value and the possible range between the values ​​are also disclosed, so as can be appropriately understood by those skilled in the art. For example, if the value "X" is disclosed, then "less than or equal to X" and "greater than or equal to X" (for example, if X is a number) are also disclosed. Also, throughout this application, it is understood that data is provided in several different forms, and this data represents endpoints and starting points, as well as ranges of any combination of data points. For example, if a specific data point "10" and a specific data point "15" are disclosed, it is understood that greater than 10 and 15, 10 and 15 or greater, less than 10 and 15, 10 and 15 or less, and equal to 10 and 15 are considered to be disclosed as well as between 10 and 15. It is also understood that each unit between two specific units is also disclosed. For example, if 10 and 15 are disclosed, then 11, 12, 13, and 14 are also disclosed.

[0033] The terms “first” and “second” may be used herein to describe various features / elements (including steps), but these features / elements should not be limited by these terms unless the context indicates otherwise. These terms are used to distinguish one feature / element from another and do not indicate a particular order unless specifically pointed out. Thus, without departing from the teachings of the invention, the first feature / element discussed below may be called the second feature / element, and similarly, the second feature / element discussed below may be called the first feature / element.

[0034] As used herein, the terms “system,” “apparatus,” and “device” are to be interpreted as interchangeable. Each system, apparatus, and device may comprise multiple components having various kinds of structural and / or functional relationships with one another.

[0035] As used herein, “based on” may be read to indicate that something is determined at least in part on what is indicated as “based on.” “Exclusively based on” may be read to indicate that something must be determined entirely by what is indicated as “exclusively based on.”

[0036] II. Overview of Exemplary Systems for State-Machine-Based Control Figure 1 illustrates examples of various components that may be incorporated into system (100). In this example, system (100) includes a housing (103) surrounding a seating fixture (115) capable of removably holding one or more microfluidic process chips (111). In other words, system (100) includes a chip receiving component configured to removably accommodate the process chip (111), the process chip (111) itself defining one or more microfluidic channels or fluid pathways. Components of system (100) (e.g., within the housing (103)) that fluidically interact with the process chip (111) may include fluid channels or pathways that are not necessarily considered microfluidic (e.g., such fluid channels or pathways are larger than the microfluidic channels or fluid pathways within the process chip (111)). In some versions, the process chip (111) is provided and used as a single-use device, and the rest of system (100) is reusable. The housing (103) may take the form of a chamber, enclosure, or the like, with an opening that can be closed (e.g., via a lid or door) to thereby seal the interior. The housing (103) may surround a temperature controller and / or be configured to surround a temperature-controlled environment (e.g., a refrigeration unit). The housing (103) may form a sterile barrier. In some modifications, the housing (103) may form a humidified or humidity-controlled environment. In addition, or alternatively, the system (100) may be located within a cabinet (not shown). Such a cabinet may provide a temperature-controlled (e.g., refrigerated) environment. Such a cabinet may also provide air filtration and airflow control to facilitate the maintenance of reagents at a desired temperature throughout the manufacturing process. In addition, such a cabinet may be equipped with a UV lamp for sterilization of the process tip (111) and other components of the system (100). Other desirable features may be incorporated into the cabinet housing the system (100).

[0037] In some scenarios, the assembly formed by the housing (103) and the components of the system (100) located within the housing (103) without the process chip (111) may be considered a “device”. Although the controller (121) and user interface (123) are shown in Figure 1 as being outside the housing (103), the controller (121) and user interface (123) may actually be located within or on the housing (103) and thus may form part of the device. As will be described in more detail below, this device may detachably receive the process chip (111) via a seating fixture (115). Once the process chip (111) is seated within the seating fixture (115), the device and the process chip (111) work together to form the system (100). When the process chip (111) is removed from the seating fixture (115), the remaining portion of the system (100) may be considered “equipment.” Equipment, system (100), and process chip (111) may each be considered “apparatus.” Thus, the term “apparatus” may be read to include equipment itself, process chip (111) itself, a combination of equipment and process chip (111), any other combination of components of system (100), or any other substitution of system (100) or its components.

[0038] The seating mount (115) may be configured to secure the process chip (111) using one or more pins or other components configured to hold the process chip (111) in a fixed and predefined orientation. Thus, the seating mount (115) can facilitate the holding of the process chip (111) in a proper position and orientation relative to other components of the system (100). In this embodiment, the seating mount (115) is configured to hold the process chip (111) in a horizontal orientation so that the process chip (111) is parallel to the ground.

[0039] In some modifications, the thermal control unit (113) is located adjacent to the seating mount (115) and can modulate the temperature of any process chip (111) mounted within the seating mount (115). The thermal control unit (113) may include thermoelectric components (e.g., a Peltier element) and / or one or more heat sinks for controlling the temperature of all or part of any process chip (111) mounted within the seating mount (115). In some modifications, two or more thermal control units (113) may be included, for example, to separately regulate the temperature of different regions of one or more regions of the process chip (111). The thermal control unit (113) may include one or more thermal sensors (e.g., thermocouples) that can be used for feedback control of the process chip (111) and / or the thermal control unit (113).

[0040] As shown in Figure 1, the fluid interface assembly (109) connects the process chip (111) to a pressure source (117), thereby providing one or more pathways for positively or negatively pressurized fluids (e.g., gases) to communicate from the pressure source (117) to one or more internal regions of the process chip (111), as will be described in more detail below. Although only one pressure source (117) is shown, the system (100) may include two or more pressure sources (117). In some scenarios, pressure may be generated by one or more sources other than the pressure sources (117). For example, one or more vials in the reagent storage frame (107) or other fluid sources may be pressurized. In addition, or alternatively, reactions and / or other processes performed on the process chip (111) may generate additional fluid pressure. In this embodiment, the fluid interface assembly (109) also connects the process chip (111) to the reagent storage frame (107), thereby providing one or more pathways through which liquid reagents and the like communicate from the reagent storage frame (107) to one or more internal regions of the process chip (111), as will be described in more detail below.

[0041] In some versions, pressurized fluid (e.g., gas) from at least one pressure source (117) reaches the fluid interface assembly (109) via the reagent storage frame (107), such that the reagent storage frame (107) includes one or more components interposed in the fluid path between the pressure source (117) and the fluid interface assembly (109). In some versions, one or more pressure sources (117) are directly coupled to the fluid interface assembly so that positive pressure fluid (e.g., positive pressure gas) or negative pressure fluid (e.g., suction gas or other negative pressure gas) bypasses the reagent storage frame (107) and reaches the fluid interface assembly (109). Regardless of whether the fluid interface assembly (109) intervenes in the fluid path between the pressure source (117) and the fluid interface assembly (109), the fluid interface assembly (109) may be removably coupled to the rest of the system (100) so that at least a portion of the fluid interface assembly (109) can be removed for sterilization between uses. As will be described in more detail below, the pressure source (117) may selectively pressurize one or more chamber regions on the process tip (111). In addition, or alternatively, the pressure source may also selectively pressurize one or more vials or other fluid storage containers held by the reagent storage frame (107).

[0042] The reagent storage frame (107) is configured to accommodate a plurality of fluid sample holders, each of which may hold a fluid vial configured to hold a reagent (e.g., nucleotide, solvent, water, etc.) for delivery to the process chip (111). In some versions, one or more fluid vials or other storage containers within the reagent storage frame (107) may be configured to receive products from within the process chip (111). In addition, or alternatively, a second process chip (111) may receive products from within the first process chip (111) so that one or more fluids are transferred from one process chip (111) to another process chip (111). In some such scenarios, the first process chip (111) may perform a first dedicated function (e.g., synthesis, etc.), and the second process chip (111) may perform a second dedicated function (e.g., encapsulation, etc.). The reagent storage frame (107) of this embodiment includes a plurality of pressure lines and / or manifolds, which are configured to divide one or more pressure sources (117) into a plurality of pressure lines that can be applied to a process chip (111). Such pressure lines can be controlled independently or collectively (in subcombinations).

[0043] The fluid interface assembly (109) may include a plurality of fluid lines and / or pressure lines, in which case each such line may include a biased (e.g., spring-loaded) holder or tip that individually and independently drives each fluid and / or pressure line to the process tip (111) when the process tip (111) is held in the seating fixture (115). Any associated tubing (e.g., fluid lines and / or pressure lines) may be part of the fluid interface assembly (109) and / or connected to the fluid interface assembly (109). In some versions, each fluid line comprises a flexible tubing that connects the reagent storage frame (107) and the process tip (111) via a connector that locks the vial to the tubing (e.g., a ferrule). In some versions, the ends of the fluid / pressure lines may be configured to seal to the process tip (111) as described below (for example, in corresponding sealing ports formed within the process tip (111)). In this embodiment, the connection between the pressure source (117) and the process tip (111), and the connection between the vial in the reagent storage frame (107) and the process tip (111) all form a sealed and closed pathway that is isolated when the process tip (111) is seated in the seating fixture (115). Such a sealed and closed pathway may provide protection against contamination when processing therapeutic polynucleotides.

[0044] The vials in the reagent storage frame (107) may be pressurized (e.g., to a pressure greater than 1 atm, such as 2 atm, 3 atm, 5 atm, or more). In some versions, the vials may be pressurized by a pressure source (117). Thus, negative or positive pressure may be applied. For example, the fluid vial may be pressurized to about 1 to about 20 psig (e.g., 5 psig, 10 psig, etc.). Alternatively, at the end of the process, a vacuum (e.g., about -7 psig or about 7 psia) may be applied to draw the fluid back into the vial (e.g., the vial that serves as the storage location). The fluid vial may be driven at a lower pressure than the pneumatic valve, as described below, which may prevent or reduce leakage. In some modifications, the pressure difference between the fluid valve and the pneumatic valve may be about 1 psi to about 25 psi (e.g., about 3 psi, about 5 psi, 7 psi, 10 psi, 12 psi, 15 psi, 20 psi, etc.).

[0045] The system (100) of this embodiment further includes a magnetic field applicator (119) configured to generate a magnetic field over a region of the process chip (111). The magnetic field applicator (119) may include a movable head that can move the magnetic field and thereby selectively isolate products adhering to magnetic trapping beads in vials or other storage containers within a reagent storage frame (107).

[0046] The system (100) of this embodiment further includes one or more sensors (105). In some versions, such sensors (105) include one or more cameras and / or other types of optical sensors. Such sensors (105) may sense one or more of the following: barcodes, fluid levels in fluid vials held within a reagent storage frame (107), fluid movement in a process chip (111) mounted within a seating device (115), and / or other optically detectable conditions. In versions in which sensors (105) are used to sense barcodes, such barcodes may be present on the vials in the reagent storage frame (107) so that sensors (105) may be used to identify the vials in the reagent storage frame (107). In some versions, a single sensor (105) is positioned and configured to simultaneously observe such barcodes on vials in a reagent storage frame (107), fluid levels in vials in the reagent storage frame (107), fluid movement in a process chip (111) mounted in a seating device (115), and / or other optically detectable conditions. In some other versions, two or more sensors (105) are used to observe such conditions. In some such versions, different sensors (105) may be positioned and configured to separately observe corresponding optically detectable conditions, such that each sensor (105) may be dedicated to a specific corresponding optically detectable condition.

[0047] In versions of sensor (105) that include at least one optical sensor, visual / optical markers may be used to estimate yield. For example, fluorescence may be used to detect process yield or residual material by tagging with a phosphor. In addition, or alternatively, dynamic light scattering (DLS) may be used to measure the particle size distribution within a portion of the process chip (111) (e.g., a mixed portion of the process chip (111)). In some modifications, sensor (105) may provide measurements using one or two optical fibers to deliver light (e.g., laser light) into the process chip (111) and detect the optical signal coming out of the process chip (111). In versions of sensor (105) that optically detect process yield or residual material, etc., sensor (105) may be configured to detect visible light, fluorescence, ultraviolet (UV) absorbance signals, infrared (IR) absorbance signals, and / or any other suitable type of optical feedback.

[0048] In a version including at least one optical sensor (105) configured to capture video images, such sensor (105) may record at least some activity on the process chip (111). For example, the entire run for synthesizing and / or processing a material (e.g., therapeutic RNA) may be recorded by one or more video sensors (105), including a video sensor (105) that can visualize the process chip (111) (e.g., from above). The processing on the process chip (111) may be visually tracked, and this video recording may be retained for later quality control and / or processing. Thus, the video recording of the processing may be stored, stored, and / or transmitted for subsequent review and / or analysis. In addition, as will be described in more detail below, the video may be used as a real-time feedback input that can influence the processing using at least visually observable conditions captured in this video.

[0049] The system (100) of this embodiment may be controlled by a controller (121). The controller (121) may include one or more processors, one or more memories, and various other suitable electrical components. In some versions, one or more components of the controller (121) (e.g., one or more processors) are embedded within the system (100) (e.g., housed in a housing (103)). In addition, or alternatively, one or more components of the controller (121) (e.g., one or more processors) may be detachably attached to or detachably connected to other components of the system (100). Thus, at least a portion of the controller (121) may be detachable. Furthermore, in some versions, at least a portion of the controller (121) may be detached from the housing (103).

[0050] Control by the controller (121) may, among other tasks, include activating the pressure source (117) to apply pressure through the process chip (111) and drive fluid movement. The controller (121) may be located entirely or partially outside the housing (103) or entirely or partially inside the housing (103). The controller (121) may be configured to receive user input via the system (100) user interface (123) and to provide output to the user via the user interface (123). In some versions, the controller (121) is fully automated to the extent that no user input is required. In some such versions, the user interface (123) may only provide output to the user. The user interface (123) may include a monitor, touchscreen, keyboard, and / or any other preferred features. The controller (121) may coordinate processes including moving one or more fluids onto the process chip (111), mixing one or more fluids on the process chip (111), adding one or more components to the process chip (111), metering fluids within the process chip (111), regulating the temperature of the process chip (111), and applying a magnetic field (for example, when using magnetic beads). The controller (121) may receive real-time feedback from the sensor (105) and execute control algorithms in accordance with such feedback from the sensor (105). Such feedback from the sensor (105) may include, but are not limited to, the identification of reagents in vials within the reagent storage frame (107), the detected fluid level in vials within the reagent storage frame (107), the detected movement of fluids within the process chip (111), and the fluorescence of fluorophores in the fluids within the process chip (111). The controller (121) may include software, firmware, and / or hardware.The controller (121) may also communicate with a remote server for purposes such as tracking the operation of the device, sorting materials (e.g., components such as nucleotides, process chips (111), etc.), and / or downloading protocols.

[0051] III. Examples of State Machine-Based Applications To utilize a system such as the one shown in Figure 1 for purposes such as the production and formulation of polynucleotides, a user may provide inputs for controlling the system (100) via the system (100)'s user interface (123) and / or develop scripts that include device operations defining actions to be performed by the system's components. To facilitate such activities, in some embodiments, an application may be provided to respond to such inputs and process such scripts having an architecture such as the one shown in Figure 2. In this type of architecture, the application may include multiple modules, each of which may be an instantiation of a module class that provides a public way enabling a module to create other modules and / or communicate with other modules. For example, each module may include a ProceedOperation method that enables other modules to communicate commands to each module that it should execute, and a constructor that can perform operations such as allocating memory to a queue that will be used to hold incoming commands, storing references to other modules that the module may need to communicate with, and / or generating a unique identifier that can be used to track the module's behavior during the execution of the application.

[0052] In applications using an architecture like the one shown in Figure 2, this type of public communication can take place in various forms. For example, when an application is started, it may first instantiate three top-level modules: a module manager (201) for processing inputs and scripts, a process logger (202) for recording actions (and errors detected) performed by the application, and a data logger (203) for recording data generated during the application's operation (e.g., readings from the thermal control unit (113)). Then, one or more of these top-level modules may instantiate their own lower-level modules. For example, in some cases, the module manager (201) may create a set of modules including a graphical user interface (GUI) manager (204) for graphical interaction with the user, one or more intermediate modules or intermediate-level modules which may also be called function modules (205a) to (205n) for issuing commands to functional units (e.g., thermal control unit (113), sensor (105), etc.), and an automation manager (206) for translating between device operations which will be written into an external script and application commands which will be executed by the application.

[0053] In some cases, the instantiation of functional modules as described above may be performed by a top-level module (e.g., a module manager (201)) that calls the constructor function of the module class corresponding to each functional module being instantiated. The top-level module may then store a reference to each of the modules it instantiates, and may share those references among the modules if the application is implemented in such a way that modules at a single level of the hierarchy can communicate with each other. For example, when implementing an application in which a second functional module (205n) may require a first functional module (205a) to complete a complex task, when the first functional module (205a) is instantiated, a reference to that module may be provided to the constructor of the second functional module (205n) for use in subsequent communication. If the instantiation of the first functional module (205a) fails, the second functional module (205n) may still function, but the features that would have been involved in communication with the first functional module (205a) may be disabled. In this way, a hierarchy like the one illustrated in Figure 2 can define the paths and data structures used to communicate commands between different parts of an application.

[0054] In addition to the modules illustrated in Figure 2, an application may, in some cases, include one or more device objects (207a-a) to (207a-n), where one or more device objects (207a-a) to (207a-n) may be modules instantiated by a functional module and may correspond to a physical device that the application can control. For example, if an application following the architecture of Figure 2 includes a functional module (205a) for issuing commands to a thermal control unit (113), then that functional module (205a) may instantiate two device objects (207a-a) (207a-b) (one corresponding to a Peltier element and the other to a heating clamp). These modules may then communicate by passing commands using references to each other, as may have been created above using the constructors of various modules.

[0055] Referring now to Figure 3, this figure illustrates an exemplary way a module may use to execute commands that may be received via a publicly accessible ProceedOperation method when the module is implemented as a state machine that stores incoming commands in a queue and runs in a loop on a dedicated thread until it is shut down. In the method shown in Figure 3, in each iteration of the module's loop, the module may determine in a decision block (301) whether it should set (and potentially change) its state. This can be done, for example, by checking whether the module is already occupied (for example, by executing a command that was received in the previous iteration but has not yet completed). If the module is already occupied, whatever process was occupying it, the module may continue that process in block (302). Otherwise, if there is a command at the head of the queue, the module may set its state based on that command.

[0056] As shown in Figure 3, a state-machine-based module can have a variety of states to which the module can transition (or maintain). For example, if there are no commands in the command queue, the module's state may be set (or maintained) as IDLE in block (303). The IDLE state may be a state in which the module does not take any action, but may be a state in which background tasks are performed when no other commands are received. For example, in a functional module corresponding to a thermal control unit (113), during the IDLE state, the module may measure and record the temperature. Alternatively, if a command exists in the queue, the command may cause the module to switch to a state corresponding to that command. In the diagram in Figure 3, this is represented in block (304), and in response to receiving an application command (for example, in a module adapted to execute n commands corresponding to a command that may be issued from a user interface or script, this could be any of commands 1 to n), the module may be placed to a state corresponding to that command.

[0057] To illustrate the state setting of block (304), consider an example of a functional module corresponding to the thermal control unit (113). An application containing such a module may send a temperature setting command (TC_SETTEMP) to the module, and the module may be configured to enter the temperature setting (TC_SETTEMP) state when such a command is received. In that state, the module may be programmed to perform any actions that would be necessary to set the temperature as indicated by the command. This may include: 1) Determine the physical device (e.g., a Peltier heater or heating clamp) on which the temperature should be set (for example, by receiving this information as a parameter of the TC_SETTEMP command). 2) Send a command to the device object corresponding to that physical device instructing it to set the device's temperature to the specified temperature (for example, by passing the temperature included as a parameter to the TC_SETTEMP command to the appropriate device object using the reference created when the device object was created). 3) Wait for the device object to confirm that it has received the command (for example, by including the address to which the device object sends its response when sending the command, and monitoring that address until an acknowledgment is received or until a pre-configured timeout expires), and 4) Wait for the device object to confirm that the command was executed successfully (for example, by monitoring the address sent with the command until a success confirmation is received or a pre-configured timeout expires).

[0058] In addition to states corresponding to commands for device operation (e.g., setting a temperature), state-machine-based modules may also include states corresponding to control commands such as STOP and / or SHUTDOWN. When in a STOP state (the module may enter block (305) after receiving a STOP command), the module may take action to stop the operation of devices that the module may otherwise control. For example, in the case of a functional module corresponding to a thermal control unit (113), when in a STOP state, the module may execute a command to stop the power supply to heating elements in the controlled system (100) (e.g., by sending an additional STOP command to the device object corresponding to these heating elements). Similarly, when in a SHUTDOWN state (the module may enter block (306) after receiving a SHUTDOWN command), the module may not only stop the operation of devices that the module may otherwise control, but once the operation of these devices is stopped, the module may shut down in block (307) by deallocating previously allocated memory (this includes deallocating any objects that the module previously instantiated).

[0059] Modifications of the state machine-based implementation, such as those described in relation to Figure 3, are also possible. For example, a system may be implemented based on this disclosure in which analyses other than those considered above may be performed when determining whether to set a state for a module. To illustrate, consider Figure 4, which illustrates an exemplary process that may be performed in each cycle of a state machine in order to determine whether to set a state for the state machine. First, in block (401), a module executing the process shown in Figure 4 can check the module's command queue to see if a command has been received. If a command has been received and the command is a STOP or SHUTDOWN command, in block (402), any commands that were already being executed may be terminated, and the process may continue to block (403) to set the module's state (for example, by setting the module to a STOP or SHUTDOWN state using the process shown in Figure 3). Similarly, if there are non-STOP commands and non-SHUTDOWN commands in a queue with high priority, in block (402), any commands that were already being executed may be terminated, and in block (403), the state may be set in order to execute the high priority commands.

[0060] In the process shown in Figure 4, if there is no command in the queue that could terminate the currently executing command, and the module is busy, block (404) may discard any command in the queue. This may include clearing the queue and sending a response back to the module that issued the command indicating that the command was discarded without being executed. Alternatively, if the module is not busy, block (403) may simply proceed to set a state using whatever command was in the queue (or proceed to IDLE if no commands were in the queue).

[0061] Further variations other than those described above may also be possible in relation to Figure 4. For example, in some cases, in addition to sending a response when a command is discarded in block (402), or as an alternative thereto, a module performing a process as shown in Figure 4 may send a message to the source of the command when the command is executed (e.g., after the module's state is set in block (403)) and / or when the command is terminated (e.g., as a result of a STOP or SHUTDOWN command in block (402)). Similarly, in some cases, instructions may be identified by priorities other than critical priority (e.g., high priority, normal priority), and a module receiving such commands may execute them in preferred order (e.g., by sorting its incoming command queue based on priority), even if not strictly in the order they were received.

[0062] To facilitate the use of the type of logic shown in Figure 4, or to support other functionalities in applications created based on this disclosure, several examples may implement modules as shown in Figure 2 using a class hierarchy that defines requirements and functionalities that flow down through various modules from a base class. For example, there may be a module class containing function encoding logic (e.g., ReceiveCmd()) as described in relation to Figure 4, and the module manager (201) and each module or application shown in Figure 2 as deriving from it may implement or inherit the module class. In this way, various modules as shown in Figure 2 can utilize the ReceiveCmd() functionality without needing to be re-encoded on an object-by-object basis.

[0063] The class hierarchy may also include items other than the module manager and its children illustrated in Figure 2. For example, a module class that may be instantiated as a module manager may itself be a child of a more generic object class. This may provide functionality that is useful not only for state machine-based modules in examples where this type of generic object class exists, but also for other types of entities. This type of basic functionality may include error logging, which may be supported by including a way to encapsulate information about errors (e.g., status codes and error descriptions) and post it to a publicly available error queue. The object class may also, or alternatively, include functionality for tracking the object itself, such as a constructor that can automatically generate a unique identifier for an instance, a name for that instance, and a timestamp when that instance was created when an instance of a class inheriting from the object class is created.

[0064] To illustrate how this type of tracking functionality can be applied, consider an example of tracking the execution of application commands corresponding to device actions from a script by an application following a state machine implementation as shown in Figure 3. In some cases, to support this type of tracking, a module such as an automation manager (206) may use a process as shown in Figure 5 to convert a script containing device actions (e.g., energizing a heated clamp and setting its temperature to a specific value) into a series of uniquely identifiable application commands. Referring to this figure, in block (501), the script may first be preprocessed by converting it into a line-by-line representation by removing any blank lines or comments that may have been included for readability and maintainability purposes when the script was created, and / or by splitting device actions that may have been contained in a single line into multiple lines. In block (502), the device actions in the preprocessed script may be associated with commands that the application can execute line by line. For example, if the script contains the device action SETTEMP, this command may be checked against data indicating that the SETTEMP device action would be represented internally by the TC_SETTEMP command within the application.

[0065] In the process shown in Figure 5, once a device operation from a script is associated with a command, block (503) may use that association information to check the syntax of the associated command. For example, an application might be defined to execute a TC_SETTEMP command with two parameters: the name of the device to which the temperature should be set, and the temperature to be set on the device. In such a case, if the SETTEMP command in the script is associated with only a single parameter (e.g., a temperature but no device name), this could cause the script to fail the syntax check in block (503). In some cases, this type of check may be supported by providing data that defines each type of command the application may execute, and this data may include the data specified in Table 1 below.

[0066] [Table 1]

[0067] In some cases, the parameter sequences described above may allow both arranged and unarranged parameters on the same line. For example, a sequence like "x,x,[x,x]" may be acceptable, where the first two parameters are read, followed by N * The two parameters can be converted into a parameter sequence that can be read to the end of the script line.

[0068] Following the syntax check in block (503), the process shown in Figure 5 may continue by checking the command semantics in block (504). This may be done by creating an application command object for each device operation using information from the script and sending that object to the module responsible for executing it (e.g., a device object corresponding to a physical object that will be controlled by the device operation from the script). This module may then check that the command was actually executable (e.g., that the module actually had instructions for the state corresponding to the command) and that its private data did not indicate any environment or other factors that could prevent the command from being executed (e.g., device readings indicating conditions under which the operation would be impossible).

[0069] If an error is triggered in any of the operations in blocks (501) to (504), the process in Figure 5 may be terminated in block (506) by generating an error message that reflects the error that occurred. Alternatively, if all operations in blocks (501) to (504) complete without errors, the script may be executed in block (505) by creating a new command object line by line for each of the device operations in the script and sending it to the appropriate module for execution. For example, the automation manager (206) may create a command for each operation and send it to the module manager (201). The module manager (201) may then route the command to the appropriate function modules (205a) to (205n), which may then route the command to device objects (207a-a) to (207a-n) corresponding to the physical devices that will be controlled by the execution of the device operations. The device objects may then enable the device operations by generating the appropriate inputs and providing them to the interface of their corresponding physical devices. In this type of scenario, the application can leverage the fact that each device action from the script is translated into a uniquely identifiable application command by logging each of the communications described above, as well as any errors associated with those communications (e.g., the module was busy when the application command was sent and the command timed out without execution, or there was a hardware error when the device object sent its input implementing the command, etc.), using a public interface exposed by an object such as a process logger (202). Thus, even if the script contains multiple commands of the same type, a particular error can be easily traced back to the specific command that triggered it.

[0070] In some examples, in addition to communicating application commands as instances of command classes, or as an alternative, responses to such application commands may be generated as instances of response classes, which may be part of an inheritance tree as described above. Such command response classes may include information and / or functionality inheriting from a base class (e.g., a unique identifier, data indicating the time the class instance was created, etc.) and additional information specific to responding to a command. Such information may include, for example, state information that can be logged and used later to track the application's behavior as needed. Examples of such states are listed in Table 2 below.

[0071] [Table 2]

[0072] During operation, the command response classes described above can work synergistically with the command classes described earlier. For example, a module class may, in some cases, include a function (e.g., a SendCmd function) for sending commands to the module that will execute them. This function may take a command object as input, along with a reference to where the response to the command should be directed (e.g., a reference to a response queue maintained by the sending module). The command sending function may use this information to enqueue the command in the receiving module's command queue (e.g., using the ProceedOperation method) and return a command response object, thus enabling the sending module to receive a response even if the command was not given an affirmative response to the receiving module. In this type of implementation, a successful command may produce two responses: one when the receiving module receives the command and another when the command execution is complete. In some cases, developers may use this to create logic that incorporates inter-process relationships across modules, such as when a first module sends a command to a second module, and then waits for that second module to complete the command for proper scheduling before proceeding to subsequent actions.

[0073] The above example illustrates how an application may execute commands corresponding to device operations from a script; however, it should be understood that implementations of the disclosed technology may not be limited to this type of command execution. For example, in some cases, an application implemented based on this disclosure may expose a graphical user interface (GUI) that allows a user to provide input that can be executed in a manner similar to that described above with respect to device operations in a script. In an application providing this type of functionality, the GUI may be generated, maintained, and operated using the method shown in Figure 6. In the method shown in Figure 6, a module (e.g., a functional module (205a) for controlling a thermal control unit (113)) may initialize the GUI in block (601) by creating the GUI as an object and storing a reference to that object in its (i.e., module's) private data. This object may then invoke two while loops that will run in parallel and sequentially (e.g., by running on separate threads), which are a control loop containing blocks (602) and (603), and an indicator loop containing block (604).

[0074] Referring to the specific loop shown in Figure 6, in the control loop, block (602) may check whether the user has provided input to the GUI that triggers an action within the controlled system. If so, block (603) generates a command corresponding to that action and dispatches it to the appropriate module for execution as described earlier in relation to Figure 3. In the indicator loop, block (604) may update the data displayed on the GUI, for example, by propagating it from the private data of the module running the GUI. In both cases, the loop may continue until the GUI is closed (for example, because the module running the GUI receives a SHUTDOWN command), in which case the process is terminated in block (605).

[0075] The methods for generating, operating, and maintaining a GUI, as shown in Figure 6, may be carried out by modules that also bear responsibility for controlling specific aspects of the system; however, it should be noted that, in some cases, other modules may also be involved in the generation, operation, and / or maintenance of the GUI. For example, in some cases, a GUI manager (204) may present a unified view of GUIs generated by multiple individual modules within the application. For instance, the GUI manager may obtain references to data objects encoding GUIs generated by various functional modules, and then use those references to display the combined GUI to the user. In some cases, other approaches may also be implemented. For example, in some cases, a module manager (201) may collect references to GUIs for each of its individual functional modules (205a) to (205n) and pass those references to the GUI manager (204) for display. Therefore, the above description should be understood as merely an illustrative example of approaches to implementing a GUI, and should not be treated as an limitation.

[0076] As another example of the potential types of functionality that may be provided by applications implemented under this disclosure, consider logging of data captured by the application. As described above, in some cases a process logger (202) may provide a public interface that can record information such as when various objects (e.g., commands, responses) were created, unique identifiers of those objects, and any errors generated by those objects. Similarly, in some cases a data logger (203) may provide a similar public interface for recording data captured during the operation of the application. For example, in some cases when a module captures measurements from a controlled system, the module may encapsulate those measurements in an object having information such as that shown in Table 3 below.

[0077] [Table 3]

[0078] This information may then be provided to the data logger(203) by the module calling a method (e.g., DataLog()), which may inherit its base class in order to add it to a queue maintained by the data logger(203).

[0079] Referring now to Figure 7, this figure illustrates an exemplary method that may be used to create a module in an application implemented under this disclosure. In this method, a set of control states may be defined for the module in block (701). This may include, for example, defining actions to be taken when the module enters a SHUTDOWN or STOP state. For example, if the module is a functional module, this may include the functional module sending a SHUTDOWN or STOP command to each of the previously instantiated device objects, and in the case of a SHUTDOWN module, calling a destructor or taking any other action (if any) necessary to deallocate memory for the previously instantiated device objects. Similarly, if the module is a device object corresponding to a particular physical device, the action may include providing a specific input to an interface exposed by the corresponding physical device so that the device is deactivated (or otherwise placed in a quiescent state).

[0080] In addition to the STOP and / or SHUTDOWN states, or as alternatives thereto, other types of control states may be defined in block (701). For example, in some cases a module may enter the BOOTUP state when its constructor is called or when it needs to be reset during application execution. In such cases, defining the BOOTUP state may involve instantiating, creating, and storing references to various lower-level modules, establishing connections to specific physical devices, defining various default values ​​that should be stored by the module or provided to its corresponding physical device at startup, and / or defining error logic to catch exceptions that may occur during the boot-up process.

[0081] After the control state is defined in block (701), the method in Figure 7 may proceed to define the module's IDLE state in block (702). As described earlier, this IDLE state may include actions that can be performed when the module has not processed any explicit commands, such as those that may have been generated by translating device actions from a script or user input into a GUI. In some implementations that include this type of IDLE state, defining the IDLE state in block (702) may include capturing information from the controlled system and logging that information using the public interface of the data logger (203), as described earlier. Depending on the module being created, other types of actions may be included in the IDLE state, or no actions may be included at all. Therefore, the above explanation of defining the IDLE state should be understood as illustrative only and should not be treated as implying any limitations on the protections provided in this document or any related documents.

[0082] The process in Figure 7 also includes defining a command state in block (703). This can be done by defining one or more actions and / or logical operations that will be performed to implement various commands that the module may be expected to receive. For example, this may include defining one or more operations that a module following an implementation of the state machine as shown in Figure 3 may perform in a single iteration of the state machine's operation loop, and subsequently setting the module's state to IDLE for the purpose of processing a command in the next iteration (or performing an operation defined for the IDLE state if no command is received). This may also include designing the state machine to be non-blocking, such as defining operations that, to the extent that any type of loop (e.g., for loops) is included, are performed such that those loops have a deterministic termination and do not include while loops or other potentially non-deterministic types of looping structures. Similarly, for error logging purposes, the final operation of any command state may be to call a function (e.g., by calling a dedicated ERRLog() method inheriting a base class) that communicates any errors detected during command execution to the process logger (202). Other types of programming practices can also be used when defining command states, such as requiring all command states corresponding to device operations that may be included in a script to be included in higher-level modules (e.g., module manager (201) or function modules (205a)~(205n)), while all lower-level modules (e.g., device objects (207a-a)~(207a-n)) only receive commands from the function modules that instantiated them. Therefore, the above explanation of how command states may be defined in block (703) should be understood as merely illustrative and not as limiting.

[0083] Just as different programming techniques may be used when defining command states in block (703), it should be understood that the definition of command states in block (703) may include definitions of actions more complex than those that may be contained in a single iteration of the state machine's operation loop. An example of how these types of more complex actions may be defined is provided in Figure 8. In this method, actions that may be performed when the state machine is in a state corresponding to a command may be defined in block (801) (for example, using programming techniques such as those described above in relation to block (703). Additionally, in block (802), additional actions that may be performed when the module is next in the IDLE state may be defined. This may include defining logic that can be associated with the IDLE state and that will be executed in future iterations of the module's operation loop, such as by placing those actions in a buffer that will be executed over loop iterations. The method in Figure 8 also includes defining error logic in block (803). This logic may prevent the actions defined in blocks (801) and / or (802) from being performed, and as a result, it can be used to detect situations in which errors may be logged using the process logger (202) as described earlier. The method in Figure 8 also includes defining in block (804) the state that the module should enter in an iteration after receiving a command as the IDLE state. Once the module enters its IDLE state, it may perform the actions defined in block (802), which may continue until all actions associated with the command are completed. In this way, actions for a command can be extended across multiple state machine loops. Additionally, implementations that allow actions to be performed in subsequent IDLE states may enable simultaneous IDLE processing of multiple commands, for example, if an action added to a buffer has not been completed before another command adds its own command to that same buffer. In this way, a new command may be received even while a previous command is in progress.

[0084] In some cases, other approaches to handling commands using behavior that extends across multiple loops may also be possible. For example, Figure 9 illustrates a method for defining how a multi-iteration command may be executed using a new state dedicated to command completion. In this method, the actions that may be performed when the module is in its initial state (e.g., the state corresponding to a command executed across multiple loop iterations) are defined in block (901). In block (902), error logic may be defined to identify errors that may occur when performing the actions defined in block (901). If the actions defined in block (901) represent all the actions required to implement the command, code is added to report that the command has finished in blocks (903) and (904), respectively, and set the next state to IDLE. Alternatively, if not all the actions required to implement the command are defined, a new state may be created in block (905) and defined as the next state to transition to. This new state may not correspond to any command that may be included in a script or received from a GUI, but instead may simply be triggered to continue the process in the next loop iteration. Next, in blocks (901) and (902), action and error logic may be defined for this new state, and this may continue until all actions necessary for the command to complete have been defined, at which point the command may end and the module may transition to the IDLE state.

[0085] Figure 10 provides yet another example of an approach to defining command states whose performance can be scaled across multiple iterations, which can be used when a command may require inter-module interaction. In the method of Figure 10, in block (1001), actions that a module may perform before needing to interact with an external module may be defined. Next, in block (1002), the interaction between the module and the external module may be defined. This may be done, for example, by including a call to a method defined for the module base class (e.g., WaitForCommandToFinish()) and providing parameters including the command that the external module would need to perform and a timeout value indicating how long the module should wait. After the external interaction is defined, in block (1003), any actions that the external module would perform after it has finished its execution may be defined. Next, code may be added to set the module to the following state, IDLE, in a manner similar to that described for Figures 8 and 9. During operation, a module created using the method shown in Figure 10 may remain in a state corresponding to the action defined using the method in Figure 10 until the command that drove the module to that state completes (or is terminated, or exits with an error, etc.). In this way, a module executing a command that required an external interaction may wait for that interaction to complete without blocking, so that any new critical command or command that would invalidate the waiting state can still be executed as needed.

[0086] Figures 8–10 provide examples of methods for defining state machine-based modules to execute commands across multiple loop iterations; however, these examples are illustrative only, and it should be understood that other variations can be implemented by those skilled in the art in light of this disclosure and will be immediately apparent to them. For example, combinations of the approaches described above can be implemented, in some cases, such as an operation involving an external interaction as illustrated in Figure 10, and an operation performed before and after the external interaction (e.g., the operations defined in blocks (1001) and (1003)) that can be extended across multiple loop iterations using techniques such as those described in relation to Figures 8 and 9. Other variations may also be possible and can be implemented by those skilled in the art without excessive experimentation based on this disclosure. Therefore, the above description of actions that may be included when defining a command state in block (703) should be understood only as illustrative and not as limiting.

[0087] Continuing our consideration of Figure 7, after all the command states of the module are defined in block (703), the illustrated process may continue to define the module's GUI (if any) in block (704). This may include, for example, defining indicators and control loops as described earlier in relation to Figure 6, as well as defining the appearance of the GUI and the potential interactions that the GUI may support. Finally, once the GUI and all necessary states are defined, the module created using the method shown in Figure 7 can be treated as complete and incorporated into the previously described application for controlling the system (100) illustrated in Figure 2 and shown in Figure 1.

[0088] Variations of the examples described above are also possible and will be apparent to those skilled in the art without excessive experimentation based on this disclosure, and can be implemented by those skilled in the art. For example, an application as described herein may be implemented using the architecture shown in Figure 2, but in some cases an application implemented based on this disclosure may instead use the architecture shown in Figure 11. As shown in Figure 11, such an alternative architecture may include modules similar to those considered above in relation to Figure 2, but they may be organized in a different manner. For example, in some cases the module manager (201) may be instantiated first, rather than the process logger (202) and data logger (203) being instantiated in parallel with the module manager (201), and then the process logger (202) and data logger (203) may be instantiated together with an automation manager (206) and / or other modules that may provide functionality accessible by functional modules (205a) to (205n).

[0089] In some embodiments (for example, embodiments following the architecture of Figure 11), after instantiating modules that will provide functionality that can be used by functional modules, the module manager (201) may instantiate functional modules (205a) to (205n) and provide pointers to previously instantiated modules (e.g., process logger (202), data logger (203)) that functional modules can use to access their functionality as an alternative to using the public interface as described above. In some implementations, this type of alternative access via pointers may be available instead of a publicly accessible interface, while in other implementations, the pointer-based method of accessing functionality may be available in parallel with the public interface, thereby giving developers of functional modules (205a) to (205n) multiple options depending on which mode of accessing functionality in another module may be most appropriate in a given situation.

[0090] As shown in Figure 11, in addition to having different hierarchies in which all modules are instantiated by the module manager (201), there may be additional modules beyond those described above, such as a cloud manager module (1101). In applications where such a cloud manager module (1101) exists, it may be used to provide other modules (e.g., function modules (205a) to (205n)) with functionality for cloud operations such as uploading or downloading files. This may be done, for example, using functions accessed via reference (e.g., the SendCloudData function) or a public interface, in a similar manner to those described above for the process logger (202) module and the data logger (203) module. Other variations are also possible, such as providing additional or different modules from those considered above in relation to Figures 2 and 11, and will be immediately apparent to those skilled in the art in light of this disclosure. Therefore, the above considerations regarding variant forms, like the preceding explanations and examples, should be understood solely as illustrative examples and should not be treated as implying any limitations on the protections provided by this document or any related documents.

[0091] IV. Others The foregoing description is provided to enable those skilled in the art to implement the various configurations described herein. While the subject art has been specifically illustrated with reference to various figures and configurations, it should be understood that these are for illustrative purposes only and should not be construed as limiting the scope of the subject art.

[0092] Many other methods may exist for implementing the subject art. Various functions and elements described herein may be classified differently from those shown without departing from the scope of the subject art. Various modifications to these implementations may be readily apparent to those skilled in the art, and the general principles defined herein may be applicable to other implementations. Thus, many changes and modifications may be made to the art by those skilled in the art without departing from the scope of the subject art. For example, a different number of given modules or units may be used, or one or more different types of given modules or units may be used, or given modules or units may be added, or given modules or units may be omitted.

[0093] Some versions of the examples described herein may be implemented using a processor that is part of a computer system and communicates with several peripheral devices via a bus subsystem. Versions of the examples described herein implemented using a computer system may be implemented using a general-purpose computer programmed to perform the methods described herein. Alternatively, versions of the examples described herein implemented using a computer system may be implemented using a purpose-specific computer built with hardware configured to perform the methods described herein. Versions of the examples described herein may also be implemented using a combination of at least one general-purpose computer and at least one purpose-specific computer.

[0094] In versions implemented using computer systems, each processor may include the computer system's central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), other types of hardware components, and combinations thereof. A computer system may include multiple types of processors. Peripheral devices of a computer system may include, for example, a storage subsystem including memory devices and a file storage subsystem, user interface input devices, user interface output devices, and a network interface subsystem. Input and output devices may enable user interaction with the computer system. The network interface subsystem may provide an interface to an external network, including an interface to a corresponding interface device in another computer system. User interface input devices may include pointing devices such as keyboards, mice, trackballs, touchpads, or graphics tablets, audio input devices such as scanners, touchscreens integrated into displays, speech recognition systems, and microphones, and other types of input devices. In general, the use of the term “input device” is intended to include all possible types of devices and methods for inputting information into a computer system.

[0095] In versions implemented using computer systems, user interface output devices may include non-visual displays such as display subsystems, printers, fax machines, or audio output devices. Display subsystems may include flat-panel devices such as cathode ray tubes (CRTs), liquid crystal displays (LCDs), projection devices, or any other mechanism for creating visible images. Display subsystems may also provide non-visual displays such as audio output devices. Generally, the use of the term “output device” is intended to include all possible types of devices and methods for outputting information from a computer system to a user or another machine or computer system.

[0096] In versions implemented using a computer system, the storage subsystem may store programming and data structures that provide some or all of the functionality of the modules and methods described herein. These software modules can generally be executed by the computer system's processor alone or in combination with other processors. The memory used by the storage subsystem may include several types of memory, including main random-access memory (RAM) for storing instructions and data during program execution, and read-only memory (ROM) for storing fixed instructions. The file storage subsystem may provide persistent storage for program and data files and may include hard disk drives, floppy disk drives with associated removable media, CD-ROM drives, optical drives, or removable media cartridges. Modules that implement the functionality of a particular implementation may be stored by the file storage subsystem within the storage subsystem or in other machines accessible by the processor.

[0097] In versions implemented using computer systems, the computer system itself may be of various types, including personal computers, portable computers, workstations, computer terminals, network computers, televisions, mainframes, server farms, a widely distributed set of loosely networked computers, or any other data processing systems or user devices. Due to the constantly changing nature of computers and networks, the examples of computer systems described herein are intended solely as specific examples for the purpose of illustrating the disclosed technology. Many other configurations of computer systems are possible, having more or fewer components than those described herein.

[0098] As a manufactured item rather than a method, program instructions executable by a processor can be loaded onto a non-temporary computer-readable medium (CRM). When executed, the program instructions implement one or more of the computer implementation methods described above. Alternatively, the program instructions can be loaded onto a non-temporary CRM and, when combined with appropriate hardware, become one or more components of a computer implementation system that practices the disclosed methods.

[0099] Underlined and / or italicized headings and subheadings are used for convenience only and do not limit the subject art, nor are they referenced in connection with the interpretation of the description of the subject art. All structural and functional equivalents of elements of various implementations described throughout this disclosure, which are known to those skilled in the art, or which will become known thereafter, are expressly incorporated herein by reference and are intended to be encompassed by the subject art. Furthermore, nothing disclosed herein is intended to be made available to the public, whether such disclosure is expressly stated in the above description or not.

[0100] It should be understood that all combinations of the aforementioned concepts and any additional concepts discussed in more detail below (provided that such concepts are not mutually contradictory) are intended to be part of the subject matter of the invention disclosed herein. Specifically, all combinations of the claimed subject matter appearing at the end of this disclosure are intended to be part of the subject matter of the invention disclosed herein.

Claims

1. A system, wherein the system Multiple scriptable devices, where each scriptable device is The interface is public, and Multiple scriptable devices adapted to perform predetermined actions based on inputs provided through that interface, Non-temporary computer-readable media, For each of the multiple mapped device behaviors, When performing the device operation, one or more inputs are provided to the corresponding device from the plurality of scriptable devices, This shows the conversion between the device's operation and the corresponding application command. Data and Multiple scripts, where each script from the multiple scripts is It has a corresponding scriptable device from the aforementioned plurality of scriptable devices, and A set of device operations, multiple scripts, and a non-temporary computer-readable medium for storing them, A computer for performing an action, wherein the action is The operation cycle is to perform the operation cycle, Determining whether an application command should be executed, Based on the determination that the aforementioned application command should be executed, To generate a globally unique identifier corresponding to that application command, The actions include adding the globally unique identifier corresponding to the application command and the device operation corresponding to the application command to the log, A system comprising a computer, which includes repeating the aforementioned operation cycle one or more times.

2. The actions performed by the computer are performed for each of the multiple scriptable devices, Determining when each device operation from each script, for which the device is the corresponding scriptable device, is included in the mapped device operations, The system according to claim 1, further comprising: generating an error message for each script that includes a device operation which is determined not to be included in the mapped plurality of device operations, provided that the device is the corresponding scriptable device.

3. The non-temporary computer-readable medium further stores data indicating a corresponding device module definition that defines a device module object for executing the corresponding application command for each of the mapped device operations, and The system according to claim 1 or 2, wherein for each of the mapped device operations, the data indicating the conversion between the device operation and the corresponding application command is included in the device module definition corresponding to the device operation.

4. The aforementioned operation cycle is The process involves receiving execution commands from the aforementioned multiple scripts to run the scripts, In response to receiving the execution command, for each device operation from the plurality of device operations included in the script, Confirm that the device operation is included in the multiple mapped device operations, The system according to claim 3, comprising verifying that the device operation having any associated parameters is executable by the device module defined by the device module definition corresponding to the device operation.

5. When performing the aforementioned operation cycle, it is determined whether the application command should be executed. Enqueuing the application command to a queue corresponding to the device corresponding to the device operation of the application command, wherein the device is referred to herein as the device corresponding to the application command, The system according to any one of claims 1 to 4, further comprising checking the status of a thread corresponding to a device corresponding to the application command.

6. The system according to any one of claims 1 to 4, wherein determining whether the application command should be executed when performing the operation cycle includes receiving, via a graphical user interface, an instruction to control the device corresponding to the device operation of the application command.

7. A method, wherein the method is Accessing a non-temporary computer-readable medium that stores module class definitions, This involves obtaining object definitions for multiple devices, where each device's object definition is: Supports physical devices, Inheriting the aforementioned module class definition, and For each of the multiple commands that can be executed by the corresponding physical device in that device object definition, The state corresponding to that command, One or more actions to be performed in the aforementioned state corresponding to that command, Specifying, obtaining, one or more inputs to be issued to the physical device corresponding to that device, This involves obtaining multiple intermediate module definitions, where each intermediate module definition is: Inheriting the aforementioned module class definition, and Each of these includes a reference to a set of device objects corresponding to the device object definition, To obtain a module manager definition, the module manager definition is Inheriting the aforementioned module class definition, and Each of these includes references to multiple intermediate modules corresponding to the intermediate module definition, and This includes launching the application, and for each device object definition, launching the application is performed as follows: Allocating memory for a device object corresponding to that device object definition, wherein the device object corresponding to that device object definition has a command queue; The corresponding thread, In order to track the current state of the device object corresponding to that device object definition, The current state of the device object corresponding to that device object definition is When the state is the same as that specified in the device object definition, in order to perform one or more actions specified for that command, This includes assigning an instruction to execute a command to determine whether to update the current state of the device object corresponding to that device object definition, based on the existence and priority of commands in the command queue included in the device object corresponding to that device object definition, For each intermediate module definition, Allocating memory for the intermediate module corresponding to that intermediate module definition, A method comprising: assigning a corresponding thread to execute instructions for sending a command to a device object having a reference contained in the intermediate module corresponding to the intermediate module definition.

8. Each device object definition specifies a set of actions to be performed while the device object defined by that device object definition is idle, and The method of claim 7, wherein for each device object definition, the corresponding thread is for performing the set of operations specified to be performed while the device object defined by that device object definition is idle.

9. The aforementioned multiple device object definitions include a temperature controller device object definition. The method of claim 8, wherein the set of operations specified by the temperature controller device object definition to be performed while the device object defined by the temperature controller device object definition is idle includes checking the temperature of the system.

10. The method according to any one of claims 7 to 9, wherein for each device object definition, all loops included in that device object definition have deterministic termination.

11. Each data object defined by a definition that inherits the aforementioned module class definition, Idle state and Stopped state, Shutdown state and A state machine having states including a boot-up state, and The method according to any one of claims 7 to 10, comprising a command queue.

12. For each device object definition, the module manager definition includes instructions for controlling the physical device corresponding to that device object definition by an action, and the action is Instantiating a command object, Passing the command object to the intermediate module defined by the intermediate module definition, wherein the intermediate module definition includes a reference to the device object corresponding to its device object definition, The command object is defined by the command object definition, and The method according to any one of claims 7 to 11, wherein both the command object definition and the module class definition inherit the base object definition.

13. Whenever an object defined by a definition that inherits the base object definition is instantiated, To generate a unique identifier for that object, The method according to claim 12, comprising an instruction for storing the aforementioned unique identifier in the object as private data.

14. A system, wherein the system Multiple scriptable devices, where each scriptable device is It is a physical device, The interface is public, and Multiple scriptable devices adapted to perform predetermined actions based on inputs provided through that interface, Non-temporary computer-readable media, For each of the multiple mapped device behaviors, When performing the device operation, one or more inputs are provided to the corresponding device from the plurality of scriptable devices, The conversion between the device operation and the corresponding application command, Data indicating multiple intermediate module definitions, each intermediate module definition containing a reference to a set of device objects corresponding to one of the scriptable devices, Multiple scripts, where each script from the multiple scripts is It has a corresponding scriptable device from the aforementioned plurality of scriptable devices, and A set of device operations, multiple scripts, and a non-temporary computer-readable medium for storing them, A computer for performing an action, wherein the action is The act of launching an application, and the act of launching the said application is For each scriptable device, Allocating memory for the device object corresponding to that scriptable device, The corresponding thread, In order to track the current state of the device object corresponding to that device object definition, When the current state of the device object corresponding to that device object definition is the same as the state specified in that device object definition, in order to execute one or more actions specified for that command, and This includes assigning an instruction to execute a command to determine whether to update the current state of the device object corresponding to that device object definition, based on the existence and priority of commands in the command queue included in the device object corresponding to that device object definition, For each intermediate module definition, Allocating memory for the intermediate module corresponding to that intermediate module definition, Starting a thread includes assigning a corresponding thread to execute instructions for sending a command to the device object having a reference contained in the intermediate module corresponding to its intermediate module definition, The operation cycle is to perform the operation cycle, Determining whether an application command should be executed, Based on the determination that the aforementioned application command should be executed, To generate a globally unique identifier corresponding to that application command, The actions include adding the globally unique identifier corresponding to the application command and the device operation corresponding to the application command to the log, A system comprising a computer, which includes repeating the aforementioned operation cycle one or more times.

15. The actions performed by the computer are performed for each of the multiple scriptable devices, Determining when each device operation from each script, for which the device is the corresponding scriptable device, is included in the mapped device operations, The system according to claim 14, further comprising generating an error message for each script that includes a device operation which is determined not to be included in the mapped plurality of device operations, provided that the device is the corresponding scriptable device.

16. The non-temporary computer-readable medium further stores data indicating a corresponding device module definition that defines a device module object for executing the corresponding application command for each of the mapped device operations, and The system according to claim 14 or 15, wherein for each of the mapped device operations, the data indicating the conversion between the device operation and the corresponding application command is included in the device module definition corresponding to the device operation.

17. The aforementioned operation cycle is The process involves receiving execution commands from the aforementioned multiple scripts to run the scripts, In response to receiving the execution command, for each device operation from the plurality of device operations included in the script, Confirm that the device operation is included in the multiple mapped device operations, The system according to claim 16, comprising verifying that the device operation having any associated parameters is executable by the device module defined by the device module definition corresponding to the device operation.

18. Based on the determination that the aforementioned application command should be executed, the operation cycle is performed. This involves instantiating a command object corresponding to that application command, This includes passing the command object to an intermediate module, The system according to any one of claims 14 to 17, wherein the command object, each device object, and each intermediate module instantiate a class that inherits a common base object definition.

19. Whenever an object defined by a definition that inherits the base object definition is instantiated, To generate a unique identifier for that object, The system according to claim 18, comprising instructions for storing the aforementioned unique identifier in the object as private data.

20. The system according to any one of claims 14 to 19, wherein for each scriptable device, all loops included in the thread corresponding to that scriptable device have deterministic termination.

Images