Buffer Allocation via Bottleneck-Based Variable Neighborhood Search

Abstract

This study addresses the challenging problem of efficient buffer allocation in production lines. Suitable locations for buffer allocation are determined to satisfy the desired throughput, while a suitable balance between solution quality and computation time is achieved. A throughput calculation approach that yields the state probability of production lines is adopted to evaluate the effectiveness of candidate buffer allocation solutions. To generate candidate buffer allocation solutions, an active probability index based on state probability is proposed to rapidly detect suitable locations of buffer allocations. A variable neighborhood search algorithm is used to maintain acceptable solution quality; an additional neighborhood structure is used in the case where no satisfactory solution is generated in the initial neighborhood structure. Extensive numerical experiments demonstrate the efficacy of the proposed approach. The proposed approach can facilitate agile design of production lines in industry by rapidly estimating production line topologies.

1. Introduction

A production line consists of materials, storage area, and working area. Materials enter the production line, move between the storage area and the working area, and finally leave the production line. In queueing theory, materials are referred to as jobs, working areas as servers, and storage areas as buffers. Buffers are extremely important to compensate for variations and to ensure smooth operation of the servers. Excessive buffers increase costs and system redundancy while insufficient buffers lead to blocking in the production. Therefore, ensuring a suitable buffer allocation is important in a production line.

Agile manufacturing [1], which aims to respond rapidly to customer and market requirements, is widely adopted in industry. Agile design [1], which facilitates agile manufacturing, has attracted considerable attention from researchers and engineers. In agile design, buffers need to be efficiently allocated to predict production line design for meeting design requirements. The potential success and value of the design can then be evaluated within a short computation time. Therefore, it is necessary to achieve a good balance between solution quality and computation time for various kinds of production line topologies. Numerous studies have focused on the buffer allocation problem in production lines [2,3,4,5]. Buffer allocation methodologies can be generally categorized into enumeration, dynamic programming, metaheuristic methods, and search methods [5,6].

Enumeration is a method that employs all feasible buffer configurations to guarantee the optimality of the solution [7]. Although previous study [8] proposed the enumeration method to design buffers for the complete solution space, this method is limited to production lines with a small-scale topology because of its combinatorial complexity and time consumption. Although “small-scale” is relative and depends on the problem, the method is usually applicable to production line topologies with less than 20 machines.

Dynamic programming solves the buffer problem in a highly intuitive manner based on a non-closed-form objective function [9]. Diamantidis and Papadopoulos [10] used dynamic programming to address the problem of buffer allocation in serial production lines. Sadr and Malhamé [11] proposed a dynamic programming-based algorithm to design the buffer size in partially homogeneous unreliable transfer lines. Both methods are only applicable to limited production line topologies with a small number of machines. In summary, dynamic programming is usually applicable to production lines with a small-scale topology because the number of solution stages and states increases exponentially with the number of buffers and servers in the production line, which leads to an extremely long computation time.

Metaheuristic methods are high-level techniques that generate sufficiently good solutions for the buffer allocation problem. Yelkenci, Kose and Kilincci [12] proposed a hybrid evolutionary algorithm-based simulation optimization approach to decide the near optimal size of each buffer storage in open serial production lines. Costa et al. [13] combined a novel parallel tabu search algorithm with a neighborhood generation mechanism to determine a suitable buffer size for a serial production line. Beşikçi et al. [14] proposed a decision support system (DSS) employing an artificial neural network-based prediction model to determine the buffer allocation. Lin and Chiu [15] solved the stochastic resource allocation problem by combining hybrid particle swarm optimization with optimal budget computing allocation. These methods can obtain buffer allocation solutions with high solution quality. However, the main disadvantage of these methods is that one method is sufficiently effective only for the design of limited production line topologies. Moreover, the computation time of some metaheuristic methods depends on the initial buffer allocation solution, which may also lead to unstable solution quality.

Search methods select suitable locations to allocate buffers using some guide information. Their main disadvantage is that it is extremely difficult to achieve a balance between solution quality and computation time for different production line topologies. Some previous studies [16,17,18,19,20] achieved buffer allocation based on search methods. Specific parameters are used to rapidly determine suitable locations for buffer allocation. However, these methods are applicable to limited production line topologies such as serial topologies. Other studies [5,6] focused on various production line topologies and proposed buffer allocation approaches with effective guide information to allocate buffers. However, the computation time needs to be further decreased under the constraint of solution quality requirements if such approaches are to be used for efficient buffer allocation.

Although previous studies achieved buffer allocation with high solution quality, a long computation time is usually required to achieve the high solution quality, which does not meet computation time requirements of efficient buffer allocation. Hence, there is a need for a buffer allocation approach that can rapidly allocate buffers to the production line with acceptable solution quality. The objective of this study is to develop an efficient buffer allocation approach that achieves a good balance between solution quality and computation time. The solution quality of the buffer allocation should be higher than previous methods in available computation time. Furthermore, from the perspective of industry practical application, the proposed approach can be applied to a production line with 50 buffers and servers, which can be regarded as a large-scale production line; the available computation time of buffer allocation for this production line typically lies within 8 h.

In the study, a throughput calculation approach that can yield the state probability of a production line is adopted to evaluate the effectiveness of candidate buffer allocation solutions efficiently. The bottleneck-based variable neighborhood search algorithm is proposed to generate the candidate buffer allocation solutions efficiently. Based on state probability, the active probability index as a bottleneck indicator is proposed to search suitable buffer updating locations, which facilitates efficient buffer allocation by decreasing invalid buffer allocation attempts. Moreover, the variable neighborhood search algorithm is used to maintain acceptable solution quality using a proper additional neighborhood structure in the case no satisfactory solution is generated in the initial neighborhood structure. Finally, numerical examples are provided to evaluate the effectiveness of the proposed approach for a production line with a different topology and topology scale.

