Enhanced system for the processing of biotechnological fluids using adaptive software

Abstract

The present application relates to biotechnology fluid processing, such as biopharmaceutical liquids, to obtain products such as monoclonal antibodies, vaccines or recombinant proteins, and in particular to a system for processing biotechnology fluids comprising a bioprocess machine and at least one bioprocess machine helper configured to be connected to each other, each comprising a controller, as well as an inter-machine communication tool configured to be connected to a network, where parts of the bioprocess machine helper are simulated and used to enhance the behavior of the disclosed system.

Description

[Technical field]

[0001] The present invention relates to the processing of biotechnological fluids, such as biopharmaceutical liquids, to obtain products such as monoclonal antibodies, vaccines or recombinant proteins. [Background technology]

[0002] It is known that biotechnological fluids, such as biopharmaceutical liquids, are generally first obtained by a process such as cell or microbial cultivation in a bioreactor, after which they must be further processed to achieve the required properties such as homogeneity, purity, concentration, absence of viruses, etc. Conventionally, these processes have been carried out in dedicated equipment such as stainless steel pipes, tanks, and filter housings, and operations are required before and after the actual process. In particular, cleaning operations after use are relatively troublesome. Within the past few years, these processes have alternatively been carried out in equipment in which the components in contact with the liquid are disposable components, in order to avoid cleaning operations.

[0003] For example, European patent applications EP 2 130 903 and EP 2 208 534 disclose equipment comprising disposable elements, including treated liquid collection bags and circuit sections, as well as filter elements, which are for the most part flexible ("Flexware™ products"), permanent or reusable elements ("hardware") housed in two or more carts, so that the equipment for processing biotechnology fluids can be assembled simply by equipping the carts with the disposable elements, while the post-processing step is essentially the removal and disposal of the disposable elements. Other known installations use the same approach with reusable elements or certain reusable elements not housed in a cart. Summary of the Invention [Problem to be solved by the invention]

[0004] Generally, the main reusable element of a facility for treating biotechnological fluids is a bioprocessing machine having a biotechnological fluid processor configured to modify at least one physicochemical or biological property of a biotechnological fluid, such as, for example, its pH, DO (dissolved oxygen), homogeneity, purity, concentration, presence or absence of certain microorganisms, e.g. viruses and / or other pathogens. In addition to the biotechnology fluid handlers, the bioprocessing machine has a digital controller for controlling the biotechnology fluid handlers, and in most cases the digital controller can control the fluid handlers, which allows the machine to automatically execute customized versions of processes, commonly called recipes. [Means for solving the problem]

[0005] The present invention aims to make it easier to set up installations for processing biotechnological fluids. The present invention relates to a system for processing a biotechnology fluid, comprising: a physical bioprocessing machine having a biotechnology fluid processor configured to modify at least one physicochemical or biological property of the biotechnology fluid and a digital controller for controlling said physical biotechnology fluid processor; and at least one physical bioprocessing machine helper having a physical biotechnology fluid processor helper configured to be coupled to said biotechnology fluid processor and a digital controller for controlling said biotechnology fluid processor helper; and / or at least one software-based bioprocessing machine helper created by an adaptive device creator; and a software-based bioprocessing machine match helper for selecting a suitable software-based bioprocessing machine helper, wherein each of said digital controllers of said bioprocessing machine and said digital controllers of said machine helper: The system includes at least one capability manager, a machine-to-machine communication tool (MtoM communication tool), and a discovery negotiation pairing manager (DNP manager); each of the MtoM communication tools is configured to connect to a network; the bioprocess machine's DNP manager and the machine helper's DNP manager are configured to cooperate over the network to establish a paired state; the bioprocess machine's capability manager and the machine helper's capability manager are configured to organize the provision and / or consumption of respective capabilities by either the bioprocess machine or the machine helper in the paired state; and the software-based bioprocess machine helper is configured to predict or calculate the behavior of the biotechnology fluid using physicochemical or biological properties and / or external data, analyze the results, and extend the capabilities of the physical bioprocess machine by the appropriate adaptive device creator.

[0006] The physical coupling between the machine helper (through the processor helper) and the bioprocessing machine (through the fluid processor) is to enable the processor helper to assist the fluid processor in modifying at least one physicochemical or biological property of the biotechnology fluid, for example, by pumping the fluid, exerting another physical action on the fluid, or sensing a physicochemical or biological quantity of the fluid, such as pH or dissolved oxygen (DO). In the system according to the present invention, the machine helper has a digital controller equipped with inter-machine communication tools to communicate with the bioprocess machine via a network enabling inter-machine communication, so that despite the physical coupling between the machine helper and the bioprocess machine, a dedicated communication channel such as a wired serial or parallel link can be relatively easily enabled, which can be operated by simply plugging in a connector when performing the physical coupling.

[0007] The present invention is based on the observation that, despite the need to perform pairing over a network in addition to the physical coupling, such pairing over a network can be used to automatically reconfigure bioprocessing machines (using their provided capacity) and machine helpers (using their consumed capacity), thus facilitating the setup of equipment for processing biotechnological fluids in practice. Such automated reconfiguration makes adding machine helpers very convenient and can even be performed during batch processing, thus providing the system according to the present invention with even greater flexibility.

[0008] Another important part of the present invention is the ability to add at least one software-based bioprocess machine helper component to the system. This is established by selecting one or more software-based helper components via the match helper, which are then created by a specific software called the adaptive device creator. This software-based bioprocess machine helper uses data about the biotechnology fluid to predict and / or calculate its operation.

[0009] This simulated operation allows testing and enhancing the functionality of the physical bioprocess machine helpers and improving the overall bioprocess machine performance. Software-based bioprocess machine helpers can be used with existing bioprocess machines with real bioprocess machine helpers or just the one that best suits the use case. It is also possible to use multiple software-based bioprocess machine helpers in a system. The configuration also varies depending on the respective use case.

[0010] According to a possible advantageous feature, the invented system comprises: the adaptive device creator and / or at least one software-based bioprocess machine helper are hosted by a remote computer that transfers said created software-based bioprocess machine helper to a respective digital controller or are hosted directly as a local instance on said respective digital controller; the at least one software-based bioprocess machine helper is configured to behave identically to its physical counterpart; the digital controller of the bioprocessing machine includes a file containing a description of each of the interface functions that can be the provided capabilities, and the digital controller of the machine helper includes a file containing a description of each of the interface functions that can be the consumed capabilities;

[0011] the DNP manager of the bioprocessing machine and the DNP manager of the machine helper are configured to cooperate over a network to establish a pairing state; the system device includes a plurality of the machine helpers, and a DNP manager of the bioprocessing machine is configured to establish the pairing condition simultaneously with at least one of the machine helpers; the system device includes a first bioprocessing machine, a second bioprocessing machine, and a plurality of machine helpers, and a DNP manager of at least one of the machine helpers is configured to establish the pairing condition with either the first bioprocessing machine or the second bioprocessing machine;

[0012] having a first said machine helper, the consumed capacity of which is an interface function controlling and / or displaying an operating parameter of a processor helper of said first machine helper, and a second said machine helper, the consumed capacity of which is an interface function displaying a physicochemical or biological quantity of a fluid sensed by a processor helper of the second machine helper, the first machine helper being a pump, the consumed capacity of which is an interface function controlling and / or displaying a speed of the pump, and the second machine helper being a pH sensor or a flow sensor, the consumed capacity of which is an interface function displaying a pH of said fluid or a flow rate of said fluid; Each of the MtoM communication tools is configured to connect to the network, which may be a network with an Internet protocol such as Ethernet, Wi-Fi, Bluetooth, or cellular 5G.

[0013] The described system may vary in various aspects depending on the functions the system is to perform. One of these aspects of the invention includes a method of operating a system for processing biotechnology fluids, comprising the steps of: identifying the relevant process context and required functions of said physical biotechnology fluid handler and using it to select at least one appropriate software-based bioprocess machine helper via said software-based bioprocess machine match helper; creating the selected at least one software-based bioprocess machine helper via said adaptive device creator; adding all software-based devices to the system and pairing at least one software-based bioprocess machine helper with the respective bioprocess machine via DNP manager; predicting and / or calculating the behavior of said biotechnology fluid in said physical biotechnology fluid handler using at least one physicochemical or biological property thereof and / or external data via said software-based bioprocess machine helper; analyzing data and based on the results, adapting the configuration of said physical biotechnology fluid handler and extending the capabilities of said physical bioprocess machine helper via said software-based bioprocess machine helper.

[0014] According to an advantageous feature, the invented method performs the following additional steps: The software-based bioprocess machine helper uses non-self-learning tools, such as machine learning models, artificial intelligence algorithms such as neural networks, and / or computational models for prediction, calculation, and data analysis. An artificial intelligence algorithm is trained using either external data or collected data relating to said at least one physicochemical or biological property from said biotechnological fluid in said physical biotechnological fluid processor. A software-based bioprocess machine helper uses smart data for predictions, calculations, and data analysis. An adaptive device creator uses a contextualization mechanism for instances of said smart data. [Brief description of the drawings]

[0015] The description of the invention continues with a detailed description of exemplary embodiments given below by way of non-limiting example with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 shows diagrammatically a production area of ​​a bioprocessing manufacturing plant or laboratory in which a bioprocessing machine is located, forming part of a system for processing biological fluids. [Diagram 2] FIG. 2 illustrates diagrammatically a storage area of ​​a bioprocessing manufacturing plant or laboratory in which a number of bioprocessing machine helpers of a system for processing biological fluids are located, the bioprocessing machine helpers being configured to be associated with the bioprocessing machines shown in FIG. [Diagram 3] FIG. 3 illustrates a bioprocess machine and one of the bioprocess machine helpers along with a network in which the bioprocess machine and the bioprocess machine helper cooperate to establish a paired state. [Figure 4] FIG. 4 shows a graphical user interface for a stand-alone mixer bioprocessing machine. [Diagram 5] Figure 5 shows the graphical user interface of the mixer when combined with a bioprocess machine helper, a pH sensor, at the top, and the graphical user interface of the pH sensor at the bottom, in a standalone state on the left and combined with the mixer on the right. [Figure 6]FIG. 6 shows a schematic of a bioprocess machine helper which is a pump along with a bioprocess machine helper which is a flow sensor at the top, where the pump and flow sensor are physically linked, with the pump's graphical user interface shown in the middle, in a standalone state on the left, and in combination with a flow sensor on the right, and the flow sensor's graphical user interface shown at the bottom, in a standalone state on the left, and in combination with a pump on the right.

