Control system for beverage dispenser

Abstract

A control system 20 receives status information 21 from a controller (18, Figure 2) gathering data about a beverage dispenser 10. The data concern various parameters of the dispenser, such as the stat

Description

Field of Invention The present invention relates to a control system and control method for a beverage 5 dispenser. In particular, the present invention relates to a control system for adjusting configuration parameters of a beverage dispenser in response to receipt of status information relating to a condition of the beverage dispenser. The present invention further relates to a beverage dispensing system comprising a beverage dispenser and a control system, and a beverage dispensing network comprising a plurality of beverage 10 dispensers in communication with a control system. Technical Background Beverage dispensers are becoming increasingly widespread across bars, restaurants and offices as a result of their ability to dispense beverages having a wide range of 15 flavours through a single tap, without the complex logistics associated with supplying containers of pre-mixed beverages. As use of beverage dispensers increases, the ability to introduce diverse ranges of flavours, and to adjust these in response to consumer demand, is particularly 20 advantageous. No physical change to the dispenser or its installation is required in order to enable new flavours to be dispensed, other than the provision of new additive containers or cartridges, or the programming of new beverage recipes and dispensing routines. As such, new beverages can be made available to large numbers of consumers very quickly, responsive to market research on consumer preferences, seasonal 25 behaviours, and the development of new beverages by drinks manufacturers. With the popularity which results from such advantages can come heavy usage of an individual dispenser. For example, a single dispenser might be shared among many workers in an office building, and be in near-continuous use during office hours, with 30 particularly intensive use at break times. Performance of the dispenser will inevitably be affected over time, in the absence of proper monitoring and maintenance, such as cleaning and flushing, by a service engineer. Additionally, regular stock-taking is needed to ensure additive levels can be maintained via orders placed with suppliers, to keep up with consumer needs. Embodiments of the present invention seek to address the above challenges, and provide many additional advantages, based on use of a control system which receives status information for a dispensing configuration of a beverage dispenser, and adjusts operating parameters of the dispenser accordingly. 5 Summary of Invention According to an aspect of the present invention, there is provided a control system for a beverage dispenser, comprising one or more controllers arranged to receive status information for a dispensing configuration of the beverage dispenser, process the io received status information to determine a condition of the beverage dispenser and an adjustment to the dispensing configuration required to change the condition from a first condition, associated with the received status information, to a predetermined second condition, and output control instructions to cause the determined adjustment to the dispensing configuration of the beverage dispenser, wherein the dispensing 15 configuration defines a set of operating parameters to be used by the beverage dispenser to dispense a beverage. In this way, dynamic reconfiguration of a beverage dispenser is made possible. The control system is able to control any of a number of parameters at the dispenser such 20 what is dispensed corresponds closely to what is requested by a consumer. The maintenance of quality of the dispensed beverage can be achieved by adapting the operation of the dispenser to compensate for factors that might affect performance of the dispenser, assessed via direct measurement using sensors at the dispenser, and inferred from consumption history. Beverage flavours can be readily configured and 25 adapted based on consumption data. The lifetime of a dispenser is thus significantly prolonged, based on optimisation of its performance, and the ability to keep up to date with consumption habits. In particular, the control system enables lengthening of the lifetime of dispenser which was previously not controlled by the control system, by retrofitting the control system to such a dispenser. 30 Further advantages are set out in the detailed description. In embodiments, the status information comprises a dispensing history of the beverage dispenser, wherein the dispensing history tracks a dispensing frequency and the 35 dispensed volume of one or more beverages over a predetermined period of time. In this way, it is possible to determine consumer habits in order to assess whether particular beverages are popular, or whether there are behavioural patterns indicating particular times at which a beverage is more likely to be consumed. Additive supply levels 5 may also be tracked in this manner. In embodiments, the status information comprises parameters relating to at least one of: one or more additives available to the beverage dispenser, one or more pumps for dispensing the one or more additives, a water supply pressure level, a carbon dioxide 10 supply level, a waste fluid system, and environmental conditions. As such, the status information which is collected can represent a combination of information relating to consumption of a particular beverage, the physical condition of the dispenser itself, and conditions associated with the environment in which the dispenser 15 is installed. With such a rich combination of information, it is possible to make a detailed assessment of the circumstances of a dispenser, and to determine an appropriate course of action to address any situation which is not desired. In embodiments, the one or more controllers are arranged to access a plurality of recipes, 20 each recipe defining a set of one or more additives for a beverage, and to select a subset of the plurality of recipes in dependence on the received status information, wherein the control instructions cause the beverage dispenser to be configured to dispense beverages defined by the selected subset of the plurality of recipes. 25 In this manner, it is possible to optimise the choice of beverages, from those defined by a maximum or global set of available recipes, which is made available for selection at a particular dispenser, based on any of the factors associated with the status information. If an issue is identified that might affect the availability or quality of a particular beverage, for example, this may be removed from the subset, while resolution of that issue can 30 cause resumption of inclusion of that beverage in the subset. In embodiments, the status information identifies a subscriber entity associated with the beverage dispenser, and the one or more controllers are arranged to select the subset of the plurality of recipes in dependence upon a predetermined set of beverages 35 associated with the subscriber entity. In this way it is possible to make different beverages available for selection to different groups of consumers. 5 In embodiments, the control system comprises a recipe storage module storing the plurality of recipes, and a beverage catalogue module for storing the selected subset of the plurality of recipes. In embodiments, the status information comprises identification information for one or io more additive containers for storing additives for the beverage dispenser to dispense, wherein the one or more controllers are arranged to authenticate the one or more additive containers using the received identification information, and to reject status information relating to an additive container which is not authenticated, and to process status information only for an additive container which is authenticated to determine the control 15 instructions to output. In this way, it is possible to ensure that an additive container is compatible with the control system of the beverage dispenser, based on its identification information matching predetermined characteristics, so that an erroneous control instruction, that may be 20 generated based on data from a third party additive container, is not generated. In embodiments, the one or more controllers are arranged to instruct an additive supply module to supply one or more additives to the beverage dispenser if the first condition indicates a level of stored additive is below a predetermined threshold, or if the first 25 condition indicates that emptying of the additive container within a predetermined time period is forecast. In this way, maintenance of additive levels is ensured automatically, and in advance of a particular additive emptying. Therefore, continuous availability of a beverage, which 30 relies on a particular additive, is ensured. In embodiments, the operating parameters comprise at least one of: timing sequences for activation of one or more pumps for dispensing one or more respective additives, dispensed volumes of one or more additives, volume and pressure of water and carbon 35 dioxide and temperature of water, and a flush system. It is therefore possible to perform precise control of a configuration of a beverage dispenser in order to optimise dispenser performance, and maintain particular flavour standards. 5 In embodiments, the one or more controllers are arranged to generate one or more images for display by a user interface of the beverage dispenser, wherein content of the one or more images is determined by the one or more controllers in dependence on the status information. 10 The content may encourage a consumer to try a new beverage, or provide information about available beverages, supply levels, and operating parameters. In embodiments, the one or more controllers are arranged to execute a machine-learning 15 algorithm to learn the adjustment to the dispensing configuration that is required to change the condition of the beverage dispenser from the first condition to the second condition, wherein the control system comprises a storage means for storing status information received before output of the control instructions and received after output of the control instructions, and the one or more controllers use the stored status information 20 and historical adjustments to the dispensing configuration as training data for the machine-learning algorithm. Particularly where a beverage dispenser is positioned in an environment in which it is used by a large number of consumers, there is a corresponding large amount of data 25 available relating to received status information and control instructions which are output as a result. As such, a machine-learning algorithm is able to develop the relationship between status information and optimal control instructions such that control of a dispenser is optimised. 30 According to a second aspect of the present invention, there is provided a beverage dispensing system comprising a beverage dispenser, comprising one or more coupling modules for coupling additive containers to the beverage dispenser, an additive manifold in communication with the coupling modules for receiving additives from the respective additive containers, and in fluid communication with a water source for flushing the 35 additives from the manifold, a dispense head in fluid communication with the manifold for dispensing the additives, a storage means for storing a dispensing configuration and a dispensing history, and a dispensing controller arranged to control the dispense head to dispense one or more additives for a beverage in dependence on the stored dispensing configuration, and the control system of the first aspect of the present 5 invention as described above, wherein the storage means is arranged to receive the dispensing configuration from the control system. In embodiments, the beverage dispensing system comprises one or more controllers of the control system. In this way, it is possible to integrate, at least partially, the control io system and the beverage dispenser. This enables local control of the beverage dispenser based on the status information, which is particularly advantageous where the beverage dispenser is to be arranged in an environment in which a reliable communication link with a network is unavailable, and where remote control may, at least temporarily, not be possible. 15 According to a third aspect of the present invention, there is provided a beverage dispensing network, comprising a plurality of beverage dispensers, each of the plurality of beverage dispensers comprising one or more coupling modules for coupling additive containers to the beverage dispenser, an additive manifold in communication with the 20 coupling modules for receiving additives from the coupling modules, and in fluid communication with a water source for flushing the additives from the manifold, and a dispense head in fluid communication with the manifold for dispensing the additives, a storage means for storing a dispensing configuration and a dispensing history, and a dispensing controller arranged to control the dispense head to dispense one or more 25 additives for a beverage in dependence on the stored dispensing configuration, and the control system of the first aspect of the present invention as described above, wherein the storage means is arranged to receive the dispensing configuration from the control system, and wherein each of the plurality of beverage dispensers comprises a communication module for communicating status information to the control system. 30 In this embodiment, centralised processing of a group of dispensers is particularly efficient, as a single control system or ‘hub’ may be able to administer control instructions to, for example, all of the dispensers in a particular establishment such as an office. In embodiments, the one or more controllers are arranged to cause the dispensing configuration of a first beverage dispenser to be adapted in dependence upon status information communicated to the one or more controllers by a second beverage dispenser. As a single the controller is in communication with multiple dispensers, it is 5 possible to collect a large amount of data relating to the network of dispensers as a whole, and using information for a group of dispensers, it is possible to perform individual adaptations in order to balance dispensing loads or achieve consumption optimisations within the group. 10 In embodiments, the beverage dispensing network comprises a validation module for validating a batch of status information and uploading batches of validated status information to the control system, wherein the communication module of each of the plurality of beverage dispensers is arranged to upload status information to the control system via the data validation system. 15 In this way, reliability of the received status information is ensured, which is particularly advantageous when status information is received over a communications link in which errors in transmission can occur as a result of, for example, network channel errors or interference. Further, certain dispenser optimisations can be synchronised with supply 20 of batch data, for example, overnight, so as not to interfere with dispensing operations. According to a fourth aspect of the present invention, there is provided a method of controlling a beverage dispenser, comprising receiving status information for a dispensing configuration of the beverage dispenser, processing the received status 25 information to determine a condition of the beverage dispenser and an adjustment to the dispensing configuration required to change the condition from a first condition, associated with the received status information, to a predetermined second condition, and outputting control instructions to cause the determined adjustment to the dispensing configuration of the beverage dispenser, wherein the dispensing configuration defines a 30 set of operating parameters to be used by the beverage dispenser to dispense a beverage. According to a fifth aspect of the present invention, there is provided a computer program comprising computer-executable instructions which, when executed by one or more processors, are arranged to cause the method of the fourth aspect of the present invention, as described above, to be performed. According a sixth aspect to the present invention, there is provided a platform upon which 5 a novel beverage formulation can be rapidly developed and commercialised in situ. A subject matter expert user can use first, second, third, and fourth aspects of the present invention to develop a unique beverage formulation via simulation of the control system controlling the beverage dispenser in such a way in which to replicate a conventional chemical recipe, in which the chemical composition will be translated into a computer 10 executable configuration, ready to be commercialised. Brief Description of Drawings Embodiments of the present invention will be described by way of example only, with reference to the accompanying drawings, of which: 15 Figure 1 is a schematic illustration of the arrangement of a beverage dispensing system comprising a control system of embodiments of the present invention; Figure 2 shows a schematic illustration of a beverage dispenser which may be controlled the control system of embodiments of the present invention. Figure 3 is a schematic illustration of a control system according to a first embodiment 20 of the present invention; Figure 4 illustrates a beverage dispensing network according to a second embodiment of the present invention; and Figure 5 illustrates a method of controlling a beverage dispenser, according to a third embodiment of the present invention. 25 Detailed Description Figure 1 is a schematic illustration of the arrangement of a beverage dispensing system, comprising a control system 20 according to embodiments of the present invention. The control system 20 is arranged to receive status information 21 from a beverage 30 dispenser, and to issue control instructions 22 in response to processing of the status information 21. The control system 20 accesses beverage recipes from a database or ‘master catalogue’ 23, which stores information specifying the ingredients which are to be mixed, and their constituent proportions, in order to produce a particular beverage. Of the beverages represented in the master catalogue 23, a further database or ‘beverage catalogue’ 24 stores a subset of recipes, which specifies ingredients for a set of beverages which are available to be dispensed by the dispenser 10. The selection of beverages defined in the dispenser catalogue 24 is dynamically 5 configured, as will be described below, taking into account both selections from a system administrator via an input to the control system 20 (not shown), and based on automatic operations performed by the control system 20 in response to status information 21. The beverage dispenser 10 may have at its disposal a plurality of different additives, and the control system 20 specifies which beverages are available for selection by a user based io on the additive mixing proportions defined in the dispenser catalogue 24 and the available additive levels. Figure 2 shows a schematic illustration of a beverage dispenser 10 which may be controlled by the control system 20 of embodiments of the present invention. The 15 beverage dispenser comprises a plurality of additive coupling modules 11A to 11F for coupling additive containers to the dispenser. In the illustrated embodiment, the beverage dispenser comprises six additive coupling modules 11A to 11F, holding six additive containers, indicated by the letters A to F respectively, although this is simply by way of example. Each of the additive coupling modules 11A to 11F has an additive pump 20 12A to 12F respectively, for pumping additives A to F from the coupling modules 11A to 11F to manifold 13. The manifold 13 is in fluid communication with each of the coupling modules 11A to 11F for receiving additives A to F, and is in fluid communication with a water source 14 for flushing the additives A to F from the manifold 13. 25 The beverage dispenser 10 further comprises a dispense head 15 in fluid communication with the manifold 13 and receives water from the water source 14 for dispensing the additives A to F and water into a vessel. The water from water source 14 may be chilled and / or carbonated by a chiller 16 and a carbonator 17 respectively, upstream of dispense head 15. In some embodiments, a heater (not shown) is also included in order to produce 30 hot beverages, and the heater may be controlled in an analogous manner to the control of the chiller 16 described below. The beverage dispenser 10 further comprises a controller 18 which is configured to control operation of the dispenser 10, and a user interface 19 for conveying information 35 to and receiving instructions from a user to be conveyed to and actioned by the controller 18. The controller 18 controls each of the pumps 12A-F, the dispense head 15 and the III 19, as shown by the dotted control lines in Figure 2, and also controls the chiller 16 and the carbonator 17 (dotted lines not shown). The water source 14 may be external to the beverage dispenser 10, with supply of water being controlled by a valve or tap system 5 (not shown) between the water source 14 and the manifold 13, chiller 16, carbonator 17 and dispense head 15. Such a valve or tap system is controlled by the controller 18. The controller 18 outputs status information 21, to be provided to a control system 20 according to embodiments of the present invention, and receives control instructions 22 io from the control system 20. In alternative embodiments, the beverage dispenser 10 comprises a dedicated communications module for transmitting and receiving data for this purpose over a communications network, to be described in more detail below. In use, information regarding the different additive containers which are coupled to the 15 beverage dispenser 10 is communicated to the controller 18 through electronic communication via, for example, RFID or NFC tags and readers. The controller 18 may then use this information to convey to a user which different additives and additive combinations are available. The different beverage options are presented to the user through the user interface 19, such as a touchscreen, and the user makes a selection 20 through the user interface 19 which is conveyed to and actioned by the controller 18. The controller 18 activates the appropriate pump(s) 12A to 12F according to the selection made by the user, to pump an appropriate volume of one or more of additives A to F to the manifold 13. For example, if a user selected beverage “ABC” (a hypothetical beverage comprising equal volumes of additives A, B and C), then the controller 18 would 25 activate pumps 12A, 12B and 12C to deliver equal volumes of additives A, B and C to the manifold 13. The additives may be delivered to the manifold 13 simultaneously or sequentially, the configuration of which is based on the rheological properties of the liquid and is predetermined by the dispense configuration control 31. The controller 18 then activates an appropriate pump and inlet valve (e.g. a rocker valve, not shown) to flush 30 water from water source 14 through the manifold 13 to convey the one or more additives within the manifold 13 to the dispense head 15. The beverage dispenser 10 may be configured so that in use multiple flushes of water through the manifold 13 occur for each beverage serve. Thus, an initial flush may carry the majority of the additives from the manifold 13 towards the dispense head 15, another flush may remove any residual 35 additives remaining in the manifold 13, and a further flush may assist with cleaning the manifold 13 and tubing between the manifold 13 and the dispense head 15 to reduce cross-contamination for future beverage serves. Alternatively, water may continuously flow through the manifold 13 and the additives drop into the flow within the manifold 13. 5 It may be desirable for the additives to be dispensed sequentially, as opposed to being mixed together in the manifold 13. Thus, for example, the controller 18 may be configured such that for certain beverage selections a first additive may enter the manifold 13 and be flushed to the dispense head 15, then a second additive may enter the manifold 13 and be flushed to the dispense head 15, and so on. The controller 18 further activates io the system to pump water from water source 14 to the dispense head 15 via chiller 16 and / or carbonator 17, according to the selection made by the user. The additive / water mixture and water are dispensed as a beverage into a vessel provided by the user. Figure 3 shows a schematic illustration showing detail of a control system 20, according 15 to a first embodiment of the present invention. The operation of the control system is managed by a processor 25. The processor may be a microcontroller mounted to a printed circuit board on which additional components of Figure 3 are also mounted and interconnected. In alternative embodiments, the processor 25 represents one or more controllers of a computer server or terminal, or network entity. 20 As shown in Figure 1, the control system 20 receives status information 21 from a beverage dispenser 10, and outputs one or more control instructions 22 to the beverage dispenser 10. As shown in Figure 3, the status information 21 may take many forms, depending on the information which is to be presented to the control system 20, and the 25 control system 20 comprises a plurality of distinct interfaces 26-29 for receiving the status information 21 and assessing its content. Among these interfaces are a beverage dispenser health interface 26, an additive supply level interface 27 and an environmental monitor interface 28, and a consumption history 30 interface 29. Status information 21 is received by received by each of these interfaces 26-29 in parallel, and processed further by one of the interfaces only if it contains information data appropriate to that interface, as determined based on identification of a predetermined format of status information. In alternative embodiments, a parser (not shown) is included in the control system 20 in a front-end component which is used to 35 route status information 21 at the point of receipt to the correct interface. The beverage dispenser health interface 26 receives status information 21 relating to one or more parameters of the beverage dispenser 10 which characterise the status of the hardware of the beverage dispenser 10, and enables an assessment of the ‘health’ 5 or physical state of the beverage dispenser 10 to be made. In this regard, the performance of a dispenser can be characterised by one or more of the following: the number of activations of each of the pumps 12A-F, the duration of activation of each pump 12A-F, output flow rates at the dispense head 15, temperature of the chiller 16, pressure of a carbon dioxide supply for the carbonator 17, temperature of dispensed io fluid, capacity of a waste collection system, and data indicating a fault in one or more components of the dispenser 10. The additive supply level interface 27 receives status information 21 indicating supply levels of each of the additives A-F present at the beverage dispenser 10. The additive 15 supply interface 27 receives identification information associated with additive containers associated with respective additives A-F as part of an authentication process, so that only status information 21 from approved additive containers is processed further by the processor 25 of the control system 20. In embodiments, an additive container which is not authenticated by the processor 18 of the dispenser 10 may already have been 20 determined to be unavailable for use by the dispenser 10, but the re-authentication at the control system 20 provides an additional level of security, and enables a distinction to be drawn between data indicating ‘non-use’ and data indicating ‘invalid additive container’. In the event of the presence of an unrecognised, or unauthorised additive container, or the absence of authentic identification information, the processor 25 is 25 configured to issue a warning message to the dispenser 10 to alert a user. In embodiments, the dispenser 10 may be instructed not to use the unauthorised additive container and further status information is processed 21 on the basis that the unauthorised additive is absent. 30 The environmental monitor interface 28 receives status information 21 relating to external factors associated with beverage dispenser 10, and particularly status information 21 which is indicative of environmental conditions of the beverage dispenser 10. Such information includes one or more of a water supply temperature and pressure, the ambient temperature of the dispenser 10, the strength of a network connection 35 between the dispenser 10 and a communications network over which status information 21 might be communicated, and parameters associated with an electrical voltage and current supply to the dispenser 10. The consumption history interface 29 receives status information defining the usage of 5 the dispenser 10 over a predetermined time period. Usage information is broken down into the dispensing frequency and volume of dispensing of a particular beverage, similar data relating to individual additives, rather than a beverage, and behavioural information indicating particular periods in which higher rates of consumption of the beverage can be expected, and profiles of consumption rates of new beverages after their launch. In io general, the information received by the consumption history interface enables a picture to be constructed of which beverages have been consumed at what times or dates, which have high rates of consumption, or particular periods of high consumption, and which beverages, available for selection at the dispenser 10, have not been consumed at all, or at only low rates. 15 Each of the interfaces 26-29 performs pre-processing on the received data so that it can be provided to the processor 25 in a form in which a decision can be made by the processor as to what, if any, corrective action is required in order to drive the dispenser 10 from a first configuration to a first condition to a predetermined second condition. For 20 example, the dispenser health interface 26 may receive a series of parameters for each of the dispenser pumps 12A-F, and may compare each parameter with a corresponding threshold or operating range in order to determine whether that parameter is within a normal range or is too high or too low. If a fault is identified by the dispenser health interface 26, the nature and severity of the fault, and the identity of the faulty pump, are 25 provided to the processor 25, and the processor 25 determines whether any corrective action exists which can address that fault, such are reducing the load on the pump, or deactivating the pump altogether, to avoid dispensing the beverage at lower than the required quality. 30 The second condition is a desired condition which is known to be able to produce a beverage at a particular level of quality such that the consumer’s experience is positive. The second condition is defined by a combination of a plurality of operating parameters which are stored as a configuration set in a configuration library 30. The role of the processor 25 is to determine which, of the available parameters to be controlled, can be 35 adjusted so that the configuration of the dispenser 10 matches an approved configuration set stored in the configuration library 30. In this regard, the processor 25 executes one or more algorithms which take definitions of system parameters as inputs, identify a system goal based on information stored at the configuration library 30, and perform computation in order to determine which of the input system parameters is to be modified 5 in order to drive the dispenser 10 towards a configuration associated with the system goal. In embodiments, the processor 25 is arranged to execute a machine-learning algorithm to learn the system parameters that should be modified, and the associated control io instructions 22, in order to drive the dispenser’s configuration towards the system goal. The machine-learning algorithm may employ an artificial neural network, having weights and biases are trained on historical status information, historical adjustments to the dispensing configuration, and the rate of convergence of the dispensing configuration to the system goal, for a given dispenser type and configuration, such that optimal control 15 instructions 22 are generated which maximise the rate of convergence to the system goal. In this regard, the identification of the system goal itself is also a process which can be optimised. The processor 25 is programmed to be able to simulate the operation of a 20 beverage dispenser operating according to a particular dispensing configuration, based on adjustment to one or more parameters, in order to determine whether the system goal is in fact the best goal to be adopted. For example, an adjustment to the dispenser may cause a short-term improvement, but may be less optimal to the longer-term health of the dispenser. In another example, a system goal may be identified which renders a 25 beverage unavailable for selection due to low additive supply levels, or water temperature problems, to ensure that the beverage is not supplied below its optimum quality, but the beverage may be so popular that even short-term unavailability is undesirable. As such, a system goal in which a beverage is dispensed below the desired specifications, but within an acceptable tolerance, may be preferable over a short-term 30 basis until, for example, an additive can be replaced. A goal-selection optimisation algorithm is therefore executed by the processor in order to simulate the effect of driving the dispenser towards one configuration in preference to another configuration, and this may be executed by a separate machine-learning algorithm from the algorithm which determines the optimum control instructions for a particular goal. With the processor 25 having determined an appropriate course of action, the control of the parameters of the dispenser 10 is executed by one or more control instructions 22, output by a dispenser configuration control module 31. These may be received by the controller 18 of the dispenser 10, or by a command interface at the dispenser 10. The 5 control instructions cause an adaptation in the manner in which any of the components of the dispenser 10 are driven by the controller 18. Information indicating a change to the system configuration may be displayed on the user interface 19, for example a warning that a particular beverage is unavailable, that a io new beverage is available instead or in addition to an existing beverage, information relating to the availability of carbonated or heated drinks, and so on. Images or video sequences to be displayed on the user interface 19 may be generated by the processor 25 of the control system 20 and provided to the dispenser 10. This is particularly advantageous where large networks of beverage dispensers are employed, an example 15 of which is described below in relation to Figure 4. The process of generating content for display can be performed centrally for multiple dispensers, rather than requiring the process to be repeated in parallel by each individual dispenser 10, which facilitates dynamic adjustments to the content. 20 For example, the control instructions 22 may cause a particular sequence of activations of one or more pumps to be used, in response to status information 21 indicating that a particular one of the pumps 12A-F is reaching the end of its lifetime. An alternative pump may be driven instead, and a user may be prompted, via the user interface 19, to switch an additive container from one coupling module to another, such that a particular pump 25 can serve that additive. Alternatively, it may be desirable to control whether a particular one of the pumps 12A-F operates with a large number of short pumping actions, or a small number of longer pump actions, in which a larger volume of additive is dispensed per action. The sequencing of a combination of pumps may also be adjusted to accommodate differences in performance of the individual pumps of the combination. 30 In a further example, the control instructions 22 may cause the water source 14 to perform a flush of the manifold 13 and other pipes at the dispenser in response to status information 21 from a flow sensor at the dispense head 15 indicating the presence of blockages in the fluid output. In the event that an additive supply level is low, or is predicted to become low within a predetermined time, based on consumption rates and a current supply level, an additive control module 32 may issue an order 33 to a supplier to have that particular additive replenished. In this manner, it is not necessary to have a service engineer, or even the 5 consumer, perform a manual inspection of an additive’s supply level. Predicting that an additive container will empty in the short-term future enables pre-emptive action to be taken that prevents any loss of dispensing service for that particular additive or a particular beverage, so that further use of that additive can be permitted in the knowledge that a replacement will be available. io As an alternative to requesting re-supply of an additive, in the event that a supplier is out of stock, or if new stock can only be expected after the predicted expiry of the current additive container, the additive control module 32 controls the dispenser catalogue 24 in embodiments of the present invention so that the subset of beverages from the master 15 catalogue 23 is adapted. The adaptation may cause one or beverages associated with an out-of-stock or low-stock additive to be removed from the dispenser catalogue 24 so that it is not possible for a user to select such beverages at the dispenser 10. A situation in which an attempt to produce a beverage is made, but in which the beverage does not meet the specifications of a drinks manufacturer, due to the lack of availability of one or 20 more additives, is avoided. The dispenser catalogue 24 is, in embodiments of the present invention, outside of the control system 20, and can be hosted on a remote web server, or cloud-based platform, accessed by the control system over a network connection. In alternative embodiments, 25 the dispenser catalogue 24 is inside the control system 20. In either case, the dispenser catalogue 24 is accessible by the dispenser 10 using, for example, a communications module, so that the controller 18 is able to configure the user interface 19 accordingly, and make particular beverages available for selection. Local storage of the recipes to be used is performed using a library (not shown) in the dispenser 10. 30 Updates to the dispenser catalogue 24 can be pushed by the additive control module 32 to the dispenser 10, or alternatively, the dispenser 10 can poll the dispenser catalogue periodically to determine whether any updates have taken place. If the dispenser catalogue 24 is updated, the availability of a new beverage may be highlighted to users 35 via an appropriate alert or advertisement on a user interface screen. The master catalogue 23 is also, in embodiments of the present invention, outside of the control system 20 and hosted on a remote web server or cloud-based platform, but in alternative embodiments, the master catalogue 23 is inside the control system 20. In 5 cases in which the master catalogue 23 is outside of the control system 20, the master catalogue 23 can be hosted, maintained and updated by third parties, such as drinks manufacturers or suppliers. In cases in which both the master catalogue 23 and dispenser catalogue 24 are inside io the control system 20, they are fully integrated with the control system 20 which reduces the communications overheads associated with extracting recipe data from the master and dispenser catalogues 23, 24 over a network. The control system 20 of embodiments of the present invention thus enable dynamic 15 configuration of the beverages to be dispensed by a user. Examples of such dynamic reconfiguration include, but are not limited to, the following manners: • The reconfiguration may take into account information indicating a dispenser may have difficulty or reduced performance when dispensing a particular beverage, as indicated by status information 21 received by the dispenser health interface 20 26. • The reconfiguration may become necessary due to additive availability difficulties, as derived from status information 21 received by the additive supply level interface 27. • The reconfiguration may become necessary due to the ambient temperature of 25 the dispenser becoming too hot, based on status information 21 received by the environmental monitor interface 28, such that the chiller 16 cannot cool a beverage to a required temperature. • The reconfiguration may become necessary as status information 21 received by the consumption history interface 29 indicates that a particular beverage is not 30 being consumed and equipping the dispenser 10 with an additive associated with an unpopular beverage is preventing installation of a different additive that may be more popular in relation to a newly launched beverage. Reconfiguration can enable small adjustments to intensity to be made throughout the day in line with natural organoleptic shifts throughout the day. Despite each of the automatic reconfigurations made possible by the control system 20, of which the above reconfigurations are simply examples, manual configuration of the beverage dispenser 10 remains possible where there is a need to override an action output by the dispenser configuration control module 31 or additive control module 32. A 5 system configuration associated with such manual reconfiguration is provided from the dispenser 10 as new status information 21, and the processor 25 may be trained to learn from the manual intervention how best to propose future instructions to drive the system towards a particular goal. io In embodiments, it is possible for a user to manually input new configurations to the configuration library 30, that are learned empirically or are requested by a particular drinks manufacturer. In embodiments, there is provided a testing platform upon which a novel beverage 15 formulation can be rapidly developed in situ. The testing platform is a computer-implemented system configured to model the chemical combinations of additives, under different mixing and dispensing conditions to simulate the chemical composition of a beverage produced under different testing scenarios. 20 In this way, new flavours and beverages can be developed by a subject-matter expert user, with the knowledge of how the beverages will taste when dispensed by a particular dispenser, whose behaviour is modelled by the testing platform. The subject matter expert user can use the testing platform to simulate control instructions for the beverage dispenser to replicate production of a beverage having a unique chemical composition, 25 in which the chemical composition can be translated into a computer-executable configuration, ready to be commercialised. Formulations developed in this manner can be transferred from the testing platform to the configuration library 30 in the form of computer-executable instructions defining recipes and associated dispensing control instructions. 30 In embodiments, the control system 20 is integrated within the dispenser 10 itself. This enables local dynamic configurations to be performed without reliance on a communication link between the dispenser 10 and the control system 20. This is particularly advantageous in situations in which the dispenser 10 is to be configured in a 35 remote environment, in which reliable network connections may not be available. For example the dispenser 10 may be intended for use at an outdoor venue such as a park or a festival, and installation of a dispenser with an on-board control system 20 enables dynamic configurations to be performed to maintain dispensing quality while the dispenser 10 is in-situ. 5 In such embodiments, the dispenser 10 may comprise a storage means for storing data associated with consumption history, device and environmental parameter history, additive level history and dynamic configurations. Such data may be uploaded to a remote control system in a batch for validation and further analysis, at a later time when io the dispenser 10 is in a more stable connection environment. The storage means may be a memory which is already present on board the dispenser 10 for storing local control instructions, parametric data, user selections and so on, although in embodiments, temporary data such as a user selection may instead be stored in a volatile memory such as a buffer, with control configurations stored in a non-volatile memory instead. 15 In embodiments, such a storage means further contains the dispenser catalogue 24, which may be copied or mirrored from a dispenser catalogue accessible to a remote control system. The master catalogue 23 may also be mirrored at the local control system 20. 20 In embodiments in which the control system 20 is local to the dispenser 10, the processor 25 is integrated with the on-board controller 18 of the dispenser 10, or alternatively is arranged as part of a multi-processor control system in which control functions are distributed across such processors. Embodiments in which the processor 25 is separate 25 from the on-board controller 18 are particularly advantageous as it is possible to retrofit the control system 20 to any dispenser 10, by providing control instructions 22 as an input to the controller 18 via a physical connection. Embodiments in which the processor 25 and the on-board controller 18 are integrated can achieve the same advantage by installing a computer program containing executable instructions for programming the 30 on-board controller to have the functions of the processor 25. The interfaces 26-29 may be implemented by programming existing component interfaces (not shown) in the dispenser 10 which are associated with the connections of the controller 19 to the components of the dispenser 10. The installation of the computer program may be achieved via a data connection through the interface 19 or any other connection which can transfer computer-executable instructions to the controller 18, via, for example, wired or wired connection to an application or file storage. In embodiments, the functionality of the control system 20 is distributed across a remote 5 controller portion and a local controller portion, such that it is not necessary for the full functionality of the control system 20 to be integrated with the dispenser 10. Such an embodiment is advantageous where the dispenser 10 is intended for re-installation in a number of different venues over a period of time, where the venues have mixed network connection environments. In such cases, it may be expected that the dispenser 10 will io regularly be installed in an environment in which full connection to a remote control system 20 is likely to be available, such that installation in environments with only weak or no connections are temporary occurrences. In such examples, programming of the on-board controller 18 may be performed such that selected or reduced functionality of the remote control system 20 is installed prior to installation. Such reduced functionality 15 may, for example, omit functionality associated with the consumption history analysis, where the temporary installation of the dispenser 10 is likely be for a sufficiently short time period that the significance of consumption history is reduced. Similarly, additive control analysis may not be required if, for example re-supply of additives is not feasible within the duration for which the dispenser 10 is installed in a particular environment. 20 Such selective configuration enables optimisation of the resources of the dispenser, so that unnecessary configuration is not required. Figure 4 illustrates a beverage dispensing network 40 according to a second embodiment of the present invention. The beverage dispensing network 40 comprises a 25 plurality of dispensers arranged in a plurality of sub-groups 41, 42, 43, 44. For ease of explanation, the second embodiment is described in connection with an office environment, which each sub-group 41-44 of dispensers represents a different floor of the office building. In the second embodiment, the sub-groups 41-44 do not contain have the number of dispensers. It will, of course be appreciated that the sub-groups may, in 30 other embodiments, be configured on a different basis, based on different customer types, organisations, subscription packages, geographical areas, and so on. The term ‘subscriber entity’ is used herein in as a generalisation of the basis of the identification of a subscriber to the control system 20. Each of the beverage dispensers 41a-b, 42, 43a-c, 44a-b is connected to the control system 20, either via a direct wired or wireless communications link. In cases in which a sub-group 43 contains a larger number of dispensers 43a-c, or in which one or more dispensers of the sub-group do not have the capacity for a direct connection to the control 5 system 20, an indirect connection via a local hub 45 or interface may be used instead. A hub 45 can be advantageous to simplify connection to a control system 20 which is arranged remotely from the office establishment, and where a particular beverage dispenser is located in part of a building such as a basement, where connectivity is less reliable. A hub 45 serves each of the dispensers 43a-c in a particular sub-group 43 and io forwards or pre-processes status information 21 to the control system 20, and receives control instructions 22 from the control system 20. Some dispensers in different groups may be in direct contact with each other to share information without the need to communicate with the control system 20. This is 15 illustrated as a communications link between dispensers 41a and 43a. Such communication may be over a short-range network, and is advantageous where data to be communicated by include, for example, confirmation that each dispenser is active, comparison of water supply pressure and temperature, comparison of temperatures, and exchange of error information. Such exchanged information can enable a dispenser to 20 make fine adjustments to process parameters which do not require a more significant system reconfiguration by the control system 20. Additionally, if an error exists in a longer-range communications module of the dispenser, such that communication with the control system 20 is not possible, a dispenser may be able alert a nearby dispenser of this problem over a shorter-range communication link, so that the nearby dispenser 25 can alert the control system 20 accordingly. The centralised control system 20 of the second embodiment is particularly advantageous as it permits collection of a large volume of status information 21, from which rich configuration optimisations can be developed. For example, the larger the 30 volume of consumption history that is received, the more reliable the identification of particular patterns can be become. It may be, for example, that some smaller sub-groups, or sub-groups in smaller locations exhibit similar ratios of consumption between different beverages as those in larger groups, and it is simply the absolute consumption data which is smaller. Having consumption data from larger sub-groups can thus enable 35 control of a dispenser in a small group based on information gathered from other dispensers, such that the network as a whole is optimised, and consistency of dispensing quality can be achieved across the network 40. Further, when such consumption history is annotated with a subscriber entity ID or 5 information such as a geographic location, it is possible to resolve consumption history not by only by particular beverage additives that are consumed in general, but by whether particular beverages are popular with different sub-groups of consumers. In response to such a determination, the control system 20 can issue a diverse set of control instructions, so that beverage dispensers in one group receive different sets of control io instructions from those in other groups, and are driven to different configuration states. For example, workers on one floor of an office may have a stronger preference for a particular beverage than those on another floor. Water pressure on higher floors may be lower than at lower floors. Temperature differences are also common between different floors, with increased consumption possible on warmer floors. 15 In some embodiments, a fault or lack of available of an additive may be identified in dispenser in a particular group that cannot be remedied immediately by a control instruction 22. In such cases, the dispenser in question may be controlled to display a message on its user interface 19 that directs a consumer to use an alternative dispenser, 20 either in the same sub-group, or potentially in a different sub-group, in order to receive a particular beverage. The alternative dispenser is identified based on the status information 21 received for each dispenser. The control system 20 in the second embodiment may be installed in the same 25 establishment as the dispensers, but may alternatively be hosted on a remote platform or server. Remote configurations are particularly suitable where the different sub-groups represent physically diverse locations across a campus or even across a town or broader geographical region, state or country. 30 In some embodiments, it is advantageous to be able to validate the status information 21 which is received from the dispensers of the dispensing network 40 so that the control system 20 is able to generate control instructions in the confidence that they are correctly determined. It is possible for communication errors, caused by network interference or processing errors, to introduce discrepancies between what is sent by a dispenser what 35 is received by the control system 20, and in some cases, it may be that data is not received at all. In the event that there are no errors in the communication process itself, it may be that errors associated with, for example, simultaneous receipt of data from multiple dispensers cause errors in way in such status information is processed by the interfaces 26-29. A validation process assists with addressing such errors. 5 To achieve such validation, embodiments of the present invention include a validation module 46 for validating received data. The validation module 46 may be included within the control system 20 itself, or may be a standalone module hosted on a network such as a cloud platform, which is separate from the control system 20 and which is arranged io between the beverage dispensers and the control system 20 such that status information 21 is communicated to the control system 20 through the validation module 46. This is the particular configuration which is illustrated in Figure 4, where the arrows represent the flow of status information 21. The control instructions 22 which are issued by the control system do not need to pass through the validation module 46, but specific paths 15 to the dispensers are not illustrated in Figure 4 in the interests of conciseness. In alternative embodiments, status information 21 is provided to the control system 20 without passing through the validation module 46, whilst the validation module 46 receives validation data from the dispensers 41a-b, 42, 43a-c, 44a-b instead. 20 In detail, each of the beverage dispensers 41a-b, 42, 43a-c, 44a-b comprises a database which stores all historical vend or dispense information. A task can be programmed for execution by the controller of each dispenser to run over an epoch date time frame (for example, three months), to calculate total vends within that period, and send the results to the validation module 46 as the validation data. The task can be configurable, either 25 via the user interface of each dispenser, or remotely, via a control instruction from the control system 20. On receipt of this vend count, the validation module 46 runs a process to calculate the total vends recorded by the control system 20 based on status information 21 received 30 via the consumption history interface 29 during the same time period, and compares this with the dispenser’s vend count, as contained in the validation data to output a vend audit report. An acceptable tolerance can be configured (for example, 10% error), outside of which 35 an alert is output by the control system 20 (for example, by transmission to an operations team) so that any discrepancy can be investigated. A customer interface, such as a web portal shows all tap vend audit reports and the most recent successful validated time period. 5 In embodiments, the validation module 46 performs a Lambda service. By doing so remotely from any individual dispenser, or from the control system 20, processing resources at the dispenser and the control system 20 do not need to be consumed by the validation process. io Figure 5 illustrates a method 50 of controlling a beverage dispenser, according to a third embodiment of the present invention. The method is performed under the control of the processor 25 of the control system 20. The method is thus implementable as a computer program, comprising a series of computer-executable instructions, and when the processor executes the instructions, the components of the control system as illustrated 15 in Figure 3, for example, cause adjustments to be made to the dispensing configuration of a beverage dispenser 10. In embodiments, the computer program is stored on a non-transitory computer-readable medium. The computer program may be downloaded as an executable file from a 20 database or application store for installation and programming of the processor 25. In step S51, the control system 20 receives status information 21 from one or more beverage dispensers. The status information 21 comprises parameters relating to at least one of: 25 one or more additives available to the beverage dispenser 10; one or more pumps for dispensing the one or more additives; a water supply pressure level; a carbon dioxide supply level; a waste fluid system; and 30 environmental conditions. The status information 21 is not limited to the above examples, however, and it will be appreciated that a variety of system parameters of a dispenser 10 can be provided to the control system 20. Step S51 may be repeated on a periodic basis, by polling the one or more dispensers for status information 21, which may be received in a batch comprising information for a plurality of parameters in a single transmission. In alternative embodiments, step S51 begins when data is pushed to the control system from a beverage dispenser 10, perhaps 5 in response to a system change. Further, the frequency of receipt of status information for different parameters may vary. Information relating to environmental conditions, and generic error code data may be provided more frequently than information relating to consumption data, for example, so io that the control system can respond substantially in real time to any particular changes that might affect the ability of a dispenser to function optimally, but where it is not necessary to track small relative changes in consumption statistics for a particular beverage at the same frequency. 15 The status information 21 further includes information which identifies the beverage dispenser, so that status information can be processed and logged in association with a particular beverage dispenser profile which is held by the control system 20. In embodiments, the control system 20 comprises a system profile storage module which contains information associated with the beverage dispenser, such as its model or serial 20 number, age, installation location, service history, and subscriber identification information associated with users of the dispenser, defining the beverages authorised for dispense, and functions available for use. In embodiments such as that of Figure 4, in which the control system 20 receives information from a plurality of beverage dispensers, the system profile storage includes information for each of the plurality of 25 dispensers. In step S52, the condition of the dispenser is determined based on the received status information 21. The condition of the dispenser represents a characterisation of a set of operating parameters of the dispenser, which are received from the status information, 30 or which are stored in the system profile storage module when not represented in status information. The term ‘condition’, as used herein, may be indicative of the physical state of the dispenser, in terms of whether its hardware is functioning correctly, but may also be 35 indicative of the status of the dispenser in terms of the beverages which it is both requested to produce, and which it is able to produce. As such, the condition is a snapshot of the overall operating configuration of a dispenser at a particular instant in time, from which a number of inferences can be made as to whether the operating configuration is as intended. 5 In embodiments, each individual parameter of the dispenser which is contained in the set of information defining the operating condition of the dispenser, is compared by the processor 25 against a predetermined threshold or target value, which is derived from the configuration library 30. The outcome of each comparison is a series of results io indicating whether the parameter is satisfactory, or whether it indicates the presence of, or a prediction of, a situation which requires action to return the comparison to a satisfactory result. The condition may therefore be characterised as ‘low additive’. It will be appreciated that a variety of conditions can be diagnosed by the processor 25, and that the condition might be simultaneously characterised by a plurality of states. 15 It may be that the condition is satisfactory, in which case no configuration is required, as all parameters are satisfactory. In this instance, no further action is required and the method 50 returns to step S51 to await further status information. 20 In step S53, a configuration adjustment is determined. This process uses a plurality of algorithms which are performed by the processor in order to determine action to take such that the dispenser 10 returns to a satisfactory condition. The satisfactory condition may be a condition which previously existed, such as a replenished additive, with no changes to the operation of the dispenser being required. The satisfactory condition may 25 alternatively be a new condition which is adopted due to a change in consumption habits, a change in environmental conditions, a change in the physical status of the dispenser, or changes in line with natural human organoleptic shifts throughout the day (e.g. flavour intensity). 30 Reconfigured operating parameters may include, but are not limited to: • timing sequences for activation of one or more pumps for dispensing one or more respective additives; • dispensed volumes of one or more additives; • volume and pressure of water and carbon dioxide and temperature of water; and 35 • activation of flush system. For example, one or more pumps may be adjusted to have different dispensing cycles and phases to ensure load balancing or to accommodate the failure of a faulty pump until it can be replaced. The pumps may be adjusted in response to a change in water 5 pressure. The chiller may be adapted in response to a change in water temperature determined by a sensor at the dispenser. A flush may be activated if a volume of water in a waste management system exceeds a predetermined limit. The user interface may be adjusted to reflect temporary or permanent lack of availability, or restricted availability of a particular beverage, beverage type, or additive. 10 Many further examples of the operation which is to be initiated at the dispenser will be apparent to those skilled in the art, and each of these examples is to be interpreted within the scope of the term ‘configuration adjustment’, as used herein. In general, the adjustment references the fact that an aspect of the dispenser’s configuration is desired 15 to be changed from the configuration associated with the provided status information 21 in step S51. In step S54, one or more control instructions 22 are output to the dispenser to cause actuation of the configuration change which was determined in step S53. The control 20 instructions are provided to the controller 18 of the dispenser, which in turn interprets and acts on the control instructions to cause the requested change in configuration. Examples of possible reconfigurations are described above. In general, the reconfigurations resolve into reconfigurations which: 25 • ensure that what is dispensed is meets particular quality requirements; • dynamically adjust what can be produced. The former category of reconfigurations are adjustments to parameters caused by changes in physical health of a device, and environmental conditions. The quality 30 requirements may be derived from the recipe for a particular beverage which is contained in the master catalogue 24. The recipe may specify a plurality of ranges or tolerances on the amounts of a particular additive to be used, to allow for variances in operating conditions. For example, water hardness may vary between geographical areas, which may affect the way in which a beverage should be dispensed. It may be permissible to 35 vary the temperature of a dispensed drink within a particular range, in response to environmental conditions. It may be permissible to made small adjustments of additive volumes for additives which are to be used, particularly those used in larger quantities, in a particular beverage. Parameters which go outside of such tolerances are those which are such that the beverage may have a different taste from that prescribed by a 5 manufacturer, such that the customer may have a negative experience. The reconfigurations to preserve quality of a dispensed beverage may relate to modifications to the way in which a beverage is dispensed, adjustments to whether a particular beverage is available for dispensing at all, and adjustments to resupply, or 10 restrict the supply of a beverage until such time as it one or more additives can be resupplied. References to the resupply of additives may also apply to resupply of carbon dioxide cylinders, such that supply of carboned beverages may be temporarily suspended or restricted if necessary. 15 Reconfigurations to dynamically adjust what can be produced may be voluntary changes, based on availability of new beverages and consumption data indicating popularity of a particular beverage. Cases in which the dynamic adjustment are not voluntary, and are triggered by the unavailability of a particular additive, are described above. 20 In the accompanying drawings, each of the functional modules illustrated as rectangular blocks of a system diagram may represent sets of computer-executable instructions, representing a subset of a larger operating program executed by the processor. In embodiments, each functional module may be a standalone component represent by a dedicated local processor and a dedicated memory storing executable instructions 25 specific to that module, the modules interconnected as shown in the figures. Groups of functional modules may be combined. It will be readily appreciated by those skilled in the art that a number of modifications to the embodiments described above will fall within the scope of the claims, dependent on 30 the number of dispensers to be controlled, the relative environments of the dispensers, the number and diversity of additives to be used by each dispenser, the communication link between each dispenser and the control system, the overall frequency of use of each dispenser, and the frequency of dispensing of individual beverages. For example, it may not be necessary in all embodiments to include a consumption history interface 29. In 35 another example, the beverage dispenser health interface 26 and the additive supply level interface 27 may be integrated into a single interface. In other embodiments, all of the interfaces 26-29 shown in Figure 3 may be integrated into a single interface. Common to each of these embodiments is the provision of a dedicated dynamic 5 adjustment functionality which can optimise not only individual dispenser performance, but consumer experience across a network of dispensers. Embodiments of the present invention can provide a large volume of diagnostic information to beverage manufacturers as to beverage popularity. Embodiments of the io present invention can also facilitate gathering of revenue-collection information for particular establishments such as bars and restaurants by providing detailed information on particular beverage vends in particular locations, so that optimisations can be developed as to which beverages should be made available and when. For example, particular flavours or temperatures may be more commonly sold or served in warm 15 climates, summer months, or during the middle of the day than other flavours which are more popular in the morning or evening, or in cooler months or climates. Tracking of dispensing information can be easily achieved by retrofitting the control system of embodiments of the invention to a particular network of beverage dispensers, 20 by providing a communications link from each dispenser’s on-board data-collection mechanisms, such as a controller and / or memory, to the control system. Alternatively, one or more individual beverage dispensers may be supplied as part of a kit containing hardware to support the control system. 25 Advantages which are associated with improving the performance of a dispenser not only improve the lifetime of a dispenser but enable more economical component choices. For example, a relatively simple or inexpensive additive pump can have a performance level which is raised to that of a more complex or premium-specification additive pump due to the improvement in the control of its operation which is made possible by the 30 control system. As such, high performance can be achieved even in the absence of the highest quality performance rating of an individual dispenser component.

