Food Passports and Intelligent Food Recipes: The Data-Oriented Way of Producing Food

Abstract

This paper discusses a Multiagent System architecture and its supporting concepts and technical implementation for food-producing systems. The Food and Beverages industry is in dire need of embracing more advanced industrial digitization practices to be able to meet immediate sustainability requirements. One such challenge is improving and optimizing resource utilization. A more rationalized use of raw materials, production processes and machinery is a key aspect of the latter. At the same time, food is still produced, in many instances, in a very traditional way, particularly when it comes to ingredient selection. The architecture introduced in this paper has the ambition of articulating the supply and demand of food products based in the technical characteristics of food (e.g., composition, nutritional content and value, processing efficiency, and taste profiles) instead of the more traditional characteristics. To that end, the paper introduces, among other key concepts, the notion of the Digital Food Identity Card as an active digital document that stores such technical information and the notion of Dynamic Recipe as an active software entity with the dynamic capability of adjusting production parameters in a recipe to market conditions, as well as coordinating the resources included in the execution of a industrial food recipe. Both concepts are modeled as agents and part of the proposed architecture. Finally, the paper provides a formal grammar for a domain specific language, that can be used by human specialists to define a dynamic recipe and be simultaneously interpreted by Dynamic Recipe Agents to enact the behaviours previously described. The domain specific language is an integral part of the architecture, together with the agent-based formulation, and an important link in creating an effectively data-oriented way of articulating different stake-holder concerns. The proposed solution is informed by requirements elicited within domain experts and sustainability targets that food-producing companies currently must adhere to.

1. Introduction

Shockingly enough, 20% of the food produced in Europe has been estimated to be wasted in 2016 [1]. In Sweden, where food losses are comprehensively tracked along the entire food chain, it is estimated that about 50% of the waste occurs in the supply chain (pre-harvest losses, food intended as human consumption that does not progress as such and wasted food due to logistic or fabrication issues) [2].

These challenges occur at the core of the Food and Beverages (F&B) industry, which is in dire need of revamping its way of operating.Data from a recent inquiry from the Swedish Food Federation show that the F&B sector is as follows [3]:

• Recognizes the immediate need for further automating their processes;
• Meets increasingly demanding sustainability targets while dealing with increased costs;
• Must renovate their buildings and equipment;
• Must attain a more energy- and resource-efficient production.

While the F&B sector has not been oblivious to advanced digitization, it has been relatively late in embracing advanced industrial digitization practices when compared to other sectors. There is still room and need for both academic and industrial contributions.

F&B supply chain management and control is currently one of the main hot research topics. In that context, accurate and trustful product identification, the real-time monitoring of products during transport, transformation and storage and general traceability build a very compelling case for the usage of Ledger-based technologies in connection with Smart Contracts [4].

The potential to couple Digital Twin (DT) models with the aforementioned technologies and their effects is very high, and the concept can be seen as a placeholder for data that enable the optimization of production planning, allow predictive maintenance, support product development, enhance food safety and generally improve collaboration between different stakeholders in the sector [5].

Definition 1. 

Digital Twin: There are many nuanced definitions of DT. Usually, they will generally refer to a virtual model of a physical system. The model is in synchrony with the system, and real-time data are exchanged bidirectionally between the two [6,7]. Model data can then be used to influence the real system by improving its operations through the application of optimization, simulation, and decision-making techniques [7], as well as the direct control of system parameters [6].

However, a DT is only as good as the models it contains, based on the data it has access to and its capabilities to process it. Here, a complication arises because many different models are both possible and needed in the F&B sector. This includes a combination of statistical, mechanistic and data-based models and their associated sensors [8,9].

Additionally, F&B production systems and supply chains include specific implementation challenges resulting from societal and ethical questions that easily exceed in complexity those asked with respect to the application of emerging digitization technologies in other domains. Such challenges can be seen as pertaining to the following dimensions [10]:

• Resources, including the deployment of the infrastructure required to acquire, process and store data and models;
• Representations, including distinguishing appropriate and inappropriate ethical and technical representations of the world;
• Actions, including understanding how the previous two dimensions can support and inform ethically aligned decision-making in the sector.

The Resources, Representations and Actions framework is, therefore, of extremely high relevance in F&B systems, not exclusively but among other aspects because of the following:

• The ability to deploy the infrastructure required to support certain DT models often does not scale well beyond laboratory conditions;
• In many European countries, the F&B sector is constituted mainly by small- or medium-sized companies that often lack the know-how or the economical resources to deploy an advanced digitization infrastructure;
• Agrifood/F&B systems must handle living organisms and perishable goods as well as engineering artifacts, including machinery, networks and data;
• Insufficiently supported decisions due to incomplete representations and non-transparent information processing and automation may have devastating effects in society.

The drivers for dramatically increasing the efficiency of food systems are, therefore, known. However, as mentioned, in the solution scope of the problem, the adoption of advanced digitalization solutions remains low.

The authors set forth the hypothesis that Multiagent Systems (MASs) are a key concept in the solution space for several reasons. Before one delves into adequacy of MASs in the design, implementation and deployment of food systems, and in the interest of an wider audience, one must first define the concept of an Industrial Agent (IA):

Definition 2. 

An Industrial Agent is an autonomous and self-contained cyber–physical entity that intelligently represents and manages the functionality of one or more industrial assets that are, permanently or temporarily, physically coupled with the purpose of executing the functions and processes made available by the Industrial Agent. The cyber part of an Industrial Agent integrates various software solutions that collectively address the representational, management, control, and execution concerns of the physical part in an ideally standardized way. The physical part of the Industrial Agent includes all the physical components and computational platforms required for the Industrial Agent to carry out the function(s) it was designed for [11,12].

In an industrial context, a MAS is a collection of collaboratively interacting IAs. Industrial MAS (IMAS), as a technical solution for controlling and managing complex engineered systems [13], largely precedes the concept of DT, currently being advocated in the F&B sector.

IMASs have found applications in many industrial and societal domains: Logistics, Energy and Smart Grids, Building and Home Automation, Traffic Control, Production, etc. [14,15]. Particularly, within the Production domain, discrete part manufacturing and assembly are sectors of intense MAS-based developments, with many pioneering application cases, for example, in the Automotive domain [14,15]. Process industries have also been frequently studied, albeit to a lesser extent [14,15].

Interestingly enough, the F&B sector has almost entirely escaped as an application case for MAS. To the best of the authors’ knowledge, the work discussed in this paper is most likely the first MAS Architecture dedicated to food-processing industrial systems.

MASs are highly relevant for the F&B for several reasons:

• As a concept, MAS provides a framework for articulating, from a modeling and implementation perspective: resources, their representation and actions. Existing technical MAS software platforms provide support for structured and scalable agent-to-agent interactions, agent representation and actions [16]. This is relevant for the digitalization of the F&B industry because, as discussed before, food production systems require the seamless integration of many different models both for the food produced, in its different stages of production, as well as for the production system and its resources.
• MAS-based systems can scale gracefully and organically, allowing the quick and easy integration of additional agents abstracting new concerns, stakeholders, representations, algorithms, etc. The previous means that the MAS in the F&B industry can provide an elegant solution for creating and transforming data flows, as well as composing such flows through the addition/removal of agents without disrupting the behavior of the system. Data collection and processing in today’s food production system occurs in a rather monolithic way that makes it difficult to progressively and on demand add new data transformations, analysis, or even data-based decision-making algorithms.
• MASs have been discussed as the base for implementing DTs (which are an emerging digital representation of assets in the F&B sector). This means that many of the innovative ideas currently under discussion within the sector could be seamlessly integrated under a MAS framework.

With the discussion above in mind, this paper describes what the authors believe is one of the first MAS-based architectures and solutions for food systems, henceforward designated by the AROMA platform. Within the scope just discussed, this paper concentrates on deploying MAS-based solutions to solve specific industry problems. In particular, the proposed work addresses the following:

• There is a need to more formally describe industrial food production recipes, ingredients and raw materials with the purpose of creating a data-link between the ingredients of an industrial recipe and the ingredients available in the market at any point in time. By doing so, it is possible to use autonomous agents to select the most appropriate ingredients, including replacement ingredients, for a specific recipe, including a variety of metric (cost, environmental impact, consumer preferences, etc.).
• There is a need to manage recipes and food descriptions autonomously. Food products are perishable, and their properties change as a function of their handling. Today, food products are documented textually, in paper or digital format, but their state is not dynamically updated. By using autonomous agents in such a representation, the proposed solution opens the door for active food information management.
• There is a need to increasingly incorporate secondary production flows into high-value products. The F&B industry generates today a lot of waste in side flows with a very high potential for incorporation in high-value products. Solving such a problem simultaneously eliminates waste and generates value.