[0016] [Figure 7] FIG. 7 shows an exemplary schematic diagram of a GUI that fits when a process machine and a machine helper are paired, showing the mixer graphical user interface at the top, when paired with a pH sensor on the left, when paired with a pH sensor and when paired with a pump combined with a flow sensor on the right, the pump graphical user interface is shown in the center, when paired with a flow sensor on the left, when paired with a flow sensor and when paired with a mixer on the right, the flow sensor graphical user interface is shown at the bottom, when paired with a pump on the left, and when paired with a pump and a mixer on the right. [Figure 8] 8 is an exemplary schematic diagram of a GUI that applies when the process machine and machine helper are not in a paired state, showing a graphical user interface for a mixer at the top, a pump paired with a pH sensor on the left, a pump paired with a flow sensor on the right, a graphical user interface for a pump paired with a pH sensor on the right, a graphical user interface for a pump paired with a flow sensor on the left, a graphical user interface for a pump paired with a mixer on the right, a graphical user interface for a flow sensor on the bottom, a graphical user interface for a pump paired with a mixer on the left, a graphical user interface for a pump paired with a mixer on the right ... right, a graphical user interface for a flow sensor on the top, a graphical user interface for a pump paired with a mixer on the left, a graphical user interface for a pump paired with a mixer on the right, [Figure 9]FIG. 9 illustrates three method steps that must be performed when using virtual software-based components in the invented system. [Figure 10] FIG. 10 illustrates an overall invented method for operating a system for processing biotechnology fluids, including the use of virtual software-based components.

[0017] 1 and 2 show a production area 10 and a storage area 11 of a bioprocessing production plant or laboratory in which the available system devices of a system for processing biotechnological fluids according to the invention are present. System Device Description: Bioprocess Machine and Bioprocess Machine Helper Each system device includes a digital processing unit (microprocessor and / or microcontroller, memory, network connections) and is configured to be connected, wired or wirelessly, to a network 12 (FIG. 3) that supports the Internet Protocol (IP). For example, a wired connection may be via Ethernet, and a wireless connection may be via Wi-Fi, Bluetooth, or cellular such as 5G. The system has a bioprocessing machine 13 and multiple bioprocessing machine helpers 14. The bioprocessing machine 13, alone or in association with one or more machine helpers 14, can be set up to become a facility for processing biotechnology fluids. As shown in FIG. 3, the bioprocessing machine 13 includes a biotechnology fluid handler 15 and a digital controller 16 . The biotechnology fluid processor 15 is configured to modify at least one physicochemical or biological property of the biotechnology fluid, for example its pH, DO (dissolved oxygen), homogeneity, purity, concentration, presence or absence of certain microorganisms, such as viruses. The digital controller 16 is configured to control the biological fluid processor 15, as indicated by the double-headed arrow in Figure 3. Here, the digital controller 16 can control the fluid processor 15 such that the machine 13 can automatically execute a customized version of a process, commonly referred to as a recipe. The digital controller 16 includes at least one capability manager, such as a Graphical User Interface (GUI) manager 17, a report manager, or a recipe manager, for handling various tasks. In a preferred embodiment, a Graphical User Interface (GUI) manager 17 is used. Additionally, the digital controller 16 includes a Machine to Machine (MtoM) communication tool 18, and a Discovery Negotiation Pairing (DNP) manager 19. It should be noted that the term "file" should be interpreted broadly here, ie, to encompass any structured data container, including folders and / or databases. The bioprocess machine helper 14 includes a biotechnology fluid handler helper 21 and a digital controller 22.

[0018] The processor helper 21 is configured to be physically coupled to the fluid processor 15, as indicated by the double-headed arrow in Figure 3. The physical coupling is to enable the processor helper 21 to assist the fluid processor 15 in modifying at least one physicochemical or biological property of the biotechnology fluid, for example, to pump the fluid, to exert another physical action on the fluid, or to sense a physicochemical or biological quantity of the fluid, such as pH, DO, etc. For example, if the bioprocessing machine 13 is a mixer, the biotechnology fluid handler 15 includes a tank and an agitator; if the machine helper 14 is a pump, the biotechnology fluid handler helper 21 includes fluid driving members such as the rollers of a peristaltic pump; and if the machine helper 14 is a pH or flow sensor, the biotechnology fluid handler helper 21 includes a pH probe and a flow probe, respectively. The physical connection between the fluid drive member (pump handler helper 21) and the tank+agitator (mixer fluid handler 15) involves pipes and folders to maintain the fluid drive member and tank+agitator in a predetermined relative position. For example, such folders may be performed by mounting the pump on the same or similar framework as the mixer, or by a cart on which the pump is mounted, and such cart is maintained in a fixed position relative to the mixer.

[0019] Similarly, a pH probe or flow probe must interact with the fluid and remain in place. Generally, the physical coupling includes interaction with the fluid (with or without contact, see the rollers of a peristaltic pump that are not in contact with the fluid or the IR probe of a temperature sensor that is not in contact with the fluid) and a folder to maintain the processor helper 21 relative to the fluid processor 15. The digital controller 22 is configured to control the processor helper 21, as indicated by the double-headed arrow in FIG. Digital controller 22 has the same architecture as digital controller 16: digital controller 22 includes a GUI manager 23, an MtoM communication tool 24, and a DNP manager 25. Digital controller 22 also includes a file 26 called a device shape that contains a description of the specific interface features of the GUI that can be displayed by GUI manager 23. In each system device 13 or 14, a GUI manager 17 or 23 makes it possible to display GUIs such as process and instrumentation diagrams (P&IDs) locally on an interactive screen or remotely on a device with an interactive screen, for example a tablet or smartphone. In each system device 13 or 14, an MtoM communication tool 18 or 24 is configured to connect to the network 12, as indicated by the double-headed arrow in FIG.

[0020] The DNP manager 19 of the bioprocessing machine 13 and the DNP manager 25 of the machine helper 14 are configured to cooperate over the network 12 to establish a pairing state. Each system device 13 or 14 may be used as a standalone device or may be paired with other appropriate system devices. The GUI manager 17 or 23 of each system device 13 or 14 is configured to undergo adaptation of the graphical user interface (GUI) when the system device transitions from a standalone (unpaired) state to a paired state with a GUI, and vice versa. For example, if the machine helper 14 is a pump that can be paired with a bioprocess machine 13, in the pump's standalone state, its GUI allows the user to control the pump, thereby allowing the user to utilize the pump as a standalone unit for tasks such as transferring liquid from one tank to another; on the other hand, when the pump is paired with the bioprocess machine 13, the pump's GUI no longer allows the user to control the pump, but only the bioprocess machine 13's GUI allows the pump to be controlled. Further, for example, if the machine helper 14 is a sensor that can be paired with the bioprocessing machine 13, such a sensor sensing a physicochemical or biological quantity of a biotechnology fluid, in the sensor's standalone state, its GUI will display the sensed quantity, allowing the user to utilize the sensor as a standalone unit, whereas in the sensor's paired state with the bioprocessing machine 13, the sensor's GUI will only display a message such as "Connected" to inform the user that the sensor is in a paired state, and the GUI of the bioprocessing machine 13 will display the quantity sensed by the sensor.

[0021] Typically, the GUI manager 17 of the bioprocess machine 13 and the GUI manager 23 of the machine helper 14 are configured in a paired state as follows: the GUI manager 17 of the bioprocess machine 13 has at least one provided capability that it does not have if it is not in a paired state, the provided capability being an interface function for controlling and / or displaying operational parameters of the processor helper 21 or displaying physicochemical or biological quantities of the fluid sensed by the processor helper 21; and - the GUI manager 23 of the machine helper 14 has at least one consumed capability that is changed with respect to when not in a pairing state, where if the provided capability is an interface function that controls and / or displays operational parameters of the processor helper 21, the consumed capability is the interface function that controls and / or displays the operational parameters, and if the provided capability is an interface function that displays physicochemical or biological quantities of a fluid sensed by the processor helper 21, the consumed capability is the interface function that displays the physicochemical or biological quantities.

[0022] ability The interface functions described in the device shape files 20 or 26 of the different system devices 13 and 14 are either of a first type or of a second type. The first type of interface functionality is interface functionality that the GUI manager 17 or 23 of the system device 13 or 14 does not have when the system device is not paired with an appropriate other system device, but that is supplemented by the GUI manager 17 or 23 when the system device 17 or 23 is paired with an appropriate other system device. In effect, the first type of interface functionality exists but is disabled when system device 13 or 14 is not paired with an appropriate other system device and is enabled when system device 13 or 14 is paired with an appropriate other system device. When enabled, each such interface function controls and / or displays an operating parameter of the paired system device or displays a quantity sensed by the paired system device, the quantity being a physicochemical or biological quantity of the biotechnology fluid being processed. For convenience of language, such interface features are designated herein as "capabilities" and, when enabled, as "provided capabilities."

[0023] The second type of interface functions are those that the system device's GUI manager 23, which is the machine helper 14, has in its original form when the system device is not paired with an appropriate other system device, and in a modified form when the system device is paired with an appropriate other system device. In its original form, each such interface feature controls and / or displays an operating parameter of the system device or displays a quantity sensed by the paired system device, the quantity being a physicochemical or biological quantity of the biotechnology fluid being processed. In its modified form, each such interface feature may, for example, be the same as the original form but with the addition of an indication indicating that the system device is paired with an appropriate other system device, or the original form may be replaced with an indication that the system device is paired with an appropriate other system device, such indication being, for example, an icon, a message, or the absence of an indication. Solely for convenience of language, such interface features are designated herein as "capabilities" and, in their modified form, as "consumed capabilities." Note that the device shape file 20 of the bioprocess machine 13 includes a description of the interface functions of its GUI manager 17; and the device shape file 26 of the machine helper 14 includes a description of at least one interface function of a second type of GUI manager 23. It is further noted that in device shape files 20 and 26, each capability description has a feature named "role" that identifies whether the capability is of a first type or a second type. In the first type, the role feature is in "consumer" and refers to the corresponding capability of the paired system device that becomes the "consumed capability" in the pairing state. Here, a system device 13 or 14 that has a capability with the role feature in "consumer" is called a capability consumer.

