Systems for processing biotechnology fluids

Abstract

The present application relates to the processing of biotechnology fluids, 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 and each equipped with a controller, as well as an inter-machine communication tool configured to be connected to a network.

Description

TECHNICAL FIELD

[0001] The present invention relates to biotechnology fluid processing, such as biopharmaceutical liquid processing, for obtaining products such as monoclonal antibodies, vaccines, or recombinant proteins. BACKGROUND ART

[0002] It is known that biotechnology fluids such as biopharmaceutical liquids are generally initially obtained by processes such as cell or microbial culture in a bioreactor, and then they need to be further processed to achieve required properties such as homogeneity, purity, concentration, and absence of viruses. These processes have conventionally been performed in dedicated equipment such as stainless steel pipes, tanks, and filter housings, requiring operations before and after the actual processing, and in particular, cleaning operations after use have been relatively cumbersome. Within the past few years, these processes have alternatively been performed in equipment where the components in contact with the liquid are disposable components, to avoid cleaning operations.

[0003] For example, European patent applications EP 2 130 903 and EP 2 208 534 disclose equipment comprising disposable elements that are for the most part flexible ("FlexwareTM products"), including a processed liquid collection bag and circuit sections, as well as filter elements, which are 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 equipment uses the same approach with reusable elements or certain reusable elements that are not housed in carts. SUMMARY OF THE INVENTION PROBLEMS TO BE SOLVED BY THE INVENTION

[0004] Generally, the main reusable elements of equipment for processing biotechnology fluids are bioprocess machines having biotechnology fluid processors configured to modify at least one physicochemical or biological property of the biotechnology fluid, such as its pH, DO (dissolved oxygen), homogeneity, purity, concentration, and the presence or absence of certain microorganisms, such as viruses and / or other pathogens.

[0005] In addition to the biotechnology fluid processor, the bioprocess machine has a digital controller to control the biotechnology fluid processor. In most cases, the digital controller can control the fluid processor, allowing the machine to automatically perform customized versions of processing, commonly referred to as recipes. [Means for solving the problem]

[0006] This invention aims to further facilitate the setup of equipment for processing biotechnology fluids. Therefore, the present invention provides a system having the following system devices for processing biotechnology fluids: - A bioprocess 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 the biotechnology fluid processor (15); and - A biotechnology fluid processor helper (21) configured to be physically connected to a biotechnology fluid processor (15), and at least one bioprocess machine helper (14) having a digital controller (22) for controlling the biotechnology fluid processor helper (21); Here: -Each of the digital controller (16) of the bioprocess machine (13) and the digital controller (22) of the machine helper (14) includes a report manager (60, 61), inter-machine communication tools (18, 24) (MtoM communication tools), and detection negotiation pairing managers (19, 25) (DNP managers); -Each MtoM communication tool (18, 24) is configured to connect to the 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 pairing state; where: the Report Manager (60) of the bioprocess machine (13) and the Report Manager (61) of the machine helper (14) are configured in the pairing state as follows: - The report manager (60) of the bioprocess machine (13) has at least one provided capability that it does not have when not in a paired state, the provided capability being a reporting function that performs data logging and / or data report generation relating to the operating parameters of the processor helper (21) and / or relating to the physicochemical or biological quantities of the fluid sensed by the processor helper (21); and - The report manager (61) of the machine helper (14) does not have at least one consumed capability when it is not in a pairing state, where: if the provided capability is a reporting function that performs data logging and / or data report generation for one or more operating parameters of the processor helper (21), the consumed capability is a reporting function that performs data logging and / or data report generation for the operating parameters; and if the provided capability is a reporting function that performs data logging and / or data report generation for physicochemical or biological quantities of fluid sensed by the processor helper (21), the consumed capability is a reporting function that performs data logging and / or data report generation for one or more physicochemical or biological quantities.

[0007] The physical connection between the machine helper (via the processor helper) and the bioprocess machine (via the fluid processor) is intended 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 liquid, applying another physical action to the liquid, or sensing physicochemical or biological quantities of the liquid such as pH or dissolved oxygen (DO).

[0008] In the system according to the present invention, the machine helper has a digital controller equipped with inter-machine communication tools, and communicates with the bioprocess machine via a network that enables inter-machine communication. Therefore, despite the physical connection between the machine helper and the bioprocess machine, a dedicated communication channel such as a wired serial or parallel link can be enabled relatively easily, and this can be operated simply by plugging in a connector when performing the physical connection.

[0009] The present invention is based on the view that, although pairing must be performed via a network in addition to physical connection, such pairing via a network can be used to automatically reconfigure the bioprocess machine (using its provided capacity) and the machine helper (using its consumed capacity), thereby actually facilitating the setup of equipment for processing biotechnology fluids. Such automated reconfiguration makes the addition of machine helpers extremely convenient and can be performed even during batch processing, thus providing even greater flexibility to the system according to the present invention.

[0010] According to the advantageous features for implementing the system according to the present invention: - Each of the report managers (60) of the bioprocess machine (13) and the report manager (61) of the machine helper (14) includes a data logger (62) and different generators (65) that generate reports from the data provided by the data logger (62); - The operating parameters of the processor helper (21), or the physicochemical or biological quantities of the fluid sensed by the processor helper (21), are recorded by the data logger (62) of the machine helper (14) when the machine helper (14) is not in a paired state, or by the data logger (62) of the bioprocess machine (13) when the machine helper (14) is in a paired state; - The provided capability reporting function is data logging and / or data report generation regarding a set of operating parameters of the processor helper (21) and / or physicochemical or biological quantities of the fluid sensed by the processor helper (21);

[0011] - The digital controller (16) of the bioprocess machine (13) includes a file (20) containing a description of each reporting function that may be the provided capacity, and the digital controller (22) of the machine helper (14) includes a file (26) containing a description of each reporting function that may be the consumed capacity; - 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 pairing state; - The system device includes multiple machine helpers (14), and the DNP manager (19) of the bioprocess machine (13) is configured to establish a pairing state with at least two machine helpers (14) simultaneously;

[0012] - The system device includes a first machine helper (14) and a second machine helper (14); the fluid processor helper (21) of the first machine helper (14) and the fluid processor helper (21) of the second machine helper (14) are configured to be physically connected to each other; the DNP manager (25) of the first machine helper (14) and the DNP manager (25) of the second machine helper (14) are configured to cooperate via a network (12) to establish a pairing state; where the report manager (61) of the first machine helper (14) and the report manager (61) of the second machine helper (14) are configured in the pairing state as follows:

[0013] - The report manager (61) of the first machine helper (14) has at least one provided capability which it does not have when not in a pairing state, the provided capability being a reporting function which performs data logging and / or data report generation relating to the operating parameters of the processor helper (21) of the second machine helper (14) or relating to the physicochemical or biological quantities of the fluid sensed by the processor helper (21) of the second machine helper (14); and

[0014] - The report manager (61) of the second machine helper (14) does not have at least one consumed capability when not in a paired state, where: if the provided capability is a reporting function that performs data logging and / or data report generation for one or more operating parameters of the processor helper (21) of the second machine helper (14), the consumed capability is a reporting function that performs data logging and / or data report generation for the operating parameters; and if the provided capability is a reporting function that performs data logging and / or data report generation for physicochemical or biological quantities of fluid sensed by the processor helper (21) of the second machine helper (14), the consumed capability is a reporting function that performs data logging and / or data report generation for physicochemical or biological quantities;

[0015] - The report manager (60) of the bioprocess machine (13) and the report manager (61) of the first machine helper (14) are such that, in the paired state between the bioprocess machine and the first machine helper (14), the first machine helper (14) is paired with the second machine helper (14), and the report manager (60) of the bioprocess machine (13) has a provided capacity that replicates the capacity provided by the first machine helper (14) corresponding to the capacity consumed by the second machine helper (14);

[0016] - The report manager (60) of the bioprocess machine (13) and the report manager (61) of the first machine helper (14) are configured such that when the bioprocess machine and the first machine helper (14) are paired, the first machine helper (14) is paired with the second machine helper (14), and the recipe manager (50) of the bioprocess machine (13) has a provided capacity that embeds the capacity provided to the first machine helper (14) corresponding to the capacity consumed by the second machine helper (14);

[0017] - The system device includes a first bioprocess machine (13), a second bioprocess machine (13), and a plurality of machine helpers (14); the DNP manager (25) of at least one machine helper (14) is configured to establish a pairing state with the first bioprocess machine (13) or the second bioprocess machine (13);

[0018] -the system has a first machine helper (14), and the consumed capability is a report function for performing data logging and / or data report generation regarding the operating parameters of the processor helper (21) of the first machine helper (14); and has a second machine helper (14), and the consumed capability is generating data logs and / or data reports relating to the physicochemical or biological quantities of the fluid sensed by the processor helper (21) of the second machine helper (14); wherein the first machine helper (14) is a pump, the consumed capability is a report function for performing data logging and / or data report generation regarding the speed of the pump, and the second machine helper (14) is a pH sensor or a flow sensor, of which the consumed capability is a report function for performing data logging and / or data report generation regarding the pH of the fluid or the flow of the fluid;

[0019] -each of the MtoM communication tools (18, 24) is configured to connect to a network (12), which is a network having an Internet protocol such as Ethernet (registered trademark), Wi-Fi, Bluetooth (registered trademark), or cellular 5G; -In the system described above: -the digital controller (16) of the bioprocess machine (13) and the digital controller (22) of the machine helper (14) each further comprise a graphical user interface manager (17, 23) (GUI manager); -the GUI manager (17) of the bioprocess machine (13) and the GUI manager (23) of the machine helper (14) are configured in the pairing state as follows:

[0020] -the GUI manager (17) of the bioprocess machine (13) has at least one provided capability that it does not have when not in the pairing state, and the provided capability is an interface function for controlling and / or displaying the operating parameters of the processor helper (21), or displaying the physicochemical or biological quantities of the fluid sensed by the processor helper (21); and

[0021] - The GUI manager (23) of the machine helper (14) has at least one consumed capability that is modified for the case where it is not in a pairing state, and when the provided capability is an interface function for controlling and / or displaying the operation parameters of the processor helper (21), the consumed capability is an interface function for controlling and / or displaying the operation parameters, and when the provided capability is an interface function for displaying the physicochemical or biological quantity of the fluid sensed by the processor helper (21), the consumed capability is an interface function for displaying the physicochemical or biological quantity; and / or

[0022] - In the above system: - The digital controller (16) of the bioprocess machine (13) and the digital controller (22) of the machine helper (14) each further comprise a recipe manager (50, 51); - The report manager (60) of the bioprocess machine (13) and the recipe manager (51) of the machine helper (14) are configured in the pairing state as follows:

[0023] - The recipe manager (50) of the bioprocess machine (13) has at least one provided capability that it does not have when not in the pairing state, and the provided capability is an automation function for controlling and / or testing the operation parameters of the processor helper (21), or testing the physicochemical or biological quantity of the fluid sensed by the processor helper (21); and

[0024] - The recipe manager (51) of the machine helper (14) has at least one consumed capability which it does not have when not in a pairing state, wherein if the provided capability is an automated capability for controlling and / or testing the operating parameters of the processor helper (21), the consumed capability is a response-on-request capability for controlling and / or making available the operating parameters; and if the provided capability is an automated capability for testing the physicochemical or biological quantities of the fluid sensed by the processor helper (21), the consumed capability is a response-on-request capability for making the physicochemical or biological quantities available. [Brief explanation of the drawing]

[0025] The description of the present invention is followed by a detailed description of exemplary embodiments given below, with reference to the accompanying drawings. In the drawings below:

[0026] [Figure 1] Figure 1 schematically shows a manufacturing area in a bioprocess plant or laboratory where bioprocess machines, which form part of a system for processing biological fluids, are located. [Figure 2] Figure 2 schematically shows a storage area in a bioprocess manufacturing plant or laboratory where multiple bioprocess machine helpers for a system of processing biological fluids are located, and the bioprocess machine helpers are configured to be associated with the bioprocess machines shown in Figure 1.

[0027] [Figure 3] Figure 3 shows a bioprocess machine and one of its bioprocess machine helpers, along with a network in which the bioprocess machine and bioprocess machine helper cooperate to establish a pairing state. [Figure 4] Figure 4 shows the graphical user interface of a bioprocess machine, which is a standalone mixer. [Figure 5]Figure 5 shows the graphical user interface of the mixer when combined with the bioprocess machine helper, which is a pH sensor, at the top, and the graphical user interface of the pH sensor at the bottom. The left side shows the standalone state, and the right side shows the state when combined with the mixer.

[0028] [Figure 6] Figure 6 schematically shows the bioprocess machine helper pump together with the bioprocess machine helper flow sensor at the top. The pump and flow sensor are physically connected, and the pump's graphical user interface is displayed in the center, with the left side showing the standalone state and the right side showing the state combined with the flow sensor. The graphical user interface of the flow sensor is displayed at the bottom, with the left side showing the standalone state and the right side showing the state combined with the pump.

[0029] [Figure 7] Figure 7 shows an exemplary schematic diagram of a GUI adapted when a process machine and machine helper are paired, with the mixer's graphical user interface shown at the top, with the left side showing it paired with a pH sensor, the right side showing it paired with a pH sensor and a pump paired with a flow sensor, the pump's graphical user interface shown in the center, with the left side showing it paired with a flow sensor, the right side showing it paired with a flow sensor and possibly paired with a mixer, and the flow sensor's graphical user interface shown at the bottom, with the left side showing it paired with a pump, and the right side showing it paired with a pump and possibly a mixer.

[0030] [Figure 8]Figure 8 is a schematic diagram of an exemplary GUI adapted when the process machine and machine helper are not paired, showing the mixer's graphical user interface at the top, paired with the pH sensor on the left, the pump paired with the flow sensor on the right, the pump's graphical user interface in the center, shown when paired with the mixer in combination with the flow sensor on the left, and when paired with the flow sensor on the right, and the flow sensor's graphical user interface at the bottom. The left side shows the mixer paired with the pump, and the right side shows the pump paired with the mixer.

[0031] [Figure 9] Figure 9 is similar to Figure 3, but is a modified version of the system in which the digital controller of the bioprocess machine and the digital controller of the machine helper each further include a recipe manager. [Figure 10] Figure 10 shows a specific module of the recipe manager for a bioprocess machine. [Figure 11] Figure 11 shows the graphical user interface of the recipe manager for the Bioprocess Machine, which is a standalone mixer.

[0032] [Figure 12] Figure 12 is similar to Figure 11, but shows the mixer paired with a machine helper, which is a pH sensor. [Figure 13] Figure 13 is similar to Figures 11 and 12, but shows a mixer in a paired state with a pump paired with a pH sensor and a flow sensor. [Figure 14] Figure 14 is similar to Figure 9, but is a modified version of the system in which the digital controller of the bioprocess machine and the digital controller of the machine helper each further include a report manager.

[0033] [Figure 15]Figure 15 shows a specific module of the bioprocess machine's report manager, such as the mixer in the illustrated example, along with the generated reports and the data path between the biotechnology fluid processor 15 and the generated reports when the bioprocess machine is in a standalone state. [Figure 16] Figure 16 is similar to Figure 15, but shows the machine helpers, such as the pump, flow sensor, and pH sensor, when the machine helpers are in a standalone state.

[0034] [Figure 17] Figure 17 is similar to Figures 15 and 16, but shows the bioprocess machine and machine helper together when they are paired with each other, illustrating the inter-machine communication tool, the network where the pairing is established, and the data path from the machine helper's processor helper to the report generated by the bioprocess machine's report manager.

[0035] [Figure 18] Figure 18 shows, at the top, a report generated by the bioprocess machine's report manager when the mixer is in a standalone state, and below that, a similar report generated by the machine helper's report manager when the machine helper is in a standalone state, with reports for the pump, flow sensor, and pH sensor displayed sequentially from top to bottom.

