# Fancy Some Chips for Your TeaStore? Modeling the Control of an Adaptable Discrete System

Anna Gallone, Simon Bliudze, Sophie Cerf, Olga Kouchnarenko

► To cite this version:

Anna Gallone, Simon Bliudze, Sophie Cerf, Olga Kouchnarenko. Fancy Some Chips for Your TeaStore? Modeling the Control of an Adaptable Discrete System. WACA 2025 - First Workshop on Adaptable Cloud Architectures, Giuseppe De Palma; Saverio Giallorenzo, Jun 2025, Lille, France. pp.58-78, 10.4204/EPTCS.438.4. [hal-05158958v2](https://hal HAL Id:)

Id: hal-05158958

https://inria.hal.science/hal-05158958v2

Submitted on 7 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Fancy Some Chips for Your TeaStore?
## Modeling the Control of an Adaptable Discrete System *

Anna Gallone

Université Marie et Louis Pasteur, CNRS UMR6174, Institut FEMTO-ST, F-25000 Besançon, France
Anna.Gallone@femto-st.fr

Simon Bliudze

Univ. Lille, Inria, CNRS, Centrale Lille, UMR 9189 CRISTAL, F-59000 Lille, France
Simon.Bliudze@inria.fr

Sophie Cerf

Univ. Lille, Inria, CNRS, Centrale Lille, UMR 9189 CRISTAL, F-59000 Lille, France
Sophie.Cerf@inria.fr

Olga Kouchnarenko

Université Marie et Louis Pasteur, CNRS UMR6174, Institut FEMTO-ST, F-25000 Besançon, France
Olga.Kouchnarenko@femto-st.fr

When designing new web applications, developers must cope with different kinds of constraints relative to the resources they rely on: software, hardware, network, online micro-services, or any combination of the mentioned entities. Together, these entities form a complex system of communicating interdependent processes, physical or logical. It is very desirable that such system ensures its robustness to provide a good quality of service. In this paper we introduce Chips, a language that aims at facilitating the design of models made of various entwined components. It allows the description of applications in the form of functional blocks. Chips mixes notions from control theory and general purpose programming languages to generate robust component-based models. This paper presents how to use Chips to systematically design, model and analyse a complex system project, using a variation of the Adaptable TeaStore application as running example.

## Resources

A GitHub repository for the Chips language is available at the address https://github.com/NwaitDev/Chips_Public.

The source code of the Chips Adaptable TeaStore model and its BIP translation are available at https://github.com/NwaitDev/TeaStore-Variation.

## 1 Introduction

Chips, standing for Control of Hierarchical Interconnected Programmable Systems, is a language for designing, modeling and simulating distributed systems that execute tasks having strong interactions with their environment. Though its primary field of application is Cyber-Physical Systems (CPS), this paper

<footnote>*This work was supported by the ANR grant ANR-23-CE25-0004 (ADAPT). O. Kouchnarenko was supported by the EIPHI Graduate School (grant number ANR-17-EURE-0002).</footnote>
proposes a Chips implementation of a model for a Cloud Computing (CC) system, the Adaptable TeaStore application [7]. Adaptivity focus is put on the caching strategy: according to the response time of the website, the system changes the size of the cache at execution-time to maintain the service while reducing delays. To ensure an efficient adaptation, the followed methodology is grounded on Control Theory formalism as proposed by Filieri et al. [1]. Chips mixes a synchronous aspect with syntactic constructs to easily configure and connect many components. Section 2 gives an overview of our language's features. They allow to draw a full Model Based Development pipeline for an adaptive system project. Such pipeline is composed of the following steps (each being illustrated by its application on the Adaptable TeaStore example): Chips, standing for Control of Hierarchical Interconnected Programmable Systems, is a language for designing, modeling and simulating distributed systems that execute tasks having strong interactions with their environment. Though its primary field of application is Cyber-Physical Systems (CPS), this paper proposes a Chips implementation of a model for a Cloud Computing (CC) system, the Adaptable TeaStore application [7]. Adaptivity focus is put on the caching strategy: according to the response time of the website, the system changes the size of the cache at execution-time to maintain the service while reducing delays. To ensure an efficient adaptation, the followed methodology is grounded on Control Theory formalism as proposed by Filieri et al. [1]. Chips mixes a synchronous aspect with syntactic constructs to easily configure and connect many components. Section 2 gives an overview of our language's features. They allow to draw a full Model Based Development pipeline for an adaptive system project. Such pipeline is composed of the following steps (each being illustrated by its application on the Adaptable TeaStore example):

* The design of an adaptive Chips model for the application, Section 3.

* Its potential declination with the duplication of the system's components to balance workload or another parameter of interest, Section 4.

* The transformation of the Chips model into a form that allows testing, simulation or code generation, Section 5.

Section 6 presents the results obtained when applied to the Adaptable TeaStore. Section 7 discusses some common aspects and differences of our methodology with other works revolving around real-time adaptation of computing systems. Finally, some insight is given on what is intended as future work for a better adaptivity of models designed with Chips and for the language itself.

## 2 Overview of the Chips language

Cloud Computing systems share many characteristics with structured distributed CPSs aimed by Chips, namely, the coordination of multiple devices over communication protocols, the repeating entry and exit of devices in the network or the need to maintain a service when a component is temporarily unavailable. Hence, Chips can be effectively used for the design of CC systems though it is focused on the design of CPSs' models, and more particularly *complex systems*<fnref n="1" />. The following subsections introduce, in a first place, the technologies and concepts on which Chips lies, then presents the main principles of the language.

<footnote n="1">¹Hereafter, the term “complex system” will be used to describe a set of processing units achieving a task altogether, with each unit potentially being implemented by another kind of system, which may be complex as well.</footnote>
## 2.1 Chips technical and theoretical base

In this paper, we propose a compilation from Chips into BIP [5], which opens the way for many additional model based operations. BIP (for Behavior Interaction Priority) is a framework for developing interacting automata based models. Its rigorous implementation of synchronicity mechanisms makes it possible to derive these models through correct-by-construction programs generation, and model exploration tools are provided alongside the BIP compiler to ensure the right behavior of the designed applications. When it comes to the adaptation of a complex system, one can distinguish two kinds of adaptation for programmable components: behavioral adaptation and structural reconfiguration [17]. In this paper, we propose a compilation from Chips into BIP [5], which opens the way for many additional model based operations. BIP (for Behavior Interaction Priority) is a framework for developing interacting automata based models. Its rigorous implementation of synchronicity mechanisms makes it possible to derive these models through correct-by-construction programs generation, and model exploration tools are provided alongside the BIP compiler to ensure the right behavior of the designed applications. When it comes to the adaptation of a complex system, one can distinguish two kinds of adaptation for programmable components: behavioral adaptation and structural reconfiguration [17]. The former is about modifying the data manipulated among the components for the system to take decisions, while the latter is about modifying the way components interact, by modifying the number of instances of subsystems in use or their connections. Behavioral adaptation can be achieved with the BIP framework pretty easily, while structural reconfiguration requires more work, hence the development of DR-BIP (Dynamic Re-configurable BIP) [4]. Providing a language to automatize the generation of BIP models should allow achieving adaptation goals in a systematic way. In this context, Chips proposes to take a step back from the BIP models, and to add upon them another abstraction layer taking advantage of two main concepts:

* The first one being *Control Theory* (CT for short) [24], a well known engineering domain, where each component is modeled by a function. Additional control components allow the system behavior to adapt at run-time. By assembling the functions together, CT turns a physical system into a differential equation. Such equation solutions are the different behaviors to adopt for the control components so the system realizes a task as expected. Though control theory is mainly applied to the engineering of continuous systems, it can find applications for discrete systems too [13].

* The first one being *Control Theory* (CT for short) [24], a well known engineering domain, where each component is modeled by a function. Additional control components allow the system behavior to adapt at run-time. By assembling the functions together, CT turns a physical system into a differential equation. Such equation solutions are the different behaviors to adopt for the control components so the system realizes a task as expected. Though control theory is mainly applied to the engineering of continuous systems, it can find applications for discrete systems too [13].

* The second concept is *Aggregate Programming* (AP for short), a programming paradigm implementing collective communication primitives that rely on field calculus [21]. The role components take in the collective behavior of the system is computed on the go by the state of variables continuously updated on each device according to their position. In such systems, leadership is assumed by the field of the values shared in the space and not by a particular device, making applications developed according to the aggregate programming principles extremely resilient to structural changes.

* The second concept is *Aggregate Programming* (AP for short), a programming paradigm implementing collective communication primitives that rely on field calculus [21]. The role components take in the collective behavior of the system is computed on the go by the state of variables
continuously updated on each device according to their position. In such systems, leadership is assumed by the field of the values shared in the space and not by a particular device, making applications developed according to the aggregate programming principles extremely resilient to structural changes.

Our goal with the Chips language is to fill the gap between these engineering concepts and their concrete implementation.

## 2.2 Chips programming principles

**A synchronous programming language** The closest to control theory programming paradigm one can find in the state of the art is synchronous programming. Languages implementing this paradigm aim at describing flows of data instead of variables, and they transform dataflows assuming some operations can be made instantaneously. Lustre [8] and one of its derived language Heptagon [11], are respectively compilable in C and Ocaml. Eclat [20] can also be mentioned as a synchronous language for the description of FPGA logical circuits. Such languages provide mathematical properties that make them reliable for the design of (potentially critical) reactive systems. Chips describes systems to make them behave in a similar way. Each component of a Chips application is represented by a functional block with inputs and outputs. Interconnected components executions are synchronized so that the system models some actions as simultaneous. Basic Chips constructs include three kinds of functions:

1 // extract last bit value for validation
2 pure user_action_is_valid (int user_action_data)
3 -> ( (user_action_data & 0x1) == 0x1 )
4
5 // all other bits are the qty of images to fetch
6 pure user_action_nb_images (int user_action_data)
7 -> (user_action_data >> 1)
8
9 logical interpretation_module (int user_action) init {
10 int nbr_images = 0;
11 } then {
12 if (!user_action_is_valid (user_action)) {
13 nbr_images = 0;
14 } else {
15 nbr_images = user_action_nb_images (user_action);
16 }
17 } -> (nbr_images)
18
19 logical image_provider (int nb_images_to_provide) init {
20 int [] cache = empty_set;
21 time_since_last_req = 0;
22 } then {
23 for i in n_up_to (nb_images_to_provide) {
24 img_to_fetch = rndImg_id () ;
25 if (!find (img_to_fetch, cache)) {
26 // simulating db request
27 } else {
28 lru_update (cache, img_to_fetch) ;
29 }
30 } -> (1)
31
32 import "server.json" as server;
33
34 physical server (int server_resources, int user_action)
35 -> (server_resources, user_action)
36
37 /* ... other definitions ... */

<caption>Listing 1: Code sample of Chips simplified TeaStore model components</caption>

**A synchronous programming language** The closest to control theory programming paradigm one can find in the state of the art is synchronous programming. Languages implementing this paradigm aim at describing flows of data instead of variables, and they transform dataflows assuming some operations can be made instantaneously. Lustre [8] and one of its derived language Heptagon [11], are respectively compilable in C and Ocaml. Eclat [20] can also be mentioned as a synchronous language for the description of FPGA logical circuits. Such languages provide mathematical properties that make them reliable for the design of (potentially critical) reactive systems. Chips describes systems to make them behave in a similar way. Each component of a Chips application is represented by a functional block with inputs and outputs. Interconnected components executions are synchronized so that the system models some actions as simultaneous. Basic Chips constructs include three kinds of functions:

* "pure", to factorize expressions that may be used elsewhere, in the components' or the system's description (lines 1 to 7 in Listing 1) or,
* "logical" if the function models a component of our system, it can include memory in the form of inner variables or execute sequential algorithms (lines 9 to 30 to model the different interacting modules of the application) or,

* "physical" if the function models a hardware component comprising calculation capacity and allocatable memory (lines 34 and 35 to specify the way a server interfaces the virtual modules and the physical world).

**Non-standard synchronous language** In contrast to previously mentioned languages, Chips is only partially synchronous. Though logical and physical components are modeled as simultaneously executed, Chips describes the relation between variables in an imperative way, closer to general-purpose programming languages. No parallelism is admitted within the shell of a logical or physical function. Each component's inner variable is modifiable with a C-like syntax. Still, according to synchronous programming principles, the output parameters of a component are only accessed by other components once the whole *Then* section is completely executed, thus hiding the sequential logic from the whole system point of view. Such constraint ensures the atomicity of the components. Since

everything that can be parallelized is set in a different component, the work of splitting apart the different functions among the modeled physical devices is simplified.

```c
1 SYSTEM {
2     user user_instance;
3     server server_instance;
4     interpretation_module im_instance;
5     image_provider ip_instance1;
6     image_provider ip_instance2;
7     link im_instance to server_instance;
8     link ip_instance1 to server_instance;
9     link ip_instance2 to server_instance;
10
11
12
13     im_instance.in(server_instance.out[1]);
14
15     splitplug(im_instance.out, profiling_flinefunction);
16
17     ip_instance1.in(im_instance.out);
18     ip_instance2.in(im_instance.out);
19
20     mergeplug(ip_instance1.out, aggregating_function);
21     mergeplug(ip_instance2.out, aggregating_function);
22
23     server_instance.in(ip_instance1.out, user_instance.out);
24     server_instance.in(ip_instance2.out, user_instance.out);
25
26     user_instance.in(server_instance.out[0]);
27 }
```

<caption>Listing 2: System description of Chips simplified TeaStore model</caption>

**Signals aggregation and profiling** An interesting addition to the language is the possibility to specify how a signal can change its cardinality to feed the inputs of a set of components. Directly inspired by AP, Chips provides the `mergeplug` and `splitplug` instructions. When a single signal has to be duplicated to be the input of several components, one can use the `splitplug` construct (see Listing 2, line 15). Its first parameter being the name of the signal to be plugged to an arbitrary number of functional blocks. The second one is the name of a function that describes how the signal should be split. Therefore, behind the term `aggregating_function`, one can imagine a function that duplicates the signal, that spreads evenly its elements among the plugged components etc. With the same philosophy, the `mergeplug` construct (Listing 2, lines 20 and 21) specifies that a signal can be merged with another one according to a certain function, thus allowing to realize summing or filtering operations for instance.

**Refining models with hardware specifications** Additionally to a Chips program, hardware description files should be provided for each physical component (see `import` command in Listing 1, line 32). Such files would give information about the components capabilities: number of processors, memory size, clock rate, actuators and sensors etc. This additional information enhances the Chips model by allowing to determine at compile time if a program fits a certain hardware or if a signal has to be transmitted to another device for the program to keep running. Syntactically, these constraints are specified in the `SYSTEM` section of a model. Each functional block has to be embedded by a physical device. That
dependency is described with the *link* operator (lines 8 to 10 of Listing 2).

These features are what models would be built upon when using Chips. To demonstrate their usefulness, next sections detail their application to the Adaptable TeaStore example.

# 3 Designing an Adaptable TeaStore with Chips

In order to construct a solid Model Based implementation of the Adaptable TeaStore, the adopted methodology is the one of CT. One can follow a six steps approach that is decomposed into:

1. Identifying *goals*

2. Identifying *knobs*

3. Devising the model

4. Designing the controller

5. Implementing and integrating the controller

6. Testing and validating the system.

Section 3.1, through a rigorous requirement analysis, realizes the steps 1 and 2. The description of the model used for this study is presented in Section 3.2. On the base of the built model, Section 3.3 explains the design of the controller used for the system and its integration into our model, thus achieving steps 4 and 5. The last step is kept for the result section of this paper.

## 3.1 TeaStore requirement analysis

We start by an analysis of the requirements associated with the Adaptable TeaStore case study [2][7]. When working on the control of a system, two main signals have to be identified, the *goal* and the *knob* signals.

On the one hand, the *goal* signal is the ideal value the system is aiming for. This could be the response time, the overall CPU load or the memory use of a system. The goal signal serves as input for the controller component introduced by CT to make the system adaptable.

On the other hand, the *knobs* (or *actuators*) are the signals produced by such controller component. They aim at changing the system's behavior toward desired goals. To identify the knobs, more domain knowledge is required because these signals can sometimes overlap each other or lie in complex parts of the system. For example, if the goal of the controller is to ensure a certain response time, the knobs could correspond to the (de)activation of processor overclocking or to the modification of the available cache size.

**Goals identification** Acknowledging common practices of web development, the main goal of the TeaStore application should be to provide an enjoyable online shopping experience. Adaptable TeaStore case study specification [7] distinguishes mandatory modules, and optional ones. It could be assumed that the mandatory modules are in charge of the base functionalities the application offers, while the other are additional non-functional requirements to fulfill.

The modules suggested are (mandatory modules in bold font): **Web User Interface** (WebUI), **Persistance service**, **Image providing service**, Authentication functions, recommendation system.
<table><caption>Table 1: TeaStore Modules and their associated knob for real-time adaptation of services speed</caption><thead><tr><th>Module</th><th>Knob name (and nature)</th><th>Description</th></tr></thead><tbody><tr><td rowspan="2">Web UI</td><td>JS (Boolean)</td><td>Enable or disable JavaScript if unsupported operation for a browser</td></tr><tr><td>Cache size (Natural)</td><td>Adjust the number of elements the local cache can store</td></tr><tr><td rowspan="2">Image Provider</td><td>Image size (Natural)</td><td>Default size of the images to store in the cache</td></tr><tr><td>Image resizing (Boolean)</td><td> Authorize the resizing of images</td></tr><tr><td rowspan="2">Persistence</td><td>Request type (Categorical)</td><td>“fullldb”, “available”, “batch-queries”, “top-popularity”, ...</td></tr><tr><td>User profile (Boolean)</td><td>Whether to retrieve additional personal data or not</td></tr><tr><td rowspan="2">Authentication</td><td>Available (Boolean)</td><td> Authorize authentication or not</td></tr><tr><td>Auth kind (Categorical)</td><td>“SSOOnly”, “TeaStoreAuth only”, “AnyAuth”, “None”, ...</td></tr><tr><td>Recommender</td><td>Nb params (Natural)</td><td>Number of parameters for the regression algorithm</td></tr></tbody></table>

From the functional point of view, the TeaStore website should contain images of the articles the store has to sell, suggest items to buy, allow the users to navigate through the pages anonymously and store items in a cart to buy them later. From a non-functional point of view, one could imagine designing an application achieving these goals within a certain time to hold the user's attention, adding authentication services through other websites accounts, having a minimal electrical consumption, actively monitoring the clients behaviors to enhance the suggestion algorithm etc.

Any of these functionalities can be submitted to thorough analysis for a CT application. Our study focuses solely on keeping the response time of the application reasonable as it is a common concern for many websites.

**Knobs identification** Now it has been decided what goal to follow, it is possible to identify for each component of the application what are the levers to improve timing performances of the system at execution time. Table 1 presents some of the knobs identified for the TeaStore example application, applying control to which could be of interest to reduce delays between operations. For instance, if the user internet connection is unstable, it becomes relevant to turn off image resizing to avoid sending multiple times the same picture if need be to re-send images when packets are lost.

The experiment conducted in this paper is focused on the development of the **Image provider**, and, more precisely, on how to use Chips to model a system where load balancing is achieved through the dynamic control of the local cache size. The greatest the number of elements stored in the cache, the lowest the number of requests to the database, and therefore, the less time it takes to answer a user's request.

## 3.2 A TeaStore Chips model

**Model devise** Following CT bases [13], Chips uses block diagrams. As first step, the system model must be assembled by turning each module of the specifications into a block converting an input signal into an output signal, as illustrated in Figure 1.

**Model devise** Following CT bases [13], Chips uses block diagrams. As first step, the system model must be assembled by turning each module of the specifications into a block converting an input signal
<figure><img src="image_2.png" /><figcaption>Figure 1: Block diagram of the designed architecture for the TeaStore application and its interaction with a user</figcaption></figure>

into an output signal, as illustrated in Figure 1. The choice was made in this paper to keep the model as simple as possible. The use case modeled is one where only one user is conversing with the server. Although it is not realistic, it remains easy both to implement and to improve when the need comes to scale the model up. Other points are worth noticing, there are some differences between the original modules described in Section 3.1 and the diagram presented:

* The WebUI has been split into two components to clearly separate its two functions, receiving the data from the user and sending back a response (respectively *User Action Interpreter* and *Web Page Service*).

* The physical interfaces through which data are exchanged are represented (*Server Physical Interface* and *User Computer Interface*).

* A *Request Validator* block is there to decide whether a request for data of the user is correct or not according to its authentication state.

When working on constraints as response time or fault tolerance, it is important to model not only the processed data, but also the context in which it is processed. Hence the differentiation of logical and physical functions of our blocks. In the end, any algorithm will always be executed by a hardware component. This hardware is responsible for the efficiency of the system at a certain task and if we want to keep our model useful, we must take it into account. Figure 2 is complementary to the block diagram described before. The physical dependency graph (associated with Chips *logical* and *physical* keywords and the *link x to y* instruction) allows the model to better determine data transmission timings, calculation speed and memory constraints. When two entities try to communicate while being associated with different physical devices, i.e., transmitting a signal through the physical interaction arrow of the diagram, there is a need to encapsulate the information in a protocol. According to the nature and connectivity of the communicating devices, a set of constraints can be applied to keep the model as close to the reality as possible. At simulation time, this could mean virtually adding delays, losing random packets of data or introducing errors.
<figure><img src="image_3.png" /><figcaption>Figure 2: Dependency graph of the designed architecture for the TeaStore application and its interaction with a user</figcaption></figure>

To achieve a working model with the aim to parameterize the cache size used by the server, simplifying hypotheses were made:

* The user always waits for an answer from the server.

* The user never disconnects from the server.

* The server provides resources as either required page or authentication page, modeled by a boolean.

* No recommendation system is used.

* The user always sends actions to the server after receiving resources from it.

* Once the user has provided right authentication data, it is considered by the server as *connected* until the end of the simulation.

* When the user is connected, the server always responds with the required page.

* Time delays are negligible, except for the ones it takes to fetch images from the cache or from the database.

* The server never shuts down and no packets are lost between it and the user computer.

* The database always contains the requested data, and provides images one at a time.

* The server tries to keep the response time of the image provider around a given constant time value.

* User actions are interpreted as a three fields data structure.

* `action_request`:

* `bool isHeavyRequest`
<figure><img src="image_4.png" /><figcaption>Figure 3: In depth block diagram of the Data Treatment Block</figcaption></figure>

* **bool requestPrivatePage**

* **bool providesRightAuthData**

These assumptions allow abstracting away many constraints that would render the system too complex to analyze. If the control were to be applied to another part of the system, such hypotheses would have to be changed to properly separate the study concerns.

## 3.3 Achieving adaptivity

The component of interest—the cache of our image provider block—can now be studied without worrying about other sources of disturbances than the one that directly impacts them. To do so, the image provider block includes, on top of the cache, a controller component depicted in Fig. 3.

**Controller design** A PID (Proportional Integral Derivative) controller is used to manage the caching part of the TeaStore application. It is a controller that takes into account the error (difference between expected and resulting value) of a system, its integral and its derivative to modify the knob it controls. This kind of controller is used in a vast majority of control scenarios with good results and its simplicity makes it an easy to implement example of controller to work with in our case [3].

**Controller design** A PID (Proportional Integral Derivative) controller is used to manage the caching part of the TeaStore application. It is a controller that takes into account the error (difference between expected and resulting value) of a system, its integral and its derivative to modify the knob it controls. This kind of controller is used in a vast majority of control scenarios with good results and its simplicity makes it an easy to implement example of controller to work with in our case [3]. The inner data treatment block controller will have the task to convert its input command (the response time required by the server general controller) into a cache size (an integer corresponding to the number of items the cache can retain), so that the overall calculation time of the system remains around the command value. The cache used will apply the Least Recently Used strategy (LRU), and to keep the model lightweight,
images will be modeled by an ID number between 1 and the total number of images of the database DB_SIZE. For each request, the image provider will look for the images IDs in the cache. This search is modeled by the CACHE_SEARCH_TIME value. For each image not found in the cache, the image provider sends a data request taking DB_REQ_TIME. Therefore:

$$actual\_response\_time = CACHE\_SEARCH\_TIME + X \times DB\_REQ\_TIME$$

$$CACHE\_SIZE(t) = P \times error(t) + I \times \left( \int_{0}^{t} error(t) \times dt \right) + D \times \frac{d \times error(t)}{dt}$$

where:

* X is the number of images not found in the cache depending on the previous requests and the actual size of the cache,

* P, I and D are constant real values chosen either empirically, arbitrarily by experience of a CT expert, or analytically by solving the whole system equation,

* error(t) = response_time_required - actual_response_time.

If the cache is too small, X is likely to be high, while if X ≥ DB_SIZE, the response time will always be CACHE_SEARCH_TIME as the cache can contain the whole database. To match the behavior of a user who sometimes requires the same images, and sometimes completely different images, the images requested will be randomly generated in [1, DB_SIZE]. That representation could also be upgraded by changing the probability distribution of the chosen numbers to simulate the popularity of different articles.

# 4 Extending adaptation to the structure of the system

If the running system has multi threading capabilities for parallel computing, one could imagine enhancing the previously described version of the controller (see Figure 3) with more instances of image provider (as the example given in the listing 2 of Section 2). In such case, the control logic can remain the same, but the way the command signal is transmitted to the under-control component must be profiled. Such architecture requires to always send the same requests to the same image provider components so the different caches don't store the same information twice. This concept can be expressed in a quite natural way with the use of mergeplug and splitplug instructions on the outputs and inputs respectively of the image providers working in parallel. They provide the possibility to turn raw signals into an adapted version of it for the image providers to efficiently cooperate(profiling function and aggregating function in Figure 4).

Thank to these operations, the same encoding of the Data Treatment Block can be used, whatever the number of instances of image provider. It makes it also possible to follow the formalism of [6] to build applications with multiple layers of hierarchy for more complex systems. This facility of AP to abstract away complex communication and coordination protocol layers is what Chips is seeking for in term of expressivity of its models. AP makes it easier for a described system to turn the architectural configuration of it into parameters that the model's controllers can tune, hence allowing even more adaptivity. This "multi-provider" instance model is provided here as a motivation for Chips further development, but could not be implemented as more work is needed to fully introduce AP syntactic constructions without breaking the rigor the synchronous paradigm offers. This point will be expanded in Section 8.
<figure><img src="image_5.png" /><figcaption>Figure 4: Data Treatment Block handling several Image Provider instances</figcaption></figure>

# 5 Experimental setup

**Test and validation of the system** The Chips model for the TeaStore application was manually translated into a BIP set of components according to transformation rules described in Section 5.1. The presented experiment was conducted on the BIP model<fnref n="2" /> with a machine using a 13th Gen Intel® Core™ i713850HX processor and a RAM of size 32 Gigabytes. The BIP model for the TeaStore application takes about 2 to 3 minutes to compile into an executable code for simulation. And such simulation takes a few seconds to run with the parameter described in Section 5.2. Each component of the block diagram implemented is modeled by a single automaton, having at least as many transitions as the block's inputs and outputs.

## 5.1 Chips to BIP transformation

Most of the functional blocks of the Chips model described by our model (Figure 1) could be turned into an associated BIP automaton in the following manner (also shown on Figure 5):

* Each inner variable, input parameter and output parameter of the Chips function is modeled by a variable of the same name in the BIP automaton.

<footnote n="2">²The BIP version used is available at https://gricad gitlab.univ-grenoble-alpes.fr/verimag/bip/ compiler.git</footnote>
* The BIP automaton associated with a Chips function forms a loop achieving the following three kinds of transitions:

- input transitions synchronized with the output transitions of another automaton providing the input data,

- updating transitions which are internal (i.e. not synchronized/exported), to execute *Then*-section operations,

- output transitions synchronized with the input transitions of another automaton needing data to keep updating.

* There is at least one input transition for each input variable of the Chips function.

* For each input transition, if not all the input data have been gathered, the transition leads to a state modeling the reception of the data. Such state loops on itself with a transition receiving the same data if the same input is received several times in a row, thus overriding the previous value to only take into account the most recent information.

* If the data collected by the input transition is the last remaining input to be collected, the transition leads to an "all data received" transition.

* An internal transition associated with the *Then* section is added from "all data received" to "adaptation computed".

* Finally, all the output transitions are added, in any order, each leading to a state modeling the sending of the data. The last one of these states serves as the source of the input transitions.

No final state is required as the system isn't supposed to shut down. The initial state is then set to the state representing the sending of the last output parameter for every component except for an arbitrarily chosen one.

That remaining component will start at the state representing the last input parameter so the system isn't in deadlock. On the initial transition leading the component to its first state, the *Chips init* section is executed. The only component that did not follow this transformation process is the *Data Treatment Block*. In Listing 1 line 26, the *Chips* program doesn't model the interaction with a database component. The BIP implementation that was used for the experiment comprises such interaction, but no *Chips* primitive can currently express it. Therefore an additional state was added. Indeed, the current semantic of *Chips* only allows to transmit information from a component to another when the *Then* section is fully executed (Figure 6). Sending requests to another component and waiting for its response is currently impossible (or at least, a lot more refactoring has to be done). Designing language constructs to specify inner-*Then* synchronized operation is one of the current concerns of this research and will be more detailed in Section 8.

## 5.2 Parameters of the model

To run these experiments, parameters of the model were arbitrarily chosen. Even if not particularly based on field values or any website response time benchmarks, variables stay relatively coherent in view of assumptions made on the authors' base knowledge on most websites behaviors:

* The cache search takes less time than the image fetch from the database.

* The system aims at reducing the time it takes to provide resources.
<figure><img src="image_6.png" /><figcaption>Figure 5: A Chips implementation of a PID controller and its BIP model equivalent</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Figure 6: BIP simplified automaton for the image provider algorithm (dashed lines represent elements with no Chips equivalent)</figcaption></figure>

* The number of images to provide is greater when the user is connected (to provide profile pictures for instance). The presented experiment will not make use of this parameter as it seems to be useful for a more detailed model only.

* The cache has a maximum size (no server has an infinite memory) and a minimum cache size. The minimum cache size was arbitrarily set to 20 as setting a cache size “too low” would give an irrelevant hit rate and a website designer would probably better not use any cache than using an almost useless one.

Hence the following parameters:

float REQUIRED_RESPONSE_TIME = 4.0;
float CACHE_SEARCH_TIME = 0.3;
float DB_REQ_TIME = 2.0;
float CACHE_MAX_SIZE = 100;
float CACHE_MIN_SIZE = 20;
int DB_SIZE = 40;

## 5.3 User activity scenario design

In the follow-up results, the user scenario presented is separated in two phases:

* A phase of “wandering”, where the user model component only sends a request for two images at the same time. It repeats this operation 300 times.

* A phase of “intensive browsing”, where the components send a request for six images and repeat this process until the end of the simulation.

Even if this behavior looks more like integration testing than an actual user behavior, it serves well the purpose of this paper as a proof of concept for Chips model design workflow.

# 6 Simulation results

Figure 7 shows the behavior of the previously described system model. The curves were obtained using the following parameters for our PID controller: $P = -1$, $I = -0.01$, $D = 0$. They were empirically tuned until the simulation exhibits signals converging toward a stable state for both the scenario phases. Other design techniques could be used as shown in [3]. Figure 7 shows the behavior of the previously described system model. The curves were obtained using the following parameters for our PID controller: $P = -1$, $I = -0.01$, $D = 0$. They were empirically tuned until the simulation exhibits signals converging toward a stable state for both the scenario phases. Other design techniques could be used as shown in [3].

During the first 800 seconds of the simulation, the user requests are answered by the server under 3 seconds on average, which is coherent regarding the number of images requested by the user during their “wandering phase”. The response time can only be greater than the required response time (4 seconds) when no image is found in the cache (2 cache misses take $2 \times 2.0 + 0.3$ seconds). As half the database can be stored in the cache when it is at its minimum size (20 images), it is likely that images requested by the user can be found, hence the average response time of 2.8 seconds.

When the user disturbs the system by asking for more images for each request (“intensive browsing phase”) after the 300 requests ($t = 834$), the response time increases and the controller adapts the cache size to keep the response time around the command. The jittering phenomenon of the cache size around 37 is due to the fact that our system is discrete. It cannot set the response time exactly to the command so it alternates between a response time a little shorter and a little longer than required.

Let us note that by tuning the PID coefficients, it is possible to change the behavior of the system to reach the optimal cache size quicker, at the risk of temporarily setting the cache size way higher than required. It is 40 in this setup since this is the size of the database and having a bigger cache wouldn’t give better results.

# 7 Related work

Formalizing adaptivity to design more robust systems is not new. With Chips, our choice is to exploit the results of CT to leverage the question of the behavioral adaptation. But other formalisms exist. One of the most used models to achieve adaptation in software design is the MAPE-K loop. Firstly introduced in [15], it describes a systematic way to adapt the behavior of a system by a four-step protocol: Monitoring signals of interest, Analyzing their meaning, Planning a way to adapt the behavior, and
<figure><img src="image_8.png" /><figcaption>Figure 7: Real time adaptation of the cache size according to the behavior of the client model</figcaption></figure>

Executing such plan by tuning correctly the signals commanding the system. The K stands for the Knowledge on which adaptation strategies lie on. It can be designers' expertise, models of the system or databases of interest for the situation. Compared to CT, MAPE-K provides a wider framework to describe adaptation strategies. It has a qualitative approach to the way systems work when CT is more about finding the signals interacting together and formally describe their relation to deduce the best adaptation function. Formalizing adaptivity to design more robust systems is not new. With Chips, our choice is to exploit the results of CT to leverage the question of the behavioral adaptation. But other formalisms exist. One of the most used models to achieve adaptation in software design is the MAPE-K loop. Firstly introduced in [15], it describes a systematic way to adapt the behavior of a system by a four-step protocol: Monitoring signals of interest, Analyzing their meaning, Planning a way to adapt the behavior, and Executing such plan by tuning correctly the signals commanding the system. The K stands for the Knowledge on which adaptation strategies lie on. It can be designers' expertise, models of the system or databases of interest for the situation. Compared to CT, MAPE-K provides a wider framework to describe adaptation strategies. It has a qualitative approach to the way systems work when CT is more about finding the signals interacting together and formally describe their relation to deduce the best adaptation function.

Still, MAPE-K stands as the base of a lot of research around adaptivity. For example, MAPE-K gave birth to Rainbow [9], a framework using a model of the controlled system at run-time to deduce best adaptation strategies at the whole system level. The MAPE-K methodology is then applied to the distributed system under control. However, the development of such adaptation mechanism remains monolithic. It is therefore inherently hard to upgrade and pushes toward a centralized implementation, potentially acting as performance bottleneck. Still, MAPE-K stands as the base of a lot of research
around adaptivity. For example, MAPE-K gave birth to Rainbow [9], a framework using a model of the controlled system at run-time to deduce best adaptation strategies at the whole system level. The MAPE-K methodology is then applied to the distributed system under control. However, the development of such adaptation mechanism remains monolithic. It is therefore inherently hard to upgrade and pushes toward a centralized implementation, potentially acting as performance bottleneck.

Aspect Oriented Programming (AOP) [12] proposes to overcome the adaptation workload distribution problem by providing tools for the task distribution at the language level. Though it comes with other challenges like the need for synchronization of wide scale systems. Chips distributes the control in a similar way: the language provides an easy way to reconfigure the models to try other distributions of the tasks. Therefore, it currently suffers the same struggle. Aspect Oriented Programming (AOP) [12] proposes to overcome the adaptation workload distribution problem by providing tools for the task distribution at the language level. Though it comes with other challenges like the need for synchronization of wide scale systems. Chips distributes the control in a similar way: the language provides an easy way to reconfigure the models to try other distributions of the tasks. Therefore, it currently suffers the same struggle.

Another problem to overcome with adaptation is the one of anticipation: At design time, it is only possible to anticipate a subset of all the events that could lead to unintended behaviors. One may need to improve the way adaptation is performed while the system is running, when the unwanted event occurs. To do this, the language AIOCJ [10] presents a way to modify the code of an application at run-time and to allocate that code to components assuming a certain role in the application. Another problem to overcome with adaptation is the one of anticipation: At design time, it is only possible to anticipate a subset of all the events that could lead to unintended behaviors. One may need to improve the way adaptation is performed while the system is running, when the unwanted event occurs. To do this, the language AIOCJ [10] presents a way to modify the code of an application at run-time and to allocate that code to components assuming a certain role in the application.

In the recent years, the development of micro-services applications became more and more popular. Their Application Programming Interfaces (API) allow to think of adaptation, not as a software grafted to an architecture to adapt, but rather as a service to which components of the system can subscribe. This is the approach adopted by Adaptiflow [22], a java framework that allows exporting the load of the MAPE-K loop to a third-party server at the cost of depending on the availability of the service.

Though, MAPE-K is not the only model that can be used to achieve some sort of real-time adaptation. It can even be considered as too reductive to embrace the complexity of some softwares [16] and trying to find ways to emancipate from it could lead to even more efficient solutions. With the recent popularity gained by the field of artificial intelligence, the AWARE model [18] has been developed to improve the reflexivity of the feedback mechanism by introducing intelligent agents to the core of the adaptation mechanism. These agents learn the behavior of the system under control while it is running. Though, MAPE-K is not the only model that can be used to achieve some sort of real-time adaptation. It can even be considered as too reductive to embrace the complexity of some softwares [16] and trying to find ways to emancipate from it could lead to even more efficient solutions. With the recent popularity gained by the field of artificial intelligence, the AWARE model [18] has been developed to improve the reflexivity of the feedback mechanism by introducing intelligent agents to the core of the adaptation mechanism. These agents learn the behavior of the system under control while it is running.

Since Chips primary focus is on CPSs, it is dealing with devices often offering low resources in term of memory, communication or CPU. Therefore, run-time code modification, delegation to micro-services or inclusion of AI agents aren't a priority.
# 8 Future work

As Chips is still in its early days, most of its development stack is yet to create. Many features are envisioned to make this project applicable. Following paragraphs detail ongoing work on the language.

**A complete version of the compiler** Currently, the language has a syntax that can be parsed, but not interpreted. A meta-model of the language is defined for the main Chips constructs but no compiler exist for the language yet. The hardware description file structure is not fully determined either. These elements are the current priorities of the Chips project and shall soon be developed. Our intention is to use ATL [14] or another model-to-model transformation tool to turn the Chips meta-model into the BIP meta-model, thereof, to generate a robust Chips-to-BIP compiler. Until then, the experimentation presented here could only be realized after a hand-written compilation.

**A complete version of the compiler** Currently, the language has a syntax that can be parsed, but not interpreted. A meta-model of the language is defined for the main Chips constructs but no compiler exist for the language yet. The hardware description file structure is not fully determined either. These elements are the current priorities of the Chips project and shall soon be developed. Our intention is to use ATL [14] or another model-to-model transformation tool to turn the Chips meta-model into the BIP meta-model, thereof, to generate a robust Chips-to-BIP compiler. Until then, the experimentation presented here could only be realized after a hand-written compilation.

**New language constructs** Few models were built thank to Chips, and as the language will be applied to more case studies, new needs are expected to emerge in terms of the Chips expressivity. Some interesting features have already appeared though:

* **Building AP primitives:** The specification of the *mergeplug* and *splitplug* is currently incomplete. More formalism is required for a proper description of what properties the profiling/aggregating functions should have. However, BIP connectors simulating the concept of AP "arity-modification" instructions are already under development. Their linked list version is currently functional, but it couldn't be added to our model to exhibit significant results in time for the edition of this document. We intend to design a tree-like version of such connectors to fit a wider range of configurations the different modeled modules can form.

* **Inner-Then data synchronization:** As mentioned in the last paragraph of Section 5.1, Chips lacks a way to signify a datum is to be read or written during the update of the variables of a component. A possibility would be to introduce a subtype for the inner variables of a component to turn them into some sort of public attributes in the style of object oriented programming. Such decision isn't made yet and has to be confronted with the formalism Chips tries to adopt so the language doesn't become too permissive and prone to errors.

* **Hierarchical control features:** With its building and plugging blocks design, Chips also permits the description of hierarchically organized control. Adding layers of control for a complex system could allow each sub-system to work at its own pace in a correct way, while together reaching a larger goal [19]. This layering could be achieved by adding annotations to our Chips blocks for instance. It would explicitly show the encapsulation of signals within a control layer.

* **Hierarchical control features:** With its building and plugging blocks design, Chips also permits the description of hierarchically organized control. Adding layers of control for a complex system
could allow each sub-system to work at its own pace in a correct way, while together reaching a larger goal [19]. This layering could be achieved by adding annotations to our Chips blocks for instance. It would explicitly show the encapsulation of signals within a control layer.

* **Introducing GALS mechanisms(Globally Asynchronous Locally Synchronous):** Currently, Chips describes complex systems in the form of synchronous programs. The synchronous hypothesis is very convenient but can't hold if the models described get too large. Transmission delays and calculation time can be considered instantaneous as long as they do not add up too much. Applying GALS knowledge and formalisms [23] to enhance Chips would open the way for better up-scaling of the models designed.

* **Introducing GALS mechanisms(Globally Asynchronous Locally Synchronous):** Currently, Chips describes complex systems in the form of synchronous programs. The synchronous hypothesis is very convenient but can't hold if the models described get too large. Transmission delays and calculation time can be considered instantaneous as long as they do not add up too much. Applying GALS knowledge and formalisms [23] to enhance Chips would open the way for better up-scaling of the models designed.

* **Virtual clock system:** Finally, Chips models relevance should as well be ensured at the level of the timing constraints of the physical devices they represent. Clocks of a multiple devices system should be handled automatically thank to the use of the hardware description files. The BIP clock component would only serve as a virtual helper for simulation and model checking. It shall be automatically removed at the lowest level compilation of the programs when implementing models on real systems.

# 9 Conclusion

This paper described a model of adaptive cloud architecture for a variation of the TeaStore web application that has been implemented. The obtained results showed that control theory can effectively be applied to such computer system to improve its performances. Its design followed a full workflow:

* the rigorous analysis of the web application goal (keeping the server response time low),

* the distinction of the different means of actions to tune the system in order to achieve these goals (modifying the size of the cache at runtime),

* the design of a control theory block diagram of the system directly translatable to a Chips model (Figure 1),

* the design of a controller within the Chips model for a chosen component (Figure 3),

* the systematic transformation of the Chips model to a BIP one,

* the validation of the system design by simulating the execution of the BIP model and fine-tuning its parameters.

During the development of this sample project, simplifying decisions were made at different levels. The first ones were about the description of the model where the recommendation block was removed and only one user was modeled. Then, the real-time optimization of the cache size was chosen for this study, thus orienting the choice of the information held by the signals exchanged between the user and the server models. Finally, the kind of controller used was one of the most classical that exists to keep the demonstration as generic and easy to repeat as possible. According to the designer's will and necessities, other choices can be made to better suit a different project.
References

[1] Antonio Filieri et al. (2015): *Software Engineering Meets Control Theory*. In Paola Inverardi & Bradley R. Schmerl, editors: *10th IEEE/ACM International Symposium on Software Engineering for Adaptive and Self-Managing Systems, SEAMS 2015, Florence, Italy, May 18-19, 2015*, IEEE Computer Society, pp. 71–82, doi:10.1109/SEAMS.2015.12.

[2] Jóakim von Kistowski et al. (2018): *TeaStore: A Micro-Service Reference Application for Benchmarking, Modeling and Resource Management Research*. In: *2018 IEEE 26th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS)*, pp. 223–236, doi:10.1109/MASCOTS.2018.00030.

[3] Karl Johan Astrom & Tore Hagglund (1995): *Pid Controllers: Theory, Design, and Tuning*, 2e édition edition. ISA.

[4] Rim El Ballouli, Saddek Bensalem, Marius Bozga & Joseph Sifakis (2018): *DR-BIP - Programming Dynamic Reconfigurable Systems*. Technical Report TR-2018-3, Verimag Research Report.

[5] Ananda Basu, Saddek Bensalem, Marius Bozga, Jacques Combaz, Mohamad Jaber, Thanh-Hung Nguyen & Joseph Sifakis (2011): *Rigorous Component-Based System Design Using the BIP Framework*. IEEE Softw. 28(3), pp. 41–48, doi:10.1109/MS.2011.27.

[6] Simon Bliudze, Sophie Cerf & Olga Kouchnarenko (2025): *A Hybrid Modelling Approach for Hierarchical Control of Structured CPSs*. In: *Lecture Notes in Computer Science, Lecture Notes in Computer Science* 16065, Claudio Antares Mezzina and Alan Schmitt, Springer Nature Switzerland, Lille, France, pp. 175–196, doi:10.1007/978-3-031-99717-4_10.

[7] Simon Bliudze, Giuseppe De Palma, Saverio Giallorenzo, Ivan Lanese, Gianluigi Zavattaro & Brice Arléon Zemtsop Ndadji (2025): *Adaptable TeaStore*. In Giuseppe De Palma & Saverio Giallorenzo, editors: *Post-proceedings of the Workshop on Adaptable Cloud Architectures (WACA 2025), Electronic Proceedings in Theoretical Computer Science* 438, Open Publishing Association, pp. 1–14, doi:10.4204/EPTCS.438.1.

[8] Paul Caspi, Daniel Pilaud, Nicolas Halbwachs & J. A. Plaice (1987): *LUSTRE: a declarative language for real-time programming*. In: *Proceedings of the 14th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, POPL '87*, Association for Computing Machinery, New York, NY, USA, p. 178–188, doi:10.1145/41625.41641.

[9] Shang-Wen Cheng, An-Cheng Huang, D. Garlan, B. Schmerl & P. Steenkiste (2004): *Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure*. In: *Proceedings of the First International Conference on Autonomic Computing*, ICAC '04, IEEE Computer Society, USA, pp. 276–277, doi:10.1109/ICAC.2004.1301377.

[10] Mila Dalla Preda, Saverio Giallorenzo, Ivan Lanese, Jacopo Mauro & Maurizio Gabbrielli (2014): *AIOCJ: A Choreographic Framework for Safe Adaptive Distributed Applications*. In Benoît Combemale, David J. Pearce, Olivier Barais & Jurgen J. Vinju, editors: *Software Language Engineering*, Springer International Publishing, Cham, pp. 161–170, doi:10.1007/978-3-319-11245-9_9.

[11] Gwenaël Delaval, Eric Rutten & Hervé Marchand (2013): *Integrating Discrete Controller Synthesis into a Reactive Programming Language Compiler*. *Discrete Event Dynamic Systems* 23, pp. 385–418, doi:10.1007/s10626-013-0163-5.

[12] Robrecht Haesevoets, Eddy Truyen, Tom Holvoet & Wouter Joosen (2010): *Weaving the Fabric of the Control Loop through Aspects*. In Danny Weyns, Sam Malek, Rogério de Lemos & Jesper Andersson, editors: *Self-Organizing Architectures*, Springer, Berlin, Heidelberg, pp. 38–65, doi:10.1007/978-3-642-14412-7_3.

[13] Joseph L Hellerstein, Yixin Diao, Sujay Parekh & Dawn M Tilbury (2004): *Feedback control of computing systems*. John Wiley & Sons.

[14] Frédéric Jouault, Freddy Allilaire, Jean Bézivin & Ivan Kurtev (2008): *ATL: A model transformation tool*. *Science of Computer Programming* 72(1), pp. 31–39, doi:10.1016/j.scico.2007.08.002.
[15] Jeffrey Kephart & D.M. Chess (2003): *The Vision Of Autonomic Computing*. Computer 36, pp. 41–50, doi:10.1109/MC.2003.1160055.

[16] Rogério de Lemos (2023): *Software Self-adaptation and Industry: Blame MAPE-K*. In: 2023 IEEE/ACM 18th Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), IEEE, pp. 88–89.