The work, therefore, reports on the preliminary findings of the AROMA Project Consortium [17], which combines a multidisciplinary team of academic and industrial experts currently working on the development of the platform introduced in this paper. The authors stress that, at this stage, and given the novelty of the approach, the findings are reported at the proof-of-concept level. On a Technology Readiness Level (TRL) scale, the authors position the maturity of the work described in between levels 3 and 4, to be progressively increased throughout the project. The previous TRL positioning correlates greatly with the key contributions reported in the manuscript:

• A preliminary MAS-based architecture for transforming industrial food production recipes into active entities that can dynamically procure ingredients;
• A Domain Specific Language (DSL) that enables the specification of such recipes in a format that is both human- and machine-actionable;
• A proof-of-concept implementation of the preliminary architecture and DSL that demonstrates how a human-written recipe can be used by intelligent agents in a MAS context to address the behavior specified in the first bullet.

While the TRL of some of the supporting technologies and concepts is quite high, the innovation of the proposed solution lies in the multidisciplinary integration of many of the challenges and potential solutions discussed in this paper. At an aggregated level, proof of concept is still necessary to inform the further developments and to encourage the F&B industry to pursue different production system development directions.

In the previous context, the main development direction of the AROMA platform is supported by two key concepts:

Definition 3. 

Digital Food Identity Card (DFIC): an active digital document that models and dynamically tracks the properties of a food it describes along the food chain.

Definition 4. 

Dynamic Recipe (DR) working definition: an active software entity that, using the information in the the DFIC, carries out, autonomously, several important actions in the AROMA platform. Among these, one may mention the following because they are described in a more detailed fashion in this article: the dynamic procurement of foods that are incorporated as ingredients in other foods, and the execution of the recipe by synchronizing the actions of the different entities involved in the food production process described in the recipe. Furthermore, dynamic recipes are defined in both a human- and machine-readable format and, unlike conventional recipes, have built-in rules and algorithms that allow them to self-adjust to the ingredients available. The former allows dynamic recipes to, at any point time, procure the most favorable ingredients according to particular business metrics.

In both definitions, food is understood in very general terms. First and foremost, it is understood as a substance of nutritional value. However, secondarily, additives, with or without nutritional value, that change the properties of a specific food and are used as an ingredient in its composition are also considered food in the definitions above.

The general use case for the AROMA platform is as follows (Figure 1). Companies register, using DFICs, the technical properties of the products they provide and the properties of the products they require in their own products.

The DFIC is then used by DRs to dynamically connect stakeholders based on the supply demand of foods and raw materials with certain properties.

The data in the DFIC are available to all the stakeholders in the platform (including final consumers), promoting traceability and transparency, but also allowing stakeholders to feedback information on specific products. Such feedback may then be used to tune the DRs.

Companies can therefore create DRs that fulfill their business needs while self-adjusting to variable market conditions, for example, by balancing protein of animal and vegetable origins on their products.

The main contributions of this work are therefore as follows. It is, as mentioned, a first and much-needed and justified incursion of IMAS in the F&B sector with the purpose of boosting production sustainability. Additionally, the work concretely articulates pressing industry requirements with architectures and supporting technical solutions. In this context, the paper contributes a MAS architecture for the F&B sector and a formal grammar specification for a Domain Specific Language (DSL) for defining and executing DRs. All these contributions are tested in a mock-up software implementation that demonstrates the technical interplay and consequences of the concepts discussed and introduced in the paper.

The subsequent details are organized as follows: Section 2 describes the methodological approach used for eliciting the functional requirements that the AROMA platform should fulfill, and provides an overview of the AROMA architecture; Section 3 details the preliminary agent-based implementation directions and components in the AROMA platform; Section 4 discusses the obtained results, lessons learned from the mock-up implementation and future research directions and challenges; finally, Section 5 wraps and summarizes the main findings of the work.

2. Methodological Approach and Reference Architecture

2.1. Methods

The methodological approach pursued in the work described in this manuscript is characterized by a conventional Requirements Engineering (RE) procedure whereby requirements are systematically defined and managed [18,19].

Definition 5. 

A requirement is as follows [18]:

• A condition or capability needed by a user to solve a problem or achieve an objective;
• A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents;
• A documented representation of a condition or capability as in the two previous points.

Many different sources can be considered for eliciting requirements [19]: documents, systems in operation, persons or organizations that have a direct or indirect influence on a system’s requirements (usually referred to as stakeholders), etc. [18].