[0036] [Figure 19] Figure 19 is similar to Figure 18, but the mixer is paired with a pump that is paired with a flow sensor, and the report generated by the mixer now also includes the pump speed and the flow rate sensed by the flow sensor. [Figure 20] Figure 20 is similar to Figure 19, but the mixer is further paired with a pH sensor, and the report generated by the mixer also includes the pH sensed by the pH sensor. [Figure 21] Figure 21 is similar to Figure 20, but the pairing between the mixer and pump is disconnected, so the report generated by the mixer will no longer include the pump speed and the flow rate sensed by the flow sensor, while the pump will generate a report that includes the pump speed and the flow rate sensed by the flow sensor. [Modes for carrying out the invention]

[0037] Figures 1 and 2 show a production area 10 and a storage area 11 of a bioprocess production plant or laboratory where available system devices for processing biotechnology fluids according to the present invention are located.

[0038] System device description: Bioprocess machine and bioprocess machine helper Each system device includes a digital processing unit (microprocessor and / or microcontroller, memory, and network connectivity) and is configured to be connected via wired or wireless connection to a network 12 (Figure 3) that supports the Internet Protocol (IP). For example, wired connections are made via Ethernet®, while wireless connections are made via Wi-Fi, Bluetooth®, or cellular networks such as 5G. This system comprises a bioprocess machine 13 and a plurality of bioprocess machine helpers 14. The bioprocess machine 13 can be set up alone or in association with one or more machine helpers 14 to become equipment for processing biotechnology fluids. As shown in Figure 3, the bioprocess machine 13 includes a biotechnology fluid processor 15 and a digital controller 16.

[0039] The biotechnology fluid processor 15 is configured to modify at least one physicochemical or biological property of the biotechnology fluid, such as its pH, dissolved oxygen (DO), uniformity, purity, concentration, and the presence or absence of certain microorganisms such as viruses. The digital controller 16 is configured to control the biofluid processor 15, as indicated by the bidirectional arrows in Figure 3. Here, the digital controller 16 can control the fluid processor 15 so that the machine 13 can automatically execute a customized version of the process, commonly referred to as a recipe.

[0040] The digital controller 16 includes a graphical user interface (GUI) manager 17, a machine-to-machine (MtoM) communication tool 18, and a discovery-negotiation-pairing (DNP) manager 19. The digital controller 16 also includes a file called a device shape 20, which contains a description of specific interface functions of the GUI that can be displayed by the GUI manager 17. Please note that the term "file" should be interpreted broadly here, encompassing any structured data container, including folders and / or databases. The bioprocess machine helper 14 includes a biotechnology fluid processor helper 21 and a digital controller 22.

[0041] The processor helper 21 is configured to be physically connected to the fluid processor 15, as indicated by the bidirectional arrows in Figure 3. The physical connection allows 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, exert another physical effect on the fluid, or sense the physicochemical or biological quantities of the fluid, such as pH or DO.

[0042] For example, if the bioprocess machine 13 is a mixer, the biotechnology fluid processor 15 includes a tank and a stirrer; if the machine helper 14 is a pump, the biotechnology fluid processor helper 21 includes fluid drive components such as rollers for a peristaltic pump; and if the machine helper 14 is a pH or flow sensor, the biotechnology fluid processor helper 21 includes a pH probe and a flow probe, respectively.

[0043] The physical connection between the fluid drive component (pump processor helper 21) and the tank + agitator (mixer fluid processor 15) involves pipes and folders to maintain the fluid drive component and the tank + agitator in predetermined relative positions. For example, such folders may be implemented by mounting the pump on the same or similar framework as the mixer, or by a cart to which the pump is mounted, with the cart being maintained in a fixed position relative to the mixer.

[0044] Similarly, pH probes or flow probes need to interact with the fluid and be maintained in place. Generally, physical connections involve interaction between the fluid (see, with or without contact, 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 the folder that maintains the processor helper 21 with respect to the fluid processor 15.

[0045] The digital controller 22 is configured to control the processor helper 21, as indicated by the bidirectional arrows in Figure 3. The digital controller 22 has the same architecture as the digital controller 16: the digital controller 22 includes a GUI manager 23, an MtoM communication tool 24, and a DNP manager 25. The digital controller 22 also includes a file called a device shape 26, which contains a description of specific interface functions of the GUI that can be displayed by the GUI manager 23.

[0046] In each system device 13 or 14, the GUI manager 17 or 23 enables the display of GUIs such as process and instrumentation diagrams (P&IDs) locally on an interactive screen, or remotely on a device with an interactive screen, such as a tablet or smartphone. In each system device 13 or 14, the MtoM communication tool 18 or 24 is configured to connect to the network 12, as indicated by the bidirectional arrows in Figure 3.

[0047] 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 pairing state. Each system device 13 or 14 can be used as a standalone device or paired with another appropriate system device. The GUI manager 17 or 23 of each system device 13 or 14 is configured to receive GUI adaptation when the system device transitions from a standalone (unpaired) state to a state paired with a graphical user interface (GUI), and vice versa.

[0048] For example, if the machine helper 14 is a pump that can be paired with the bioprocess machine 13, in the standalone state of the pump, its GUI allows the user to control the pump, so that the user can use 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, and only the GUI of the bioprocess machine 13 allows the pump to be controlled.

[0049] Furthermore, for example, if the machine helper 14 is a sensor that can be paired with the bioprocess machine 13, such a sensor that senses a physicochemical or biological amount of a biotechnology fluid can be used as a standalone unit by the user, as its GUI displays the sensed amount when the sensor is in a standalone state, whereas when the sensor is paired with the bioprocess machine 13, the sensor's GUI only displays a message such as "connected" to indicate that the sensor is in a paired state, and the bioprocess machine 13's GUI displays the amount sensed by the sensor.

[0050] Generally, the GUI manager 17 of the bioprocess machine 13 and the GUI manager 23 of the machine helper 14 are configured as follows in the paired state: - The GUI manager 17 of the bioprocess machine 13 has at least one provided capability which it does not have when not in a pairing state, and the provided capability is an interface function that controls and / or displays the operating parameters of the processor helper 21, or displays the physicochemical or biological quantities of the fluid sensed by the processor helper 21; and

[0051] - The GUI manager 23 of the machine helper 14 has at least one consumed capability which is modified when it is not in a pairing state, where if the provided capability is an interface capability that controls and / or displays the operating parameters of the processor helper 21, the consumed capability is an interface capability that controls and / or displays the operating parameters, and if the provided capability is an interface capability that displays the physicochemical or biological quantities of the fluid sensed by the processor helper 21, the consumed capability is an interface capability that displays the physicochemical or biological quantities.

[0052] ability The interface functions described in the device shape files 20 or 26 of the different system devices 13 and 14 are either of the first type or the second type. The first type of interface function is an interface function that the GUI manager 17 or 23 of system device 13 or 14 does not have when the system device is not paired with another suitable system device, but the GUI manager 17 or 23 is supplemented when system device 17 or 23 is paired with another suitable system device.

[0053] In practice, the first type of interface functionality exists, but it is disabled if system device 13 or 14 is not paired with another appropriate system device, and enabled when system device 13 or 14 is paired with another appropriate system device. When enabled, each such interface function controls and / or displays the operating parameters of the paired system device, or displays a quantity sensed by the paired system device, where the quantity is a physicochemical or biological quantity of the biotechnology fluid being processed.

[0054] For the sake of convenience, such interface functions are referred to as “capabilities” in this specification, and as “provided capabilities” when enabled. The second type of interface function is an interface function that the GUI manager 23 of the system device, which is a machine helper 14, has in its original form when the system device is not paired with another suitable system device, and in a modified form when the system device is paired with another suitable system device.

[0055] In the original form, each such interface function controls and / or displays an operating parameter of a system device, or displays a quantity sensed by a paired system device, where the quantity is a physicochemical or biological quantity of the biotechnology fluid being processed. In the modified form, each such interface function is, for example, the same as in the original form, but with the addition of an indication that the system device is paired with another appropriate system device, or the original form is replaced with one that indicates that the system device is paired with another appropriate system device, where such indication is, for example, an icon, a message, or the absence of a display.

[0056] For linguistic convenience only, such interface functions are referred to as “capabilities” in this specification, and in modified forms as “consumed capabilities.” Note that the device shape file 20 of the bioprocess machine 13 includes a description of the interface function 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.

[0057] It should be further noted that in device shape files 20 and 26, each capability description has a feature called "role" that identifies whether the capability is of type 1 or type 2. In the first type, the role function is in the "consumer" and refers to the corresponding capability of the paired system device that becomes the "consumed capability" in the paired state. Here, the system device 13 or 14 that has the capability with the role characteristic in the "consumer" is called the capability consumer.

[0058] In the second type, the role feature is in “Provider,” which becomes “Provided Capability” in the paired state, referring to the corresponding capability of the paired system device, and a system device 14 having capability with the role feature in “Provider” is referred to herein as a capability provider. Please note that there is always a correspondence between the abilities provided and the abilities consumed.

[0059] If the provided capability (within capability consumer 13 or 14) is an interface function that controls and / or displays the operating parameters of the capability provider, then the consumed capability (within capability provider 14) is the interface function that controls and / or displays these operating parameters. For example, if the capability provided by the mixer is the start / stop control of a paired pump, then the capacity consumed by the paired pump is the start / stop control of that pump.

[0060] If the capacity provided (in capacity consumer 13 or 14) is an interface function that displays the physicochemical or biological quantities of the biotechnology fluid sensed by capacity provider 14, then the capacity consumed (in capacity provider 14) is the interface function that displays these physicochemical or biological quantities. For example, if the capacity provided by the mixer is a display of the pH of the biotechnology fluid sensed by a paired pH sensor, then the capacity consumed by the paired pH sensor is a display of the sensed pH.

[0061] The corresponding provided and consumed capabilities are referred to herein as “shared capabilities”. Each system device 13 or 14 has a device shape file 20 or 26 that can be deployed at design time and updated at runtime, extending the list of capabilities available to capability consumers or provided by capability providers throughout the lifespan of the system device. This allows the system device to contribute to new platform features without changing (and recertifying) the software packages installed on the system device.

[0062] Here, we describe examples of system devices 13 and 14 and how equipment for processing biotechnology fluids is set up with these system devices. An example of a bioprocess machine 13 is a mixer (capacity consumer). Examples of bioprocess machine helpers 14 are a pH sensor (capacity provider), a flow sensor (capacity provider), and a pump (both capacity consumer and capacity provider).

[0063] Mixer description The mixer includes a tank, an agitator inside the tank, and two inlets to which pipes can be connected to fill the tank. The tank, agitator, and inlet form a biotechnology fluid processor 15. To make it operational, the mixer needs to be connected to at least one pump to allow the biotechnology fluid to flow through one of its inlets. The mixer includes a digital processing unit that includes an industrial programmable logic controller (PLC) and an industrial PC. PLCs are dedicated to the real-time control and monitoring of various equipment modules to which they are connected (e.g., wirelessly or wired), such as agitators and valves that open and close inlets.

[0064] Industrial PCs have software packages installed and a file 20 called "device shape" is saved. The digital processing unit, installed software package, and saved device shape file 20 form the digital controller 16. The installed software package includes: a DNP manager 19; an MtoM communication tool 18 which includes an OPC UA server and an OPC UA client to support data exchange with other system devices; and a GUI manager 17 which enables the display of process and instrumentation diagrams (P&ID) locally on an interactive screen, such as a tablet or smartphone, or remotely on a device with an interactive screen. File 20, called the device shape, contains descriptions of four interface functions that provide capabilities when they become available.

[0065] Description of the capabilities available in the mixer's software package. As mentioned above, such capabilities consist of four interface functions: interface function 1, interface function 2, interface function 3, and interface function 4. Interface Function 1 When enabled, Interface Function 1 supplements the P&ID GUI with process data provided by the paired system device, whatever that paired system device may be. Capability Interface Function 1 has the following description in the mixer's device shape file 20: Domain: "Graphics", Purpose: "Process Value Display", Role: "Consumer", Limitations / Conditions: Optional. The list of properties is: [Table 1]

[0066] This capability description means the following: As a capability consumer with graphics capabilities, the mixer can display process values ​​from multiple paired system devices, and there are no restrictions or conditions on negotiation or pairing, provided that 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 modified version, the list of properties would include at least one of the following: [Table 2]

[0067] In such variations, the capability description further means that, if provided by a paired system device, the mixer can use a range of process values ​​to propose an auxiliary type of display (such as a gauge). Interface Function 2 Enabling Capability Interface Function 2 displays whether the P&ID GUI is compatible and whether the required (mandatory) expected pump is paired, and adds a control icon and a display of the paired pump's operating parameters to the P&ID GUI. Interface function 2 has the following description in the mixer's device shapefile 20: Domain: "Control", Purpose: "Pumping", Role: "Consumer", Restrictions / Conditions: Exclusive, Required, Operator Confirmation. The list of properties is: [Table 3]

[0068] This capability description means the following: As a capability consumer with control skills, the mixer must mandatorily pair with the system device, which is the pump, to fulfill the defined role of the pump connected to inlet 1. To pair, the system device must be made available for start / stop commands and provide its current start state. The mixer can control and monitor the pump speed, provided it is provided by the paired system device. Operator confirmation is required during the pairing procedure. Once paired, the mixer can exclusively use the system device, which is the pump. In a modified version, the list of properties would include at least one of the following: [Table 4]

[0069] In such modifications, the capability description further implies that the mixer can display the minimum and maximum values ​​of the speed range, provided by the pair of pumps to guide the operator when setting the pump speed. Interface function 3 When interface function 3 is enabled, the P&ID GUI is adjusted to show whether the planned optional pump is paired, and the P&ID GUI is updated to display a control icon and the operating parameters of the paired pump. Capability Interface Function 3 has the following description in the mixer's device shape file 20: Domain: "Control", Purpose: "Pumping", Role: "Consumer", Limitations / Conditions: Exclusive, Optional, Operator Verified. The list of properties is: [Table 5]

[0070] This capability description means that a mixer, as a capability consumer with control skills, can control an optional system device, which is a pump, to achieve a predefined role for the pump connected to inlet 2. For pairing to occur, the system device must be forced to enable start / stop commands and provide its current start state. If provided by the paired system device, the mixer can control and monitor the pump speed. Operator confirmation is required during the pairing procedure. Once paired, the mixer has exclusive use of the system device that is the pump. In a modified version, the list of properties would include at least one of the following: [Table 6]

[0071] In such modifications, the capability description further implies that the mixer can display the minimum and maximum values ​​of the speed range, provided by the pair of pumps to guide the operator when setting the pump speed. Interface function 4 Enabling interface function 4 allows the P&ID GUI to display other optional paired pumps, and the P&ID GUI is complemented by the display of control icons and operating parameters of the paired pump. Capability interface function 4 has the following description in the mixer's device shape file 20: Domain: "Control", Purpose: "Pumping", Role: "Consumer", Restrictions / Conditions: Exclusive, Optional. The list of properties is: [Table 7]

[0072] This capability description means that a mixer, as a capability consumer with control skills, can control any other system device that is a pump. No required properties are assumed. The mixer can start / stop the pump and control and monitor the pump speed, provided it is provided by the paired system device. Operator confirmation is not required during the pairing procedure. Once paired, the mixer has exclusive use of the system device that is a pump.

[0073] It should be noted that not all interface functions of the mixer's GUI manager 17 have been described here. Interface functions related to the instrument modules within the mixer (such as the agitator and inlet valve control) are not described here. Only interface functions that are disabled when the mixer is not paired with the appropriate system device and enabled when the mixer is paired with the appropriate system device are described, and at least other such interface functions may be included in the mixer's GUI manager 17.

[0074] Furthermore, it should be noted that the functions of interface function 2, interface function 3, and interface function 4 represent three levels of functionality that can be provided: predefined 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.

[0075] Description of pH sensor The pH sensor includes a probe for sensing the pH of the biotechnology fluid. The probe forms a biotechnology fluid processor helper 21. The pH sensor includes a digital processing unit that includes a microprocessor and / or microcontroller, memory, and network connectivity. The processing unit is configured to control and monitor flow-sensing probes, which are electrically wired to the probes. The processing unit has a software package installed and a file 26 called the device shape is stored there. The processing unit, installed software package, and saved device shape file 26 form the digital controller 22.

[0076] The installed software package has the same architecture as the software package installed on the mixer, and the software package installed on the pH sensor includes: a DNP manager 25; an MtoM communication tool 24 with an OPC UA server and OPC UA client that support data exchange with other system devices; and a GUI manager 23 that enables the GUI to be remotely displayed on a device with an interactive screen, such as a tablet or smartphone. File 26, called the device shape, contains a description of one interface function, which is the capability consumed when the format was changed.

[0077] Description of the capabilities available in the pH sensor software package: If a single interface function described in the pH sensor's device shape file is changed, the display of the current value measured by the pH sensor will be retained, a trend curve representing the change in pH over time will be displayed, and it will be indicated that the pH sensor is paired with the appropriate other system device. This capability is described in the pH sensor's device shapefile 26 as follows: Domain: "Graphics", Purpose: "Process Value Display", Role: "Provider", Limitations / Conditions: None. The list of properties is: [Table 8]

[0078] This capability description means that the pH sensor, as a capability provider, can provide a pH (and pH only) process value display dataset to a system device paired using the OPC UA standard. The dataset includes the process value, its name, and its units. Since an OPC UA tag value is specified for each data item, the paired system device can read these values ​​with an OPC UA client. There are no particular restrictions or conditions on negotiation or pairing. In a modified example, the dataset further includes at least one of the minimum or maximum values ​​within the range of values ​​where the pH process value is expected to be found.

[0079] Flow sensor description The flow sensor includes a probe for sensing the flow of biotechnology fluids. The probe forms a biotechnology fluid processor helper 21. The flow sensor includes a digital processing unit that includes a microprocessor and / or microcontroller, memory, and network connectivity. The processing unit is configured to control and monitor flow-sensing probes, which are electrically wired to the probes. The processing unit has a software package installed and a file 26 called the device shape is stored there.

[0080] The processing unit, installed software package, and saved device shape file 26 form the digital controller 22. The installed software package has the same architecture as the software package installed on the mixer, and the software package installed on the flow sensor includes; a DNP manager 25; an MtoM communication tool 24 with an OPC UA server and OPC UA client that support data exchange with other system devices; and a GUI manager 23 that enables the GUI to be remotely displayed on a device with an interactive screen, such as a tablet or smartphone. File 26, called the device shape, contains a description of one interface function, which is the capability consumed when the format was changed.

[0081] Description of the capabilities available in the flow sensor software package. In the modified format, the single interface function described in the flow sensor's device geometry is replaced by a display of the current value measured by the flow sensor, and the trend curve represents the change in flow over time, indicated by a display of the flow sensor being paired with other appropriate system devices. This capability is described in the flow sensor's device shapefile 26 as follows: Domain: "Graphics", Purpose: "Process Value Display", Role: "Provider", Limitations / Conditions: None. The list of properties is: [Table 9]

[0082] This capability description means that the flow sensor, as a capability provider, can provide a flow (and flow-only) process value display dataset to a system device paired using the OPC UA standard. The dataset includes the process value, its name, and its units. Each data point is assigned an OPC UA tag value, allowing the paired system device to read these values ​​with an OPC UA client. There are no particular restrictions or conditions on negotiation or pairing. In a modified example, the dataset further includes at least one of the minimum or maximum values ​​within the range of values ​​where the flow process value is expected to be found.

[0083] Pump description The pump includes components that act on the fluid to drive it, such as rollers in a peristaltic pump, and a motor that drives such components. The driving motor and driven components that act on the fluid form the biotechnology fluid processor helper 21. The pump includes a digital processing unit that includes a microprocessor and / or microcontroller, memory, and network connectivity. The processing unit is configured to control and monitor electrically wired motors. The processing unit has a software package installed and a file 26 called the device shape is stored there. The processing unit, installed software package, and saved device shape file 26 form the digital controller 22.

[0084] The installed software package has the same architecture as the software package installed on the mixer; the software package installed on the pump includes: a DNP manager 25; an MtoM communication tool 24 with an OPC UA server and OPC UA client that supports 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 the device shape contains a description of the interface functionality, which is the capability provided when it was active (interface functionality 1), and a description of the interface functionality, which is the capability consumed in a modified form (interface functionality 2).

[0085] Description of the capabilities available in the pump's software package. As mentioned above, each of these functions has two interfaces: Interface Function 1 and Interface Function 2. Interface Function 1 When interface function 1 is enabled, the GUI is supplemented with data provided by the paired system device, whatever that paired system device may be. Capability Interface Function 1 has the following description in the pump's device shape file 26: Domain: "Graphics", Purpose: "Process Value Display", Role: "Consumer", Limit / Condition: Max=1, Optional. The list of properties is: [Table 10]

[0086] This capability description means the following: As a capability consumer with graphical capabilities, the pump can optionally display at least one flow process value, the name and unit of the process value using the OPC UA standard, provided that the paired system device provides at least one process value. Aside from the maximum number of allowed pairings, no other restrictions or conditions are imposed on negotiation or pairing. In a modified version, the list of properties would include at least one of the following: [Table 11] In such modified versions, the description of capability further implies that the paired system device can optionally provide the minimum and maximum values ​​of the range associated with the flow process value.

[0087] Interface Function 2 In the original version, interface function 2 displayed the pump motor speed and had control icons to start / stop the pump motor and to set the pump motor speed. In the modified version, the two control icons are removed from the GUI, and only the pump motor speed display is shown. Capability Interface Function 2 has the following description in the pump's device shape file: Domain: "Control", Purpose: "Pumping", Role: "Provider", Restrictions / Conditions: Exclusive. The list of properties is: [Table 12]

[0088] This capability description means that pump 13, as a capability provider with pumping skills, can provide control and monitoring of its pumping function using the OPC UA standard. A paired system device has exclusive use of the pumping function and can start / stop the pump, set the pump speed, and retrieve the current pumping status and speed. Because OPC UA tag values ​​are specified for control and monitoring, consumers can use the pump with an OPC UA client.

[0089] In a modified version, the list of properties would include at least one of the following: [Table 13] In such modifications, the capability description further implies that the pump 13 can provide minimum and maximum values ​​within the speed range.

[0090] Detection, Negotiation, and Pairing (DNP) Here, we will explain how system devices 13 and 14 can cooperate via the network 12 to establish a pairing state. This is primarily performed by the DNP managers 19 and 25 within system devices 13 and 14 through the discovery, negotiation, and pairing steps described below.

[0091] detection When a system device connects to a network using IP (e.g., Ethernet®, Wi-Fi, Bluetooth®, or cellular such as 5G), it can recognize other connected system devices, including discovery tools. Several architectures already exist that enable discovery across the entire network (for example, the "Bonjour" protocol defined by Apple®, and here, global or local discovery as proposed by the OPC UA standard). Visibility is limited only by potential security policies placed on the network. Using detection tools, system devices can maintain an up-to-date list of visible system devices with which they can exchange information. This list is updated especially when new system devices connect to or disconnect from the network.

[0092] negotiation Based on the capability descriptions provided in the device shapefile, negotiation is initiated between connected system devices: where each system device on the network: refers to the capability descriptions provided by other system devices, identifies matching capabilities based on capability feature domains, purposes, and roles, verifies that it can respect the limitations and conditions associated with the matching capabilities, and checks whether the list of properties provided by the matching capabilities is what is expected. The negotiation process occurs whenever a new system device is discovered on the network, disconnected from the network, or becomes unreachable.

[0093] Pairing Once negotiations are reached, the various contributors will agree on how to adapt to respect the limitations and conditions set out for their respective shared features. The pairing process is complete, and the negotiation between the two system devices is confirmed. Each capability consumer (each provider) remembers the provider's (each consumer's) ID and location (in this case, the OPC UA endpoint) to enable data exchange later.