The remainder of this article is organized as follows. Section 2 presents the problem statement. The solution methodology is described in Section 3. Section 4 provides numerical examples to verify the effectiveness of the proposed solution methodology. The article ends with some conclusions and the scope for future work, in Section 5.

2. Problem Statement

In this study, the following assumptions are considered for production lines:

• Jobs enter a server or buffer in a production line at an external arrival rate according to a Poisson process that is widely used in the analysis of production lines [21].
• Jobs leave a server or buffer at a service rate with an exponential distribution that is widely used in the analysis of production lines [21].
• Both servers and buffers in a production line have their own service rates by which the working rate of the servers and buffers can be described.
• The capacities of the server and the buffer are set as “1” to simplify modelling; note that the capacity can be set as any value without affecting the effectiveness of the proposed approach. If the capacity of a server or a buffer is one, it implies that a server or buffer can deal with or contain only one job at a time.
• Although both blocking mechanisms—blocking before service and blocking after services—can be applied to the proposed approach to schedule job movement when blocking occurs in production lines [21], in the study, the former is adopted.
• Designed buffers that are allocated by the proposed approach have service rates that are equal to the highest service rate in an initial production line.

In [22], the goal of the dual buffer allocation problem is to maximize throughput of a production line subject to total designed buffer size.

In this study, computation time is also considered, and therefore, the efficient buffer allocation problem in this study is to find a buffer configuration vector for a production line to maximize throughput subject to available computation time and total designed buffer size decided by the available computation time. The problem can be described as

$$\mathrm{Find} B_{sol}= \left(b_{h,i},\cdots \right)$$

(1)

$$\mathrm{maximize} T_{sol}$$

(2)

$$\mathrm{subject} \mathrm{to} t_{sol}\le t_{available},$$

(3)

$$N_{sol}\le N_{max}$$

(4)

where $B_{sol}$ represents the buffer configuration vector which is the combination of designed buffer size in the solution,$i$ represents a node that describes a server or buffer, $b_{h,i}$ represents the designed buffer size allocated between nodes $h$ and its following node $i$, $T_{sol}$ is the obtained throughput in the solution, $t_{sol}$ is the computation time of buffer allocation and $t_{available}$ is the available computation time. Furthermore, $N_{sol}$ is the designed buffer size and $N_{max}$ is the maximum designed buffer size, which is decided by $t_{available}$. The term $t_{available}$ typically lies within 8 h for a large-scale production line and 4h for a small-scale production line.

3. Solution Methodology

Previous studies typically achieved the desired throughput by allocating several buffers at different locations in the production line. This method allows adding buffers at unsuitable locations; however, it increases the computation time of buffer allocation. Thus, to decrease unsuitable buffer allocation, it is effective to add one buffer at the bottleneck of a production line in each buffer update.

Figure 1 presents the framework of the proposed bottleneck-based variable neighborhood search algorithm. The Algorithm 1 presents the pseudocode of the proposed bottleneck-based variable neighborhood search algorithm. The algorithm detects the bottleneck of a production line using an active probability index. The initial neighborhood structure is set to detect the bottleneck with a small number of searches, which decreases the computation time of buffer allocation. When no satisfactory solution is generated in the initial neighborhood structure, an additional neighborhood structure is used to assess more candidate nodes, which improves the solution quality of the buffer allocation. The algorithm ends with no throughput increasing by allocating buffers or available computation time being exceeded.

Algorithm 1: bottleneck-based variable neighborhood search algorithm

1 Initialize parameters

2 $T_{sol}=1$

3 $\mathrm{Input} \mathrm{arrival} \mathrm{rates} {\lambda }_i,\mathrm{service} \mathrm{rates} \mathrm{of} \mathrm{nodes} {\mu }_i, \mathrm{nodes} nod=\left\{1,\cdots ,i,l,\cdots \right\},$ $\mathrm{edges} edg=\left\{\cdots ,\left(i,l\right),\cdots \right\} \mathrm{between} \mathrm{nodes}, \mathrm{service} \mathrm{discipline} sed=\left\{\cdots ,\left(i,FCFS\right),\cdots \right\}$ at merging or splitting node i

4 $\mathbf{while} T_{sol}>T_{comparision} \mathrm{and} t_{sol}<t_{available} \mathbf{do}$

5   $j=j+1$

6   $\mathbf{if} j=1 \mathbf{then}$

7     $\mathrm{Calculate} \mathrm{system} \mathrm{state} \mathrm{probability} sta \mathrm{by} \mathrm{QMTAA}$

8    $\mathbf{else}$

9     $\mathbf{if} j>2 \mathbf{then}$

10       $T_{comparison}=T_{hig}^{j-1}$

11      $\mathbf{end\; if}$

12     $\mathrm{Update} {\lambda }_i, {\mu }_i, nod, edg, sed, sta$

13     $\mathrm{Calculate} \mathrm{active} \mathrm{probability} \mathrm{index} {\beta }_i \text{of node }i \mathrm{based} \mathrm{on} sta$

14     $\mathrm{Calculate} \mathrm{total} \mathrm{number} \mathrm{of} \mathrm{candidate} \mathrm{bottlenecks} V_{bot}$

15     $\mathbf{for} k=1 \mathrm{to} \mathrm{initial} \mathrm{search} \mathrm{times} C_{ori} \mathbf{do}$

16        $V_{bot}=V_{bot}-C_{ori}$

17       Add one buffer before one candidate bottleneck based on βi from high value to low value and generate new ${\lambda }_i, {\mu }_i, nod, edg, sed.$

18       Calculate throughput of the new ${\lambda }_i, {\mu }_i, nod, edg, sed$ by QMTAA and put it into throughput set thr

19       $\mathrm{Recover} {\lambda }_i, {\mu }_i, nod, edg, sed$

20     $\mathbf{end\; for}$

21      $T_{hig}^j=max thr$