Claims

1. A control system for a beverage dispenser, comprising one or more controllers arranged to:5 receive status information for a dispensing configuration of the beveragedispenser;process the received status information to determine a condition of the beverage dispenser and an adjustment to the dispensing configuration required to change the condition from a first condition, associated with the received status information, to a io predetermined second condition;output control instructions to cause the determined adjustment to the dispensing configuration of the beverage dispenser; andwherein the dispensing configuration defines a set of operating parameters to be used by the beverage dispenser to dispense a beverage.

152. The control system of claim 1, wherein the status information comprises a dispensing history of the beverage dispenser, wherein the dispensing history tracks a dispensing frequency and the dispensed volume of one or more beverages over a predetermined period of time.

203. The control system of claim 1 or claim 2, wherein the status information comprises parameters relating to at least one of:one or more additives available to the beverage dispenser;one or more pumps for dispensing the one or more additives;25 a water supply pressure level;a carbon dioxide supply level;a waste fluid system; andenvironmental conditions.30 4. The control system of any one of the preceding claims, wherein the one or morecontrollers are arranged to access a plurality of recipes, each recipe defining a set of one or more additives for a beverage, and to select a subset of the plurality of recipes in dependence on the received status information,wherein the control instructions cause the beverage dispenser to be configured 35 to dispense beverages defined by the selected subset of the plurality of recipes.