[0024] In the second type, the role characteristic is in "provider" and refers to the corresponding capability of the paired system device that becomes a "provided capability" in the pairing state, and a system device 14 that has a capability with the role characteristic in "provider" is referred to in this specification as a capability provider. Note that there is always a correspondence between capabilities provided and capabilities consumed. If the provided capability (in a capability consumer 13 or 14) is an interface function that controls and / or displays an operational parameter of the capability provider, then the consumed capability (in a capability provider 14) is the interface function that controls and / or displays this operational parameter. For example, if the provided capability of a mixer is the start / stop control of a paired pump, then the consumed capability of the paired pump is the start / stop control of this pump. If the capacity provided (at a capacity consumer 13 or 14) is an interface function that displays a physicochemical or biological quantity of a biotechnological fluid sensed by a capacity provider 14, then the capacity consumed (at a capacity provider 14) is the interface function that displays this physicochemical or biological quantity. For example, if the capacity provided at a mixer is an indication of the pH of a biotechnological fluid sensed by a paired pH sensor, then the capacity consumed at the paired pH sensor is an indication of the sensed pH.

[0025] The corresponding provided capacity and consumed capacity are referred to herein as "shared capacity." Each system device 13 or 14 has a device shape file 20 or 26 that can be evolved at design time and updated at run time to extend the list of capabilities available to capability consumers or available to capability providers over the life of the system device, allowing the system device to contribute to new platform features without having to modify (and recertify) software packages installed on the system device. We now describe examples of system devices 13 and 14 and how an installation for processing biotechnological fluids can be set up with these system devices. An example of a bioprocess machine 13 is a mixer (capacity consumer). Examples of a bioprocess machine helper 14 are a pH sensor (capacity provider), a flow sensor (capacity provider), and a pump (together a capacity consumer and a capacity provider).

[0026] Mixer Description The mixer contains a tank, an agitator within the tank, and two inlets to which pipes can be connected that can be used to fill the tank. The tank, the agitator, and the inlet form a biotechnology fluid processor 15 . To be operational, the mixer must be connected to at least one pump to allow the flow of biotechnology fluid through one of the inlets. The mixer contains a digital processing unit that includes an industrial programmable logic controller (PLC) and an industrial PC. The PLC is dedicated to the real-time control and monitoring of the various equipment modules to which it is connected (e.g., wirelessly or wired), such as the agitator or the valves that open and close the inlets. A software package is installed on the industrial PC and a file 20 called device geometry is stored. The digital processing unit, the installed software packages and the stored device geometry files 20 form the digital controller 16 . The installed software packages include: a DNP Manager 19; an MtoM communication tool 18, herein having an OPC UA server and an OPC UA client, for supporting data exchange with other system devices; and a GUI Manager 17, allowing for the display of process and instrumentation diagrams (P&IDs) locally on an interactive screen, e.g., a tablet or smartphone, or remotely on a device with an interactive screen. File 20, called the device configuration, contains descriptions of the four interface functions that will be provided when enabled.

[0027] A description of the capabilities available in the mixer software package As mentioned above, there are four such capabilities: interface function 1, interface function 2, interface function 3, and interface function 4, respectively. Interface function 1 When enabled, Interface Function 1 supplements the P&ID GUI with process data provided by the paired system device, whatever the paired system device is. This capability description means: The mixer, as a capability consumer with graphic skills, can display process values ​​from multiple paired system devices, and there are no restrictions or conditions on negotiation or pairing, if these paired system devices provide at least the process value, the name and unit of the process value, and optionally a valid decimal number using the OPC UA standard. In a variant, the list of properties further includes at least one of the following: In such a variation, the capability description further implies that the mixer can use the process value range to suggest an auxiliary type of display (such as a gauge) if provided by the paired system device.

[0028] Interface function 2 Enabling Capability Interface Feature 2 will conform the P&ID GUI and indicate if a mandatory expected pump is paired or not, and will add display of the control icons and operating parameters of the paired pump to the P&ID GUI. This capability description means: The mixer, as a capability consumer with control skill, must mandatorily pair with a system device, which is a pump, to achieve the role defined for the pump connected to inlet 1. To pair, the system device must mandatorily enable start / stop commands and provide the current start state. The mixer can control and monitor the pump speed, if offered by the paired system device. Confirmation by the operator is required during the pairing procedure. Once paired, the mixer has exclusive use of the system device, which is a pump. In a variant, the list of properties further includes at least one of the following: In such a variant, the capability description further means that the mixer can display minimum and maximum speed range values, if provided by the paired pump, to guide the operator when setting the pump speed.

[0029] Interface feature 3 Enabling Interface Feature 3 will adjust the P&ID GUI to show if a planned optional pump is paired and will add display of the control icons and operating parameters of the paired pump to the P&ID GUI. This capability description means that the mixer as a capability consumer with control skill can control an optional system device, which is a pump, to achieve the predefined role of a pump connected to inlet 2. To pair, the system device must force start / stop commands available and provide the current start state. The mixer can control and monitor the pump speed if provided by the paired system device. Confirmation by the operator is required during the pairing procedure. Once paired, the mixer can exclusively use the system device, which is a pump. In a variant, the list of properties further includes at least one of the following: In such a variant, the capability description further means that the mixer can display minimum and maximum speed range values, if provided by the paired pump, to guide the operator when setting the pump speed. Interface function 4 Enabling Interface Feature 4 allows the P&ID GUI to display other optional paired pumps and complements the P&ID GUI with display of control icons and operating parameters of paired pumps.

[0030] This capability description means that a mixer as a capability consumer with control skill can control any other system device that is a pump. No mandatory properties are assumed. A mixer can start / stop a pump and control and monitor the pump speed if provided by the paired system device. No confirmation by the operator is required during the pairing procedure. Once paired, a mixer can exclusively use a system device that is a pump. It should be noted that not all interface functions of the mixer GUI manager 17 have been described here. Interface functions relating to equipment modules in the mixer (such as agitators, inlet valve control, etc.) are not described here. Only interface functions that are disabled when the mixer is not paired with an appropriate system device and that are enabled when the mixer is paired with an appropriate system device are described; at least other such interface functions may be included in the mixer GUI manager 17. Further, it should be noted that the capabilities of Interface Function 2, Interface Function 3, and Interface Function 4 indicate three levels of capabilities that can result in provided capabilities, namely, predefined and mandatory capabilities such as Interface Function 2, predefined and optional capabilities such as Interface Function 3, and optional auxiliary capabilities such as Interface Function 4.

[0031] pH Sensor Description The pH sensor includes a probe for sensing the pH of a biotechnology fluid. The probe forms a biotechnology fluid handler helper 21. The pH sensor includes a digital processing unit that includes a microprocessor and / or microcontroller, memory and a network connection. The processing unit is configured to control and monitor the flow sensing probe and is electrically wired to the probe. The processing unit has a software package installed and stores a file 26 called the device geometry. The processing unit, the installed software packages and the stored device configuration files 26 form the digital controller 22 . The installed software packages have the same architecture as the software packages installed on the mixer, the software packages installed on the pH sensor include: a DNP manager 25; an MtoM communication tool 24 with an OPC UA server and an OPC UA client supporting data exchange with other system devices; a GUI manager 23 allowing to remotely display a GUI on devices with interactive screens such as tablets and smartphones. A file 26 called device configuration contains a description of one interface function that is a capability consumed when in modified form.

[0032] Description of capabilities available in the pH sensor software package: If you modify a single interface function described in the device shape file for a pH sensor, it will retain the display of the current value measured by the pH sensor, display a trend curve showing the change in pH over time, and indicate that the pH sensor is paired with the appropriate other system devices. This capability description means that the pH sensor as a capability provider can provide a pH (and only pH) process value display dataset to a paired system device using the OPC UA standard. The dataset contains the process value, its name, and its unit. The OPC UA tag values ​​for each data item are specified so that the paired system device can read these values ​​with an OPC UA client. There are no particular restrictions or conditions on the negotiation or pairing. In a variant, the data set further includes at least one of a minimum or maximum value of a range of values ​​within which the pH process value is expected to be found.

[0033] Description of the flow sensor The flow sensor includes a probe for sensing the flow of a biotechnology fluid, the probe forming a biotechnology fluid handler helper 21. The flow sensor includes a digital processing unit that includes a microprocessor and / or microcontroller, memory, and a network connection. The processing unit is configured to control and monitor the flow sensing probe and is electrically wired to the probe. The processing unit has a software package installed and stores a file 26 called the device geometry. The processing unit, the installed software packages and the stored device configuration files 26 form the digital controller 22 . The installed software package has the same architecture as the software package installed on the mixer, and includes: a DNP manager 25; an MtoM communication tool 24 with an OPC UA server and an OPC UA client supporting data exchange with other system devices; and a GUI manager 23 allowing the GUI to be displayed remotely on a device with an interactive screen, e.g. a tablet or smartphone. A file 26 called device configuration contains a description of one interface function that is a capability consumed when in modified form.

[0034] A description of the capabilities available in the flow sensor software package In the modified form, the single interface function described in the flow sensor's device form factor is replaced with a display of the current value measured by the flow sensor, and a trend curve represents the change in current over time with an indication that the flow sensor is paired with an appropriate other system device. This capability description means that the flow sensor, as a capability provider, can provide flow (and only flow) process value display data sets to paired system devices using the OPC UA standard. The data set contains the process values, their names, and their units. The OPC UA tag values ​​for each data are specified so that the paired system device can read these values ​​with an OPC UA client. There are no particular restrictions or conditions on the negotiation or pairing. In a variation, the data set further includes at least one of a minimum or maximum value of a range of values ​​within which the flow process value is expected to be found.