Food systems have a very large number of stakeholders. In this preliminary presentation of the AROMA platform, the number of stakeholders considered is limited to the ones that are more directly related to the development of food recipes and the ingredient procurement process for a specific industrial food recipe. In the F&B sector, such stakeholders may be deployed in different roles depending on the organization (chefs, procurement specialists, business owners, food engineers, production engineers, plant operators, etc.). The authors therefore choose to stereotype these two types of stakeholders into the following fictional groups: Recipe Preparator and Procurement Specialist. The latter is usually responsible for procuring ingredients and ensuring their delivery in the needed quantities, costs and time frames. The former is responsible for the development of new food products or the adjustment of existing ones as well as guaranteeing the quality and production ability of the products at the desired scale.

These two stereotyped stakeholder groups have been mapped to different real individuals and experts (with academic, industry and business backgrounds) from the partners participating in the AROMA project. These individuals are, together with the specialized literature, the main sources of requirements for the AROMA platform.

Requirements are specified according to the syntax proposed in [19], whereby a requirement takes the form of Object + Degree of Obligation + Function and where the degree of obligation may take one of the following values:

• Shall—the object must implement the function attributed to it.
• Should—the object will, if possible, implement the function attributed to it.
• Will—the object may come to implement the function attributed to it at some point in the future.

The objects and functions are, in the scope of this manuscript, those included in the AROMA platform (Figure 1) and use case specified in Section 1.

The requirements are also formulated following the Axiomatic Design Independence Axiom which postulates that an optimal design always maintains the independence of Functional Requirements [20].

The above-mentioned stakeholder groups have been informally interviewed. The ones directly involved in the AROMA project’s developments have used their technical expertise, together with state-of-the-art literature, to specify the set of requirements, justified next. These requirements are also the base for the technical developments reported in this manuscript. There are a number of reasons for using informal interviews as the main method for eliciting requirements from different field experts:

• The project is heavily multidisciplinary and there was a risk that a more formal and rigid approach to interviewing experts would not meet them at the correct level and would not bring out the relevant operational details needed to establish the technical requirements.
• At this early stage of the project, and given its nature, it would not be possible to develop a mature questionnaire.
• The process of collecting requirements is ongoing, and new requirements are elicited as the project progresses. Some will build upon existing requirements, and others may even eliminate them.

The enumeration of requirements, which follows, is not exhaustive and should instead be seen as a set of minimum requirements to be fulfilled and complemented over time. It is also important to stress that the requirements collected pertain to the process of technically developing food identity cards and dynamic recipes. It is not the intention of the paper to elicit requirements for a full-fledged digital twin model for food-producing systems. This would be an arguably impossible task. The approach followed is therefore to concentrate on key aspects, which may later become incorporated in such full-fledged platforms.

Furthermore, the elicitation of requirements leading to the concepts and need for food identity cards and dynamic recipes occurred independently of the project whose results are discussed in this paper. For example, the need for product identity cards is being pushed by incoming European legislation. Likewise, the need for dynamic recipes is driven by other external factors (including legislation), that put additional pressure on food-producing companies to develop more sustainable production.

The requirements below are elicited already in that pre-existing context and are expressed towards the technical objectives of the project.

2.1.1. Digital Food Identity Card Requirements

Requirement 1. 

The DFIC shall include technical food information with sufficient detail to support the matching of foods at different levels of specification.

Food is, in many production instances, selected based on more traditional properties: color, flavor, and the perception that consumers have of it. However, the realization of dynamic recipes requires a level of technical detail beyond the more traditional properties. From Definition 4, it is clear that a dynamic recipe will adjust its ingredients dynamically. This literally means that a DFIC must be able to support “comparing apples and oranges" when the property of interest within these ingredients, for the success of the recipe, is a type of fruit fiber that they may have in common.The DFIC must therefore include information with a relatively fine level of granularity regarding specification.

Requirement 2. 

The DFIC shall include technical food information with sufficient detail to enable the comparison of different foods based on a technical property of interest.

This requirement connects to the previous one. Once the DFIC includes a level of technical description that is useful to understand potential replaceable ingredients in a recipe, it must also include additional information to render them comparable. For example, it must include the units in which the technical food property is expressed, the language in which the food is described, etc.