22      $\mathbf{while} \frac{T_{hig}^j-T_{hig}^{j-1}}{T_{hig}^{j-1}}<\epsilon \mathrm{and} V_{bot}>0 \mathbf{do}$

23        $V_{bot}=V_{bot}-C_{add}$

24        $\mathrm{Set} thr=\left\{\right\} \mathrm{and} \mathrm{put} T_{hig}^j \mathrm{into} thr$

25        $\mathbf{for} k=1 \mathrm{to} \mathrm{additional} \mathrm{search} \mathrm{times} C_{add} \mathbf{do}$

26       Add one buffer before one candidate bottleneck based on βi from high value to low value and generate new ${\lambda }_i, {\mu }_i, nod, edg, sed.$

27       Calculate throughput of the new ${\lambda }_i, {\mu }_i, nod, edg, sed$ by QMTAA and put it into throughput set thr

28        $\mathrm{Recover} {\lambda }_i, {\mu }_i, nod, edg, sed$

29     $\mathbf{end\; for}$

30      $T_{hig}^j=max thr$

31    end while

32     $T_{sol}=T_{hig}^j$

33     $N_{sol}=N_{hig}^j$

34     $B_{sol}=B_{hig}^j$

35   $\mathbf{end\; if}$

36  $\mathbf{end\; while}$

3.1. Notations

This section presents the notations used in the proposed algorithm:

• $i$: A node that models a server or buffer.
• $n_i$: Number of jobs at node $i$.
• $\pi \left(n_i=k\right)$: Steady-state probability of $k$ jobs being at node $i$.
• ${\lambda }_i$: External Poisson arrival rate at node $i$; i.e., the average number of jobs that enter a production line from node$i$ per unit time.
• ${\mu }_i$: Exponential mean service rate at node $i$; i.e., the average number of jobs that leave node $i$ per unit time.
• $j$: Number of buffer updates.
• $T_i$: Throughput at which jobs leave node $i$ per unit time.
• $T_{hig}$: Temporary highest throughput rate.
• $T_{hig}^j$: Obtained highest throughput rate at $j$th buffer update.
• $T_{sol}$: Throughput in the solution.
• $N_{hig}^j$: Buffer size corresponding to the obtained highest throughput rate at $j$th buffer update.
• $N_{sol}$: Buffer size in the solution.
• $B_{hig}^j$: Buffer configuration vector corresponding to the obtained highest throughput rate at the $j$th buffer update.
• $B_{sol}$: Buffer configuration vector in the solution.
• $C_{ori}$: Search times of the initial neighborhood.
• $C_{add}$: Search times of an additional neighborhood.
• $V_{bot}$: Number of nodes that may be the bottleneck.
• $V_{mer}$: Number of merging nodes.
• $V_{spl}$: Number of splitting nodes.
• ${\beta }_i$: Active probability index.

3.2. Queue Module-Based Throughput Analysis Approach (QMTAA)

The queue module-based throughput analysis approach (QMTAA) developed by Gao et al. [23] is efficient for calculating the throughput of production lines. Considering efficient buffer allocation, QMTAA is used in the study. Figure 2 show a production line model. In the modelling of QMTAA, products are called jobs; a server of a buffer is modelled as a node and denoted as $i$; service rate ${\mu }_i$ represents the performance of node $i$; and arrival rate ${\lambda }_i$ represents the external arrival jobs from input node $i$. At merging or splitting nodes, service disciplines determine job movement priority. The output parameters of QMTAA are throughput $T_i$. Figure 3 shows the framework of the throughput analysis in QMTAA. For more detailed information on the modelling and solution of QMTAA, the reader can refer to the literature [23].

3.3. Active Probability Index (API)

A bottleneck is a blocking point in a production line. A bottleneck indicator (BI), such as inventory [24] and active time [25], is an evaluation parameter that can be used to identify the bottleneck of the production line. The inventory indicator is the probability of full capacity, and a machine with a high inventory can easily become the bottleneck of a production line. The active time is the time when the machine is in the processing state; a machine with a long active time has a high possibility to be the bottleneck of a production line. Active time is effective in finding the real bottleneck [25]. However, QMTAA calculates the throughput of the production line based on steady-state probabilities but not on processing time. Therefore, based on the definition of the active time, the active probability index as a bottleneck indicator is proposed:

$${\beta }_i=\pi \left(n_i=1,n_l=0\right)+\pi \left(n_h=1,n_i=1,n_l=0\right)$$

(5)

Here, $\pi \left(n_i=1,n_l=0\right)$ is the state probability of one job being at node $i$ and no jobs being at its following node $l$. The state of $\pi \left(n_i=1,n_l=0\right)$ is described as shown in Figure 4; the red circle represents the job at node $i$. The term $\pi \left(n_h=1,n_i=1,n_l=0\right)$ is the state probability of one job being at node $h$ and its following node $i$, respectively, while no jobs are at node $l$. The state of $\pi \left(n_h=1,n_i=1,n_l=0\right)$ is described as shown in Figure 5.

In the case of a high arrival rate, $\pi \left(n_i=1,n_l=0\right)$ is effective to detect the bottleneck of a production line. However, when the external arrival rate is low, and few jobs are in a production line, the states of each node may be similar. This can decrease the effectiveness of $\pi \left(n_i=1,n_l=0\right)$. Considering that jobs are usually blocked before the bottleneck as the state is shown in Figure 5, $\pi \left(n_h=1,n_i=1,n_l=0\right)$ is used to improve the effectiveness of ${\beta }_i$ in the case of low arrival rates. Using QMTAA, the state probabilities of nodes in a production line can be obtained via a throughput calculation process. By substituting the state probabilities into Equation (5), the specific values of the active probability index of each node can be obtained.

If node $i$ is a merging node as shown in Figure 6, two active probability indexes can be obtained as

$${\beta }_{i-g}=\pi \left(n_i=1,n_l=0\right)+\pi \left(n_g=1,n_i=1,n_l=0\right)$$