[0035] Pump Description The pump includes members that act on the fluid to drive it, such as the rollers of a peristaltic pump, and a motor that drives such members. The drive motor and the driven members that act on the fluid form a biotechnology fluid processor helper 21. The pump includes a digital processing unit that includes a microprocessor and / or microcontroller, memory, and a network connection. The processing unit is configured to control and monitor the electrically wired motor. The processing unit has a software package installed and stores a file 26 called the device geometry. The processing unit, the installed software packages and the stored device configuration files 26 form the digital controller 22 . The installed software packages have the same architecture as the software packages installed on the mixer: the software packages installed on the pump include: a DNP Manager 25; an MtoM communication tool 24 with an OPC UA server and an OPC UA client supporting data exchange with other system devices; and a GUI Manager 23 that can remotely display a GUI on devices with interactive screens such as tablets and smartphones. The file, called device shape, contains a description of the interface capabilities that are the capabilities provided when enabled (interface capabilities 1) and a description of the interface capabilities that are consumed in modified form (interface capabilities 2).

[0036] A description of the capabilities available in the pump software package As mentioned above, there are two such functions: interface function 1 and interface function 2. Interface function 1 Enabling interface feature 1 will supplement the GUI with data provided by the paired system device, whatever that may be. This capability description means: The pump, as a capability consumer with graphic skills, can optionally display at least one flow process value, the name and unit of the process value using the OPC UA standard, if the system device it is paired with provides at least that process value. No other restrictions or conditions are imposed on negotiation or pairing, except for the maximum number of allowed pairings. In such variations, the capability statement further means that the paired system device can optionally provide minimum and maximum values ​​for a range associated with the flow process value. Interface function 2 In its original form, interface function 2 displays the pump motor speed and has a control icon that allows the pump motor to be started / stopped, and another control icon that allows the pump motor speed to be set. In its modified form, the two control icons have been removed from the GUI, leaving only the pump motor speed display. This capability description means that Pump 13, as a capability provider with the pumping skill, can provide control and monitoring of its pumping functionality using the OPC UA standard. Paired system devices have exclusive use of the pumping functionality and can start / stop the pump, set the pump speed, and get the current pumping status and speed. OPC UA tag values ​​for each of the control and monitoring are specified so that consumers can use the pump in their OPC UA clients. In such variations, the capacity description further means that the pump 13 is capable of providing a minimum and a maximum value for the speed range.

[0037] Discovery, Negotiation, Pairing (DNP) It will now be described how system devices 13 and 14 can cooperate over network 12 to establish a paired state. This is performed primarily by DNP managers 19 and 25 in system devices 13 and 14 through the discovery, negotiation, and pairing steps described below. detection When connected to a network using IP (e.g., Ethernet, Wi-Fi, Bluetooth, or cellular such as 5G), a system device can recognize other connected system devices, including discovery tools. Several architectures already exist that allow discovery across a network (e.g. the "Bonjour" protocol defined by Apple®, here the global or local discovery proposed by the OPC UA standard). Visibility is only limited by the underlying security policies in place on the network. Discovery tools allow a system device to maintain an up-to-date list of visible system devices with which it can exchange information. This list is specifically updated when new system devices are connected to or disconnected from the network.

[0038] negotiation Based on the capability descriptions provided in the device shape files, a negotiation is initiated between connected system devices: Now, each system device on the network: looks up the capability descriptions indicated by other system devices, identifies matching capabilities based on capability feature domain, purpose and role, verifies that it can respect the restrictions and conditions associated with the matching capabilities, and checks if the list of properties indicated in the matching capabilities is the one expected. The negotiation procedure occurs whenever a new system device is discovered on the network, disconnected from the network, or becomes unreachable. Pairing Once negotiation is achieved, the various contributors agree on how to adapt their shared features to respect the stated limitations and conditions. Pairing completes the procedure and confirms the negotiation between two system devices. The capability consumer (respectively a provider) remembers the identity and location (here an OPC UA endpoint) of the provider (respectively a consumer) to enable later data exchange.

[0039] Both the capability consumer and capability provider apply the restrictions and conditions (if any) agreed upon during negotiation. A capability consumer locally publishes access to a list of properties in the device shape file of the consumed capability so that a GUI manager installed on the capability consumer can exchange data with its paired capability provider. This can be achieved, for example, using a standard publication / subscription approach: when a system device is powered on, a specific data queue is created by the DNP manager for each different pair (domain, purpose) described in the device shape file; the GUI manager subscribes to the (domain, purpose) queues it is interested in; every time a pairing occurs, the DNP manager publishes access information to the corresponding (domain, purpose) data queue; the GUI manager subscriber to this queue is automatically triggered to access the description and adapts accordingly. Certain situations may arise where different system devices on the network may be able to offer certain capabilities that a consumer expects, in which case the pairing may require a decision by a human operator to manually select the capability provider. Even if the conditions are explicitly expressed in the capability description, there will be situations where operator approval is required. Note that unpairing requires operator intervention to be able to distinguish between an intentional disconnection of a system device and a communication failure. In the absence of such voluntary user action, the disconnection of the system device is deemed abnormal and appropriate action is taken, such as generating an alarm. Here, the description of canceling pairing will be explained.

[0040] Unpairing As previously mentioned, unpairing a system device from another system device with which it is paired requires a voluntary and explicit action of the user, allowing for distinction between an intentional disconnection of the system devices and a communication failure. This may be accomplished, for example, by providing a dedicated menu accessible to the user on the graphical user interface of the system device, such menu listing each other system device with which the system device is paired, and from such menu, the user may explicitly request unpairing with a system device selected in the menu's list. When the user requests unpairing with other selected system devices, (i) steps are taken to remove the effects of the pairing steps, (ii) steps are taken to remove the effects, if any, of the negotiation steps, and (iii) steps are taken to temporarily prevent the system device and the other selected system devices from performing negotiation steps. To undo the effects of the pairing step, the DNP manager 19 or 25 of the system device locally issues a status change for each capability consumed or provided from the selected other system device and sends a request to proceed to unpairing to the selected other system device via the MtoM communication tool 18 or 24. The DNP manager 19 or 25 of the selected other system device then locally issues a status change for each capability consumed from or provided to the system device and sends an acknowledgement of the request to proceed to unpairing to the system device via the MtoM communication tool 18 or 24.

[0041] At the system device, and at selected other system devices, the GUI manager 17 or 23 is alerted to the state changes of each relevant capability and adapts accordingly. To undo the effects of the negotiation step, if any, restrictions and conditions (e.g., exclusivity) that the capability consumer and capability provider agreed upon during negotiation are applied, these restrictions and conditions become ineffective. Now that previously shared capabilities are once again available for negotiation, isolation may be implemented by temporarily preventing the system device and selected other system devices from performing the negotiation step, for example using a timeout, e.g., not accepting the associated system device in the negotiation step for a predetermined period of time, the length of which is not critical but could be, e.g., 1 minute, 2 minutes, 3 minutes, 4 minutes, 5 minutes, 10 minutes, etc., or by ignoring the associated system device until it has disconnected from the network and reconnected to the network connection. We now describe in detail the pairing of a mixer with a pH sensor, with a pump and flow sensor, with a previously paired mixer with a pH sensor, with a previously paired pump and flow sensor, and the removal of a paired pump and flow sensor from a mixer while the pH sensor remains paired with the mixer.

[0042] Pairing the mixer with a pH sensor Mixer GUI Features Once the operator powers up the mixer, the basic P&ID GUI shown in Figure 4 can be accessed either locally on an interactive screen or remotely on a device with an interactive screen such as a tablet or smartphone. The basic P&ID GUI represents the various components required for the mixing process, with icon 27 representing a tank with an agitator, icon 28 representing a required pump in fluid communication with inlet 1 of the tank, and icon 29 representing an optional pump in fluid communication with inlet 2 of the tank. In a basic P&ID GUI, icon 27 is displayed in a manner that indicates that a tank with an agitator is present and in operation (e.g., displayed with a persistent solid line), icon 28 is displayed in a manner that indicates that a required pump is missing (e.g., displayed with a flashing dash-dot line), and icon 29 is displayed in a manner that indicates that an optional pump is not present (e.g., displayed with a persistent dash-dot line). The manner in which the two icons 28 and 29 representing the pumps are displayed depends on the pairing status and is automatically updated to indicate that the corresponding pump system device is paired (e.g., by displaying the icons with a persistent solid line).

[0043] Further description of the P&ID GUI for pairing with a pump will be given later in the section on pairing a mixer with a pump. Next, description of the P&ID GUI for pairing with a pH sensor will be given. When a mixer is powered on, its DNP manager creates a capability data queue ("Graphics", "Process Value Display") to the mixer's digital controller. The pump's GUI manager subscribes to the capability data queue ("Graphics", "Process Value Display") and displays a basic P&ID GUI until a new capability description is published on this queue. Later, when a system device offering a capability ("Graphics", "Process Value Display") with the expected properties is paired with the mixer, the mixer's DNP manager publishes a description of this capability to the ("Graphics", "Process Value Display") data queue, triggering the GUI manager to access the published description and adapt the P&ID GUI accordingly by additionally displaying the current process value (here pH) and the process value trend curve 30, as shown in the top part of Figure 5. In fact, as mentioned above, the Mixer's device shape file contains a capability named Interface Capability 1, which when enabled, supplements the P&ID GUI with process data provided by the paired system device, whatever the paired system device may be; this capability has the description: As a capability consumer with graphics skills, the Mixer can display process values ​​from multiple paired system devices, provided that the paired system devices provide at least the process value, the name and unit of the process value, and optionally a valid decimal number using the OPC UA standard. There are no restrictions or conditions on negotiation or pairing.

[0044] pH Sensor GUI Features Once an operator powers up the pH sensor, they can remotely access the original GUI, shown in the bottom left of Figure 5, on a device with an interactive screen, such as a tablet or smartphone. The original GUI includes the current value 31 measured by the pH sensor and a trend curve 32 representing the change in pH over time. When a pH sensor is powered on, its DNP manager creates a capability data queue ("Graphics", "Process Value Display") to the pH sensor's digital controller. The pH sensor's GUI manager subscribes to the capability data queue ("Graphics", "Process Value Display") and displays the original GUI until a new capability description is published on this queue. Later, when a system device using a capability ("Graphics", "Display Process Values") with the expected characteristics is paired with the pH sensor, the pH sensor's DNP manager will publish a description of this capability to the ("Graphics", "Display Process Values") data queue and additionally display the message "Connected" 33, which will trigger the GUI manager to access the published description and adapt the GUI accordingly, as shown in the bottom right of Figure 5. Indeed, as mentioned above, the device shape file of the pH sensor contains a capability, in the case of a modified form, that holds an indication of the current value measured by the pH sensor and a trend curve representing the change in pH over time, and adds an indication that the flow sensor is paired with a suitable other system device, this indication here being the message "connected" 33; this capability has a description that means: The pH sensor, as a capability provider, can provide pH (and only pH) process value display datasets to paired system devices using the OPC UA standard. The dataset contains the process value, its name, and its unit. The OPC UA tag value for each data item is specified so that the paired system device can read these values ​​with an OPC UA client. There are no particular restrictions or conditions on the negotiation or pairing.