To reinforce the significance of Requirements 1 and 2, it is worth further analyzing one of the potential dynamic recipes that is currently being investigated under the AROMA project: the development of a protein patty. The general idea is to develop a dynamic recipe for a patty that can self-adjust to incorporate a variable amount of protein coming from other sources, namely, apple pulp and peas, in addition to meat-based protein.

One of the main challenges is that meat proteins generally contribute to the appearance, textural and functional properties of a meat-based product [21]. Mimicking meat protein characteristics by any other source of protein is difficult, as meat brings to a product characteristics that are appreciated by consumers. For example, when discussing products developed with red meat, texture and taste are highly important, and using alternative proteins to create meat analogues is very challenging. Different ingredients have been proposed by the industry and academia to create meat analogues. Among them are many plant proteins based on cereals, seed oils, legumes, with a prevalence of soy and pea proteins. Such sources present the appropriate functional properties (e.g., water and oil absorption capacity and emulsification) and can be used to create various meat substitutes [22,23].

Considering the previous, the quality of a patty can be measured using physico-chemical and sensory parameters. These parameters include pH, texture, color, cooking loss, water retention, homogeneity, appearance, taste and flavor as well as nutritional values. Ultimately, these and many other properties of interest need to find their way into the DFIC. These must also include the thermal properties of food that largely influence the methods that can be used to process it [24].

Requirement 3. 

The DFIC shall contain references to the DFICs of other foods that have been used in producing the food it describes.

Foods are available in different stages of processing. More highly processed foods will naturally incorporate an equally higher amount of ingredients, many of which will be processed foods themselves. For the sake of information transparency and traceability but also to understand the impact of using one specific food as an ingredient in one recipe, it is important to link the DFIC of processed foods to the DFICs of its ingredients.

Requirement 4. 

The DFIC should include information about the energy efficiency of processing the food it describes using different processes.

As mentioned before, different foods will have different thermal properties [25], which directly influences the amount of energy that needs to be utilized to process them. Energy efficiency has been pin-pointed has a priority area for the industry [3] and, as such, the DFIC should, whenever possible, include such data.

Requirement 5. 

The DFIC should include information about the processes that were utilized to prepare the food it describes as well as the relation of those processes with the other foods mentioned in the DFICs from Requirement 4.

This requirement is directly connected to the previous one, whereby transparency but also the correct calculation of aggregated sustainability metrics (e.g., energy efficiency) for the whole product requires that measurable process information is included.

Requirement 6. 

The DFIC should have the ability to track the state of the food it describes along several stages of that food’s handling and usage: production, transportation, storage, sale and consumption.

Unlike other products, a large number of food products are perishable. Variations in their handling may decisively affect their properties to different degrees. The information in the DFIC must therefore be able to track and monitor such deviations as well as adjusting the technical products of the described food accordingly.

Requirement 7. 

The DFIC will update its information autonomously by directly collecting data from different systems whereby the food it describes is being handled.

To fully fulfill Requirement 6, the DFIC needs, ideally, to have access to relevant system and sensorial data; otherwise, its abilities to dynamically adjust food data are very limited.

2.1.2. Dynamic Recipe Requirements

Requirement 8. 

A DR shall be writable, readable and interpretable both by humans and machines.

Dynamic recipes will, due to their development complexity, be mainly developed by food experts. The majority of the food experts interviewed/consulted, and stereotyped in the Food Preparator stakeholder group mentioned that they do not posses such in-depth programming experience to be able to specify a recipe in a conventional programming language. At the same time, to safeguard the adequate behavior of the system, recipes must conform to a machine-readable and -writable format so that they can be instantiated as active software entities.

Requirement 9. 

A DR shall support a multitude of metrics used in its ingredient selection procedure.

Different companies may equate the flexibility provided by dynamic recipes differently and should be able to use different metrics to guide the behavior of recipes.

Requirement 10. 

A DR, as an active entity in a system, shall automate and optimize the procurement and usage of food and resources without compromising the legal, ethical and business values of the company using it.

This is a general requirement for all active software entities in a company that may legally act on behalf of said company.

Collectively, these 10 requirements motivate the development of specific design properties and/or features of the AROMA platform.

2.2. Architecture

This contribution focuses mainly on the agent-based architecture required to support the operation of the Dynamic Recipes. The definition of the dynamic behavior of the DFIC is still under development and cannot be demonstrated yet. However, a sketch of some the main components of the model can be found in Figure 2.