[0094] Both the capability consumer and the capability provider will apply the limitations and conditions (if any) agreed upon during negotiations. The capability consumer locally issues access to a list of properties in the device shapefile of the consumed capability, allowing the GUI manager installed on the capability consumer to exchange data with the paired capability provider.

[0095] This can be achieved, for example, using a standard publication / subscription approach: when a system device is powered on, the DNP manager creates a specific data queue for each different pair (domain, purpose) described in the device shapefile; the GUI manager subscribes to the (domain, purpose) queue of interest; and each time a pairing occurs, the DNP manager issues access information to the corresponding (domain, purpose) data queue; and GUI manager subscribers to this queue are automatically triggered to access the description and adapt accordingly.

[0096] Certain situations may arise where various system devices on a network can provide specific capabilities that a consumer expects. In such cases, pairing may require a human operator to manually select the capability provider. Even when the conditions are explicitly stated in the ability description, situations may arise where operator approval is still required. Please note that unpairing requires operator intervention to distinguish between intentional disconnection of the system device and a communication failure. If there is no such voluntary action by the user, the disconnection of the system device will be considered abnormal, and appropriate action will be taken, such as generating an alarm. Here, we will explain how to unpair the devices.

[0097] Unpair As mentioned above, unpairing a system device from another paired system device requires a voluntary and explicit action from the user, allowing for distinction between intentional disconnection of the system device and communication failure. This can be done, for example, by providing a dedicated menu accessible to the user on the system device's graphical user interface, which lists each other system device with which the system device is paired, and from such a menu the user can explicitly request to unpair the system device selected in the menu list.

[0098] When the user requests to unpair with another selected system device, (i) a step is performed to remove the effects of the pairing step, (ii) a step is performed to remove any effects of the negotiation step, and (iii) a step is performed to temporarily prevent the system device and the other selected system device from performing the negotiation step.

[0099] 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 by the other selected system device and sends a request to proceed with unpairing to the other selected system device via the MtoM communication tool 18 or 24. The DNP manager 19 or 25 of the other selected system device then locally issues a status change for each capability consumed or provided to the system device and sends an acknowledgment of receipt of the request to proceed with unpairing to the system device via the MtoM communication tool 18 or 24.

[0100] For system devices and other selected system devices, the GUI manager 17 or 23 receives warnings about changes in the status of each relevant capability and adapts accordingly. To negate the effects of the negotiation step, any restrictions and conditions (e.g., exclusive) agreed upon by the capability consumer and capability provider during negotiation will be nullified.

[0101] Because previously shared functionality is now available for negotiation again, isolation is implemented by temporarily preventing system devices and other selected system devices from performing the negotiation step, for example using a timeout, which means not accepting the relevant system device in the negotiation step for a predetermined period of time, the length of which is not particularly important, but could be, for example, 1 minute, 2 minutes, 3 minutes, 4 minutes, 5 minutes, 10 minutes, or by using network connectivity, such as ignoring the relevant system device until it is disconnected from and reconnected to the network.

[0102] Here, we will explain in detail the pairing of the mixer with the pH sensor, the pairing of the pump with the flow sensor, the pairing of a previously paired mixer with the pH sensor, the pairing of a previously paired pump with the flow sensor, and the detachment of the paired pump and flow sensor from the mixer while the pH sensor remains paired with the mixer.

[0103] Pairing the mixer and pH sensor Features of the Mixer GUI When the operator powers on the mixer, they can access the basic P&ID GUI shown in Figure 4 locally via an interactive screen, or remotely using an interactive device 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 mandatory pump communicating with the tank inlet 1, and icon 29 representing an optional pump communicating with the tank inlet 2.

[0104] In the basic P&ID GUI, icon 27 is displayed in a way that indicates a tank with an agitator is present and in operation (e.g., displayed with a persistent solid line), and icon 28 is displayed in a way that indicates a required pump is missing (e.g., displayed with a blinking dashed line). ), Icon 29 is displayed in a way that indicates there are no optional pumps (for example, it is displayed with a persistent dashed line).

[0105] The way the two icons 28 and 29 representing the pump are displayed depends on the pairing status and is automatically updated to indicate that the corresponding pump system device is paired (for example, by displaying the icon with a persistent solid line). Further details regarding the P&ID GUI for pairing with the pump will be discussed later in the section on pairing the mixer and pump. Next, we will describe the P&ID GUI for pairing with the pH sensor.

[0106] When the mixer is powered on, its DNP manager creates a capability data queue ("Graphics," "Process Value Display") on 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 issued in this queue.

[0107] Later, when a system device providing the expected properties ("Graphics," "Process Value Display") is paired with the mixer, the mixer's DNP manager issues a description of this capability ("Graphics," "Process Value Display") to the data queue, triggering the GUI manager to access the issued description and adapt the P&ID GUI accordingly by further displaying the current process value (in this case pH) and the process value trend curve 30, as shown at the top of Figure 5.

[0108] In fact, as mentioned above, the mixer's device shapefile includes a capability called Interface Function 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 following description: Capability with Graphics Skills: As a consumer, the mixer can display process values ​​from multiple paired system devices, provided that the multiple 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.

[0109] Features of the pH Sensor GUI When the operator powers on the pH sensor, they can remotely access the original GUI shown in the lower left of Figure 5 using an interactive device 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.

[0110] When the pH sensor is powered on, its DNP manager creates a capability data queue ("Graphics," "Process Value Display") on 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 issued in this queue.

[0111] Later, when a system device with the expected characteristics ("graphics," "process value display") is paired with the pH sensor, the pH sensor's DNP manager issues a description of this capability ("graphics," "process value display") to the data queue and displays the additional message "connected"33, which triggers the GUI manager, as shown in the lower right of Figure 5, to access the issued description and adapt the GUI accordingly.

[0112] In fact, as described above, the pH sensor's device shapefile encompasses its capabilities, and in the case of a modified format, it holds a display of the current value measured by the pH sensor and a trend curve representing the change in pH over time, and adds a display indicating that the flow sensor is paired with the appropriate other system device, which in this case is the message "Connected"33; this capability has the following description: As a capability provider, the pH sensor can provide a pH (and pH only) process value display dataset to a system device paired using the OPC UA standard. The dataset contains the process value, its name, and its units. Since an OPC UA tag value is specified for each data item, the paired system device can read these values ​​with an OPC UA client. There are no particular restrictions or conditions on negotiation or pairing.

[0113] DNP sequencing The operator connects the mixer and pH sensor to the same network 12. Once the above DNP is executed and complete, the mixer's P&ID GUI and the pH sensor's GUI will automatically update; the mixer's P&ID GUI will further display the current pH value and a pH value trend curve30; and the pH sensor's GUI will further display the message "Connected"33. It goes without saying that in order for the pH sensor to sense the pH of the fluid being processed by the mixer, the pH sensor must be in physical contact with the mixer.

[0114] The message "Connected" on the pH sensor's GUI clearly indicates that the pH sensor is in a paired state, not a standalone state. Here, we will describe in detail an example of a DNP sequence. In this example, the pH sensor is initially connected to network 12 using IP, but of course, the reverse is also possible. Since the pH sensor is a capability provider of the capabilities described in the device shape file 26, as long as the pH sensor is connected to the network 12, its MtoM communication tool 24 will provide the sensed pH value in real time and, thanks to the included OPC UA server, will be available on the network 12 at the OPC UA endpoint specified in the capability description of the device shape file 26, i.e., opc.tcp: / / pH / 4:control / 4:.

[0115] To enable DNP, in the pH sensor, the DNP manager 25 provides data to the MtoM communication tool 24, making the capability description in the device shape file 26, which includes the characteristics in the capability description, available; the DNP manager 25 creates a data queue ("graphics", "process value display") for this capability within the digital controller 22 of the pH sensor. The MtoM communication tool 24 then waits for the detection of another system device on the network 12. Next, in preparation for adaptation at the pH sensor, the GUI manager 23 subscribes to the data queue ("Graphics", "Process Value Display") created by the DNP manager 25 and displays the original GUI format.