[0045] pH Sensor GUI Features Once an operator powers up the pH sensor, they can remotely access the original GUI, shown in the bottom left of Figure 5, on a device with an interactive screen, such as a tablet or smartphone. The original GUI includes the current value 31 measured by the pH sensor and a trend curve 32 representing the change in pH over time. When a pH sensor is powered on, its DNP manager creates a capability data queue ("Graphics", "Process Value Display") to the pH sensor's digital controller. The pH sensor's GUI manager subscribes to the capability data queue ("Graphics", "Process Value Display") and displays the original GUI until a new capability description is published on this queue. Later, when a system device using a capability ("Graphics", "Display Process Values") with the expected characteristics is paired with the pH sensor, the pH sensor's DNP manager will publish a description of this capability to the ("Graphics", "Display Process Values") data queue and additionally display the message "Connected" 33, which will trigger the GUI manager to access the published description and adapt the GUI accordingly, as shown in the bottom right of Figure 5. Indeed, as mentioned above, the device shape file of the pH sensor contains a capability, in the case of a modified form, that holds an indication of the current value measured by the pH sensor and a trend curve representing the change in pH over time, and adds an indication that the flow sensor is paired with a suitable other system device, this indication here being the message "connected" 33; this capability has a description that means: The pH sensor, as a capability provider, can provide pH (and only pH) process value display datasets to paired system devices using the OPC UA standard. The dataset contains the process value, its name, and its unit. The OPC UA tag value for each data item is specified so that the paired system device can read these values ​​with an OPC UA client. There are no particular restrictions or conditions on the negotiation or pairing.

[0046] Continuing with the pH sensor, in preparation for the adaptation, the GUI manager 23 subscribes to the data queues ("Graphics", "Process Value Display") created by the DNP manager 25 and displays the original form of the GUI. The mixer then connects to the network and performs a similar procedure according to its device configuration file 20, as described in more detail below. To enable DNP, in the mixer, the DNP manager 19 provides data to the MtoM communication tool 18 to make available the capability descriptions in the device shape file 20, i.e., interface function 1, interface function 2, interface function 3, and interface function 4, including the properties of each capability description; and the DNP manager 19 creates data queues ("Graphics", "Process Value Display") for capability interface function 1, and ("Control", "Pumping") for capabilities interface function 2, interface function 3, and interface function 4, in the mixer's digital controller 16. The MtoM communication tool 18 then waits to detect another system device on the network. Still within the mixer, in preparation for adaptation, the GUI manager 17 subscribes to the ("Graphics", "Process Value Display") and ("Control", "Pumping") data queues created by the DNP manager and displays a basic P&ID GUI.

[0047] In the pH sensor, when the MtoM communication tool 24 detects that a mixer is connected to the network 12, it notifies this to the DNP manager 25, which requests the MtoM communication tool 24 to provide the capability description indicated by the mixer. Once provided, the capability description is reviewed by the DNP manager 25, which identifies a match between the capability interface function 1 made available by the mixer and the local capability with applicable restrictions / conditions. The DNP manager 25 then requests the MtoM communication tool 24 to suggest to the mixer to apply the pairing between the local capability and the capability interface function 1 in the mixer. When the MtoM communication tool 24 receives the pairing acceptance, it provides the pairing acceptance to the DNP manager 25, which publishes a description of the mixer capability interface function 1 in the ("Graphics", "Process Value Display") data queue and requests the MtoM communication tool 24 to confirm the application of the mixer capability interface function 1. The GUI manager 23 is automatically notified about the publication in the ("Graphics", "Process Value Display") data queue, receives the description of the mixer capability interface function 1 and thus displays a modified form of the GUI, i.e. additionally displays the message "Connected" 33. The modified form of the GUI is displayed until unpairing occurs.

[0048] In the mixer, when the MtoM communication tool 18 detects that a pH sensor is connected to the network 12, it notifies this to the DNP manager 19, which requests the MtoM communication tool 18 to provide the capability description indicated by the pH sensor. Once provided, the capability description is reviewed by the DNP manager 19, which identifies a match between the capability interface functions 1 made available by the pH sensor and the local capabilities with applicable limitations / conditions. When the MtoM communication tool 18 receives confirmation of the application of the capability interface function 1 from the pH sensor, the confirmation is forwarded to the DNP manager 19, which publishes a description of the pH sensor's capabilities to the ("Graphics", "Process Value Display") data queues. The GUI manager 17 is automatically notified of the publication in the data queue ("Graphics", "Process Value Display") and receives a description of the pH sensor's capabilities, including the OPC UA tag for the flow value opc.tcp: / / pH / 4:control / 4:V, and adapts the P&ID GUI, i.e. by additionally displaying the current pH value and the pH value trend curve 30, and thanks to the OPC UA client in the MtoM communication tool 18, the tag provided for the pH value is used to continuously update the pH value until unpairing occurs.

[0049] Pairing the Pump and Flow Sensor Pump GUI Features Once the operator turns on the pump, they can remotely access the basic GUI shown in the center left of Figure 6 from any device with an interactive screen, such as a tablet or smartphone. The basic P&ID GUI includes a start / stop button 34 that allows operation of the pump, a variator 35 that allows changing the pump speed, a display of the current pump speed 36 and a curve display 37 that represents the change in pump speed over time. When a pump is powered on, its DNP manager 25 creates a capability data queue ("graphics", "process value display") in the pump's digital controller 22. The pump's GUI manager 23 subscribes to the capability data queue ("graphics", "process value display") and displays a basic GUI until a new capability description is published to this queue. Later, when a system device offering a capability ("Graphics", "Process Value Display") with the expected characteristics is paired with the pump, the pump's DNP manager 25 publishes this capability description to the ("Graphics", "Process Value Display") data queue, triggering the GUI manager 23 to access the published description and adapt the GUI accordingly by additionally displaying the current flow value and the flow value trend curve 38, as shown in the center right of FIG. 6. Indeed, as mentioned above, the pump's device shape file contains a capability named Interface Capability 1 that, when enabled, complements the GUI with data provided by the paired system device; this capability has the description: The pump, as a capability consumer with graphic skills, can optionally display only one flow process value, using the OPC UA standard, if the paired system device provides at least the process value, the name of the process value, and the unit. No other restrictions or conditions are imposed on the negotiation or pairing, except for the maximum number of allowed pairings.

[0050] Flow Sensor GUI Features Once an operator powers up the flow sensor, they can remotely access the original GUI, shown in the bottom left of Figure 6, on a device with an interactive screen, such as a tablet or smartphone. The original GUI includes a display of the current value 39 measured by the flow sensor and a display of a trend curve 40 representing the change in flow rate over time. When a flow sensor is powered on, its DNP manager 25 creates a capability data queue ("graphics", "process value display") in the flow sensor's digital controller 22. The flow sensor's GUI manager 23 subscribes to the capability data queue ("graphics", "process value display") and displays the original GUI until a new capability description is published to this queue. Later, when a system device using a capability ("Graphics", "Display Process Values") having the expected properties is paired with the flow sensor, the flow sensor's DNP manager 25 publishes this capability description to the ("Graphics", "Display Process Values") data queue, triggering the GUI manager 23 to access the published description and adapt the GUI accordingly by simply displaying the message "Connected" 41, as shown in the bottom right of FIG. 6.

[0051] Indeed, as mentioned above, the device shape file 26 of the flow sensor contains a capability, which in its modified form replaces the display of the current values ​​measured by the flow sensor and the display of the trend curve representing the change in flow over time by an indication that the flow sensor is paired with a suitable other system device, this indication being here the message "connected" 41; this capability has the description: The flow sensor, as a capability provider, can provide flow (and only flow) process value display datasets to the paired system device using the OPC UA standard. The dataset contains the process values, their names and their units. The OPC UA tag values ​​for each data are specified so that the paired system device can read these values ​​with an OPC UA client. There are no particular restrictions or conditions on the negotiation or pairing.

[0052] DNP sequencing The operator connects the pump and the flow sensor to the same network 12 (FIG. 3). The DNP described above is performed, and once executed, the pump GUI and flow sensor GUI are automatically updated: the pump P&ID GUI additionally displays the current flow value and the flow value trend curve 38; the flow sensor GUI only displays the message "Connected" 41. Of course, in order for the flow sensor to be able to sense the flow of fluid driven by the pump, the flow sensor must be physically connected in a known manner to the pump or to a pipe through which the fluid driven by the pump flows, as shown at the top of FIG. 6 by reference numeral 42. Note that because the pump and flow sensor are both machine helpers 14, the physical connection 42 is between the two processor helpers 21 (not between the fluid processor 15 and the processor helper 21). Further noteworthy, the pump's DNP manager 25 can act as the bioprocess machine's 13's DNP manager 19 towards the flow sensor's DNP manager 25, and collaborate via the network 12 to establish a pairing state between the pump and the flow sensor, thanks to the fact that the capability pump's interface function 1 has the role characteristic "Consumer", just like each capability in the device shape file 20 of the bioprocess machine 13. The message "Connected" 41 on the flow sensor GUI clearly indicates that the flow sensor is in a pairing state rather than a standalone state. An example of the DNP sequence will now be described in detail. In this example, the flow sensor is initially connected to the network 12 using IP, although of course the reverse is also possible. Since the flow sensor is a capability provider for the capabilities described in the device shape file 26, as long as the flow sensor is connected to the network 12, its MtoM communication tool 24 will be provided with the sensed flow value in real time and make it available on the network 12 by virtue of the OPC UA server that contains it at the OPC UA endpoint specified in the capability description in the device shape file 26, i.e. opc.tcp: / / flow / 4:control / 4:.

