Preventive Planning of ‘Product-as-a-Service’ Offers Using Genetic Population-Driven Stepping Crawl Threads

Abstract

Unlike the precise methods implemented in constrained programming environments, the proposed approach to preventive planning of Product-as-a-Service offers implements a competitive solution based on Genetic Population Stepping Crawl Threads (GPSCT).GPSCT techniques are used to determine the so-called stepping crawl threads (SCT) that recreate, in subsequent steps, variants of the allocation of sets of leased devices with parameters that meet the expectations of the customers ordering them by means of genetic algorithms. SCTs initiated at a selected point of the Cartesian product space of the functional repertoire of the equipment offered penetrate it in search of offer variants that meet the constraints imposed by the size of the budget and the risk level (i.e., expressed as the likelihood of damaging the device or losing part of its functionality) of individual customers. Two approaches of implementation techniques were used to determine the initial SCT population for the genetic algorithm—branch and bound (BBA) and linear programming (LPA). Many experiments assessed their impact on the computation time and the quality of the obtained solution. The performed computational experiments indicate that the effectiveness of both approaches depends on the specificity of the problem considered each time. Interestingly, for different instances of the problem, an alternative solution can always be selected that is competitive with the exact methods, allowing for a 10-fold increase in scalability.

1. Introduction

The integration of Product-as-a-Service (PaaS) models in contemporary business landscapes has reshaped the traditional paradigms of product delivery, emphasizing the importance of service-oriented approaches [1,2]. However, this shift from traditional product-centric transactions to comprehensive service-based solutions introduces a set of unique challenges, particularly regarding the potential risks to which customers are exposed in situations that threaten to lose some of the functionality of leased devices when accepting equipment providers’ PaaS offers. In the context of PaaS offers, effective resource allocation becomes a crucial aspect of preventive planning to ensure the seamless provision of services while proactively mitigating potential risks [3,4].

The dynamic and evolving nature of PaaS offerings, particularly in preventive planning scenarios, demands a strategic allocation of resources to address uncertainties and preemptively handle potential challenges [3,5]. Conducted research confirms these possibilities. A developed provider–customer reference model [6,7] allows for a formal recognition of the relationships connecting the capabilities of the equipment provider with the needs and limitations of the customer. The scale of the resource allocation problems formulated therein (i.e., the allocation of customized equipment to the customers ordering it) was limited by the capabilities of the available constraints programming environments implementing the adopted declarative representation of the reference model. In the case considered, the number of offers was ≤13, and the number of leased equipment was ≤8.

Although constraint programming can be used to model and optimize resource allocation decisions [8] while adhering to various constraints, e.g., including budget constraints, resource availability, and specific requirements associated with PaaS services, its main deficiency results from high computational costs, especially in the case of a large number of variables and constraints [9,10]. This means it is necessary to combine constraint programming with other optimization and heuristic methods, e.g., genetic algorithms (GA) to enhance its effectiveness in real-world applications.

Unlike the conventional formulation [11,12,13], which searches for a PaaS offer allocation to potential customers, the proposed model looks for the structures of the so-called stepping crawl threads (SCT) reconstructing variants of ordered equipment. SCT stages, which step by step determine new variants of sets of ordered equipment, explore the Cartesian product space of the equipment’s functionalities. Initiated from the starting point, SCTs follow a search for offer variants within the budget and risk constraints of individual customers. Reconstructions of equipment sets ordered by customers are assessed in subsequent SCT states while approximating planned offers.

The adopted model allows the formulation of two types of resource allocation problems. The first one seeks the answer to the question: can all customers be satisfied with the offers they expect without exceeding the PaaS provider’s capabilities? The second one is: how many resources the PaaS provider should have to guarantee offers that satisfy customer expectations? Further considerations will focus on the first of them.

The proposed approach uses two algorithms for generating initial populations of SCTs: the branch and bound approach (BBA) and the linear programming approach (LPA). The size of the initial population and the quality of the individuals comprising it affect the time of selecting the offer and its quality (measured by the number of provider resources used to guarantee the given robustness of the offer). The effectiveness of the proposed BB and LP approaches has been verified experimentally.

To summarize, this paper delves into the resource allocation problem within the framework of preventive planning for PaaS offers, aiming to optimize the utilization of resources and enhance the overall robustness of service delivery. Compared to our previous work [7,14] carried out in this area, its main contribution comes down to the development of a new PaaS offer planning method with significantly increased efficiency (i.e., scalability).

The structure of this study is as follows: Section 2 provides a literature review. Section 3 presents the modeling framework behind preventive planning for Product-as-a-Service offerings. Based on the authors’ introduced solution space concept, distinguishing the concepts of the so-called feasible and robust solution spaces, the problem of proactive planning of leasing offers was formulated. Section 4 elaborates on a branch and bound/linear programming-driven genetic algorithm, dedicated to determining acceptable variants of leasing offers. The case study presented in Section 5 summarizes the results of both qualitative and quantitative computer experiments aimed at assessing the scalability of the proposed approach. Conclusions and directions of future research are suggested in Section 6.

2. Literature Review

The considerations pertain to the formulation of strategies for offering multifunctional devices for rental under the Product-as-a-Service (PaaS) model, addressing key aspects such as the allocation of equipment to customers, failure rates of leased devices, and the proactive scheduling of maintenance services. These strategies must also account for constraints related to the supplier’s capabilities and the associated risks faced by customers in scenarios where device functionality may be compromised.

2.1. Product-as-a-Service

PaaS, also known as “Product-service-systems” has been a widely researched topic in academic literature since the 1990s [15,16]. PaaS represents a transformative business model that shifts focus from product ownership to fulfilling customer needs through servitization, where products are offered as services rather than sold outright, focusing on service performance and circular economy principles [17,18], encouraging manufacturers to design products complemented with services such as repair or replacement in subscription systems making products durable, energy-efficient, and easier to remanufacture or recycle, setting a precedent for sustainability. In the PaaS model products are offered in subscription systems with associated services, and since ownership is not transferred to the customer, there is great potential for the circular economy, as the company is responsible for producing a better product.

In the context under consideration, i.e., the so-called Software-Defined Production Systems, it is also worth pointing out the growing importance of other similar concepts such as Manufacturing-as-a-Service (MaaS) and Serviceability. MaaS is a service that delivers manufactured products by connecting its network of suppliers with its customers on a digital platform [19,20]. MaaS helps in the adoption of distributed manufacturing aiming for flexibility, agility, and enhanced customer orientation in manufacturing building mass customization capabilities, thereby enabling production on demand [21]. In turn, serviceability, which refers to the ease and convenience of performing maintenance, such as availability, modularity, standardization, and compatibility of components, supports the expectations mentioned above [22].

However, some research [23,24] has raised concerns about the potential downsides of leasing. They argue that leasing can lead to a reduction in product durability due to possible misuse by the lessee, who may be less careful with the equipment since they do not own it. To mitigate the risk of equipment abuse, it is important to incentivize lessees to take good care of the leased equipment during the lease period. Therefore, an offer type that encourages such responsible behavior, benefiting both parties in the lease agreement, needs to be developed.

In the PaaS model, the lessor typically includes maintenance services as part of the lease agreement [25]. This makes the lessor responsible for implementing an effective maintenance strategy, particularly for preventive maintenance (PVM) and/or predictive maintenance (PDM), to ensure the equipment remains operational in a cost-effective manner.

2.2. Leasing Maintenance Strategies

The literature on the subject distinguishes the following types of maintenance: corrective, preventive, predictive, and normative. Corrective maintenance is performed when a fault is detected or when there are clear signs of a malfunction. Preventive maintenance, on the other hand, is scheduled at specific intervals to prevent potential failures. Predictive maintenance takes this a step further by using time-based data and insights to anticipate and prevent failures, thereby avoiding downtime. Finally, prescriptive maintenance not only predicts potential issues but also provides actionable recommendations on how to control the occurrence of specific events [26,27]. For rented equipment, the most common maintenance strategies are preventive maintenance (PVM) and predictive maintenance (PDM).

The goal of preventive maintenance is to detect and correct any potential problems before they lead to equipment failure, reducing downtime and the need for costly repairs. This type of maintenance aims to move away from corrective maintenance, which is only performed to fix or correct a problem rather than prevent potential issues before they arise. This means that it is usually based on the manufacturer’s recommendations and involves tasks such as inspections, cleaning, lubrication/greasing, tightening, calibration, and parts replacement based on a recurring cycle.

Some scholars have demonstrated that cost-revenue-sharing contracts can ensure supply chain coordination [28]. Various studies have explored such contracts to coordinate the product supply chain among manufacturers, suppliers, retailers, and customers [29,30,31,32], as well as the service supply chain [3,33]. Additionally, a few studies have incorporated warranty contracts into the optimization of PVM policies for leased equipment. For example, Hajej et al. [34] examined the leasing contract during the warranty period, considering its effects on failure rates. Hamidi et al. [35] developed a game-theoretic model where the lessee determined the optimal lease duration and usage rate, while the lessor optimized the PVM policy. Iskandar and Husniah [36], and Iskandar et al. [37], proposed one- and two-dimensional lease contracts with infinite time and usage limits. Wang et al. [38] optimized upgrade and PVM strategies under successive usage-based lease contracts, taking into account the OEM (Original Equipment Manufacturer) warranty, while Husniah et al. [39] considered both crisp and fuzzy usage rates in lease contracts that included service strategies for used products.