[0116] Next, the mixer connects to the network and performs a similar procedure according to its device shapefile 20, as detailed 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 then creates data queues ("graphics", "process value display") for capability interface function 1 and ("control", "pumping") for capability interface functions 2, interface function 3, and interface function 4 in the mixer's digital controller 16. The MtoM communication tool 18 then waits for the discovery of another system device on the network.

[0117] Still within the mixer, in preparation for adaptation, GUI Manager 17 subscribes to the ("Graphics", "Process Value Display") and ("Control", "Pumping") data queues created by the DNP Manager and displays the basic P&ID GUI.

[0118] In the pH sensor, when the MtoM communication tool 24 detects that the mixer is connected to the network 12, it notifies the DNP manager 25 of this, which requests the MtoM communication tool 24 to provide a capability description provided 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 limitations / conditions. The DNP manager 25 then requests the MtoM communication tool 24 to suggest to the mixer that it apply a pairing between the local capability and the capability interface function 1 within the mixer.

[0119] When the MtoM communication tool 24 receives a pairing acceptance, it provides the pairing acceptance to the DNP manager 25, which issues a description of the mixer's 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's capability 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 mixer's capability interface function 1, and displays the modified GUI, i.e., displays the additional message "Connected" 33. The modified GUI is displayed until a pairing is unpaired.

[0120] In the mixer, when the MtoM communication tool 18 detects that the pH sensor is connected to the network 12, it notifies the DNP manager 19, which requests the MtoM communication tool 18 to provide a 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 function 1 made available by the pH sensor and the local capability with applicable limitations / conditions.

[0121] When the MtoM communication tool 18 receives confirmation from the pH sensor that the capability interface function 1 has been applied, the confirmation is forwarded to the DNP manager 19, which issues a description of the pH sensor's capability ("graphics", "process value display") to the data queue.

[0122] The GUI manager 17 is automatically notified of publications in the data queue ("Graphics", "Process Value Display") and receives a description of the pH sensor's capabilities, including the OPC UA tag of the flow value opc.tcp: / / pH / 4:control / 4:V. It then adapts the P&ID GUI by further 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 an unpairing occurs.

[0123] Pairing of pump and flow sensor Pump GUI Features Once the operator powers on the pump, they can remotely access the basic GUI shown in the left center of Figure 6 from a 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, and a display 36 of the current pump speed and a curve display 37 that show the change in pump speed over time.

[0124] When the pump is powered on, its DNP manager 25 creates a capability data queue ("Graphics," "Process Value Display") on the pump's digital controller 22. The pump's GUI manager 23 subscribes to the capability data queue ("Graphics," "Process Value Display") and displays the basic GUI until a new capability description is issued to this queue.

[0125] Later, when a system device providing the expected capabilities ("graphics," "process value display") is paired with the pump, the pump's DNP manager 25 issues this capability description to the ("graphics," "process value display") data queue, triggering the GUI manager 23 to access the issued description and, accordingly, adapt the GUI by further displaying the current flow value and the flow value trend curve 38, as shown in the center right of Figure 6.

[0126] In fact, as mentioned above, the pump's device shape file includes a capability named Interface Feature 1, which, when enabled, complements the GUI with data provided by the paired system device; this capability has the following description: The pump, as a capable consumer with graphical skills, can optionally display only one flow process value using the OPC UA standard, provided that the paired system device provides at least the process value, the name of the process value, and the units. No other restrictions or conditions are imposed on negotiation or pairing, except for the maximum number of allowed pairings.

[0127] Features of the Flow Sensor GUI When the operator powers on the flow sensor, they can remotely access the original GUI shown in the lower left of Figure 6 using an interactive screen device 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.

[0128] When the flow sensor is powered on, its DNP manager 25 creates a capability data queue ("graphics," "process value display") within 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 issued to this queue.

[0129] Later, when a system device that uses the capabilities of the expected properties ("graphics", "process value display") is paired with the flow sensor, the flow sensor's DNP manager 25 issues this capability description to the ("graphics", "process value display") data queue, triggering the GUI manager 23 to access the issued description and adapt the GUI accordingly by simply displaying the message "Connected" 41, as shown in the lower right of Figure 6.

[0130] In fact, as described above, the device shape file 26 of the flow sensor contains the capability, and in the modified format, it replaces the display of a trend curve representing the change in flow over time with a display of the current value measured by the flow sensor and a display indicating that the flow sensor is paired with the appropriate other system device, this display here being the message "Connected" 41; this capability has the description that means: As a capability provider, the flow sensor can provide a flow (and flow only) process value display dataset to a system device paired using the OPC UA standard.

[0131] The dataset contains process values, their names, and their units. Each data entry has an OPC UA tag value, allowing paired system devices to read these values ​​with an OPC UA client. There are no particular restrictions or conditions on negotiation or pairing.

[0132] DNP sequencing The operator connects the pump and flow sensor to the same network 12 (Figure 3). Once the above DNP is executed, the pump GUI and the flow sensor GUI are automatically updated: the pump P&ID GUI further displays the current flow value and the flow value trend curve38; the flow sensor GUI displays only the message "Connected"41. Needless to say, 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 way to the pump or the pipe through which the pump-driven fluid flows, as shown at the top of Figure 6 by reference numeral 42.

[0133] Since both the pump and the flow sensor are machine helpers 14, note that the physical connection 42 is between the two processor helpers 21 (and not between the fluid processor 15 and the processor helper 21). Furthermore, it is noteworthy that the pump's DNP manager 25 can act as the bioprocess machine 13's DNP manager 19 in relation to the flow sensor's DNP manager 25, and thanks to the fact that the capability pump interface function 1 has the same role characteristic "consumer" as each capability of the bioprocess machine 13's device shape file 20, they cooperate via the network 12 to establish a pairing state between the pump and the flow sensor.

[0134] The message "Connected" 41 on the flow sensor's GUI clearly indicates that the flow sensor is in a paired state and not a standalone state. Here, we will describe in detail an example of a DNP sequence. In this example, the flow sensor is initially connected to network 12 using IP, but of course, the reverse is also possible.

[0135] Since the flow sensor is a capability provider of 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 provide the sensed flow values ​​in real time and make them available on the network 12 thanks to the OPC UA server that contains them at the OPC UA endpoint specified in the capability description of the device shape file 26, i.e., opc.tcp: / / flow / 4:control / 4:.

[0136] To enable DNP, in the flow sensor, the DNP manager 25 provides data to the MtoM communication tool 24 to make the capability description in the device shape file 26, which includes the capability description properties, available; the DNP manager 25 creates data queues ("graphics", "process value display") for this capability within the digital controller 22 of the flow sensor. The MtoM communication tool 24 then waits for the detection of another system device on the network 12.

[0137] Still in the flow sensor, in preparation for adaptation, the GUI manager 23 subscribes to the data queue ("graphics", "process value display") created by the DNP manager 25 and displays the original form of the GUI.

[0138] Next, the pump is connected to the network and a similar procedure is performed according to its device shape file 26, as detailed below. Regarding capability interface function 2 (where the pump is the capability provider), as long as the pump is connected to network 12, its MtoM communication tool 24 provides the pump's operating parameters (start / stop control, start status, speed setting and value) in real time, which become available on network 12 thanks to the OPC UA servers that include opc.tcp: / / start, opc.tcp: / / started, and opc.tcp: / / speed / 4, respectively, at the OPC UA endpoints specified in the capability description of the device shape file 26.

[0139] To enable DNP, in 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, which include properties for each capability description; the DNP manager 25 creates data queues ("graphics", "process value display") for capability interface function 1 and ("control", "pumping") for capability interface function 2 within the pump's digital controller 22. The MtoM communication tool 24 then waits for the discovery of another system device on the network 12.

[0140] While still inside the pump and preparing for adaptation, the GUI manager 23 subscribes to the data queues created by the DNP manager 25 ("Graphics", "Process Value Display") and ("Control", "Pumping") and displays a basic GUI.

[0141] When the flow sensor detects that the pump is connected to network 12, the MtoM communication tool 24 notifies the DNP manager 25 of this, 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 the local capability with applicable limitations / conditions. The DNP manager 25 then requests the MtoM communication tool 24 to suggest to the pump that a pairing be applied between the local capability and the capability interface function 1 within the pump.

[0142] When the MtoM communication tool 24 receives a pairing acceptance, it provides the pairing acceptance to the DNP manager 25, which issues a description of the pump's capability interface function 1 in the data queue ("Graphics", "Process Value Display") and requests the MtoM communication tool 24 to confirm the application of the pump's capability interface function 1. The GUI manager 23 is automatically notified of the publication in the data queue ("Graphics", "Process Value Display") and receives the description of the pump's capability interface function 1, i.e., displays the modified GUI, i.e., displays only the message "Connected" 41. The modified form of the GUI is displayed until a pairing unpair occurs.

[0143] In the pump, when the MtoM communication tool 24 detects that the flow sensor is connected to the network 12, it notifies the DNP manager 25 of this, which requests the MtoM communication tool 24 to provide a capability description indicated by the flow sensor. Once the capability description is provided, it is reviewed by the DNP Manager 25, which identifies a match between the capability interface function 1 made available by the flow sensor and the local capability with applicable limitations / conditions.

[0144] When the MtoM communication tool 24 receives confirmation from the flow sensor that the capability interface function 1 has been applied, the confirmation is forwarded to the DNP manager 25, which issues a description of the flow sensor's capability in the data queue ("Graphics", "Process Value Display").

[0145] The GUI manager 23 automatically receives notification of publications in the data queue ("Graphics", "Process Value Display") and receives a description of the flow sensor's capabilities, including the OPC UA tag of the flow value opc.tcp: / / flow / 4:control / 4:V, and further displays the current flow value and the flow value trend curve 38, thereby adapting the GUI as shown in the center right of Figure 6. Thanks to the OPC UA client in the MtoM communication tool 24, the tags provided to the flow value are used to continuously update the flow value until an unpairing occurs.

[0146] It should be noted that the pump device shape file 26 has the additional capability to allow the pump to provide the flow values ​​sensed by the flow sensor, as if the flow sensor were part of the pump. This will be discussed later. For now, it is sufficient to note that this allows the 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.

[0147] Pairing of previously paired mixers and pH sensors with previously paired pumps and flow sensors. Further features of the mixer GUI As described above, when paired with the pH sensor, the mixer's P&ID GUI will, with respect to the basic P&ID, as shown at the top of Figure 5, This is supplemented by the display of the pH value and the pH trend curve.

[0148] As mentioned above, the basic P&ID GUI shown in Figure 4 has an icon 27 representing a tank with a stirrer, an icon 28 representing a required pump that has fluid communication with tank inlet 1, an icon 29 representing an optional pump that has fluid communication with tank inlet 2, an icon 27 that is displayed in a way that indicates that a tank with a stirrer exists and is in operation (e.g., displayed with a persistent solid line), an icon 28 that is displayed in a way that indicates that a required pump is missing (e.g., displayed with a blinking dashed line), and an icon 29 that is displayed in a way that indicates that there is no optional pump (e.g., displayed with a persistent dashed line).

[0149] The way the two icons 28 and 29 representing the pump are displayed depends on the pairing status and is automatically updated to indicate that the corresponding pump system device is paired (for example, by displaying the icon with a persistent solid line).

[0150] Further details regarding pairing with pH sensors are provided elsewhere in this specification. We will explain the pairing with the pump in more detail later.

[0151] When the mixer is powered on, its DNP manager 19 creates a ("control", "pumping") capability data queue within 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 way that indicates there are no required pumps until a new capability description with a Control_Local_Name equal to "Pump_on_inlet1" is issued in this queue (for example, displayed as a blinking dashed line). Icon 29 is displayed in a way that indicates there are no optional pumps until a new capability description with a Control_Local_Name equal to "Pump_on_inlet2" is issued in this queue (for example, displayed as a persistent dashed line).

[0152] Later, when a system device providing the ("control", "pumping") capability is paired with the mixer, the mixer's DNP manager 19 issues a description of this capability completed with Control_Local_Name equal to "Pump_on_inlet1" in the ("control", "pumping") capability data queue, triggering the GUI manager 17 to access the issued description and, accordingly, adapt the P&ID GUI by displaying an icon 28 in a way that indicates the required pump is paired (e.g., displayed with a persistent solid line), as shown in the upper right of Figure 7.

[0153] In fact, as described above, the mixer's device shape file 20 includes a capability called Interface Function 2, which, when enabled, adapts the P&ID GUI to display whether the required expected pump is paired, supplementing the P&ID GUI with a display of control icons and the operating parameters of the paired pump, and this capability has the following description: The mixer, as a capability consumer with control skills, is required to force the system device, which is the pump, to pair and perform the defined role of the pump connected to inlet 1.

[0154] For pairing to occur, the system device must be forced to enable start / stop commands and provide its current start state. If provided by the paired system device, the mixer can control and monitor the pump speed. Operator confirmation is required during the pairing procedure. Once paired, the mixer can exclusively use the system device, which is the pump.

[0155] Similarly, when a system device that later provides ("control", "pumping") capability is paired with the mixer, the mixer's DNP manager 19 issues a description of this capability completed with Control_Local_Name equal to "Pump_on_inlet2" in the ("control", "pumping") capability data queue, triggering the GUI manager 17 to access the issued description and, accordingly, adapt the P&ID GUI by displaying an icon 29 in a way that indicates an optional pump is paired (e.g., displayed with a persistent solid line).

[0156] In fact, as described 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, supplementing the P&ID GUI with a control icon and a display of the paired pump's operating parameters; this capability has the following description: The mixer, as a capability consumer with control skills, can control an optional system device which is a pump to achieve a predefined role for the pump connected to inlet 2.

[0157] For pairing to occur, the system device must be forced to enable start / stop commands and provide its current start state. If provided by the paired system device, the mixer can control and monitor the pump speed. Operator confirmation is required during the pairing procedure. Once paired, the mixer can exclusively use the system device, which is the pump.

[0158] Further features of the pump GUI The operator connects the pump to the same network 12. When the mixer detects a pump, the mixer's P&ID GUI alerts the operator (for example, on a display not shown in a pop-up window) to ensure that a pump that meets the expected requirements for the pump is available and usable, and prompts them to select one of the available pumps.

[0159] Once the operator has physically connected the pump to mixer inlet 1, select inlet 1 can be selected. The flow sensor GUI remains unchanged; in other words, message 41 is displayed, as shown at the bottom of Figure 7. The mixer's P&ID GUI and the pump's GUI will be automatically updated.

[0160] In the mixer's P&ID GUI, as shown at the top of Figure 7, an icon 28 is displayed indicating that a required pump is present and operating at inlet 1 (for example, displayed with a persistent solid line), and the control panel 44 is displayed in the mixer's P&ID GUI, allowing the operator to control and monitor the pump at inlet 1. The control panel 44 includes start / stop buttons for operating the pump, a variator for changing the pump speed, and a display of a trend curve representing the fluctuation of the flow rate measured by a flow meter paired with the pump.

[0161] In the pump's GUI, as shown in the center of Figure 7, the start / stop button 34 for operating the pump and the variator 35 for changing the pump speed are disabled. Only the flow rate and speed are displayed. When the pump is powered on, its DNP manager 25 creates a ("control", "pumping") capability data queue within the pump's digital controller 22. The pump's GUI manager 23 subscribes to the ("control", "pumping") capability data queue and displays the basic GUI until a new capability description is issued to this queue.

[0162] Later, when a system device providing the ("control", "pumping") capability with the expected characteristics is paired with the pump, the pump's DNP manager 25 issues a description of this capability in the ("control", "pumping") capability data queue, triggering the GUI manager 23 to access the issued description and adapt the GUI accordingly by releasing start / stop buttons 34 that allow the pump to be operated and a variator 35 that allows the pump speed to be changed.

[0163] In fact, as mentioned above, the pump device shape file 26 includes a capability named interface function 2, which in its original form has a control icon (button 34) that displays the pump motor speed and allows the pump motor to be started / stopped, and a control icon (variator 35) that allows the pump motor speed to be set.