(6)

$${\beta }_{i-h}=\pi \left(n_i=1,n_l=0\right)+\pi \left(n_h=1,n_i=1,n_l=0\right)$$

(7)

where ${\beta }_{i-g}$ refers to the active probability index for the location between nodes $g$ and $i$; meanwhile ${\beta }_{i-h}$ refers to the active probability index for the location between nodes $h$ and $i$.

If node $i$ is a splitting node as shown in Figure 7, there are two routes after node $i$. Because each job at node $i$ can only enter one route, two active probability indexes of two routes can be calculated, respectively. The maximum value between the two active probability indexes is used as the active probability index for node $i$.

$${\beta }_i=\max \left\{\begin{array}{c}\pi \left(n_i=1,n_l=0\right)+\pi \left(n_h=1,n_i=1,n_l=0\right),\\ \pi \left(n_i=1,n_p=0\right)+\pi \left(n_h=1,n_i=1,n_p=0\right)\end{array}\right\}$$

(8)

3.4. Variable Neighborhood Search (VNS)

To achieve a balance between computation time and solution quality of buffer allocation, a proper initial neighborhood structure is set to detect the bottleneck of a production line rapidly, where an additional neighborhood structure is set to improve the solution quality in case no satisfactory throughput is generated in the initial neighborhood structure. Here, neighborhood structure refers to candidate bottlenecks.

3.4.1. Initial Neighborhood Structure

Neighborhood search times that are the number of candidate bottlenecks considered can be set to different values according to different problems. For instance, one choice is to set all possible neighborhoods as the neighborhood structure and the other choice is to select only a set of possible neighborhoods [26]. Considering the effectiveness of the API and the efficient calculation of QMTAA, the initial neighborhood search times $C_{ori}$ is set as

$$C_{ori}=\min \left\{\frac{V_{bot}}{2},\sigma \right\}$$

(9)

where $V_{bot}$ is the number of total candidate bottlenecks.

According to the state probabilities of the nodes, the API values of the nodes can be obtained using Equation (5). According to the API values from high to low, $C_{ori}$ nodes are selected as initial candidate bottlenecks. If $V_{bot}/2$ is greater than $\sigma$, the initial neighborhood search time $C_{ori}$ is $\sigma$; otherwise, $C_{ori}$ is set as $V_{bot}/2$. According to our experiment results and error control, $\sigma$ is set to 10.

3.4.2. Neighborhood Change Criterion

The neighborhood change criterion is used when no satisfactory throughput is generated. Compared with the throughput $T_{hig}^{j-1}$ before one buffer update, if the current throughput $T_{hig}^j$ is improved by less than a fixed percentage, the neighborhood structure will be changed and additional neighborhood structure will be tested. The equation is described as

$$\frac{T_{hig}^j-T_{hig}^{j-1}}{T_{hig}^{j-1}}<\epsilon$$

(10)

According to our experiment results and error control, $\epsilon$ is set to $0.1\%$.

3.4.3. Additional Neighborhood Structure

If no satisfactory throughput is generated by the initial neighborhood structure, the neighborhood structure is expanded and additional candidate neighborhoods are tested. In general, the topology of a production line and the jobs flowing in it become more complex with increasing merging or splitting [27]; therefore, it is believed that the number of additional neighborhood searches should be related to the number of merging or splitting nodes in the production line. The number of additional neighborhood searches is set as

$$C_{add}=\max \left\{V_{mer},V_{spl}\right\}$$

(11)

where $V_{mer}$ and $V_{spl}$ are the numbers of merging and splitting nodes in the production line, respectively. For the application of additional neighborhoods, according to the API values from high to low, the initial candidate bottlenecks are ignored, and $C_{add}$ nodes are selected as the additional candidate bottlenecks. Then, one buffer is added before the additional candidate bottlenecks to search a better solution.

4. Numerical Example

The five comparison methods according to different search algorithms and neighborhood definition are listed in

Table 1. Five methods for comparison in the numerical example.

		Neighborhood Definition
		API	Inventory [24]	Random
Search algorithms	VNS	API-VNS (Proposed approach)	Inv-VNS	$\times$
	BS [24]	API-BS	Inv-BS	$\times$
	TS [29]	$\times$	$\times$	ETS

. The five methods are as follows:

• The proposed buffer allocation approach that generates candidate bottlenecks by the API and detects the real bottleneck by VNS, which is denoted by API-VNS.
• Park [24] used inventory to evaluate the candidate bottlenecks of a production line and used the beam search (BS) algorithm to search for the real bottleneck. Therefore, the inventory-based beam search algorithm (Inv-BS) is used as another method for comparison.
• Lutz et al. [28] and Papadopoulos et al. [29] used the tabu search (TS) algorithm to obtain suitable buffer allocation solutions. The solution quality of this method was shown to be high, and the computation time was controllable. Therefore, TS is used as a method for comparison. However, in prior studies, TS was typically used to maximize the throughput of a production line subject to a fixed number of designed buffers, whereas the designed buffer size is decided by available computation time in the proposed approach. For the comparison, it is assumed that in each buffer update, one buffer is added and the TS attempts to maximize the throughput. If the obtained throughput does not increase even when buffers are added, or available computation time is exceeded, the buffer allocation process stops. Otherwise, the loop of one buffer addition and throughput calculation is performed. This extended tabu search algorithm is denoted by ETS. Moreover, in the numerical examples, a random mechanism is used to generate candidate buffer allocation solutions in ETS; therefore, the average values based on five calculations are used.
• To further evaluate the effectiveness of the API, the API-BS generated by BS [24] and the proposed API is set as the fourth method for comparison.
• To evaluate the effectiveness of VNS further, Inv-VNS generated by inventory [24] and the proposed VNS is set as the fifth method for comparison.