In recent years, the application of IoT and other Industry 4.0 technologies has improved maintenance operations. The key idea is to deploy IoT sensors on every machine to facilitate communication between devices, systems, and the flow of information. A network of smart sensors is created to receive real-time data on equipment conditions, which is then analyzed using big data techniques to identify maintenance needs and improve equipment performance and reliability [40,41,42].

Even if proactive and/or predictive maintenance strategies are used, leased equipment failures are also difficult to avoid altogether. Conversely, if no preventive and/or predictive activities are planned, once an unexpected resource failure occurs, any operation on the resource will be rejected during its downtime. To solve this problem, an unplanned maintenance activity is required to restore the equipment to its original state, which always causes longer downtime of the resource, resulting in degraded operations system stability and performance.

To mitigate the impact of such disruptions, a disruption-tolerant planning approach can be integrated into the maintenance strategy. This approach emphasizes the creation of contingency plans and flexible operational workflows that can adapt in real time to equipment failures or resource downtime. By utilizing dynamic scheduling, alternative resource allocation, and real-time monitoring, the system can redirect tasks to other available resources or adjust production schedules to minimize overall downtime. Additionally, predictive analytics can be employed to anticipate potential failures and preemptively adjust operations before a breakdown occurs. This not only reduces the total downtime but also ensures that system performance is maintained at an optimal level, even when unforeseen disruptions arise. By embedding such robustness to disruptions into the planning process, organizations can significantly enhance operational stability and improve their ability to recover from unplanned equipment failures.

2.3. Robustness of Leased Equipment to Loss of Rented Functionalities

Robust planning ensures satisfactory performance across a wide range of future scenarios, while adaptive planning allows for adjustments to unforeseen future conditions [43]. To achieve this, investing in disruption-prevention resources and strategically deploying them after disruptions is essential.

Robustness is a concept that exists in many fields with similar general interpretations, but at a detailed level may be significantly different. Certainly, in cases where robustness is defined by some application-specific metric, the definition has little use outside the application area. However, generally, robustness refers to how a system or plan behaves in the presence of uncertainty. This can, for example, be that some plan is created using estimates of parameters, but operated with a realization of those parameters that can differ from the estimates. A plan that behaves well under a wide range of realizations of parameters is considered robust, whereas a plan that behaves very differently or even fails under different realizations is less robust. In other words, a robust plan is defined as one that delivers outcomes considered satisfactory based on specific assessment criteria across a broad spectrum of plausible future scenarios [44].

As discussed in Section 2.1, planning Platform-as-a-Service (PaaS) offerings under conditions of disruption, such as the failure of leased equipment, has been extensively addressed through various preventive and predictive strategies (see Section 2.2). However, existing approaches in the literature concerning the maintenance of leased devices often fall short of meeting the expectations of both providers and customers. These studies primarily focus on specific aspects of the problem such as maintenance policy for leased equipment [45,46], prognosis and health management (PHM) in the leased manufacturing system [47], warranty for leased equipment from the lessor’s perspective [48], leaving critical gaps unaddressed. To address this limitation, our research extends the classic resource allocation problem (RAP) [49] by incorporating the concept of disruption-robust offers—those that ensure the continuity of expected functionalities even in the event of a device failure. By considering this form of robustness, it becomes possible to mitigate costs associated with the risk of equipment failure.

2.4. Modeling Frameworks

The above-mentioned issues are usually formulated in deterministic models that allow them to be solved by exact operational research methods, such as Mixed-Integer Programming [50] and constraint programming [51], however most often though by approximate methods, including heuristic and metaheuristic methods such as Genetic Algorithms, Adaptive Large Neighborhood Search [52,53], and also deep machine learning [54]. Stochastic representations of scheduling and routing models are rare [55]. A similar situation occurs when trying to model problems described by parameters with uncertain, vague values using the formalism of fuzzy sets and those implementing the declarative modeling paradigm enabling constraint programming environments.

Our previous works [7,14] in the area of planning disruption-robust rental based on a PaaS model dedicated to multifunction devices offers have shown that the concept of robustness can be successfully used in the discussed topic. The research implemented a declarative modeling framework enabling computer experiments in the environment IBM ILOG CPLEX. The results of the conducted studies highlighted the shortcomings of the adopted representation, limiting its use online to relatively small-scale problems. The attempt to overcome these limitations using a Genetic Algorithm (GA) demonstrated its effectiveness [56]. The scale of the problems considered increased by 30%, although at the cost of omitting some feasible solutions. Because GAs are frequently used in optimization problems across industries, concerning areas such as routing, scheduling, and decision-making including PaaS models [57,58,59,60], this direction has been taken up once again in this work. Its aim is to develop a method supporting decision-making enabling the search for a balance between the supply of available equipment (supplier capacity) and customer demand (expectations). Attempts made in this regard concern, for instance, Machine Maintenance Management [61] and Computerized Maintenance Management [62] systems. In addition to these first attempts, it is worth pointing out other research gaps, such as:

• There are no reference models integrating the Product-as-a-Service paradigm with leasing maintenance strategies and techniques ensuring the robustness of leased equipment to the loss of rented functionalities, enabling the search for a balance between the supply of available supplier capacity and customer expectations.
• There is a lack of methods for the integrated preventive-predictive maintenance of multifunctional resources leased to a group of lessors.
• There are no models that allow for taking into account the uncertainty of parameters of leased devices as well as the costs and dates of related services.

Filling these gaps contributes to creating systems supporting both the PaaS provider in planning preventive-predictive maintenance of multifunction devices and its lessors.

3. Preventive Planning of Product-as-a-Service Offers

3.1. The Modeling Framework

The PaaS provider has a set of $n$ types of devices: $\mathcal{K}=\{k_1, k_2,\dots ,k_i,\dots , k_n\}$. Each type of device $k_i\in \mathcal{K}$ is characterized by a subset of the $O_{k_i}$ functionalities from the set $O=\{o_1,o_2,\dots ,o_l\}$ (i.e., $O_{k_i}\subseteq O$). In the algebraic representation, the functionalities of devices can be represented in the form of a matrix $K$. Each row of the $K$ matrix (corresponding to the $k_i$ type of device) corresponds to the sequence $[k_{i,1}, k_{i,2},\dots ,k_{i,j},\dots , k_{i,l}]$, where $k_{i,j}$ determines whether device type $k_i$ has functionality $o_j$ ($k_{i,j}=1$) or not ($k_{i,j}=0$):

$$K=\left[\begin{array}{c}{k}_1\\ k_2\\ ⋮\\ k_n\end{array}\right]=\left[\begin{array}{cccc}{k}_{\mathrm{1,1}}& k_{\mathrm{1,2}}& \cdots & k_{1,l}\\ k_{\mathrm{2,1}}& k_{\mathrm{2,2}}& \cdots & k_{2,l}\\ ⋮& ⋮& \ddots & ⋮\\ k_{n,1}& k_{n,2}& \cdots & k_{n,l}\end{array}\right].$$

(1)

The number of devices of a given type is determined by the sequence $Z=[z_1,z_2,\dots , z_i,\dots ,z_n]$, where $z_i\in \mathbb{N}$ means the number of devices of type $k_i$. The cost of renting each type of device is determined by the sequence $Q=[q_1,q_2,\dots ,q_i,\dots ,q_n]$, where $q_i$ is the cost of the device type $k_i$.

There is a set of potential customers $\mathbb{C}=\left\{C_1,C_2,\dots ,C_u,\dots ,C_p\right\}$ looking for offers (sets of devices) that meet their expected assumptions. Each customer $C_u\in \mathbb{C}$ expects access to a set of devices that fulfill the functionalities specified by the sequence $E{C}_u=\left[e{c}_{u,1}, e{c}_{u,2},\dots ,e{c}_{u,j},\dots ,e{c}_{u,l}\right]$, where $e{c}_{u,j}\in \mathbb{N}$ specifies the number of functionalities of type $o_j$ expected by customer $C_u$. Each customer $C_u\in \mathbb{C}$ has a budget ${EB}_u$, which cannot be exceeded (i.e., the sum of the costs of devices cannot exceed this value).

Each of the potential customers $C_u\in \mathbb{C}$ is looking for an offer of PaaS provider devices denoted as the sequence $X_u=[x_{u,1}, x_{u,2},\dots ,x_{u,i},\dots ,x_{u,n}]$, where $x_{u,i}$ means number of $k_i$ type devices offered. The functionalities offered as part of the $X_u$ offer, described with the sequence $S_u$, can be defined as follows:

$$S_u=\left[s_{u,1},s_{u,2},\dots ,s_{u,j},\dots ,s_{u,l}\right]=X_u\times K,$$

(2)

where $s_{u,j}\in \mathbb{N}$ is the number of functionalities $o_j$ made available to customer $C_u$ by the PaaS provider as part of the $X_u$ offer. $A\times B$—product of matrices A and B. For example, if the prepared offer $X_u$ is set according to the sequence: $X_u=[1, 2, 1]$, then customer $C_u$ is offered 1 device of type $k_1$, 2 devices $k_2$ and 1 device $k_3$. Assuming that the matrix $K$ is: $K=\left[\begin{array}{ccc}1& 0& 1\\ 1& 1& 0\\ 0& 1& 1\end{array}\right]$, then $k_1=[1, 0, 1]$ (i.e., device type $k_1$ has functionality $o_1$ and $o_3$), $k_2=[1, 1, 0]$ (i.e., device type $k_2$ has functionality $o_1$ and $o_2$)) and $k_3=[0, 1, 1]$ (i.e., device type $k_3$ has functionality $o_2$ and $o_3$). The functionalities offered as part of the offer $X_u$ are therefore described by the sequence $S_u$ (obtained as the product of the matrix $X_u\times K$—see (2)) of the form: $S_u=\left[3, 3, 2\right]$. This means that as part of the presented offer, the customer will have 3 functionalities $o_1$, 3 functionalities $o_2$, and 2 functionalities $o_3$.