[0164] In the modified format, the two control icons are removed from the GUI, and only the pump motor speed display is shown; this capability has the following description: The pump, as a capability provider with pumping skills, can provide control and monitoring of pumping functionality using the OPC UA standard. The paired system device has exclusive use of the pumping functionality and can start / stop the pump, set the pump speed, and retrieve the current start state and speed. Because separate OPC UA tag values ​​are specified for control and monitoring, the consumer can use the pump with an OPC UA client.

[0165] DNP sequencing The mixer (previously paired with a pH sensor) and the pump (previously paired with a flow sensor) are deployed on the same network 12, allowing them to recognize each other and initiate a negotiation step. The pump will be made available for use with the capability interface function 2.

[0166] The mixer enables the use of three capabilities ("control", "pumping") that share the same domain and purpose: capability interface function 2, which requires the pumping system to be forcibly paired to achieve a defined role for the pump connected to inlet 1; capability interface function 3, which allows the mixer to control and monitor an optional pump system to achieve a defined role for the pump connected to inlet 2; and capability interface function 4, which allows the mixer to control and monitor other optional pump systems.

[0167] All three abilities are consistent with the abilities that Pump exhibits. Once negotiation is successful, the pairing procedure can begin. The pump's capabilities have one defined limitation / condition: "Only one system can be paired with the pump to use this capability." Since there is no system yet paired with a pump that uses this capability, this condition is confirmed and pairing becomes possible. Two of the three capabilities of the mixer have a single restriction / condition defined: "Operator confirmation is required during pairing." Pairing is only achieved if confirmed by the operator.

[0168] Next, a warning message is displayed by the mixer's P&ID GUI (not shown; for example, it appears in a pop-up window) prompting the operator to assign the pump to one of three possible uses. Once the operator assigns the pump to inlet 1, the pairing procedure continues. Both the mixer and pump remember the identification and location (OPC UA endpoint) of the paired system for this function. In the illustrated example, only the mixer uses this information to later control and monitor the pump. Once paired, the pump is also prevented from pairing with another system that has this capability.

[0169] On both the mixer and the pump, the DNP manager 19 or 25 issues capability descriptions to the capability data queues ("Control" and "Pumping"). To match the operator's selection, on the mixer side, this function is issued with the "Control Application" value set to "Pump_on_inlet1". As mentioned above, for both the mixer and the pump, GUI manager 17 or 23 subscribes to its capacity data queue and updates it automatically.

[0170] In a modified version not shown, instead of disconnecting the pump from the GUI, when pairing the pump with another appropriate system device such as a mixer, the start / stop button 34 and variator 35 are disconnected, and only the variator 35 is disconnected from the pump's GUI, while the start / stop button 34 remains active.

[0171] The pH sensor remains paired with the mixer, and the paired pump and flow sensor are removed from the mixer. As mentioned above, unpairing a system device from another paired system device requires a voluntary and explicit action from the user, which allows for the distinction between intentional disconnection of the system device and communication failure. This is accomplished by providing a dedicated menu (not shown in the diagram) that the user can access through the GUI of each system device. In this example, the mixer's P&ID GUI, the pH sensor's GUI, the pump's GUI, and the flow sensor's GUI each have such a dedicated menu.

[0172] This dedicated menu lists each other system device to which the system device is paired, and from such a menu, the user can explicitly request to unpair the system device selected in the menu list. When the user requests to unpair with another selected system device, the following steps are performed: (i) to cancel the effects of the pairing step, (ii) to cancel the effects of the negotiation step, if any, and (iii) to temporarily prevent the system device and the other selected system device from performing the negotiation step.

[0173] 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 by the other selected system device and sends a request to proceed with unpairing to the other selected system device via the MtoM communication tool 18 or 24.

[0174] Next, the DNP manager 19 or 25 of the other selected system device locally issues status changes for each capability consumed by or provided to the system device, and sends an acknowledgment of receipt of the request to proceed with unpairing via the MtoM communication tool 18 or 24 to the system device.

[0175] For system devices and other selected system devices, the GUI manager 17 or 23 receives warnings about changes in the status of each relevant capability and adapts accordingly. Figure 8 shows the changes in the mixer's P&ID GUI, pump GUI, and flow sensor GUI, in addition to user selection. The pump paired with the flow sensor can be unpaired from the mixer via the mixer's dedicated menu.

[0176] Within the mixer, the DNP manager 19 issues a state change for the corresponding capability, i.e., interface function 2, to the appropriate queue, i.e., the ("control", "pumping") queue, which triggers the GUI manager 17 to adapt accordingly by disabling capability interface function 2, as shown at the top of Figure 8, and the control panel 44 is released from the mixer's P&ID GUI. Within the mixer, the DNP manager 19 then requests the MtoM communication tool 18 to send a request to the pump to proceed with unpairing.

[0177] This request is sent via network 12, received by the pump's MtoM communication tool 24, forwarded to the pump's DNP manager 23, which then issues it to the appropriate queue, i.e., the ("control", "pumping") queue, issuing a status change for the corresponding capability, i.e., interface function 2, which triggers the GUI manager 23 to adapt accordingly by returning the capability interface function 2 to its original form, so that the variator 35 and start / stop button 34 are present on the pump's GUI, as shown in the center of Figure 8.

[0178] Since the flow sensor is not involved in the unpairing process (it remains paired with the pump), no action is taken, and therefore its GUI remains unchanged, as shown at the bottom of Figure 8. The same applies to the pH sensor, which is not involved in the unpairing process (it remains paired with the mixer). The pump's DNP manager 25 sends an acknowledgment of receipt of the request to proceed with unpairing via the MtoM communication tool 24 to the mixer.

[0179] As mentioned above, the (exclusive) negotiation step between the mixer and pump is disabled; and since the previously shared capabilities can now be used for negotiation again, the aforementioned isolation is implemented to temporarily prevent the mixer and pump from performing the negotiation step. Other unpairings (mixer and pH sensor, pump and flow sensor) are performed in the same way.

[0180] Ability transmission As mentioned above, the pump has the additional capability to provide the flow values ​​sensed by the flow sensor, as if the flow sensor were part of the pump itself. This additional capability, named Interface Function 3, is described in the pump's device shape file 26. The description of capability interface function 3 includes an identifier (capabilityUniqueID) which also references the identifier of another capability (refToCapabilityUniqueID), i.e., the associated capability of the flow sensor paired with the pump, if any. In this regard, for the sake of simplifying the disclosure above, it should be noted that each capability description includes a unique identifier (capabilityUniqueID) for that capability, which in this example is a four-digit value.

[0181] Interface function 3 If available, interface function 3 is similar to the interface function of the pH sensor disclosed above: in the modified form, interface function 3 of the pump holds a display of the current value measured by the flow sensor, and the trend curve represents the change in flow over time while the display is changed to indicate that the pump is paired with the appropriate other system device, which is here done by interface function 2 when paired with the appropriate other system device such as a mixer, by releasing two control icons 34 and 35 from the pump's GUI.

[0182] Capability Interface Function 3 has the following description in the pump's device shape file 26: Domain: "Graphics", Purpose: "Process Value Display", Role: "Provider", Limitations / Conditions: NotAvailable. The list of properties is: [Table 14]

[0183] In these cases, the `capabilityUniqueID` property is a unique identifier for the pump's interface function 3; a tag attribute "tag=undefined, source=refToCapabilityUniqueID" is provided, which is updated when paired with the flow sensor and uses the corresponding attribute in the description of the flow sensor's capability issued to the queue ("Graphics", "Process Value Display") within the pump. The limit / condition features are also updated to be the same as the flow sensor's capability; such updates indicate that capability interface function 3 is available.

[0184] The description of pump capability interface function 3 means that the pump, as a capability provider, can provide a flow (and flow only) process value display dataset to a system device paired using the OPC UA standard. This capability is negotiable only if enabled by the pump. The dataset includes the process value, its name, and its units.

[0185] Generally, capabilities such as interface function 3 operate when activated in the same way as the capabilities of other paired system devices, and can be provided to system devices other than the pump, as if they were coming from the system device itself.

[0186] For convenience, a mechanism involving capabilities such as the pump's interface function 3 can be called capability propagation, and a source capability (such as the flow sensor's capability) can activate a capability that replicates the source capability (such as interface function 3), referring to the fact that the source capability (such as the flow sensor's capability) becomes available in the same material through a system device such as a pump; capabilities such as interface function 3 can be called capability transfer functions (propagators).

[0187] It goes without saying that such a capability (such as interface function 3) replicates the source capability, so the capability provided by the bioprocess machine 13 (here a mixer) replicates the capability provided by the associated machine helper 14 (here a pump).

[0188] Multiple shared capabilities In a non-illustrated variant, the pump does not have the capability as interface function 3: since the flow sensor is paired with both the pump and the mixer instead of being paired only with the pump, the mixer obtains the flow value directly from the flow sensor (not from the pump that obtains the flow value from the flow sensor).

[0189] In fact, in the capability of the flow sensor, there is no restriction on the number of other system devices that are permitted to pair, but the capability interface function 1 of the mixer can display process values from a plurality of paired system devices such as the flow sensor in addition to the pH sensor. For convenience, the fact that a capability (such as the capability of a flow sensor) is consumed by a plurality of other system devices can be referred to as multiple sharing of the capability.

[0190] ability stratification In another non-illustrated variant, the capability interface function 3 not only simply replicates the source capability (the capability of the flow sensor), but also enables the provision of an additional function that the pump cannot provide without the flow sensor, namely flow regulation.

[0191] Interface function 3 When interface function 3 is available, control and monitoring of the pump speed can be performed to regulate the flow rate through the pump using the OPC UA standard. The capability interface function 3 has the following description in the device shape file of the pump: Domain: "Control", Purpose: "PV regulation", Role: "Provider", Restriction / Condition: Exclusive, NotAvailable. The list of properties is: [Table 15]

[0192] In these cases, the capabilityUniqueID property is a unique identifier for the pump's interface function 3; a tag attribute "tag=undefined, source=refToCapabilityUniqueID" is provided and updated upon pairing with the flow sensor, along with the corresponding attribute in the description of the flow sensor's capability issued to the queue ("Graphics", "Process Value Display") within the pump. Limitation / conditional features are also updated to indicate that capability interface function 3 is available.

[0193] The description of pump capability interface function 3 means the following: The pump, as a capability provider with process value adjustment skills, can provide control and monitoring of the pump speed to adjust the flow through the pump using the OPC UA standard. This capability is negotiable only when enabled by the pump. Paired system devices, such as mixers, have exclusive control and can start / stop adjustments, set adjustment parameters, and retrieve data from process values.

[0194] Generally, the capabilities provided by activating additional functions such as interface function 3 can be offered to paired system devices other than flow sensors, and to system devices other than pumps. For convenience, a mechanism including capabilities such as the pump's interface function 3 can be called a functional hierarchy, referring to the fact that source capabilities (such as the flow sensor's capabilities) are embedded in more complex capabilities; and capabilities such as interface function 3 can be called a hierarchical capability.

[0195] Such capabilities (such as interface function 3) may include source capabilities, but the capabilities provided by the bioprocess machine 13 (mixer in this case) do not necessarily have to embed the capabilities provided by the machine helper 14 (pump in this case). As used herein, the term “hierarchical capability” is generally used to indicate that source capabilities are required for a machine helper to issue / display a hierarchical capability. For example, “volume calculation” as a hierarchical capability requires “length,” “height,” and “depth” as source capabilities, depending on the shape of the volume to be determined.

[0196] Variations of a system device with a recipe manager Figure 9 shows a modified system device, similar to Figure 3, in which the digital controller 16 of the bioprocess machine 13 further includes a recipe manager 50, and the digital controller 22 of the machine helper 14 further includes a recipe manager 51. In the bioprocess machine 13, the recipe manager 50 enables the display of a GUI (as shown in Figures 11 to 13) locally on an interactive screen or remotely on a device with an interactive screen, such as a tablet or smartphone. In Machine Helper 14, the Recipe Manager 51 is not configured to display a GUI.

[0197] Recipe management In automation, especially with recipes, the key concepts are criteria (testable values) and actions. A recipe primarily consists of an ordered set of instructions, which are used to evaluate actions on the controlled device (such as starting a motor, setting a heating setpoint, changing alarm conditions, setting controller constants, etc.) or data acquired from the controlled device (process values, machine status, alarm status, etc.) as the basis for testing. A recipe can include recipe execution controls that define the order in which instructions are executed (e.g., loop instructions, conditional branching, etc.).

[0198] The following is an example of a recipe. "While (pH > 6) do [= recipe execution control and criteria evaluation] Inlet1.Valve.Open TRUE [= action] Wait 500 ms [= recipe execution control] Inlet1.Valve.Open FALSE [= action] If (pH < 3) do [= recipe execution control and criteria evaluation] Prompt 'Too acid' [= action] Else [= recipe execution control and criteria evaluation] Prompt 'pH OK' [= action]" As shown in Figure 10, the recipe manager 50 of the bioprocess machine 13 has three modules, namely an editor 52, a loader 53, and an executor 54 respectively.

[0199] The editor 52 allows a user to create a recipe in a human-readable manner and assemble available instructions for the bioprocess machine 13. The recipe can be selected to be executed on the bioprocess machine 13. The loader 53 converts the human-readable instruction set into a machine-oriented instruction list, then loads the instruction list into the executor 54 to execute the converted instructions in a predefined order. In general, the recipe manager 50 of the bioprocess machine 13 and the recipe manager 51 of the machine helper 14 are configured in a paired state as follows:

[0200] - The recipe manager 50 of the bioprocess machine 13 has at least one provided capability that it does not have when not in a pairing state. The capabilities provided are automated functions for controlling and / or testing the operating parameters of the processor helper 21, or for testing the physicochemical or biological quantities of the fluid sensed by the processor helper 21; and

[0201] - The recipe manager 51 of the machine helper 14 has at least one consumed capability which it does not have when not in a pairing state, where if the provided capability is an automated capability that controls and / or tests the operating parameters of the processor helper 21, the consumed capability is a response-on-request capability that controls and / or makes available the operating parameters, and if the provided capability is an automated capability that tests the physicochemical or biological quantities of the fluid sensed by the processor helper 21, the consumed capability is a response-on-request capability that makes available the physicochemical or biological quantities.

[0202] Of course, each such automated function is a recipe instruction, the control of such operational parameters is an action, and such operational parameters, physicochemical quantities, or testable biological quantities are criteria. In practice, the automation or response-on-request function exists, but it is disabled if system device 13 or 14 is not paired with another appropriate system device, and enabled if system device 13 or 14 is paired with another appropriate system device.

[0203] Here, we will describe the operation of the recipe manager 50 when the mixer is in a standalone state (Figure 11), and the operation of the recipe managers 50 and 51 when the mixer is paired with a pH sensor (Figure 12), and when the mixer is paired with a pH sensor and also with a pump that was previously paired with a flow sensor (Figure 13).

[0204] Operating Recipe Manager 50 when the mixer is in standalone mode. As described above, the recipe manager 50 enables the GUI to be displayed locally on an interactive screen, or remotely on a device with an interactive screen, such as a tablet or smartphone. Figure 11 shows this GUI when the mixer is in standalone mode.

[0205] This GUI has a section 55 which contains icon 56 corresponding to the mixer. When the mixer is in standalone mode, only icon 56 is displayed in section 55. The GUI of Recipe Manager 50 includes a button (not shown) that allows access to the window (not shown) displayed in Section 57.

[0206] This window is the GUI for Editor 52. This window contains a set of instructions related to the control and monitoring of the mixer's biotechnology fluid processor 15, which is formed by a tank equipped with a stirrer and an inlet, as disclosed above. This series of commands is based on actions and criteria that the mixer natively has, such as "start the agitator," "set the agitator speed," "set all alarms off," and the criterion "agitator speed."