In the numerical examples, nodes in the production line models represent servers and buffers. Both blue and green nodes represent buffers; the blue nodes transport jobs, and the green nodes not only transport jobs but they also change their movement direction. Therefore, the service rates of blue nodes are higher than those of the green nodes. Servers marked by black nodes have the lowest service rates.

Two experiments are performed in the numerical examples to evaluate the effectiveness of the proposed approach for a production line with a different topology and topology scale. Each experiment involves two input patterns where all initial values except for the external arrival rates are the same. The two different external arrival rates are used to represent a high arrival job flow and a low arrival job flow. The effectiveness of the proposed approach is evaluated in the large-scale experiment and the available computation time is set as 8 h. The other experiment is presented to show the application of the proposed approach in a small-scale production line. Considering that there are a small number of nodes in the experiment, the available computation time is set as 4 h. All five methods are applied to the same sets of data. Moreover, all five methods are written in Python 3.6 and executed in all experiments on a personal computer with a 2.6 GHz Intel Core 2 Duo CPU.

To evaluate the comparison results, two aspects are discussed:

• Solution quality refers to the obtained solution throughput because a buffer allocation approach with a high solution quality usually generates a high solution throughput. In the case of the same solution throughput, the buffer allocation approach that generates the same throughput with fewer designed buffer sizes has a higher solution quality.
• Computation time refers to the computation time spent to achieve the same throughput, because an efficient buffer allocation can allocate buffers and achieve an objective throughput rapidly.

4.1. Small-Scale Topology Experiment

4.1.1. Setting

A production line with a small-scale topology was tested, as shown in Figure 8. The production line includes three servers (nodes 3, 6, and 9) and 12 buffers. All input parameters for experiment 1 are listed in

Table 2. Input parameters of experiment 1.

Items	Parameters
Arrival rates	${\lambda }_1=\lambda$ (jobs/s)
Service rates of buffers 1, 4, 7, 11, 13, 15	${\mu }_1={\mu }_4={\mu }_7={\mu }_{11}={\mu }_{13}={\mu }_{15}={\mu }_{nor}$ (jobs/s)
Service rates of buffers 2, 5, 8, 10, 12, 14	${\mu }_2={\mu }_5={\mu }_8={\mu }_{10}={\mu }_{12}={\mu }_{14}={\mu }_{con}$ (jobs/s)
Service rates of servers 3, 6, 9	${\mu }_3={\mu }_6={\mu }_9={\mu }_{ser}$ (jobs/s)
Service discipline of merging	First come, first served: jobs arriving at the merging node enter it first preemptively.
Service discipline of splitting	Random: jobs at the splitting node move to ensuing nodes randomly.

.

4.1.2. Results

Table 3. Results of the five methods in experiment 1.

$\mathbf{Pattern} (\mathit{\lambda }, {\mathit{\mu }}_{\mathit{n}\mathit{o}\mathit{r}}$$,{\mathit{\mu }}_{\mathit{c}\mathit{o}\mathit{n}},{\mathit{\mu }}_{\mathit{s}\mathit{e}\mathit{r}})$	Algorithm	$\mathbf{Computation} \mathbf{Time}$ ${\mathit{t}}_{\mathit{s}\mathit{o}\mathit{l}}$ $\left(\mathbf{s}\right)$	$\mathbf{Obtained} \mathbf{Throughput} {\mathit{T}}_{\mathit{s}\mathit{o}\mathit{l}}$ $(\mathbf{jobs}/\mathbf{s})$	$\mathbf{Designed} \mathbf{Buffer} \mathbf{Size} {\mathit{N}}_{\mathit{s}\mathit{o}\mathit{l}}$	$\mathbf{Obtained} \mathbf{Buffer} \mathbf{Configuration}$ ${\mathit{B}}_{\mathit{s}\mathit{o}\mathit{l}}$$$\begin{gathered} =({\mathit{b}}_{\mathbf{1},\mathbf{2}},{\mathit{b}}_{\mathbf{2},\mathbf{3}},{\mathit{b}}_{\mathbf{3},\mathbf{14}}, \\ {\mathit{b}}_{\mathbf{4},\mathbf{5}},{\mathit{b}}_{\mathbf{5},\mathbf{6}},{\mathit{b}}_{\mathbf{6},\mathbf{12}},{\mathit{b}}_{\mathbf{7},\mathbf{8}}, \\ {\mathit{b}}_{\mathbf{8},\mathbf{9}},{\mathit{b}}_{\mathbf{9},\mathbf{10}},{\mathit{b}}_{\mathbf{11},\mathbf{12}},{\mathit{b}}_{\mathbf{13},\mathbf{14}}) \end{gathered}$$
(0.4, 1.0, 0.5, 0.2)	API-VNS	1012	0.2403	13	(10,2,1,0,0,0,0,0,0,0,0)
	Inv-BS	1605	0.2200	10	(1,0,0,2,0,1,0,3,0,3,0)
	ETS	Average: 14,400	Average:	Average:
			0.2438	12
			① 0.2408	① 11	① (6,1,1,1,1,1,0,0,0,0,0)
			② 0.2492	② 10	② (4,0,4,0,1,0,0,0,1,0,0)
			③ 0.2413	③ 15	③ (11,1,1,0,1,0,0,0,0,0,0)
			④ 0.2459	④ 10	④ (5,0,2,0,2,0,0,0,0,1,0)
			⑤ 0.2416	⑤ 13	⑤ (8,2,1,0,1,1,0,0,0,0,0)
	API-BS	1476	0.2403	13	(10,2,1,0,0,0,0,0,0,0,0)
	Inv-VNS	1895	0.2200	10	(1,0,0,2,0,1,0,3,0,3,0)