One of the first aspects to consider when developing the DFIC is that quite a lot of information is already collected today regarding food. For example, the Global Trade Item Number (GTIN) is already nowadays used to identify products and manufacturers, to support traceability, etc. Foods are also subject to different markings (eco labels, nutritional markings, certifications, etc.) The DFIC shall not replicate those but rather link to and complement them. In this light, the preliminary model from Figure 2 includes open placeholders for marking and certifications and further defines that one DFIC describes one food but that a food is an aggregation of ingredients, transformed by one dynamic recipe. An ingredient is also a food, and therefore will, recursively, also have its own DFIC.Foods have one or many technical properties of interest. A food property is simply described as the name of the property, its value and the unit in which it is expressed. Food properties are therefore currently defined as generic placeholders for any conceivable type of information. However, such information will inevitably have to conform to a specific ontology to adequately support Requirements 1 and 2. This preliminary model seeks to support many of the mandatory DFIC requirements that have been previously mentioned. However, the active part of the DFIC, related to the implementation of Requirements 6 and 7 needs to be further investigated with respect to its feasibility in real operational scenarios.

Figure 3 shows a structural view of the MAS-based architecture, which was preliminarily implemented and tested as described in the next session. The general development direction behind the architecture is not fundamentally different from the Holonic and MAS-based architectures derived from the PROSA [26] and COBASA [27] reference architectures and follows variations of well-documented agent-based interaction patterns [28]. In particular, as per the model in Figure 3, a dynamic recipe is first and foremost a digital document that can be written and read by humans and machines and is actively managed by one Dynamic Recipe Agent (DRA). The DRA then has a dual role. On the one hand, by interpreting the recipe, it negotiates with available Supplier Agents (SAs) in order to procure the recipe’s ingredients. On the other hand, as soon as the ingredient supply has been guaranteed, it operates as an order/coalition leader agent (respectively in PROSA or COBASA) and orchestrates the execution of the recipe by allocating tasks to Resource Agents (RAs) and monitoring the execution of such tasks.

The aforementioned architecture directly addresses the general use case defined in Section 1 and more concretely provides a solid base for addressing the requirements detailed earlier. The architecture, however, does not enforce specific implementation directions and the efficiency of many of the discussed functions is implementation-dependent.

In the next section, and as result of this work, a mock-up software implementation and exemplary application case are detailed as a proof of concept of the feasibility of the proposed architecture and development directions but also as an example of the key technologies required for its realization. Section 3 provides, therefore, additional technological details that are crucial for addressing the specific requirements.

3. Results

3.1. Defining Human- and Machine-Interpretable Dynamic Recipes

To illustrate the realization of the architecture, one uses a mock-up implementation of the proposed MAS-based architecture and a fictitious and simplified application case. The mock-up implementation is publicly available in https://github.com/luferi/AROMA_Project (accessed on 1 January 2024).

In the distributed code, the use case is simple: a Food Preparator wishes to develop a dynamic recipe for sugary water. The recipe should specify the ingredients of the recipe, the preferred ratios of said ingredients, and the resources included in the execution of the recipe but also the orchestration of said resources. All of the above must be specified in a machine-interpretable format; otherwise, the recipe becomes unusable from a DRA perspective. As discussed before, Food Preparators should not be forced into learning a new programming language but at the same timeneed support in specifying all of the above in a consistent and machine-validatable way.

An obvious solution is the development of a Domain Specific Language (DSL). A first proposal of the AROMA DSL is given in the grammar below (see Listing 1, where, for the sake of simplicity, the lexer rules are omitted). The grammar uses the ANTLR4 [29,30] grammar notation that is a variation of the EBNF form. A few selected production rules are highlighted and discussed next due to their relevance to the requirements discussed.

Listing 1. Production Rules of the AROMA DSL.

The production rule recipe (line 1) is the starting rule of the AROMA DSL. A recipe is therefore defined by a the reserved work Recipe followed by the recipe’s identifier, an optional description, a list of ingredients, a list of resources, and the flow of the recipe.

One ingredient (rule ingredient, in line 4) includes the ingredient’s identifier and the admissible range of values for the ingredient.

Ranges (rule range, in line 11) can be represented as one numeric interval, as a set of numeric intervals and as an enumeration.

The list of resources specifies the resources (rule resource, in line 8) required for the execution of the recipe as well as their functions (rule function, in line 9). Functions have input and output parameters (rule parameter, in line 10), and the values of said typed parameters can be optionally constrained by ranges (rule range, in line 11).