[17] Mariachiara Puviani, Giacomo Cabri & Franco Zambonelli (2013): *A taxonomy of architectural patterns for self-adaptive systems*. In: Proceedings of the International C* Conference on Computer Science and Software Engineering, ACM, Porto Portugal, pp. 77–85, doi:10.1145/2494444.2494470.

[18] Brell Peclard Sanwouo Chekam, Clément Quinton & Paul Temple (2025): *Breaking the Loop: AWARE is the New MAPE-K*, p. 626–630. Association for Computing Machinery, New York, NY, USA, doi:10.1145/3696630.3728512.

[19] Riccardo Scattolini (2009): *Architectures for distributed and hierarchical Model Predictive Control – A review*. Journal of Process Control 19(5), pp. 723–731, doi:10.1016/j.jprocont.2009.02.003.

[20] Loïc Sylvestre, Jocelyn Sérot & Emmanuel Chailloux (2025): *Programming Parallelism on FPGAs with Eclat*. Int. J. Parallel Program. 53(4), p. 26, doi:10.1007/S10766-025-00801-7.

[21] Mirko Viroli, Jacob Beal, Ferruccio Damiani, Giorgio Audrito, Roberto Casadei & Danilo Pianini (2019): *From distributed coordination to field calculus and aggregate computing*. Journal of Logical and Algebraic Methods in Programming 109, p. 100486, doi:10.1016/j.jlamp.2019.100486.

[22] Brice Arléon Zemtsop Ndadji, Simon Bliudze & Clément Quinton (2025): *AdaptiFlow: An Extensible Framework for Event-Driven Autonomy in Cloud Microservices*. In Giuseppe De Palma & Saverio Gi-allorenzo, editors: Post-proceedings of the Workshop on Adaptable Cloud Architectures (WACA 2025), Electronic Proceedings in Theoretical Computer Science 438, Open Publishing Association, pp. 123–147, doi:10.4204/EPTCS.438.7.

[23] Weiyi Zhang, Zoran Salcic & Avinash Malik (2025): *System-Level Design, Modeling, and Verification of GALS Cyber-Physical Systems*. IEEE Open Journal of the Industrial Electronics Society 6, pp. 1137–1151, doi:10.1109/OJIES.2025.3591389.

[24] Enrique Zuazua & Enrique Fernández-Cara (2003): *Control theory: history, mathematical achievements and perspectives*. Boletín de la Sociedad Española de Matemática Aplicada 26, pp. 79–140. Available at https://api.semanticscholar.org/CorpusID:16939188.