(0.6, 1.0, 0.5, 0.2)	API-VNS	3644	0.2714	19	(0,7,6,1,2,1,0,1,0,1,0)
	Inv-BS	1148	0.2192	8	(0,0,0,0,3,4,0,0,0,1,0)
	ETS	Average: 14,400	Average:	Average:
			0.2707	15
			① 0.2714	① 12	① (0,5,5,0,1,0,0,0,0,1,0)
			② 0.2695	② 12	② (0,2,5,0,2,0,0,0,2,1,0)
			③ 0.2733	③ 20	③ (4,5,9,0,1,0,0,0,1,0,0)
			④ 0.2687	④ 15	④ (0,4,4,2,0,3,1,0,0,1,0)
			⑤ 0.2704	⑤ 16	⑤ (0,4,5,3,1,2,0,0,1,0,0)
	API-BS	1530	0.2650	14	(0,7,7,0,0,0,0,0,0,0,0)
	Inv-VNS	2399	0.2664	18	(1,7,5,1,1,1,0,0,0,0,2)

lists the results of the five methods at the computation time when buffer allocation is finished. Figure 9 shows the computation time versus throughput curves for the five methods in the case of $\lambda =0.4$. The results show that API-VNS and API-BS can generate higher throughput than the other three methods in the first 2 h. However, API-VNS achieved the same throughput more rapidly than API-BS. Subsequently, ETS obtained a higher throughput than API-VNS because of its high solution quality for available computation time. Figure 10 shows the computation time versus throughput curves for the five methods in the case of $\lambda =0.6$. The results show that API-VNS can achieve the highest throughput among the comparison methods, which shows the advantage of its solution quality in available computation time. Moreover, compared to other four methods, API-VNS obtained the same throughput with least computation time.

Figure 11 and Figure 12 show the scatter plots of the designed buffer size versus the solution throughput for the five methods in the cases of $\lambda =0.4$ and $\lambda =0.6$, respectively. In the case of $\lambda =0.4$, ETS achieved the highest solution throughput, followed by API-VNS and API-BS. However, ETS allocated less designed buffers than API-VNS and API-BS. ETS adds several buffers in each buffer update, which test more candidate buffer allocation solutions. Therefore, it can achieve the highest solution quality in the experiment. Moreover, API-VNS and API-BS obtain the same solution throughputs as they both use API; Inv-BS and Inv-VNS also obtain the same solution throughput because both use the inventory indicator. Furthermore, API-VNS and API-BS have the highest solution quality because both achieve the highest solution throughput with the same designed buffer size.

Unlike that in the case of $\lambda =0.4$, API-VNS and API-BS obtain different solution throughputs, and Inv-BS and Inv-VNS also obtain different solution throughputs. API-VNS and API-BS use API as the BI to detect bottlenecks. However, the real bottleneck is not detected in the initial neighborhood structure, and VNS is used to search for more candidate bottlenecks. Therefore, API-VNS can achieve a higher solution throughput. Similarly, Inv-VNS achieves a higher solution throughput than Inv-BS. Compared to the API, the inventory indicator is not sufficiently effective in the experiment. Therefore, API-VNS can obtain a higher solution throughput than Inv-VNS in the case of $\lambda =0.6$.

Figure 13 shows the production line topology after buffers are allocated by API-VNS in the case of $\lambda =0.4$. A total of ten buffers were allocated before node 2, while three buffers were allocated in the branch with node 3. Because the external arrival rate is low and many jobs tend to arrive at node 14 rapidly via the branches with node 3, the splitting node 2 easily became the bottleneck; therefore, many buffers were allocated before it to compensate for the variation of job flow that attempts to enter via the branches with node 3. Figure 14 shows the production line topology after buffers are allocated by API-VNS in the case of $\lambda =0.6$. A total of 13 buffers were allocated in the branch with node 3, meanwhile 4 buffers were allocated in the branch with node 6; only 2 buffers were allocated in the branches with node 9. Compared to the case of $\lambda =0.4$, the external arrival rate increased in the case of $\lambda =0.6$. Therefore, it is difficult for jobs to arrive at node 14 via only the branches with node 3. Jobs from splitting node 2 arrive at merging node 14 by the 3 branches with nodes 3, 6, and 9. Because the branch with node 3 is the shortest for the jobs to arrive at splitting node 14, most jobs tend to enter it, and more buffers are needed here compared to that at other branches.

4.2. Large-Scale Topology Experiment

4.2.1. Setting

A production line with a large-scale topology including 35 nodes was tested, as shown in Figure 15. The production line includes three servers (nodes 13, 16, and 19) and 32 buffers. All input parameters for experiment 2 are listed in

Table 4. Input parameters of experiment 2.

Items	Parameters
Arrival rates	${\lambda }_1={\lambda }_4={\lambda }_7=\lambda$ (jobs/s)
Service rates of buffers 1, 3, $\cdots$, 33, 35	${\mu }_1={\mu }_3=\cdots ={\mu }_{33}={\mu }_{35}={\mu }_{nor}$ (jobs/s)
Service rates of buffers 2, 5, $\cdots$, 31, 34	${\mu }_2={\mu }_5=\cdots ={\mu }_{31}={\mu }_{34}={\mu }_{con}$ (jobs/s)
Service rates of servers 13, 16, 19	${\mu }_{13}={\mu }_{16}={\mu }_{19}={\mu }_{ser}$ (jobs/s)
Service discipline of merging	First come, first served: jobs arriving at the merging node enter it first preemptively.
Service discipline of splitting	Random: jobs at the splitting node move to ensuing nodes randomly.

.

4.2.2. Results

Table 5. Results of the five methods in experiment 2.