[0207] These actions and criteria are described in the mixer's device shape file 20. In this window, you can create recipes using the available commands and save the recipes you have created. The Recipe Manager 50 GUI includes a menu (not shown) that allows you to select one of the saved recipes to load for execution.

[0208] During this operation, the recipe can be loaded at any time, so loader 53 checks whether the instructions used in the recipe are still defined for the mixer, then converts the instructions, and loads the result into executor 54. From the GUI of the recipe manager 50, the user can start the execution of a recipe. The executor 54 then automatically controls and monitors the mixer and executes the converted instructions sequentially in the order specified by the recipe.

[0209] Operation of Recipe Managers 50 and 51 when the mixer is paired with a pH sensor. Figure 12 shows the GUI of the recipe manager 50 when the mixer is paired with the pH sensor. Section 55 includes an icon 56 corresponding to a mixer, as well as an icon 58 corresponding to a pH sensor. On the GUI window (not shown) of editor 52, in addition to a series of instructions for controlling and monitoring the mixer's biotechnology fluid processor 15, there is at least one instruction that allows monitoring (by test) of the pH value provided by the pH sensor and more accurately detected by the pH sensor processor helper 21.

[0210] The pH sensor's recipe manager 51 is involved in a mechanism that allows monitoring of the pH value provided by the pH sensor, and the recipe manager 51 provides a response on request that makes the current pH value available. This will be explained in more detail later. The operation of the recipe manager 50 is the same as when the mixer is in a standalone state, except that additional commands are available that allow monitoring of the pH value provided by the pH sensor. As described above, users can create recipes using the available instructions and save the created recipes. The Recipe Manager 50 GUI includes a menu (not shown) that allows you to select one of the saved recipes to load for execution.

[0211] During this operation, since the recipe can be loaded at any time, the loader module 53 checks whether the instructions used in the recipe are still defined for the mixer, and in particular, if the pH sensor is still paired with the mixer, if there are instructions to monitor pH, it translates the instructions and loads the results into the executor 54. From the GUI of the recipe manager 50, the user can start executing a recipe. The executor 54 then automatically controls and monitors the mixer and pH sensor and executes the converted commands sequentially in the order specified by the recipe.

[0212] Operation of Recipe Managers 50 and 51 when the mixer is paired with a pH sensor and then with a pump that was previously paired with a flow sensor. Figure 13 shows the GUI of the recipe manager 50 when the mixer is paired with the pH sensor and also paired with the pump that was previously paired with the flow sensor. Section 55 includes an icon 56 corresponding to a mixer and an icon 58 corresponding to a pH sensor, as well as another icon 59 corresponding to a pump.

[0213] On a window (not shown) which is the GUI of editor 52, there are further commands that enable monitoring of the pH value provided by the pH sensor and more accurately sensed by the pH sensor processor helper 21 for the control and monitoring of the mixer's biofluid processor 15, monitoring of the flow value provided by the flow sensor and more accurately sensed by the flow sensor processor helper 21 (by testing), and control and monitoring of the pump, more precisely the pump processor helper 21 (by testing).

[0214] The pH sensor, flow sensor, and pump recipe manager 51 are involved in a mechanism that allows monitoring of pH values, flow values, and control and monitoring of the pump's operating parameters. Each recipe manager 51 provides a response that, upon request, makes the current pH value, flow value, or other criteria available, or provides a response that, upon request, controls and / or makes available the pump's operating parameters. This will be explained in more detail later.

[0215] The operation of the recipe manager 50 is the same as when the mixer is in a standalone state, except that additional commands are available that allow monitoring of the pH value provided by the pH sensor, monitoring of the flow value provided by the flow sensor, and controlling and monitoring the pump.

[0216] As described above, users can create recipes using the available instructions and save the created recipes. The Recipe Manager 50 GUI includes a menu (not shown) that allows you to select one of the saved recipes to load for execution. During this operation, the recipe can be loaded at any time, so the loader 53 checks whether the instructions used in the recipe are still defined for the mixer, in particular whether the necessary pH sensor and pump are still paired with the mixer, translates the instructions, and loads the result into the executor 54. From the GUI of the recipe manager 50, the user can start executing a recipe. The executor 54 then automatically controls and monitors the mixer, pH sensor, pump, and flow sensor, and executes the converted commands sequentially in the order specified by the recipe.

[0217] Recipe Domain In the above description of system devices 13 or 14 without recipe managers 50 or 51, as given with respect to Figures 3 to 8, all capabilities are interface functions of the GUI manager 17 of the bioprocess machine 13 and the GUI manager 23 of the machine helper 14, respectively, and the domain feature is "graphics" or "control". All of the above regarding the capabilities of GUI managers 17 and 23 are applied to recipe managers 50 and 51 with necessary modifications, and the capabilities, instead of being interface functions, are the automation function of recipe manager 50 for bioprocess machine 13 and the response-on-request function for recipe manager 51 for bioprocess machine 14, and the domain feature is "recipe".

[0218] In the example shown in the drawing, for the bioprocess machine 13, which is a mixer, the device shape file 20 further includes descriptions of two automated functions whose capabilities are provided when activated; for the machine helpers 14, which are a pH sensor, a pump, and a flow sensor, respectively, the device shape file 26 includes a description of at least one response-on-request function whose capabilities are consumed when activated.

[0219] Mixer automation function 1 Enabling the mixer's automation function 1 expands the recipe management capabilities with new standards provided by the paired system device, whatever that system device may be. When the capability automation function 1 is used in a recipe, the bioprocess machine, in this case the mixer, can automatically acquire data from the machine helper 14. The functionality of automation feature 1 includes the following description in the mixer's device shape file 20: Domain: "Recipe", Purpose: "Standard", Role: "Consumer", Limitations / Conditions: Optional. The list of properties is: [Table 16]

[0220] This capability description means that a mixer, as a capability consumer with recipe skills, can obtain process values ​​from its paired system device and use them as test criteria for the recipe. The paired system device must compel the provision of data for the following criteria: information used by Editor 52 (from the property shortDescription to the property valueMaxRange), and information used by Loader 53 and Executor 54 to execute the recipe (translatedInstruction, requestAddress, responseAddress). Some data must be provided as OPC UA tags. Some data (without constraints) is provided as needed by the capability provider. There are no restrictions or conditions on negotiation or pairing.

[0221] Note that the information used by editor 52 and the information used by loader 53 and executor 54 may include more properties than those described above. It should be further noted that instead of providing capabilities for each criterion, it is possible to provide capabilities for a set of criteria. In fact, since Machine Helper 14 can potentially propose dozens of recipe criteria, it is more efficient for negotiation to provide a single capability that provides recipe criterion data at once.

[0222] Mixer automation function 2 Generally, automation function 2 is similar to automation function 1, except that it is for actions rather than criteria. Enabling the mixer's automation function 2 expands recipe management capabilities with new actions provided by the paired system device, whatever that paired system device may be. When automation function 2 is used in a recipe, the machine helper 14 can be automatically controlled from the bioprocess machine 13, which is the mixer. The capability automation function 2 has the following description in the mixer's device shape file 20: Domain: "Recipe", Purpose: "Action", Role: "Consumer", Limitations / Conditions: Optional. The list of properties is: [Table 17]

[0223] This ability description means the following: Mixer, as an ability consumer with recipe skills, can perform actions on paired system devices and use them in recipes. Paired system devices must compel the provision of data for the following actions: data used by Editor 52 (from property shortDescription to property argumentMaxRange), and data used by Loader 53 and Executor 54 to execute recipes (translatedInstruction, requestAddress, responseAddress). Some data must be provided as OPC UA tags. Some data (without constraints) is provided as needed by the ability provider. There are no restrictions or conditions on negotiation or pairing.

[0224] Note that the information used by editor 52 and the information used by loader 53 and executor 54 may include more properties than those described above. Furthermore, it should be noted that instead of providing abilities to each individual action, you can provide abilities to a series of actions, and in fact, since a machine helper can potentially propose dozens of recipe actions, it is more efficient in negotiation to provide a single function that provides the recipe action data at once.

[0225] pH sensor response-on-request function When enabled, the pH sensor's Response-on-Request feature can provide a new standard for paired system devices, whatever they may be, to extend their recipe management capabilities. The Response-on-Request capability of the pH sensor is described in the pH sensor's device shape file 26 as follows: Domain: "Recipe", Purpose: "Standard", Role: "Provider", Limitations / Conditions: None. The list of properties is: [Table 18]

[0226] This capability description means that the pH sensor, as a capability provider with recipe skills, proposes that its pH value be used as the basis for recipes executed on the consumer executor 54. The consumer must force-wait for (and understand) the translatorInstruction, requestAddress, and responseAddress properties from the provider in order to access the pH value. There are no restrictions or conditions on negotiation or pairing.

[0227] Please note that the information used by editor 52, and the information used by loader 53 and executor 54 (translatedInstruction, requestAddress, responseAddress), can include many properties other than those listed above (from the shortDescription property to the valueMaxRange property).

[0228] It should be further noted that instead of providing capabilities for each criterion, it is possible to provide capabilities for a set of criteria, and in fact, since a machine helper may be able to propose dozens of recipe criteria, providing a single capability that provides recipe criterion data at once is more efficient in negotiation.

[0229] Flow sensor response-on-request function Enabling the flow sensor's response-on-request function provides a new standard for paired system devices, whatever they may be, to extend their recipe management capabilities. The response-on-request functionality of the capability flow sensor is described in the flow sensor's device shape file 26 as follows: Domain: "Recipe", Purpose: "Standard", Role: "Provider", Limitations / Conditions: None. The list of properties is: [Table 19]

[0230] This capability description means the following: The Flow Sensor, as a capability provider with a Recipe Skill, proposes a flow value to be used as a basis in recipes executed on the Consumer's Executor 54. The Consumer must force await (and understand) the translatorInstruction, requestAddress, and responseAddress properties from the provider in order to access the flow value. There are no restrictions or conditions on negotiation or pairing.

[0231] Please note that the information used by editor 52, and the information used by loader 53 and executor 54 (translatedInstruction, requestAddress, responseAddress), can include many properties other than those listed above (from the shortDescription property to the valueMaxRange property).

[0232] It should be further noted that instead of providing capabilities for each criterion, it is possible to provide capabilities for a set of criteria, and in fact, since a machine helper may be able to propose dozens of recipe criteria, providing a single capability that provides recipe criterion data at once is more efficient in negotiation.

[0233] Pump Response-On-Request Function 1 Generally speaking, the pump's capacity response-on-request function 1 is similar to the capacity response-on-request function of a pH sensor or flow sensor, except that the machine helper 14 is a pump (not a pH sensor or flow sensor), and the reference is the pump's motor speed (not the pH value or flow value).

[0234] Pump Response-On-Request Function 2 Enabling the Pump Response-On-Request feature 2 allows you to offer new actions to the paired system device, whatever it may be, to extend its recipe management capabilities. The Response-on-Request function 2 of the capacity pump has the following description in the pump's device shape file 26: Domain: "Recipe", Purpose: "Action", Role: "Provider", Restrictions / Conditions: None. The list of properties is: [Table 20]

[0235] This ability description means that a pump, as an ability provider with a recipe skill, proposes that the pump be started by a recipe executed on the consumer's executor 54. The consumer must force-wait (and understand) the translatorInstruction, requestAddress, and responseAddress properties from the provider so that it can start / stop the pump motor, as is possible with the start / stop button 34. There are no restrictions or conditions on negotiation or pairing.

[0236] Please note that the information used by editor 52, and the information used by loader 53 and executor 54 (translatedInstruction, requestAddress, responseAddress), can include many properties other than those listed above (from the shortDescription property to the valueMaxRange property).

[0237] Pump Response-On-Request Function 3 Generally, the response-on-request function 3 of the capacity pump is similar to the response-on-request function 2 of the capacity pump, but differs in that it sets the motor speed so that operation is possible with the variator 35.

[0238] Pump Response-On-Request Function 4 Generally, the pump's capacity response-on-request function 4 is similar to the capacity response-on-request function 2, but the action is flow adjustment, which is possible with the pump's capacity interface function 3 as a hierarchical capacity. The response-on-request function 4 is also a hierarchical capacity.

[0239] Note that instead of providing an ability to each individual action, you can provide an ability to a set of actions. In fact, since a machine helper can propose dozens of recipe actions, it is more efficient in negotiation to provide a single ability that provides the data for all recipe actions at once.

[0240] Furthermore, in this modified example, it should be noted that the pump's response-on-request function 4 is similar to the capability response-on-request function 1, but the criterion is the flow value provided by the flow sensor, which can be expressed as a capability transfer function in the version of the pump's capability interface function 3. In this modified example, the response-on-request function 4 is also a capability transfer function. In a further variation, the pump does not have the capability as a response-on-request function 4, and the flow sensor is paired with the pump and mixer, and its response-on-request function is a multiple shared capability.

[0241] DNP sequencing Between different pairings, the DNP sequence is executed by recipe managers 50 and 51, as described above for GUI managers 17 and 23, and the domain features involved are of course in the "recipe". Similar to GUI managers 17 and 23, the mixer's recipe manager 50 subscribes to data queues that have domain features in the “recipes”.

[0242] Once negotiation / pairing with the pH sensor is successful, the mixer's DNP manager 19 issues a description of the pH sensor reference capability to the ("Recipe", "Reference") queue. The recipe manager 50 is alerted that a new capability has been issued to this queue and can then extend its instruction set using the description provided to this queue.

[0243] Upon successful negotiation / pairing with the pump, the mixer's DNP manager 19 issues a description of the pump's base capability to the ("recipe," "base") queue and a description of the pump's operational capability to the ("recipe," "operational") queue. The recipe manager 50 is alerted that the new capabilities have been issued to these queues and can then extend its instruction set using the descriptions provided in these queues. In some embodiments, operator authorization for pair conditions is required only if specified, for example, in the negotiated DNP capability.

[0244] In the processor helper 14 (pH sensor, flow sensor, and pump), the recipe manager 51 does not subscribe to a data queue with domain features in the “recipe” because pairing is sufficient to transition the recipe manager 51’s response-on-request function from disabled (other system devices cannot make requests to it) to enabled (pairing allows paired system devices to make requests to it).

[0245] Loading and running recipes As mentioned above, the Recipe Manager 50 GUI has a menu (not shown) that allows you to select one of the stored recipes to load for execution. During this operation, recipes can be loaded at any time, so loader 53 checks whether the instructions used in the recipe are still defined for the mixer: if the recipe contains at least one instruction relating to a given paired system device, loader 53 checks whether this system device is still paired with the mixer.

[0246] If this check is positive, the loader 53 creates a communication path between the bioprocess machine 13, which is a mixer, and the machine helper 14, which is a pH sensor, flow sensor, or pump. The communication path allows the executor 54 to access reference values ​​in the paired machine helper 14 or to send action requests to the paired machine helper 14.

[0247] This is done thanks to the requestAddress and responseAddress properties of the mixer's related automation functions, which are updated when paired with the appropriate machine helper 14, for example, if the pH sensor tag=opc.tcp: / / ph / 4:control / 4, then the requestAddress property is set to request tag=opc.tcp: / / ph / 4:control / 4 and the responseAddress property is set to request tag=opc.tcp: / / ph / 4:control / 4.

[0248] Loader 53 translates each instruction in the recipe into machine-oriented instructions and loads those translations into executor 54. Commands that control / monitor the equipment of the fluid processor 15 of the bioprocess machine 13, such as "Agitator - Start," are converted as follows: If the recipe command includes an action, it is converted into a command that directly writes the value to the equipment of the fluid processor 15; if the recipe command includes a criterion, it is converted into a command that directly reads the value from the instrument of the fluid processor 15.

[0249] Instructions that control / monitor the equipment of the paired machine helper 14's processor helper 21, such as "pump.start" or "flow sensor.flow", are translated as follows: for recipe instructions containing an action, they are translated into an instruction that sends the translatedInstruction property value via the request channel of the communication path; for recipe instructions containing a criterion, they are translated into an instruction that sends the translatedInstruction property value via the request channel of the communication path and an instruction that reads the value via the response channel of the communication path.

