Proceedings of the 26th International Workshop on
Configuration (ConfWS 2024) co-located with the 30th
International Conference on Principles and Practice of
Constraint Programming (CP 2024), Girona, Spain,
September 2-3, 2024.

Élise Vareilles, Chiara Grosso, Jose-Miguel Horcas, Alexander Felfernig

► To cite this version:

Élise Vareilles, Chiara Grosso, Jose-Miguel Horcas, Alexander Felfernig. Proceedings of the 26th International Workshop on Configuration (ConfWS 2024) co-located with the 30th International Conference on Principles and Practice of Constraint Programming (CP 2024), Girona, Spain, September 2-3, 2024. ConfWS 2024 - 26th International Workshop on Configuration, Sep 2024, Gerone, Spain. CEUR Workshop Proceedings, 3812, 110 p., 2024, Configuration Workshop 2024. hal-04770758

HAL Id: hal-04770758

https://imt-mines-albi.hal.science/hal-04770758v1

Submitted on 7 Nov 2024

**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 Attribution 4.0 International License
Elise Vareilles

Chiara Grosso

José Miguel Horcas

Alexander Felfernig (Eds.)

ConfWS 2024

26th International Workshop on Configuration

Girona, Spain, September 2-3, 2024

Proceedings
© 2024 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. Re-publication of material from this volume requires permission by the copyright owners.

Editors' addresses:
Universitat de Girona
Edifici Les Àligues
17071 Girona, Spain

elise.vareilles@mines-albi.fr, chiara.grosso@uniroma1.it, horcas@uma.es, alexander.felfernig@ist.tugraz.at
Preface

The 26th edition of the International Workshop on Configuration (ConfWS 2024) has been co-located with the International Conference on Principles and Practice of Constraint Programming (CP 2024 celebrating its 30th anniversary) hosted by the University of Girona in Spain. ConfWS 2024 has been a vibrant hub for researchers and industry professionals interested in configuration technology. In addition, for edition 2024, Siemens supported the event confirming its sponsorship.

ConfWS 2024 was a two-day event where high-quality research in all configuration-related technical areas has been presented. This edition had a special focus on Green Configuration which is related to EU Green Deal as stated in the EU Agenda 2050 to drive the EU community to a more sustainable future. Researchers and experts from academia and industry shared their contributions on the potentials of configuration in achieving sustainability goals for a more sustainable future. The program includes special sessions on green configuration and sustainability, including topics such as sustainability and configurator applications, efficient reasoning, configuration space learning, integration of large language models (LLMs), and further aspects related to problem solving and optimization.

ConfWS 2024 has been visited by 24 attendants from academia and industry. There were 14 papers submitted for peer review to ConfWS 2024. 14 papers were selected for publication in the workshop proceedings after a review by three independent reviewers per paper. In addition, three keynote speakers were invited from three industrial partners: Patrik Östberg and Sonja Arce (from Tacton) presented the talk "Inspiring & enabling manufacturers to shape and build a sustainable future"; Sophie Rogenhofer (from Siemens) presented the talk "Sustainability at Siemens - Scaling sustainability impact"; and Jean-Guillaume Fages (from Cosling) presented the talk "Automating complex computations with Cosling Configurator".

ConfWS 2024 introduced the role of a "Publicity and Social Media Chair" on the organization committee, a role played by Irene Campo Gay (Technical University of Denmark), who was in charge of promoting the workshop on social media and managing the official workshop accounts on LinkedIn and Twitter (X). In line with previous editions, the workshop participants selected the best paper ("Exploiting Large Language Models for the Automated Generation of Constraint Satisfaction Problems") and the best student paper ("Configuration Copilot: Towards Integrating Large Language Models and Constraints").

We want to thank the ConfWS 2024 authors for their high-quality submissions, the program committee members for their high-quality reviews, and the University of Girona and the CP Workshop Chair and CP Chairs for their proactive support. Further thanks goes to SIEMENS for sponsoring ConfWS 2024, and the keynote speakers for delivering inspiring presentations. The following projects by the Spanish Ministry of Science, Innovation and Universities also supported the workshop: TASOVA PLUS research network (RED2022-134337-T), IRIS (PID2021-122812OB-I00), and Data-pl (PID2022-138486OB-I00).

September 2024

Elise Vareilles, Chiara Grosso
José Miguel Horcas, Alexander Felfernig
**Workshop Chairs**

Elise Vareilles, IMT Mines Albi, France

Chiara Grosso, DIAG, University La Sapienza Rome, Italy

José Miguel Horcas, Universidad de Málaga, Spain

Alexander Felfernig, Graz University of Technology, Austria

**Publicity and Social Media Chair**

Irene Campo Gay, Technical University of Denmark, Denmark

**Award Chair**

Alexander Felfernig, Graz University of Technology, Austria

**Program Committee**

Gerhard Friedrich, Alpen-Adria-Universität Klagenfurt, Austria

Gerhard Leitner, Alpen-Adria-Universität Klagenfurt, Austria

Lothar Hotz, Hamburger Informatik Technologie-Center, Germany

Andreas Falkner, Siemens AG Österreich, Vienna, Austria

Lidia Fuentes, Universidad de Málaga, Spain

Yue Wang, Hang Seng University, Hong Kong

José Ángel Galindo, Universidad de Sevilla, Spain

Enrico Sandrin, University of Padova, Italy

Markus Stumptner, University of South Australia, Australia

Lars Hvam, Technical University of Denmark, Denmark

David Benavides, Universidad de Sevilla, Spain

Cipriano Forza, University of Padova, Italy

Albert Haag, Product Management GmbH, Germany

Alois Haselboeck, Siemens AG Österreich, Austria

Richard Comploi-Taupe, Siemens AG Österreich, Vienna, Austria

Tomi Mänistö, University of Helsinki, Finland

Viet-Man Le, Graz University of Technology, Austria

Abdourahim Sylla, Université Grenoble Alpes, France

Juha Tiihonen, Variantum, Finland

Franz Wotawa, Graz University of Technology, Austria

Rüdiger Dehn, Lino GmbH, Germany
# Contents

<table><tr><td>Configuration of Heterogeneous Agent Fleet: a Preliminary Generic Model<br>Thomas Pouré, Stephanie Roussel, Elise Vareilles, Gauthier Picard</td><td>8</td></tr><tr><td>Challenges in Automotive Hardware-Software Co-Configuration<br>Florian Jost, Carsten Sinz</td><td>17</td></tr><tr><td>Prospective and retrospective approaches to integrate life cycle assessment in<br>configurators: A multiple case study in the construction industry<br>Irene Campo Gay, Lars Hvam, Johan Ernfors</td><td>21</td></tr><tr><td>Premises, challenges and suggestions for modelling building knowledge using<br>the configuration paradigm<br>Bart Deschoolmeester, Elise Vareilles</td><td>29</td></tr><tr><td>Requirements and Architectures for Green Configuration<br>Andreas Falkner, Richard Comploi-Taupe, Katrin Müller, Sophie Rogenhofer</td><td>33</td></tr><tr><td>Developing an Algorithm Selector for Green Configuration in Scheduling<br>Problems<br>Carlos March Moya, Christian Perez, Miguel A. Salido</td><td>41</td></tr><tr><td>Instance Configuration for Sustainable Job Shop Scheduling<br>Christian Perez, Carlos March, Miguel A. Salido</td><td>50</td></tr><tr><td>Product visualization in configurators: laying the foundations for a comparative<br>description<br>Andrea Petterle, Enrico Sandrin, Cipriano Forza</td><td>54</td></tr><tr><td>Using Answer Set Programming for Assigning Tasks to Computing Nodes<br>Franz Wotawa</td><td>64</td></tr><tr><td>Responsible Configuration Using LLM-based Sustainability-Aware Explana-<br>tions<br>Sebastian Lubos, Alexander Felfernig, Lothar Hotz, Thi Ngoc Trang Tran, Seda<br>Polat-Erdeniz, Viet-Man Le, Damian Garber, Merfat El-Mansi</td><td>68</td></tr></table>
<table>
  <tbody>
    <tr>
      <td><strong>Semantics-Preserving Merging of Feature Models</strong><br>Mathias Uta, Viet-Man Le, Alexander Felfernig, Damian Garber, Gottfried Schenner, Thi Ngoc Trang Tran</td>
      <td>74</td>
    </tr>
    <tr>
      <td><strong>An extensive comparison of preprocessing methods in the context of configuration space learning</strong><br>Damian Garber, Alexander Felfernig, Viet-Man Le, Tamim Burgstaller, Merfat Elmansi</td>
      <td>81</td>
    </tr>
    <tr>
      <td><strong>Exploiting Large Language Models for the Automated Generation of Constraint Satisfaction Problems</strong><br>Lothar Hotz, Christian Bähnisch, Sebastian Lubos, Alexander Felfernig, Albert Haag, Johannes Twiefel</td>
      <td>91</td>
    </tr>
    <tr>
      <td><strong>Configuration Copilot: Towards Integrating Large Language Models and Constraints</strong><br>Philipp Kogler, Wei Chen, Andreas Falkner, Alois Haselboeck, Stefan Wallner</td>
      <td>101</td>
    </tr>
  </tbody>
</table>
# Configuration of Heterogeneous Agent Fleet: a Preliminary Generic Model

Thomas Pouré<fnref n="1" />,†, Stéphanie Roussel<fnref n="2" />,†, Elise Vareilles<fnref n="1" />,<fnref n="3" />,*,† and Gauthier Picard<fnref n="2" />,†

**Abstract**

A multitude of autonomous agents – encompassing a range of technologies, including robots and drones – represent a crucial modern tool for the execution of a multitude of tasks, including surveillance, delivery and the saving of lives. In order to optimally utilise these agents, it is vital to configure each agent, the composition of the entire fleet of agents and the mission plan associated with each agent in the most effective manner possible. The following article presents a knowledge model for the configuration of a fleet of heterogeneous agents, encompassing the three levels of configuration: agent configuration, agent fleet configuration, and mission plan configuration. It explicitly delineates the relationships between these three configuration levels, thereby facilitating rapid, efficient, robust, and simultaneous configuration. A toy problem illustrates our first proposals.

**Keywords**

Multi-level Configuration, Autonomous Agent, Knowledge Formalisation, Heterogeneous Fleet,

## 1. Introduction

With the increasing autonomy of drones and robots, fleets of agents are now being used for many different types of missions, such as exploration, rescue, disaster relief, civil and military security. In this article, the term "agent" is used to refer to any system that is capable of acting autonomously in a variety of environments, including ground, water, and air. The term encompasses a diverse range of platforms, including quadrupeds, bi-blades, underwater rockets, and others. Additionally, the term "agent" encompasses a wide range of capabilities, including communication, rescue, and delivery. Therefore, the term "agent" can be used to describe a diverse range of systems, from household robots to high-tech stealth military drones. Some of these applications require heterogeneous agent fleets, i.e. with different platforms, capabilities, mobility and equipment. Such fleet of heterogeneous agents may or may not be coordinated autonomously to carry out the missions to which the fleet is dedicated. For example, an exploration mission may require the collaboration

of ground agents with at least the ability to *Travel* and *Communicate*, and aerial agents with at least the ability to *Observe* and *Communicate*. The success of a multi-agent mission depends, among other things, on the configuration of the fleet executing it [1].

This paper addresses the problem of *multi-level configuration of heterogeneous agent fleets*, as presented in Fig. 1. By multi-level configuration, we mean the several interleaved problems that must be solved when setting up a fleet to carry out a mission. The first level is the simultaneous configuration of each agent (Agent Configuration Problem, ACP). The second consists in configuring the fleet itself (Fleet Configuration Problem, FCP), i.e. defining precisely what the composition of the fleet is. The final level is the fleet deployment problem in order to carry out dedicated missions in an efficient and robust way (Plan Configuration Problem, PCP). This multi-level configuration problem requires an analysis of the relationships between these three configuration levels, both upstream in fleet composition and downstream in fleet operation.

This multi-level configuration problem raises many research questions, such as:

* the representation/modeling of configuration knowledge (compact modeling language),

* eliciting constraints (what is allowed or forbidden) and criteria (what is preferable) that apply both to the fleet configuration and to each robot in it, and

* the development of algorithms to generate optimal or, at least, good-quality solutions.

This problem can be tackled in several ways. First of all, there is the question of how to express knowledge,

ConfWS'24: 26th International Workshop on Configuration, Sep 2–3, 2024, Girona, Spain

*Corresponding author.

†These authors contributed equally.

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

thomas.poure@student.isae-supaero.fr (T. Pouré);

stephanie.roussel@onera.fr (S. Roussel);

elise.vareilles@isae-supaero.fr (E. Vareilles);

gauthier.picard@onera.fr (G. Picard)

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

https://onera.academia.edu/SRoussel (S. Roussel);

https://pagespro.isae-supaero.fr/elise-vareilles/ (E. Vareilles);

https://gauthier-picard.info/ (G. Picard)

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

0000-0001-7033-555X (S. Roussel); 0000-0001-6269-8609

(E. Vareilles); 0000-0002-9888-9906 (G. Picard)

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

© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License

Attribution 4.0 International (CC BY 4.0).

<footnote n="1">¹ISAE SUPAERO, Université de Toulouse, 10 avenue Édouard Belin, BP 54032 - 31055 Toulouse CEDEX 4, France</footnote>

<footnote n="2">²DTIS, ONERA, Université de Toulouse, 2 avenue Édouard Belin, BP 74025 - 31055 Toulouse CEDEX 4, France</footnote>

<footnote n="3">³CGI / IMT Mines Albi, Université de Toulouse, allée des sciences, 81000 Albi, France</footnote>
<figure><img src="image_6.png" /><figcaption>**Figure 1:** Multi-level configuration of an heterogeneous fleet of robots.</figcaption></figure>

constraints and preferences, both from the point of view of fleet configuration and from the point of view of performance and robustness in the context of mission [2]. Approaches such as constraint programming and multi-agent modeling [3, Chap.2 and 15] appear to be suitable candidates.

Following several works dedicated to Search and Rescue applications such as [4] and [5], a mission consists here in the execution of several tasks distributed on an intervention zone represented by a graph. A fleet and a plan of action are configured in order to accomplish the mission, i.e. successfully complete all the tasks. The performance of a fleet for a mission can be evaluated along several criteria: the global time required for performing all tasks, the fleet cost (platform, equipment), the fleet and the plan robustness (capacity of the fleet/the plan to support damages and complications), etc.

This article focuses on initial ideas for modeling the knowledge of this multi-level configuration problem of heterogeneous agents fleets. More precisely, we propose a formal modelling of the inputs of each level configuration problem, along with the decisions that have to be made. The formalization of constraints associated with each level are out of scope of this paper and are left for future work.

The paper is organized as follows. In Section 2, we formally describe the type of mission we consider. Then, Sections 3, 4 and 5 are respectively dedicated to the Agent Configuration Problem or ACP, the Fleet Configuration Problem or FCP and the Plan Configuration Problem or PCP. In each of these sections, we formally present the inputs of the problem, the associated decision variables

and an illustrative example. Finally, we conclude and discuss future works in Section 6.

## 2. Mission

A mission allows to represent the several tasks that the agents have to perform and the graph on which they can move. The elements composing a mission can be represented in a UML diagram as illustrated in Fig. 2. Those elements are first briefly described and then formalized in a second step. In our work, we have made several assumptions on a mission. A mission is therefore:

* **deterministic:** the mission is perfectly known from the beginning and during the fleet's intervention, and agents cannot suffer from malfunctions,

* **static:** the mission remains static throughout the fleet's intervention. No edges or vertices are introduced or removed during the mission.

### 2.1. Description

A Mission is composed of the following elements.

* The location on which the agents can evolve is represented by a connected and non-directed Graph. Such a graph is composed of vertices (Vertex class), representing way points or places of interest in the mission context, and edges (Edge class), representing routes for moving.
<figure><img src="image_7.png" /><figcaption>Figure 2: UML representation of a mission.</figcaption></figure>

* One of the vertices is called the base, and is the location at which the agents start and finish their missions.

* The actions that the agents have to perform to achieve the mission are called Tasks. Each task is assigned to a single vertex, that represents the location at which it must be executed. A capability is associated to each task, it is the requirement to perform a task.

For the agent to be able to move through the graph and execute task, we define two additional classes.

* A Capability describes how an agent accomplishes the mission's tasks. More precisely, each task requires a single specific capability to be executed. Examples of capabilities are *observe*, *grab material*, *transport a injured person*, etc.

* One instance of Trafficability is associated to each edge, representing the edge practical environment for agent moves. Instances of Trafficability could be *Aerial*, *Terrestrial* or more fine-grained properties such as *Forest*, *Field*, *Street*, etc. Note that a trafficability could also be combinations such as *Terrestrial and Aerial*.

## 2.2. Formalization

We propose here a mathematical formalization of the mission, that can be used as input for the multi-level configuration problem.

A mission is a tuple $m = (V, E, T, TV, C, CT, R, RE)$ where:

* $V = (1, \dots, n_V)$ is the vector of vertices. We suppose that vertex with number 1 is the base.

* $E = (e_{i,j})_{i,j \in [1..n_V]^2}$ is the adjacency matrix of size $n_V^2$ that represents the connection between vertices

$V$. For all vertices $i, j \in [1..n_V]^2$, $e_{i,j} = 1$ if there exists an edge between vertices $i$ and $j$, $e_{i,j} = 0$ otherwise.

* $T = (1, \dots, n_T)$ is the vector of tasks that have to be performed during the mission.

* $TV = (tv_i)_{i \in [1..n_T]}$ is a vector of size $n_T$ such that for all task $i \in [1..n_T]$, $tv_i \in [1..n_V]$ is the vertex the task $i$ is assigned to.

* $C = (1, \dots, n_C)$ is the vector of capability types.

* $CT = (ct_i)_{i \in [1..n_T]}$ is a vector of size $n_T$, such that for each task $i \in [1..n_T]$ in $m$, $ct_i \in [1..n_C]$ represents the capability required by task $i$.

* $R = (1, \dots, n_R)$ is the vector of trafficabilities.

* $RE = (re_{i,j})_{i,j \in [1..n_V]^2}$ is a matrix of size $n_V^2$, such as for each edge $(i, j) \in [1..n_V]^2$, $re_{i,j} \in [1..n_R]$ is the trafficability of the edge $e_{i,j}$ in $m$.

We call the graph associated to a mission $m$ the pair $(V, E)$. A mission $m$ is said to be well-formed if the following assumptions hold:

* The graph does not contain any edge from a vertex to itself.

$$ \forall i \in [1..n_V], e_{i,i} = 0 \quad (1) $$

* The graph is non-oriented and the trafficability matrix is symmetrical.

$$ E = E^T \quad (2) $$

$$ RE = RE^T \quad (3) $$

* The graph is connected, i.e. from any two vertices $i$ and $j$, there exists a path of edges connecting them. Formally, $\forall i, j \in [1..n_V]^2, \exists k \in \mathbb{N}^*, \exists(v_1, \dots, v_k) \in [1..n_V]^k$, such that:

$$ v_1 = i, v_k = j \quad (4) $$

$$ \forall r \in [1..k-1], \quad e_{v_r, v_{r+1}} = 1 \quad (5) $$

* For any vertices $i, j \in [1..n_V]^2$, $e_{i,j} = 1$ means that there is exactly one edge between vertices $i$ and $j$.

In order to illustrate the notations defined previously, we consider the following toy example.

## 2.3. Toy Problem Mission

We define a simple Search & Rescue mission $m$, illustrated in Fig. 3, composed of the following elements.