$\mathbf{Pattern}$ $(\mathit{\lambda }, {\mathit{\mu }}_{\mathit{n}\mathit{o}\mathit{r}}$$,{\mathit{\mu }}_{\mathit{c}\mathit{o}\mathit{n}},{\mathit{\mu }}_{\mathit{s}\mathit{e}\mathit{r}})$	Algorithm	$\mathbf{Computation} \mathbf{Time}$ ${\mathit{t}}_{\mathit{s}\mathit{o}\mathit{l}}$ $\left(\mathbf{s}\right)$	$\mathbf{Obtained} \mathbf{Throughput}$ ${\mathit{T}}_{\mathit{s}\mathit{o}\mathit{l}}$ $(\mathbf{jobs}/\mathbf{s})$	$\mathbf{Designed} \mathbf{Buffer} \mathbf{Size}$ ${\mathit{N}}_{\mathit{s}\mathit{o}\mathit{l}}$	$\mathbf{Obtained} \mathbf{Buffer} \mathbf{Configuration}$ ${\mathit{B}}_{\mathit{s}\mathit{o}\mathit{l}}$$$\begin{gathered} = \\ \begin{array}{c}({\mathit{b}}_{\mathbf{1},\mathbf{2}},{\mathit{b}}_{\mathbf{3},\mathbf{5}},{\mathit{b}}_{\mathbf{4},\mathbf{5}},{\mathit{b}}_{\mathbf{6},\mathbf{8}},{\mathit{b}}_{\mathbf{7},\mathbf{8}},{\mathit{b}}_{\mathbf{9},\mathbf{10}},\\ {\mathit{b}}_{\mathbf{11},\mathbf{12}},{\mathit{b}}_{\mathbf{12},\mathbf{13}},{\mathit{b}}_{\mathbf{13},\mathbf{24}},{\mathit{b}}_{\mathbf{14},\mathbf{15}},{\mathit{b}}_{\mathbf{15},\mathbf{16}},\\ {\mathit{b}}_{\mathbf{16},\mathbf{22}},{\mathit{b}}_{\mathbf{17},\mathbf{18}},{\mathit{b}}_{\mathbf{18},\mathbf{19}},{\mathit{b}}_{\mathbf{19},\mathbf{20}},{\mathit{b}}_{\mathbf{21},\mathbf{22}},\\ {\mathit{b}}_{\mathbf{23},\mathbf{24}},{\mathit{b}}_{\mathbf{25},\mathbf{26}},{\mathit{b}}_{\mathbf{27},\mathbf{28}},{\mathit{b}}_{\mathbf{30},\mathbf{31}},{\mathit{b}}_{\mathbf{33},\mathbf{34}})\end{array} \end{gathered}$$
(0.1, 1.0, 0.5, 0.2)	API-VNS	21,430	0.2263	15	(0,0,0,0,0,0,0,2,0,0,0,1,0,0,0,0,1,9,2,0,0)
	Inv-BS	633	0.2033	1	(0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)
	ETS	Average: 28,800	Average:	Average:
			0.2139	4
			① 0.2154	① 5	① (0,0,0,0,0,0,0,1,0,0,0,0,0 ,0,0,1,2,1,0,0,0)
			② 0.2103	② 3	② (0,0,0,0,0,0,0,1,0,0,0,1,0 ,0,0,0,0,1,0,0,0)
			③ 0.2255	③ 4	③ (0,0,0,0,0,0,0,0,0,0,0,1,0 ,0,0,1,0,0,0,0,2)
			④ 0.2097	④ 3	④ (0,0,0,0,0,0,0,1,0,0,0,1,0 ,0,0,0,0,1,0,0,0)
			⑤ 0.2089	⑤ 3	⑤ (0,0,0,0,0,0,0,1,0,0,0,0,0 ,0,0,0,0,1,1,0,0)
	API-BS	18376	0.2263	15	(0,0,0,0,0,0,0,2,0,0,0,1,0,0,0,0,1,9,2,0,0)
	Inv-VNS	15518	0.2253	8	(2,0,0,0,2,0,0,2,0,1,1,0,0,0,0,0,0,0,0,0,0)
(0.2, 1.0, 0.5, 0.2)	API-VNS	23924	0.2292	12	(0,0,0,0,0,0,0,1,0,0,0,1,0,0,0,0,4,5,1,0,0)
	Inv-BS	745	0.2033	1	(0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)
	ETS	Average: 28,800	Average:	Average:
			0.2210	7
			① 0.2275	① 4	① (0,0,0,0,0,0,0,1,0,0,0,0,0 ,0,1,1,0,0,0,1,0)
			② 0.2135	② 4	② (0,0,0,0,0,0,0,1,0,0,0,1,0 ,0,0,0,1,1,0,0,0)
			③ 0.2135	③ 9	③ (0,0,1,3,1,0,0,0,0,0,1,0,0 ,0,0,0,1,1,1,0,0)
			④ 0.2248	④ 8	④ (3,0,0,1,0,1,0,0,0,0,0,0,0 ,0,1,0,0,0,0,1,1)
			⑤ 0.2262	⑤ 9	⑤ (4,0,0,1,0,0,0,0,0,0,0,0,0 ,0,0,1,0,0,0,2,1)
	API-BS	22,371	0.2292	12	(0,0,0,0,0,0,0,1,0,0,0,1,0,0,0,0,4,5,1,0,0)
	Inv-VNS	21,884	0.2248	10	(0,0,0,0,2,0,0,6,0,1,1,0,0,0,0,0,0,0,0,0,0)

lists the results of the five methods at the computation time when buffer allocation is completed. Figure 16 and Figure 17 show the computation time versus throughput curves for the five methods in the cases of $\lambda =0.1$ and $\lambda =0.2,$ respectively. The results show that both API-VNS and API-BS can achieve the highest throughput among the five methods, even though API-VNS takes a little longer for the throughput solution compared to API-BS. This delay is attributed to the application of the variable neighborhood search. When the throughput obtained by API-VNS increases on an extremely small scale, the variable neighborhood search is triggered, and an additional neighborhood structure is used. Therefore, compared to API-BS, the computation time of buffer allocation for API-VNS is slightly longer. Moreover, for the production line with a large-scale topology, the computation time of API-VNS is less than 8 h. It is interesting that Inv-BS and Inv-VNS generated very different results, even though they used the same BI. Both Inv-VNS and Inv-BS use inventory as a bottleneck indicator. However, an additional neighborhood structure is used when the real bottleneck is not detected in the initial neighborhood structure for Inv-VNS. Therefore, Inv-VNS and Inv-BS generated very different results in the experiment.