5. The control system of claim 4, wherein the status information identifies a subscriber entity associated with the beverage dispenser, and the one or more controllers are arranged to select the subset of the plurality of recipes in dependence 5 upon a predetermined set of beverages associated with the subscriber entity.

6. The control system of claim 4 or claim 5, comprising a recipe storage module storing the plurality of recipes, and a beverage catalogue module for storing the selected subset of the plurality of recipes.io7. The control system of any one of the preceding claims, wherein the status information comprises identification information for one or more additive containers for storing additives for the beverage dispenser to dispense;wherein the one or more controllers are arranged to authenticate the one or more 15 additive containers using the received identification information, and to reject status information relating to an additive container which is not authenticated, and to process status information only for an additive container which is authenticated to determine the control instructions to output.20 8. The control system of claim 7, wherein the one or more controllers are arrangedto instruct an additive supply module to supply one or more additives to the beverage dispenser if the first condition indicates a level of stored additive is below a predetermined threshold, or if the first condition indicates that emptying of the additive container within a predetermined time period is forecast.

259. The control system of any one of the preceding claims, wherein the operating parameters comprise at least one of:timing sequences for activation of one or more pumps for dispensing one or more respective additives;30 dispensed volumes of one or more additives;volume and pressure of water and carbon dioxide and temperature of water; and a flush system.