[0053] To enable DNP, in the flow sensor, the DNP manager 25 provides data to the MtoM communication tool 24 to make available a capability description in a device shape file 26 that contains the properties of the capability description; the DNP manager 25 creates a data queue for this capability ("graphics", "process value display") in the flow sensor's digital controller 22. The MtoM communication tool 24 then waits to detect other system devices on the network 12. Still at the flow sensor, in preparation for the adaptation, the GUI manager 23 subscribes to the data queues ("Graphics", "Process Value Display") created by the DNP manager 25 and displays the original form of the GUI. The pump then connects to the network and performs a similar procedure according to its device's configuration file 26, as described in more detail below. With regard to the Capability Interface Function 2 (the pump is the capability provider), as long as the pump is connected to the network 12, its MtoM communication tool 24 will be provided with the real-time operational parameters of the pump (start / stop control, start status, speed settings and values), which will be available on the network 12 thanks to the OPC UA server that encompasses the OPC UA endpoints opc.tcp: / / start, opc.tcp: / / started, and opc.tcp: / / speed / 4, respectively, specified in the capability description in the device shape file 26. To enable DNP, at the pump, the DNP manager 25 provides data to the MtoM communication tool 24 to make available the capability descriptions in the device shape file 26, i.e., interface function 1 and interface function 2, with properties in each capability description; the DNP manager 25 creates data queues for capability interface function 1 ("Graphics", "Process Value Display") and capability interface function 2 ("Control", "Pumping") in the pump's digital controller 22. The MtoM communication tool 24 then waits to detect another system device on the network 12. Still inside the pump and in preparation for adaptation, the GUI Manager 23 subscribes to data queues created by the ("Graphics", "Process Value Display") and ("Control", "Pumping") DNP Manager 25 and displays a basic GUI.

[0054] In the flow sensor, when the MtoM communication tool 24 detects that a pump is connected to the network 12, it notifies this to the DNP manager 25, which requests the MtoM communication tool 24 to provide a capability description indicated by the pump. Once provided, the capability description is reviewed by the DNP manager 25, which identifies a match between the capability interface function 1 indicated by the pump and a local capability with applicable limitations / conditions. The DNP manager 25 then requests the MtoM communication tool 24 to propose to the pump to apply the pairing between the local capability and the capability interface function 1 in the pump. When the MtoM communication tool 24 receives the pairing acceptance, it provides the pairing acceptance to the DNP manager 25, which publishes a description of the pump's capabilities interface function 1 in the ("Graphics", "Process Value Display") data queue and requests the MtoM communication tool 24 to confirm the application of the pump's capabilities interface function 1. The GUI manager 23 is automatically notified of the publication in the ("Graphics", "Process Value Display") data queue, receives the description of the pump's capabilities interface function 1, i.e. displays a modified form of the GUI, i.e. displays only the message "Connected" 41. The modified form of the GUI is displayed until unpairing occurs.

[0055] At the pump, when the MtoM communications tool 24 detects that a flow sensor is connected to the network 12, it notifies the DNP manager 25, which requests the MtoM communications tool 24 to provide a description of the capabilities exhibited by the flow sensor. Once provided, the capability description is reviewed by the DNP manager 25, which identifies a match between the capability interface functions 1 made available by the flow sensor and the local capabilities with applicable limitations / conditions. When the MtoM communication tool 24 receives confirmation of application of capability interface function 1 from the flow sensor, the confirmation is forwarded to the DNP manager 25, which publishes a description of the flow sensor's capabilities in a data queue ("Graphics", "Process Value Display"). The GUI manager 23 is automatically notified of the publication in the data queue ("Graphics", "Process Value Display") and receives a description of the capabilities of the flow sensor, including the OPC UA tag of the flow value opc.tcp: / / flow / 4:control / 4:V, and adapts the GUI as shown in the center right of Figure 6, i.e. by further displaying the current flow value and the flow value trend curve 38, and thanks to the OPC UA client in the MtoM communication tool 24, the tag provided for the flow value is used to continuously update the flow value until unpairing occurs.

[0056] It should be noted that the pump's device shape file 26 has an additional capability that enables the pump to provide flow values ​​sensed by a flow sensor as if the flow sensor were part of the pump. This will be discussed later, but for now it is sufficient to note that this allows a flow trend curve to be included in the control panel 44 of the mixer's P&ID GUI, as shown at the top of Figures 7 and 8.

[0057] Pairing a previously paired mixer and pH sensor with a previously paired pump and flow sensor Further Mixer GUI Features When paired with a pH sensor as described above, the mixer’s P&ID GUI is supplemented with a display of the pH value and a display of the pH value trend curve, as shown at the top of Figure 5, for a basic P&ID. As previously discussed, the basic P&ID GUI shown in FIG. 4 has icon 27 representing a tank with an agitator, icon 28 representing a required pump in fluid communication with inlet 1 of the tank, icon 29 representing an optional pump in fluid communication with inlet 2 of the tank, icon 27 displayed in a manner indicating that the tank with an agitator is present and in operation (e.g., displayed as a persistent solid line), icon 28 displayed in a manner indicating that the required pump is missing (e.g., displayed as a flashing dash-dot line), and icon 29 displayed in a manner indicating that the optional pump is not present (e.g., displayed as a persistent dash-dot line). The manner in which the two icons 28 and 29 representing the pumps are displayed depends on the pairing status and is automatically updated to indicate that the corresponding pump system device is paired (e.g., by displaying the icons with a persistent solid line). Further details regarding pairing with a pH sensor are provided elsewhere herein. More details on pairing with a pump will be provided below.

[0058] When a mixer is powered up, its DNP manager 19 creates a ("Control", "Pumping") capability data queue in the mixer's digital controller 16. The mixer's GUI manager 17 subscribes to the ("Control", "Pumping") capability data queue. Icon 28 is displayed in a manner indicating there is no mandatory pump (e.g., displayed with a blinking two-dot dash line) until a new capability description with Control_Local_Name equal to "Pump_on_inlet1" is published in this queue. Icon 29 is displayed in a manner indicating there is no optional pump (e.g., displayed with a permanent two-dot dash line) until a new capability description with Control_Local_Name equal to "Pump_on_inlet2" is published in this queue. Later, when a system device offering a ("control", "pumping") capability is paired with the mixer, the mixer's DNP manager 19 publishes a description of this capability completed with a Control_Local_Name equal to "Pump_on_inlet1" in the ("control", "pumping") capability data queue, triggering the GUI manager 17 to access the published description and adapt the P&ID GUI accordingly by displaying icon 28 in a manner indicating that the required pump is paired (e.g., displayed with a persistent solid line), as shown in the top right of Figure 7.

[0059] Indeed, as mentioned above, the Mixer's device shape file 20 contains a capability named Interface Capability 2 which, when enabled, adapts the P&ID GUI to display whether the required expected pump is paired or not, and supplements the P&ID GUI with the display of the control icons and the operating parameters of the paired pump, and this capability has a description which means: The Mixer, as a capability consumer with control skills, must forcefully pair a system device that is a pump to the pump connected to inlet 1 to achieve the role defined. To pair, the system device must force start / stop commands available and provide the current start state. The mixer can control and monitor the pump speed if provided by the paired system device. Confirmation by the operator is required during the pairing procedure. Once paired, the mixer has exclusive use of the system device that is the pump. Similarly, later, when a system device offering a ("control", "pumping") capability is paired with the mixer, the mixer's DNP manager 19 will publish a description of this capability completed with a Control_Local_Name equal to "Pump_on_inlet2" in the ("control", "pumping") capability data queue, triggering the GUI manager 17 to access the published description and adapt the P&ID GUI accordingly by displaying icon 29 in a manner indicating that an optional pump is paired (e.g., displayed with a persistent solid line).

[0060] Indeed, as mentioned above, the Mixer's device shape file 20 includes a capability named Interface Function 3 which, when enabled, adapts the P&ID GUI to indicate whether a planned optional pump is paired and complements the P&ID GUI with the display of the control icon and the operating parameters of the paired pump; this capability has a description which means: The Mixer, as a capability consumer with control skill, can control an optional system device, which is a pump, to achieve the predefined role of the pump connected to inlet 2. To pair, the system device must force start / stop commands available and provide the current start state. The mixer can control and monitor the pump speed if provided by the paired system device. Confirmation by the operator is required during the pairing procedure. Once paired, the mixer has exclusive use of the system device that is the pump. Further Pump GUI Features The operator connects the pumps to the same network 12 . When the mixer detects a pump, the mixer's P&ID GUI alerts the operator (e.g., in a pop-up window, not shown display) and requests the operator to select one of the possible pumps to ensure that a pump that meets the expected requirements is available and can be used. Once the operator has physically connected the pump to inlet 1 of the mixer, selected inlet 1 can be selected. The flow sensor GUI remains unchanged, ie, message 41 is displayed, as shown at the bottom of FIG. The mixer P&ID GUI and pump GUI will update automatically.

[0061] In the mixer's P&ID GUI, as shown at the top of Figure 7, an icon 28 appears to indicate that the required pump at inlet 1 is present and operating (e.g., displayed as a persistent solid line), and a control panel 44 appears in the mixer's P&ID GUI to allow the operator to control and monitor the pump at inlet 1. The control panel 44 includes a start / stop button that allows the operator to operate the pump, a variator that allows the pump speed to be changed, and a display of a trend curve that represents the variation in flow rate measured by the flow meter paired with the pump. In the pump GUI, the start / stop button 34 that allows to operate the pump and the variator 35 that allows to change the pump speed are released, as shown in the center of Figure 7. Only the flow rate and speed display are retained. When a pump is powered on, its DNP manager 25 creates a ("control", "pumping") capability data queue in the pump's digital controller 22. The pump's GUI manager 23 subscribes to the ("control", "pumping") capability data queue and displays a basic GUI until a new capability description is published to this queue. Later, when a system device offering a ("control", "pumping") capability with expected characteristics is paired with the pump, the pump's DNP manager 25 publishes a description of this capability in the ("control", "pumping") capability data queue, triggering the GUI manager 23 to access the published description and adapt the GUI accordingly by releasing the start / stop button 34 that allows the pump to be operated and the variator 35 that allows the pump speed to be changed.