Figure 18 and Figure 19 show the scatter plots of the designed buffer size versus the solution throughput for the five methods in the cases of $\lambda =0.1$ and $\lambda =0.2$, respectively. API-VNS and API-BS achieved the highest solution throughput with the same designed buffer size, followed by Inv-VNS and ETS. The solution throughput obtained by Inv-BS was the lowest. Both API-VNS and API-BS use the API as the BI to detect the bottleneck of a production line. For large-scale topology, the effectiveness of the API is so high that all real bottlenecks are detected by the initial neighborhood structure. Therefore, API-VNS and API-BS have a similar solution quality in the experiment. Because the effectiveness of the inventory indicator for the large-scale topology is low, it is difficult to detect the real bottleneck and increase the buffer size. Therefore, the solution throughput obtained by Inv-BS is the lowest, which shows the worst solution quality among all comparison methods. ETS adds several buffers in each buffer update and it tests more candidate buffer allocation solutions; therefore, it allocated buffers and increased the throughput very slowly in the experiment.

Figure 20 shows the production line topology after buffers are allocated by API-VNS in the case of $\lambda =0.1$. Most buffers were allocated before node 26. Because the external arrival rate is low, many jobs can arrive at the merging node 24 without considerable blocking. However, when the jobs leave node 24 and attempt to enter node 26, it is difficult to enter the node rapidly because the node requires some time to change job movement, and node 26 has a lower service rate than that of node 25. Therefore, node 26 easily becomes the bottleneck of the production line and requires many buffers allocated before it. Figure 21 shows the production line topology after buffers are allocated by API-VNS in the case of $\lambda =0.2$. Most buffers were allocated before nodes 24 and 26. In this case, the external arrival rate increased, and it was difficult for the jobs to arrive at node 24 using only the branches with node 13. Jobs from splitting node 12 arrive at merging node 24 by the three branches with nodes 13, 16, and 19. To decrease the blocking at merging node 24, compared to the case of $\lambda =0.1$, more buffers were allocated between node 23 and node 24 in the case of $\lambda =0.2$.

4.3. Discussion

In terms of solution quality, API-VNS can achieve the highest solution quality among five comparison methods in the large-scale experiment. In the small-scale experiment, API-VNS can achieve the highest solution quality in the case of $\lambda =0.6$, while ETS achieves a higher solution quality than API-VNS in the case of $\lambda =0.4$. This is because API-VNS can achieve a high solution quality with a short available computation time. If the computation time is extended, the solution quality of API-VNS may be degraded because API-VNS adds only one buffer in each buffer update. In the case of $\lambda =0.4$, available computation time is very long for the production line with small-scale topology. Even though the buffer is allocated at the real bottleneck of the production line in each buffer update by API-VNS, it is still possible for the final solution to be a local optimal solution because a large number of buffers are allocated with a long available computation time. Solution quality of ETS is hardly affected even though the available computation time is very long, because it adds several buffers at a time and can thus consider more candidate buffer allocation solutions; however, it is usually difficult for ETS to provide a high solution quality in the available computation time. Inv-BS, API-BS, and Inv-VNS cannot achieve the same solution quality as API-VNS in some cases because of the disadvantages of using the inventory indicator and BS. Inventory is not effective enough to represent characteristics of the real bottleneck; meanwhile it is easy for BS to obtain a local optimal solution due to its limited search times.

As for computation time, API-VNS achieves the same throughput with the least computation time, which shows the advantages of its computation time. Because the API is more effective than inventory to represent characteristics of the real bottleneck, API-BS is found to be better than Inv-BS. Compared to BS that has limited search times, VNS can test more candidate bottlenecks in the case of no satisfactory solution generated, therefore, Inv-VNS is found to be better than Inv-BS. ETS usually requires a long computation time to obtain the same throughput because of its buffer updating regulation, which may test too many candidate buffer allocation solutions. Moreover, with the number of nodes increasing in a production line, computation time of the proposed approach also largely increases. Although it is difficult to estimate the production line scale that leads to unreasonable computation time, we believe that the proposed approach can be applicable to most of the production lines in industry.

In summary, API-VNS achieves a good balance between solution quality and computation time in available computation time, especially for the efficient buffer allocation of a production line with a large-scale topology.

5. Conclusions and Future Work

This study presented an efficient buffer allocation approach based on a bottleneck indicator and a variable neighborhood search algorithm to solve the buffer allocation problem in production lines. The active probability index as the bottleneck indicator was proposed to predict the most promising buffer updating locations. Based on the active probability index, the real bottleneck of the production line can be detected with a small number of searches, thereby decreasing computation time.

The variable neighborhood search algorithm was used to improve solution quality. If no satisfactory solution was generated for the bottleneck in the initial neighborhood structure, an additional neighborhood structure was used to search for a better solution. To prove the effectiveness of the proposed buffer allocation approach, it was compared with four other buffer allocation methods. The numerical examples showed that the proposed approach achieves a good balance between solution quality and computation time. In the large-scale experiment, the proposed approach achieves the highest solution quality and allocates buffers more rapidly than the other four methods. It requires less than 8 h even for the buffer allocation of the production line with 50 nodes.

In summary, the study contributes toward efficient buffer allocation for the rapid estimation of topology and the potential value of a production line. In particular, in the phase of feasibility analysis, the proposed approach can be used to rapidly estimate the handling capability and cost of a production line.

The proposed buffer allocation approach can only solve the efficient buffer allocation problem for a production line with one kind of job. In the future, the proposed approach should be improved to allocate buffers efficiently for a production line with multiple kinds of jobs.