10. The control system of any one of the preceding claims, wherein the one or more 35 controllers are arranged to generate one or more images for display by a user interfaceof the beverage dispenser, wherein content of the one or more images is determined by the one or more controllers in dependence on the status information.

11. The control system according to any one of the preceding claims, wherein the 5 one or more controllers are arranged to execute a machine-learning algorithm to learn the adjustment to the dispensing configuration that is required to change the condition of the beverage dispenser from the first condition to the second condition;wherein the control system comprises a storage means for storing status information received before output of the control instructions and received after output of io the control instructions, and the one or more controllers use the stored status information and historical adjustments to the dispensing configuration as training data for the machine-learning algorithm.

12. A beverage dispensing system comprising:15 a beverage dispenser comprising:one or more coupling modules for coupling additive containers to the beverage dispenser;an additive manifold in communication with the coupling modules for receiving additives from the respective additive containers, and in fluid 20 communication with a water source for flushing the additives from the manifold;a dispense head in fluid communication with the manifold for dispensing the additives;a storage means for storing a dispensing configuration and a dispensing history; and25 a dispensing controller arranged to control the dispense head to dispenseone or more additives for a beverage in dependence on the stored dispensing configuration; andthe control system of any one of the preceding claims;wherein the storage means is arranged to receive the dispensing configuration 30 from the control system.