[0250] The conversion is performed thanks to the translatorInstruction property of the mixer's associated automation function, which is updated when paired with the appropriate machine helper 14. Recipe instructions that include criteria such as "While (pH > 6) do" are translated as "Submit pH request on tag Y" and "While (tag X < 6) do," which use tag Y as the requestAddress property and tag X as the responseAddress property.

[0251] As described above, when a description of the pH sensor reference capability is published in the queue ("Recipe", "Reference") created by the mixer's DNP manager 19, the mixer's recipe manager 50 is automatically notified and receives the description of the pH sensor reference capability, which includes OPC UA tags in the requestAddress and responseAddress properties. Thanks to the OPC UA client in the mixer's MtoM communication tool 18, the network 12, and the OPC UA server in the pH sensor's MtoM communication tool 24, the recipe manager 50 can use the loader 53 to create a communication path between the mixer and the pH sensor.

[0252] The command "Submit pH request on tag Y" is executed by the executor 54 by requesting the MtoM communication 18 to use its OPC UA client to send a pH request to the OPC UA tag in the requestAddress property via the network 12 (i.e., opc.tcp: / / ph / 4:control / 4:request). The instruction "While (tag X < 6) do" is executed by the executor 54 by requesting MtoM communication 18 to use its OPC UA client to retrieve the pH value via network 12 with the OPC UA tag in the responseAddress property (i.e., opc.tcp: / / ph / 4:control / 4:answer). Now, if we look at recipe instructions that include actions such as "Pump->Start", such instructions are translated as "Set tag Y with value Z", where tag Y is the requestAddress property and value Z is the translatorInstruction property.

[0253] As described above, when the pump's response-on-request capability 2 description in the queue ("recipe", "criteria") created by the mixer's DNP manager 19 is published, the mixer's recipe manager 50 is automatically notified and receives the pump's response-on-request capability 2 description, which includes the OPC UA tag in the translatedInstruction property and the requestAddress property. The recipe manager 50 can use the loader 53 to create a communication path between the mixer and the pump, thanks to the OPC UA client in the mixer's MtoM communication tool 18 and the network 12 and OPC UA server in the pump's MtoM communication tool 24.

[0254] The command "Set tag Y with value Z" is executed by the executor 54 by requesting the MtoM communication 18 to send the value Z (i.e., "5~1~1") to the OPC UA tag of the requestAddress property (i.e., opc.tcp: / / Pump / 4:control / 4:request) via the network 12 from its OPC UA client. From the GUI of the recipe manager 50, the user can start executing a recipe. The executor 54 then automatically controls and monitors the appropriate machine helpers 14, such as a mixer, pH sensor, pump, or flow sensor, and executes the converted commands sequentially in the order specified by the recipe.

[0255] As described above, standard commands such as "Submit pH request on tag Y" are executed by the executor 54 by requesting the MtoM communication 18 to use its OPC UA client to send a pH request over the network 12 to the OPC UA tag in the requestAddress property (i.e., opc.tcp: / / ph / 4:control / 4:request).

[0256] When the OPC UA server in the pH sensor's MtoM communication tool 24 receives this request, the MtoM communication tool 24 notifies the pH sensor's recipe manager 51 accordingly. In response to this request, the pH sensor's recipe manager 51, which is provided with the pH value sensed by the pH sensor's processor helper 21 in real time thanks to the request-responsive function, makes the pH value available on network 12 with the OPC UA tag specified in the responseAddress property (i.e., opc.tcp: / / ph / 4:control / 4:answer) thanks to the OPC UA server of the pH sensor's MtoM communication tool 24.

[0257] Therefore, the executor 54 can execute the instruction "While (tag X < 6) do" by requesting the MtoM communication 18 to use its OPC UA client to look up the pH value in the OPC UA tag within the responseAddress property (i.e., opc.tcp: / / ph / 4:control / 4:answer) via the network 12. As described above, action commands such as "Set tag Y with value Z" are executed by the executor 54 by requesting the MtoM communication 18 to send the value Z (i.e., "5~1~1") from its OPC UA client to the OPC UA tag in the requestAddress property (i.e., opc.tcp: / / Pump / 4:control / 4:request) via the network 12.

[0258] When the OPC UA server in the pump's MtoM communication tool 24 receives this request, the MtoM communication tool 24 notifies the recipe manager 51 of the pump accordingly. In response to this request, thanks to the response-on-request function 2 capability, the pump's recipe manager 51 writes the value Z (i.e., "5~1~1") to the pump's processor helper 21, so that the pump motor starts. In a modified version, instead of simply writing the value Z to the processor helper 21, the recipe manager 51 sends a feedback message to the recipe manager 50 indicating that the pump has been instructed to start, thanks to the OPC UA server of the pump's MtoM communication tool 24 at the OPC UA tag specified in the responseAddress property (i.e., opc.tcp: / / Pump / 4:control / 4:answer), by making the feedback message available on the network 12.

[0259] Of course, the above mechanism for pH sensor reference commands can be applied to other machine helpers 14 that provide a reference, such as a pump that provides motor speed as a reference; and the above mechanism for pump operation commands can be applied to other machine helpers 14 that provide operations, such as a valve that provides closing or opening as an operation. The pairing is unpaired in the manner described above. In variations not shown, the system device 13 or 14 lacks the GUI manager 17 or 23, and the user interface operates differently.

[0260] Variations of a system device with a report manager Figure 14 shows a modified system device, similar to Figure 9, in which the digital controller 16 of the bioprocess machine 13 further includes a report manager 60, and the digital controller 22 of the machine helper 14 further includes a report manager 61. In the bioprocess machine 13, the report manager 60 enables the display of a GUI (shown in Figures 18 to 21) locally on an interactive screen or remotely on a device with an interactive screen, such as a tablet or smartphone. The machine helper 14, via the report manager 61, can remotely display a similar GUI (shown in Figures 18 to 21) on devices with interactive screens, such as tablets and smartphones.

[0261] Generally, the report manager 60 of the bioprocess machine 13 and the report manager 61 of the machine helper 14 are configured as follows in the paired state. - The report manager 60 of the bioprocess machine 13 has at least one provided capability which it does not have when not in a pairing state, and the provided capability is a reporting function which performs data logging and / or data report generation regarding the operating parameters of the processor helper 21 or regarding the physicochemical or biological quantities of the fluid sensed by the processor helper 21;

[0262] - The report manager 61 of the machine helper 14 does not have at least one consumed capability when it is not in a pairing state, where if the provided capability is a reporting capability that performs data logging and / or generates data reports on the operating parameters of the processor helper 21, the consumed capability is a reporting capability that performs data logging and / or generates data reports on the operating parameters, and if the provided capability is a reporting capability that performs data logging and / or generates data reports on the physicochemical or biological quantities of the fluid sensed by the processor helper 21, the consumed capability is a reporting capability that performs data logging and / or generates data reports on the physicochemical or biological quantities.

[0263] With regard to the reporting manager, reporting functions, and the reports generated, please note that terms such as “operational parameters” or “physicochemical or biological quantities” can also be interpreted to include multiple or combinations of such parameters, quantities, etc. Depending on the type of report generated, such parameters, quantities, etc. may also be obtained from any combination of bioprocess machines and / or machine helpers.

[0264] In practice, for the bioprocess machine 13, there is a reporting function that is added in the pairing state, but it is disabled if the bioprocess machine 13 is not paired with the appropriate machine helper 14, and is enabled if the bioprocess machine 13 is paired with the appropriate machine helper 14. For the machine helper 14, if the machine helper 14 is not in a pairing state with the appropriate bioprocess machine 13, the reporting function that is withdrawn in the pairing state is enabled, and it is disabled if the machine helper 14 is paired with the appropriate bioprocess machine 13.

[0265] Report Management Facilities for processing biotechnology fluids typically log data and generate reports (sometimes mandated to meet regulatory requirements), and this data includes the facility's operating parameters or the physicochemical or biological quantities of the fluid being processed. Figure 15 shows a specific module of the report manager 60 of the bioprocess machine 13, such as the mixer in the illustrated example, along with the data path between the biotechnology fluid processor 15 and the generated report, when the bioprocess machine is in a standalone state.

[0266] As shown in Figure 15, the report manager 60 has two modules, a data logger 62 and a report generator 63, respectively. The data logger 62 includes or accesses a remote database or historian 64 that can store data over time in a structured manner for easy retrieval. The report generator 63 includes different generators 65 and a quasi-real-time generator 66.

[0267] The report generator 63 can generate reports in the following different formats: trend curves 67 for a quasi-real-time data series, generated by the quasi-real-time generator 66, can be displayed on the GUI of the report manager 60; printable reports 68 or displayable reports 69 for historical data, generated by different generators 65, can be printed (report 68) or displayed (report 69) locally or remotely.

[0268] The data paths from the fluid processor 15 to reports 67, 68, and 69 are shown in Figure 15 by solid arrows: Data such as the operating parameters of the fluid processor 15, or the physicochemical or biological quantities of the fluid processed by the fluid processor 15, are communicated from the fluid processor 15 to the database or historian 64 and the quasi-real-time generator 66; the data from the database or historian 64 is transmitted to different generators 65; the quasi-real-time generator 66 generates a trend curve 67 from the data provided by the fluid processor 15; and the different generators 65 generate a printable report 68 or a displayable report 69 from the data provided by the database or historian 64.

[0269] The Report Manager GUI includes menus (not shown) that allow users to customize reports 67, 68, and 69. For example, if multiple process data sets exist, the user can select which process data is the trend curve 67; and for printable reports 68, the user can use various templates to select the process data and time period they want to use. Figure 16 is similar to Figure 15, but shows the machine helper 14, including the pump, flow sensor, and pH sensor, when the machine helper is in a standalone state.

[0270] Generally, the given description of the bioprocess machine is that it is the report manager 61 (and not the report manager 60), that the data originates from the processor helper 21 (and not from the fluid processor 15), and the data path from the fluid helper 21 to reports 67, 68, and 69 is shown in Figure 16 by dotted arrows. Figure 17 is similar to Figures 15 and 16, but shows the bioprocess machine 13 and machine helper 14 together in a paired state, their MtoM communication tools 18 and 24, and the network 12 on which the paired state is established.

[0271] Similar to Figure 16, the path taken by the data from the processor helper 21 of the machine helper 14 is shown by the dotted arrow. Instead of being transmitted to the database or historian 64 and the quasi-real-time generator 66 of the machine helper 14, data from the processor helper 21 of the machine helper 14 is transmitted to the database or historian 64 and the quasi-real-time generator 66 of the bioprocess machine 13 via the machine helper 14's MtoM communication tool 24, the network 12, and the bioprocess machine 13's MtoM communication tool 18.

[0272] Therefore, reports 67, 68, and 69 generated by the report manager 63 of the bioprocess machine 13 include data from the machine helper's processor helper 21 from the moment of pairing; reports 67, 68, and 69 generated by the report manager 63 of the machine helper 14 include data from the machine helper's processor helper 21 only up to the moment of pairing.

[0273] Data Domain In the above description of system devices 13 or 14 without report managers 60 or 61, as given with respect to 13 from Figure 3, all capabilities are interface functions of the GUI manager 17 of the bioprocess machine 13 and the GUI manager 23 of the machine helper 14, respectively, with the domain feature being "graphics" or "control"; or, the automation function of the recipe manager 50 of the bioprocess machine 13 and the response-on-request function of the recipe manager 51 of the machine helper 14, with the domain feature being "recipe".

[0274] All of the above regarding the capabilities of GUI managers 17 and 23, as well as recipe managers 50 and 51, are applied to report managers 60 and 61 with necessary modifications, and in particular, instead of interface functions, automation functions, or response-on-request functions, the capability is a reporting function for report manager 60 of bioprocess machine 13 or recipe manager 61 of bioprocess machine 14, and the domain feature is "data".

[0275] In the case of a capability having the domain function "data" and the objective feature "process value logging," if negotiation is successful, the process data flow is rerouted from the machine helper 14 to the bioprocess machine 13, and the data logger 62 and report generator 63 of the bioprocess machine 13, as well as the machine helper 14, adapt accordingly.

[0276] From a process perspective, the process data of the machine helper 14 is considered to be provided by the bioprocess machine 13. The capability description defines which data is involved and how the data is rerouted, for example, via MtoM communication tools 18 and 24, or using specific network resources. Only process data values ​​from the machine helper 14 recorded before pairing occurs can be used for reporting in the machine helper 14. The process data values ​​of the routed machine helper 14 from the moment pairing occurs can be used for reporting by the bioprocess machine 13.

[0277] It is preferable that process data values ​​are not recorded in the machine helper 14 following pairing. Process data values ​​recorded before pairing occurs remain in the machine helper 14 and can be used for reporting. From the moment pairing occurs, process data values ​​from the routed machine helper 14 are recorded in the bioprocess machine 13. As described above, unpairing restores the data routing within the machine helper 14. Both the data logger 62 and the report generator 63 adapt accordingly. The process data values ​​for machine helper 14 are logged locally. These process data values ​​can then be reused in reports related to machine helper 14.

[0278] The process data values ​​for machine helper 14, which are logged when machine helper 14 is paired, cannot be used in reports about machine helper 14. Only process data values ​​recorded when the machine helper 14 is paired with the bioprocess machine 13 are recorded in the bioprocess machine 13. The process data values ​​of the machine helper 14, recorded when the machine helper 14 was paired, remain available for reporting by the bioprocess machine 13.

[0279] In the example shown in the drawing, for the bioprocess machine 13, which is a mixer, the device shape file 20 further includes a description of one reporting function, which is the capability provided when activated; for the machine helpers 14, which are a pH sensor, a pump, and a flow sensor, respectively, the device shape file 26 includes a description of at least one reporting function, which is the capability consumed when activated.

[0280] Mixer reporting function Enabling the mixer's reporting function extends data logging and reporting capabilities by using process data values ​​provided by any paired system device. The mixer's capability reporting function has the following description in the mixer's device shape file 20: Domain: "Data", Purpose: "Process Value Logging", Role: "Consumer", Limitations / Conditions: None. The list of properties is: [Table 21]

[0281] This capability description means the following: As a capability consumer with data skills, the mixer can log process data values ​​from multiple paired system devices using the OPC UA standard and the capabilityUniqueID used in the case of propagation or layering, provided that the multiple paired system devices provide at least process data values, process data names, and units. There are no restrictions or conditions on negotiation or pairing. Note that when describing the mixer's capability report function, you can also describe properties other than those mentioned above, such as the range of process values ​​(minimum and maximum values).

[0282] It should be further noted that instead of providing capability to each process value, it is possible to provide capability to a set of process values. In fact, since machine helper 14 can potentially propose dozens of process values, it is more efficient to negotiate by providing a single capability that provides data at once for data logging and reporting.

[0283] pH sensor reporting function When enabled, the pH sensor's reporting function can be adapted to adjust data logging and reporting capabilities so that the provided process data values ​​are no longer used. The reporting function of the pH sensor is described in the pH sensor's device shape file 26 as follows: Domain: "Data", Purpose: "Process Value Logging", Role: "Provider", Restrictions / Conditions: Exclusive. The list of properties is: [Table 22]

[0284] This capability description means the following: As a capability provider, the pH sensor can provide a dataset of process data values ​​recorded on a system device that is exclusively paired with it using the OPC UA standard. The dataset includes the process value, its name and units, and optionally the rate of value provision. Each data point is assigned an OPC UA tag value so that consumers can read these values ​​with an OPC UA client. For propagation or layering, the capabilityUniqueID is used.

[0285] This capability is used when pairing the pH sensor with the mixer, allowing the data from the pH sensor to be rerouted to the mixer. Note that when describing the pH sensor's performance report function, you can also describe properties other than those mentioned above, such as the range of process values ​​(minimum and maximum values).