The cost $B_u$ of the offer $X_u$ can, in turn, be described by the equation:

$$B_u=X_u\times Q^T.$$

(3)

In addition to knowing the leasing costs, the customer wants to be sure that in the event of a failure of one or more of the ordered devices, the functionalities of these devices can be met (replaced) by the remaining functional ones. Equipment failure is further understood as a situation in which one of the devices (of type $k_i$) fails and its functionalities are no longer available to the customer. As a consequence of this assumption, it becomes possible to introduce the robustness $R_u\in 〈\mathrm{0,1}〉$ of the $X_u$ offer, understood as the ratio of failure scenarios in which the customer still has the full set of required functionalities ($ns$) to all considered failure scenarios ($nsa$):

$$R_u={\displaystyle \frac{ns}{nsa}},$$

(4)

where $R_u=0$ means lack of robustness, i.e., for each failure scenario of a single device its functionality cannot be replaced by other functional devices; $R_u=1$ it means full robustness, i.e., for each failure scenario of a single device, other rented devices offer the functionalities of the malfunction. PaaS provider knows about the $C_u$ robustness level ${ER}_u$ of each customer, therefore his offer must meet the customer’s requirements $R_u\ge {ER}_u$.

The proposed approach to planning PaaS offerings addresses the main question: Given a set of customers $\mathbb{C}$, can a corresponding set of offers $\mathbb{X}=\left\{X_1,X_2,\dots , X_u,\dots ,X_p\right\}$ be formulated to satisfy their requirements (detailed below)?

To fulfill the specified constraints, each offer $X_u\in \mathbb{X}$ must ensure the following:

(I)

Functionality: $\forall j\le l:s_{u,j}\ge e{c}_{u,j}$.

(II)

Budget: $B_u\le E{B}_u$.

(III)

Device Availability: $\forall i\le n:x_{u,i}\le z_i$.

(IV)

Robustness: $R_u\ge {ER}_u$.

The methodology for identifying offers that satisfy these constraints (I–IV) is outlined in Section 4. This approach is grounded in the “space of stepping crawl thread” concept introduced in Section 3.2

An illustration of an example problem in which a PaaS provider assesses the possibility of preparing robust ($R_u\ge {ER}_u$) offers for two customers ($C_1$ and $C_2$) is shown in Figure 1. The provider has three types of devices $\mathcal{K}=\left\{k_1, k_2, k_3\right\}$ respectively in number: fifteen, five, ten. Customers expect offers that include devices that guarantee two functionalities: $o_1,o_2$ in numbers eight and five (for customer $C_1$) and eleven and three (for customer $C_2$), respectively.

The formulated problem is an extension of the classic problem of resource allocation [63] with the possibility of searching for so-called disruption-robust offers (i.e., guaranteeing the maintenance of expected functionalities in the event of a failure of one of the devices). Taking into account this type of robustness allows you to reduce costs determined by the risk of failure [7].

The problem of searching for disruption-robust offers was first formulated in [6], where constraint programming techniques were used to solve it. Despite many advantages, these techniques are characterized by low computational efficiency. The current scale of problems solvable online is limited to thirteen customers and no more than eight types of devices. The principle of planning offers for a given customer group $\mathbb{C}$, which is the basis for the proposed approach, is illustrated in Figure 1.

It assumes that each of the feasible offers is verified in terms of whether it guarantees the expected degree of robustness. It is worth noting that the computational complexity of the problems of determining feasible solutions (constraints No. I–III) and assessing their robustness $R_u$ (constraint No. IV) approximate functions with an exponential course.

3.2. The Solution Space

An algebraic representation of the considered problem (concerning Formulas (1)–(4)) allows the formulation of properties allowing its simplification. Let $\Omega ={\mathbb{N}}^l$ ($l$—is the number of functionalities of the set $O$) denote the solution space whose elements ${\omega }_v\in \Omega$ are points with coordinates $(s_{v,1},\dots ,s_{v,j},\dots ,s_{v,l})$, i.e., ${\omega }_v=(s_{v,1},\dots ,s_{v,j},\dots ,s_{v,l})$. The coordinate $s_{v,j}\in \mathbb{N}$ of the point ${\omega }_v$ determines the number of functionalities $o_j$ made available to the customer as part of the presented offer.

Given is a non-empty set of vectors $\mathcal{K}=\{k_1,\dots ,k_i,\dots ,k_n\}$ where $k_i=[k_{i,1},{\dots ,k}_{i,j},\dots ,k_{i,l}]$ and $k_{i,j}\in \left\{\mathrm{0,1}\right\}$. For example, the set of vectors from the space in Figure 2a) takes the form $\mathcal{K}=\left\{k_1,k_2,k_3\right\}$, where $k_1=[0, 1]$, $k_2=\left[1, 1\right]$ and $k_2=\left[1, 0\right].$

The translation of the point ${\omega }_v\in \Omega$ by the vector $k_i$ is an operation resulting in the point ${\omega }_l\in \Omega$ with coordinates $s_{l,j}=s_{l,j}+k_{i,j}$. This type of action is denoted hereafter: ${\omega }_v\stackrel{k_i}{\to }{\omega }_l$. For example, the result of translating the point ${\omega }_v=(1,1)$ by the vector $k_1=\left[0,1\right]$ is the point ${\omega }_l=\left(1,2\right),$ i.e., $(1,1)\stackrel{k_1=\left[0,1\right]}{\to }(1,2)$.

The defined space $\Omega$ and the operations of translating ($\stackrel{k_i}{\to }$) the points of this space by the vectors of the set $\mathcal{K}$ constitute the algebraic structure: $\mathbb{O}=\left(\Omega ,\stackrel{k_i}{\to },\mathcal{K}\right)$, the graphical representation of which (for two dimensions) is shown in Figure 2a). The $\mathbb{O}$ structure enables to define the concept of a vector path, hereinafter named as stepping crawl thread (SCT). Let the sequence ${\pi }_u=\left(k_{u_1},\dots ,k_{u_r},k_{u_{r+1}},\dots ,k_{u_m}\right)$ define an SCTs built from the vectors of the set $\mathcal{K}$ (where $k_{u_r}\in \mathcal{K}$, $u_r\in \left\{1,\dots ,n\right\}$). The translation of the point $\underset{\_}{{\omega }_u}\in \Omega$ by the SCT ${\pi }_u$ is the result of successive translations of the point ${\omega }_u$ by the vectors making up this path, i.e., $\underset{\_}{{\omega }_u}\stackrel{k_u}{\to }\dots \stackrel{k_{u_r}}{\to }{\omega }_{i_r}\stackrel{k_{u_{r+1}}}{\to }...\stackrel{k_{u_m}}{\to }\overline{{\omega }_u}$. The points $\underset{\_}{{\omega }_u}$ and $\overline{{\omega }_u}$ (distinguished by the symbols “_”, “ $\overline{ i }$”) denote the starting and ending points of the stepping crawl thread ${\pi }_u$, respectively. This translation is further abbreviated as: $\underset{\_}{{\omega }_u}\stackrel{{\pi }_u}{\to }\overline{{\omega }_u}$. An example of 3 vector paths with the origin at point $(0,0)$ is illustrated in Figure 2b).

In the adopted representation, the elements (edges) of the SCT ${\pi }_u$ (with the beginning at the point $\underset{\_}{{\omega }_u}=(0,\dots ,0)$) represent the devices constituting the offer $X_u$ made available by the PaaS provider to the customer $C_u$. However, the coordinates of the endpoint $\overline{{\omega }_u}$ of such a thread determine the functionalities $o_j$ made available under a given offer $X_u$. The coordinates of the end point $\overline{{\omega }_u}$ of the thread ${\pi }_u=\left(k_{u_1},\dots ,k_{u_r},k_{u_{r+1}},\dots ,k_{u_m}\right)$ can be determined from the following relationship:

$$\overline{{\omega }_u}={\sum }_{r=1}^m{k}_{u_r}.$$

(5)

For example, SCT ${\pi }_1$ from Figure 2b takes the form: ${\pi }_1=\left(k_3,k_1,k_1,k_1,k_3,k_1\right)$ where $k_1=[1, 0]$, $k_3=[1, 1]$. According to (5), the end point is the point $\overline{{\omega }_1}=4\times k_1+2\times k_3=\left(\mathrm{6,2}\right)$ representing the functionalities made available to the customer as part of the offer $X_1$ presented by ${\pi }_1$—to the customer who will have 6 functionalities $o_1$ and 2 functionalities $o_2$.

3.2.1. Subspace of Feasible Solutions

Let us distinguish the $O{C}_u\subseteq \Omega$ subspace containing those solutions that meet the customer’s expectations (i.e., those for which constraint No. I is met—see Section 2.1):

$$O{C}_u=\left\{{\omega }_v\in \Omega :s_{v,1}\ge e{c}_{u,j},\dots ,s_{v,j}\ge e{c}_{u,j},\dots ,s_{v,l}\ge e{c}_{u,j}\right\}.$$

(6)