[0062] Indeed, as mentioned above, the pump's device shape file 26 contains a capability named Interface Function 2, which in its original form has a control icon (button 34) that can display the pump motor speed and start / stop the pump motor, and a control icon (variator 35) that can set the pump motor speed. In its modified form, the two control icons are removed from the GUI and only the display of the pump motor speed is displayed; this capability has a description that means: The pump, as a capability provider with the pumping skill, can provide control and monitoring of the pumping function using the OPC UA standard. The paired system device has exclusive use of the pumping function and can start / stop the pump, set the pump speed, and get the current start state and speed. The OPC UA tag values ​​for each of the control and monitoring are specified, so that the pump can be used by the consumer in an OPC UA client.

[0063] DNP sequencing Since the mixer (previously paired with the pH sensor) and the pump (previously paired with the flow sensor) are deployed on the same network 12, they are able to recognize each other and begin the negotiation step. The pump makes available the capability interface function 2. The mixer makes available three capabilities ("control", "pumping") with the same domain and purpose: capability interface function 2 that requires the pumping system to be forcefully paired to achieve a role defined for the pump connected to inlet 1; capability interface function 3 that allows the mixer to control and monitor an optional pumping system to achieve a role defined for the pump connected to inlet 2; and capability interface function 4 that allows the mixer to control and monitor other optional pumping systems.

[0064] All three abilities match the abilities the pump exhibits. If the negotiation is successful, the pairing procedure can begin. The capability that the pump exhibits has one restriction / condition defined: "Only one system can be paired with the pump to use this capability." Since there is no system yet paired with the pump that uses this capability, this condition is confirmed and pairing becomes possible. Two of the three capabilities that the mixer has have one restriction / condition defined: "Operator confirmation is required when pairing." Pairing is only achieved if confirmed by the operator. A warning message is then displayed by the mixer's P&ID GUI (not shown, e.g., in a pop-up window) requesting the operator to assign the pump to one of three possible usages. Once the operator has assigned the pump to inlet 1, the pairing procedure continues. Both the mixer and the pump store the identity and location (OPC UA endpoint) of the paired system for this functionality. In the depicted example, only the mixer uses this information to control and monitor the pump at a later time. Pairing also prevents the pump from pairing with another system that has this capability.

[0065] For both mixers and pumps, the DNP manager 19 or 25 publishes a capability description to the capability data queue ("control", "pumping"). On the mixer side, this function is published with the value of "control application" set to "Pump_on_inlet1" to match the selection made by the operator. As mentioned above, for both mixers and pumps, the GUI manager 17 or 23 subscribes to the capabilities data queue and updates automatically. In a variation not shown, instead of being released from the pump GUI, the start / stop button 34 and variator 35 are released when the pump is paired with a suitable other system device such as a mixer, and only the variator 35 is released from the pump GUI, while the start / stop button 34 is maintained.

[0066] Removing the paired pump and flow sensor from the mixer while the pH sensor remains paired to the mixer As previously mentioned, unpairing a system device from another system device with which it is paired requires a voluntary and explicit action of the user, which allows for distinction between an intentional disconnection of the system devices and a communication failure. This is done by providing dedicated menus (not shown in the drawings) that the user can access in the GUI of each system device, so in this example there are such dedicated menus in the mixer P&ID GUI, each of the pH sensor GUIs, the pump GUI and the flow sensor GUI. This dedicated menu lists each other system device with which the system device is paired, and from such menu the user can explicitly request unpairing with a system device selected in the menu's list. When the user requests to unpair with the selected other system devices, steps are performed (i) to remove the effect of the pairing step, (ii) to remove the effect of the negotiation step, if any, and (iii) to temporarily prevent the system device and the selected other system devices from performing the negotiation step. To undo the effects of the pairing step, the DNP manager 19 or 25 of the system device locally issues a status change for each capability consumed or provided from the selected other system device and sends a request via the MtoM communication tool 18 or 24 to the selected other system device to proceed to unpairing. The DNP manager 19 or 25 of the selected other system device then locally publishes a status change for each capability consumed from or provided to the system device and sends an acknowledgment of receipt of the request to proceed to unpairing to the system device via the MtoM communication tool 18 or 24.

[0067] At the system device, and at selected other system devices, the GUI manager 17 or 23 is alerted to the state changes of each relevant capability and adapts accordingly. Figure 8 shows the changes in the mixer P&ID GUI, pump GUI, and flow sensor GUI in addition to the user selection, in the mixer's dedicated menu, where a pump paired with a flow sensor is unpaired from the mixer. Within the mixer, the DNP manager 19 issues a state change of the corresponding capability, i.e., interface function 2, to the appropriate queue, i.e., ("control", "pumping") queue, which triggers the GUI manager 17 to adapt accordingly by disabling capability interface function 2, and the control panel 44 is released from the mixer's P&ID GUI, as shown at the top of FIG. 8. Still within the mixer, the DNP manager 19 requests the MtoM communication tool 18 to send a request to the pump to proceed to unpair. This request is sent over the network 12, received by the pump's MtoM communication tool 24 and forwarded to the pump's DNP manager 23, which then issues it to the appropriate queue, i.e. ("Control", "Pumping") queue, and issues a status change in the corresponding capability, i.e. interface function 2, triggering the GUI manager 23 to adapt accordingly by reverting capability interface function 2 so that a variator 35 and a start / stop button 34 are present on the pump's GUI, as shown in the center of Figure 8.

[0068] Since the flow sensor is not involved in the unpairing (it remains paired with the pump), no action is taken and therefore its GUI remains unchanged, as shown in the bottom part of Figure 8. This is also the case for the pH sensor, which is not involved in the unpairing (it remains paired with the mixer). The pump's DNP manager 25 sends an acknowledgement to the mixer via the MtoM communication tool 24 of the request to proceed to unpair. As mentioned above, the effect of the negotiation step (exclusive) between the mixer and the pump is nullified; the previously shared capabilities are now available for negotiation again, and so the aforementioned isolation is implemented to temporarily prevent the mixer and the pump from performing the negotiation step. Other unpairings (mixer and pH sensor, pump and flow sensor) are performed similarly.

[0069] Ability Spread As mentioned above, the pump has the further capability of enabling the pump to provide the flow value sensed by the flow sensor as if the flow sensor was part of the pump. This further capability, named Interface Function 3, is described in the pump's device shape file 26. The Capability Interface Function 3 description includes an identifier (capabilityUniqueID) that also references another capability identifier (refToCapabilityUniqueID), i.e., the associated capability of the flow sensor paired with the pump, if any. In this regard, it is noted that, to simplify the disclosure above, it has not been mentioned that each capability description includes a unique identifier for that capability (capabilityUniqueID), which in this example is a four-digit value. Interface feature 3 Where available, interface function 3 is similar to the interface function disclosed above for the pH sensor: in a modified form, interface function 3 of the pump holds a display of the current value measured by the flow sensor, with a trend curve representing the change in flow over time while the display changes to indicate that the pump is paired with an appropriate other system device, which indication here is the release of two control icons 34 and 35 from the pump's GUI, which is done by interface function 2 upon pairing with an appropriate other system device such as a mixer.

[0070] The description of Capability Interface Function 3 of the pump means that the pump as a capability provider can provide flow (and only flow) process value display datasets to paired system devices using the OPC UA standard. This capability is negotiable only if the pump makes it available. The dataset contains the process value, its name, and its unit. In general, capabilities such as interface function 3 operate when activated in the same manner as capabilities of other paired system devices, and can be provided to paired system devices other than flow sensors, other than pumps, as if they were from the system device. For convenience, a mechanism involving a capability such as interface function 3 of a pump can be referred to as capability propagation, in reference to the fact that a source capability (such as the capability of a flow sensor) becomes available in the same substance via a system device such as a pump, and a capability (such as interface function 3) that replicates the source capability can be activated; a capability such as interface function 3 can be referred to as a capability propagator. Needless to say, such capabilities (such as interface function 3) replicate source capabilities, so that the capabilities provided in the bioprocess machine 13 (here a mixer) replicate the capabilities provided in the associated machine helper 14 (here a pump).

[0071] Multiple sharing of abilities In a variation not shown, the pump does not have the capability for interface function 3: instead of being paired only with the pump, the flow sensor is paired together with the pump and the mixer, so that the mixer gets the flow value directly from the flow sensor (and not from the pump which gets the flow value from the flow sensor). In fact, the capability of a flow sensor places no restrictions on the number of other system devices it is allowed to pair with, whereas the capability of a mixer, interface function 1, can display process values ​​from multiple paired system devices, such as a flow sensor in addition to a pH sensor. For convenience, the fact that a capacity (such as the capacity of a flow sensor) is consumed by multiple other system devices can be referred to as multiple shares of the capacity.

[0072] ability stratification In another variation not shown, the capability interface function 3 does not simply replicate the source capability (the capability of the flow sensor) but allows the pump to provide additional functionality that it cannot provide without the flow sensor, namely flow regulation. Interface feature 3 If interface function 3 is available, the pump speed can be controlled and monitored to regulate the flow rate through the pump using the OPC UA standard. The description of Capability Interface Function 3 of a pump means: The pump, as a capability provider with the Process Value Regulation skill, can provide pump speed control and monitoring to regulate the flow through the pump using the OPC UA standard. This capability is negotiable only if the pump makes it available. A paired system device, such as a mixer, has exclusive control and can start / stop regulation, set regulation parameters and get data from the process value.

[0073] In general, the capabilities provided by activating additional features such as Interface Function 3 can be provided to paired system devices other than flow sensors, and to system devices other than pumps. For convenience, mechanisms that include capabilities such as the pump's interface function 3 can be referred to as function layering, in reference to the fact that a source capability (such as the flow sensor's capability) is embedded in a more complex capability; capabilities such as interface function 3 can be referred to as layered capabilities. Such capabilities (such as interface function 3) can include source capabilities, but capabilities provided in the bioprocess machine 13 (here a mixer) must necessarily embed capabilities provided in the associated machine helper 14 (here a pump). As used herein, the term "tiering capability" is used generally to indicate that a source capability is required to enable a machine helper to issue / display a tier capability. For example, "Volume Calculation" as a tier capability requires, for example, "Length", "Height", and "Depth" as source capabilities, depending on the shape of the volume to be determined.