[0286] It should be further noted that instead of providing capability for each process value, it is possible to provide capability for a set of process values. In fact, since machine helper 14 can potentially propose dozens of process values, it is more efficient for negotiation to provide a single capability that provides the data for data recording and reporting all at once.

[0287] Flow sensor reporting function Generally, the reporting function of a flow sensor is similar to that of a pH sensor, but the only difference is the nature of the process value (flow, not pH).

[0288] Pump reporting function 1 Generally, the pump's reporting function 1 is similar to the reporting function of a pH sensor or flow sensor, but differs only in the nature of the process value (motor speed, rather than pH or flow rate).

[0289] Pump reporting function 2 Generally, the pump's reporting function 2 is similar to the mixer's reporting function, but differs in that the nature of the process values ​​is limited to flow values. The pump's capacity reporting function 2 has the following description in the pump's device shape file 26: Domain: "Data", Purpose: "Process Value Logging", Role: "Consumer", Limitations / Conditions: Optional. The list of properties is: [Table 23]

[0290] This description of the feature means the following: A pump, as a data-skilled capability consumer, can log flow process data values ​​from only one paired system device, provided it optionally provides at least the process value, process value name, unit using the OPC UA standard, and capabilityUniqueID used in the case of propagation or layering. There are no restrictions or conditions on negotiation or pairing. This capability is used when pairing the flow sensor with the pump, allowing data values ​​from the flow sensor to be rerouted to the pump.

[0291] Pump reporting function 3 The pump's reporting function 3, like the pump's interface function 3, is a capability transfer function. Capability Report Function 3 has the following description in the pump's device shape file 26: Domain: "Data", Purpose: "Processing value logging", Role: "Provider", Limitations / Conditions: NotAvailable, Exclusive, Optional. The list of properties is: [Table 24]

[0292] In these cases, the capabilityUniqueID property is a unique identifier for the pump's reporting function 3; a tag attribute "tag=undefined, source=refToCapabilityUniqueID" is provided and updated upon pairing with the flow sensor, along with the corresponding attribute in the description of the flow sensor's capability issued in the queues ("Data", "Process Value Log") within the pump. The limit / condition features are also updated to match the capacity of the flow sensor, and such updates indicate that capability reporting function 3 is available.

[0293] The description of the pump's reporting function 3 capability means the following: As a capability provider, the pump can record a dataset of flow process data to an optional single (exclusively) paired system device using the OPC UA standard. The dataset includes the process data values, their names and units, and optionally the rate of value provision, and this capability is negotiable only if enabled by the pump. This capability is used when pairing the pump with the mixer, allowing data values ​​from the flow sensor to be rerouted from the pump to the mixer.

[0294] DNP sequencing Between different pairings, the DNP sequence is performed by the report managers 60 and 61, as described above for the recipe managers 50 and 51 and the GUI managers 17 and 23; the domain features are of course included in the "data". Similar to GUI managers 17 and 23, report managers 60 and 61 subscribe to data queues that have domain features in "data".

[0295] Once negotiation / pairing between the mixer and the pH sensor is successful, the mixer's report manager 60 and the pH sensor's report manager 61 adapt to rerouting the pH value path as described above. Once negotiation / pairing with the pump is successful, the mixer's report manager 60 and the pump's report manager 61 adapt to rerouting the motor speed and flow value paths as described above.

[0296] Generated report Figure 18 shows the report generated when the mixer, pump, flow sensor, and pH sensor are all in a standalone (unpaired) state. The top of Figure 18 shows the graphical user interface of the mixer's report manager 60, which displays reports 69 generated by different generators 66, and the reports 69 include only a weight curve 70 generated from a time series of weight data recorded from data provided by a weight sensor in the fluid processor 15 of the bioprocess machine 13.

[0297] Immediately below the graphical user interface of the mixer's report manager 60, Figure 18 shows printable reports 68 generated by different generators 65 that contain only weight data. Below are a series of similar reports generated by the report manager 61 for the pump (regarding pump speed), the flow sensor (regarding flow data), and the pH sensor (regarding pH data).

[0298] Figure 19 is similar to Figure 18, but the mixer is paired with the pump, and the flow sensor is paired with it. The pump process data values ​​initially recorded in the pump are now recorded in the mixer and can be used for reporting in the mixer. This includes process data values ​​measured by the pump itself, in this case the pump speed, and process data values ​​transmitted by the pump. Only process data values ​​provided after the moment indicated by the dotted line 71 when pairing with the pump occurs are available and are shown by the pump speed curve 72 and the flow rate curve 73.

[0299] In the mixer, all process data values ​​from the mixer and pump become available for generating report 68 or 69. The complete history of values ​​is available in the mixer process data. Only process data values ​​recorded since pairing occurred are available in the pump. Using the report manager 61 on the pump, the operator can select process data from the pump or from a previously paired flow sensor. Only process data values ​​from periods when the pump was not paired with the mixer can be displayed and shown in the report.

[0300] Using the report manager 61 on the flow sensor, the operator can select flow process data. Only process data values ​​for periods when the flow sensor is not paired with the pump are displayed and included in the report. Using the report manager 61 on the pH sensor, the operator can select pH process data. Since the pH sensor is not paired with the pump, the entire history of values ​​is available as pH process data.

[0301] Figure 20 is similar to Figure 19, but the mixer is further paired with a pH sensor, and the pH sensor is... In the mixer report 69, process data values ​​provided from the point in time indicated by the dotted line 74, where pairing with the pH sensor occurred, are available and are shown by the pH curve 75. Report 69 from the pH sensor displays only the process data values ​​for the period when the pH sensor was not paired with the pump, and this data can be included in the report.

[0302] Figure 21 is similar to Figure 20, but the pairing between the mixer and the pump paired with the flow sensor has been disconnected. Therefore, from the moment the disconnection occurs, indicated by the dotted line 76, the report 69 generated by the mixer does not include the pump speed and the flow sensed by the flow sensor. Report 69 generated by the pump includes the pump speed and flow rate from the time the unpairing occurred.

[0303] Further variations A variation of the example disclosed above is: - Bioprocess machines are different from mixers. Examples include bioreactors, chromatographs, virus inactivation machines, and tangential flow filters.

[0304] - Unlike pumps, flow sensors, and pH sensors; for example, other active components such as valves and mass flow controllers; other sensors such as mechanical, electronic, optoelectronic, 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, etc., humidity sensors, light / illuminance sensors, position (valve, actuator, switch, ...) sensors, power (watt, ...) sensors, galvanometers, molar sensors Sensors such as pressure sensors, vacuum sensors, title sensors, viability sensors, resistivity sensors, proximity / distance sensors, volume sensors, UV sensors, IR sensors, frequency sensors, molar concentration sensors, duration / time sensors, radiation sensors, colorimeters, glucometers, opacity meters, osmometers, photometers, spectrometers, sound pressure sensors, sonometers, video sensors, photosensors, charge sensors, particle counters, viscosity sensors or lactate sensors; other types of instrumentation; and / or auxiliary devices such as cell retention devices or mixers (different from the mixers in the examples above) that are capability providers.

[0305] Unlike the mixer in the example above, which is required to be paired with a pump connected to inlet 1 in order to be operational, the bioprocess machine can be operated in a standalone state, meaning it does not need to be paired with a bioprocess machine helper to be operational. -System equipment is typically located in a separate area from the production and storage areas. For example, all system devices are initially in the storage area and are then brought into the production area to set up the installation.

[0306] - Interactive screens are replaced or complemented by other user interfaces such as passive displays and physical buttons, or passive screens and keyboards; - The network is different from a network that uses IP; - The communication standard between machines is different from OPC UA; and / or

[0307] - The system may consist of only one bioprocess machine and one bioprocess machine helper; or it may consist of multiple bioprocess machines and multiple bioprocess machine helpers, each having at least one specific machine helper that can be combined with different bioprocess machines. Many other modifications are possible, and in this regard, it should be noted that the present invention is not limited to the examples disclosed and illustrated.

Claims

1. A system having the following system devices for processing biotechnology fluids: - A bioprocess 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 the biotechnology fluid processor (15); and - A bioprocess machine helper (14) having a biotechnology fluid processor helper (21) configured to be physically connected to a biotechnology fluid processor (15), and a digital controller (22) for controlling the biotechnology fluid processor helper (21); Here: - Each of the digital controllers (16) of the bioprocess machine (13) and the digital controller (22) of the machine helper (14) includes a report manager (60, 61), inter-machine communication tools (18, 24) (MtoM communication tools), and detection negotiation pairing managers (19, 25) (DNP managers); Each MtoM communication tool (18, 24) is configured to connect to the 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 pairing state; where: the report manager (60) of the bioprocess machine (13) and the report manager (61) of the machine helper (14) are configured in the pairing state as follows: - The report manager (60) of the bioprocess machine (13) has at least one provided capability that it does not have when not in a paired state, the provided capability being a reporting function relating to one or more operating parameters of the processor helper (21) and / or one or more biophysical quantities of fluid sensed by the processor helper (21); and - The report manager (61) of the machine helper (14) does not have at least one consumed capability when not in a pairing state, where: if the provided capability is a reporting function relating to one or more operating parameters of the processor helper (21), the consumed capability is a reporting function relating to one or more operating parameters; and if the provided capability is a reporting function relating to one or more biophysical quantities of fluid sensed by the processor helper (21), the consumed capability is a reporting function relating to one or more biophysical quantities. Biophysical quantities include physicochemical or biological quantities. The reporting function includes data logging and / or data report generation. The aforementioned system.

2. The system according to claim 1, wherein each of the report manager (60) of the bioprocess machine (13) and the report manager (61) of the machine helper (14) includes a data logger (62) and a generator (65) that generates a report from the data provided by the data logger (62).

3. The system according to claim 2, wherein one or more operating parameters of the processor helper (21), or one or more biophysical quantities of fluid sensed by the processor helper (21), are logged by either the data logger (62) of the machine helper (14) when the machine helper (14) is not in a pairing state, or by the data logger (62) of the bioprocess machine (13) when the machine helper (14) is in a pairing state.

4. The system according to any one of claims 1 to 3, wherein the provided capability includes a reporting function relating to a set of operating parameters of the processor helper (21) and / or to biophysical quantities of fluid sensed by the processor helper (21).

5. The system according to any one of claims 1 to 4, wherein the digital controller (16) of the bioprocess machine (13) includes a file (20) containing a description of each reporting function that may be a provided capability, and the digital controller (22) of the machine helper (14) includes a file (26) containing a description of each reporting function that may be a consumed capability.

6. The system according to any one of claims 1 to 5, wherein the DNP manager (19) of the bioprocess machine (13) and the DNP manager (25) of the machine helper (14) are configured to cooperate via a network (12) to establish a pairing state.

7. The system according to any one of claims 1 to 6, wherein the system device comprises a plurality of machine helpers (14), and the DNP manager (19) of the bioprocess machine (13) is configured to establish a pairing state with at least one machine helper (or more) (14) simultaneously.

8. The system device comprises a first machine helper (14) and a second machine helper (14), the fluid processor helper (21) of the first machine helper (14) and the fluid processor helper (21) of the second machine helper (14) are configured to be physically connected to each other, and the DNP manager (25) of the first machine helper (14) and the DNP manager (25) of the second machine helper (14) are configured to cooperate via a network (12) to establish a pairing state; where: if the bioprocess machine (13) and the first machine helper (14) are not in a pairing state, the report manager (61) of the first machine helper (14) and the report manager (61) of the second machine helper (14) are configured in a pairing state as follows: - The report manager (61) of the first machine helper (14) has at least one provided capability that it does not have when not in a pairing state, the provided capability being a reporting function relating to the operating parameters of the processor helper (21) of the second machine helper (14), or relating to biophysical quantities of fluid sensed by the processor helper (21) of the second machine helper (14); - The report manager (61) of the second machine helper (14) has at least one consumed capability when not in a pairing state, where: if the provided capability is a reporting capability relating to the operating parameters of the processor helper (21) of the second machine helper (14), the consumed capability is a reporting capability relating to the operating parameters; if the provided capability is a reporting capability relating to the biophysical quantities of fluid sensed by the processor helper (21) of the second machine helper (14), the consumed capability is a reporting capability relating to the biophysical quantities. The system according to any one of claims 1 to 7.

9. The system according to claim 8, wherein the report manager (60) of the bioprocess machine (13) and the report manager (61) of the first machine helper (14) are in a pairing state between the bioprocess machine (13) and the first machine helper (14), the first machine helper (14) is in a pairing state with the second machine helper (14), and the report manager (60) of the bioprocess machine (13) has a provided capacity that replicates the capacity provided by the first machine helper (14) corresponding to the capacity consumed by the second machine helper (14).

10. The system according to any one of claims 1 to 9, wherein the system device comprises a first bioprocess machine (13), a second bioprocess machine (13), and a plurality of machine helpers (14); and the DNP manager (25) of at least one machine helper (14) is configured to establish a pairing state with the first bioprocess machine (13) or the second bioprocess machine (13).

11. A system according to any one of claims 8 to 9, comprising: a first machine helper (14) whose consumed capacity is a reporting function relating to the operating parameters of a processor helper (21) of a first machine helper (14); and a second machine helper (14) whose consumed capacity is a reporting function relating to biophysical quantities of fluid sensed by a processor helper (21) of a second machine helper (14), wherein: the first machine helper (14) is a pump, and the consumed capacity is a reporting function relating to the speed of the pump; and the second machine helper (14) is a pH sensor or a flow sensor, and the consumed capacity is a reporting function relating to the pH of the fluid or the flow of the fluid.

12. The system according to any one of claims 1 to 11, wherein each MtoM communication tool (18, 24) is configured to connect to a network (12) which is a network having an Internet protocol such as Ethernet®, Wi-Fi, Bluetooth®, or Cellular 5G.

13. - Each of the digital controllers (16) of the bioprocess machine (13) and the digital controller (22) of the machine helper (14) further includes a graphical user interface manager (17, 23) (GUI manager), -The GUI manager (17) of the bioprocess machine (13) and the GUI manager (23) of the machine helper (14) are configured as follows in the paired state: - The GUI manager (17) of the bioprocess machine (13) has at least one provided capability that it does not have when not in a pairing state, the provided capability being a user interface function relating to the operating parameters of the processor helper (21) and / or to the biophysical quantities of the fluid sensed by the processor helper (21); and - The GUI manager (23) of the machine helper (14) does not have at least one consumed capability when not in a pairing state, where: if the provided capability is a user interface function relating to the operating parameters of the processor helper (21), the consumed capability is a user interface function relating to the operating parameters; if the provided capability is a user interface function relating to the biophysical quantities of fluid sensed by the processor helper (21), the consumed capability is a user interface function relating to the biophysical quantities. The user interface functions include controlling and / or displaying operating parameters and / or displaying biophysical quantities of the fluid. The system according to any one of claims 1 to 12.

14. - Each of the digital controllers (16) of the bioprocess machine (13) and the digital controller (22) of the machine helper (14) further incorporates a recipe manager (50, 51), - The recipe manager (50) of the bioprocess machine (13) and the recipe manager (51) of the machine helper (14) are configured as follows in the paired state: - The recipe manager (50) of the bioprocess machine (13) has at least one provided capability that it does not have when not in a pairing state, the provided capability being an automated function relating to the operating parameters of the processor helper (21) and / or the biophysical quantities of the fluid sensed by the processor helper (21); and - The machine helper (14) recipe manager (51) has at least one consumed capability that it does not have when not in a pairing state, where: if the provided capability is an automated capability relating to the operating parameters of the processor helper (21), the consumed capability is a response-on-request capability relating to the operating parameters; if the provided capability is an automated capability relating to the biophysical quantities of the fluid sensed by the processor helper (21), the consumed capability is a response-on-request capability relating to the biophysical quantities. The Response-on-Request function includes controlling and / or testing operational parameters, and / or testing biophysical quantities of fluids. The system according to any one of claims 1 to 13.

Images