Therefore, each customer $C_u$ corresponds to a set of $O{C}_u$ points that meet his expectations, i.e., points with the coordinates defined by the expression (6). Figure 3 shows examples of spaces $O{C}_1$ (green field) and $O{C}_2$ (blue field) that correspond to the needs of customers from the example shown in Figure 1. Customer $C_1$ expects an offer that guarantees two functionalities ($o_1,o_2)$ in the number of eight and five ($E{C}_1=\left[8, 5\right]$), respectively, while the customer $C_2$—in the number eleven and three ($E{C}_2=\left[11, 3\right]$). Each point in these spaces defines the conditions that an offer acceptable to customers should meet.

In the presented approach, the problem of offer planning comes down to determining a set of the SCTs: $\Pi =\left\{{\pi }_1,{\pi }_2,\dots ,{\pi }_p\right\}$, ending at points in the $O{C}_u$ space, i.e., $\overline{{\omega }_1}\in O{C}_1$, $\overline{{\omega }_2}\in O{C}_2$, …, $\overline{{ \omega }_p}\in O{C}_p$. Example threads: ${\pi }_1=\left(k_3,k_1,k_1,k_3,k_1,k_2,k_1,k_1,k_2,k_2,k_3\right)$, ${\pi }_2=\left(k_3,k_1,k_1,k_1,k_1,k_1,k_1,k_3,k_1,k_1,k_1,k_2 \right)$, corresponding to the following offers, are shown in Figure 3:

• $X_1$ which consists of: five devices of type $k_1$ , three devices $k_2$, and three devices $k_3$,
• $X_2$, which consists of: nine devices of type $k_1$, one device $k_2$, and two devices $k_3$.

Of course, not every point of the $O{C}_u$ space can be reached. The number of vectors of the set $\mathcal{K}$ from which threads ${\pi }_u$ are generated is finite (determined by $z_i$). The subspace of achievable solutions $OA\subseteq \Omega$ therefore contains those points $\overline{{\omega }_v}$ that are reachable by the thread ${\pi }_v=\left(k_{v_1},\dots ,k_{v_r},k_{v_{r+1}},\dots ,k_{v_m}\right)$ generated from the vectors of the set (i.e., points for which constraint No. III is met—see Section 2.1):

$$OA=\left\{\overline{{\omega }_v}\in \Omega :(0,\dots ,0)\stackrel{{\pi }_v}{\to }\overline{{\omega }_v}; \forall k_i\in \mathcal{K},\mathcal{L}\left({\pi }_v,k_i\right)\le z_i\right\},$$

(7)

where $\mathcal{L}\left({\pi }_v,k_{\mathrm{i}}\right)$—a function that returns the number of occurrences of the vector $k_i$ in the sequence ${\pi }_v$.

Figure 4 shows the $OA$ space for the example from Figure 1. Each point of this space $\overline{{\omega }_v}\in OA$ represents an offer whose number of shared devices does not exceed the number of devices at the provider’s disposal: $z_1=15$, $z_2=5$, $z_3=10$.

It is easy to notice that this space is bounded by two threads: ${\pi }_{up}$, ${\pi }_{down }$ generated from all devices available from the provider:

• ${\pi }_{up}=\left(k_2,k_2,\dots ,k_2,k_3,k_3,\dots ,k_3,k_1,k_1,\dots ,k_1\right)$,
• ${\pi }_{down}=\left(k_1,k_1,\dots ,k_1,k_3,k_3,\dots ,k_3,k_2,k_2,\dots ,k_2\right)$.

We can then define the $O{F}_u$ space of feasible solutions, being the intersection of the $OA$ space of achievable solutions and the $O{C}_u$ space containing points meeting the customer’s expectations:

$$O{F}_u=OA\cap O{C}_u.$$

(8)

A corresponding example of space $O{F}_1$ (green field) and $O{F}_2$ (violet field) that correspond to the feasible solutions for customers from the example shown in Figure 1 is presented in Figure 5.

3.2.2. Subspace of Robust Solutions

Of course, searching for ${\pi }_u$ threads requires continuous verification of other constraints concerning the offer costs (constraint No. II) and assessment of the offer’s robustness (constraint No. IV). Of the above, the stage of assessing the offer’s robustness is the most computationally expensive. According to (4), this assessment requires an overview of all possible failure scenarios ($nsa$), the number of which, in general, increases exponentially.

The step of verifying the offer’s robustness assessment (carried out during the construction of the ${\pi }_u$ thread) can be removed by introducing a concept of the robust solution space $O{R}_u$. The $O{R}_u$ robust solution space contains those points of the $O{F}_u$ space which, in the event of a failure (malfunction of any device from the offer), still meet the expectations of the customer $C_u$. In general, failure of multiple $\alpha$ devices can be considered. The failure of $\alpha$ devices of type $k_i$ for the offer represented by the thread ${\pi }_u$ ending at point $\overline{{\omega }_u}$ can be interpreted as translations of this point by the vector $-\alpha \times k_i$ i.e., $\overline{{\omega }_u}\stackrel{{-\alpha \times k}_i}{\to }\overline{{\omega }_u^{\prime }}$. If after such a translation the point $\overline{{\omega }_u^{\prime }}$ is located in the area of feasible solutions (i.e., $\overline{{\omega }_u^{\prime }}\in O{F}_u$), then the offer is robust to a given failure scenario. Formally, the $O{R}_u$ space can be defined as follows:

$$O{R}_u=\left\{{\omega }_v\in O{F}_u:\forall k_i\in \mathcal{K};{\omega }_v\stackrel{{-\alpha \times k}_i}{\to }{\omega }_v^{\prime };{\omega }_v^{\prime }\in {OF}_u\right\}.$$

(9)

Considered robust solution space $O{R}_u$ contains those points ${\omega }_v$, reaching which (by thread ${\pi }_u$ representing the offer $X_u$) guarantees full robustness $(R_u=1$) of offer $X_u$. Examples of the robust solution space ${OR}_1$ (the solution space robust to the failure of one device $\alpha =1$) and ${OR}_2$ (the space of solutions robust to the failure of two devices $\alpha =2$) are illustrated in Figure 6.

Each point belonging to these spaces corresponds to offers that meet the expectations of customers $C_1$ and $C_2$ even in the event of failure of a given number of devices (i.e., one device in the case of customer $C_1$’s offers, two devices in the case of customer $C_2$’s offer). In other words, the spaces ${OR}_1$, ${OR}_2$ contain points reaching which guarantee full robustness of offers: $R_1=R_2=1$. An example of threads leading to such points is shown in Figure 6:

• ${\pi }_1=\left(k_3,k_1,k_1,k_3,k_1,k_2,k_1,k_1,k_2,k_3,k_3\right)$, and
• ${\pi }_2=\left(k_3,k_1,k_1,k_1,k_1,k_1,k_1,k_3,k_1,k_1,k_1,k_3,k_3,k_2\right)$.

These threads correspond to offers $X_1$ and $X_2$ which guarantee the fulfillment of the functionalities expected by customers: $E{C}_1=\left[8,5\right]$, $E{C}_2=\left[\mathrm{11,3}\right]$ even in the event of a failure of one (customer $C_1$) or two (customer $C_2$) of the offered devices.

To sum up, in the space $\Omega$ we can distinguish the following subspaces (see Figure 7):

• subspace $O{C}_u$ of expected solutions (6),
• subspace $OA$ of achievable solutions (7),
• subspace $O{F}_u$ of feasible solutions which is the intersection of $O{C}_u$ and $OA$ (8),
• subspace $O{R}_u$ of robust solutions which is included in the subspace $O{F}_u$ (9),

The introduced concepts allow us to develop a method for determining SCTs representing robust offers $\mathbb{X}$ guaranteeing the fulfillment of constraints No. I–IV (see Section 2). An example of such a method is presented in Section 4.

3.2.3. Problem Statement

Consequently, the thread ${\pi }_u$ obtained in the presented way guarantees robustness $R_u=1$. It is worth noting that the introduced representation allows replacing the process of searching for threads that require additional verification of the robustness of the presented offers by the process of searching in $O{R}_u$ for threads that guarantee specific reliability (in the case under consideration, $R_u=1$). Referring to the approach presented in Figure 1, this means that the robust verification stage (verification of constraint No. IV) has been removed from the process of searching for offers. In that context in proposed approach, the considered problem comes down to the following question: Is it possible in the $\Omega$ space to determine the SCTs $\Pi =\left\{{\pi }_1,\dots ,{\pi }_p\right\}$ leading to points guaranteeing a given level of robustness ($\overline{{\omega }_1}\in O{R}_1$, …, $\overline{{\omega }_p}\in O{R}_p$)?

It is worth adding that the points corresponding to solutions with robustness $R_u<1$ are contained in the space $O{P}_u=O{F}_u\backslash O{R}_u$ (see an example in Figure 2b). Determining offers that guarantee this type of robustness also comes down to determining the SCTs $\Pi =\left\{{\pi }_1,{\pi }_2,\dots ,{\pi }_p\right\}$ leading to the points of the $O{P}_u$ space (see the next Section).

4. Genetic Algorithm Driven Approach

The distinguishing feature of the developed genetic algorithm, whose structure corresponds to the conventionally accepted schemes [64,65], is the chromosome defined below.

Let ${\Pi }_u^{*}=\left\{{\pi }_u^1,{\pi }_u^2,\dots ,{\pi }_u^{l\left(u\right)}\right\}$ denote the set of feasible solutions (i.e., SCTs) for customer $C_u$ obtained when the expectations of other customers (set $\mathbb{C}\backslash \left\{C_u\right\}$) are ignored. In other words, when constructing the $C_u$ customer offer, the availability of all PaaS provider resources is assumed. The elements of the set ${\Pi }_u^{*}$ are determined using an algorithm based on the branch and bound method or a newly introduced linear programming method, both of which are explained in further subsections.