13. A beverage dispensing system according to claim 12, wherein the beverage dispenser comprises one or more controllers of the control system.35 14. A beverage dispensing network, comprising:a plurality of beverage dispensers, each of the plurality of beverage dispensers comprising:one or more coupling modules for coupling additive containers to the beverage dispenser;5 an additive manifold in communication with the coupling modules forreceiving additives from the coupling modules, and in fluid communication with a water source for flushing the additives from the manifold; anda dispense head in fluid communication with the manifold for dispensing the additives;10 a storage means for storing a dispensing configuration and a dispensinghistory; anda dispensing controller arranged to control the dispense head to dispense one or more additives for a beverage in dependence on the stored dispensing configuration; and15 the control system of any one of claims 1 to 11,wherein the storage means is arranged to receive the dispensing configuration from the control system; andwherein each of the plurality of beverage dispensers comprises a communication module for communicating status information to the control system.2015. The beverage dispensing network of claim 14, wherein the one or more controllers are arranged to cause the dispensing configuration of a first beverage dispenser to be adapted in dependence upon status information communicated to the one or more controllers by a second beverage dispenser.2516. The beverage dispensing network of claim 14 or claim 15, comprising a validation module for validating a batch of status information and uploading batches of validated status information to the control system;wherein the communication module of each of the plurality of beverage 30 dispensers is arranged to upload status information to the control system via the data validation system.

17. A method of controlling a beverage dispenser, comprising:receiving status information for a dispensing configuration of the beverage 35 dispenser;processing the received status information to determine a condition of the beverage dispenser and an adjustment to the dispensing configuration required to change the condition from a first condition, associated with the received status information, to a predetermined second condition; and5 outputting control instructions to cause the determined adjustment to thedispensing configuration of the beverage dispenser;wherein the dispensing configuration defines a set of operating parameters to be used by the beverage dispenser to dispense a beverage.10 18. A computer program comprising computer-executable instructions which, whenexecuted by one or more processors, are arranged to cause the method of claim 17 to be performed.

Images