* The vertices vector of locations is $V = (1 \ 2 \ 3)$, where 1 is the "base" (■), 2 is the "ruins" (■), and 3 is the "aid camp" (■).
<figure><img src="image_8.png" /><figcaption>**Figure 3:** Illustration for Example 2.3. Three locations are considered: a base (®, ruins ( Bau), to explore, and an aid camp ( Bau) to supply. Moving from the base to the ruins requires an aerial agent ( A), while moving to the camp requires a terrestrial agent ( S).</figcaption></figure>

* The edges matrix of paths is $E = \begin{pmatrix} 0 & 1 & 1 \\ 1 & 0 & 1 \\ 1 & 1 & 0 \end{pmatrix}$.

For instance, $e_{1,3} = 1$ holds, meaning that it is possible to directly go from vertex 1 ("base") to vertex 3 ("aid camp").

* The tasks vector is $T = (1 \ 2)$, where 1 is "explore the ruins" ( ® ), and 2 is "deliver supplies" ( ® ).

* The assignment of tasks to the vertices is the vector $TV = (2 \ 3)$, representing that task 1 ("explore the ruins") and task 2 ("deliver supplies") must respectively be executed in vertex 2 ("ruins") and vertex 3 ("aid camp").

* The capabilities vector is $C = (1 \ 2)$, where 1 is "carry" ( C ) and 2 is "observe" ( O ).

* The assignment of capabilities to the tasks is the vector $CT = (2 \ 1)$, meaning that capability 2 ("observe") is required for task 1 ("explore the ruins") and capability 1 ("carry") is required for task 2 ("deliver supplies").

* The trafficabilities are $R = (1 \ 2)$, where 1 is "terrestrial" ( S ), and 2 is "aerial" ( A ).

* The assignment of trafficabilities to the edges is the
matrix $RE = \begin{pmatrix} 0 & 2 & 1 \\ 2 & 0 & 1 \\ 1 & 1 & 0 \end{pmatrix}$. For instance the path (1,2) has the trafficability 2 ("aerial"), whereas the path (2,3) has the trafficability 1 ("terrestrial").

3. Agent Configuration Problem

In this section, we present the model associated with the
Agent Configuration Problem (ACP), which consists in
deciding agents’ composition wrt. a catalog of platform

types and equipment types, by using the notion of agent
pattern.

**3.1. Description**

As illustrated in Fig. 4, an AgentPattern represents a type of robot or a type of drone that can act somewhat autonomously. Elements composing an agent pattern are divided as follows:

* Platform represents the skeleton of an agent pattern. Each agent pattern has a single platform.

* Each Platform is associated to a unique Platform-Type representing the agent pattern skeleton type. Examples of such platform types could be *aerial*, *terrestrial*, *marine*. It would also be possible to consider more fine-grained platform types, such as *quadcopter* or *submarine*. The platform type limits and defines most of the agent pattern characteristics.

* Equipment represents the payload that can equip an agent pattern. An agent pattern can be equipped with several equipments.

* Each Equipment is associated to a unique EquipmentType, which represents the type of the equipment (e.g. camera, sensor, motor).

* Available PlatformTypes and EquipmentTypes are grouped in a Catalog.

An agent is able to interact with the mission throughout
two connections to the mission description:

* Each Equipment instance has a set of Capability instances, allowing agents to execute tasks. If an agent pattern is equipped with an equipment that provides the capability associated to a task, then any agent following that pattern will be able to perform the task.

* Each PlatformType instance is associated with a set of Trafficability instances representing the types of environments it is compatible with. Consequently, an agent pattern is compatible with an edge if and only if the edge trafficability belongs to the agent pattern platform type set of compatible trafficabilities.

**3.2. Formalization**

We first formalize the inputs of the agent configuration
problem and then define the decision variables. We next
present some assumptions on the problems we consider
and finally illustrate the concepts on the toy example.
<figure><img src="image_9.png" /><figcaption>Figure 4: UML representation the ACP.</figcaption></figure>

### 3.2.1. Inputs

Let $m$ be a mission. A catalog on $m$ is a tuple $cat_m = (P, Q, \max_Q, RP, CQ)$ where:

* $P = (1, \dots, n_P)$ is the platform types vector,

* $Q = (1, \dots, n_Q)$ is the equipment types vector,

* $\max_Q \in \mathbb{N}^*$ is an upper bound on the number of instances of each equipment type that can be carried by an agent pattern,

* $RP = (rp_{i,j})_{i,j \in [1..n_P] \times [1..n_R]}$ is the platform/traf ficability compatibility matrix of size $n_Q \cdot n_R$. For each platform type $i \in [1..n_P]$ and each trafficability $j \in [1..n_R]$, $rp_{i,j} = 1$ if the platform type $i$ is compatible with trafficability $j$. Otherwise, $rp_{i,j} = 0$.

* $CQ = (cq_{i,j})_{i,j \in [1..n_Q] \times [1..n_C]}$ is the equipment/capability relation matrix of size $n_Q \cdot n_C$. For each equipment type $i \in [1..n_Q]$ and each capability $j \in [1..n_C]$, $cq_{i,j} = 1$ if the equipment type $i$ provides the capability $j$. It equals 0 otherwise.

The catalog is the only input of the ACP.

### 3.2.2. Assumptions

A catalog *cat* should satisfy the following assumptions.

* **Task Feasibility.** For each task, there is at least one equipment type in the catalog that provides its capability, which translates into:

$$ \forall j \in [1..n_T], \sum_{i=1}^{n_Q} cq_{i,ct_j} \ge 1 \quad (6) $$

* **Task Reachability.** For each task, there exists a platform type and a path from the base to the task's vertex such that the platform type is compatible with all the path's edges trafficabilities. Formally, $\forall i \in [1..n_T], \exists j \in [1..n_P], \exists k \in \mathbb{N}^*, (v_1, \dots, v_k) \in [1..n_V]^k, \text{ s. t.}$

$$ v_1 = 1, v_k = tv_i \quad (7) $$

$$ \forall r \in [1..k-1]^2, \quad e_{v_r, v_{r+1}} = 1 \quad (8) $$

$$ rp_{j, re_{v_r, v_{r+1}}} = 1 \quad (9) $$

Those two assumptions ensure that for each task in the mission, there exists an agent pattern compatible with the task perform it.

### 3.2.3. Decision Variables

We present here the decision variables that must be assigned a value when solving an ACP. To do so, we first formally define an *agent pattern*.

For a given catalog *cat*, an agent pattern is a tuple $a_{cat} = (ap, AQ)$ where:

* $ap$ is an integer in $[1..n_P]$ that represents the platform of catalog *cat* associated with $a_{cat}$.

* $AQ = (aq_i)_{i \in [1..n_Q]}$ is the $a_{cat}$ equipment vector of size $n_Q$. For all equipment type $i \in [1..n_Q]$, $aq_i$ is an integer in $[1..\max_Q]$ that represents the number of equipment type $i$ present in $a_{cat}$.

For a given catalog *cat*, the objective of ACP is to compute a tuple $\mathcal{T}_{cat} = (1, \dots, n_{\mathcal{J}})$ where each element is an index of an agent pattern, as defined previously, and $n_{\mathcal{J}}$ the number of elements in the tuple.

As we do not consider any constraint in this paper, there are $n_{\mathcal{J}} = n_P \cdot n_Q^{\max_Q}$ possible agent patterns. In real world applications, the ACP should of course satisfy some constraints (e.g. max payload, mission's budget, etc.) and could optimize some criteria (e.g. cost minimization). This is out of scope of this paper, and so are the precise definitions of platform and equipment attributes related to them (such as weight, price, etc.). Note that even with constraints consideration, the vector $\mathcal{T}_{cat}$ might be too large to be exhaustively explored.

## 3.3. Toy Problem ACP

We consider the mission $m$ defined in Subsection 2.3.

We define the catalog *cat* the following way.

* The platform types vector is $P = (1 \ 2)$, where 1 is "UAV" (UAV) and 2 is "rover" (rover).

* The equipment types vector is $Q = (1 \ 2)$, where 1 is "camera" (Camera) and 2 is "trunk" (Trunk).
<figure><img src="image_10.png" /><figcaption>Figure 5: UML representation of the FCP.</figcaption></figure>

• the maximum number for each equipment instance on an agent pattern is $max_Q = 1$.

• The platform/trafficability compatibility matrix is
  $$RP = \begin{pmatrix} 0 & 1 \\ 1 & 0 \end{pmatrix}.$$ In this example, $rp_{1,2} = 1$ holds, meaning that platform 1 ("UAV") is compatible with the trafficability 2 ("aerial"). However, as $rp_{1,1} = 0$, platform 1 is not compatible trafficability 1 ("terrestrial").

• The equipment/capability relation matrix is $CQ = \begin{pmatrix} 1 & 0 \\ 0 & 1 \end{pmatrix}$. In this example, $rp_{1,1} = 1$ holds, meaning that the equipment 1 ("camera") provides the capability 2 ("observe"). However, $rp_{1,2} = 0$, which means that this equipment does not provide capability 2 ("carry").

The two following agent patterns belong to $\mathcal{T}_{cat}$:

• $\mathbf{a}_1 = (1, (1 \ 0))$ is a UAV equipped with one camera and zero trunk.

• $\mathbf{a}_2 = (2, (1 \ 1))$ is a rover equipped with one camera and one trunk.

There is a total of $n_{\mathcal{F}} = 6$ possible agent patterns ($\mathcal{T}_{cat} = (\mathbf{a}_1, \dots, \mathbf{a}_6)$).

# 4. Fleet Configuration Problem

In this section, we present the model associated with the Fleet Configuration Problem (FCP), which aims at deciding the composition of the fleet wrt. the available stock.

## 4.1. Description

Fig. 5 contains a UML representation of the Fleet Configuration Problem. The FCP class takes as an input the set of AgentPattern computed by the ACP, as presented in the previous section. Its output is a Fleet, i.e. a collection of Agents, where each Agent is associated to a unique AgentPattern.

In order to model the fact that equipment and platform are available in limited quantities, we define the class Stock. Such a class is associated to a set of Platforms and a set of Equipments. The FCP takes an instance of Stock as an input. Even if it is clear that the stock will impose hard constraints on FCP, the precise formalization of these constraints is left for future work.

## 4.2. Formalization

We first formalize the inputs of the agent configuration problem, then define the decision variables and illustrate the formalization on the toy example.

### 4.2.1. Inputs

Let cat be a catalog. The FCP associated to this catalog has two inputs:

• A stock associated with cat, denoted $s_{cat}$, and defined by a pair $(P_s, Q_s)$ where:

- $P_s = (p_i)_{i \in [1..n_P]}$ is a vector of size $n_P$ such that for each platform type $i \in [1..n_P]$ in cat, $p_i \in \mathbb{N}^*$ defines how many type $i$ platform instances are in the stock.

- $Q_s = (q_j)_{j \in [1..n_Q]}$ is a vector of size $n_Q$ such that for each equipment type $j \in [1..n_Q]$ in cat, $q_j \in \mathbb{N}^*$ defines how many type $j$ equipment instances are in the stock.

• A vector of agents pattern $\mathcal{T}_{cat}$. Such a vector can for instance come from the output resulting from the ACP solving.

### 4.2.2. Decision Variables

Given a catalog cat, a stock $s_{cat}$ on this catalog, and $\mathcal{T}_{cat}$ a vector of the agent patterns, a fleet is a tuple $\mathbf{f}_{s_{cat}, \mathcal{T}_{cat}} = (\mathbf{n}_a, \mathcal{A}_f)$ where:

• $\mathbf{n}_a$ is the size of the fleet.

• $\mathcal{A}_f = (\mathbf{a}_i)_{i \in [1..\mathbf{n}_a]}$ is the finite vector of size $\mathbf{n}_a$ of agents in the fleet such as, for each $i \in [1..\mathbf{n}_a]$, $\mathbf{a}_i \in [1..n_{\mathcal{F}}]$ is the index of the agent pattern of the agent $i$ in the fleet.

Note that the model allows to have the same agent pattern present several times in $\mathcal{A}_f$, representing the fact that there are some identical agents in the fleet.
## 4.3. Toy Problem FCP

We consider the mission *m* defined in Subsection 2.3, the catalog *cat* and the agent patterns *Tcat* defined in Subsection 3.3.

We define the stock *s*<sub>cat</sub> the following way.

* The platform instance vector is $P_s = (2 \ 1)$, meaning that there are 2 instances of type 1 platform ("UAV" - 🚗) and 1 instance of type 2 platform ("rover" - 🚗) in the stock.

* The equipment instances vector is $Q_s = (2 \ 1)$. In this example, there are two instances of type 1 equipment ("camera" - 📷) and one instance of type 2 equipment ("trunk" - 📶) in the stock.

With this stock, it is possible to configure several fleets of agents. For instance, we define two fleets as follows:

* $\mathbf{f}_{s_{cat}, \mathcal{T}_{cat}}^1 = (1, \mathbf{a}_2)$, is a fleet composed of a single agent with the pattern $\mathbf{a}_2$ (a rover equipped with one camera and one trunk - 🚗+ 📷+ 📶).

* $\mathbf{f}_{s_{cat}, \mathcal{T}_{cat}}^2 = (2, \mathbf{a}_1, \mathbf{a}_2)$, is a fleet composed of two agents with the respective patterns $\mathbf{a}_1$ (a UAV equipped with one camera - 🚗+ 📷) and $\mathbf{a}_2$ (a rover equipped with one camera and one trunk - 🚗+ 📷+ 📶).

# 5. Plan Configuration Problem

In this section, we present the model associated with the Plan Configuration Problem (PCP), which aims at deciding the agents' positions and tasks all along the mission.

## 5.1. Description

The plan configuration is the last problem to solve in order to get a solution for the multi-level configuration problem. As illustrated on Fig. 6, it takes as input a Mission and a Fleet. Its output is a Plan which consists of an AgentPlan for each Agent in the fleet. For each agent in the fleet, an AgentPlan describes exhaustively at any given time step the position of the agent and the task currently executed, if any.

## 5.2. Formalization

We first formalize the inputs of the plan configuration problem and then define the decision variables.

### 5.2.1. Inputs

For a catalog *cat*, a stock on this catalog, *s*<sub>cat</sub>, the PFD associated to this stock requires two additional inputs:

<figure><img src="image_11.png" /><figcaption>Figure 6: UML representation of the PCP.</figcaption></figure>

* a mission *m*,

* a fleet $f_{s_{cat}, \mathcal{T}_{cat}}$.

### 5.2.2. Decision Variables

In order to represent the position of each agent in the solution plan, we use binary decision variables (*Vpl* matrix) that indicate whether an agent is at a given position at each time step. Similarly, for each task, we use binary decision variables indicating whether an agent executes this task at the time step (*Tpl* matrix).

Formally, for a catalog *cat*, a stock on this catalog, *s*<sub>cat</sub>, a mission *m*, a fleet $f_{s_{cat}, \mathcal{T}_{cat}}$, a plan is a tuple $\mathbf{pl}_{m, f_{s_{cat}, \mathcal{T}_{cat}}} = (\mathbf{H}, \mathbf{Tpl}, \mathbf{Vpl})$ where:

* $\mathbf{H} \in \mathcal{N}^*$ is the temporal plan horizon.

* $\mathbf{Tpl} = (\mathbf{tpl}_{i,j,h})_{i,j,h \in [1..n_a] \times [1..n_T] \times [1..\mathbf{H}]}$ is the allocation of tasks over agents for each time steps, represented as a tensor of size $n_a \cdot n_T \cdot \mathbf{H}$. For each agent $i \in [1..n_a]$, each task $j \in [1..n_T]$ and each time step $h \in [1..\mathbf{H}]$, $\mathbf{tpl}_{i,j,t} = 1$ if the agent $\mathbf{a}_i \in \mathcal{A}_f$ is executing the task $j$ at the time $h$. It equals 0 otherwise.

* $\mathbf{Vpl} = (\mathbf{vpl}_{i,j,h})_{i,j,h \in [1..n_a] \times [1..n_T] \times [1..\mathbf{H}]}$ is the position of the agents for each time steps, defined by a tensor of size $n_a \cdot n_T \cdot \mathbf{H}$. For each agent $i \in [1..n_a]$, each task $j \in [1..n_T]$ and each time step $h \in [1..\mathbf{H}]$, $\mathbf{vpl}_{i,j,t}$ equals 1 if the agent $\mathbf{a}_i \in \mathcal{A}_f$ is at the vertex $j$ at the time $h$. It equals 0 otherwise.

Through this plan formalization, moves of agents are not explicitly described, but this piece of information could be retrieved through their positions.

## 5.3. Toy problem PCP

We consider the definitions of mission *m*, catalog *cat*, introduced in the three previous examples.
<figure><img src="image_12.png" /><figcaption>**Figure 7:** Execution of plan $\textbf{pl}_{m,f_{\text{scat}},\mathcal{F}_{\text{cat}}}$ from Example 5.3: starting from the base, the UAV moves to the ruins while the rover moves to the aid camp; then, they both perform the required tasks in their respective locations; finally, they both come back to the base.</figcaption></figure>

We consider the following plan for the fleet
$f_{\text{scat},\mathcal{F}_{\text{cat}}}^2 = (2, (a_1, a_2)):$

$\textbf{pl}_{m,f_{\text{scat}},\mathcal{F}_{\text{cat}}}$ = (3, (Tpl1 Tpl2)), (Vpl1 Vpl2)), illustrated in Fig. 7, where:

* Tpl1 = $\begin{pmatrix} 0 & 1 & 0 \\ 0 & 0 & 0 \end{pmatrix}$ is the task allocation matrix of the first agent of the fleet, that has pattern $a_1$ (platform 🚗). It performs the task "explore the ruins" (ITER) at time step 2.

* Vpl1 = $\begin{pmatrix} 1 & 0 & 1 \\ 0 & 1 & 0 \\ 0 & 0 & 0 \end{pmatrix}$ describes the movement of the first agent of the fleet, that has pattern $a_1$. It starts at the "base" (📖) than goes to the "ruins" (📖) and comes back to the "base" (📖).

* Tpl2 = $\begin{pmatrix} 0 & 0 & 0 \\ 0 & 1 & 0 \end{pmatrix}$ is the task allocation matrix of the second agent of the team, with pattern $a_2$ (platform 🚗). It performs the task "deliver supplies" (📖) at the time step 2.

* Vpl2 = $\begin{pmatrix} 1 & 0 & 1 \\ 0 & 0 & 0 \\ 0 & 1 & 0 \end{pmatrix}$ describes the movement of the second agent of the team, with pattern $a_2$. It starts at the "base" (📖) than goes to the "aid camp" (📖) and comes back to the "base" (📖).

Note that the time steps used in that example plan give a macro view of the agents actions. It would be possible to have a much finer discretization of the time in order to handle temporal constraints such as task duration, or edge traversal duration.

# 6. Conclusion

In this paper, we model and formalize the multi-level configuration problem for a fleet of heterogeneous agent. This problem is decomposed into three problems, ACP, FCP and PCP and for each of them, we formally define their inputs and their decision variables and we illustrate them on a toy problem. We focus on Search and Rescue missions where tasks have to performed on some nodes of a given graph.

The work presented in this paper is a first step for solving the multi-level configuration problem. As mentioned in the paper, the next step is to formally define the set of constraints and the eventual criteria associated to ACP, FCP and PCP. To do so, it will be possible to study the literature associated with each problem, such as [1] for ACP, [3, 6] for FCP and [7, 8, 9] for PCP.

Then, we have presented the three configuration problems independently but in practice, they are interleaved. For instance the output of ACP is an input of FCP, and the output of FCP is an input for PCP. In the other direction, the evaluation of solutions produced by PCP and FCP can influence the choices made in ACP. If the evaluation of the overall multi-level configuration solution is not satisfactory, there might be several interactions between each level before converging (if any convergence is possible). In order to avoid these interactions, it would be possible to solve all the configuration problems simultaneously. Some works have started contributing towards that objective [10, 11, 12, 2]. Following those works, we aim at proposing a global solver/architecture for solving the multi-level configuration problem.

Finally, we have considered here a simple model of a Search and Rescue mission. It would be possible to make it more realistic in several ways. For instance, it would be possible to consider: more complex mission (e.g. with multiple bases), autonomy constraints on agents forcing them to recharge in some specific locations, more
complex tasks (e.g. requiring multiple capabilities, or
requiring synchronisation between multiple agents), a
non-deterministic setting (e.g. uncertainty on tasks dura-
tion) and a dynamic environment (e.g. discover the edges
trafficability, agent's loss).

Acknowledgments

The authors would like to thank the ONERA, ISAE-SUPAERO and ENAC Federation for its support of this work. This work is partly founded by the ONERA federative project on cooperative and interactive intelligent multi-robot systems (SICICOD).

References

[1] É. Vareilles, S. Roussel, G. Picard, PERFECT: performant and robust read-to-fly fleet configuration: from robot to mission plan, in: J. M. Horcas, J. A. Galindo, R. Comploi-Taupe, L. Fuentes (Eds.), Proceedings of the 25th International Workshop on Configuration (ConfWS 2023), Málaga, Spain, September 6-7, 2023, volume 3509 of *CEUR Workshop Proceedings*, CEUR-WS.org, 2023, pp. 104–107.

[2] C. Lei, W.-H. Lin, L. Miao, A two-stage robust optimization approach for the mobile facility fleet sizing and routing problem under uncertainty, Computers & Operations Research 67 (2016) 75–89.

[3] G. Weiss, Multiagent systems, Second Edition, MIT press, 2013.

[4] G. Radzki, P. Golinska-Dawson, G. Bocewicz, Z. Banaszak, Modelling robust delivery scenarios for a fleet of unmanned aerial vehicles in disaster relief missions, Journal of Intelligent & Robotic Systems 103 (2021) 1–18.

[5] T. Calamoneri, F. Corò, S. Mancini, A realistic model to support rescue operations after an earthquake via uavs, IEEE Access 10 (2022) 6109–6125.

[6] J. F. Hübner, J. S. Sichman, O. Boissier, Moise+ towards a structural, functional, and deontic model for mas organization, in: Proceedings of the first international joint conference on Autonomous agents and multiagent systems: part 1, 2002, pp. 501–502.

[7] J. Blythe, An overview of planning under uncertainty, Artificial Intelligence Today: Recent Trends and Developments (2001) 85–110.

[8] Ç. Koç, T. Bektaş, O. Jabali, G. Laporte, Thirty years of heterogeneous vehicle routing, European Journal of Operational Research 249 (2016) 1–21.

[9] L. Berghman, Y. Kergosien, J.-C. Billaut, A review on integrated scheduling and outbound vehicle routing problems, European Journal of Operational Research 311 (2023) 1–23.

[10] R. F. Lemme, E. F. Arruda, L. Bahiense, Optimization model to assess electric vehicles as an alternative for fleet composition in station-based car sharing systems, Transportation Research Part D: Transport and Environment 67 (2019) 173–196.

[11] R. Pinto, A. Lagorio, R. Golini, Urban freight fleet composition problem, IFAC-PapersOnLine 51 (2018) 582–587.

[12] H. R. Sayarshad, R. Tavakkoli-Moghaddam, Solving a multi periodic stochastic model of the rail-car fleet sizing by two-stage optimization formulation, Applied Mathematical Modelling 34 (2010) 1164–1174. doi:https://doi.org/10.1016/j.apm.2009.08.004.
# Challenges in Automotive Hardware-Software Co-Configuration

Florian Jost<fnref n="1" />,*, Carsten Sinz<fnref n="2" />

**Abstract**

Car manufacturers offer their customers an enormous number of configuration options to individualize their vehicles. While configuration options mostly covered physical components in the past, over the last years the number of software-related options has increased immensely. Existing systems for car configuration should thus be optimized and extended to handle the shift towards more software-related features, e.g. for automatic driver assistance systems. In this article, we highlight different problems and properties combined systems of hardware-software configurations have to tackle in an automotive context.

**Keywords**

Automotive Configuration, Hardware-Software Co-Configuration, Future Challenges

## 1. Introduction

Modern car manufacturers offer a vast number of configuration options for their products. In the past, these options covered parts and functionality that were primarily based on physical components. With the ongoing electrification of cars, the rate of functionality implemented in software and thus also the variance in software is increasing [1].

But not only the number of configuration options is increasing, the same holds for the complexity of their interdependencies. Some options are mutually dependent, others are mutually exclusive. This results in an enormous configuration space with more than $10^{100}$ possible constructable (valid) configurations for a product line [2]. The inherent complexity of the problem challenges automotive manufacturers in all stages of the product lifecycle, from development, through production, sales to after-sales. Due to the increasing importance of software in this context, hardware-software co-configurations are playing an increasingly substantial role.

In this publication, we describe upcoming or already existing problems that arise in the context of increasingly software-driven vehicles.

## 2. State of the Art

Classically, the possible configurations through which a car can be realized are represented by configuration options. In addition to different color finishes, these can also describe different engine designs, or optional extras such as an improved infotainment system. An existing order, i.e. a set of configuration options, can then be translated into the physical parts that are needed to manufacture the particular car instance.

Historically, with the increasing emergence of software functionality and the associated ECUs (electronic control units) in the car, the existing hardware configuration systems were adapted to also manage software configurations. But, as automotive software can have a wide variety of requirements for the installed hardware (e.g. sensors for autonomous driving systems), software configuration cannot be treated independent of the hardware configuration. However, this close connection is often not reflected in current configuration systems, where mostly software configuration is treated as a second configuration step, after the physical components have been selected and configured.

Additionally, software often comes with configurable parameters that can be set to different values. As an example, emergency call numbers differ from country to country and have to be set accordingly. The basic functionality of the software remains the same, independent of the value the parameter is set to. Thus, instead of writing software for each possible parameter setting, an ECU runs through an additional configuration step, where correct parameter values are written to the ECU (special bits get set in the programmable ROM of the ECU). The high-level software then can adapt its functionality by reading the corresponding bits in the ROM. In the au-

<footnote n="1">¹Mercedes-Benz AG, Leibnitzstr. 2, Böblingen, 71032, Germany</footnote>

<footnote n="2">²Karlsruhe University of Applied Sciences, Moltkestraße 30, 76133 Karlsruhe, Germany</footnote>

<footnote>ConfWS'24: 26th International Workshop on Configuration, Sep 2-3,
2024, Girona, Spain</footnote>

<footnote>* Corresponding author.</footnote>

<footnote>florian_benedikt.jost@mercedes-benz.com (F. Jost);
carsten.sinz@h-ka.de (C. Sinz)</footnote>

<footnote>0009-0006-9670-8856 (F. Jost); 0000-0001-9718-1802 (C. Sinz)</footnote>

<footnote>© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License
Attribution 4.0 International (CC BY 4.0)</footnote>

<footnote>CEUR Workshop Proceedings (CEUR-WS.org)</footnote>
tomotive sector, this configuration step is often called variant coding [3].

Typically, in the automotive industry, configuration options are realized through Boolean variables, so-called codes, where each code is represented by a variable name a.k.a. identifier. An option selected by a customer is then reflected by setting the corresponding code to true. Besides codes to register customer's selections, internal codes are used, for example, there can be codes representing spatial regions and codes indicating if the car possesses left or right steering.

The set of valid configurations is described by a set of Boolean formulas (rules, constraints) that all have to be satisfied in a valid order. Such constraints can express, e.g., mutual exclusivity, as in the selection of left-hand or right-hand steering. But often constraints are much more evolved, encompassing many dozens of codes.

Example:

$$c_1 \rightarrow \neg c_2 \land \neg c_3$$

with codes $c_1, c_2, c_3$. In other words, if we select code $c_1$, codes $c_2$ and $c_3$ cannot be selected.

Handling of parameters is mostly done in separate systems, where valid values (or sometimes even valid combinations of values) are specified via tables listing the admissible settings.

## 3. Challenges

Since software has become central in modern cars, the question arises whether existing systems, into which the software configuration is mostly just cobbled in, still meet all the necessary or desired requirements.

Until today, the configuration process is still mostly divided into two steps. First the hardware configuration, then – on top of it – the software configuration. However, it is questionable whether this two-step process is still the best approach for existing and future use-cases.

In this section, we present various challenges that prevail in current hardware-centric configuration systems and might require additional consideration in future hardware-software co-configuration systems.

**Hardware Upgrade.** Automotive manufacturers recently started to offer subscription models for features that are not present at the time of sale, but can be retrofitted – often by a simple software switch – into already delivered vehicles. For this, the manufacturers need the possibility to enable functions for vehicles in the field. Typically, this also requires a check, whether the hardware of the car supports the extended functionality.

It might even be the case that an OEM (Original Equipment Manufacturer) allows a retrofit including an update

of hardware components. This can occur as follows: In a revision of an existing car series, the hardware is slightly modified and a new software function becomes available. Now, this software function could potentially also be provided in the older model, if the necessary hardware can be retrofitted. Checking whether such an update is possible (and which parts have to be exchanged) requires access to the exact configuration of the delivered car as well as configuration systems that have knowledge about constraints for historic configurations, possibly going back to several years or even decades.

**OTA Update.** Over-the-air (OTA) software updates present unique challenges for automotive manufacturers. Firstly, the vehicle's software configuration must be fully defined in both hardware and software terms, ensuring that only compatible software satisfying all dependencies is delivered to the vehicle. Additionally, the delivered software must be correctly configured through variant coding, based on the underlying hardware configuration. Therefore, a combined consideration of hardware and software is highly important

**Missing Expert.** Up to day, software updates are still performed in repair shops by an expert. Manufacturers profit in this context from the expertise of the working staff. Occurring errors can instantly be analyzed by a qualified person. In the best case, the underlying error can be directly fixed by the repair shop staff. Especially in the case of OTA updates, this expertise is missing. In particular, problem analysis and troubleshooting pose a special challenge, as they all have to be done before delivery of the update or – for residual errors – must be fixable remotely, in the worst case by a downgrade to the previous version.

**Certification.** The automotive sector is highly standardized and regulated. Automotive manufacturers must guarantee that their products satisfy all kinds of standards from different domains. The regulations classically certify a vehicle to satisfy predefined security and safety standards. With the increasing use of driver assistant systems in the automotive sector, the certification requirements, especially in software, grow. In particular, lawmakers want to know in the future exactly which software is delivered in which car. An example is the UN ECE regulation 156,<fnref n="1" /> describing the requirements for a software update management system (SUMS) and the future scope for type approval procedures under consideration of the software.

<footnote n="1">¹https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update</footnote>
**Frequent Updates.** Software updates can be much more frequent than hardware revisions. As software is in an increasing manner not only security but also safety relevant, software updates may have the need to be rolled out quickly. However, as software changes can impact other components of the vehicle, an automatic validity and conformity check of the target vehicle configuration is required. In the best case, after a fix in an existing software package, a package manager should compute a new valid configuration, including the fixed software.

**Vehicle function distribution.** The distribution of functions in a vehicle and their mapping to ECUs is still done mostly manually. However, with the rapidly changing software architectures in vehicles, the distribution is getting more and more complex. To simplify the initial process in development, algorithmic support is an obvious solution. This requires a detailed specification and documentation of dependencies of the software to be distributed. This initial distribution, we call it *static vehicle function distribution*, can also be extended to the dynamic case, in which functions can be (re-)distributed in real-time to corresponding computing nodes. This allows an improved energy usage, as ECUs can be turned off and on if needed – complex algorithms might even be run in the cloud. For both use cases, a complete description of the hardware and software dependencies is required.

**Version Constraints.** For software configurations, the specific version of a software package and its dependencies are vital information. In a major software release, dependencies might change drastically, reflecting the changed and extended behavior of the software. However, version constraints are mostly documented in a numeric way, e.g. via *Semantic Versioning*[^2]. Whether the currently employed Boolean formalization of constraints is still the best way to address the problem is questionable.

**Variance over time.** If software updates can still be carried out for older vehicles, new functionalities can also be integrated into existing fleets if technically feasible. Determining which vehicle configurations can still be supplied with new software, as well as documenting and verifying this, is a major challenge given the enormous space of possible configurations. Enabling this variance over larger timeframes will require new mechanisms and considerations.

**Software Packaging.** In classic computer systems, software configuration problems are often solved with the help of package managers. However, automotive

software has additional constraints. In addition to the hardware dependency, there are also complex parameterizations (variant coding) and the need for diagnostic options. This raises the question of how to define software components or packages in order to be able to adopt existing concepts.

# 4. Related Work

How to handle hardware/software configurations in the automotive sector has been an active point of research and discussion for several years now [4, 5]. In a survey of German car manufacturers, Sax et al. [6] claim that new ways of checking the consistency of major, regular software updates is an important aspect for not hindering fast development of new functions in the future.

The configuration problem in the automotive industry and solutions to it were already described in the early 2000s. Sinz [7] describes a rule system based on Boolean logic. Here, not only checking individual configurations is covered, but also ways to determine common properties of all valid configurations. Moreover, the mapping from code sets into concrete physical components is also considered. In a later publication, Sinz [8] also describes the verification of such rule systems in order to detect and minimize errors at an early stage. Astesana et al. [9] on the other hand, describe vehicle configurations by using a CSP framework, with Renault as a case study. More recent publications also deal with the topic of classic configurations. Bischoff et al. [10] describes a graphical editor for visualizing and editing item selection rules.

In addition to the control systems mentioned above, there are other approaches to describing variability in general. One of them is feature modeling. In this, the configuration options (features) are often represented in the form of trees, which represent the relations between the features. The analysis of feature models is often performed with the use of SAT solvers [11]. However, analysis approaches using SMT solvers have also been part of recent research [12].

In the area of classic computer systems, configurations are often found in the area of package management and dependency solving. These are mostly so-called component-based systems such as GNU/Linux distributions (e.g. Debian[^3]). These contain metadata for software packages, which the package managers utilize in their search for valid configurations. While most package managers initially used ad-hoc solvers [13], nowadays more efficient algorithms from the SAT or CSP community are usually employed [14]. Pinckney et al. [15] recently proposed a package solver, *PacSolve*, for NPM which uses

<footnote>[^2]: https://semver.org</footnote>

<footnote>[^3]: https://www.debian.org</footnote>
an SMT approach instead of SAT/CSP solvers. As an
alternative to SAT and SMT, there are also publications
that describe and solve package update problems with
Answer Set Programming [16, 17].

The distribution of different functions in the architecture of a vehicle represents an enormous challenge in modern vehicles. Ruhnau et al. [18] take a first step towards mastering this challenge by describing an ontology for function distribution, covering both static and dynamic distribution.

5. Conclusion

In this paper, we have described various challenges that
exist in the area of hardware/software configurations in
the automotive sector. Many of these challenges arise
from the increasing complexity and relevance of software
in vehicles. We have listed that research work already ex-
ists for some of the topics. For others, there are promising
approaches from related problem areas, the suitability of
which we will investigate in more detail in future work.

Acknowledgments

The research presented in this paper was done in the con-
text of the SofDCar (19S21002) project, which is founded
by the German Federal Ministry for Economic Affairs
and Climate Action.

References

[1] C. Fehling, M. Frank, O. Kopp, Digital sustainability and digital diversification: The two key challenges for automotive software development, in: IEEE 18th Intl. Conf. Software Architecture Companion (ICSA-C), 2021, pp. 162–166.

[2] A. Kübler, C. Zengler, W. Küchlin, Model counting in product configuration, in: Proc. of the 1st Intl. Workshop on Logics for Component Configuration, LoCoCo 2010, Edinburgh, UK, 2010, pp. 44–53.

[3] H. Takimizu, T. Fukaya, Y. Ito, N. Sakano, ECU variant coding system, Mitsubishi Motors Technical Review 18 (2006).

[4] O. Media, Effective hardware-software co-design for automotive systems, 2014. URL: https://embedd edcomputing.com/application/automotive/effect ive-hardware-software-co-design-for-automotiv e-systems.

[5] O. Burkacky, J. Deichmann, G. Doll, C. Knochen-
hauer, Effective hardware-software co-design for
automotive systems, 2018. URL: https://www.mcki
nsey.com/industries/automotive-and-assembly/

our-insights/rethinking-car-software-and-electro
nics-architecture.

[6] E. Sax, R. Reussner, H. Guissouma, H. Klare, A Survey on the State and Future of Automotive Software Release and Configuration Management, Technical Report 11, Karlsruher Institut für Technologie (KIT), 2017.

[7] C. Sinz, Baubarkeitsprüfung von Kraftfahrzeugen durch automatisches Beweisen, Diplomarbeit, Universität Tübingen, 1997.

[8] C. Sinz, Verifikation regelbasierter Konfigura-
tionssysteme, Ph.D. thesis, Universität Tübingen,
Tübingen, Germany, 2003.

[9] J.-M. Astesana, L. Cosserat, H. Fargier, Constraint-based vehicle configuration: A case study, in: 2010 22nd IEEE International Conference on Tools with Artificial Intelligence, 2010, pp. 68–75.

[10] D. Bischoff, W. Küchlin, O. Kopp, Poseidon: A graphical editor for item selection rules within feature combination rule contexts, in: PLM in Transaction Times, Springer, Cham, 2023, pp. 3–14.

[11] D. Benavides, S. Segura, A. Ruiz-Cortés, Automated analysis of feature models 20 years later: A literature review, Information Systems 35 (2010) 615–636.

[12] J. Sprey, C. Sundermann, S. Krieter, M. Nieke, J. Mauro, T. Thüm, I. Schaefer, SMT-based variability analyses in FeatureIDE, in: Proceedings of the 14th International Working Conference on Variability Modelling of Software-Intensive Systems, ACM, 2020.

[13] P. Abate, R. D. Cosmo, R. Treinen, S. Zacchiroli, A modular package manager architecture, Information and Software Technology 55 (2013) 459–474.

[14] P. Abate, R. D. Cosmo, G. Gousios, S. Zacchiroli, Dependency solving is still hard, but we are getting better at it, in: 27th Intl. Conf. Software Analysis, Evolution and Reengineering (SANER), IEEE, 2020.

[15] D. Pinckney, F. Cassano, A. Guha, J. Bell, M. Culpo, T. Gamblin, Flexible and optimal dependency management via Max-SMT, in: 45th Intl. Conf. Software Engineering (ICSE), 2023, pp. 1418–1429.

[16] M. Gebser, R. Kaminski, T. Schaub, aspcud: A linux package configuration tool based on answer set programming, Electronic Proceedings in Theoretical Computer Science 65 (2011) 12–25.

[17] T. Gamblin, M. Culpo, G. Becker, S. Shudler, Using answer set programming for HPC dependency solving, in: Proc. Intl. Conf. on High Performance Computing, Networking, Storage and Analysis, SC '22, IEEE Press, 2022.

[18] J. Ruhnau, M. Sommer, J. Henle, A. Walz, S. Becker, E. Sax, Ontology for vehicle function distribution, in: IEEE Intl. Systems Conf. (SysCon), Vancouver, Canada, 17-20 April 2023, IEEE, 2023, p. 1-6.
# Prospective and retrospective approaches to integrate life cycle assessment in configurators: A multiple case study in the construction industry

Irene Campo Gay<fnref n="1" />*, Lars Hvam<fnref n="1" /> and Johan Ernfors<fnref n="2" />

## Abstract

This study contributes to the evolving dialog on sustainable practices, emphasizing the strategic integration of life cycle assessment (LCA) in configurators to comply with new regulatory standards and achieve environmental objectives. We investigated the application of configurators integrating LCA through a comparative analysis of two case studies in the construction industry: a prospective approach applied during the early design stages, and a retrospective approach using post-design. Our findings illustrate that prospective LCA configurators can significantly influence early design choices and facilitate preliminary environmental impact assessment. Conversely, a retrospective LCA configuration approach offers more precise and accurate assessments based on finalized designs, enabling detailed LCA reporting and saving significant time and effort. The analysis underscores that the application of these approaches is not mutually exclusive. This suggests that a combined strategy could maximize the potential of these tools. Such a combination would facilitate a more dynamic interaction between the early and later design stages, ensuring that the environmental assessment is thorough and iterative. Additionally, it would help the company gain in-depth insights into the environmental aspects of the design process.

## Keywords

configurators, construction, environmental impact, life cycle assessment (LCA), sustainability

## 1. Introduction

Sustainability is widely recognized as a multifaceted concept encompassing three dimensions: environmental, social, and economic. Notably, the environmental dimension plays a foundational role given its direct influence on socioeconomic elements [1]. In assessing environmental impact, particular attention has been given to the environmental impact of products and services. One of the most widespread methodologies for assessing environmental impact is life cycle assessment (LCA) [2].

In this context, the European Commission has highlighted the urgency of making sustainable products the norm across Europe by setting stricter product design and lifecycle standards [3]. As a result, the increasing focus on assessing environmental performance is evidence of the clear need for digital tools to support this process.

Configurators are a widespread technology that emerged in the late 1970s as decision support systems designed to streamline the specification process during

product customization [4]. They allow users to select from various options and configurations of a product, automatically adjusting components and features according to user choices. This technology enhances the decision-making process by providing immediate feedback on potential configurations, thereby significantly improving speed, quality, and efficiency [5].

Additionally, configurators enhance efficiency by automating the creation of crucial documents, such as quotes and bills of materials. This automation ensures accuracy and consistency in documentation; it is particularly valuable in complex configurations, where manual processes are prone to errors [6].

The integration of LCA with configurator technology is quite promising for enhancing sustainable product development. By embedding environmental assessment capabilities in configurators, companies can provide real-time data on the environmental impacts of various product options. This integration can facilitate a more informed design, incorporating environmental consequences alongside traditional factors, such as

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

<footnote n="1">¹ Technical University of Denmark, Anker Engelunds Vej 101 2800 Kongens Lyngby, Denmark</footnote>

<footnote n="2">² MOKO AB, Humlegårdsgatan 14 114 46 Stockholm, Sweden</footnote>
pricing. Furthermore, configurators can enhance the communication of environmental assessment results, a crucial aspect of LCA [7].

Despite the significant potential of this technology, research on the integration of LCA into configurators is still in its early stages. However, over the last five years, this topic has increasingly captured academic interest, as reflected in numerous recent publications [8–19].

Moreover, no research has examined the different implications of LCA in either a prospective or retrospective manner within the context of configurators. This gap in the literature leads to the following research question:

RQ: *What are the implications of a proactive and retrospective of life cycle assessment through configurators?*

We examined two different case studies of companies that have successfully developed configurators with LCA. The first case study involved using this technology during the early design phase to evaluate various design alternatives. The second case study described how a configurator, used over finalized designs, enables precise and accurate LCA. Both case studies pertain to the same sector: the construction industry.

We explored these case studies to assess and compare their impacts, thereby contributing to the research community's understanding of how configurators can be effectively employed to improve environmental development.

The structure of this paper is as follows. In Section 2, we present the theoretical background of LCA typologies in terms of application timing, and we review the academic research conducted on configurators, integrating LCA considerations. In Section 3, we describe the methodology used for analyzing the comparative case studies, and we introduce both case studies. In Section 4, we present the findings from the analysis, and in Section 5, we discuss the implications of the results. Finally, in Section 6, we summarize the key conclusions.

# 2. Theoretical background

## 2.1. Prospective and retrospective LCA

The use of LCA is subject to different contexts and can be driven by distinct aims and goals. In terms of the time perspective, LCA can be divided into two primary categories [20, 21]. On the one hand, *retrospective* LCA is aimed at assessing the effects of something that occurred; on the other hand, *prospective* LCA is a forward-looking approach [20, 21].

Retrospective LCA evaluates the environmental impacts of existing products based on actual data. It

helps to understand and improve the environmental performance of current technologies [20, 21].

On the other hand, prospective LCA evaluates the potential environmental impacts of products before they are implemented. It is used to guide decision-making during the development phase by predicting future impacts [20, 21].

## 2.2. Configurators and sustainability

The increasing focus on environmental considerations in the use of configurators has become a significant area of interest over the past five years. This trend is noticeable in the academic community and across various industries. For instance, standard product configuration software applications such as Tacton CPQ are developing their environmental impact assessment capabilities by incorporating LCA features into their applications [22].

Various researchers have also turned their attention to this subject in the academic sector. Given the novelty of the topic, the range of issues discussed in these studies regarding the integration of LCA and configurators is quite diverse, demonstrating the broad scope of the field.

Hankammer et al. [13] extensively reviewed over 900 configurators, providing valuable insights into enhancing sustainability features across sectors. Responding to the need for streamlined LCA assessments, Spreafico et al. [8] introduced I-Tree, a tool that leverages real-time data for efficient eco-assessment. Similarly, Rousseau et al. [10] explored the impact of environmental indicators in configurators, focusing mainly on sustainability enhancement in 3D printing.

To address the nexus between product variety and sustainability, Medini et al. [9] proposed a comprehensive framework, while Wiezorek and Christensen [14] focused on refining configurator architectures to enable better sustainability data communication. In consumer electronics, Hankammer et al. [11] found that default sustainable options significantly influence consumption patterns. Campo Gay et al. [18] analyzed the successful integration of LCA into configurators, guiding users toward sustainable choices. Focusing on sustainability integration, Christensen and Wiezorek [12] aligned configurators with ISO 14040 standards, while Campo Gay and Hvam [17] demonstrated the transformative impact of sustainability-focused configurators, particularly in construction.

Regarding configurators' development, Piroozfar et al. [16] discussed solutions tracking environmental impact, while Helo et al. [15] introduced software streamlining environmental assessments in supply chains. Moreover, Jakobsen et al.'s [19] call to redesign product configuration systems for better sustainability
integration tied these efforts together, portraying a concerted push toward deeper sustainability considerations in configuration processes across sectors.

All of these efforts highlight a strong trend toward deepening sustainability considerations within configuration processes.

## 3. Methods

Given that the advancement of configurators incorporating LCA is still at an early stage, elucidating their full potential and application is a notable challenge. To address this gap, we conducted a qualitative case study analysis comparing two distinct applications of configurator systems within the construction industry. Our objective was to delve deeply into their utilization of LCA and compare their effectiveness to gain in-depth insights.

As highlighted by previous research [23,24], case studies are essential for understanding the key variables, the connections between them, and the reasons behind these relationships.

We identified two case companies using configurators for environmental impact assessment, employing standard LCA methodology. These companies operate within the construction sector in Sweden.

The main reasons are first, that, according to the United Nations Environment Programme (UNEP), the building and construction industry stands as the most polluting industry sector, responsible for 38% of all energy-related CO2-eq emissions [25]. Consequently, the construction sector has played a pioneering role in shaping standards and regulations, as exemplified by the European standard EN 15804 for environmental product declarations [26], aligned with international LCA methodology standards ISO 14040 and ISO 14044 [7,27].

Second, Sweden has been a leading country in terms of introducing new policies and regulations for the construction sector. Currently, it is compulsory to declare an LCA on new buildings, and beginning in 2025, new projects must adhere to statutory limits on CO2-eq emission per m2 per year across the life cycle [28].

Consequently, all these factors motivate the construction sector in Sweden to seek out new tools and solutions to support their initiatives and make the studied companies ideal case studies.

### 3.1. Data gathering

To analyze the first case company, we conducted a series of systematic observations of the configuration process. We evaluated the experiences of the primary configurator implementor involved in the project over a period of four years.

For the company described in the second case, we began with an initial semistructured interview based on the main research question. This was followed by six semistructured interviews to understand the company's working processes and configuration systems. We finalized our analysis with a review of the results by one of the main configurator developers at the company.

### 3.2. Case company 1

The company is a subsidiary of a large international corporation that operates in Sweden and has approximately 350 employees. It specializes in developing, manufacturing, and marketing cement for infrastructure, such as roads, tunnels, bridges, and residential, commercial, and industrial buildings.

Recognizing the upcoming regulations that will take effect in 2025, which impose limitations on new construction projects, the company saw the need for an early design tool to assist in this process. They developed an LCA configuration to facilitate and promote environmentally friendly design options in the initial stages of projects when decisions are more flexible and have fewer resource implications. This tool assists users in the educational process, encouraging the consideration of less conventional options and more environmentally sustainable solutions.

Given the high level of uncertainty in decision-making during the early design phase of projects, a preliminary LCA was performed. In addition to serving as a decision support tool to address the complexity of environmental and technical requirements, the tool was modeled to quantify LCA to determine the margin of safety concerning maximum statutory limits.

The company has collaborated with external consultants over the past four years to develop this tool, reaching the final testing phase in the first quarter of 2024. Ownership of the tool was transferred to the company during the second quarter of 2024, with full integration into the company's workflow scheduled for completion by June 2024.

### 3.3. Case company 2

The company is a small enterprise that has been based in Sweden since 2018 and employs 35 people. It specializes in designing and planning the construction aspects of projects. The company uses a configuration system approach to streamline its building design process, which optimizes the overall process.

In response to new regulations requiring LCA declarations for construction projects since 2022, the company has integrated LCA evaluation into its established configurators. To facilitate this, the company uses a commercial solution named *One Click LCA*, a leading cloud-based software solution for
<caption>**Table 1**</caption>

Company Case 1: Early Design Stage Configurator Usage (Prospective)

<table><thead><tr><td>Aspect</td><td>Description</td></tr></thead><tbody><tr><td>Stage of use</td><td>Used in the very early design stages for planning</td></tr><tr><td>Main purpose of the LCA integration</td><td>To make environmentally conscious decisions and compare different solutions</td></tr><tr><td>LCA approach</td><td>Prospective, integrating LCA from the start of a design</td></tr><tr><td>Output</td><td>Overview of environmental impacts and technical aspects</td></tr><tr><td>Required configuration inputs</td><td>Preliminary technical requirements and environmental priorities</td></tr><tr><td>LCA integration kind with the configurator</td><td>During the configuration.</td></tr><tr><td>Impact on the design process</td><td>Significant influence over the design approach</td></tr><tr><td>Environmental focus</td><td>Screening LCA, preliminary impact assessments</td></tr><tr><td>Suitability for Projects</td><td>New projects with undefined design parameters</td></tr></tbody></table>

creating Environmental Product Declarations (EPDs) and LCA reports for building materials and products.

Consequently, the company has updated its configuration system to automatically generate a comprehensive material list with detailed material quantities in kilograms. These data can then be seamlessly processed by One Click LCA and integrated into the company's database to produce comprehensive EPDs.

## 4. Results

First, we characterized how each application on the configurator integrating LCA capabilities works and impacts the building design process, focusing on when they are used, what outputs they produce, and their ultimate influence on design decisions and environmental assessments.

Table 1 illustrates the case of Company 1. The application is employed during the early design stage of the building process, representing a prospective approach.

<caption>**Table 2**</caption>

Company Case 2: Post-Design Specification of Configurator Usage (Retrospective)

<table><thead><tr><td>Aspect</td><td>Description</td></tr></thead><tbody><tr><td>Stage of use</td><td>Used after the building design is finalized</td></tr><tr><td>Main purpose of the LCA integration</td><td>To create detailed LCA reports</td></tr><tr><td>LCA Approach</td><td>Retrospective, LCA applied to finalized designs</td></tr><tr><td>Output</td><td>Detailed environmental impact reports based on specific materials used and their quantities</td></tr><tr><td>Required configuration input</td><td>High-level drawing specifications</td></tr><tr><td>LCA integration kind with the configurator</td><td>After configuration, based on the automatic generation of specifications (i.e., a part list with quantities), the LCA is performed through an external tool (One Click LCA).</td></tr><tr><td>Impact on the design process</td><td>No or minimal impact on the design.</td></tr><tr><td>Environmental Focus</td><td>Detailed LCA, focusing on the quantifiable impacts of materials</td></tr><tr><td>Suitability for Projects</td><td>Projects with set designs needing LCA reflection</td></tr></tbody></table>

In contrast, Table 2 presents the case of Company 2, where the application is used after the design has been finalized, adhering to a retrospective approach.

Subsequently, we examined the implications of choosing either a prospective or a retrospective approach to how a new company's resources, design process, and overall strategy for sustainability are impacted. This should help in understanding the strategic differences between these two approaches. Table 3 outlines the considerations for a prospective approach, whereas Table 4 details the considerations for a retrospective approach when LCA is integrated into configurators. It is important to note that retrospective design is considered viable only for companies that have already implemented configurators. Implementing a retrospective approach without pre-existing configurators would be significantly costly and inefficient.
<caption>**Table 3**</caption>

Considerations for a Prospective Approach to Configurators Integrating LCA

<table><caption>**Table 4**</caption><thead><tr><td>Feature</td><td>Evaluation</td><td>Explanation</td></tr></thead><tbody><tr><td>Iterative design</td><td>Yes</td><td>Facilitates iterative design adjustments during early stages</td></tr><tr><td>Approach to design</td><td>Prospective</td><td>Used to influence initial design choices and integrate LCA</td></tr><tr><td>Accuracy</td><td>Low</td><td>Estimates are broad and based on preliminary data</td></tr><tr><td>Influence in design</td><td>High</td><td>Can significantly alter design outcomes</td></tr><tr><td>LCA is the main aim of the configurator</td><td>Yes</td><td>The primary aim is to guide environmentally conscious design</td></tr><tr><td>Further integrations</td><td>No</td><td>Standalone use for initial design stages</td></tr><tr><td>Resource investment in developing the configurator</td><td>High</td><td>Requires the development of a LCA focused configurator</td></tr><tr><td>Cost</td><td>Medium/High</td><td>Licenses and running cost of configurator tool</td></tr></tbody></table>

Considerations for a Retrospective Approach to Configurators Integrating LCA

<table><thead><tr><td>Feature</td><td>Evaluation</td><td>Explanation</td></tr></thead><tbody><tr><td>Iterative design</td><td>No</td><td>The LCA evaluation occurs once the configuration is finalized</td></tr><tr><td>Approach to design</td><td>Retrospective</td><td>Used after design choices are made</td></tr><tr><td>Accuracy</td><td>High</td><td>Calculations are detailed, based on precise information</td></tr><tr><td>Influence in design</td><td>None or minimal</td><td>The LCA is carried out to reflect on the design rather than modify it</td></tr><tr><td>LCA is the main aim of the configurator</td><td>No</td><td>LCA is secondary and happens thanks to the configuration</td></tr><tr><td>Further integrations</td><td>Yes</td><td>Requires integration with One Click LCA</td></tr><tr><td>Resource investment in developing the configurator</td><td>Low</td><td>Utilizes existing configurator</td></tr><tr><td>Cost</td><td>Medium/High</td><td>While the configurator is in place, there are costs for licenses on external LCA databases.</td></tr></tbody></table>
# 5. Discussion

A prospective approach in configurators integrating LCA allows for the early detection and mitigation of environmental impacts. In contrast, a retrospective approach ensures that these mitigations are based on precise, real-world data, ultimately enhancing the accuracy and reliability of environmental assessments.

Despite the benefits of a prospective configurator integrating LCA, the higher cost and resource requirements associated with developing and maintaining configurators must be considered. The investment in licenses and running costs of configuration applications can be substantial, but the long-term benefits of reduced environmental impacts and alignment with policies and requirements can compensate for initial costs.

On the other hand, a retrospective approach is highly dependent on completed project design specifications. This approach prevents the flexibility needed to make environmental improvements once the design is finalized. Moreover, while LCA reports on the same product should be comparable and provide precise environmental impact data, the exceptional detail provided by a configuration translates into outstanding detailed LCA reports, which differ from standard LCA reports. For example, this configuration approach could include the consideration of even the smallest details, such as the weight of bolts in a multifamily building construction. Such detailed LCA assessments can result in a misleading comparison between products using the same LCA database, where one report is very detailed (enabled by the configurator), and others are less detailed.

Therefore, the application of prospective and retrospective configurators integrating LCA should not be regarded as mutually exclusive. Incorporating both approaches into a project could substantially streamline efficiency in embracing environmental considerations and reporting LCA. Moreover, such dual applications could enable more dynamic interaction between the early and later design stages, ensuring that the environmental assessment is comprehensive and iterative.

Comparing LCA results from an early design stage with those derived from detailed data collected later in the same project can provide significant insights into product design. This comparison could help companies identify major environmental impact drivers and offer opportunities to reduce environmental assessment uncertainties.

# 6. Conclusions

The integration of LCA into configurators presents a promising path for enhancing sustainable production

practices. We explored the use of configurators integrating LCA at different stages of the design process through two contrasting case studies, a prospective and a retrospective LCA approach in the construction industry.

By employing prospective and retrospective LCA tools, companies can achieve a more thorough understanding of environmental impacts at different project stages, leading to more informed decision-making. This approach not only aids in achieving compliance with evolving regulatory standards but also aligns with broader corporate sustainability goals.

Future research should continue to explore the development and application of these tools across different sectors to fully realize their potential in driving sustainable development.

# References

[1] D. Griggs, M. Stafford-Smith, O. Gaffney, J. Rockström, M.C. Öhman, P. Shyamsundar, W. Steffen, G. Glaser, N. Kanie, I. Noble. Policy: Sustainable development goals for people and planet, Nature 495 (2013) 305–307. https://doi.org/10.1038/495305A.

[2] W. Klöpffer, B. Grahl, Life Cycle Assessment (LCA), Wiley Blackwell, Weinheim, Germany, 2014. https://doi.org/10.1002/9783527655625.

[3] European Commission, Communication From the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of The Regions, On Making Sustainable Products the Norm, Brussels, 2022. https://www.europarl.europa.eu/RegData/docs_a_utres_institutions/commission_europeenne/com/2022/0140/COM_COM(2022)0140_EN.pdf (accessed April 18, 2024).

[4] L.L. Zhang, Product configuration: A review of the state-of-the-art and future research, International Journal of Production Research 52 (2014) 6381–6398. https://doi.org/10.1080/00207543.2014.942012.

[5] A. Felfernig, C. Bagley, J. Tiihonen, L. Wortley, L. Hotz, Benefits of configuration systems, in: Knowledge-Based Configuration: From Research to Business Cases, (Eds. A. Felfernig, L. Hotz, C. Bagley, J. Tiihonen), Elsevier Inc., Waltham, USA, 2014, pp. 29–33. https://doi.org/10.1016/B978-0-12-415817-7.00004-9.

[6] C. Forza, F. Salvador, Managing for variety in the order acquisition and fulfilment process: The contribution of product configuration systems, Int J Prod Econ 76 (2002) 87–98. https://doi.org/10.1016/S0925-5273(01)00157-8.
[7] ISO, ISO 14044-Environmental management-Life cycle assessment-Requirements and guidelines, 2006. https://sd ds.dk/Viewer? ProjectNr=M337075P. S. Abril, R. Plant, The patent holder's dilemma: Buy, sell, or troll?, Communications of the ACM 50 (2007) 36-44. doi:10.1145/1188913.1188915.

[8] C. Spreafico, D. Russo, Generating infographics for environmental product declarations (EPDs) with I-tree software, in: Smart Innovation, Systems and Technologies, (Eds. R. J. Howlett & L. C. Jain), Springer Science and Business Media Deutschland GmbH, 2019, pp. 145-154. https://doi.org/10.1007/978-981-13-9271-9_14.

[9] K. Medini, T. Wuest, D. Romero, V. Laforest, Integrating sustainability considerations into product variety and portfolio management, Procedia CIRP 93 (2020) 605-609. https://doi.org/10.1016/j.PROCIR.2020.04.147.

[10] M. Rousseau, K. Medini, D. Romero, T. Wuest, Configurators as a means to leverage customer-centric sustainable systems-Evidence from the 3D-printing domain, in: Procedia CIRP, (Eds. K. Kellens, E. Ferraris, & E. Demeester), Elsevier B.V., 2020: pp. 103-108. https://doi.org/10.1016/j.procir.2021.01.060.

[11] S. Hankammer, R. Kleer, F.T. Piller, Sustainability nudges in the context of customer co-design for consumer electronics, Journal of Business Economics 91 (2021) 897-933. https://doi.org/10.1007/s11573-020-01020-x.

[12] N. Christensen, R. Wiezorek, Enabling mass customization life cycle assessment in product configurators, in: Lecture Notes in Mechanical Engineering, (Eds. A.-L. Andersen, R. Andersen, T. D. Brunoe, M. S. S. Larsen, K. Nielsen, A. Napoleone, S. Kjeldgaard), Springer Science and Business Media Deutschland GmbH, 2022, pp. 819-826. https://doi.org/10.1007/978-3-030-90700-6_93.

[13] S. Hankammer, A.M. Weber, L. Canetta, S.K. Sel, M. Hora, A sustainability based optimization model for starting solutions in toolkits for mass customization, in: 2017 International Conference on Engineering, Technology and Innovation (ICE/ITMC), Ice/Itmc 2017-Proceedings, Institute of Electrical and Electronics Engineers Inc., Madeira, Portugal, 2018, pp. 407-416. https://doi.org/10.1109/ICE.2017.8279914.

[14] R. Wiezorek, N. Christensen, Integrating sustainability information in configurators, in: Proceedings of the 23rd International Configuration Workshop, Vienna, 2021, pp. 65-72.

[15] P. Helo, B. Mayanti, R. Bejarano, C. Sundman, Sustainable supply chains-Managing

environmental impact data on product platforms, International Journal of Production Economics 270 (2024). https://doi.org/10.1016/j.ijpe.2024.109160.

[16] P. Piroozfar, S. Shafiee, L. F. Forberg, E. R. P. Farr, Product configurator as a monitoring tool for environmental impact: An AEC perspective, in: Proceedings of the 9th Changeable, Agile, Reconfigurable and Virtual Production Conference (CARV2023) and the 11th World Mass Customization & Personalization Conference (MCPC2023), Bologna, 2023, pp. 101-109. https://doi.org/10.1007/978-3-031-34821-1_12.

[17] I. Campo Gay, L. Hvam, Sustainability- focused product configurators benefits and expectations: A construction industry case, in: 2023 IEEE International Conference on Industrial Engineering and Engineering Management, IEEM 2023, Institute of Electrical and Electronics Engineers Inc., Singapore, 2023, pp. 773-777. https://doi.org/10.1109/IEEM58616.2023.10406559.

[18] I. Campo Gay, L. Hvam, A. Haug, Automation of life cycle assessment through configurators, in: 10th International Conference on Mass Customization and Personalization-Community of Europe, Novi Sad, 2022, pp. 19-25.

[19] A. Jakobsen, T. Tambo, M. Kadenic, Greener Information systems for product configuration management: towards adaptation to sustainability requirements, in: Proceedings of the 26th International Conference on Enterprise Information Systems, SCITEPRESS-Science and Technology Publications, Angers, 2024, pp. 100-109. https://doi.org/10.5220/0012737200003690.

[20] A. M. Tillman, Significance of decision-making for LCA methodology, Environmental Impact Assessment Review 20 (2000) 113-123. https://doi.org/10.1016/S0195-9255(99)00035-9.

[21] B.A. Sandén, M. Karlström, Positive and negative feedback in consequential life-cycle assessment, Journal of Cleaner Production 15 (2007) 1469-1481. https://doi.org/10.1016/j.jclepro.2006.03.005.

[22] Environmental Footprint Configuration-Tacton | Tacton, (n.d). https://www.tacton.com/products/tacton-cpq/environmental-footprint-configuration/ (accessed May 10, 2024).

[23] R.K. Yin, Case Study Research and Applications: Design and Methods, 6th ed., SAGE Publications, Inc., Thousand Oaks, California, 2018.

[24] C. Voss, M. Johnson, J. Godsell, Case research, in: Christer Karlsson (Ed.), Research methods for operations and supply chain management, 3rd Ed., Routledge, London, 2023, pp. 159-189. https://doi.org/10.4324/9781003315001.
[25] UNEP—UN Environment Programme, (n.d.). https://www.unep.org/ (accessed April 14, 2021).

[26] CEN, EN 15804—Sustainability of construction works, Environmental product declarations, Core rules for the product category of construction products, European Committee for Standardization (CEN): Brussels, Belgium (2012).

[27] ISO, ISO 14040—Environmental Performance Evaluation in Engineer-to-Order Companies: An Integrative Framework, 2006.

[28] Swedish National Board of Housing, Building and Planning. (2023, July). Limit values for climate impact from buildings (Report No. 2023:24). Retrieved from https://www.boverket.se/globalassets/engelska/li mit-values-for-climate-impact-from-buildings- and-an-expanded-climate-declaration.pdf.
# Premises, Challenges and Suggestions for Modelling Building Knowledge using the Configuration Paradigm.

Bart Deschoolmeester<fnref n="1" />*,†, Elise Vareilles<fnref n="2" />,<fnref n="3" />,†

**Abstract**

This problem instance paper addresses the need for an industry wide modelling paradigm and language that allows the formalisation and representation of building knowledge by domain experts (architects, engineers). Herein, the special nature of the construction industry (e.g. its openness and semantics) in comparison to other industries and the complexity that arises from this, is recognised. The research needed covers a computation independent meta-model and accompanying modelling language and the added value of the knowledge-based configuration paradigm therein. The research outcome might spark renewed interest in an all-round universal knowledge representation language in the field of building information modelling (BIM) and even prove valuable for other 'less complex' industries.

**Keywords**

Knowledge Modelling, Building Sector, Configuration, Universal Language

## 1. Introduction

A modelling environment for the design, construction, operation and end-of-life of buildings, in which it is impossible for the end user to make modelling mistakes because of the integration of personal, company, standardised and regulatory knowledge, has been envisioned since at least 1999 [1]. In addition, the introduction of environmental, social, cost, organisational, etc. objectives would further automate the modelling process through optimisation.

While some attempts have been made in the field of building information modelling, also named BIM, [2][3][4], the quest for a universal knowledge representation language has also been met with scepticism [1][5]: claiming that immediate practical needs should be prioritised or even that this is not (yet) feasible. It can even be argued that the field has adopted a pragmatic approach by focusing on information (as opposed to knowledge) [6], its translation from one environment to another [7], and constraint verification only after modelling [8]. Our proposed research returns to an idealistic view, but finds it promising if based on revised conceptual foundations and the knowledge-based configuration paradigm.

The rest of the paper is as follows. First, in Section 2,

the 'open' nature specific to the building industry is presented. In Section 3, the need to call some basic premises of previous efforts into question is addressed. Section 4 introduces the knowledge configuration paradigm and outlines the work of examining the possible benefits and challenges of its application for building knowledge. Lastly, possible further extension of the research is outlined in Section 5.

## 2. Building Industry as an ‘Open’ Industry

The need for a universal knowledge representation language (or at least a common meta-model) and the research challenges this provides, arise from the fact that the building industry is possibly the most open industry [1]:

* Many parties are involved in a project and parties change with every project.

* Vast numbers of manufacturers and products for any building part (from traditional to innovative), on any scale (up to the building itself) are available on the market.

* Both a product directly and an onsite composition from products might provide a solution for a required part (e.g. a wall as prefabricated masonry or on site masonry).

* Project specifications often don't prescribe specific products.

* Product delivery might not include some parts but only list its requirements (called 'open systems'

ConfWS'24: 26th International Workshop on Configuration, Sep 2–3,
2024, Girona, Spain

* Corresponding author.

† These authors contributed equally.

✉ bartdeschoolmeester@hotmail.com (B. Deschoolmeester); elise.vareilles@imines-albi.fr (E. Vareilles)

cy https://pagespro.isae-supaero.fr/elise-vareilles/ (E. Vareilles)

☎ 0000-0001-6269-8609 (E. Vareilles)

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

© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License
Attribution 4.0 International (CC BY 4.0)

<footnote n="1">¹Lammekensstraat 25 - 2140 Borgerhout, Belgium</footnote>

<footnote n="2">²ISAE SUPAERO, University of Toulouse, France</footnote>

<footnote n="3">³IMT Mines Albi, Toulouse University, Albi, France</footnote>
in this text, as opposed to proprietary, 'closed'
systems').

This openness is reenforced at a European level through regulation (Construction Product Regulation[9], public procurement[10]) and standardisation (CEN - European Committee for Standardization). This openness entails that most knowledge is generic and generally available in ample building regulations and standards. Designers, contractors and manufacturers refer to these documents and generally only complement them with their specific requirements.

The need for a common language for all the stakeholders is even more acute because of the challenges facing the construction industry: climate and environment, robotics, artificial intelligence, digital twins, etc. and this while facing a shrinking workforce (both engineers and workers).

## 3. Work Part 1: Basic Premises

In light of the unsuccessful attempts to develop a uni-
versal knowledge representation language for the con-
struction sector (see Section 1), it is necessary to first list
these experiments, examine their potential shortcomings
and generate new ideas and approaches. Based on this
work, it will then be possible to define the premises of a
meta-model and its accompanying modelling language.

A preliminary examination already allows some un-
derpinnings of previous efforts to be called into question.

Firstly, are existing attempts sufficiently intuitive? The sheer volume of available building expertise will necessitate the creation, verification and maintenance of knowledge models as a collaborative endeavour to be done by domain experts (e.g. architects and engineers) directly without a need for intermediaries like knowledge engineers.

Secondly, are these efforts ontological sufficiently
sound? Some examples of overlooked building ontology:

* A building concept can play different semantic roles: it can simultaneous be a conceptual 'container' of parts, items, variants and positions. For instance, a window is composed of parts for its operation: generally, a frame, glazing(s) and hardware. Yet, in a project, the concept might also represent more than one window, for example, a generalisation of the 4 physical windows (items) of the front facade. The concept might also express the variants allowed in the specification (e.g. the designer allows freedom in the choice of hardware to the contractor) or offered by the product (a window available in different heights). Lastly, variability can also exist within a single

physical item (called positions in this text): a win-
dow can be open or closed, supports for raised
office floors having an adjustable height or a ven-
tilation unit with different flow rates. Therefore,
at least conceptually, properties must be thought
of as potentially having different domains over
its parts, items, variants and positions.

* Any level of abstraction should be allowed from the obvious generic concept 'door', over 'parti-tion' (covering window, door, wall, floor, etc. ) up to a 'building object' concept.

* Innovative products exist for any building part and therefore must be expected: a generic concept should not be confined to its traditional meaning but allow almost unlimited heterogeneity.

* The semantics of the aforementioned 'position' can be further developed to also hold changes like the onsite length adjustment of a beam, the removal, addition or replacement of a part (e.g. a filter change), or the different installation or use options of a product. With the addition of a 'location' and 'time' property an item could be tracked in space and time, with each change being a new position. Thus covering the complete life-cycle.

* The semantics of the hierarchical relations be-
tween a concept and its parts and items respec-
tively, should not be confined to their traditional
definitions. A concept is primarily a generali-
sation of its items but this relation can have a
part-like meaning through emergent properties
like cardinality, overall cost, energy loss etc. Like-
wise, a concept might have properties that are a
generalisation of the part properties: for example,
a masonry wall concept enforces the same colour
domain for mortar and bricks.

* The ontology should be polyhierarchical (a single concept occurs in more than in one place) [11]: for example, products exist that act as roof boards and roof insulation or the window grille is simultaneously part of the window and the ventilation system.

* Within the partonomy there is also a need for the idea of 'breakdowns': different ways of breaking down a concept into parts. These ways can be disjunct (variants): for example, the choices for the building structure might be frame-like (e.g. wood or steel) or mass-like (e.g. prefab concrete or masonry). Breakdowns can also be conjunct (within a single variant): a building can be subdivided into its structure and total air volume or into floors (with each floor incorporating part of the structure and air volume). Each breakdown (and its parts) can be needed for the representation of knowledge or user requirements.
Lastly, what is the universe of discourse of the at-
tempts? In any industry, knowledge is interconnected,
but in the construction industry, due to its open nature,
this is scaled to the entire industry. It might therefore
be impossible to effectively isolate a particular aspect in
a model while striving for its universal use. The work
should therefore outline the contours of what constitutes
as building knowledge.

4. Work Part 2: Applying
Knowledge-based
Configuration

The knowledge-based configuration paradigm defines a configuration model as a set of variables with their domains and with product and user constraints limiting the possible combinations of variable values, and a solution (a configuration) as an assignment of single values to all variables consistent with the constraints (e.g. a valid configuration), as in Chapter 6 of [12]. Knowledge-based configuration is a matured and successful area of artificial intelligence, used and integrated across many industries for more than 40 years, as presented in Chapter 1 of [12]. The configuration paradigm will feel intuitive and familiar for most building professionals: a (product independent) specification as a solution space; a building as a configuration; design choices as constraints; configurable products like drywall systems, roof systems, insulation systems. An intensional, declarative representation through domains and constraints might therefore prove to be a good fit for construction knowledge

Another appealing aspect is the possibility of a repre-
sentation that is non-causal, meaning that in a particular
constraint which variables are input and which are out-
put need not be defined. Though the building modelling
process is largely experienced as procedural, directional,
top-down, where decisions thought of as the most im-
pactful, like the overall shape of the building, are taken
first and then gradually more detailed decisions are taken,
it is argued that this must not be imposed by the mod-
elling environment. Light requirements might determine
the number and shape of windows instead of the other
way around [13], or standard sizes of plywood sheets
determine the size of a construction to avoid waste [13].
In light of circularity, products available for reuse might
even become requirements instead of solutions. The up-
coming practice of early involvement of all stakeholders
entails the registering of big and small requirements be-
fore designing is started.

The knowledge-based configuration paradigm might
even make the typical iterative design process obsolete,
creating substantial savings. Though the knowledge-
based configuration paradigm seems promising, some

<figure><img src="image_15.png" /><figcaption>**Figure 1:** Left: relationship between product and user solution space in a traditional configuration task. Right: relationships between generic concept, project specification and products solutions space in a configuration task for a building project part</figcaption></figure>

challenges to the paradigm can already be identified.

Can configuration cover the needs resulting from the
work of Section 3: the ontology, the domain of discourse
and will it be enough to allow domain experts to take on
the role of knowledge engineers? A task resembling the
work of [14].

Will the configuration paradigm be able to fully absorb
the open character discussed in Section 2?

* The knowledge base will be incomplete. This because of the amount of standards, products, etc., the gradual nature of the design process or confidentiality (e.g. pricing information). Also, tacit knowledge is prevalent with construction parties.

* As it is impossible for any product knowledge base to contain all building products available on the market, the user requirements (the project specification) do no operate ‘within’ or on a single product knowledge base, cf. Chapter 6 of [12]. It is rather that both constraints defining multiple products and user requirements operate in the knowledge base of the generic concept (e.g. a generic window, door, wall, etc.) and it is the intersection of the specification and products solution spaces that represents the configurations that provides a solution and this only for the known products (see Fig. 1).

* The user should be presented only with valid options at any one moment in the modelling process. It is therefore not enough to solve for one valid solution but continuously for the complete valid solution space. This is especially necessary in a multi-user environment, where parties operate in each other’s solution space.

* Building industry knowledge is distributed. Not only for product knowledge (different manufacturers) but also generic knowledge (building regulations and standards) is generated by different institutions at different geographical levels (municipality, country, EU level, etc.). Expecting all of them to formalise their knowledge on
one location seems unrealistic. The product and generic knowledge base will be distributed and maybe also the project requirements base. Consistency, verification and maintenance of distributed generic knowledge might seem especially challenging.

* A solution is not always a product variant (a single product item). A product item position (a specification might require a specific height for a support, yet a support adjustable in height might be acceptable), a product item part (order the whole product to use only one of its parts) or product items combined (concrete from different suppliers for one single structure or products combined as parts to make up the specified whole) might prove to be equally valid solutions.

* In open systems, as defined in Section 2, the constraints for the not included parts of a (supply side) product might in effect be a product independent (demand side) specification. Making it necessary to solve the product knowledge base first.

## 5. Further Expansion of Research

Once the conceptual foundation and configuration as a solution established, the research could be extended:

* As touched up in the introduction, a need for optimisation might arise.

* New solving methodologies: computationally more efficient surrogate models might proof to be more practical or the use of generative design where the solution space is explored in an iterative process through single exemplary solutions.

* Propositions for domain expert and end user interface might result from the work.

* New ways of knowledge acquisition like through voluntary open collaboration of domain experts or the use of artificial intelligence (large language models, natural language processing) to extract knowledge.

## References

[1] C. M. Eastman, Building product models: computer environments supporting design and construction, 1st. ed., CRC Press LLC, Boca Raton, Florida, 1999.

[2] B.-C. Björk, Requirements and information structures for building product data models, Ph.D. thesis, VTT Building Technology, Espoo, Finland, 1995.

[3] B.-C. Björk, Ratas, a longitudinal case study of an early construction it roadmap project, Journal of Information Technology in Construction 14 (2009) 385–399.

[4] J.-K. Lee, C. M. Eastman, Y. C. Lee, Implementation of a BIM domain-specific language for the building environment rule and analysis, Journal of Intelligent & Robotic Systems 79 (2015) 507–522. doi:10.1007/s10846-014-0117-7.

[5] R. S. Weygant, BIM Content Development. Standards, Strategies, and Best Practices, 1st. ed., Hoboken, NJ, 2011.

[6] F. Liu, A. K. Jallow, C. Anumba, Building knowledge modeling: integrating knowledge in BIM, in: Proceedings of the CIB W78 2013: 30th International Conference – Beijing, w78, 2013, pp. 199–208.

[7] ISO 16739 Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries - Part 1: Data scheme, 2nd. ed., International Organization for Standardization, Geneva, Switzerland, 2024.

[8] A. Koutamanis, Planning regulations and modelled constraints in BIM: A dutch case study, Buildings 44 (2024). doi:10.3390/buildings14040939.

[9] Regulation (eu) no 305/2011 of the european parliament and of the council of 9 march 2011 laying down harmonised conditions for the marketing of construction products and repealing council directive 89/106/eec, in: Official Journal of the European Union, 1st. ed., European Union, 2011, pp. 4–43.

[10] Directive 2014/24/eu of the european parliament and of the council of 26 february 2014 on public procurement and repealing directive 2004/18/ec, in: Official Journal of the European Union, volume 57, 1st. ed., European Union, 2014, pp. 65–242. doi:10.3000/19770677.L_2014.094.

[11] ISO 5127 Information and documentation – Foundation and vocabulary, 2nd. ed., International Organization for Standardization, Geneva, Switzerland, 2017.

[12] A. Felfernig, L. Hotz, C. Bagley, J. Tiihonen, Knowledge-based Configuration: From Research to Business Cases, 1 ed., Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2014.

[13] K. M. Kensek, D. E. Noble, Building Information Modeling. BIM in Current and Future Practice, 1st. ed., Hoboken, NJ, 2014.

[14] M. Mohammad-Amini, T. Coudert, É. Vareilles, M. Aldanondo, System Configuration Models: Towards a Specialization Approach, in: 10th IFAC Conference on Manufacturing Modelling, Management and Control, volume 55, Nantes, France, 2022, pp. 1189 – 1194. URL: https://imt-mines-albi.hal.science/hal-03833708. doi:10.1016/j.ifacol.2022.09.551.
# Requirements and architectures for green configuration

Richard Comploi-Taupe<fnref n="1" />,†, Andreas Falkner<fnref n="1" />,*,†, Katrin Müller<fnref n="2" />,† and Sophie Rogenhofer<fnref n="1" />,†

**Abstract**

Green Configuration combines product configuration technologies with environmental impact calculations and enables customers to balance cost drivers and environmental impact drivers (such as CO₂ footprint) for their preferred product variants. We analyse requirements for configurable products that go beyond the state of the art of classical Life Cycle Assessment (LCA), and we list corresponding challenges for configurators, such as missing environmental impact data, total costs over the product life cycle, confidence in data accuracy, performance of the calculation, multi-objective optimisation, comparability of the results, and efficient explanations. To address those challenges, we discuss three architecture variants which go beyond sequentially calling separate tools for configuration and LCA: loosely coupled (where the configurator communicates via parameters with the LCA tool), tightly coupled (where the configurator also manages the basic environmental data and lets the LCA tool calculate the impact values for assemblies), and integrated (where the LCA calculation is implemented as part of the configurator). We find that all architectures rely on complete and reliable input data (which might be synthesised offline by data-driven AI methods) and have different advantages and disadvantages concerning efforts for tool vendors, product modellers, and customers.

**Keywords**

product configuration, sustainability, green configuration

## 1. Introduction

With the European Green Deal [1, 2], the European Union drives the EU society to a more sustainable future. The EU Agenda 2050 defines environmental, economic, and social goals to be achieved by production systems [3]. Requests for Proposal (RFPs) and other B2B offers of all manufacturing companies will soon require proof of highly sustainable production and operations – due to higher awareness of customers and national authorities, and stricter laws such as the forthcoming Ecodesign for Sustainable Products Regulation (ESPR) [4] or Sustainable Products Initiative (SPI) of the EU.

To persist, companies need to document the Product Carbon Footprint (PCF) or even Product Environmental Footprint (PEF) of all their products transparently and reliably, according to valid or forthcoming regulations like the Digital Product Passport (DPP) [5]. For mass production, processes to assess the environmental impact have already been defined and standardised, e.g., Life Cycle Assessment (LCA) is standardised by ISO 14040 [6].

Product configuration [7] and Industry 4.0 architectures [8] go beyond mass production, and mass customisation allows to manufacture individualised (i.e., lot-size 1) products. The transition towards a circular economy, as required by ESPR, puts challenges to mass customisation and configuration systems, such as the promotion of circularity-based business models, integration of eco-design principles to serve sustainable business demands (i.e., green procurement), and documentation and understanding of the product's material characteristics, manufacturing processes, energy usage, and environmental impacts over the complete life cycle. Only by integrating pre-manufacturing data

with data from usage and end-of-life phases can genuine circularity and optimised sustainability (e.g., maximising the product's utility while minimising waste) be reached for configurable products.

The term “Green Configuration” was established a few years ago<fnref n="1" /> for this enhancement of configuration tools with environmental impact calculations. This gives the user comprehensive information about the specific effects of their decisions. Small changes in configuration can have a significant impact on the ecological footprint. Multi-objective optimisation strategies make it possible to optimise the product configuration according to desired dimensions (financial and sustainable) depending on specific requirements. Furthermore, provisions must be made so that the final product remains in accordance with the increasingly complex legal framework. This affects not only sales configurators (where customers shall see the expected environmental impact and corresponding costs at the point-of-sale, i.e., before they order a product) but is also vital for engineering configurators (which need to prove that the finally manufactured and deployed product keeps the promises of the sales phase to avoid penalties or non-compliance costs).

Wiezorek and Christensen [11] have given a good overview of the topic, and we will extend their work based on the current developments, e.g., by considering various types of environmental impact (not only CO₂ equivalents) and by integrating the total cost of ownership (TCO) over the complete life cycle (not only the production phase). Our goal is to find alternative architectures for combining configuration and environmental impact calculation and evaluate them w.r.t. user requirements and challenges of their application in practice.

In the next section, we will analyse the state of the art of environmental data and impact calculation. In section 3, we discuss which challenges arise when this is to be applied to configurable products. In section 4, we present the main architectures for green configuration and describe how they deal with those challenges. Finally, we conclude what this can mean for configurator vendors.

Conf WS'24: 26th International Workshop on Configuration, Sep 2-3, 2024, Girona, Spain

* Corresponding author.

† These authors contributed equally.

richard.taupe@siemens.com (R. Comploi-Taupe); andreas.a.falkner@siemens.com (A. Falkner); katrin.km.mueller@siemens.com (K. Müller); sophie.rogenhofer@siemens.com (S. Rogenhofer)

0000-0001-7639-1616 (R. Comploi-Taupe); 0000-0002-2894-3284

(A. Falkner)

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

© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).

<footnote n="1">¹Siemens, Vienna, Austria</footnote>

<footnote n="2">²Siemens, Berlin, Germany</footnote>

<footnote n="1">¹The term “Green Configuration” has been used more by CPQ solution providers than in academia, e.g., by encoway [9] and CAS [10].</footnote>
## 2. Environmental impact assessment: The state of the art

Life Cycle Assessment according to ISO 14040 [6] has been the means of choice for environmental impact assessment for products, processes, and solutions for decades. More and more LCA tools and databases are available, and LCA results are used for Environmental Product Declarations (EPDs) according to ISO 14025 [12]. Examples for commercial providers are SimaPro<fnref n="2" />, iPoint<fnref n="3" />, and sphera<fnref n="4" />. Ecoinvent<fnref n="5" /> is an extensive database used by providers such as SimaPro. Some tools and databases target single environmental indicators only – e.g., SiGREEN [13]. ESTAINIUM<fnref n="6" /> is an open network to exchange PCF-related data in a non-profit-oriented way.

The LCAs are based on the product's Bill of Materials (BOM) and Bill of Processes (BOP) along its life cycle. Most LCAs are done after the final product design when the materials and processes are identified. LCA can also be applied earlier in the design process of configurators to improve design decisions before finalisation.

In customer communication, EPDs are often used to show the results of the LCA. However, the EPDs are based on a specific, fully specified product or – less individually and less precisely – on a representative product, an average (fictive) product, or the worst-case product of a homogenous product family. Thus, they cannot help customers decide on product details or with customer-specific optimisation. In the best case, they can give a rough orientation based on existing LCAs for product representatives or typicals.

As EPDs are used for customer communication, Product Category Rules (PCR) and Product Specific Rules (PSR) are defined to provide comparable results [12]. PCRs and PSRs harmonise the system boundaries and provide default parameters for EPDs. However, the usage scenario to be applied in EPD refers to a fictive reference service time. This reference service defines the years of service, load, and operating hours for calculation purposes only. It does not consider the customer-specific usage conditions. Although PCR and PSR aim to provide comparable EPD results within a product category, customers still have to make an effort to relate these results to the individual life cycle conditions and make the right purchase decisions.

Besides the insufficient consideration of the customer-specific usage scenario, the broad range of existing background data sets makes it hard to figure out the product-specific environmental performance, as this is influenced by applied LCA data sets as well. The LCA data sets often provide a market average or a representative example process and do not reflect a specific supplier's product and production-specific environmental impacts. There is still a gap in using primary data along the supplier chain.

Recent initiatives<fnref n="7" /> target the PCF accounting and management to improve the primary PCF data share in product accounting and to provide trusted and reliable data along the supply chain. However, even for PCF, several standards and guidelines are in place [14, 15] – and sufficient methods are not yet available to make the data comparable. Large-scale products may require data on millions of materials and

components from thousands of suppliers across multiple industrial sectors, which poses considerable challenges to data management and performance.

As PCRs and PSRs try to harmonise the environmental impact assessment within one product category, large-scale systems such as rolling stock, production lines, or process technology are composed of products or assemblies with multiple PCRs and PSRs to be applied, which are not necessarily comparable. Inline environmental assessments are required independently of PCRs and PSRs, especially in large-scale system configuration or turnkey projects. Focusing on customer-specific usage conditions will provide tailored results. However, small changes in the conditions may significantly impact the product's LCA results.

There is little related work concerning combining LCAs with a dynamic modelling approach to consider customer-specific usage or to adapt the background database to future scenarios (cf. Udriot et al. [16] for one example). Such a scenario analyser often applies the same product configuration to multiple usage scenarios. Changes in the product configuration could be made iteratively and sequentially.

Other research reports about work on guidance to integrate LCAs in general and EPDs in particular into configurators and its evaluation in the construction sector [17]. Wiezorek and Christensen [11] suggest an architecture for integrating LCA into a configurator based on a profound analysis of sustainability assessments according to the Ecological Scarcity Method (ESM) and data from the ecoinvent database – focusing on the supply chain and manufacturing phase and mapping all impact to PCF values. A qualitative study [18] lists several advantages that sustainability-focused configurators can potentially provide.

## 3. Challenges of impact assessment for configurable products

Manufacturing companies need to document not only the PCF but also the PEF (i.e. more environmentally critical substances than just CO2) of all their products transparently and reliably, according to valid or forthcoming regulations like DPP. This must be based on information from suppliers and knowledge about production processes and operations (i.e., usage and end-of-life phases) and includes the selection of suppliers and processes which minimise the overall environmental impact. In addition, economic key performance indicators (KPIs), such as costs for production, transport, usage, disposal, etc. need to be considered and require multi-objective optimisation with good user guidance (including understandable explanations).

The configuration of such an environmentally conscious system is difficult, especially for complex products, because:

* Many suppliers are involved, among them many small and medium-sized enterprises (SMEs), which often cannot provide sufficiently good documentation on materials and PEF (e.g., several thousand suppliers for parts of metro trains).

* Parts have entirely different properties as they come from different industries such as electrical, engineering, or building technology and may interpret environmental KPIs differently.

* Different countries have a wide variety of regulations and certificates (which may even change over

<footnote n="2">²https://simapro.com/</footnote>

<footnote n="3">³https://www.ipoint-systems.com/</footnote>

<footnote n="4">⁴https://sphera.com/</footnote>

<footnote n="5">⁵https://ecoinvent.org/</footnote>

<footnote n="6">⁶https://www.estainium.eco</footnote>

<footnote n="7">⁷Initiatives such as the aforementioned SiGREEN and ESTAINIUM.</footnote>
time), so different solutions (i.e., combinations of components) are necessary.

* The environmental impact (e.g., concrete PEF values) depends on the production technologies and locations of the suppliers and the location of deployment and conditions at customer sites.

* Sustainability data for many components is missing or questionable, and improvement is difficult as it is out of the control of the system integrator.

* The system configuration is often not yet defined in sufficient detail at the offering time, and therefore, the environmental impacts can only be estimated but not precisely calculated.

* Adaptations during contract negotiations or after deployment can affect compliance and/or performance and require efficient re-calculation and updating of documentation.

To handle those requirements, we need algorithms and techniques for:

* Calculation of all relevant sustainability metrics at point-of-sale: This is not possible in advance (as currently done) because it depends on user decisions, which can lead to billions of potential variants. It must be fast enough to ensure a good user experience and, therefore, requires high performance.

* Reliable aggregation of the values of all sub-parts: This includes highly accurate approximations for missing values specific to the current customer selections. For the usage phase, this cannot be based on sub-parts alone (as is currently done) but on the functionality of the whole product or sub-systems.

* Guided optimisation of several objectives: It is not sufficient to calculate only one (combined, weighted) optimum (as in current tools). The user must be supported in evaluating the Pareto front efficiently and finding the best compromise for conflicting goals.

* Concise visualisation of the results: This helps the user to easily understand the impacts of their decisions. It shall explain the system's confidence in its calculations and where to change a decision to achieve a better result (which goes beyond the capabilities of current systems).

In the remainder of the text, we will focus on the following concrete challenges of Green Configuration:

1. Missing environmental data from suppliers: Many, especially smaller companies, do not yet disclose environmental data for their products (partly because they do not know them themselves). This not only concerns the supply chain, i.e., the impact of the production of those sub-parts, but also their usage and end-of-life processing. To ensure proper LCA calculation, missing data must be synthesised as accurately as possible, i.e., by specific approximations based on machine learning from similar suppliers and/or components, simulation of production and/or operation, using intelligent extrapolation which takes trends into account (e.g., new versions of components typically get better).

2. Unclear impact data for the usage phase: The environmental impact is customer- and even application-specific. It depends on the context, such as operating hours (e.g., whether an engine runs 8 or 24 hours

a day) and energy mix (e.g., how much fossil, how much wind power or photovoltaic) [19].

3. Complexity of PEF calculation: The calculation of the complete product's environmental impact (e.g., CO₂ emissions) is more complicated than just adding the corresponding values of all the parts [20]. LCA tools such as Green Digital Twin™ (GDT) [21] or SimaPro implement such details and are certified to comply with the standards.

4. Confidence in calculated data: As the input data come with a certain uncertainty, we must hand over that uncertainty to the intermediate and total values (e.g., with a confidence level or a value range). Plausibility checks (e.g., assembly cannot have less impact than the sum of parts) would be helpful.

5. Multi-objective optimisation: For the customer, it is helpful to know about the impact distribution over the phases (supply chain, production, deployment, usage, end-of-life) and separately for different impact types (energy consumption, pollution, etc.). The corresponding costs (especially TCO) over different expected lifetime periods (e.g., 10 years vs. 20 years) are vital for good decisions. This means the values for all those metrics must be tracked individually.

6. Effective explanations and user guidance: It is insufficient to simply show the user the resulting LCA and TCO values. The user must also understand the causes for those values, i.e., which of their decisions contributed most. Transparency must be established to support users in understanding the impact of a specific configuration on economic and PEF KPIs.

7. Comparability of data: Data often depends on assumptions (such as those mentioned in challenge 2), and players may use different assumptions. To make offers from different vendors comparable, those assumptions and the algorithms used must be disclosed or harmonised, e.g., according to standards such as ISO 14040 [6].

# 4. Comparison of architectures for green configuration

This section presents architectures with increasing degrees of integration, starting with simply using an existing configurator and feeding its results into an existing or newly customised LCA calculator. In subsections, we will discuss how each deals with the challenges from the previous section and summarise the whole section in a table at the end.

## 4.1. Status quo: Separate tools

A naïve approach to Green Configuration is sequential – based upon the availability of two separate tools: configurator and LCA calculator. For the configurator (i.e., the left lane in Figure 1), a modeller defines the product model (i.e., variety and dependencies) in a knowledge base (KB) by using the integrated development environment (IDE) for the configurator. A customer or salesperson uses the configurator user interface (UI) to set values to configuration parameters to fulfil their requirements. Continuously, the solver checks compliance with the KB and sets other parameters accordingly. Only when the configuration is finished, the solver hands over the resulting BOM to the LCA tool
<figure><img src="image_17.png" /><figcaption>**Figure 1:** Sequential architecture</figcaption></figure>

<figure><img src="image_18.png" /><figcaption>**Figure 2:** Loosely coupled architecture</figcaption></figure>

(right lane). A (typically other) modeller now collects all necessary LCA data for the materials for all relevant phases (supply chain, production, usage, end-of-life) and calculates the environmental impact values for the product.

We will not go into more detail because this approach does not really combine the two tools and is impractical due to the typically long duration of the manual LCA assessment.

## 4.2. Loosely coupled architecture

To achieve faster results for the user, one can automate the process. Such a loosely coupled approach was taken by, e.g., Tacton [22]. It is based upon modelling the environmental impact in an LCA tool (such as SimaPro) and synchronising it with the configurator by mapping configuration features with parameters for the LCA (as sketched by the dashed line between KB and LCA data in Figure 2). After each user action in the configurator UI, the LCA calculator is called and returns the adjusted sustainability values to be shown in the configurator UI. The final LCA values may be used for optimisation, i.e., minimisation of environmental impact, in the configurator (indicated by the dashed arrow from the LCA values to the solver).

The main challenge for the configurator vendor is to define a clean generic mapping between configuration and

LCA concepts and continuously maintain this interface to comply with the evolving versions of both the configurator and the LCA tool and API. Modellers need much expertise and additional effort because they must specify the LCA model separately from the configurator model and make sure that both are in sync (i.e., define the core structure and the dynamic parameters, include all relevant materials and components, map those included components to configuration features, i.e., parameters). They may even need to involve a tool specialist, at least for the first setup of the system. The configurator users benefit from the proven LCA processes and the typically up-to-date data in the corresponding databases (e.g., ecoinvent). On the other hand, user experience may still be weak because of possibly long response times in interactive use (due to the overhead of calling an external tool and – especially for the first calls – the comparably long time to calculate the resulting value). Optimisation is challenging as the configurator cannot easily access intermediate values for sub-assemblies, thereby steering optimisation in the right direction. This loosely coupled architecture covers the challenges from section 3 in the following way:

1. Missing environmental data from suppliers: Available LCA data for the sub-parts (from suppliers), for the manufacturing tasks (in the own production
process), for various time periods in the operations phase (depending on details of usage and surroundings), and for end-of-life (e.g., recycling efforts) can be reviewed and – if necessary – extended by the modeller in the LCA tool's UI before the configuration process starts. Additionally, an external tool based on machine learning could help to synthesise data offline (this needs to be implemented by other experts).

2. Unclear impact data for usage phase: Information about expected usage can be collected as configuration data and handed over as parameters to the LCA calculator to achieve customer-specific values.

3. Complexity of PEF calculation: The LCA calculator can be trusted to comply with the rules for proper calculation (PCR, PSR).

4. Confidence in calculated data: Current LCA tools do not (yet) sufficiently inform about (missing) accuracy of values.

5. Multi-objective optimisation: LCA values of sub-parts and sub-assemblies are not available to the optimiser, which can lead to weak (sub-optimal) performance.

6. Effective explanations and user guidance: The configurator UI cannot access the internals of LCA calculation and thus cannot assist the user with explanations and recommendations.

7. Comparability of data: The LCA tool is typically certified. Therefore, the resulting LCA values are comparable to other calculations based on the same standards.

### 4.3. Tightly coupled architecture

Some LCA tools, e.g., Green Digital Twin™ (GDT) from Siemens, are generic and expect that the LCA data for the LCA calculation is handed over at the call. This can be used for a tightly coupled architecture, where the configurator manages the LCA data and just calls the LCA tool (see Figure 3).

Again, the advantage for the customer is that they are facing just one UI (for configuration and LCA values). But now, the same is true for the modeller (a single UI for configuration and LCA models). This means that the configurator vendor must supply such a modelling UI, which allows the binding of configuration variants to their LCA data (typically extracted from LCA data sets), and a solver which hands the LCA data for the selected variants over to the LCA calculator. The LCA calculator can even be called for parts of the product (not only for the whole product). The tightly coupled approach covers the challenges from section 3 in the following way:

1. Missing environmental data from suppliers: Similarly to the loosely coupled approach, LCA data for the relevant sub-parts can be prepared or synthesised offline.

2. Unclear impact data for usage phase: The configurator hands those LCA data over to the LCA calculator, corresponding to the customer's expected usage.

3. Complexity of PEF calculation: The LCA calculator can be trusted to comply with the rules for proper calculation (PCR, PSR).

4. Confidence in calculated data: Current LCA tools do not (yet) sufficiently inform about (missing) accuracy of values, but as the solver has access to the LCA values of sub-assemblies, it can partly validate them.

<figure><img src="image_19.png" /><figcaption>Figure 3: Tightly coupled architecture</figcaption></figure>

5. Multi-objective optimisation: The optimiser can use the LCA values of sub-assemblies for informed heuristics.

6. Effective explanations and user guidance: The configurator UI cannot access the internals of LCA calculation but can use the LCA values of sub-assemblies for some recommendations.

7. Comparability of data: Similar to the loosely coupled approach, the LCA values are comparable to other calculations based on the same standards.

### 4.4. Integrated architecture

One can go one step further and directly integrate LCA calculation into the configurator by extending the modelling environment (IDE) with a component for LCA and calculating sustainability values directly in the configurator (see Figure 4). Such an approach was taken by, e.g., CAS Merlin [11, 23].

The integrated approach has the advantage that it does not need an explicit mapping to an LCA tool during modelling and can use environmental data during reasoning and optimisation to come up with a more preferred solution. On the other hand, it needs considerable effort for the
<figure><img src="image_20.png" /><figcaption>**Figure 4:** Integrated architecture</figcaption></figure>

configurator vendor to implement the calculation, care for certification (for LCA calculation according to ISO 14040, for EPD generation according to ISO 14025), and continuously maintain it to keep compliance with standards up to date. Development efforts can be reduced if certification is unnecessary, e.g., because customers need not compare their products with competitors but only with their internal variants. The integrated approach covers the challenges from section 3 in the following way:

1. Missing environmental data from suppliers: Similarly to the coupled approaches, LCA data for the relevant sub-parts can be prepared or synthesised offline.

2. Unclear impact data for usage phase: The combined solver and calculator can directly access the expected usage information as specified by the customer to compute the LCA values.

3. Complexity of PEF calculation: Simple impact calculations (e.g., the addition of upstream) can be easily integrated into the solver. Covering the same functionality as an LCA tool and achieving certification requires much more effort by the configurator vendor.

4. Confidence in calculated data: The combined solver and calculator can keep track of the accuracy of the

calculated LCA values for assemblies if the accuracy of the input data is known or can be estimated.

5. Multi-objective optimisation: As the optimiser and LCA calculator are fully integrated, intermediate LCA values can efficiently control optimisation.

6. Effective explanations and user guidance: The complete integration of the solver and LCA calculator and full access to all their intermediate data allows for detailed explanations and recommendations.

7. Comparability of data: The extension of the solver with LCA calculation leads to highly individualised LCA values. If the configurator vendor does not achieve certification (e.g., due to high costs and/or efforts), the LCA values may not be comparable to commercial LCA tools.

### 4.5. Summary

Summing up, all three approaches have strengths and weaknesses when dealing with the challenges. Challenge 1 (missing data) is not discriminating, and the best way to cover it is by extending and/or improving input data offline, e.g. with the help of data-driven AI. Therefore, we rate only challenges 2 to 7 in Table 1 and use a three-valued scale – the approach has strengths, is neutral, or has weaknesses – to condense the arguments from the preceding subsections.

<caption>**Table 1**</caption>

Concerning the challenges, the architectures have strengths (+), are neutral (0), or have weaknesses (-)

<table><thead><tr><td>Challenge</td><td>Loosely coupled</td><td>Tightly coupled</td><td>Integrated</td></tr></thead><tbody><tr><td>2 - usage phase</td><td>0</td><td>+</td><td>+</td></tr><tr><td>3 - calculation</td><td>+</td><td>+</td><td>0</td></tr><tr><td>4 - confidence</td><td>-</td><td>0</td><td>+</td></tr><tr><td>5 - optimisation</td><td>-</td><td>0</td><td>+</td></tr><tr><td>6 - explanations</td><td>-</td><td>0</td><td>+</td></tr><tr><td>7 - comparability</td><td>+</td><td>+</td><td>0</td></tr></tbody></table>

The integrated approach offers more value to the customers, e.g. more optimisation possibilities and better explanations. On the other hand, this requires more effort for the configurator developer because they must implement LCA calculations (not just call existing tools or libraries) and care for the necessary certification to make the calculations transparent and comparable.

The coupled approaches take advantage of re-using off-the-shelf LCA calculators and can even hand over configuration information as parameters, but neither (especially the loosely coupled architecture) can easily integrate the calculation results into their reasoning (e.g. for optimisation and explanations). The tightly coupled architecture can access values from sub-assemblies to achieve better usability.

A product modeller may prefer the tightly coupled approach and especially the integrated approach because data management can be done with only one tool: the configurator.

## 5. Conclusions

Green Configuration, the combination of product configuration technologies with environmental impact calculations, is a vital approach to address sustainability challenges. We
have analysed requirements and challenges and discussed
several architectures for configurators implementing a green
configuration approach.

We have seen that the different architectures have dif-
ferent strengths and weaknesses, advantages and disadvan-
tages. All of them are feasible and require different efforts
from stakeholders, i.e., tool vendors, product modellers, and
customers. From the viewpoint of a product owner, the se-
lection of their individually preferred architecture depends
on the product's complexity, the level of product customisa-
tion, the number of offers per year, the LCA impact of the
usage phase, and the need to enhance customer experience
and operational efficiency.

There is much room for future research on efficiently
merging sustainability management with configuration life-
cycle management, e.g., reference architectures, reliable data
exchange, individualised impact calculation, multi-objective
optimisation, elaborate standards, etc.

As one of the most important, we see the monetary as-
sessment of PEF as a means of providing an estimate of
the TCO. Visualising the monetary impact of configuration
decisions over the whole lifecycle of the product will create
a real incentive for the customer to choose the more sustain-
able product configuration (e.g., less energy costs during
the operation phase). Green Configuration extended with
TCO minimisation can lead to a triple-win situation: min-
imised total cost of ownership for the customer, increased
demand for high-quality products for the industry, and less
environmental damage.

Green Configuration enables the creation and scale of
application-specific EPDs and DPPs based on more precise
information and assumptions on the concrete product prop-
erties and usage. To make such specifically customised
values comparable between tools, existing standards like
ISO 14040 and the ISO 14020 series [24] need to be adapted
or extended. Transparency of the individual impact values
per phase and/or criterion is necessary for well-founded
decisions.

Disclaimer: Much of the presented work is “thought
work”. Currently, we are working on prototypes to con-
firm the ideas and results in practice.

References

[1] European Commission, The European Green Deal: Striving to be the first climate-neutral continent, 2020. URL: https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/european-green-deal_en, accessed 2024-07-19.

[2] European Commission, The European Green Deal, 2019. URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM%3A2019%3A640%3AFIN, accessed 2024-07-19.

[3] S. Muench, E. Stoermer, K. Jensen, T. Asikainen, M. Salvi, F. Scapolo, Towards a green & digital future, 2022. doi:10.2760/54.

[4] European Commission, Proposal for ecodesign for sustainable products regulation, 2022. URL: https://environment.ec.europa.eu/publications/proposal-ecodesign-sustainable-products-regulation_en, accessed 2024-07-19.

[5] T. Götz, H. Berg, M. Jansen, T. Adisorn, D. Cembrero, S. Markkanen, T. Chowdhury, Digital Product Passport: The ticket to achieving a climate neutral

and circular european economy?, 2022. URL: https://
circulareconomy.europa.eu/platform/en/knowledge/
digital-product-passport-ticket-achieving-climate-
neutral-and-circular-european-economy, accessed
2024-07-19.

[6] International Organization for Standardization, ISO 14040:2006 Environmental management — Life cycle assessment — Principles and framework, 2006.

[7] A. Felfernig, L. Hotz, C. Bagley, J. Tiihonen (Eds.), Knowledge-based Configuration: From Research to Business Cases, 1st ed., Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2014.

[8] H. Lasi, P. Fettke, H.-G. Kemper, T. Feld, M. Hoffmann, Industry 4.0, Business & Information Systems Engineering 6 (2014) 239–242. doi:10.1007/s12599-014-0334-4.

[9] S. Keinitz, Corporate sustainability – how Green Configuration can help!, 2023. URL: https://www.encoway.de/en/blog/green-configuration/, accessed 2024-07-19.

[10] R. Wiezorek, CPQ-Software: Green Configuration für mehr Klimaschutz, 2022. URL: https://www.digital-engineering-magazin.de/cpq-software-green-configuration-fuer-mehr-klimaschutz-a-dc586d2681e3701d3088e0a405ee6185/, accessed 2024-07-19.

[11] R. Wiezorek, N. Christensen, Integrating sustainability information in configurators, in: M. Aldanondo, A. A. Falkner, A. Felfernig, M. Stettinger (Eds.), 23rd International Configuration Workshop, volume 2945 of *CEUR Workshop Proceedings*, CEUR-WS.org, 2021, pp. 65–72. URL: https://ceur-ws.org/Vol-2945/52-RW-ConfWS21_paper_16.pdf.

[12] International Organization for Standardization, ISO 14025:2006 Environmental labels and declarations — Type III environmental declarations — Principles and procedures, 2006.

[13] Siemens, Decarbonization starts with data, 2024. URL: https://www.siemens.com/global/en/company/sustainability/product-carbon-footprint.html, accessed 2024-07-19.

[14] World Business Council for Sustainable Development, Pathfinder framework – guidance for the accounting and exchange of product life cycle emissions, 2021. URL: https://www.wbcsd.org/resources/guidance-for-the-accounting-and-exchange-of-product-life-cycle-emissions/, accessed 2024-07-19.

[15] Together for Sustainability, The product carbon footprint guideline for the chemical industry, 2024. URL: https://www.tfs-initiative.com/app/uploads/2024/03/TfS_PCF_guidelines_2024_EN_pages-low.pdf, accessed 2024-07-19.

[16] M. Udriot, K. Treyer, O. Buhler, L. Etesi, E. David, V. Girardin, Rapid life cycle assessment software for future space transportation vehicles design, in: Aerospace Europe Conference 2023, 2023. doi:10.13009/EUCASS2023-015.

[17] I. Campo Gay, L. Hvam, A. Haug, Automation of life cycle assessment through configurators, in: Z. Anišić, C. Forza (Eds.), 10th International Conference on Mass Customization and Personalization, 2022, pp. 19–25. URL: https://mcp-ce.org/wp-content/uploads/2022/10/5.pdf.

[18] I. Campo Gay, L. Hvam, Sustainability-focused product configurators benefits and expectations: A
construction industry case, in: IEEE Interna-
tional Conference on Industrial Engineering and En-
gineering Management, IEEE, 2023. doi:10.1109/
ieem58616.2023.10406559.

[19] H. Ritchie, P. Rosado, Energy mix, Our World in Data (2020). URL: https://ourworldindata.org/energy-mix.

[20] European Commission, Product Environmental Footprint Category Rules Guidance, version 6.3, 2018. URL: https://eplca.jrc.ec.europa.eu/permalink/PEFCR_guidance_v6.3-2.pdf, accessed 2024-07-19.

[21] Siemens, Finding the right balance between costs and the carbon footprint, 2024. URL: https://resources.sw.siemens.com/en-US/case-study-siemensag, accessed 2024-07-26.

[22] Tacton Systems AB, Tacton CPQ environmental footprint configuration, 2024. URL: https://www.tacton.com/products/tacton-cpq/environmental-footprint-configuration/, accessed 2024-07-19.

[23] CAS Software AG, GreenConfiguration mit CAS Merlin CPQ, 2024. URL: https://www.cas.de/infothek/wissenswertes/cpq-wissen/green-configuration/, accessed 2024-07-19.

[24] International Organization for Standardization, ISO 14020:2022 Environmental statements and programmes for products — Principles and general requirements, 2022.
ever, achieving this optimization is complex due to various real-world constraints and dependencies, contributing to the JSP's NP-completeness. The combinatorial explosion of possible job and machine combinations further complicates the problem, making exhaustive exploration impractical as the number of jobs and machines grows.

## 2.1. Mixed Integer Programming

The JSP involves various sets, parameters, variables, and constraints crucial for formulation and solution:

Sets:

* $J = \{1, ..., n\}$, the set of jobs.

* $M = \{1, ..., m\}$, the set of machines.

* $S = \{1, ..., s\}$, the set of speeds.

* $T_j, \forall j \in J$, the set of tasks in job j. In standard JSP $T_j = M$.

Parameters:

* $D_{jt}, \forall j \in J, \forall t \in T_j$, the due date of task job $t_{jt}$.

* $R_{jt}, \forall j \in J, \forall t \in T_j$, the release date of task job $t_{jt}$.

* $P_{jts}, \forall j \in J, \forall t \in T_j$, the processing time of task job $t_{jt}$ on machine t with speed s.

* $E_{jts}, \forall j \in J, \forall t \in T_j$, the energy consumption for processing task job $t_{jt}$ with speed s.

Variables:

* $c_{jt}, \forall j \in J, \forall t \in T_j$, the completion time of task job $t_{jt}$

* $tt_{jt}, \forall j \in J, \forall t \in T_j$, tardiness of task job $t_{jt}$ with respect to its due date

* $x_{mjts} \in \{0, 1\}, \forall m \in M, \forall j \in J, t \in T_j$, binary sequencing variables (i.e., $x_{mjts} = 1$ denotes that task t of job j is performed with speed s on machine m)

* $y_{mijpq} \in \{0, 1\}, \forall m \in M, \forall i, j \in J, \forall p, q \in T_i, T_j, i \neq j, \text{ binary assignment variables (i.e., } y_{ijpq} = 1 \text{ denotes that task p of job i precedes task q of job j on machine m)}$

$$ \phi^* = \arg \min_{\phi \in \Phi} [MK(\phi), EC(\phi), TT(\phi)] \quad (1) $$

subject to:

$$ \sum_{m \in M} x_{mjts} = 1 \qquad (2) $$

$$ \forall j \in J, \forall t \in T_j, \forall s \in S $$

$$ \sum_{m \in M} y_{mijpq} = 1 \qquad (3) $$

$$ \forall i, j \in J, \forall p, q \in T_i, T_j, i \neq j, p \le q $$

$$ tt_{mjt} \ge c_{mjt} - D_{jt} \qquad (4) $$

$$ \forall m \in M, \forall j \in J, \forall t \in T_j, x_{mjt} = 1 $$

$$ c_{mjt} \ge R_{jt} + P_{mjts} \qquad (5) $$

$$ \begin{array}{l} \forall m \in M, \forall j \in J, \\ \forall t \in T_j, \forall s \in S, x_{mjts} = 1 \end{array} $$

$$ c_{mjs} \ge c_{mip} + P_{mips} \qquad (6) $$

$$ \begin{array}{l} \forall m \in M, \forall i, j \in J, \\ \forall p, q \in T_i, T_j, \forall s \in S, \\ i \neq j \land p < q \land y_{mijps} = 1 \end{array} $$

$$ c_{mjt} \ge 0, t_{mjt} \ge 0 \qquad (7) $$

$$ \forall m \in M, \forall j \in J, \forall t \in T_j $$

This model seeks the optimal solution $\phi^*$ that minimizes the three measures mentioned in equation 1. considering the constraints associated: the maximum makespan of all task jobs $MK(\phi)$, the total energy consumption $EC(\phi)$, and the total tardiness $TT(\phi)$. The simultaneous optimization of these objectives requires a delicate balance between the various considerations and constraints of the problem. Therefore, two approaches to optimizing the problem solutions are proposed, allowing us to analyze the methods' behavior better.

## 2.2. Mono-objective optimization

This section presents the mono-objective optimization for a specific scheduling problem involving multiple jobs and machines, emphasizing key performance metrics such as makespan, energy consumption, and total tardiness.

$$ f^m = \max_{\substack{j \in J \\ m \in M}} (c_{jm}) \qquad (8) $$

$$ f^e = \sum_{j \in J} \sum_{t \in T_j} E_{jt} \qquad (9) $$

$$ f^{tt} = \sum_{m \in M} \sum_{j \in J} \sum_{t \in T_j} tt_{mjt} \qquad (10) $$

Equation 8 represents the makespan, which is the maximum completion time among all machines, by calculating the total processing time of all job tasks on each machine and selecting the maximum value across all machines. Equation 9 describes energy consumption by computing the total energy consumed by all job tasks across all machines. Lastly, Equation 10 is formulated to show the total tardiness, which represents the number of time units of each job or operation that are performed outside its time window, i.e., the period of time between the release date and the due date.

$$ \min \frac{f^m - m_1^-}{m_1^+ - m_1^-} + \frac{f^e - m_2^-}{m_2^+ - m_2^-} + \frac{f^{tt}}{m_1^+} \qquad (11) $$

Minimizing the objective Function 11 aims to find a solution that achieves a balanced trade-off among the components. The values $m_{1,2}^+$ and $m_{1,2}^-$ are used to normalize the $\phi^*$ solution obtained in the three-dimensional objective space. This allows a correct comparison between the values of the objective function in minimizing the problem, giving the same weight to all the parts, and avoiding any of the variables dominating the search.

$$ m_1^+ = \sum_{j \in J} \left( \sum_{m \in M} \max_{s \in S} (P_{jms}) \right) \qquad (12) $$
$$m_2^+ = \sum_{m \in M} \left( \sum_{j \in J} \max_{s \in S} (E_{jms}) \right) \quad (13)$$

$$m_1^- = \max_{j \in J} \left( \sum_{m \in M} \min_{s \in S} (P_{jms}) \right) \quad (14)$$

$$m_2^- = \sum_{m \in M} \left( \sum_{j \in J} \min_{s \in S} (E_{jms}) \right) \quad (15)$$

Equations between 12 and 15 determine both maximum ($m_1^+$ and $m_2^+$) and minimum ($m_1^-$ and $m_2^-$) values for makespan and energy consumption respectively. For makespan, these values signify the maximum and minimum completion times across all machines, accounting for the maximum and minimum processing times of job tasks on each machine. Similarly, in terms of energy consumption, they represent the maximum and minimum energy utilized among all machines, considering the maximum and minimum energy consumption of all job tasks on each machine.

### 3. Algorithm Selector

The selection of algorithms for a given problem *JSP* involves identifying the most appropriate algorithm from a collection capable of solving *JSP*, taking into account the specific characteristics of *JSP*. Rubinoff [13] formalized this process of algorithm selection. Rubinoff defined key elements, including the problem space *X*, representing all instances of *JSP*; the algorithm space *A*, encompassing algorithms capable of solving any $jsp \in X$; and a performance metric *y*, which quantifies algorithm effectiveness for solving $jsp \in X$.

The core objective is to establish a function $S: X \to A$ that, for each problem instance $jsp \in X$, selects the optimal algorithm from *A* based on metric *y*. To effectively characterize each *jsp*, a feature set *F* is constructed to represent *p* and assist in the decision-making process for *S*. Consequently, *S* is defined as a composite function $S = T \circ G$, where $G: X \to \mathbb{R}^{|F|}$ maps *p* to its feature vector in $\mathbb{R}^{|F|}$, and $T: \mathbb{R}^{|F|} \to A$ selects the algorithm from *A* based on this feature representation. The choice of *F* is critical as it must be informative and accurately represent the characteristics of *JSP*.

Considering the modeling of algorithm selectors in Figure 1, an algorithm selector structure is proposed, where it can be seen that it is composed of a training phase, in which the features of a set of instances are processed to generate a set of data and are solved using three solvers: GECODE, CPLEX, and GUROBI. Once the instances have been solved, the extracted features are related to the best algorithm that has solved that instance, and different machine learning models are trained in order to validate which is the one that obtains the best accuracy and thus use it to recommend future instances.

The following subsections detail each of the training processes.

#### 3.1. Feature processing

For each instance, we extract the typical characteristics of a *JSP* (Job Shop Scheduling) problem, such as the number of jobs $|J|$, the number of machines $|M|$, the type of Release date, and Due date constraint $Rd/Dd$, and the number of speeds $|S|$. Additionally, we extract other features that are obtained in a less direct manner and aim to be as informative as possible about the complexity of the instance they represent. The extra features extracted are:

$$\max(P) \quad (16)$$

$$\text{mean}(P) \quad (17)$$

$$\min(P) \quad (18)$$

The maximum processing time (16) represents the longest time required to complete any single operation within the job set. The mean processing time (Equation 17) gives the average duration of the operations, providing an overall sense of the job length. The minimum processing time (Equation 18) shows the shortest time needed for any operation, indicating the fastest job segment.

$$\max(E) \quad (19)$$

$$\text{mean}(E) \quad (20)$$

$$\min(E) \quad (21)$$

The maximum energy consumption (Equation 19) indicates the highest energy required for any single operation. The mean energy consumption (Equation 20) provides the average energy used across all operations, reflecting the overall energy profile. The minimum energy consumption (Equation 21) shows the lowest energy usage for an operation, highlighting the least energy-intensive job segment.

$$\sum_{j \in J} \left( \sum_{m \in M} \max_{s \in S} (P_{jms}) \right) \quad (22)$$

Maximum makespan (Equation 22) represents the maximum makespan of the instance obtained, assuming that all operations are performed serially with their maximum processing time. This value gives the longest possible duration to complete all jobs, assuming no parallel processing.

$$\max_{j \in J} \left( \sum_{m \in M} \min_{s \in S} (P_{jms}) \right) \quad (23)$$

Minimum makespan (Equation 23) represents the makespan of the solution obtained by considering that the operations can be performed in parallel and do not overlap. This makespan represents a lower bound of the possible makespan in a solution, indicating the shortest time to complete all jobs if perfectly parallelized.

$$\sum_{m \in M} \left( \sum_{j \in J} \max_{s \in S} (E_{jms}) \right) \quad (24)$$

$$\sum_{m \in M} \left( \sum_{j \in J} \min_{s \in S} (E_{jms}) \right) \quad (25)$$

The sum of the maximum (Equation 24) and minimum (Equation 25) energy consumption is obtained by adding for each operation its maximum and minimum energy consumption, respectively. These values provide insights into the total energy requirements of the job set under extreme conditions.

$$\left\{ \begin{array}{l} -1 \\ \sum_{j \in J} \left( \sum_{m \in M} \max_{s \in S} (P_{jms}) \right) \quad \begin{array}{l} Rd/Dd = 0 \\ Rd/Dd = 1 \end{array} \end{array} \right. \quad (26)$$
provides insights into the relationships between the variables and the probability of the outcomes.

*   **Decision Tree:** This is a decision support tool that uses a tree-like model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. A decision tree is built by splitting the dataset into subsets based on the value of input features, with the goal of making the most informative splits. This method is easy to interpret and visualize, making it useful for understanding the structure of the data.

*   **Gaussian Naive Bayes:** This is a probabilistic classifier based on Bayes' theorem, with the assumption that the features are independent given the class label and that they follow a Gaussian distribution. Despite its simplicity, Gaussian Naive Bayes can perform well in various situations, especially when the assumption of independence roughly holds true.

*   **K-Nearest Neighbors (KNN):** This is a non-parametric method used for classification and regression. For classification, the input consists of the *k* closest training examples in the feature space, and the output is a class membership. The object is assigned to the class most common among its *k* nearest neighbors.

*   **Random Forest:** This is an ensemble learning method for classification and regression that constructs multiple decision trees during training and outputs the mode of the classes (classification) or mean prediction (regression) of the individual trees. Random forests improve the predictive accuracy and control over-fitting by averaging multiple trees, reducing the model's variance.

*   **XGBoost [14]:** This is an optimized distributed gradient boosting library designed to be highly efficient, flexible, and portable. It implements machine learning algorithms under the gradient boosting framework, which builds models in a stage-wise fashion and generalizes them by optimizing for a differentiable loss function. XGBoost is known for its speed and performance, making it a popular choice for structured/tabular data.

*   **Multi-Layer Perceptron (MLP):** This is a class of feed-forward artificial neural networks that consist of at least three layers of nodes: an input layer, a hidden layer, and an output layer. Except for the input nodes, each node (or neuron) uses a nonlinear activation function. MLPs are capable of learning complex mappings from inputs to outputs and are trained using backpropagation.

# 4. Evaluation

All experiments were conducted on a system equipped with an Intel 3.60 GHz 12th generation Core i7 CPU and 64 GB of RAM. The implementation was developed in Python 3.11. Well-known solvers such as GUROBI [15], CPLEX [16], and GECODE [17], which are implemented on Minizinc, were utilized.

To evaluate the quality of the solutions obtained, the mono-objective function shown in Equation 11 is used to compare the best solutions from the solvers. Other important results, such as the average objective function, solving

time, optimum, satisfaction rate, and the number of unsolved solutions, are presented above.

## 4.1. Instances

Instance creation is one of the most important aspects of evaluation as it allows a specific number of instances to be configured to ensure the most comprehensive evaluation possible, taking into account all possible combinations the problem may encounter in real-life scenarios.

The JSP Benchmark used for testing is composed of the number of jobs (*J*) and machines (*M*) to determine each job's tasks. These variables can take any natural number. In this test set, the set {5, 10, 20, 25, 50, 100} is considered for *J*. The release and due date can take values {0, 1, 2}, speed scaling can take values {1, 3, 5}, and statistical distributions considered are {uniform, normal, exponential}. For each configuration, 10 instances are generated with different seeds to ensure substantial variation between them. Therefore, a total of 6(*J*) × 6(*M*) × 3(rddd) × 3(ss) × 3(dist) × 10(*Q*) = 9720 instances are obtained.

<figure><img src="image_21.png" /><figcaption>**Figure 2:** Distribution of timeout and relationship between time and energy.</figcaption></figure>

The time allocated for resolving each instance depends on the specific characteristics of the problem. An example of this allocation is illustrated in Figure 2. In this example, an instance with 50 jobs, 10 machines, no Release Date or Due Date, and a single speed per machine is allocated 149 seconds. The principle is that if the maximum allocation time for an instance is 300,000 milliseconds, each characteristic's impact on the allocation should be equivalent. Therefore, each characteristic contributes at most 300,000/4 = 75,000 milliseconds. In this manner, for the given example, if the Release Date and Due Date are assigned at the operation level (RDDD = 2), they contribute 75,000 milliseconds. If they are absent (RDDD = 0), they contribute 50 milliseconds. When assigned at the job level, the contribution is determined by exponential interpolation between these two cases.

## 4.2. Results

Upon defining the problem instances and setting appropriate search time limits for each solver, the focus shifted toward analyzing and interpreting the outcomes. This involved evaluating the efficacy of the solvers employed, assessing solution quality, and considering the broader implications within the problem domain.
<figure><img src="image_22.png" /><figcaption>**Figure 3:** Quantity of optimum, satisfied and unresolved instances by each solver.</figcaption></figure>

Figure 3 illustrates the distribution of solved instances among GUROBI, CPLEX, and GECODE across three categories: optimal (best solution), satisfied (feasible but not optimal), and unresolved (not solved).

GUROBI emerged as the top performer overall, solving the highest number of optimal solutions and consistently demonstrating its ability to find acceptable solutions even when optimal ones were unfeasible. This underscores GUROBI's robust capability in efficiently managing a diverse array of problem types. Conversely, GECODE excelled in finding feasible solutions, significantly outperforming other solvers in achieving satisfactory solutions. Moreover, GECODE showed the fewest instances left unresolved, highlighting its reliability in tackling complex problems without abandoning them.

In contrast, CPLEX, while proficient, faced challenges with more complex problem instances, leading to a higher incidence of unresolved cases. Although it achieved reasonable numbers of optimal and satisfactory solutions, its performance consistency was observed to be less reliable compared to GUROBI and GECODE.

Table 1 compares solution times and objective function values from GUROBI, CPLEX, and GECODE across different job and machine configurations. This analysis reveals insights into each solver's performance characteristics, highlighting strengths and limitations in solving optimization problems.

For 5 to 20 jobs, GUROBI consistently shows shorter solution times and competitive objective values compared to CPLEX and GECODE. Its efficiency and precision make it highly effective in simpler problem instances.

In medium-sized scenarios (20 to 50 jobs), GUROBI maintains an edge, particularly with fewer machines, though CPLEX occasionally performs better in specific configurations. GUROBI generally achieves superior objective function values in varied problem setups.

In complex cases (50 to 100 jobs), GECODE demonstrates exceptional scalability despite encountering timeouts in some instances. GUROBI and CPLEX struggle more often with timeouts as problem size and complexity increase, yet GUROBI often maintains competitive objective values.

These insights underscore the importance of selecting solvers based on problem specifics. GUROBI excels in smaller to medium-sized instances, balancing efficiency and high-quality solutions. CPLEX performs well in certain

medium-sized setups but faces scalability challenges. GECODE shines in complex problems, offering robust scalability and reliability despite occasional computational hurdles. These findings aid practitioners in optimizing solver choices and considering trade-offs between solution quality, efficiency, and problem complexity.

### 4.3. Complexity analysis

Observing the results obtained by the methods used, a relationship is observed between the parameters employed and the complexity of the instances. This part of the study focuses on the in-depth analysis of each parameter to observe its contribution to the overall complexity of the instances.

<figure><img src="image_23.png" /><figcaption>**Figure 4:** Number of instances solved</figcaption></figure>

To delve deeper into the data presented in Table 1, Figure 4 provides a general overview of the number of solved instances. Organizing the data by the number of machines, as shown in subfigure 4a, it is evident that as the number of machines increases, the number of solved instances progressively decreases except for the case of 5 machines, where all instances are solved for all possible job configurations. Looking at subfigure 4b, which is organized by the number of jobs for all possible machine configurations, it can be seen that all instances are solved for 5 and 10 jobs, but there is a notable decrease for the rest. Focusing on the set of 20 and 25 jobs, it can be observed that there is a slight decrease from 25 machines onwards; later, the reasons for this are analyzed. For instances with 50 and 100 jobs, the decrease in the number of solved instances is exponential. Only all instances are solved for a configuration of 5 machines for 100 jobs and 5 and 10 machines for 50 jobs. This figure
<table><caption>**Table 1**
Comparison of mean resolution time and mean objective function obtained with different solvers.</caption><thead><tr><th rowspan="2">Jobs</th><th rowspan="2">Machines</th><th colspan="3">Solve Time</th><th colspan="3">Objective</th></tr><tr><th>GUROBI</th><th>CPLEX</th><th>Gecode</th><th>GUROBI</th><th>CPLEX</th><th>Gecode</th></tr></thead><tbody><tr><td rowspan="6">5</td><td>5</td><td><strong>6499.47</strong></td><td>9393.54</td><td>76754.74</td><td>0.58053</td><td><strong>0.57924</strong></td><td>0.7748</td></tr><tr><td>10</td><td><strong>22177.73</strong></td><td>35193.18</td><td>77122.47</td><td>0.46884</td><td><strong>0.46842</strong></td><td>0.64781</td></tr><tr><td>20</td><td><strong>50222.29</strong></td><td>57898.63</td><td>81637.16</td><td><strong>0.42377</strong></td><td>0.42422</td><td>0.58867</td></tr><tr><td>25</td><td><strong>55920.19</strong></td><td>59732.08</td><td>79771.76</td><td><strong>0.41208</strong></td><td>0.41279</td><td>0.5677</td></tr><tr><td>50</td><td><strong>69226.88</strong></td><td>71453.81</td><td>95645.56</td><td><strong>0.39632</strong></td><td>0.40691</td><td>0.53307</td></tr><tr><td>100</td><td><strong>110177.22</strong></td><td>123730.15</td><td>154180.72</td><td><strong>0.38944</strong></td><td>0.42882</td><td>0.51176</td></tr><tr><td rowspan="6">10</td><td>5</td><td><strong>72263.13</strong></td><td>76261.31</td><td>85388.49</td><td><strong>0.56284</strong></td><td>0.56433</td><td>0.77965</td></tr><tr><td>10</td><td><strong>69831.23</strong></td><td>71671.93</td><td>86539.69</td><td><strong>0.44524</strong></td><td>0.4482</td><td>0.64365</td></tr><tr><td>20</td><td><strong>71619.72</strong></td><td>74610.4</td><td>89860.43</td><td><strong>0.38908</strong></td><td>0.39532</td><td>0.5713</td></tr><tr><td>25</td><td><strong>73930.71</strong></td><td>78202.9</td><td>91969.19</td><td><strong>0.3798</strong></td><td>0.39247</td><td>0.54207</td></tr><tr><td>50</td><td><strong>89935.3</strong></td><td>95355.06</td><td>109638.51</td><td><strong>0.36431</strong></td><td>0.38019</td><td>0.49456</td></tr><tr><td>100</td><td><strong>146282.37</strong></td><td>152079.82</td><td>168202.69</td><td>0.35029</td><td><strong>0.30281</strong></td><td>0.35159</td></tr><tr><td rowspan="6">20</td><td>5</td><td><strong>80190.01</strong></td><td>88650.74</td><td>89079.98</td><td><strong>0.65727</strong></td><td>0.67151</td><td>0.83772</td></tr><tr><td>10</td><td><strong>80369.98</strong></td><td>89368.09</td><td>89895.89</td><td><strong>0.48249</strong></td><td>0.48393</td><td>0.71326</td></tr><tr><td>20</td><td>91070.63</td><td><strong>83648.86</strong></td><td>92953.44</td><td>0.40615</td><td><strong>0.36374</strong></td><td>0.60325</td></tr><tr><td>25</td><td>92555.52</td><td><strong>86596.51</strong></td><td>96516.25</td><td>0.38184</td><td><strong>0.3135</strong></td><td>0.58104</td></tr><tr><td>50</td><td>109441.69</td><td>97752.14</td><td><strong>78306.1</strong></td><td>0.35987</td><td>0.24087</td><td><strong>0.20729</strong></td></tr><tr><td>100</td><td>164169.07</td><td>161843.67</td><td><strong>112923.84</strong></td><td>0.29168</td><td>0.06245</td><td><strong>0.00733</strong></td></tr><tr><td rowspan="6">25</td><td>5</td><td><strong>73156.78</strong></td><td>86322.15</td><td>91381.59</td><td>0.64018</td><td><strong>0.63401</strong></td><td>0.84305</td></tr><tr><td>10</td><td><strong>78504.99</strong></td><td>83658.47</td><td>92142.26</td><td>0.57263</td><td><strong>0.46831</strong></td><td>0.73123</td></tr><tr><td>20</td><td>99400.75</td><td><strong>83989.35</strong></td><td>95774.25</td><td>0.46229</td><td><strong>0.36985</strong></td><td>0.62663</td></tr><tr><td>25</td><td>104469.18</td><td><strong>76519.47</strong></td><td>102202.35</td><td>0.42563</td><td><strong>0.30161</strong></td><td>0.61462</td></tr><tr><td>50</td><td>118524.24</td><td>127129.68</td><td><strong>59800.26</strong></td><td>0.31818</td><td>0.21552</td><td><strong>0.13974</strong></td></tr><tr><td>100</td><td>168354.77</td><td>Timeout</td><td><strong>113885.23</strong></td><td>0.28319</td><td>Timeout</td><td><strong>0.01021</strong></td></tr><tr><td rowspan="6">50</td><td>5</td><td>101811.91</td><td><strong>86469.46</strong></td><td>110038.97</td><td>0.70258</td><td><strong>0.49251</strong></td><td>0.86043</td></tr><tr><td>10</td><td>115365.19</td><td><strong>71684.29</strong></td><td>110542.27</td><td>0.56627</td><td><strong>0.21168</strong></td><td>0.75717</td></tr><tr><td>20</td><td>108631.5</td><td>117752.67</td><td><strong>78930.63</strong></td><td>0.37003</td><td><strong>0.12673</strong></td><td>0.66168</td></tr><tr><td>25</td><td>105251.06</td><td>120220</td><td><strong>72639.27</strong></td><td>0.43698</td><td><strong>0.16123</strong></td><td>0.57382</td></tr><tr><td>50</td><td>136252.05</td><td>Timeout</td><td><strong>59343.32</strong></td><td>0.47363</td><td>Timeout</td><td><strong>0.14455</strong></td></tr><tr><td>100</td><td>153826.43</td><td>Timeout</td><td><strong>122941.2</strong></td><td>0.91743</td><td>Timeout</td><td><strong>0.04168</strong></td></tr><tr><td rowspan="6">100</td><td>5</td><td>Timeout</td><td><strong>114685.56</strong></td><td>183151.94</td><td>Timeout</td><td><strong>0.32913</strong></td><td>0.86754</td></tr><tr><td>10</td><td>Timeout</td><td>Timeout</td><td><strong>180057.66</strong></td><td>Timeout</td><td>Timeout</td><td><strong>0.77187</strong></td></tr><tr><td>20</td><td>Timeout</td><td>Timeout</td><td><strong>139246.52</strong></td><td>Timeout</td><td>Timeout</td><td><strong>0.68049</strong></td></tr><tr><td>25</td><td>Timeout</td><td>Timeout</td><td><strong>122740.76</strong></td><td>Timeout</td><td>Timeout</td><td><strong>0.59173</strong></td></tr><tr><td>50</td><td>Timeout</td><td>Timeout</td><td><strong>116506.13</strong></td><td>Timeout</td><td>Timeout</td><td><strong>0.4602</strong></td></tr><tr><td>100</td><td>Timeout</td><td>Timeout</td><td><strong>157021.85</strong></td><td>Timeout</td><td>Timeout</td><td><strong>0.13594</strong></td></tr></tbody></table>

illustrates how the number of jobs and machines affects the possibility of obtaining a solution to the problem at hand.

## 4.4. Algorithm selector results

<table><caption>**Table 2**
Table showing the training results of the different models</caption><thead><tr><th>Model</th><th>Accuracy (%)</th></tr></thead><tbody><tr><td>Logistic Regression</td><td>76.08</td></tr><tr><td>Gaussian Naive Bayes</td><td>48.93</td></tr><tr><td>Decision Tree</td><td>79.48</td></tr><tr><td>K-Nearest Neighbors</td><td>78.34</td></tr><tr><td>Random Forest</td><td>82.87</td></tr><tr><td>XGBoost</td><td><strong>83.26</strong></td></tr><tr><td>MLP</td><td>82.81</td></tr></tbody></table>

Table 2 shows the validation results of the tested models. As can be seen, XGBoost is the model with the best validation accuracy. Training this model with the total training data set and testing it with the test set finally yields an accuracy of 84.51%. This indicates that XGBoost performs well during the validation phase and generalizes effectively to

unseen data. The high accuracy suggests that XGBoost's ensemble learning approach, which combines multiple decision trees to improve performance, is particularly well-suited to this dataset. Moreover, the performance difference between XGBoost and other models like Random Forest and MLP, which also showed strong results,

<figure><img src="image_24.png" /><figcaption>**Figure 5:** Confusion matrix for the algorithm selector predictions (true algorithms on the y-axis, predicted algorithms on the x-axis).</figcaption></figure>

The confusion matrix in Figure 5 presents the algorithm selector's classification results. Each cell value represents the number of instances where the algorithm selector predicted the algorithm in the corresponding column for a
problem best solved by the algorithm in the corresponding row. For instance, the selector correctly identified GUROBI for 611 out of the total instances where GUROBI was the best choice. Similarly, GECODE was correctly identified 396 times. However, there are misclassifications, such as predicting GUROBI when CPLEX was optimal, which occurred 70 times.

An in-depth analysis of the precision and recall metrics provides further insights into the performance of the algorithm selector. GECODE achieved a precision of 90.20%, indicating that 90.20% of the instances predicted as GECODE were correctly identified. Its recall was 86.84%, signifying that 86.84% of the actual GECODE instances were correctly detected. This high precision and recall demonstrate the algorithm selector's robustness in identifying GECODE instances accurately.

On the other hand, CPLEX showed a precision of 62.76%, meaning that only 62.76% of the predictions for CPLEX were accurate, and a recall of 73.75%, which indicates that 73.75% of the actual CPLEX instances were correctly classified. The lower precision for CPLEX suggests a higher rate of false positives, which could imply that the algorithm selector often misclassifies other algorithms as CPLEX.

For GUROBI, the precision was 89.85%, reflecting that 89.85% of the GUROBI predictions were correct, and the recall was 86.66%, meaning that 86.66% of the actual GUROBI instances were identified correctly. These values indicate a strong performance, similar to GECODE, highlighting the selector's efficiency in recognizing GUROBI accurately.

These metrics, precision, and recall, are crucial for evaluating the algorithm selector's effectiveness, as they provide a more comprehensive understanding of its performance beyond simple accuracy. They highlight the selector's strengths in accurately identifying certain algorithms while also pointing out areas where misclassification occurs, thus providing a clear direction for further improvements.

## 5. Conclusions

This study explores the complexities of JSP, emphasizing its NP-completeness and diverse optimization goals such as makespan, energy consumption, and tardiness. The problem presents significant computational challenges due to its combinatorial nature, making timely optimal solutions crucial in operations research and manufacturing.

An innovative aspect of this research is integrating machine learning techniques to enhance algorithm selection for JSP instances. By extracting comprehensive features like job and machine characteristics, release dates, and energy requirements, models such as XGBoost and Random Forest were effectively trained. These models accurately recommend suitable solvers like GUROBI, CPLEX, and GECODE, streamlining decision-making for solving diverse and complex scheduling problems.

GUROBI proved particularly efficient for smaller to medium-sized instances, consistently delivering optimal and satisfactory solutions across different configurations. Meanwhile, GECODE demonstrated robust scalability, excelling in complex scenarios despite occasional computational challenges. This analysis underscores the importance of selecting solvers based on specific problem parameters to optimize solution quality and computational efficiency.

Looking ahead, the study suggests refining feature extraction methodologies to enhance the algorithm selector's accu-

racy across a broader range of JSP scenarios. Advancements in solver performance under varying constraints promise to expand the practical utility of scheduling optimization tools in real-world manufacturing settings, emphasizing efficiency and sustainability.

Although the results obtained are not as high as those reported in the literature, it should be noted that the energy-aware JSP constitutes a more complex problem compared to the standard JSP and flexible JSP found in the literature. Furthermore, this study uses a smaller set of features than those used in other studies, yet the accuracy achieved is not significantly lower.

In conclusion, this work advances both academic understanding and practical applications by integrating traditional optimization techniques with modern machine-learning approaches. It offers tools that can significantly benefit research and industrial practices, addressing contemporary challenges in operations management and manufacturing logistics.

## References

[1] H. Xiong, S. Shi, D. Ren, J. Hu, A survey of job shop scheduling problem: The types and models, Computers & Operations Research 142 (2022) 105731. doi:https://doi.org/10.1016/j.cor.2022.105731.

[2] D. B. M. M. Fontes, S. M. Homayouni, J. F. Gonçalves, A hybrid particle swarm optimization and simulated annealing algorithm for the job shop scheduling problem with transport resources, European Journal of Operational Research 306 (2023) 1140-1157. doi:https://doi.org/10.1016/j.ejor.2022.09.006.

[3] D. M. Torres, F. Barber, M. A. Salido, Psplib-energy: a extension of psplib library to assess the energy optimization in the rcpsp, Inteligencia Artificial 17 (2014) 48-61. doi:10.4114/intartif.vol17iss54pp48-61.

[4] M. M. S. El-Kholany, M. Gebser, K. Schekotihin, Problem decomposition and multi-shot asp solving for job-shop scheduling, 2022.

[5] C. Perez, M. A. Salido, D. Gurrea, A metaheuristic search technique for solving the warehouse stock management problem and the routing problem in a real company, in: Artificial Intelligence XXXVII, Springer International Publishing, Cham, 2020, pp. 187-201.

[6] M. Dai, D. Tang, A. Giret, M. A. Salido, Multi-objective optimization for energy-efficient flexible job shop scheduling problem with transportation constraints, Robotics and Computer-Integrated Manufacturing 59 (2019) 143-157. doi:https://doi.org/10.1016/j.rcim.2019.04.006.

[7] C. Pérez, L. Climent, G. Nicoló, A. Arbelaez, M. A. Salido, A hybrid metaheuristic with learning for a real supply chain scheduling problem, Engineering Applications of Artificial Intelligence 126 (2023) 107188. doi:https://doi.org/10.1016/j.engappai.2023.107188.

[8] M. A. Salido, J. Escamilla, A. Giret, F. Barber, A genetic algorithm for energy-efficiency in job-shop scheduling, Int J Adv Manuf Technol 85 (2016) 1303-1314. doi:https://doi.org/10.1007/s00170-015-7987-0.

[9] K. Jyothi, R. B. Dubey, Minimizing non-processing en-
ergy consumption/total weighted tardiness &amp; ear-
liness, and makespan into typical production schedul-
ing model-the job shop scheduling problem, Journal
of Intelligent & Fuzzy Systems 45 (2023) 6959-6981.
doi:10.3233/JIFS-222362.

[10] A. Ham, M.-J. Park, K. M. Kim, Energy-aware flexible job shop scheduling using mixed integer programming and constraint programming, Mathematical Problems in Engineering 2021 (2021) 1-12. doi:10.1155/2021/8035806.

[11] D. Müller, M. G. Müller, D. Kress, E. Pesch, An algorithm selection approach for the flexible job shop scheduling problem: Choosing constraint programming solvers through machine learning, European Journal of Operational Research 302 (2022) 874-891. doi:https://doi.org/10.1016/j.ejor.2022.01.034.

[12] S. Strassl, N. Musliu, Instance space analysis and algorithm selection for the job shop scheduling problem, Computers & Operations Research 141 (2022) 105661. doi:https://doi.org/10.1016/j.cor.2021.105661.

[13] J. R. Rice, The algorithm selection problem. this work was partially supported by the national science foundation through grant gp-32940x. this chapter was presented as the george e. forsythe memorial lecture at the computer science conference, february 19, 1975, washington, d. c., in: Advances in Computers, volume 15 of *Advances in Computers*, Elsevier, 1976, pp. 65-118. doi:https://doi.org/10.1016/S0065-2458(08)60520-3.

[14] T. Chen, C. Guestrin, Xgboost: A scalable tree boosting system, in: Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, KDD '16, ACM, 2022, p. 785-794. doi:10.1145/2939672.2939785.

[15] Y. Zeiträg, J. Rui Figueira, G. Figueira, A cooperative coevolutionary hyper-heuristic approach to solve lot-sizing and job shop scheduling problems using genetic programming, International Journal of Production Research (2024). doi:10.1080/00207543.2023.2301044.

[16] D. Rooyani, F. M. Defersha, An efficient two-stage genetic algorithm for flexible job-shop scheduling, IFAC-PapersOnLine 52 (2019). doi:10.1016/j.ifacol.2019.11.585.

[17] L. Ingmar, C. Schulte, Making compact-table compact, in: Principles and Practice of Constraint Programming, Springer International Publishing, Cham, 2018, pp. 210-218.
# Instance Configuration for Sustainable Job Shop Scheduling

Christian Pérez<fnref n="1" />,<fnref n="2" />,*,†, Carlos March<fnref n="1" />,† and Miguel Salido<fnref n="1" />

**Abstract**

The Job Shop Scheduling Problem (JSP) is a pivotal challenge in operations research and is essential for evaluating the effectiveness and performance of scheduling algorithms. Scheduling problems are a crucial domain in combinatorial optimization, where resources (machines) are allocated to job tasks to minimize the completion time (makespan) alongside other objectives like energy consumption. This research delves into the intricacies of JSP, focusing on optimizing performance metrics and minimizing energy consumption while considering various constraints such as deadlines and release dates. Recognizing the multi-dimensional nature of benchmarking in JSP, this study underscores the significance of reference libraries and datasets like JSPLIB in enriching algorithm evaluation. The research highlights the importance of problem instance characteristics, including job and machine numbers, processing times, and machine availability, emphasizing the complexities introduced by energy consumption considerations.

An innovative instance configurator is proposed, equipped with parameters such as the number of jobs, machines, tasks, and speeds, alongside distributions for processing times and energy consumption. The generated instances encompass various configurations, reflecting real-world scenarios and operational constraints. These instances facilitate comprehensive benchmarking and evaluation of scheduling algorithms, particularly in contexts of energy efficiency. A comprehensive set of 500 test instances has been generated and made publicly available, promoting further research and benchmarking in JSP. These instances enable robust analyses and foster collaboration in developing advanced, energy-efficient scheduling solutions by providing diverse scenarios.

**Keywords**

Job Shop Scheduling Problem, Instance Generation, Benchmarking, Energy consumption, Speed scaling

## 1. Introduction

The Job Shop Scheduling Problem (JSP) stands as a cornerstone in the realm of operations research and optimization, representing a fundamental challenge pivotal for evaluating algorithmic effectiveness and performance. In essence, JSP revolves around the intricate task of allocating jobs to machines within a manufacturing environment to optimize a plethora of performance metrics, ranging from makespan and flow time to tardiness, resource utilization, and energy consumption [1]. The process of benchmarking in JSP is multi-dimensional, necessitating the definition and evaluation of metrics such as makespan, energy consumption, and tardiness to assess scheduling efficiency and resource utilization [2]. Reference libraries and datasets like JSPLIB play an indispensable role in these benchmarking endeavours, furnishing researchers with a rich array of instances sourced

from seminal works and experimental studies, thereby enriching the evaluation of algorithms [3].

A profound understanding of problem instance characteristics significantly shapes benchmarking efforts in JSP. Factors such as the number of jobs and machines, variability in processing times, machine availability, and precedence relationships exert notable influences on algorithm performance [4]. Furthermore, incorporating energy consumption considerations, contingent upon machine speed and operational attributes, introduces an added layer of complexity to these instances [5]. The delicate balance between energy consumption and scheduling decisions emerges as paramount in achieving energy efficiency goals without compromising production targets [6].

In recent years, the spotlight on addressing energy efficiency within the realm of JSP has intensified, driven by its profound environmental and economic implications [7]. Strategies involving integrating speed-adjustable machines and vehicles have been explored as avenues to optimize energy consumption while upholding productivity levels [8]. Concurrently, developing advanced algorithms and optimization techniques tailored to tackle energy-related challenges has seen significant advancements, considering factors such as machine speed, idle time, and energy requirements [9]. Real-world implementations of these energy-efficient strategies have yielded tangible benefits, manifesting in substantial cost savings

ConfWS'24: 26th International Workshop on Configuration, Sep 2-3,
2024, Girona, Spain

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

<footnote n="1">¹Universitat Politécnica de València, Instituto de Automática e Informática Industrial, Camí de Vera S/N, Valencia, Spain</footnote>

<footnote n="2">²Universitat Politécnica de València, valgrAI - Valencian Graduate School and Research Network of Artificial Intelligence, Camí de Vera S/N, Valencia, Spain</footnote>

<footnote>* Corresponding author.</footnote>

<footnote>† These authors contributed equally.</footnote>

<footnote>✉ cripber@upv.es (C. Pérez); cmarmoy@upv.es (C. March); msaldo@upv.es (M. Salido)</footnote>

<footnote>✉ https://gps.blogs.upv.es/ (C. Pérez); https://gps.blogs.upv.es/ (C. March); https://gps.blogs.upv.es/ (M. Salido)</footnote>

<footnote>✉ 0000-0002-9121-7939 (C. Pérez); 0009-0009-7525-9133 (C. March); 0000-0002-4835-4057 (M. Salido)</footnote>

<footnote>© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License
Attribution 4.0 International (CC BY 4.0)</footnote>
and positive environmental impacts [10].

In conclusion, the imperative of energy efficiency in JSP research has become increasingly pronounced, paralleling the traditional focus on performance metrics [11]. Benchmarking is a linchpin in evaluating the efficacy of energy-efficient scheduling strategies, furnishing invaluable insights into their ramifications on production efficiency and energy consumption [12]. Manufacturers can embark toward more sustainable and economically viable operations by harnessing advanced optimization techniques and leveraging real-world implementations.

## 2. Instance Configuration

Test sets play a vital role in JSP research by providing a standardized platform for comparing algorithmic approaches. Their diversity enables researchers to evaluate various algorithms, from heuristics to exact methods, identifying strengths, weaknesses, and potential limitations across different contexts [13]. However, as industrial systems evolve, the complexity of real-world problems increases, necessitating the development or expansion of test sets to simulate real-world scenarios better.

To address this need, the proposed instance configurator operates with the following parameters:

* $J = \{0, \dots, n\}$: the set of jobs.

* $M = \{0, \dots, m\}$: the set of machines.

* $S = \{0, \dots, s\}$: the set of speeds, indexed by $s$ in $S$.

* $T_j$: the set of tasks in job $j$, indexed by $t_{jt} \in T_j, \forall j \in J, \forall t \in M$.

* $D_{jt}$: the due date of task job $t_{jt} \forall j \in J, \forall t \in M$.

* $R_{jt}$: the release date of task job $t_{jt} \forall j \in J, \forall t \in M$.

* $P_{jts}$: the processing time of task job $t_{jt}, \forall j \in J, \forall t \in M, \forall s \in S$.

* $E_{jts}$: the energy consumption for processing task job $t_{jt}, \forall j \in J, \forall t \in M, \forall s \in S$.

The process of configuring instances, managed by Algorithm 1, is initiated by receiving several input parameters: the number of instances to generate $Q$, the number of machines $M$, the count of jobs $J$, the number of tasks $t$, the types of release and due dates $rrdd$, random seeds $seeds$, and the distribution $dist$.

Subsequently, the algorithm executes a series of steps to generate instances systematically. The random seed is initialized to ensure reproducibility, and an empty list $G$ is created to store the generated instances (Line 2). The

**Algorithm 1 Instance Configurator**

**input:** Quantity of instances $Q$, Number of machines $M$, Number of jobs $J$, Number of tasks $T$, Release and due date type $rrdd$, Random seed $seed$, Distribution $dist$
**output:** Generated instances $G$

1: SetSeed(seed)

2: $G \leftarrow []$

3: **for** $q$ from 1 to $Q$ **do**

4: &nbsp;&nbsp;&nbsp;&nbsp;O $\leftarrow$ GenerateJobsOperations($T$, $J$, $M$)

5: &nbsp;&nbsp;&nbsp;&nbsp;$P \leftarrow$ GenerateProcessingTimes($J$, $M$, $S$)

6: &nbsp;&nbsp;&nbsp;&nbsp;$E \leftarrow$ GenerateEnergy($J$, $M$, $S$)

7: &nbsp;&nbsp;&nbsp;&nbsp;$R$, $D \leftarrow$ GenerateRDDate($J$, $M$, $dist$)

8: &nbsp;&nbsp;&nbsp;&nbsp;$G \leftarrow G \cup JSP(O, P, E, R, D)$

9: **end for**

10: **return** $G$

algorithm generates jobs and tasks within a loop iterating through each instance $q$ from 0 to $Q-1$ (Line 4).

Next, each job operation's processing times and energy consumption are generated.

$$f(x) = \lfloor e^{-\frac{x}{100}} \times 100 \rfloor \quad (1)$$

$$g(x) = 4.0704 \times \frac{\log(2)}{\log(1 + (x \times 2.5093)^3)} \quad (2)$$

The functions responsible for generating the processing times (line 5) and energy consumption (line 6) for the combination of jobs, machines, and speeds are managed by functions $f(x)$ 1 and $g(x)$ 2, as illustrated in Figure 1 as studied in [14]. These functions balance the variables to establish a correlation between processing time and energy consumption. In these equations, $x$ represents the processing time for Equation $f(x)$ 1 and the energy consumption for Equation $g(x)$ 2. Speeds are generated by obtaining the energy consumption percentage for each speed using Equation $f(x)$ 1, which models an inverse relationship between processing time and energy consumption. This involves dividing the interval [0.5, 3] into $|S| - 1$ equal parts, where the boundaries of these new intervals correspond to the energy consumption percentages for each speed. Subsequently, Equation $g(x)$ 2 is utilized to determine the fraction of time corresponding to each speed.

Release and due dates are computed using functions based on the chosen distribution (Line 7). Each distribution offers distinct characteristics suited for modeling various real-world scenarios.

The exponential distribution, defined by its probability density function $f(x; \lambda) = \lambda e^{-\lambda x}$, is ideal for modeling the time until an event occurs, such as machine failures or job arrivals, assuming a constant hazard rate $\lambda > 0$. Its mean is $\frac{1}{\lambda}$. The Gaussian distribution, with mean $\mu$ and standard deviation $\sigma$, has a probability density function