Chromosome $G$ has the form of a sequence of natural numbers $G=[g_1,\dots ,g_u,\dots ,g_p]$ where $g_u\in \left\{\mathrm{1,2},\dots ,l\left(u\right)\right\}$ and $l\left(u\right)=\left|{\Pi }_u^{*}\right|$ denotes the number of solutions allowed for customer $C_u$. The value of $g_u$ specifies the index of solution ${\pi }_u^{g_u}$ that was selected for customer $C_u$ from the set ${\Pi }_u^{*}$. Chromosome $G$ thus determines a set of offers (selected from the previously determined sets of feasible solutions ${\Pi }_u^{*}$) for all customers of set $\mathbb{C}.$ An example of chromosome $G=\left[\mathrm{1,4},2,\dots ,\mathrm{1,6},2\right]$ is shown in Figure 8.

The value $g_1=1$ means that the first possible solution of the form: ${\pi }_1^1=\left[k_1,k_1,k_2,k_1\right]$ was adopted for customer ${ C}_1$ (the set ${\Pi }_1^{*}$ contains 8 feasible solutions: ${\Pi }_1^{*}=\left\{{\pi }_1^1,{\pi }_1^2,\dots ,{\pi }_1^8\right\}$). Similarly, $g_p=2$ means that the second possible solution of the form: ${\pi }_p^2=\left[k_1,k_2,k_3\right]$ was adopted for customer $C_p$.

Objective function. It is required that the set of offers defined by the $G$ chromosome meets the limitations resulting from the finite number of devices at the PaaS provider’s disposal. Thus, the total number of devices of a given type cannot exceed the value determined by the sequence $Z=[z_1,\dots ,z_i,\dots ,z_n]$ (where $z_i\in \mathbb{N}$ means the number of devices of type $k_i$). This constraint is expressed by the following objective function:

$$f\left(G\right)={\sum }_{i=1}^n\max \left(z_i^{g_u},0\right),$$

(10)

$$z_i^{g_u}=\left({\sum }_{u=1}^p{x}_{u,i}^{g_u}\right)-z_i,$$

(11)

where $x_{u,i}^{g_u}$ determines the number of devices of type $k_i$ offered as part of the offer $X_u^{g_u}$ determined by the solution ${\pi }_u^{g_u}$. For example, the thread: ${\pi }_1^1=\left[k_1,k_1,k_2,k_1\right]$ from Figure 4, determines the offer of the form $X_1^1=\left[3, 1, 0\right]$ (3 devices of type $k_1$: $x_{\mathrm{1,1}}^1=3$; 1 device of type $k_2$: $x_{\mathrm{1,2}}^1=1$; 0 devices of type $k_3$: $x_{\mathrm{1,3}}^1=0$).

The objective function $f\left(G\right)$ defined in this way determines the number of excessive devices in the solution represented by the $G$ chromosome.

The developed algorithm searches for the minimum (equal to 0) value of the objective function $f\left(G\right).$ Determining a chromosome $G$ that guarantees such a value means that the offer does not exceed the number of devices at the PaaS provider’s disposal ($Z$ sequence). The developed algorithm has the following form (Algorithm 1):

Algorithm 1. PaaS-Offers-Genetic-Planning

$\mathrm{Generate} \mathrm{a} \mathrm{random} \mathrm{population} \mathbb{G}$. $\mathrm{Evaluate} \mathrm{each} \mathrm{individual} G\in \mathbb{G}$$\mathrm{according} \mathrm{to} \mathrm{the} \mathrm{objective} \mathrm{function} f\left(G\right)$ (10), $\mathrm{If} \mathrm{the} \mathrm{value} \mathrm{of} \mathrm{the} \mathrm{objective} \mathrm{function} f\left(G^{\mathrm{*}}\right)$$\mathrm{for} \mathrm{the} \mathrm{best} \mathrm{individual} G^{\mathrm{*}}$$\mathrm{is} \mathrm{equal} \mathrm{to} 0, \mathrm{terminate} \mathrm{the} \mathrm{algorithm}. \mathrm{Select} \mathrm{individual} G^{\mathrm{*}}$ as the solution to the problem. $\mathrm{Limit} \mathrm{the} \mathrm{population} \mathbb{G}$  $\mathrm{by} \mathrm{half} \mathrm{by} \mathrm{discarding} \mathrm{individuals} \mathrm{with} \mathrm{the} \mathrm{highest} \mathrm{value} \mathrm{of} \mathrm{the} \mathrm{objective} \mathrm{function} f\left(G\right)$. Crossover the individuals of the obtained population in pairs, obtaining two new individuals per pair. Crossover according to the rule: the first child inherits the first half of the chromosome of the first parent and the second half of the chromosome of the second parent; the second child inherits the other half. $\mathrm{Mutate} \mathrm{the} \mathrm{individuals} \mathrm{of} \mathrm{the} \mathrm{resulting} \mathrm{population}. \mathrm{The} \mathrm{mutation} \mathrm{involves} \mathrm{randomly} \mathrm{changing} \mathrm{the} \mathrm{value} g_u\in \left\{\mathrm{1,2},\dots ,l\left(u\right)\right\}$$\mathrm{of} \mathrm{an} \mathrm{element} \mathrm{of} \mathrm{the} \mathrm{chromosome} \mathrm{with} \mathrm{a} \mathrm{probability} \mathrm{of} pm$ (mutation rate). $\mathrm{If} \mathrm{the} \mathrm{number} \mathrm{of} \mathrm{generations} \mathrm{does} \mathrm{not} \mathrm{exceed} \mathrm{the} \mathrm{maximum} \mathrm{number} \mathrm{of} \mathrm{generations} mg$, $\mathrm{return} \mathrm{to} \mathrm{step} \mathrm{two}, \mathrm{otherwise} \mathrm{terminate} \mathrm{the} \mathrm{algorithm} \mathrm{and} \mathrm{select} \mathrm{the} \mathrm{best} \mathrm{individual} G^{\mathrm{*}}$ as the solution to the problem.

The structure of the algorithm emphasizes, among others: stages of crossbreeding and mutation of population individuals, and, above all, the most important stage of generating the initial population $\mathbb{G}$. Two interchangeable ways of determining the population $\mathbb{G}$ are presented in the Section below.

4.1. Generation of Initial Population $\mathbb{G}$

The effectiveness of the developed algorithm depends on the “quality” (i.e., convergence with the searched solution) of the elements constituting the initial population $\mathbb{G}$. It is assumed that the quality of the new elements (individuals) generated in the process of population crossover and mutation is determined by the quality of the initial population. In the adopted representation, the initial population $\mathbb{G}$ is defined as follows:

$$\mathbb{G}\subseteq \left\{\left[g_1,\dots ,g_u,\dots ,g_p\right]:g_u\in \left\{\mathrm{1,2},\dots ,l\left(u\right)\right\};l\left(u\right)=\left|{\Pi }_u^{\mathrm{*}}\right|\right\},$$

(12)

where ${\Pi }_u^{\mathrm{*}}=\left\{{\pi }_u^1,{\pi }_u^2,\dots ,{\pi }_u^h,\dots ,{\pi }_u^{l\left(u\right)}\right\}$—is the set of feasible threads for customer $C_u$.

The quality of the newly generated populations $\mathbb{G}$ depends on the appropriate selection of threads ${\pi }_u^h$ of the set ${\Pi }_u^{*}$ determined in accordance with one of two proposed approaches: Branch and Bound Approach and Linear Programming Approach, described below.

4.1.1. Branch and Bound Approach (BBA)

The proposed approach assumes that the threads ${\pi }_u^h$ of the set ${\Pi }_u^{*}$ are branches of the $T{R}_u$ tree rooted in the $\Omega$ space (point ${\omega }_u=$ (0, …, 0)) built from the $k_i$ vectors of the set $\mathcal{K}$. An example of such a tree is shown in Figure 9.

The Branch and Bound Approach (BBA) is used to construct a tree $T{R}_u$, implementing the following principle: a vertex (represented by an appropriate point ${\omega }_v$ of the $\Omega$ space) can be further expanded (i.e., it may have outgoing edges) if the following conditions are met:

(a)

the number of devices available to the supplier has not been exhausted, i.e., $\forall i\le n:x_{u,i}\le z_i$.

(b)

the customer’s budget has not been exceeded, i.e., $B_u\le E{B}_u$.

(c)

there are devices that improve the functionality of the offer $X_u$ (represented by branch of tree $T{R}_u$), i.e., $\exists i\le n \exists j\le l:\left(k_{i,j}=1\right)\wedge \left(s_{u,j}\le e{c}_{u,j}\right)$.

(d)

the vertex is not in the $O{R}_u$ space.

A vertex that cannot be expanded according to the above rules becomes a leaf of the tree $T{R}_u$.

The proposed approach assumes that the set ${\Pi }_u^{*}$ contains threads ${\pi }_u^h$ (branches) of $T{R}_u$ tree (what is hereinafter denoted: ${\pi }_u^h⊑T{R}_u$—branch ${\pi }_u^h$ is a part of a tree $T{R}_u$), which lead to vertices $\overline{{\omega }_u}$ from the space of feasible solutions $O{F}_u$:

$${\Pi }_u^{\mathrm{*}}=\left\{{\pi }_u^h⊑T{R}_u:\left(0,\dots ,0\right)\stackrel{{\pi }_u^h}{\to }\overline{{\omega }_u};\overline{{\omega }_u}\in O{F}_u\right\}.$$

