Title of Invention: SYSTEM AND METHOD FOR ADJUSTING THE DEPTH OF PARALLELIZATION FOR RECIPE PROGRAM EXECUTION Abstract: Recipe instructions may be executed by one or more cooking apparatuses, and annotated with one or more device types suitable to execute the respectively annotated recipe instructions. A parallelization constraint associated with a particular cooking user may influences a degree of parallelization of the food preparation with regard to the parallel use of the registered cooking apparatuses. A program analyzer module determines one or more subsets of the registered cooking apparatuses by identifying execution options for the recipe instructions on said one or more subsets resulting in a recipe execution in compliance with the parallelization constraint. The execution option providing a best match with the received parallelization constraint in accordance with predefined matching rules is selected recipe deployment instructions are provided in relation to the respective one or more cooking apparatuses of the selected execution option in accordance with the corresponding annotations for preparing the food product. Detailed Description: CROSS-REFERENCE TO RELATED APPLICATIONS The application claims priority to EP Patent Application No. 21162909.2, filed on Mar. 16, 2021 and entitled “System and method for adjusting the depth of parallelization for recipe program execution,” the disclosure of which is hereby incorporated by reference in its entirety. TECHNICAL FIELD The present description generally relates to cooking apparatuses, and more particularly, relates to adjusting the depth of parallelization for executing recipe program instructions under given parallelization constraints. BACKGROUND Cooking apparatuses (cooking devices) have become more and more intelligent in the recent past by integrating multiple cooking functions into a single cooking apparatus. For example, modern cooking devices integrate functions, such as heating, mixing, boiling, pureeing, etc., in a single multi-function cooking device. A cooking device typically has to be operated with appropriate technical parameter settings (e.g., temperature settings, rotational speed settings, etc.) to ensure proper operation. Proper operation of a cooking device as used hereinafter refers to correct, safe and/or secure operation for producing reproducible cooking results with the cooking apparatus with regards to a particular food product. Typically, the functions of such a multi-function cooking apparatus are controlled by one or more recipe programs which have instructions that are sequentially executed to arrive at the prepared food product or menu. For example, a recipe program can be loaded into the cooking apparatus for preparing a certain course of a menu and multiple courses can be prepared by processing respective recipe programs in a corresponding sequence. However, a recipe program may also include program instructions related to food processing steps of two or more courses (or an entire menu). Food products resulting from such complex food processing steps are referred to as complex food products herein. The processing of such complex food processing steps may involve the use of a plurality of cooking apparatuses to allow for parallel execution of certain recipe instructions on multiple cooking apparatuses. SUMMARY There is therefore a need to enable the provisioning of recipe instructions in relation to one or more cooking apparatuses for preparing a food product with cooking apparatuses available in the cooking environment of the cooking user. The cooking apparatuses may be of different device types supporting different cooking functions. This is achieved by a dynamic adjustment of the depth of parallelization for recipe program execution when using a plurality of cooking apparatuses in parallel to meet a parallelization constraint associated with a user for the preparation of the food product. The parallelization constraint may be different for different types of cooking users dependent on the desired cooking experience by the respective user. The desire for provisioning recipe instructions to multiple cooking apparatuses may be motivated by: a user desire to shorten the overall cooking time (recipe execution time) through simultaneous execution of different groups of recipe instructions on different cooking apparatuses, a user desire to influence the degree of automation of the cooking steps through the use of cooking apparatuses supporting a respective degree of automation, and a user desire to improve the user perceived quality of food products through the use of specialized cooking apparatuses which provide cooking results for particular cooking functions in compliance with the user's quality expectations. The above problem is solved by embodiments as claimed by the independent claims: a computer-implemented method for recipe instruction provisioning in relation to one or more registered cooking apparatuses for preparing a food product, a computer program product with recipe instructions configured to cause execution of said method when executing the computer program method, and a computer system which can load and executed saic computer program product to execute said method. Typically, cooking apparatuses used in a joint cooking process for preparing a food product are under the control of a control system which deploys respective partitions of the recipe program to the involved cooking apparatuses for execution, and which provides recipe instructions to the user if such instructions are to be manually executed by the user. Typically, such cooking apparatuses include apparatuses of different device types (e.g., refrigerator, oven, microwave, or multi-function cooking apparatuses with different functional scopes—i.e., support of different cooking functions —, etc.) The control system can be a separate system which is communicatively coupled with one or more of the cooking apparatuses, or it may be an integral component of one of the cooking apparatuses (lead apparatus). The control system determines which of the other cooking apparatuses are to be used for execution of respective recipe instructions. Multi-function cooking apparatuses of different device types may, for example, support different maximum cooking temperatures with their respective heating elements and heat controller, or different maximum rotational speeds of their stirring/chopping elements with their respective motors and motor control elements. It is to be noted that “cooking function” as used herein refers to any action which can be performed by a cooking apparatus in the course of processing recipe instructions. That is, a cooking function does not necessarily involve a heating step. Also functions such as chopping or stirring are referred to as cooking functions. The computer system for recipe instruction provisioning in relation to one or more registered cooking apparatuses is communicatively coupled with one or more registered cooking apparatuses. Each cooking apparatus is of a particular device type. There can be multiple registered cooking apparatuses of the same device type. A registry accessible by the control system provides the information about the available cooking apparatus. An available cooking apparatus is registered in the registry together with its device type. This ensures that all cooking apparatuses which are available for recipe execution are known by the control system. The system has an interface to receive a recipe program file with machine readable recipe instructions for preparing the food product. Typically, such recipe program files are provided by a remote recipe server which can be accessed by the control system via wide area network such as the Internet. However, recipe files may also be provided by wearable or portable storage media, such as for example, a USB stick, a DVD, or the like, which is then connected to the control system do download the recipe file into a corresponding memory of the control system. In particular with recipes for complex food products, the recipe instructions are configured to be executed by one or more cooking apparatuses in that the recipe instructions are annotated with one or more device types suitable to execute the respectively annotated recipe instruction. In other words, the recipe instructions of such a recipe program include metadata which specify which device types are appropriate to execute a particular recipe instruction. The recipe program file may also include recipe instructions which are not dependent on a particular apparatus but which are directed to manual tasks to be performed by the user (e.g., preparing cooking ingredients). However, for such manual recipe instructions, a deployment to the one or more cooking apparatuses is not necessary. Further, the system has an interface to receive a parallelization constraint associated with a particular cooking user. The parallelization constraint is configured to influence the degree of parallelization of the food preparation with regard to the parallel use of the one or more registered cooking apparatuses. It is to be noted that in case recipe instructions can be provisioned to multiple cooking apparatuses, typically at least some of those instructions can be executed in parallel, whereas when using a single cooking apparatus, all instructions which require the use of the cooking apparatus are necessarily executed sequentially (only manual steps may be performed in parallel). Parallel use, as used herein, therefore relates to the cooperative use of multiple cooking apparatuses when jointly executing a recipe program with certain partitions of the recipe program being distributed to the respective cooking apparatuses. For example, the parallelization constraint may specify a user defined preparation time for the food product, or a user defined device support-level specifying a degree of automation for semi-automated cooking, or a user defined device flexibility-level specifying potential use of specialized cooking devices. A specification for a user defined preparation time may also be given by a representation of relative time related expressions, such as, “slow”, “relaxed”, “fast”, etc. A specification for a user defined device support-level for semi-automated cooking may be given, for example, by specifying an acceptable maximum number of manual cooking steps in the recipe program, or by relative automation related expressions specifying anything between manual cooking and automated cooking. Examples for such relative terms are “low automation”, “high automation”, etc. A specification for a user defined device flexibility-level specifying potential use of specialized cooking devices may be given as relative terms regarding the device type variety to be used for the recipe execution. For example, a user may specify a flexibility constraint by terms such as “healthy”, “crispy” or the like. For example, if a specialized device type allows to execute a frying step with less fat/oil than a standard device type, the specialized device type may be associated with the flexibility-level “healthy” for respective cooking functions and the system would select execution options using the specialized device type in compliance with a corresponding flexibility-level constraint. A further specialized device type may be associated with the flexibility-level “crispy” for a particular cooking function. In case a flexibility-constraint value “crispy” is associated with the user, the system would select execution options with this further device type. The parallelization constraint may be received as a direct input provided by the cooking user via a respective user interface. Alternatively, the parallelization constraint may be retrieved from a stored user profile of the cooking user after the user has logged into the control system. A program analyzer module of the system determines one or more subsets of the registered cooking apparatuses by identifying execution options for the recipe instructions on said one or more subsets. Thereby, each possible sequence of recipe instructions when being executed by the annotated device types is considered as an execution option. For example, for a recipe with two recipe instructions RI1, RI2 with the following device type annotations RI1: DT1, DT2, and RI2: DT1, DT3, the following execution options are possible: RI1(DT1)-RI2(DT1); RI1(DT1)-RI2(DT3); RI1(DT2)-RI2(DT1); and RI1(DT2)-RI2(DT3). Assuming that the registry includes a first cooking apparatus of device type DT1 and a second cooking apparatus of device type DT2, then the subsets determined by the program analyzer as are: (DT1) and (DT1, DT2) with the corresponding execution options RI1(DT1)-RI2(DT1) and RI1(DT2)-RI2(DT1). The device type annotations of the recipe instructions are thereby used as a filter criterion to eliminate all execution options for the recipe program which require device types not represented by the registered cooking appliances. Of course, such execution options would not be executable by the user's equipment. The execution options RI1(DT1)-RI2(DT1) requires only DT1 but does not allow for parallelization because only a single cooking apparatus is used for sequential processing of the recipe instructions RI1, RI2. It is assumed that the output of RI1 is not needed as an input to RI2. In such case the execution option RI1(DT2)-RI2(DT1) allows for parallel use DT2 and DT1 which reduces the overall preparation time of the food product. The program analyzer also ensures that the determined subset(s) can guarantee a recipe execution in compliance with the parallelization constraint. Assuming that the parallelization constraint relates to a preparation time constraint of the user, for example, the user may have set a time constraint of 20 minutes for the food preparation. In this case, it is assumed that execution option RI1(DT1)-RI2(DT1) takes 23 min while the parallel execution option RI1(DT2)-RI2(DT1) only requires 19 min of food processing time. To enable the program analyzer to select the execution option with the subset providing a best match with the received parallelization constraint, predefined matching rules are evaluated by the program analyzer. Such matching rules are typically part of the user profile. For example, the user may specify that in case of a time constraint it is desired that the time constraint is treated by the system as a maximum time, a minimum time or the time to which the actual preparation time should be closest. If the time constraint of 20 min is treated as the maximum cooking time, the program analyzer selects the subset (DT2, DT1) for the parallel execution option RI1(DT2)-RI2(DT1) as the best match. This would also be selected by the matching rule where the selected execution comes closest to the given time constraint. However, if the matching rule interprets the time constraint as the minimum time (e.g., “slow” cooking is preferred), then the subset (DT1) for the sequential execution option RI1(DT1)-RI2(DT1) is selected. A deployment module provides the corresponding recipe deployment instructions in relation to the respective one or more cooking apparatuses of the selected execution option in accordance with the corresponding annotations for preparing the food product. In the above example, in case the execution option with the subset (DT2, DT1) is selected, RI1 is deployed to DT2, and RI2 is deployed to DT1. In case execution option with the subset (DT1) is selected, RI1 and RI2 are deployed to DT1. In case that RI1 and RI2 are machine readable instructions which can directly be processed by the respective cooking apparatuses, the control system can send the instructions directly to the respective receiving cooking apparatuses via an appropriate communication link (e.g., LAN, WLAN, Bluetooth, or any other appropriate communication channel). If no direct machine-to-machine communication is possible, the respective deployment instructions are provided to the user to be manually applied to the respective receiving cooking apparatus. For example, a display unit of the control system may show the corresponding instructions to the user. In one embodiment, the recipe program file includes predefined alternative program listings of the recipe program. Each alternative program listing is related to a particular combination of cooking apparatuses with corresponding device type annotations. In other words, the alternative listings correspond to various execution options suitable to be executed on respective cooking apparatuses in accordance with the device annotations of the recipe instructions. In the above example, for each execution option RI1(DT1)-RI2(DT1), RI1(DT1)-RI2(DT3), RI1(DT2)-RI2(DT1), and RI1(DT2)-RI2(DT3) the corresponding program listing is included in the recipe program file. To determine one or more subsets of the registered cooking apparatuses the program analyzer selects the alternative program listings with combinations that only include registered cooking apparatuses. That is, in the above example, with the registered cooking equipment of the user only including DT1 and DT2 cooking apparatuses, the program analyzer discards the program listings associated with the execution options RI1(DT1)-RI2(DT3) and RI1(DT2)-RI2(DT3) because they could not be executed by the available equipment. In this embodiment, the alternative program listings in the recipe program file are annotated with corresponding parallelization constraint metadata in accordance with parallelization constraint preferences of stored user profiles. For example, the program listing for execution option RI1(DT1)-RI2(DT1) may be annotated with a representation of a predicted preparation time of 23 min for this alternative program listing, whereas the program listing for the parallel execution option RI1(DT2)-RI2(DT1) may be annotated with the predicted preparation time of 19 min. With regard to the parallelization constraint of the device support-level, the parallelization constraint metadata may include a representation of an associated support-level. For example, the degree or level of automation in the food preparation process may be higher when using the sequential execution option RI1(DT1)-RI2(DT1) because less manual steps may be required with regard to moving actions required in the parallel execution option RI1(DT2)-RI2(DT1). The sequential program listing may therefore be annotated with “high automation degree” whereas the parallel program listing may be annotated with “low automation degree”. With regard to the parallelization constraint device flexibility-level, DT2 may be a cooking apparatus which has a certain cooking capability that is particularly advantageous for performing RI1. Therefore, the parallel execution option has a higher device flexibility in this regard as it uses DT2 for RI1 and DT1 for RI2. As a consequence, the parallel program listing may be annotated with “high device flexibility” whereas the sequential program listing may be annotated with “low device flexibility”. It is to be noted that real program listings may include a large number of recipe instructions (e.g., >>10) which may be executed by a relatively large number of cooking apparatuses (e.g., >5). In such situations, a large number of alternative program listings would be needed to cover all kinds of execution options in predefined program listings. Therefore, an alternative embodiment of the program analyzer may be used which can determine execution options at runtime based on single generic recipe program description in the recipe program file. In this alternative embodiment, the recipe program file has a program listing which indicates groupings of recipe instructions. The recipe instructions of a particular grouping are to be executed by one cooking apparatus in accordance with the corresponding annotations. In the embodiment, the program analyzer has a partitioning module which identifies execution options for the recipe instructions based on predefined partitioning rules. Such partitioning rules can check the various groupings to determine which grouping can be assigned to which cooking apparatus (device type) in view of the parallelization constraint. For example, preparation times may be computed for various execution options executed by various combinations of cooking apparatuses in accordance with the annotations. Then, the program analyzer may select the execution option having the best match with the corresponding parallelization constraint (time constraint). In another dimension, degrees of automation may be determined for various execution options executed by various combinations of cooking apparatuses in accordance with the annotations. For example, the program analyzer may select the execution option with a corresponding number of manual activities (or with a corresponding time effort in manual activities) while taking into account the respective groupings and the given device automation constraint. In case the parallelization constraint indicates the user's desire for the highest degree in automation for a particular recipe, the program analyzer may select the execution option with the lowest number of manual activities (or with the lowest time effort in manual activities). In yet another dimension, degrees of device flexibility may be determined by the program analyzer for various execution options executed by various combinations of cooking devices in accordance with the annotations. For example, if the user prefers a high degree of flexibility the program analyzer may identify the execution option making use of the most different device types for the food processing din accordance with the respective groupings. In summary, the identified execution options can be mapped to parallelization constraint preferences directly received as user inputs or stored in respective user profiles in accordance with predefined mapping rules. Such mapping rules are configured such that the recipe program is checked whether the recipe instructions can be divided into partitions which can then deployed to one or more of the registered cooking apparatuses to comply with parallelization constraint. The above functions of the control system are executed as a computer-implemented method for recipe instruction provisioning in relation to one or more registered cooking apparatuses for preparing a food product, with the various steps being executed in an appropriate order as described in more detail in the detailed description. Thereby, in one embodiment, a respective computer program product with computer readable instructions is loaded into a memory of the control system and executed by at least one processor of the control system, thus causing the computing device to perform the computer-implemented method for performing the herein described functions of the control system. Further aspects of the description will be realized and attained by means of the elements and combinations particularly depicted in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 illustrates a block diagram including a control system for recipe instruction provisioning in relation to one or more registered cooking apparatuses for preparing a food product according to an embodiment; FIG. 2 is a simplified flow chart illustrating a computer-implemented method for recipe instruction provisioning in relation to one or more registered cooking apparatuses for preparing a food product according to an embodiment; FIGS. 3A, 3B illustrate two example implementations of recipe partitioning in line with execution options; FIG. 4 illustrates execution times for two alternative recipe program listings with different levels of parallelization; FIG. 5 illustrates an example for executing an execution option in accordance with a flexibility-level constraint; and FIG. 6 is a diagram that shows an example of a generic computer device and a generic mobile computer device, which may be used in example embodiments. DETAILED DESCRIPTION FIG. 1 illustrates a block diagram including a control system 100 for recipe instruction provisioning in relation to one or more registered cooking apparatuses 210, 220, 230 for preparing a food product according to an embodiment. FIG. 2 is a simplified flow chart of a computer implemented method 1000 for recipe instruction provisioning in relation to one or more registered cooking apparatuses for preparing a food product according to an embodiment. FIG. 1 is described now in the context of FIG. 2. For this reason, reference numbers of FIG. 1 and FIG. 2 are used in the following description. In the example of FIG. 1, the control system 100 (implemented by a computer system) is communicatively coupled with a recipe storage 280. The recipe storage 280 can also be an integral component of the system 100, or it may be a remote data storage system accessible via the interface 110. The recipe storage 280 stores a plurality of recipe program files with machine readable recipe instructions for preparing food products. Typically, a cooking user 1 can select a particular recipe for preparing a particular food product while interacting with the control system 100. For interaction with the user 1, the interface 110 also implements a suitable user interface. Once the user 1 has made a selection of a particular food product to be prepared, the control system receives 1100 the associated recipe program file 281 (e.g., via a download of the recipe program file from the recipe storage 280). The recipe program file 281 includes recipe instructions which are configured to be executed by one or more cooking apparatuses in that each recipe instruction is annotated with one or more device types suitable to execute the respectively annotated recipe instruction. Thereby, the recipe program file may include all kinds of possible device type options for respective recipe instructions. The user 1 does not necessarily command cooking apparatus (CA) of all such device types which are listed as options in the recipe program file. In the example, the user's cooking environment provides a multi-function apparatus 210 of device type DT1 (supporting a broad range of cooking functions 212), a simpler version of a multi-function cooking apparatus 220 of device type DT2 (supporting a smaller range of cooking functions 222), and an oven 230 of device type DT3 (supporting cooking functions 323 that may differ from the other cooking function). All cooking apparatuses which are available in the user's cooking environment for food preparation are registered (dash-dotted double arrows) in a CA registry 140. The CA registry 140 may be an integral part of control system 100, or it may be accessible by the system 100 on a remote storage device. In the example, DT1 and DT2 are compatible in the sense that they provide receipts (e.g., connectors, mechanical interfaces, holders) configured to insert the same type of bowls or vessels. That is, the bowl (or vessel) 215 (with a lid) of CA 210 can equally be inserted into CA 220, and bowl (or vessel) 225 of CA 220 can equally be inserted into CA 210. Each of the cooking apparatuses 210, 220, 230 has a respective recipe execution module 211, 221, 231. The recipe execution modules are configured to execute recipe instructions on the respective CA to perform corresponding cooking functions 212, 222, 232. It is to be noted that “cooking function” as used herein refers to any action which can be performed by a cooking apparatus in the course of processing recipe instructions. That is, a cooking function does not necessarily involve a heating step. Cooking functions include but are not limited to functions such as heating, boiling, frying, steaming, baking, weighing, chopping, mixing, whipping, stirring, etc. Thereby, each CA may be of a different device type and support a different subset of cooking functions associated with the respective device type. The cooking functions are implemented via respective hardware components. For example, the stirring and chopping functions are implemented with a motor and a motor control function driving a chopping/stirring element. The heating function is implemented with a heater and a heat control function. The skilled person knows how other cooking functions of a multifunction cooking apparatus can be implemented. Typically, the hardware control functions process sensor data which monitor the respective function parameters, such as for example, data received from a rotational speed sensor for the motor control, or from a temperature sensor for the heater control. The recipe instructions may be directly deployed to a CA via a machine-to-machine communication between the control system 100 and the CA. In the example of FIG. 1, a partition P1 of the recipe program file 281 with recipe instructions directed to CA 210 is directly deployed to CA 210 by the deployment module 130 of the system 100 via machine-to-machine communication. Such partitions may be already predefined in the received recipe program file 281, or they may be dynamically generated by a partitioning module 124 using predefined partitioning rules. In the example, deployment module 130 also provides a partition P3 with recipe instructions directed to the oven 230. It is assumed that there is no machine-to-machine communication between the control system 100 and the oven. Instead, the oven needs to be manually operated by the user 1. In this case, the deployment instructions of P3 are provided to the user to operate the oven accordingly. The control system 100 further receives 1200 a parallelization constraint 11 associated with the cooking user 1. In one implementation, the user may directly enter the parallelization constraint 11 as an input to the control system via the user interface which enables the user 1 to interact with the control system 100. Any appropriate user interface technology (e.g., keyboard, touch screen, audio input, etc.) may be used. The user interface may be implemented as an integral part of the control system or it may be implemented on a remote, communicatively coupled front-end device (e.g., a smartphone or tablet computer), for example by an application which allows the front-end device to interact with the control system. In an alternative implementation, the user 1 logs into the control system 100. Once logged in, a user profile 291 of the user 1 is retrieved from a user database 290. The user profile 291 includes the user's parallelization constraint(s) 11. Thereby a parallelization constraint 11 specifies any of the following: a user defined preparation time for the food product, a user defined device support-level for semi-automated cooking, and a user defined device flexibility-level specifying potential use of specialized cooking devices. In case a user profile includes multiple parallelization constraints (e.g., in different dimensions, such as a time constraint “slow”, a support-level constraint “low automation”, and a flexibility-level constraint specifying one or more specialized cooking devices) the user may select via the user interface which parallelization constraint is to be used for the currently selected recipe program file 281. Alternatively, the user profile may define a default parallelization constraint for the user if no selection is made. The parallelization constraint finally influences the degree of parallelization of the food preparation with regard to the parallel use of the registered cooking apparatuses 210, 220, 230 in that a recipe program analyzer module 120 of the control system determines an execution option for the recipe execution involving one or more subsets of the registered cooking apparatuses which are appropriate to comply with the given parallelization constraint 11. For that purpose, the program analyzer module 120 firstly determines 1300 one or more subsets S1, S2 of the registered cooking apparatuses by identifying execution options 121 for the recipe instructions on said one or more subsets resulting in a recipe execution in compliance with the given parallelization constraint 11. Execution options 121 may already be predefined as alternative program listings in the recipe program file 281 (cf. FIG. 3A), or they may be dynamically derived from a generic program listing based on the annotations of the recipe instructions. At this stage, already all execution options associated with the recipe program file 281 requiring a device type which is not amongst the device types of the registered cooking apparatuses are eliminated from further consideration. That is, executions options which cannot be executed with the cooking equipment of the user 1 are discarded. Secondly, a selector function 122 of the program analyzer 120 selects 1400 the subset S1 providing a best match with the received parallelization constraint 11 in accordance with predefined matching rules 123. Thereby, the matching rules 123 may be derived from the user profile of the user 1. Example of the matching rules 123 may include, but are not limited to: in case of a particular time constraint, select the subset which enables the execution option with an execution time that is closest to the execution time associated with the given time constraint; in case of a particular time constraint, select the subset which enables the execution option with an execution time that is closest to and not longer than the execution time associated with the given time constraint; in case of a particular time constraint, select the subset which enables the execution option with an execution time that is closest to and not shorter than the execution time associated with the given time constraint; in case of a particular support-level constraint, select the subset which enables the execution option which limits the number of manual cooking activities in accordance with the given support-level constraint; and in case of a particular flexibility-level constraint, select the subset which enables the execution option which uses a number of different device types of specialized cooking devices in accordance with the given flexibility-level constraint. In the example of FIG. 1, it is assumed that the program analyzer 120 identifies execution options which can be enabled by two different CA subsets of the registered CAs. The first subset S1 includes the multifunction CA 210 (DT1) and the oven 230 (DT3), whereas the second subset S2, in addition to CA 210, 230, further includes CA 220 (DT2). It is assumed in the example that the execution option enabled by S2 allows parallel execution of some recipe instructions by using CA 210 and CA 220 in parallel, whereas S1 performs these recipe instructions sequentially on CA 210. As a consequence, the execution option enabled by S2 allows a faster food preparation than the execution option S1. Assuming now that parallelization constraint of the user is a time constraint as which indicates that the user prefers a “long” or “slow” cooking experience, then the selector 122 identifies the best match with this parallelization constraint for execution option S1 as it is associated with the longest preparation time. Assuming that the user is under time pressure and inputs a desired parallelization constraint “no longer than 20 min”, and further assuming that the execution time by S1 is 21 min and the execution time by S2 is 17 min, then the selector 122 would have selected the parallel execution option associated with S2. In another example, the parallelization constraint 11 may be a support-level constraint indicating the user's desire to maximize the degree of cooking automation by “minimizing the number of manual steps”. Assuming that the execution option using S1 requires a plurality of manual cleaning steps of the bowl or vessel (because the respective cooking steps are all executed by CA 210), and that the execution option using S2 allows to avoid such manual cleaning steps by using two different bowls 215, 225, the selector 122 will select the execution option enabled by S2 which has the best match with the constraint “minimizing the number of manual steps” in accordance with the respective matching rule. In another example, the parallelization constraint 11 may be a flexibility-level constraint indicating the user's desire to always use as much specialized cooking apparatuses as possible. The use of specialized CAs may improve the quality of the cooking result for certain cooking functions. For example, when the recipe program includes instructions for a cooking step “searing a piece of meat”, the corresponding device type annotations may provide for optional use of a standard multi-function cooking apparatus where the searing is done in the heated CA bowl. In an alternative execution option, the use of an oven with a high-temperature grill cooking function for searing is enabled with a corresponding device type annotation. A third alternative option may be the use of an oven with an automatic steam function typically leads to a crispy crust of the meat. In this example, two of the alternatives make use of a specialized cooking apparatus. For example, a flexibility-level constraint in the user profile may indicate a preference of the user for crispy food. In this case, the execution option using the oven with the automatic steam function would be preferred. In general, flexibility-level annotations may be associated with alternative program listings making use of the respective specialized cooking apparatuses, or they may be associated with the device types of such specialized cooking devices. In both cases, the selector can select an appropriate execution option in accordance with the received parallelization constraints. In the example of FIG. 1, the selected execution option (enabled by S1) is then deployed to the respective CAs 210, 230. In one implementation, the respective partitioning into partition P1 with recipe instructions of the recipe program 281 to be executed by the execution module 211 of CA 210, and partition P3 with recipe instructions of the recipe program 281 to be executed by the execution module 231 of CA 230 is already predefined with corresponding alternative program listings in the recipe program file 281. The recipe instruction in partition P1 may be directly provided 1500 by the deployment module 130 to the execution module 211 via machine-to-machine communication. P3 may be provided 1500 as deployment instructions to the user 1 (via the user interface) to instruct the user on how to operate the oven 230. Once the user has entered the corresponding recipe instruction as input for the CA 230, the execution module 231 executes said instructions of P3 and CA 230 performs the corresponding cooking function 232. In an alternative implementation, the recipe program file may only include a generic recipe program with all cooking steps to be performed for preparing the food product, and annotations (specifying usable device types and corresponding execution times for each recipe instructions) which implicitly specify all possible execution options. In this implementation, the program analyzer 124 has a partitioning module 124 which uses predefined partitioning rules 150 to generate deployable partitions P1, P3 in accordance with the selected execution option. A detailed recipe example is given further down below which demonstrates dynamic identification of execution options and the corresponding partitioning of the recipe program. FIG. 3A illustrates an example of the first implementation of the recipe program file 281, with the recipe program file already including alternative program listings PL1 to PL4 associated with respective execution options. In the example, each of the program listings PL1 to PL4 includes the recipe instructions RI1 to RI5 and a device type of a device which is suitable executed the respective instructions with an associated execution time noted in brackets. It is to be noted that in a real-world recipe program file, the various program listings can differ with regard to the recipe instructions. For example, a program listing associated with a sequential execution option may include instructions related to the cleaning of a bowl/vessel. Such activities may not be necessary when using a parallel execution option in which case the respective recipe instructions may be omitted in the respective program listing. Each program listing has a parallelization constraint annotation which, in this example, corresponds to a time constraint. PL1 represents an execution option for slow cooking S. PL2 represents an execution option for fast cooking F. PL3 represents an execution option for relaxed cooking R. PL4 represents an execution option for very fast cooking VF. It is to be noted that, in this implementation, the time constraint which may be received as a user input or retrieved from the user profile does not necessarily need to include an absolute time interval specifying the duration of the entire food processing but can relate to relative terms such as slow, fast, etc., because the execution options are directly annotated with such relative terms. In the example, PL1 is the default listing where the recipe instructions RI1 to RI4 can be executed by a single cooking apparatus of device type DT1. Only RI5 is to be executed by another apparatus of device type DT3 with an execution time T5. That is, PL1 denotes an entirely sequential recipe execution for the recipe instructions RI1 to RI4. Only for illustration purposes, alternative options for executing RI3 and RI4 are denoted in PL1 in italics separated by slashes in the column “Device type (Time)”. In a real program listing of PL1, the alternative options may not be included in this implementation. The alternative options illustrated that RI3 can also be executed by an apparatus of device type DT2 with an execution time T3′, or by an apparatus of device type DT4 with an execution time T3″. RI4 can also be executed by an apparatus of device type DT2 with an execution time T4′. PL2 is a program listing which differs from PL1 in that the recipe instructions RI3, RI4 are deployed to the DT2 apparatus. The associated execution time T3′+T4′ is supposed to be different from DT1 execution time T3+T4. PL2 is annotated as fast F execution option because RI3 and RI4 can be executed in parallel on the two devices. That is, the overall execution time of the recipe instructions RI1 to RI4 is determined by the longer time interval of T1+T2 and T3′+T4′. In any case, the execution option PL2 I supposed to require a shorter execution time for those instructions than T1+T2+T3+T4 of PL1. PL3 is a program listing which differs from PL1 in that only recipe instruction RI3 is deployed to the DT4 apparatus. The associated execution time T3″ is supposed to be different from DT1 execution time T3. PL3 is annotated as relaxed R execution option because RI3 can be executed in parallel on two devices but most of the cooking RI1, RI2, RI4 is still being executed on the same device in a sequential manner. The use of DT4 for RI3 may be motivated by an elimination of a cleaning activity which makes the cooking process more convenient for the user. However, it is assumed that the gain in overall food processing time is less than for PL2 which reaches a higher degree of parallelization. PL4 is a program listing which differs from PL1 in that recipe instruction RI3 is deployed to the DT4 apparatus and RI4 is deployed to the DT2 apparatus. In this example, it is assumed that the activities RI3 and RI4 can also be executed in parallel. That is, PL4 uses the highest degree of parallelization amongst the provided execution options. Assuming that T3′+T4′>T1+T2 and T3″<T1+T2 and T4′<T1+T2, then PL4 with the highest degree of parallelization leads to an even shorter food processing time for RI1 to RI4 than PL2 for which reason it is annotated as very fast VF. In this example, with parallelization constraint annotations directly corresponding to respective parallelization constraints given in the user profiles (or as user input), the matching rules used by the selector can simply check the equality of the given parallelization constraint with the respective annotations of the alternative program listings (execution options) and select the corresponding execution option for deployment. If the user would enter a maximum time for the food processing as parallelization constraint, the selector can compare the cumulated execution times of RI1 to RI5 while taking into account time gains achieved by using CAs in parallel and select the appropriate execution option in accordance with the matching rules (e.g., the execution option with an execution time which is shorter than and comes closest to the given time constraint). For this purpose, the program analyzer may use predefined mappings which can relate a user input to a respective matching rule. For example, providing a maximum time maps to the matching rule to select the execution option with an execution time which is shorter than and comes closest to the given time constraint. Other mappings may be defined by a skilled person to meet the individual preferences of the user. It is to be noted that each alternative program listing may have an annotation in each dimension of the pallelization constraint. In other words, each program listing can have multiple annotations with one each dimension: a time constraint, a support-level constraint, and a flexibility-level constraint. FIG. 3B illustrates the second implementation of a recipe program file 282 with dynamic construction of execution options. In this second implementation, the program file includes a generic program listing PLg which provides a generic description of all potential execution options for this recipe program. Again, the example program 282 includes five recipe instructions RI1 to RI5. For each recipe instruction, the column “Device type (Time)” includes device type annotations specifying all execution options for the recipe instruction with the respective execution times. In this regard, the example PLg corresponds to the execution options explained in FIG. 3A for PL1 when including the options in italics. Further, the generic program listing PLg indicates groupings G1, G2, G3, G4 of recipe instructions, with the recipe instructions of a particular grouping to be executed by one cooking apparatus in accordance with the corresponding device type annotations DT1, DT2, DT3. In other words, recipe instructions assigned to the same group cannot be separated but need to executed sequentially on the same CA. For PLg, RI1 and RI2 are assigned to G1 indicating that both steps need to be sequentially executed on a DT1 CA. However, each of the other recipe instructions is assigned to another group G2, G3, G4. This indicates that each of the steps can be independently deployed to any of the device types as annotated, and can be executed in parallel when using different CAs in parallel. RI3 can be deployed to a DT1 CA, DT2 CA or DT4 CA. When deployed to a DT2 CA or DT4 CA it can be executed in parallel to RI1, RI2. RI4 can be deployed to a DT1 CA and a DT2 CA. When deployed to a DT2 CA it can be executed in parallel to RI1, RI2, and in parallel to RI3 in case RI3 is deployed to a DT4 CA. That is, the generic program listing PLg of the second implementation includes the information which is needed to determine different execution options with different levels of parallelization. In such a generic program listing, the program analyzer can identify execution options, such as EO1, EO2, for the recipe program file in accordance with the annotations of the recipe instructions. For example, if the parallelization constraint is a time constraint, the program analyzer can construct all possible execution options for PLg, compute the total food processing time for each of the execution options, and finally select the execution option which has the best match with the time constraint in accordance with the matching rules. In the example of FIG. 3B, two of the determined execution options are shown by example (EO1, EO2). EO1 corresponds to PL1 of FIG. 3A, and EO2 corresponds to PL2 of FIG. 3B. The overall processing time for the sequential EO1 (RI1 to RI4 executed by DT1 CA) is TEO1=T1+T2+T3+T4+T5. For EO2, the program analyzer determines that RI3, RI4 can be executed in parallel with RI1, RI2 because they do not belong to the same grouping. Therefore, the overall processing time for the parallel EO2 is TEO2=max((T1+T2),(T3′+T4′))+T5. The same computation exercise is performed for all other possible execution options and finally the selector selects the best matching execution option in accordance with the matching rules. With regard to a support-level constraint, the program analyzer compares the degree of parallelization (also referred to as the degree of automation) of the determined execution options and selects the execution option with the best match with the given support-level constraint. The degree of parallelization corresponds to the depth of parallelization in terms of parallel use of multiple CAs. For example, EO1 performs RI1 to RI4 on a DT1 CA and can perform RI5 in parallel on a DT3 CA. That is, the degree of parallelization for EO1 is 2 (using two CAs in parallel). For EO2, the DT1 CA performs RI1, R2 in parallel with the DT2 CA (performing RI3, RI4), and in parallel with the DT3 CA (performing RI5). That is, the degree of parallelization for EO2 is 3 (using three CAs in parallel). The execution option corresponding do PL4 of FIG. 3A has a degree of parallelization of 4 (using four CAs in parallel). Based on a flexibility-level constraint, the system can adjust the level of specialized cooking apparatuses which are used in parallel to a multi-function cooking apparatus. In this example, it is assumed that a flexibility constraint “crispy” is retrieved from the user profile. Assuming further that DT1 specifies a multi-function cooking apparatus, DT2 specifies a support apparatus for the DT1 CA (e.g., with reduced functional scope but compatibility as described earlier), DT3 specifies an oven and DT4 specifies a pan in combination with an induction stove. Assuming further that RI4 is a recipe instruction for frying a piece of meat, and that the DT4 CA is flagged in the recipe program file as a specialized cooking apparatus with regard to the frying function to deliver a “crispy” frying result. The reason may be that a more “crispy” frying result can be achieved with the specialized DT4 CA than with the multi-function DT2 CA. In this case, the execution options which correspond to PL3 and PL4 are ranked with a higher flexibility-level than the execution options corresponding to PL1 and PL2 of FIG. 3A. If the oven (DT3) and the pan (DT4) contribute one count to the flexibility-level of an execution option, then PL1 and PL2 would result in a flexibility-level of 1 whereas PL3 and PL4 result in a flexibility-level of 2. In general, recipe instructions which can use alternative cooking apparatuses for execution may be annotated with flexibility-level annotations with regard to respective specialized cooking apparatuses. If there is a match of such an annotation with a corresponding user parallelization constraint, the associated execution options which make use of the specialized cooking apparatus is ranked with a higher flexibility score (flexibility-level). In the above example, the parallelization constraint “crispy” is a flexibility-level constraint that matches the execution options PL3 and PL4. The selector has now to decide whether to deploy execution option PL3 or PL4 which have the same flexibility score. The selector may simply use the first execution option which provides a best match. In a more sophisticated solution, a user may define primary and secondary parallelization constraints. For example, the primary constraint may be the flexibility-level constraint and the secondary constraint may be the time constraint. If the secondary constraint specifies that the user prefers a slow cooking procedure, then the selector would evaluate the PL3 and PL4 options with regard to the time constraint to make the final selection. The execution option with the longer food processing time would finally be selected. FIG. 4 illustrates a recipe program file 400 with two examples of alternative program listing PL41, PL42 for preparing “chicken pizzaiola with celeriac-potato puree”. In the example, PL41 uses a DT1 CA and, in parallel, a DT3 CA. PL42 has a higher degree of parallelization because it further uses a DT2 CA
{'application_number': '<application-reference appl-type="utility">\n<document-id>\n<country>US</country>\n<doc-number>17655104</doc-number>\n<date>20220316</date>\n</document-id>\n</application-reference>', 'publication_number': '<publication-reference>\n<document-id>\n<country>US</country>\n<doc-number>20220296038</doc-number>\n<kind>A1</kind>\n<date>20220922</date>\n</document-id>\n</publication-reference>', 'source_file': './application/2022/ipa220922.xml', 'source_data': 'USPTO-Application'}