The next part of interest is the flow of the recipe (rule flow, in line 15), which specifies the syntax for declaring variables and the execution order of the functions of the recipe’s resources.

In a food recipe, the actions that need to be carried out do not always conform to a sequence of actions. To that end, the AROMA DSL allows the specification of sequential actions (rule sequence, in line 22), parallel actions (rule parallel, in line 25), repetitive conditional actions (rule repetition, in line 26) and decisions (rule decision, in line 27). These flow control modifiers define how other flows, or the resources’ functions, are to be executed.

One can obtain a better appreciation of the DSL in action by examining the recipe for the sugary water earlier mentioned (Listing 2).

Listing 2. Sugary water Dynamic Recipe using the AROMA DSL.

The first part of the recipe specifies that sweet water contains water, sugar and sweetener. The default ratio specifies the ideal proportion, but the DRA is able to select different proportions as long as they are within the ranges specified for the different ingredients.

The execution of the recipe includes three resources: a special container, with warming and mixing functions; a person, with the ability to add ingredients in certain quantities to a container; and a timer to control some mixing processes.

The Actions section includes a few variables that may be used to control the process followed by a sequence of functions and flows. In order to execute the recipe, the sequence can be read as follows:

• The person adds 50 mL of water to the container;
• Then, simultaneously, a person adds 5 g of sugar and 1 g of sweetener to the container while the container is warming up to 50 °C, mixing the ingredients at mix speed two;
• After the parallel block is executed (i.e., all the functions and flows in it terminate), the container must be warmed at mix speed one until the timer reaches 60 s;
• Finally, the person adds the remaining water while the container mixes at mix speed three.

3.2. Procuring Ingredients and Regulating the Execution of Recipes

The recipe needs now to be processed by the DRA, which needs to interpret it, procure its ingredients and control its execution. In the following text, the authors refer to the mock-up implementation provided in https://github.com/luferi/AROMA_Project (accessed on 1 January 2024).

In said implementation, the DRA will continuously negotiate the procurement of ingredients with all the available SAs. It will preferably negotiate for the ideal quantities specified in the DefaultRatio section of the recipe. Eventually, the suppliers will run out of supplies in the desired quantity and start refusing the procurement requests of the DRA. When this occurs, the DRA will start regulating the ratio of ingredients within the specified ranges and trigger re-negotiation.

In parallel, for every successfully negotiated batch, the DRA will coordinate the execution of the defined flow of functions with the appropriate resources.

The current implementation uses JADE [31], particularly version 4.6.0 [32] for implementing the agents, while the parsing of the AROMA DSL files uses the parse tree listener pattern documented in [33] and the interfaces automatically generated by ANTLR4 [30].

There are two main JADE behaviors within a DRA, running simultaneously. The first behavior handles, continuously and through negotiation, the procurement of ingredients for the recipes (Figure 4 and Figure 5). In both diagrams, the FIPA Contract Net Protocol (CNET) [34] is considered.

Successful negotiations (Figure 4) see many DRAs issuing a Call For Proposal (CFP) message to many SAs. On the CFP message, the desired products and properties are described. The SA will then evaluate whether they can supply accordingly to the CFP and issue a proposal in the form of a PROPOSE message, indicating the unit price of the procured ingredient. The DRAs process the different proposals and select the most appropriate one while rejecting all the others.

In the case of the dynamic recipe, described in Listing 2, the mock-up implementation will initiate a CNET interaction for each ingredient in the recipe.

Certain protocol instances may fail due to the insufficient supply quantity on the suppliers side (Figure 5). In these circumstances, the DRA will recalculate the ingredient ratio, according to a specialized function that maintains the desired properties of the food being produced by a dynamic recipe, and will re-trigger negotiation for the recalculated ingredients. In certain cases, it may not be possible to recalculate the ratio, which causes the DRA to give up on the procurement process.

For every successfully negotiated ingredient batch, the DRA then proceeds with the coordination of the resources described in the recipe flow. The actual interaction with the resources uses the FIPA Request Interactions Protocol [35].

At this point, the Actions section in the Dynamic Recipe document (Listing 2, lines 89 to 115) is parsed using ANTLR4 and interpreted into JADE behaviors [16]. The mapping is as follows:

• Sequence is interpreted as the JADE sequential behavior.
• Parallel is interpreted as the JADE parallel behavior.
• Repeat is interpreted as three main behaviors. A sequential behavior holds all the sub-flows of the repeat block, and a simple behavior evaluates the termination condition, both embedded into a finite state machine behavior, which, depending on the termination condition, evaluated as the terminator behavior, either re-runs the Repeat block, or terminates the finite state machine behavior.
• Function invocations within resources are mapped into AchieveREInitiator behaviors, corresponding to the client-side communication of the FIPA Request Interaction protocol, whose responder side is implemented by the Resource Agents (RAs).

The current mock-up implementation already provides a very solid base for addressing many of the long-term requirements specified earlier. However, it also uncovers both the technological limitations and the future design decisions that will need to be made for the full realization of the AROMA framework.

4. Discussion

The AROMA architecture proposed as well as the mock-up implementation made available along with this manuscript provide a preliminary proof of concept that attest to the feasibility of the overall approach. In order to more systematically discuss the results and lessons learned from the proof-of-concept implementation, the authors would like to reflect on the three dimensions, Resources, Representations and Actions [10], both in light of the requirements defined and available supporting technologies.

On the Resources dimensions, it is clear that the computational resources required to support the use case in Figure 1 exist. It is possible to model information with an arbitrary level of complexity, and store and actively transform such information appropriately. The majority of the mandatory requirements defined for the DFIC are realizable. Non-compulsory Requirements 6 and 7 require, however, closer examination. To track the status of food implies a dynamic slink between all physical processes that may come to affect one specific food and the evaluation of its processes. From an infrastructure perspective, such a level of monitorization and control may require the usage of sensors along the food chain infrastructure in places where these sensors currently do not exist. Alternatively, if such a sensor exists, access to it will have to be opened to potentially all the DFIC stakeholders. There is a case to be discussed here if the amount of sensing required is reasonable or implementable in a scalable way for example, should all the logistic operators transporting food include an open data infrastructure that would allow retailers to monitor the transport temperature of food items they have purchased. In this exemplary case, aside from the instrumentation needs within trucks transporting food, there is the question of the economical costs related to the ownership, maintenance and support of digital infrastructure. The laboratory-scale proof of concept does not directly warrant large-scale applicability.

On the Representations dimension, the work developed strongly suggests that the main barrier is not technology but rather the finding of adequate representations. One of very important aspects that is not derivable from the current results is whether it is possible to represent food with a generic set of properties, applicable to all foods, that would enable dynamic recipes, and subsequently DRAs, to operate generally and without being constrained to a subset of foods. Transparency is a key aspect, and a lingering challenge is to create models that transparently describe food and its transformation without exposing trade secrets. The latter directly impacts the success of dynamic recipes. From the results obtained, it is clear that they are realizable but also that they model critical production aspects that contribute to the success of a product (something that companies may, understandably, want to protect). The current version of the DFIC includes an explicit relation to the recipe but does not make any assumptions about the public accessibility of its details. It seems, at this stage of development, reasonable to use just a reference to the dynamic recipe for the purpose of traceability, while omitting the details.

On the Actions dimension, it is apparent that the MAS formulation of the problem as well as its supporting technologies are highly adequate for articulating resources and representations. Agents are a natural metaphor for developing cyber–physical systems and modeling their autonomous behavior. The current implementation relies on JADE and leverages its modeling and communication infrastructures to create and orchestrate complex flows of actions, including cyber–physical negotiation and execution. While the usage of JADE is arguable, other technologies may provide additional technological benefits. The MAS modeling of the problem appears to be essential and an integral part of the solution.

The authors therefore see these preliminary solutions as a credible proof of concept and testament of the feasibility of the AROMA platform. The authors also see clear future challenges, particularly in the Representations dimension for which straightforward solutions are still contained in future research.

5. Conclusions

This paper discussed a MAS architecture and implementation for food-producing systems. For many years, the F&B sector has been in dire need of a rethinking in the current prevalent production practices. At the same time, the perishable nature of food as well as its relation to consumers add additional digitization challenges that exceed those seen in many other more digitized industrial domains. One such challenge is that, to a relatively large extent, food production is in many cases an art, with many subjective decisions contained and tacit know-how included in the development of recipes. This manuscript sheds new light on the challenges but also the opportunities in digitizing the process of designing food and, in particular, the process of creating autonomous and self-adjusting recipes. To that end, the MAS formulation of the problem is a key contribution as is the AROMA DSL, allowing a mundane document, such a food recipe, to become an active digital document and therefore combining the art of designing food and food products with the advanced decision-making opportunities offered by modern computer science.