(13)

Illustrations of branches belonging to the set ${\Pi }_u^{*}$ (highlighted in blue) on the $T{R}_u$ tree are shown in Figure 9. As you can easily see, all branches ${\pi }_1^1,\dots ,{\pi }_1^5$ end with leaves constituting the vertices of the $O{F}_u$ space. The idea of determining the set ${\Pi }_u^{*}$ by the tree $T{R}_u$ construction is expressed in the following algorithm (Algorithm 2):

Algorithm 2. Generating feasible solutions, Branch and Bound Approach (BBA)

Determine the parameters characterizing the provider $Z$  $(\mathrm{the} \mathrm{number} \mathrm{of} \mathrm{devices} \mathrm{he} \mathrm{offers}) \mathrm{and} \mathrm{the} \mathrm{customer}’\mathrm{s} \mathrm{expectations} E{C}_u$. Determine the spaces $O{F}_u$  $\mathrm{and} O{R}_u$. $\mathrm{Start} \mathrm{building} \mathrm{a} T{R}_u$ tree rooted at ${\omega }_v=\left(0,\dots ,0\right)\in \Omega$. If conditions (a)–(d) (described above) are met for point ${\omega }_v$ $, \mathrm{then} \mathrm{expand} \mathrm{the} \mathrm{corresponding} \mathrm{vertex} (\mathrm{i}.\mathrm{e}., \mathrm{add} \mathrm{new} \mathrm{edges} \mathrm{and} \mathrm{vertices} \mathrm{for} \mathrm{the} \mathrm{tree} T{R}_u$  $), \mathrm{else} \mathrm{vertex} {\omega }_v$ is a leaf of the tree (it does not have outgoing edges). $\mathrm{If} \mathrm{the} T{R}_u$  $\mathrm{tree} \mathrm{contains} \mathrm{an} \mathrm{unexpanded} \mathrm{vertex} {\omega }_v$ that is not a leaf, repeat step 4 for that vertex. Otherwise, go to step 6. $\mathrm{Branches} {\pi }_u^h$ of the tree $T{R}_u$  $(\mathrm{i}.\mathrm{e}., {\pi }_u^h⊑T{R}_u$) ending with leaves from the space $O{F}_u$ form the set ${\Pi }_u^{*}$ (13).

4.1.2. Linear Programming Approach (LPA)

In this approach, the linear programming method is used to determine the elements ${\pi }_u^h$ of the set ${\Pi }_u^{*}$ (determining the initial population $\mathbb{G}$ according to (11)). According to the adopted representation, a thread ${\pi }_u^h$ is feasible if the point $\overline{{\omega }_u^h}$, to which it leads, belongs to the $O{F}_u$ space: $\overline{{\omega }_u^h}\in O{F}_u$. From the description presented in Section 3, it follows that the $O{F}_u$ space is limited by a convex hyperpolyhedron—see Figure 5.

To simplify the calculations, let us consider a hypercube $H{C}_u$ inscribed in this space i.e., $H{C}_u\subseteq O{F}_u$. Figure 10 shows examples of different hypercubes for the space of Figure 5 (taking the shape of squares in two-d space). Each of them corresponds to a different size (length of the edge of the square): $h{r}_u^{‴}=1$, $h{r}_u^{″}=4$, $h{r}_u^{\prime }=8$. In general, the size $h{r}_u$ of hypercube $H{C}_u$ can take the following values: $h{r}_u\in \{1,\dots ,HM\}$ (where $HM$ is the size of the largest hypercube $H{C}_u$ inscribed in the $O{F}_u$ space).

In the approach considered, it is assumed that the threads ${\pi }_u^h$ constituting the set ${\Pi }_u^{*}$ are SCTs leading to the space $H{C}_u$—see Figure 11. Due to the shape of the space taking the form of a hypercube, determining these threads can be represented as solving an appropriate linear programming problem. In this approach, the set ${\Pi }_u^{*}$ takes the form:

$${\Pi }_u^{\mathrm{*}}=\left\{{\pi }_u^h:\forall k_{\mathrm{i}}\in \mathcal{K},\mathcal{L}\left({\pi }_u^h,k_{\mathrm{i}}\right)=x_{u,i}\right\},$$

(14)

$$x_{u,i}\times k_{i,j}\ge e{c}_{u,j}\mathrm{for} i=1,\dots ,n\mathrm{and} j=1,\dots ,l,$$

(15)

$$x_{u,i}\times k_{i,j}\le e{c}_{u,j}+{hr}_u\mathrm{for} i=1,\dots ,n\mathrm{and} j=1,\dots ,l,$$

(16)

$$x_{u,i}\le z_i\mathrm{for} i=1,\dots ,n,$$

(17)

where $\mathcal{L}\left({\pi }_u^h,k_{\mathrm{i}}\right)$—a function that returns the number of occurrences of the vector $k_i$ in the sequence ${\pi }_u^h$.

In the proposed approach, inequalities (15)–(17) constitute constraints of the linear model, the solution of which, in the form of variables $x_{u,i}$ (for $i=1,\dots ,n$ and $j=1,\dots ,l$) represents a feasible offer of customer $C_u$. The variables $x_{u,i}$ determine the (14) threads ${\pi }_u^h$ leading to the space $H{C}_u$—as shown in Figure 11.

The advantage of the proposed approach is the ability to reduce the problem of determining feasible threads ${\pi }_u^h$ to a linear programming problem, which can be solved using existing approaches [66,67]. Of course, the set ${\Pi }_u^{*}$ of threads determined in this way is limited only to solutions of the $H{C}_u$ space (of a given size $h{r}_u$), which is a subspace of $O{F}_u$, which means that some of the feasible solutions may be omitted.

The idea of the proposed approach is expressed in the following algorithm (Algorithm 3):

Algorithm 3. Generating feasible solutions, Linear Programming Approach (LPA)

$\mathrm{Determine} \mathrm{the} \mathrm{parameters} \mathrm{characterizing} \mathrm{the} \mathrm{provider} (\mathrm{i}.\mathrm{e}., \mathrm{the} \mathrm{number} \mathrm{of} \mathrm{devices} \mathrm{offered}) \mathrm{and} \mathrm{the} \mathrm{customer}’\mathrm{s} \mathrm{expectations} E{C}_u$. Specify the size of space $H{C}_u$  $: h{r}_u\in \{1,\dots ,HM\}$. Solve a linear programming problem with constraints (15)–(17). If the solution does not exist, i.e., $X_u=\varnothing$  $\mathrm{and} h{r}_u<HM$  $, \mathrm{then} h{r}_u :=h{r}_u+1$ and return to step three, else go to step five. Based on the obtained result $X_u$, determine the set ${\Pi }_u^{*}$ (14) (in case of $X_u=\varnothing$  $\mathrm{and} h{r}_u=HM,$  $\mathrm{set} {\Pi }_u^{*}=\varnothing$).

5. Computational Experiments

The approaches presented in Section 3 and Section 4 were verified on real data collected from a PaaS provider (PP), the description of which, due to its sensitive nature, requires confidentiality. The offered collection distinguishes five types of multifunctional devices (i.e., photocopiers) in various configurations, such as A3 printing, stapling, duplex, and Wi-Fi connectivity. The rental prices of individual types of devices are known, as well as the functionality expectations and budget constraints characterizing the order expectations of each of the twenty customers.

The aim of the experiments is to evaluate alternative approaches to BBA, and LPA described in Section 4.1 and Section 4.1.2, allowing for comparison of generated device rental offers offered by PP to a group of customers with specific capabilities and expectations. An equally important element of this verification is also related to the assessment of time expenditure incurred on solutions in each of these approaches.

5.1. Qualitative Experiments

The experiment used data from PP, which has five types of devices $K=\left\{k_1,\dots ,k_5\right\}$ equipped with ten functionalities $O=\left\{o_1,\dots ,o_{10}\right\}$ (see

Table 1. Matrix of functionalities of each device.

	${\mathit{O}}_{\mathit{i}}$	${\mathit{o}}_1$	${\mathit{o}}_2$	${\mathit{o}}_3$	${\mathit{o}}_4$	${\mathit{o}}_5$	${\mathit{o}}_6$	${\mathit{o}}_7$	${\mathit{o}}_8$	${\mathit{o}}_9$	${\mathit{o}}_{10}$
${\mathit{K}}_{\mathit{i}}$
$k_1$		0	1	1	0	0	1	1	1	0	0
$k_2$		1	1	0	0	1	1	0	0	0	1
$k_3$		1	0	1	1	1	0	0	1	0	1
$k_4$		0	1	1	1	0	0	1	0	1	0
$k_5$		1	0	0	0	1	1	1	1	1	1

). PP has the following number of devices of particular types: $Z=\left[65, 68, 68, 61, 65\right]$ (in pieces) and the unit rental prices of each of them: $Q=[20, 15, 15, 10, 20]$ (in EURO).