[0074] Further variations In a variation of the example disclosed above: -Bioprocessing machines are different from mixers. Examples include bioreactors, chromatography, viral inactivation, tangential flow filtration, etc. - Machine helpers are different from pumps, flow sensors, pH sensors; other active components such as valves and mass flow controllers; other sensors such as mechanical, electronic, photoelectron, infrared, ultraviolet, pressure sensors, temperature sensors, OD (optical density) sensors, DO (dissolved oxygen) sensors, gas (CO2, …) sensors, weight sensors, speed (RPM …) sensors, flow (gas / air) sensors, humidity sensors, light / illumination sensors, position (valve, actuator, switch …) sensors, power (watts …) sensors, galvanometers, motors a measurement sensor, a vacuum sensor, a title sensor, a viability sensor, a resistivity sensor, a proximity / distance sensor, a volume sensor, a UV sensor, an IR sensor, a frequency sensor, a molar concentration sensor, a duration / time sensor, a radiation sensor, a colorimeter, a glucometer, an opacity meter, an osmometer, a photometer, a spectrometer, a sound pressure sensor, a sonometer, a video sensor, a photosensor, a charge sensor, a particle counter, a viscosity sensor or a lactate sensor; other types of instrumentation; and / or an auxiliary device such as a cell retention device or mixer that is a capability provider (different from the mixer in the example above). Unlike the mixer in the above example, which must be paired with a pump connected to inlet 1 in order to be operational, the bioprocess machine is operational in a standalone state, i.e., it does not need to be paired with a bioprocess machine helper in order to be operational. -The system equipment is originally located in a separate location from the production and storage areas, for example, all system devices are initially in the storage area and then all are brought into the production area to set up the installation. -The interactive screen is replaced or supplemented by another user interface, such as a passive display and physical buttons, or a passive screen and keyboard; -The network is different from networks that use IP; -The communication standard between machines is different from OPC UA; and / or - the system has only one bioprocess machine and one bioprocess machine helper; or there are multiple bioprocess machines and multiple bioprocess machine helpers with at least certain machine helpers that can be combined with different bioprocess machines. It is recalled that many other variants are possible and in this respect the invention is not limited to the examples disclosed and illustrated.

[0075] One important preferred aspect is that the system can include virtual software-based components that can be used to predict or calculate the behavior of biotechnological fluids in the fluid handler using physicochemical or biological properties and / or external data. These software-based components can analyze the results and use the information so obtained to improve the overall system performance. Figure 9 shows the steps required to add such virtual software-based components. The following worked example, including FIG. 10, illustrates a preferred method for creating and using a system that includes these software-based components.

[0076] 1. A lab scientist needs a DO (dissolved oxygen) prediction for a bioprocess. To obtain this DO prediction, software running on a computer is used. This computer can be any kind of computing device, from a standard personal computer, a microcontroller to a quantum computer, as long as it is suitable. It can also be a local computer or a remote computer, such as a cloud-based computer. The software consists of several modules with specific functionality and contains information about the current bioprocess for which the lab scientist needs a DO prediction. One of these modules is Match Helper, which shows the lab scientist available helpers that match the assigned bioprocess and can be used. 2. The laboratory scientist then selects the appropriate DO prediction feature in the Match Helper module, and this information is communicated to the Adaptive Device Creator, another software module that creates virtual components, in this case the DO prediction helper. 3. Using the given information, the adaptive device creator creates a virtual new DO prediction helper in a smart component in the laboratory and virtually adds it to the bioprocess machine system.

[0077] 4. From the storage or production area, a suitable mixer defined in the available process orchestration recipe is selected as a physical component and added to the system. The computer hosting the virtual DO prediction helper, e.g. a personal computer or any other suitable computer, also contains all the necessary data about the physical system and its components, which allows the physical system and the virtual software-based DO prediction helper to perform the predictions. Once all planned components have been added to the system, the system is powered on. The software also provides a basic P&ID about the installed system. 5. Next, a storage area is installed for all the smart components, whether physical, such as mixers and pumps, or software-based, such as DO prediction helpers. 6. The Virtual DO Prediction Helper calculates the DO prediction data using the data provided by the software. 7.The lab scientist then logs into the system via an appropriate machine interface (HMI) and accesses the reporting modules for each smart component.

[0078] 8. The DO prediction data required for a specific system will be delivered to the laboratory scientists by the respective smart components and made available via the corresponding reporting module. 9. With this DO prediction data, laboratory scientists can improve their systems to improve dissolved oxygen levels without having to run actual tests with physical components. While the virtual software-based component 14a is preferably suitable for use in the disclosed system for processing biotechnology fluids as disclosed in this document, it will be understood that the invention for creating and using such software-based components is not limited to this system, and the invention may be used in any comparable system having system components that can be simulated and used in the disclosed manner.

Claims

1. 1. A system for processing a biotechnology fluid, comprising: a bioprocessing machine (13) having a biotechnology fluid processor (15) configured to modify at least one physicochemical or biological property of a biotechnology fluid, and a digital controller (16) for controlling said physical biotechnology fluid processor (15); and At least one physical bioprocess machine helper (14) having a physical biotechnology fluid processor helper (21) configured to be coupled to said biotechnology fluid processor (15) and a digital controller (22) for controlling said biotechnology fluid processor helper (21); and / or At least one software-based bioprocess machine helper (14a) created by an adaptive device creator (42); and a software-based bioprocess machine match helper (43) for selecting an appropriate software-based bioprocess machine helper (14a); Each of the digital controller (16) of the bioprocess machine (13) and the digital controller (22) of the machine helper (14) includes at least one capability manager (17, 23), a machine-to-machine communication tool (18, 24) (MtoM communication tool), and a discovery negotiation pairing manager (19, 25) (DNP manager); Each of said MtoM communication tools (18, 24) is configured to connect to a network (12); The DNP manager (19) of the bioprocess machine (13) and the DNP manager (25) of the machine helper (14) are configured to cooperate via the network (12) to establish a paired state; the capacity manager (17) of the bioprocess machine (13) and the capacity manager (23) of the machine helper (14) are configured to organize the provision and / or consumption of respective capacities by either the bioprocess machine (13) or the machine helper (14) in the paired state; the software-based bioprocess machine helper (14a) is configured by the appropriate adaptive device creator (42) to predict or calculate the behavior of the biotechnological fluid using physicochemical or biological properties and / or external data, to analyze the results, and to extend the capabilities of the physical bioprocess machine (13); The system.

2. 2. The system of claim 1, wherein the adaptive device creator (42) and / or at least one software-based bioprocess machine helper (14a) are hosted by a remote computer that transfers the created software-based bioprocess machine helper (14a) to a respective digital controller (16) or are hosted directly as a local instance on the respective digital controller (16).

3. 3. The system of claim 1 or 2, wherein at least one software-based bioprocess machine helper (14a) is configured to behave in the same manner as its physical counterpart (14).

4. 2. The system of claim 1, wherein the digital controller (16) of the bioprocessing machine (13) includes a file (20) containing a description of each of the interface functions that can result in the provided capacity, and the digital controller (22) of the machine helper (14) includes a file (26) containing a description of each of the interface functions that can result in the consumed capacity.

5. 2. The system of claim 1, wherein the DNP manager (19) of the bioprocessing machine (13) and the DNP manager (25) of the machine helper (14) are configured to cooperate via the network (12) to establish a pairing state.

6. 2. The system of claim 1, wherein the system device includes a plurality of the machine helpers, and wherein a DNP manager of the bioprocessing machine is configured to establish the pairing conditions simultaneously with at least one of the machine helpers.

7. 2. The system of claim 1, wherein the system device includes a first bioprocess machine, a second bioprocess machine, and a plurality of machine helpers, and wherein a DNP manager of at least one of the machine helpers is configured to establish the pairing conditions with either the first bioprocess machine or the second bioprocess machine.

8. 2. The system of claim 1, comprising a first machine helper (14) whose consumed capacity is an interface function for controlling and / or displaying operating parameters of a processor helper (21) of the first machine helper (14), and a second machine helper (14) whose consumed capacity is an interface function for displaying a physicochemical or biological quantity of a fluid sensed by a processor helper (21) of the second machine helper (14), wherein the first machine helper (14) is a pump whose consumed capacity is an interface function for controlling and / or displaying a pump speed, and the second machine helper (14) is a pH sensor or a flow sensor whose consumed capacity is an interface function for displaying a pH of the fluid or a flow rate of the fluid.

9. 2. The system of claim 1, wherein each of the MtoM communication tools (18, 24) is configured to connect to the network (12), which is a network with an Internet protocol such as Ethernet, Wi-Fi, Bluetooth, or cellular 5G.

10. 10. A method of operating a system for processing biotechnology fluids according to claim 1, comprising the steps of: identifying the relevant process context and required capabilities of said physical biotechnology fluid handler (15) and using it to select at least one appropriate software-based bioprocess machine helper (14a) via said software-based bioprocess machine match helper (43); creating at least one selected software-based bioprocess machine helper (14a) via said adaptive device creator (42); adding all software-based devices (14a) to the system and pairing at least one software-based bioprocess machine helper (14a) with each bioprocess machine (13) via a DNP manager (19); predicting and / or calculating, via said software-based bioprocess machine helper (14a), the behavior of said biotechnological fluid in said physical biotechnological fluid processor (15) using at least one physicochemical or biological property thereof and / or external data; analyzing the data and, based on the results, adapting the configuration of the physical biotechnology fluid handler (15) and extending the capabilities of the physical bioprocess machine helper (14) via the software-based bioprocess machine helper (14a); The method comprising:

11. 11. The method of claim 10, wherein the software-based bioprocess machine helper (14a) uses non-self-learning tools such as machine learning models, artificial intelligence algorithms such as neural networks, and / or computational models for prediction, calculation, and data analysis.

12. 12. The method according to claim 11, wherein an artificial intelligence algorithm is trained using either external data or collected data relating to said at least one physicochemical or biological property from said biotechnological fluid in said physical biotechnological fluid processor (15).

13. 11. The method of claim 10, wherein the software-based bioprocess machine helper (14a) uses smart data for prediction, calculation, and data analysis.

14. The method of claim 13, wherein the adaptive device creator (42) uses a contextualization mechanism for the instance of smart data.

Images