The provider considers applications from 20 customers specifying their rental expectations by the number of devices ordered and the types of functionalities provided by them (see

Table 2. Matrix of the customers’ ($C_1-C_{20}$) expectations ($o{c}_{u,l}$).

	${\mathit{C}}_{\mathit{u}}$	${\mathit{C}}_1$	${\mathit{C}}_2$	${\mathit{C}}_3$	${\mathit{C}}_4$	${\mathit{C}}_5$	${\mathit{C}}_6$	${\mathit{C}}_7$	${\mathit{C}}_8$	${\mathit{C}}_9$	${\mathit{C}}_{10}$	${\mathit{C}}_{11}$	${\mathit{C}}_{12}$	${\mathit{C}}_{13}$	${\mathit{C}}_{14}$	${\mathit{C}}_{15}$	${\mathit{C}}_{16}$	${\mathit{C}}_{17}$	${\mathit{C}}_{18}$	${\mathit{C}}_{19}$	${\mathit{C}}_{{\displaystyle 20}}$
${\mathit{O}}_{\mathit{i}}$
$o_1$		7	0	3	10	7	0	0	7	3	0	10	0	0	0	10	0	0	7	0	3
$o_2$		0	3	0	0	3	10	0	10	0	3	3	0	14	7	7	0	3	0	3	0
$o_3$		0	3	3	10	0	3	0	0	10	3	0	0	0	0	3	0	10	7	0	0
$o_4$		3	3	0	7	0	0	0	0	0	10	0	7	0	7	0	0	0	0	0	10
$o_5$		0	7	0	3	0	7	0	0	0	3	0	7	3	0	0	10	0	0	10	0
$o_6$		7	0	7	3	0	7	0	3	7	0	0	14	3	0	0	7	0	3	0	0
$o_7$		10	0	3	0	0	7	14	3	0	3	7	0	7	0	0	3	3	10	0	0
$o_8$		0	0	7	3	7	0	10	3	0	0	7	3	0	0	0	0	3	0	14	7
$o_9$		3	0	3	3	3	0	3	3	0	7	0	10	0	0	7	0	0	0	0	7
$o_{10}$		0	0	0	10	0	3	14	3	7	0	0	0	3	0	14	0	0	7	0	3

). For example, customer $C_1$ expects that the rented devices will have seven functionalities $o_1$, four functionalities $o_4$, seven functionalities $o_6$, ten functionalities $o_7$ and three functionalities $o_9$.

Each customer has a specific budget and expects a given minimum robustness from the rented equipment (

Table 3. Customers’ ($C_u$) budget ${EB}_u$ and robustness limitations $E{R}_u$.

	Customers
	${\mathit{C}}_1$	${\mathit{C}}_2$	${\mathit{C}}_3$	${\mathit{C}}_4$	${\mathit{C}}_5$	${\mathit{C}}_6$	${\mathit{C}}_7$	${\mathit{C}}_8$	${\mathit{C}}_9$	${\mathit{C}}_{10}$	${\mathit{C}}_{11}$	${\mathit{C}}_{12}$	${\mathit{C}}_{13}$	${\mathit{C}}_{14}$	${\mathit{C}}_{15}$	${\mathit{C}}_{16}$	${\mathit{C}}_{17}$	${\mathit{C}}_{18}$	${\mathit{C}}_{19}$	${\mathit{C}}_{20}$
${EB}_u$	630	525	875	1225	875	875	700	700	875	700	875	700	875	875	980	875	1015	1050	1225	945
$E{R}_u$ (%)	25	50	50	75	50	50	25	50	75	25	50	25	50	50	50	50	25	25	75	50

). For example, customer $C_1$ expects that all rented equipment will cost him at most ${EB}_1=630$ euros and will have robustness $E{R}_1=25\%$, customer $C_2$ expects that all rented equipment will cost at most ${EB}_2=525$ euros and will have robustness $E{R}_2=50\%$, etc.

The proposed algorithm was run with the following parameters: population size $\left|\mathbb{G}\right|=1000$, maximum number of generations $mg=1000$, mutation rate $pm=0.02$. The algorithm was implemented in C++ with the Google OR-Tools library, on an Apple M1 3,2 GHz, 16 GB RAM.

Two solutions were obtained in the form of two alternative offers that meet the requirements of the ordering parties. The first solution (let us call it offer A) presented in

Table 4. Set of offers $X_u$ for customers $\mathbb{C}=\left\{C_1,\dots ,C_{20}\right\}$ obtained by the BBA (offer A).

		Offer A
		${\mathit{X}}_1$	${\mathit{X}}_2$	${\mathit{X}}_3$	${\mathit{X}}_4$	${\mathit{X}}_5$	${\mathit{X}}_6$	${\mathit{X}}_7$	${\mathit{X}}_8$	${\mathit{X}}_9$	${\mathit{X}}_{10}$	${\mathit{X}}_{11}$	${\mathit{X}}_{12}$	${\mathit{X}}_{13}$	${\mathit{X}}_{14}$	${\mathit{X}}_{15}$	${\mathit{X}}_{16}$	${\mathit{X}}_{17}$	${\mathit{X}}_{18}$	${\mathit{X}}_{19}$	${\mathit{X}}_{20}$
Device assignment $X_u$	$k_1$	6	0	0	2	3	7	3	0	4	0	8	5	9	0	1	2	8	1	3	3
	$k_2$	8	3	3	0	4	5	5	5	4	2	4	3	6	1	1	9	3	0	0	0
	$k_3$	0	5	7	6	3	3	0	1	5	2	5	0	0	1	5	1	1	4	7	9
	$k_4$	4	0	0	3	3	0	0	6	5	8	4	8	0	7	5	0	2	3	2	1
	$k_5$	0	0	4	7	1	0	11	2	0	2	1	6	2	1	9	1	0	6	5	7
Offer price $B_u$		280	120	230	300	215	260	355	190	265	180	355	345	310	120	340	210	240	230	285	345
Offer $R_u$ (%)		44	62	50	100	50	53	26	79	100	29	55	36	100	100	67	77	100	29	100	50

, generated using the BBA algorithm (Seciton 4.1.1), took 173 s to generate, while the alternative (let us call it offer B), see

Table 5. Set of offers $X_u$ for customers $\mathbb{C}=\left\{C_1,\dots ,C_{20}\right\}$ obtained by the LPA (offer B).

		Offer B
		${\mathit{X}}_1$	${\mathit{X}}_2$	${\mathit{X}}_3$	${\mathit{X}}_4$	${\mathit{X}}_5$	${\mathit{X}}_6$	${\mathit{X}}_7$	${\mathit{X}}_8$	${\mathit{X}}_9$	${\mathit{X}}_{10}$	${\mathit{X}}_{11}$	${\mathit{X}}_{12}$	${\mathit{X}}_{13}$	${\mathit{X}}_{14}$	${\mathit{X}}_{15}$	${\mathit{X}}_{16}$	${\mathit{X}}_{17}$	${\mathit{X}}_{18}$	${\mathit{X}}_{19}$	${\mathit{X}}_{20}$
Device assignment $X_u$	$k_1$	2	1	8	0	2	3	3	3	8	0	1	5	5	6	0	1	9	3	5	0
	$k_2$	2	7	0	3	3	5	1	7	0	0	2	1	6	0	5	6	7	2	4	0
	$k_3$	0	0	3	7	3	1	4	1	7	6	4	5	0	3	5	3	0	4	8	4
	$k_4$	4	4	3	4	4	3	1	4	0	4	1	3	4	4	3	0	1	5	1	7
	$k_5$	5	3	1	1	2	2	10	0	1	6	8	8	0	2	5	2	0	2	2	4
Offer price $B_u$		210	225	255	210	210	220	345	220	285	250	280	380	230	245	280	195	295	240	330	210
Offer $R_u$ (%)		46	100	100	100	50	100	26	100	100	38	100	36	100	53	100	75	41	38	100	100

, was generated using the LPA algorithm (Seciton 4.1.2) in 47 s.

In addition to the visible gain in problem-solving time in favor of the LPA algorithm, a difference can be observed in the number of devices assigned to specific customers, which translates into the cost of the offer for the customer/revenue for the provider and the robustness of the ordered equipment.

To sum up, it can be concluded that the relatively small increase in the provider’s revenue provided by offer A (5175 euro compared to 5115 euro obtained in offer B) is not balanced by the loss of robustness (replacement of rented equipment) from the summary level of $R=1503$ in offer B to the summary level $R=1307$ in offer A. This means that offers obtained using the LPA algorithm are, in general, more favorable for the customer (higher robustness of the rented equipment) at the expense of a slight loss of revenue for the provider.

It is worth adding that in offer A, the provider rents all units of equipment $k_1$, $k_4$, and $k_5$, and is left with only two units of equipment $k_2$ and three units of equipment $k_3$. In turn, the allocation from offer B results in the rental of all units of equipment $k_1$ and $k_3$, and seven units of equipment $k_2$ and one unit each of $k_4$ and $k_5$ remain at disposal. This means that the supplier providing offer B will have an additional, larger amount of equipment that could be rented, resulting in additional revenue. This fact once again confirms the competitiveness of the newly developed LPA algorithm.

5.2. Quantitative Experiments

In addition to the qualitative experiments described in Section 5.1, which involve a case study demonstrating the application of the developed model, quantitative experiments were also conducted to evaluate the scale of problems addressed by both proposed approaches.

The problem presented in the previous section constitutes a reference instance (hereinafter referred to as $A^0$) for the instances $A^1, \dots , A^q,\dots ,A^Q$ used in the quantitative experiments that follow. Let $s^q\in {\mathbb{R}}^{+}$ denote the scale of the problem understood as the proportionality coefficient between the parameters of the generated instance $A^q$ and the reference instance $A^0$. The parameters subject to scaling are the number of provider devices $Z$, the expected functionalities of customers $O{C}_u$ and their budget $E{B}_u$. It is assumed that the scaled $A^q$ instance is described by the following parameter values (where the superscript ($q$) specifies the parameters of the $A^q$ instance and the index ($0$) specifies the parameters of the $A^0$ instance):

$$Z^{\left(q\right)}=Z^{\left(0\right)}\times s^q,$$

(18)

$$E{C}_u^{\left(q\right)}=E{C}^{\left(0\right)}\times s^q,$$

(19)

$$E{B}_u^{\left(q\right)}=E{B}^{\left(0\right)}\times s^q.$$

(20)

The remaining parameters of the problem instance $A^q$ remain unchanged.

The experiments were carried out for $Q=20$ instances (scale $s^q=0.1,0.2,\dots ,2.0$), the aim of which was to determine offers that meet customer expectations. For this purpose, the developed algorithm in the LPA and BBA variants was used (see Section 4). It is worth noting that the time needed to solve a problem instance is determined by the first stage of the algorithm (generation of an initial population $\mathbb{G}$—see Section 4.1), in which sets ${\Pi }_u^{*}$ of feasible solutions (threads ${\pi }_u^h$) are determined for each customer. Due to the above, the quantitative experiments conducted focused on the assessment of this stage (i.e., determining the set ${\Pi }_u^{*}$).

The experiments distinguished three groups dedicated to answering the following questions:

• At what time is it possible to determine the solution to the problem for the given instances: $A^1, \dots , A^q,\dots ,A^Q$ using both variants of the algorithm: LPA and BBA?
• What is the minimum size $h{r}_u$ of hypercube $H{C}_u$ (LPA algorithm) that guarantees solving a problem of a given scale $s$?
• What is the time to obtain a solution to the problem with the LPA variant for a given scale s, for different sizes $h{r}_u$ of hypercube $H{C}_u$?

The calculations were performed in the environment described in Section 5.1 assuming the population size $\left|\mathbb{G}\right|=1000$, maximum number of generations $mg=1000$, mutation rate $pm=0.02$. The developed genetic algorithm was implemented in C++ with the Google OR-Tools library and ran on an Apple M1 3.2 GHz processor, with 16 GB RAM.

Ad. I. The calculation times of generating a solution to the problem in the proposed two approaches were compared. The results for various instances of the scale $s=0.1,0.2,\dots ,2.0$ are presented in

Table 6. Calculation times of the scale of problem instances for the considered algorithms.

Scale	Number of Devices	Calculation Time [s]
		BBA	$\mathbf{LPA} {\mathit{h}\mathit{r}}_{\mathit{u}}=25$	$\mathbf{LPA} \mathit{h}{\mathit{r}}_{\mathit{u}}=30$
0.1	30	0.001	1.4	1.4
0.2	64	0.007	17.5	19.6
0.3	96	0.032	36.6	48.8
0.4	130	0.084	60.0	92.6
0.5	162	0.424	69.3	108.4
0.6	194	3.14	77.4	129.3
0.7	226	10.0	89.5	154.4
0.8	258	30.6	95.9	175.1
0.9	292	49.29	101.7	192.6
1.0	322	178.0	102.2	192.4
1.1	357	548.0	107.6	219.9
1.2	391	>600	110.0	230.6
1.3	423	>600	110.1	233.5
1.4	457	>600	110.2	233.7
1.5	489	>600	106.1	238.0
1.6	521	>600	104.2	234.6
1.7	553	>600	105.2	246.9
1.8	587	>600	99.9	232.1
1.9	619	>600	90.4	227.1
2.0	654	>600	85.6	227.1

and Figure 12. For the LPA, two sample values of the size of hypercube $H{C}_u$ were adopted: $H{C}_u$: ${hr}_u=25$ and $h{r}_u=30$. It is easy to notice that for small scales ($s\le 0.5$) the BBA allows solving the problem in a shorter time (even less than a second) compared to the LPA, while for the scale $s>0.9$ the LPA solves the same problem faster. It is worth noting that the solution time obtained as a result of using the BBA increases very quickly as the scale of the problem increases, while for the LPA the solution time for most of the tested scale values remains at a similar level.

Ad. II. The significant advantage of the LPA algorithm (especially for “large” scales of problem instances) meant that further experiments focused only on assessing the impact of the parameters of this algorithm. First, the influence of the size value $h{r}_u$ of hypercube $H{C}_u$ on the possibility of obtaining a feasible solution, i.e., ${\Pi }_u^{*}\ne \varnothing$ was examined. In other words, an attempt was made to assess the minimum size $h{r}_u$ of hypercube $H{C}_u$ for which there is a solution to a problem with scale $s$. The results obtained are illustrated in Figure 13. It can be seen that the minimum value of $h{r}_u$ increases linearly with the scale $s$. It is evident that selecting a value of $h{r}_u$ that is too low for a given scale $s$ leads to the absence of an acceptable solution. The experiments conducted indicate that this value should not fall below the trend line represented in the data from Figure 13:

$$h{r}_u\ge 13.97\times s+0.53.$$

(21)

The above relationship determines the lower limit of the $h{r}_u$ parameter, beyond which the LPA algorithm does not return to a feasible solution for the considered instances.

It is worth noting that the possibility of automatically generating the value of this parameter, i.e., selecting it depending on the given scale of the problem, raises a promising topic for future research.

Ad. III. In subsequent experiments, it was checked how the calculation time changes depending on the value of $h{r}_u$ with a constant problem scale $s=1$. The results emphasizing its non-linear dependence on the hypercube’s size are shown in Figure 14. The observed effect results from the fact that as the $h{r}_u$ value increases, the number of points belonging to hypercube $H{C}_u$ increases exponentially.

The rapid increase in computation time associated with a linear increase in scale $s$ significantly constrains the value of $h{r}_u$. For instance, if we assume that the time required to determine a solution does not exceed 10 min, this condition restricts $h{r}_u$ to values less than 40.

The results of quantitative experiments showed the advantage of the LPA algorithm. For example, for the scale $s=1$, the time to obtain the response of this algorithm was three times smaller than in the BBA algorithm (see Table 6). However, the effectiveness of the LPA algorithm depends on the appropriate selection of the $h{r}_u$ value—if it is too small, the algorithm will not find feasible solutions. On the other hand, if the parameter value is too large, the time to solve the problem instance will be greater than acceptable, e.g., in online systems.

The resulting scalability of the proposed approach, determined by the minimum value of $h{r}_u$ for a given scale $s$ (Figure 13), and the time of determining the set ${\Pi }_u^{*}$ of solutions allowed for a given value of $h{r}_u$ (Figure 14), is illustrated in Figure 15. It can be seen that its implementation in online mode is limited to problems of scale $s\le 2.7$. This means that the presented approach is applicable in situations where the number of devices presented in offers does not exceed 450.

To summarize, previous research [14,52] examining the potential of both declarative programming environments and population algorithms has demonstrated the feasibility of addressing these problems at a scale of $s=0.3$ (where the number of devices does not exceed 100). In comparison, the approach implemented in the LPA, which operates at a problem scale of $s\le 2.7$ (as shown in Figure 15), is more time-efficient than the existing solutions for planning multi-functional equipment leasing offers within the PaaS model.

6. Conclusions

Addressing the issue of preventive planning for PaaS, this work proposes a model enabling the search for resource allocation that meets the risk level expected by the customer while enabling the implementation of dedicated computer-aided supporting decision-making. The developed model implements the authors’ concept of stepping crawl threads, which allows, step by step, to generate variants of allocation of sets of leased devices with parameters that meet the expectations of the customers ordering them.

The case study has demonstrated the practical implementation of the suggested approach in a scenario with twenty customers and five device types with ten functionalities. The findings of this research are applicable in decision support systems for preventive planning of leasing offers while focusing on mitigating customer risks associated with accepting equipment providers’ offers. The scalability of the obtained solution is many times higher than previously obtained results. The proposed approach based on the linear programming method (LPA) allows to increase the scale of previously solved problems (using the BBA method) from 100 to 450 offered devices. That means it provides for taking up challenges posed by problems of a size encountered in practice.

However, high computational efficiency comes at the cost of the obtained solution quality. The obtained solutions often require the PaaS provider to have additional resources (not previously available), even if it is not necessary in reality. Moreover, the developed model does not consider uncertain data related to the fault and servicing of the offered resources. Therefore, future work involves extending the model to include activities related to servicing rented equipment and including cases related to work time uncertainty, while meeting expectations related to minimizing the total cost of maintaining the serviced equipment. Its significant extension should include cases related to the uncertainty of service teams’ working time as well as costs and risks expressed in fuzzy numbers.

The proposed model is distinguished by its open and flexible architecture, which facilitates the seamless incorporation of additional constraints to address the specific requirements of an offer or a particular customer. This adaptability ensures that any extensions or modifications involve merely augmenting the existing set of constraints, without adversely affecting the computational efficiency of the solution. Such a design is particularly advantageous in dynamic and rapidly evolving application contexts, where both PaaS providers and their customers must navigate an environment shaped by shifting operational guidelines, competitive dynamics, and regulatory changes. The model’s inherent flexibility and responsiveness enable it to maintain relevance and effectiveness in the fluid landscape of the leasing industry.

Future research will focus on the development of methodologies for identifying and analyzing factors that influence the balance between supply and demand in PaaS-driven markets. A key area of investigation will center on the provider’s perspective, specifically the trade-offs between the costs associated with equipment procurement by the primary PaaS provider and the expenses incurred for maintenance services outsourced to third-party vendors. By extending the model to capture trade-offs from both supply- and demand-side perspectives, this research aims to provide a comprehensive framework for understanding the dynamic interactions that underpin equilibrium in service-oriented industries, ultimately enhancing the ability to manage and sustain balance within the PaaS market.