Paola Goatin
email: paola.goatin@inria.fr

Simone Göttlich
email: goettlich@uni-mannheim.de.

Oliver Kolb
email: kolb@uni-mannheim.de.

Speed limit and ramp meter control for traffic flow networks

Keywords: AMS Classification. 90B20, 49K20 Keywords. Traffic flow network, control of discretized PDEs, adjoint based optimization

Speed limit and ramp meter control for traffic flow networks

Introduction

Traffic flow networks based on scalar conservation laws have been investigated from various perspectives during the last years, see for instance [START_REF] Coclite | Traffic flow on a road network[END_REF][START_REF] Holden | A mathematical model of traffic flow on a network of unidirectional roads[END_REF] for theoretical results or [START_REF] Bretti | A tracking algorithm for car paths on road networks[END_REF] for numerical considerations. In the case of nonlinear traffic flow networks where the dynamics obey the Lighthill-Whitham-Richards equations [START_REF] Lighthill | On Kinematic Waves. II. A Theory of Traffic Flow on Long Crowded Roads[END_REF][START_REF] Richards | Shock waves on the highway[END_REF], the crucial point is the modeling of intersections. Assuming conservation of mass leads to a flux maximization problem at nodes to obtain unique admissible solutions. This approach results in appropriate Riemann solutions that can be directly specified, see [START_REF] Garavello | Traffic flow on networks[END_REF]. We will use this mathematical formulation and framework to describe the dynamics for the traffic system.

For many applications, not only the numerical simulation of the nonlinear dynamics is of interest but also optimization or control issues. To set up the optimization problem, a cost functional and control variables must be identified, while the constraints are given by the above mentioned traffic flow network equations. There exists a broad range of practical aspects including the optimal routing of traffic [START_REF] Gugat | Optimal control for traffic flow networks[END_REF], traffic light control [START_REF] Göttlich | Traffic light control: a case study[END_REF] or coordinated ramp metering [START_REF] Reilly | Adjoint-based optimization on a network of discretized scalar conservation law pdes with applications to coordinated ramp metering[END_REF] for the LWR network model. Since these optimal control problems are constrained by nonlinear conservation laws, relaxed models with simplified dynamics have been investigated instead, cf. [START_REF]Simplified dynamics and optimization of large scale traffic networks[END_REF].

Reduced models usually rely on linear approximations leading to control methodologies such as linear optimization [START_REF] Muralidharan | Optimal control of freeway networks based on the Link Node Cell Transmission model[END_REF], feedback control [START_REF] Papageorgiou | ALINEA: A local feedback control law for on-ramp metering[END_REF] or Lyapunov stability [START_REF] Bastin | Lyapunov stability analysis of networks of scalar conservation laws[END_REF], respectively. However, nonlinear control techniques as for instance adjoint calculus [START_REF] Reilly | Adjoint-based optimization on a network of discretized scalar conservation law pdes with applications to coordinated ramp metering[END_REF] or model predictive control [START_REF] Hegyi | Optimal coordination of variable speed limits to suppress shock waves[END_REF] represent a suitable and natural choice to treat traffic network control problems.

We concentrate on the variable speed limit (VSL) problem coupled to ramp metering. From a mathematical point of view, the control variable, i.e. the maximal velocity for the VSL problem, varies and must be evaluated at discrete points in time. This leads to conservation laws with time-dependent discontinuous coefficients [START_REF] Coclite | Conservation laws with time dependent discontinuous coefficients[END_REF]. On the other hand, the on-ramp metering problem corresponds to a discussion of boundary conditions at junctions [START_REF]Conservation laws on complex networks[END_REF][START_REF] Garavello | Time-varying Riemann solvers for conservation laws on networks[END_REF]. Setting up the corresponding control problems is then a combination of two control issues directly influencing each other in the sense that time-dependent speed limits reduce congestions and hence the travel times. This kind of problem have been for example considered in [START_REF] Csikos | Freeway shockwave control using ramp metering and variable speed limits[END_REF][START_REF] Hegyi | Model predictive control for optimal coordination of ramp metering and variable speed limits[END_REF][START_REF] Muralidharan | Optimal control of freeway networks based on the Link Node Cell Transmission model[END_REF] and references therein. In contrast to our approach, the latter either follow a model predictive control where the optimization is obtained using sequential quadratic programming (SQP) or are restricted to the presentation of (numerical) results for one road/one on-ramp only.

To the best of our knowledge, the variable speed limit control problem combined with ramp metering has never been solved for the full LWR model on complex network topologies in a rigorous manner. In this article, we will close this gap from a modeling and computational point of view. We will stick to continuous optimization techniques where usually the first order optimality system is derived and solved by a descent type method [START_REF] Kelley | Iterative methods for optimization[END_REF][START_REF] Spellucci | Numerische Verfahren der Nichtlinearen Optimierung[END_REF]. We apply the so-called discretize-then-optimize approach, meaning that a suitable numerical discretization is chosen such that the original problem leads to a finite-dimensional optimality system [START_REF] Gugat | Optimal control for traffic flow networks[END_REF]. In this way, we automatically include information about the current traffic situation into the control framework (open loop control) and look for the best traffic management. This procedure was originally introduced for aerodynamic shape design [START_REF] Giles | An introduction to the adjoint approach to design[END_REF].

We proceed as follows: We briefly recall the LWR network model in Section 2. Then, in Section 3, we explain how we model variable speed limits and ramp metering. We address the optimal control problem and its solution procedure by discretizing the governing equations in space and time. The numerical results are collected in Section 4. In particular, we point out benefits and drawbacks of our approach. We also observe that variable speed limits help to navigate the traffic flow, so that short travel times and high system outflows are maintained even if the ramp metering is unable to prevent congestion.

Traffic Flow Network Modeling

Following the ideas in [START_REF] Coclite | Traffic flow on a road network[END_REF][START_REF] Garavello | Traffic flow on networks[END_REF], we typically model a traffic flow network as a directed graph G = (V, E), where the edges E correspond to roads and the vertices V to junctions or intersections. Each edge e ∈ E is associated with an interval [0, L e ] and ρ e (x, t) denotes the density of cars on road e.

Given some initial state ρ e (x, 0) on all roads, the dynamics are described by

∂ t ρ e (x, t) + ∂ x f e (ρ e (x, t), t) = 0 ∀e ∈ E, x ∈ (0, L e ), t ∈ [0, T ] (1)
with Lighthill-Whitham-Richards flux [START_REF] Lighthill | On Kinematic Waves. II. A Theory of Traffic Flow on Long Crowded Roads[END_REF][START_REF] Richards | Shock waves on the highway[END_REF]

f e (ρ, t) = ρ v max e (t) 1 - ρ ρ max e ,
where v max e (t) is the (piecewise constant) maximal speed limit and ρ max e is the maximal car density corresponding to the jammed situation. See for instance Figure 1 for an illustration of the dependencies of the velocity and the flow rate with respect to the density in case of different speed limits. We also denote by f max e the maximal flux: We also see in Figure 1 that different maximal velocities v max e (t) lead to conservation laws on networks with time-dependent discontinuous coefficients. Note that general existence results for these type of conservation laws on networks are not available at the moment. The network consideration requires the extension of the well-posedness result given in [START_REF] Coclite | Conservation laws with time dependent discontinuous coefficients[END_REF] for the standard Cauchy problem on the real line. Nevertheless, in the specific application considered in this work, the time-dependence is piecewise constant, and therefore classical existence results on networks can be applied [START_REF]Conservation laws on complex networks[END_REF].

f max e = f e (ρ c

Coupling Conditions at Junctions

The description of the whole network dynamics requires the definition of the corresponding boundary and coupling conditions at junctions v ∈ V to basically ensure the conservation of mass. Therefore, we introduce the demand and supply functions that are given respectively by

D e (ρ) = f e (ρ) if ρ ≤ ρ c e , f max e if ρ ≥ ρ c e ,
and S e (ρ) =

f max e if ρ ≤ ρ c e , f e (ρ) if ρ ≥ ρ c e .
For simplicity and in view of the applications considered in this work, we will only consider the cases of one-to-one junctions, the merging of two roads into one, and the dispersing of one road into two, see Fig. In the case of a junction between only an incoming road e = 1 and an outgoing one e = 2, the appropriate fluxes at the junction are simply obtained through the minimization between demand and supply:

γ1 = γ2 = min {D 1 (ρ 1 ), S 2 (ρ 2 )} . (2)
Let us now consider more involved cases, e.g. the case of a dispersing junction with one incoming road e = 1 and two outgoing roads e = 2, e = 3. Here, the distribution of cars must be externally prescribed by so-called distribution rates α 2,1 ≥ 0 and α 3,1 ≥ 0 (and α 2,1 + α 3,1 = 1).

Contrarily to what is proposed in [START_REF] Garavello | Traffic flow on networks[END_REF], we make the choice of applying NON-FIFO rules, thus allowing for some flow through the junction even if one of the outgoing roads is blocked. This is more reasonable for highway networks than a classical FIFO model. The fluxes at the junction are computed as (see also [START_REF] Herty | Modeling, simulation, and optimization of traffic flow networks[END_REF][START_REF] Lebacque | First order macroscopic traffic flow models for networks in the context of dynamic assignment[END_REF])

γ2 = min {α 2,1 D 1 (ρ 1 ), S 2 (ρ 2 )} , (3a)
γ3 = min {α 3,1 D 1 (ρ 1 ), S 3 (ρ 3 )} , (3b) γ1 = γ2 + γ3 .

(3c)

Finally, we focus on the case of a merging junction of ingoing two roads e = 1, e = 2 and outgoing one e = 3. In this case, a priority parameter P ∈ (0, 1) is introduced so that γ1 = P γ3 and γ2 = (1 -P )γ 3 . This is necessary to define a unique solution in the supply constrained cases, see [7, Section 5.2.2] for more details. The corresponding fluxes are then

γ1 = min {D 1 (ρ 1 ), max {P S 3 (ρ 3 ), S 3 (ρ 3 ) -D 2 (ρ 2 )}} , (4a) γ2 = min {D 2 (ρ 2 ), max {(1 -P )S 3 (ρ 3 ), S 3 (ρ 3 ) -D 1 (ρ 1 )}} , (4b) γ3
= γ1 + γ2 . ( 4c
)
The model equations ( 1)-( 4) can be further coupled to inflow conditions at roads entering or leaving the network. As we will see later on, this modeling framework can be extended to describe the ramp metering.

Inflow and Outflow Conditions

Let us consider an arc e connected to the network only at its right node. Given a desired inflow rate f in e , the actual inflow to the road e is given by γ in e = min f in e , S e (ρ e ) .

We assume there is a queue at the left node of arc e with length l e (t). Then, the inflow to the road is given by γ in e = min {D e (l e ), S e (ρ e )} [START_REF] Csikos | Freeway shockwave control using ramp metering and variable speed limits[END_REF] with the demand function dependent on the length l e (t)

D e (l e ) = f max e if l e (t) > 0 , min f in e , f max e if l e (t) = 0 . (7)
As usual, the evolution of the queue-length l(t) obeys the rate equation

dl(t) dt = f in e -γ in e ( 8
)
for an initial state l e (0). Conversely, on arcs connected only on their left to the network, we prescribe absorbing boundary conditions up to a given maximum flow rate f out

which ensures that the flow reaching the end of such a road is able to leave the network without being stopped if it is below the given maximum flow rate.

In the next section, we describe the optimization problem we intend to solve. We also comment on the discretization and the numerical implementation.

Optimal Control Problem

For optimization purposes, we are interested in controlling the traffic flow through a network by adjusting maximal speed limits and on-ramp fluxes as well.

The overall goal of optimization is to choose the controls in such a way that the total travel time is minimized and/or the outflow of the system is maximized, i.e. (10) Here, β e and γ e denote non-negative weights. Note that we later consider additional terms in the objective function such that J will further explicitly depend on the control variables introduced in the following. The constraints of the optimization problem are mainly determined by the traffic flow network model introduced in Section 2. Further, we consider upper bounds for queue lengths below. These inequality constraints will be explicitly passed to the applied optimization procedure and not integrated by additional penalty terms in the objective function. However, we need to explain how the two controls are integrated into the model equations. That means, we have to modify the flux in (1) for the speed limit and (8) for the ramp metering control. Since the optimization problem under consideration is constrained by differential equations, we first use suitable numerical methods to discretize the equations and then propose a nonlinear optimization technique. This results in a so-called discretize-then-optimize approach.

Variable Speed Limits

As already mentioned and shown in Figure 1, the maximal velocities v max e (t) on each road e ∈ E may change in time. Therefore, we assume that v max e (t) is a time-dependent control variable restricted by box constraints,

v low e ≤ v max e (t) ≤ v high e ∀t ∈ [0, T ] .
To get a finite dimensional optimization problem and also for practical reasons, we introduce control points ν k ∈ [0, T ] (k ∈ {0, . . . , Nu}) and corresponding control variables z k e for each road. We take v max e (t) piecewise constant on the control grid:

v max e (t) = z k+1 e ∀t ∈ (ν k , ν k+1 ] . (11)
The choice of the control grid will be investigated in Section 4.1. Note that, in order to avoid high fluctuations in the control function, a penalty term can be added to [START_REF] Giles | An introduction to the adjoint approach to design[END_REF]. This issue is also addressed in Section 4.1.

Ramp Metering

The control of on-ramps can be recast in the framework of merging junctions, i.e. we consider a two-to-one merge as in Figure 2(c). We aim at controlling the main lane access from the on-ramp, where we assume that the index e = 2 corresponds to the on-ramp, now described by a queue [START_REF] Garavello | Traffic flow on networks[END_REF]. The time-dependent control variable w e = w e (t) is used to control the inflow from the on-ramp into the main lane by rewriting equations ( 4). Mathematically, we define the controlled demand function

D c e (l e ) = w e (t)D e (l e ), (12)
for D e (l e ) given by [START_REF] Garavello | Traffic flow on networks[END_REF]. Then we plug [START_REF] Gugat | Optimal control for traffic flow networks[END_REF] in ( 4) and end up with

γ1 = min {D 1 (ρ 1 ), max {P S 3 (ρ 3 ), S 3 (ρ 3 ) -D c 2 (l 2 )}} , (13a) γ2 = min {D c 2 (l 2 ), max {(1 -P )S 3 (ρ 3 ), S 3 (ρ 3 ) -D 1 (ρ 1 )}} , (13b) γ3
= γ1 + γ2 . (13c)
Correspondingly, the evolution of the on-ramp buffer changes to

dl(t) dt = f in 2 -γ2 , (14)
where f in 2 is the external boundary inflow at the on-ramp. Similar to the speed control [START_REF] Göttlich | Traffic light control: a case study[END_REF] we also assume a piecewise constant control function for the ramp metering:

w e (t) = w k+1 e ∀t ∈ (ν k , ν k+1 ] . (15)
A reasonable extension is to put queue length limits on [START_REF] Hegyi | Optimal coordination of variable speed limits to suppress shock waves[END_REF]. This case is presented in Sections 4.2 and 4.3.

Summarizing, the speed limit and ramp metering control problem for traffic flow networks reads as follows: min ze,we J(l e , ρ e , f out e , z e , w e ) s.t. ( 1)-( 9), ( 11), ( 12)-( 15). [START_REF]Simplified dynamics and optimization of large scale traffic networks[END_REF] This is a nonlinear optimization problem which can be solved within an adjointbased optimization framework. To this end, we fully discretize ( 16) in a straightforward way. Then, the first order optimality system and the associated gradient information is obtained by evaluations of forward and backward (or adjoint) equations. Details of this procedure can be found in Section 3.2.

Discretization

For the numerical solution of the described model, we consider a finite number of time points t n = n∆t with ∆t = T Nt . Note that the t n may differ from the control points ν k above. Further, we divide each road e into Nx e cells of equal size ∆x e = Le Nxe . Hence, the objective function [START_REF] Giles | An introduction to the adjoint approach to design[END_REF] The constraints are discretized by following the structure of Section 2. For the discretization of (1), we use a staggered Lax-Friedrichs scheme (leaving out the index e for the road and the time dependency of the flux function for a better reading):

ρ n+1 0.5 = 1 4 (3ρ n 0.5 + ρ n 1.5 ) -λ 2 [f (ρ n 1.5 ) + f (ρ n 0.5 ) -2f (ρ n 0 )] , (18a)
ρ n+1 j-0.5 = 1 4 (ρ n j-1.5 + 2ρ n j-0.5 + ρ n j+0.5 ) -λ 2 [f (ρ n j+0.5 ) -f (ρ n j-1.5 )] , (18b)
ρ n+1 Nx-0.5 = 1 4 (ρ n Nx-1.5 + 3ρ n Nx-0.5 ) -λ 2 [2f (ρ n Nx ) -f (ρ n Nx-0.5 ) -f (ρ n Nx-1.5 )] , (18c)
where λ = ∆t/∆x and ρ n e,j-0.5 ≈ 1 ∆x e j∆xe (j-1)∆xe ρ e (x, t n ) dx for j ∈ {1, . . . , Nx e }, n ∈ {0, . . . , Nt} .

Concerning [START_REF] Giles | An introduction to the adjoint approach to design[END_REF], f out e (t) corresponds to f (ρ n Nx ). The inflow f (ρ n 0 ) and the outflow f (ρ n Nx ) directly result from the applied coupling and boundary conditions.

Coupling conditions at junctions

At a simple junction connecting two roads e = 1 (incoming) and e = 2 (outgoing), we use

f (ρ n 1,Nx1 ) = f (ρ n 2,0 ) = min D 1 (ρ n 1,Nx1-0.5 ), S 2 (ρ n 2,0.5 ) , (19)
according to [START_REF] Bretti | A tracking algorithm for car paths on road networks[END_REF]. For junctions with one incoming road e = 1 and two outgoing roads e = 2 and e = 3, and non-negative distribution rates α 2,1 and α 3,1 (with α 2,1 + α 3,1 = 1), we apply (referring to (3))

f (ρ n 2,0 ) = min {α 2,1 c 1 , c 2 } , (20a)
f (ρ n 3,0 ) = min {α 3,1 c 1 , c 3 } , (20b)
f (ρ n 1,Nx1 ) = f (ρ n 2,0 ) + f (ρ n 3,0 ) , (20c)
with

c 1 = D 1 (ρ n 1,Nx1-0.5 ) , c 2 = S 2 (ρ n 2,0.5 ) , c 3 = S 3 (ρ n 3,0.5 ) .
For junctions with two incoming roads e = 1 and e = 2, one outgoing road e = 3, and priority parameter P ∈ (0, 1), we use (according to (4))

f (ρ n 1,Nx1 ) = min {c 1 , max {P c 3 , c 3 -c 2 }} , (21a)
f (ρ n 2,Nx2 ) = min {c 2 , max {(1 -P )c 3 , c 3 -c 1 }} , (21b)
f (ρ n 3,0 ) = f (ρ n 1,Nx1 ) + f (ρ n 2,Nx2 ) , (21c)
with

c 1 = D 1 (ρ n 1,Nx1-0.5 ) , c 2 = D 2 (ρ n 2,Nx2-0.5 ) , c 3 = S 3 (ρ n 3,0.5 ) .
Note that c 2 = D c 2 (l n 2 ) in the case of a controlled on-ramp junction as described in ( 12) and ( 13).

Inflow conditions

According to (5), we apply

f (ρ n e,0 ) = min f in e (t n ), S e (ρ n e,0.5 ) (22)
at an inflow boundary with a desired inflow rate f in e (t n ). In the presence of a queue, according to ( 6), ( 7), ( 8) and ( 12

where l n e ≈ l e (t n ). At an outflow boundary at edge e with maximum outflow rate f out e (t n ), we use (see [START_REF] Garavello | Time-varying Riemann solvers for conservation laws on networks[END_REF])

f (ρ n e,Nx ) = min f out e (t n ), D e (ρ n e,Nx-0.5 ) . ( 25
)
Entire Simulation Procedure

For given initial conditions for the traffic flow network and prescribed speed limits and ramp controls, the presented discretizations allow for an approximate solution of our model. The basic steps of this procedure are given in Algorithm 1.

Starting from the initial state at time t 0 = 0, one may iteratively compute the flow rates at the current time t n (for n = 0, . . . , Nt -1), and subsequently the density values and queue lengths at the next time t n+1 .

Algorithm 1 Numerical Simulation

Input: initial conditions ρ 0 e,j and l 0 e at time t 0 ; speed limits v max e (t) and ramp controls w e (t). Output: state variables ρ n e,j and l n e for all times t n with n ∈ {1, . . . , Nt}. for n = 0, . . . , Nt -1 do 1. Compute inflow and outflow rates at the nodes at time t n according to ( 22), ( 23), ( 25), ( 19), ( 20) and ( 21).

2. Compute density values ρ n+1 e,j and queue lengths l n+1 e at time t n+1 according to [START_REF] Kelley | Iterative methods for optimization[END_REF] and [START_REF] Papageorgiou | ALINEA: A local feedback control law for on-ramp metering[END_REF]. end for

Optimization approach

Based on the presented discretization and the simulation procedure shown in Algorithm 1, we want to solve the underlying (finite dimensional) optimization task with an SQP solver [START_REF]A new technique for inconsistent QP problems in the SQP method[END_REF][START_REF]An SQP method for general nonlinear programs using only equality constrained subproblems[END_REF]. This necessitates the evaluation of the objective function and the computation of gradient information. The (discretized) objective function ( 17) can be directly evaluated after running a simulation according to Algorithm 1. For the necessary gradient information we applay a first-discretize adjoint approach. The main steps of the underlying procedure are given in Algorithm 2.

Algorithm 2 Gradient Computation

Input: initial conditions ρ 0 e,j and l 0 e at time t 0 ; speed limits v max e (t) and ramp controls w e (t) given by a control vector u containing all z k e and w k e (for k ∈ {1, . . . , Nu}). Output: total derivative d du J(u, y(u)). 1. Run numerical simulation according to Algorithm 1.

Solve adjoint equation (26). 3. Compute gradient d

du J(u, y(u)) according to [START_REF] Spellucci | Numerische Verfahren der Nichtlinearen Optimierung[END_REF].

To describe the applied adjoint approach, we consider the objective function J(u, y) (in our case given by ( 17)), where u contains all control variables of the discretized model equations (the speed limits z k e and the ramp controls w k e ) and y all state variables (densities ρ n e , flow rates f (ρ n e ), queue lengths l n e ). Further, we summarize all discretized model equations, or constraints respectively, as E(u, y) = 0. Assuming that for given control variables u the model equations E(u, y) have a unique solution, one may consider y = y(u) and the so-called reduced problem with the objective function J(u) = J(u, y(u)). Note that the solution of E(u, y) = 0 corresponds to running Algorithm 1.

With the so-called adjoint state ξ given by the solution of the adjoint equation ∂ ∂y E(u, y(u))

T ξ = - ∂ ∂y J(u, y(u)) T , (26)
one can efficiently compute the cost gradient as

d d u J(u, y(u)) = ∂ ∂u J(u, y(u)) + ξ T ∂ ∂u E(u, y(u)) . (27)
In fact, the partial derivatives of J and E with respect to u and y can be easily computed and ( 26) is a single linear system with a special structure that can be easily exploited (see for instance [START_REF] Kolb | Simulation and Optimization of Gas and Water Supply Networks[END_REF][START_REF] Kolb | Mathematical optimization of water networks[END_REF]). Incidentally, we remark that the solution given by the gradient descent method is only locally optimal. As already noted above, the time points t n of the discretization may differ from the control points ν k . The values of the controls v max e (t) and w e (t) at t = t n , which are needed within Algorithms 1 and 2, are computed according to [START_REF] Göttlich | Traffic light control: a case study[END_REF] and [START_REF] Herty | Modeling, simulation, and optimization of traffic flow networks[END_REF]. Regarding the computation of gradient information with Algorithm 2, this necessitates the application of the chain rule (cf. again [START_REF] Kolb | Simulation and Optimization of Gas and Water Supply Networks[END_REF]), where in our case the "inner derivatives" equal zero or one due to the piecewise constant control functions.

Numerical Results

This section collects the numerical results corresponding to three different scenarios. The first example is concerned with variable speed limits to control traffic flow on a road network similar to the Frankfurter Kreuz, which is a famous German Autobahn interchange. Here we vary discretization as well as control grid parameters to study their influence on the optimal solution. In the second example we consider the combined optimization of variable speed limits (VSL) and ramp metering. The topology of the third example is quite similar to the second one, but refers to a real world case study.

Variable Speed Limits

Inspired by the Autobahn interchange in Frankfurt, Germany, we present a corresponding topology of the road network (including distribution rates α and priority parameters P ) in Figure 3. Further road properties as well as the initial conditions are given in Table 1. Additionally, Figure 4 shows the inflow profiles within the considered time horizon of 1000 seconds. For the described setting we consider the following experiments:

1. Optimization for a fixed discretization (∆x = 50, ∆t = 0.5) and various numbers of control points Nu. 3. We finally consider the same experiment as in 1. with a fixed discretization but an additional penalty term with weight δ e ≥ 0 in [START_REF] Holden | A mathematical model of traffic flow on a network of unidirectional roads[END_REF]:

e δ e Nt n=1 ∆t v max e (t n ) -v max e (t n-1 ) v high e ∆t 2
in order to get smoother controls. This is similar to [START_REF] Hegyi | Optimal coordination of variable speed limits to suppress shock waves[END_REF]. Table 2 and Figure 5 show the results for the first test. While the discretization parameters are kept fixed, we consider an increasing number of control points Nu and run the optimization once for minimizing the total travel time (with β e = 10 -3 ) and once for maximizing the accumulated outflow at the nodes outA and outB (with γ e = 10 -1 ). As expected one gets lower travel times / larger outflows for an increasing number of control points. In particular, compared to the uncontrolled case, where all speed limits are taken at the upper bound, we achieve an improvement of 1.28% / 0.03%. Exemplarily, Figure 6 compares the traffic density in the middle of roadB2 with and without optimization of speed limits (with respect to the total travel time). The computing time for a single simulation with the given discretization parameters is roughly one second on an Intel(R) Core(TM) i5-3340M CPU with 2.70GHz. 6: Density on roadB2 with and without optimization of speed limits.

In the second experiment we vary the discretization parameters and keep the number of control points constant for the minimization of the total travel time / maximization of the outflow. Table 3 and Figure 7 show the results for these computations. Note that the presented values of the objective function (scaled travel times / outflows) are evaluated using a simulation with the finest discretization parameters. Similar to above, the finer the discretization parameters are, the better the computed optimal solutions are. For the (too) coarse discretizations, one actually gets "optimal controls", which are worse than the "no control" case (all speed limits at the upper bound). Note that this may only happen because we finally evaluate the computed controls by a simulation using the finest grid.

The results of the third experiment are shown in Figure 8. Obviously, the additional penalty term, which penalizes variations in the control, leads to smoother optimal solutions.

VSL meets Coordinated Ramp Metering

In our second example, we consider the combined optimization of variable speed limits and ramp metering. The topology of the underlying network is shown in Figure 9 and the corresponding parameters are given in Table 4. The priority parameter at the on-ramp is P = 0.5 and we take f max = 1.5. Figure 10 shows the inflow profiles and the maximum outflow. For the discretization we apply ∆t = 1.5 and ∆x = 100. A single simulation with these parameters takes about 2.3 seconds (for the considered time horizon of 3 hours). For the optimization we use Nu = 36 control points.

The objective for this scenario is to minimize the total travel time, i.e. γ e = 0 in [START_REF] Holden | A mathematical model of traffic flow on a network of unidirectional roads[END_REF], subject to the following constraints: We allow a maximum size of the queue at the inflow of the main road (node "in") of 50 cars and a maximum size of the queue at the on-ramp of 600 cars. Both constraints are violated without optimization (v max at the upper bound and w(t) = 1 at the on-ramp). Note that the gradients of these constraints, which are necessary for the applied SQP solver, are computed exactly in the same manner as the gradients of the objective (as described in Section 3.2). in mid1 on-ramp out road1a road1b road2

Figure 9: Road network with an on-ramp at the node "on-ramp". Figure 11 shows the inflow to the main road from the on-ramp in the uncontrolled case, nicely validating the different situations that may occur at an on-ramp: Initially the full inflow goes to the main road (f in = 0.75). Due to the congestion at road2, the inflow drops down to P • f out = 0.5 (outflow at the node "out" is 1.0 and priority parameter P = 0.5). When the maximum possible outflow at the node "out" increases, also the flow on the on-ramp increases up the maximum flow level (f max = 1.5). When the queue at the on-ramp is empty, the inflow to the main road from the on-ramp decreases to the inflow at this node again (f in = 0.75).

Finally, Figures 12 and13 show the computed optimal control and the queue lengths at the inflow of the main road and at the on-ramp in the uncontrolled and the optimized cases. q(t) at "in" with no control q(t) at "on-ramp" with no control q(t) at "in" with opt. control q(t) at "on-ramp" with opt. control those on the bottom are on and off ramps. Highway's sections limited by green lines are those where the maximal speed limit is 110 km/h, while in the orange ones is 90 and in the red one is 70 km/h. Width is proportional to the number of lanes: 2, 3 or 4. For further details see [START_REF] Cabassi | Validation of traffic flow models on processed GPS data[END_REF]. Numerical simulations performed in this section correspond to sections 1 to 4.

Inspired by the real network depicted in Figure 14, we consider a stretch of highway of 9 km long divided in cells of ∆x = 100m each as follows:

• a section of 5 km between x 0 = 0 km and x 1 = 5 km consisting of 3 lanes (ρ max Moreover, an on-ramp link is connected to the mainline at the node x 1 (with priority parameter P = 0.25). We know that traffic is hindered downstream, that is, we impose a maximum outflow at x 3 . The inflow and maximum outflow values are given in Figure 15. The computing time for a single simulation with ∆t = 1.5 seconds for a 5 hour time horizon is roughly 5 seconds. are imposed by the authorities. We are interested in comparing the current situation resulting from the above choice of the parameters with the controlled one. We use the current speed limits as upper bound for the speed controls and 50 km/h as lower bound for all roads.

The objective is again to minimize the total travel time subject to the following constraints:

• maximum size of the queue in Antibes: 120 cars,

• maximum size of the queue at the on-ramp: 50 cars.

Figure 16 shows the traffic density on the entire section at different times in the uncontrolled case. Due to the limited outflow, a traffic jam is building at (roughly) 7:15 (corresponding to t = 1.25 hours, first plot), almost arriving at x 0 at about 8:30 (third plot) and having vanished approximately further 2 hours later. Unfortunately, the optimization procedure is not able to (significantly) improve the total travel time for the given scenario. Nevertheless, by controlling the speed limits and the metering rate, we are able to find a solution fulfilling the constraints above while maintaining the total travel time. The optimal solution found for the controls is plotted in Figure 17, the queues in the uncontrolled and the optimized case are shown in Figure 18.

Conclusion

In this work we have considered variable speed limits combined with coordinated ramp metering within the framework of the LWR network model. On one hand, the first order LWR model can be considered the most simple PDE model for traffic flow, which also allows for congestions. Nevertheless, the simulation results for the real world example presented in Section 4.3 agreed well with the observed real situation. To improve the current situation, we applied a first discretize then optimize adjoint approach and sequential quadratic programming. While the fulfillment of prescribed constraints was successful within this framework, the optimization procedure was not able to (significantly) improve the current situation in terms of total travel time. Probably, this is a drawback of the applied first order model. This assumption is motivated by our results in Section 4.2, since for similar scenarios as in [START_REF] Hegyi | Model predictive control for optimal coordination of ramp metering and variable speed limits[END_REF], where a "discrete second order model" but also a different model for the on-ramp flow are used, speed control and coordinated ramp metering yield a significant improvement of the total travel time. Accordingly, in future work we are going to extend the presented framework to a second order PDE model and also to consider different models for the on-ramp flow. q(t) at "in" with no control q(t) at "onramp" with no control q(t) at "in" with opt. control q(t) at "onramp" with opt. control

Figure 1 :

 1 Figure 1: Velocity and flow rate for different speed limits.

2

 2

  .

Figure 2 :

 2 Figure 2: Different types of junctions.

  f out e , D e (ρ e ) ,

  min J(l e , ρ e , f out e

  is discretized by quadrature formulas as follows: Nt n=1 f (ρ n e,Nxe ) ∆t . (17)

  ), we use f (ρ n e,0 ) = min c queue , S e (ρ n e,0.5 )(23)withc queue = w e (t n ) min f in e (t n ) + e + ∆t f in e (t n ) -f (ρ n e,0 ) ,

3 Figure 3 :

 33 Figure 3: Road network with two main roads.

Figure 4 : 3 . 2 .

 432 Figure 4: Inflow profiles for the network in Figure 3.

Figure 5 :

 5 Figure 5: Optimal control of v max for an increasing number of control points.

Figure 7 :

 7 Figure 7: Optimal control of v max for different discretizations.

Figure 8 :

 8 Figure 8: Optimal control of v max with and without penalty term (min. travel time).

Figure 10 :Figure 11 :

 1011 Figure 10: Inflow/max. outflow profiles for the network in Figure 9.

Figure 12 :

 12 Figure 12: Optimal control of v max on road1b and w(t) at the on-ramp.

Figure 13 :

 13 Figure 13: Queue at the node "in" and the on-ramp with and without optimization.

1 = 1 =max 2 = 2 =max 3 = 3 =

 112233 450 cars/km) with maximal speed v max 110 km/h;• a section of 3 km between x 1 = 5 km and x 2 = 8 km consisting of 4 lanes (ρ 600 cars/km) with maximal speed v max 110 km/h;• a section of 1 km between x 2 = 8 km and x 3 = 9 km consisting of 3 lanes (ρ 450 cars/km) with maximal speed v max 90 km/h.

  /hour] (a) Inflow at x0.

  /hour] (b) Inflow at x1 (on-ramp).

  Max. outflow at x2 (off-ramp).

  Max. outflow at x3.

Figure 15 : 1 , v max 2 and v max 3

 15123 Figure 15: Inflow/max. outflow profiles for considered network part of Figure 14. The speed limits v max 1 , v max 2

Figure 16 :Figure 17 :

 1617 Figure 16: Traffic density between Antibes and Nice at different times.

Figure 18 :

 18 Figure 18: Queue at the node "in" and the on-ramp with and without optimization.

Table 1 :

 1 Properties of the roads in Figure3

	road	length ρ max v low v high initial density
	roadA1	1000	2	20	30	0.3
	roadA2	1000	2	20	30	0.3
	roadA3	1000	2	20	30	0.3
	roadB1	1000	2	20	30	0.3
	roadB2	1000	2	20	30	1.2
	roadB3	1000	2	20	30	1.2
	roadAB	200	0.5	10	20	0.1
	roadBA	200	0.5	10	20	0.1
	inflow at node inA		inflow at node inB
	0	500	1,000

Table 2 :

 2 Optimal travel times / outflows for different numbers of control points

	Nu ∆x / ∆t min. travel time max. outflow
	-	50 / 0.5	2336.698921	1844.762416
	5	50 / 0.5	2307.370375	1845.023309
	10	50 / 0.5	2307.157634	1845.030866
	20	50 / 0.5	2306.863796	1845.289234
	40	50 / 0.5	2306.778537	1845.290014
	80	50 / 0.5	2306.694086	1845.353672
	ρ(500, t) on roadB2 with no control	ρ(500, t) on roadB2 with opt. control
		1.2
		1
	density	0.6 0.8
		0.4
		0.2
		0	200	400	600	800	1,000
				t
	Figure

Table 3 :

 3 Optimal travel times / outflows for different discretizations

	Nu ∆x (max.) / ∆t min. travel time max. outflow
	-	-	2330.987519	1846.918574
	20	200 / 0.500	2369.960626	1825.869588
	20	100 / 0.500	2333.714043	1836.601771
	20	50 / 0.500	2306.708163	1845.327369
	20	25 / 0.250	2300.563136	1846.649973
	20	12.5 / 0.125	2297.448274	1847.150023

Table 4 :

 4 Properties of the roads in Figure9

	road	length ρ max v low v high initial density
	road1a	2000	2	30	30	0.1
	road1b	2000	2	10	30	0.1
	road2	4000	2	30	30	0.1

Acknowledgments

This work was financially supported by the project "Transport network modeling and analysis" co-funded by DAAD (Project-ID 57049018) and the PHC Procope (Project no. 30715QA).


Antonio Giovannini
email: antonio.giovannini@univ-lorraine.fr

Alexis Aubry
email: alexis.aubry@univ-lorraine.fr

Hind Hervé Panetto
email: herve.panetto@univ-lorraine.fr

El Haouzi

Ludovic Pierrel

Michele Dassisti
email: michele.dassisti@poliba.it

A Aubry

* H Panetto

H El Haouzi
email: hind.el-haouzi@univ-lorraine.fr

* L Pierrel

M Dassisti

Approach for the rationalisation of product lines variety

Keywords: Mass customization, Product variety, Knowledge representation, Knowledge-based system

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

1.

INTRODUCTION: ABOUT MASS CUSTOMISATION AND PRODUCT VARIETY For a shirt manufacturer, "what if technology made it possible for every one of the five thousand shirts to be customized while on the assembly line […] produced just as quickly as the five thousand identical shirts, yet at not greater expense?" Starting from these words Davis in [START_REF] Davis | Future Perfect[END_REF] introduced for the first time the term mass customisation (MC). Other definitions can be found in [START_REF] Du | Product Platform Representation: a Graph Grammar Approach[END_REF] and [START_REF] Blecker | Mass Customization Vs[END_REF]. In these papers, MC is defined as a business approach that aims to fulfil individual customer's needs having an organizational efficiency of a mass production (MP) company. The MC is explained by comparison also in (Pine II et al., 1993). Authors discuss the change of paradigm needed to move toward MC: if MP or continuous improvement strategies call for low costs and standard goods and services, MC stress on flexibility and quick responsiveness in order to cope with the products customisation. Another recently introduced concept is the Mass Craftsmanship (MCMS) that is a hybrid form of pure MC and mass personalization, since it is possible to address both wide market and unique requirements. An interesting application in the furniture sector is discussed in [START_REF] Dassisti | Enterprise Integration and Economical Crisis for Mass Craftsmanship: A Case Study of an Italian Furniture Company[END_REF], which is mainly similar to that addressed in this paper. From these definitions, it is clear now the big deal in MC is to timely react to the complexity deriving from the variety of the customer domain. This variety impacts directly the number of products to be manufactured and consequently, the complexity of the manufacturing system and of the planning and scheduling processes [START_REF] Blecker | Mass Customization Vs[END_REF]. Most of the related works cope with these effects of the product variety. Complementarily, in this paper, the aim is to reason about the origin of this variety, in order to define the right level of customisation to propose, i.e. the number of product variants. For a better understanding, the example of a shoes seller who offered 3*10 21 variants of its shoes is described in (Piller 2003). All together, these shoes can cover 7,000 times the surface of the earth. In the next section, we formalise the modelling requirements to rationalise the product variety. In the section 3 current variety modelling methods are presented: here, defining a gap between these systems and the customer domain. To understand how to bridge this gap, in the section 4, we focus on the methods typically employed for designing non-customisable products: here the aim is to discuss which method is the more appropriate for expressing formally the variety in the customer domain. Starting from methods discussed in the section 4. A conceptual model that applies a System thinking view on the product variety definition is presented in the section 5. Using this conceptual model as knowledge model, a knowledge-based system is designed in section 6. Finally, section 7 is dedicated to present an application of an industrial case. In the last section, results and future perspectives are discussed.

MODELING REQUIREMENTS FOR VARIETY RATIONALISATION

In order to identify the modelling requirements to rationalise the product variety, let us first define two generic sets and . The set represents a targeted customer segment. An element of is a vector of features in the customer domain expressing one customer. The set represents the set of product variants defined for the customer segment: an element of is a vector of features in the engineering domain expressing one product variant (see Fig. 1a). The function g is the product variety definition function and it has as domain and as codomain. One product variant can correspond to more than one customer. This means that two different element of can be related by g to the same element of . In other words, the product variety definition function g can be multivalued (see Fig. 1b).

Fig. 1 -how the relationships between the customers and the product variants allows to define the right product variety If is the image of the function g, we can define a function that has as domain and as codomain. The function is the configuration function that allows to link the customers for which a product is feasible (set ) with the product variants in . The configuration function is defined as the inverse function of the multivalued definition function g (represented also in Fig. 1c). In order to avoid unnecessary development costs, an engineer should design no more than one variant for each customer in the customers segment: these variants have the same added value for the customer, but can represent different resources consumption for the customizer. This requirement can be formalised by the following property of the configuration function :

(1)

There exists more than one subset of in which respects this property: the choice of the best one should be done according criteria from economics, sustainability and so on. A subset of , in which the configuration function respects the defined property (1), is called . If a function respects the property (1), a customer cannot be related to more than one product variant. In other words, the function defined from to is a single-valued function (see Fig. 1d). If is the inverse function of and respects (1) then we can infer that covers completely : a product variant that is not related with any customer cannot exist. This means that an engineer is not involved in the development of a product variant that will not be sold to any customers.

Starting from these definitions, the set represents the right product variety for the customer variety . From the whole customers segment , the function g allows to identify the set representing the customers that is possible to satisfy. A configuration system that expresses the right level of product variety is a system that uses the configuration function as in (1) to allow each customer described in to configure only one product variant in . In the next section, an overview of works on variety modelling, especially for product configuration, is presented. The aim is to verify if the state of the art includes solutions able to model the set , and consequently the set (i.e. formalisation of the right product variety).

CURRENT VARIETY MODELING METHODS

The models that formalise the variety (i.e. set ) in MC are usually named product family [START_REF] Hong | Identification of the Optimal Product Configuration and Parameters Based on Individual Customer Requirements on Performance and Costs in One-of-a-kind Production[END_REF], configurable product model [START_REF] Aldanondo | Configuration for Mass Customization: How to Extend Product Configuration Towards Requirements and Process Configuration[END_REF] or product line [START_REF] Pohl | Software Product Line Engineering[END_REF][START_REF] Mazo | Constraints: The Heart of Domain and Application Engineering in the Product Lines Engineering Strategy[END_REF]. In this paper we refer to them as product lines (PLs). A PL is the model that expresses the product variety, i.e. set , that a company offers to a given customer segment in order to fulfil the needs of customers in the segment.

A PL is the base model for every configuration system, used by the customer to select one product variant starting from its needs. In all configuration systems, the customer describes his needs giving some values and preferences to attributes related to the PL variety. An attribute is defined as "an inherent property or characteristic of an entity that can be distinguished quantitatively or qualitatively by human or automated means" (ISO/IEC/IEEE, 2007). Starting from the attributes values, the configuration system is able to define the product variants into the PL variety that are related to the customer needs. For instance, the range of values for the attribute screen size can represent the product variety of a laptop PL.

In the following figure from [START_REF] Jiao | Product Family Design and Platformbased Product Development: a State-of-the-art Review[END_REF], a complete view of the PLs design and development is shown. The authors define there four main processes for translating the customer needs into design, manufacturing and logistic requirements:

• Product definition -how to offer the right variety to the right target market? • Product design -definition of parameters or functional modules (PL attributes) for deriving from the PL the product that fulfils the customer needs • Process design -the management of process variety with process platforms and process configuration methods • Supply chain design -the management of variety on sourcing, manufacturing and distribution strategies. Here, customer needs represents the customer's description of the ideal product (e.g. cute, easy to use). Functional requirements concern the features owned by the product, seen as a whole (e.g. colour, size). Design parameters are features characterising product modules, subassemblies and components. Process and logistic variables deal with production and supply chain (not the focus of this paper). adapted from [START_REF] Jiao | Product Family Design and Platformbased Product Development: a State-of-the-art Review[END_REF] In this section, an overview on PLs modelling solutions and related configuration systems is presented. In Tab. 1, related works are classified according to the above-defined terms related to customer needs, functional requirements and design parameters. The analysed research works are classified according to the semantics of the attributes that expresses the PL variety regarding the customer in current configuration systems. Essentially, we consider here research works that model concepts related to the customer, e.g. customer needs, customer profiles. The analysis of the solutions developed so far allows us to identify a gap between the semantics of these concepts in the cited scientific works and the customer domain representing the set , as formalised in the previous section. This gap prevents the presented configurations system to identify a function and therefore the set representing the right product variety.

Product configuration from design parameters

In order to configure a product starting from design parameters, the customer is asked to know how components interacts and what the final product features are. Here the required knowledge is technical. For instance, in configuration processes of laptops, the variants description is typically based on memory size (RAM), processor speed, and so on. In each case, the customer has to have a good knowledge about a computer architecture even if its needs concern the ability of the laptop to go on internet, to write some documents, to watch videos, to play videogames and so on. In this kind of systems, a clear definition of the customer needs as required for the definition of is not expressed. This lack in the definition of hinders formalising the configuration function for linking the customers segment with the right level of product variety, i.e. . The effect on the product variety is that, two customers having the same needs, and this representing only one element of the set, can configure two different product variants, as a consequence of their knowledge about the computer architecture. This violates the property (1) causing a lack of control on the level of product variety proposed to the customers.

Product configuration from functional requirements

In configuration systems based on attributes described as functional requirement, the customer would be asked to configure the product starting from a holistic view of the product. In this case the customer has to know how the product interacts with its environment to fulfil his needs. For instance, in a heating or cooling system, the power of the system is a property and is not the only one directly related to a room temperature value that can represents a real customer need. In order to reach a temperature target we need to know about room usage, isolation and so on. Also in this situation, two customers with the same needs, represented as only one element of the set (see section 2), can configure two different product variants, according to their experience about the usage of these kinds of systems. As for the systems in the previous subsection, configuration systems based on functional requirements cannot express univocally the right product variety. Product configuration from customer needs In [START_REF] Helo | Integrated Vehicle Configuration System-Connecting the Domains of Mass Customization[END_REF], the customizer uses market research. In this case, the manufacturer designs the products and after looks for potential customers for defining a variety in the customer domain. Here, the product variety is defined before defining the customers segment. Doing so it is not possible to guarantee that each product variant meets the requirements of at least one customer in the targeted segment. Moreover, even if the customer does not express his needs as design parameters or functional requirements, he answers also questions about the product (e.g. "which part of the truck do you like most?"). Therefore, also in this case a formalisation of the customers segment, as in , is not feasible.

The effect of the gap: missing a consistent model of the customer segment

As a consequence of the recognised gap between the current configuration systems attributes and the customer domain, as defined by the set , in current configuration systems, the customer is asked for describing something about the product. The effects of this lack of the definition of the set are shown in the Fig. 3. Without a formal definition of a set representing the customer variety, a formalisation of a unique configuration function , as described above, is never performed. In other words, each customer follows a different based on his knowledge; therefore the selection of the best variants (according in Fig. 3) cannot be performed on the engineering side. The absence of a unique formalised implies that a customer, element of , can also configure (according in Fig. 3) a product variant that does not represent the best choice for the enterprise (see the definition of ). In the worst case (according in Fig. 3), the customer can select something not included in the available product variety. In summary, without a consistent formalisation of , a definition of a set representing the right product variety is not possible.

Fig. 3 -Effects of the gap between configuration systems and the definition of

The gap between the representation of the product variety and the customer domain -that is not covered by current configuration systems leads to build configuration systems that cannot express the right level of product variety. In order to bridge this gap, we need to understand how to define and formalise the customer variety and what is the knowledge needed for the definition and configuration functions and the set . In the next section an overview on marketing and engineering methods for the non-customisable product definition processes is presented. The aim is to understand how the link between the customer domain and the product is performed for non-customisable product and then apply this solution to the variety modelling.

CUSTOMER MODELING FOR NON-CUSTOMISABLE PRODUCTS DESIGN

Typically the product definition process, for the PLs as well as for simple products, is discussed in the marketing domain and during some engineering phases, i.e. the early design stages.

Marketing domain

Usually, the solutions to cope with the product definition are in the domain of marketing. We can identify two main approaches: a "attribute-based" and a product "alternativebased" product choice.

The first group is mainly based on the conjoint analysis [START_REF] Green | Conjoint Analysis in Consumer Research: Issues and Outlook[END_REF]. This technique represents a milestone: this is an attribute-based method that aims to study the customer behaviour; the customer preferences on product attributes are analysed in order to derive a utility function to be maximised during the design stage. An application can be found in [START_REF] Balakrishnan | Genetic Algorithms for Product Design[END_REF]: here authors use a genetic algorithm to elaborate the conjoint analysis data for design optimisation.

Another application is suggested in [START_REF] Tseng | Design by Customers for Mass Customization Products[END_REF], where the designed by customers method is presented. Here authors describe how to integrate in an engineering design the conjoint analysis results. In [START_REF] Krishnan | Appropriateness and Impact of Platform-Based Product Development[END_REF], authors define a consumer valuation that is calculated from the consumer utility per performance unit. In [START_REF] Hong | Identification of the Optimal Product Configuration and Parameters Based on Individual Customer Requirements on Performance and Costs in One-of-a-kind Production[END_REF], authors represent the formalisation as a customer satisfaction optimization model for solving a configuration problem. A genetic algorithm is deployed for finding a solution. Graphs are used for linking product components features with customer needs. To the second group of methods belongs the decision-based design [START_REF] Hazelrigg | A Framework for Decision-Based Engineering Design[END_REF]. For example, in [START_REF] Wassenaar | An Approach to Decision-based Design[END_REF], authors compare the discrete choice analysis (DCA) with the conjoint analysis. In the former, the customer choice is directly related to product alternatives. The hypothesis here is that for choosing which product to buy is what customer does best. Actually, in [START_REF] Huffman | Variety for Sale: Mass Customization or Mass Confusion[END_REF], authors present experimental results on the customers' satisfaction in front of product variety. They show how too much variety can be frustrating for the customers and an attribute-based selection is to prefer to an alternative-based, because the first one can simplify the product variety vis-à-vis the customer. In all described marketing methods the analysis of the customer preferences starts with the evaluation of solutions, represented by product attributes or directly by product alternatives. In this way, the customer is asked to talk about the product. Therefore a formalisation of a unique configuration function , as described above, is never performed. In other words, each customer follows a different based on his knowledge. The absence of a unique formalised implies a lack in the characterisation of the customers segment, i.e. the set . In summary, the usage of this type of methods for the PL definition lead to the cases discussed in the section 3;

Tab. 1-overview on configuration systems Customer needs Functional requirements Design Parameters Deployed configuration method [START_REF] Aldanondo | Configuration for Mass Customization: How to Extend Product Configuration Towards Requirements and Process Configuration[END_REF][START_REF] Mazo | Constraints: The Heart of Domain and Application Engineering in the Product Lines Engineering Strategy[END_REF][START_REF] Yang | A Constraint Satisfaction Approach to Resolving Product Configuration Conflicts[END_REF] x Constraint-based approach [START_REF] Du | Product Platform Representation: a Graph Grammar Approach[END_REF][START_REF] Janitza | A Product Model for Mass -Customisation Products, 1023-1029[END_REF][START_REF] Qin | Product Configuration Based on Modular Product Family Modelling[END_REF] x Mapping approach [START_REF] Gao | Automatic Acquisition of Product Configuration Model Based on Ontology Mapping[END_REF][START_REF] Liu | Layered Product Configuration Model Based on Feature and Faced to Customer[END_REF] x Ontology mapping approach [START_REF] Helo | Integrated Vehicle Configuration System-Connecting the Domains of Mass Customization[END_REF] x Ontology mapping approach [START_REF] Hong | Identification of the Optimal Product Configuration and Parameters Based on Individual Customer Requirements on Performance and Costs in One-of-a-kind Production[END_REF] x Genetic programming [START_REF] Inakoshi | Effective Decision Support for Product Configuration by Using Cbr[END_REF] x Case-based reasoning & constraint-based approach [START_REF] Li | Product Configuration Optimization Using a Multiobjective Genetic Algorithm[END_REF] x Genetic algorithm [START_REF] Wang | Research on Design Method of Demand-driven Product Configuration for Mass Customization[END_REF] x Ontology mapping [START_REF] Xie | Modelling and Solving Engineering Product Configuration Problems by Constraint Satisfaction[END_REF] x Constraint-based approach [START_REF] Zhou | Customer-driven Product Configuration Optimization for Assemble-to-order Manufacturing Enterprises[END_REF] x Constraint-based approach & genetic algorithm [START_REF] Zhu | Applying Fuzzy Multiple Attributes Decision Making for Product Configuration[END_REF] x Fuzzy decision making approach without a consistent formalisation of , a definition of a set representing the right product variety is not possible.

Engineering domain

In this section, some of most known engineering design solutions are briefly introduced. Most of those are related to the concepts of product and process quality.

One of the best approach oriented to close the gap between customer domain and engineering domain is the design for 6S [START_REF] Ferryanto | DESIGN FOR SIX SIGMA[END_REF]. One of the basic tool for this is the Quality Function Deployment (QFD) method [START_REF] Ferryanto | DESIGN FOR SIX SIGMA[END_REF]. The application of QFD for product design provides an effective methodology for the recursive translation of the voice of customer into customer needs, so as to facilitate their technical specification. QFD allows (1) to analyse the requirements demanded by customers in their own words, (2) to translate the relationships between these and product quality properties, (3) to convert customer requirements into technical ones [START_REF] Akao | Quality Function Deployment: Integrating Customer Requirements Into Product Design[END_REF]. The lean production (LP) philosophy is based on the experiences of the Toyota Production System (TPS) [START_REF] Shah | Defining and Developing Measures of Lean Production[END_REF]. The LP focus is on the waste minimisation.

According authors in [START_REF] Spear | Decoding the DNA of the Toyota Production System[END_REF], LP is based on four main rules: (1) all work shall be highly specified as to content, sequence, timing, and outcome;

(2) every customersupplier connection must be direct, and there must be an unambiguous yes-or-no way to send requests and receive responses;

(3) the pathway for every product and service must be simple and direct; (4) any improvement must be made in accordance with a scientific method, at the lowest possible level in the organization. Also the lean philosophy, like for design for 6S, has a branch that focuses on the product development. In [START_REF] Morgan | The Toyota Product Development System[END_REF], authors define 13 principles of the lean product development. The first one concerns the characterisation of a customer-defined value for distinguishing the value-added features from the waste. According authors in [START_REF] Liker | Lean Product Development as a System: A Case Study of Body and Stamping Development at Ford[END_REF], the best way to deploy this principle is to go beyond the QFD performing a Requirement Engineering (RE) process.

Based on theoretical principles from the General Systems Theory (Von [START_REF] Bertalanffy | General Systems Theory[END_REF], in last years a new engineering discipline has been developed: System Engineering (SE). The focus of SE is on the design of complex systems that usually require multidisciplinary exchanges of knowledge and expertise. Main system models are [START_REF] Pyster | A Guide to the Systems Engineering Body of Knowledge (SEBoK)[END_REF]:

1. The System requirements model that contains the required system features in order to fulfil customer needs; this model is independent from solution alternatives and from technology; 2. The Logical architecture model that describes how the system functions, i.e. its behaviour for the requirements fulfilment; this model is independent from technology 3. The Physical architecture model that describes the set of elements that perform functions; this model is related to technologies. The process that performs a translation from customer requirements to system requirements is named RE. The main purpose of RE "is to produce a set of system requirements which, as far as possible, is complete, consistent, relevant and reflect what the customer actually wants" [START_REF] Sommerville | Requirements Engineering: A Good Practice Guide[END_REF]. All methods described in this section perform an analysis of the customer domain. In QFD, the object described by the "voice of the customer" is not specified. This means that the customer can express some requirements about the product features as well as about his own environment (in which the product has to work) or the required effects in this environment. Despite requirements clustering may help to solve this problem, the application of the QFD for PL definition still lacks of precision: a model representing a variety of the voice of the customer is not possible. Therefore the first formalisation of the variety is only possible on the technical side, according to the product description. This leads to a similar position with the discussed for marketing: an abstraction of the customer needs to obtain a characterisation of the set is not possible. A missing definition of does not allow assessing the proposed product variety. As mentioned in [START_REF] Liker | Lean Product Development as a System: A Case Study of Body and Stamping Development at Ford[END_REF], RE allows going much further than QFD. Actually, in SE a better definition of customer needs, customer requirements and system requirements are provided. Already in our initial work [START_REF] Giovannini | Mass Customisation in Sustainable Networked Enterprises[END_REF], we identified the gap according SE, describing the lack of precision in the definition of customer needs for current configuration systems. In the next section, an application of these definitions on the variety modelling is discussed. The aim is to identify how to formalise the variety in the customer domain (set ) and in the engineering domain (set ) and what is the nature of the knowledge formalised by the functions and g.

APPLYING THE SE CONCEPTS TO THE VARIETY MODELING

The proposed approach relates the PL concept to the definitions of System Engineering [START_REF] Pyster | A Guide to the Systems Engineering Body of Knowledge (SEBoK)[END_REF]) and concepts of system thinking (e.g. [START_REF] Jackson | Deriving Specifications from Requirements: An Example[END_REF]); the aim is to provide a formal definition of the sets and functions described in the section 2.

Basic terms from SE

The current section presents the SE concepts that relate, by means of their semantics, the person (generalisation of a customer -element of ) with the system requirements (elements of the product variety). The following definitions served as a basis for building the conceptual diagram in Fig. 5a.

According to SE terminology, the interaction between the person and its environment is moved by a purpose. The purpose represents "what the system is for, and why the different stakeholders are willing to participate in the system lifecycle" [START_REF] Blockley | Doing It Differently: Systems for Rethinking Construction[END_REF]. The person who participates to this relationships is a stakeholder, where stakeholder is defined as "a party having a right, share or claim in a system or in its possession of characteristics that meets that party's needs and expectations" (ISO/IEC, 2008). The definition of purpose matches the definition of real needs in [START_REF] Faisandier | Systems Architecture and Design[END_REF]: here the author defined as real needs those needs "that lie behind any perceived needs (defined below) and they are conditioned by the context in which people live". In the same paper, the author presents a diagram of the needs lifecycle (Fig 4) that shows the transformations from real needs to a set of consistent requirements. In this figure, real needs are related to stakeholder requirements by perceived needs, expressed needs and retained needs:

• perceived needs "are based on a person's awareness that something is wrong, that there is a lack of something, that there is something that could improve a situation, or that there are business, investment, or market opportunities" • expressed needs "originate from perceived needs in the form of generic actions or constraints, and are typically prioritized"; • retained needs " are selected from the expressed needs.

The selection process uses the prioritization of expressed needs to achieve something or make solutions feasible ". The retained needs represent the stakeholder intensions that still "do not serve as stakeholder requirements, since they often lack of definition, analysis, and possibly consistency and feasibility [..] RE leads stakeholders from those initial intentions to structure more formal stakeholder requirement statements"

(ISO/IEC/IEEE, 2011). Stakeholders requirements are "the requirements for a system that can provide the services needed by users and other stakeholders in a defined environment" (ISO/IEC, 2008). According to authors in [START_REF] Jackson | Deriving Specifications from Requirements: An Example[END_REF] the stakeholder requirements have to constraint the environment of the system, stating the expected effect on the environment caused by the interaction with the system. Stakeholder requirements are transformed by a RE process into system requirements. System requirements are defined as "the requirements for a system that can provide the services needed by users and other stakeholders in a defined environment" (ISO/IEC, 2008). A detailed analysis of the process for transforming stakeholders requirements into system requirements can be found in [START_REF] Bouffaron | Revisiting the Interoperation Relationships Between Systems Engineering Collaborative Processes[END_REF]. System requirements are collected in a system requirement model (SRM), as defined in the previous section. As system requirements, also stakeholder requirements are collected in an appropriate fashion (stakeholder requirements model -RM). This environment is different from the one of person i.e. the person can be part of the system environment. this latter includes "anything affecting a subject system or affected by a subject system through interactions with it, or anything sharing an interpretation of interactions with a subject system" (IEEE, 2002). The system here is the system whose life cycle is under consideration, named the System-of-Interest (SoI) (ISO/IEC, 2008). Fig. 5(a). shows the conceptual model expressing the main definitions from the previous section. Notice that the stakeholder requirements are the first statements really structured and consistent, in the customer domain.

The conceptual model for representing the right variety Customer and product variety

In order to define the sets and , let us now consider a SoI referring to a PL so that it has to describe a certain variety interacting with an environment now related to a customer segment (see Fig. 5b). A segment environment is related to more than one RM. Similarly the SoI is related to more than one SRM. Since a requirement is unambiguous and measurable (ISO/IEC, 2007) and a SRM models consistently a set of system requirements, a SRM can represent an element of the set . As for PLs (see section 3), a set of attributes can describe the variety and similarities between different SRMs: this variety can formalise the product variety (i.e. set ) for the customers segment. As analogy of SRM, the values related to a set of attributes describing the variety between the RMs will represent the customer variety, i.e. the set . This implies that the customer variety is defined by the characterisation of the system environment and the effects that the system has to provide on its environment. The difference between this definition of and the definition of the set concerns the feasibility. The stakeholder requirements are related to a feasible system (ISO/IEC/IEEE, 2011) therefore every RM has a correspondent SRM. The PL definition function Since the stakeholder requirements constraint the environment and the system requirements specify the SoI, the knowledge behind the PL definition function g (and consequently as inverse of g) allows relating attributes concerning the system environment and attributes specifying the SoI. Therefore it represents the knowledge of the interactions between the SoI and its environment. Since the function g is multivalued, more than one SRM can be found for a RM. In this section, we have defined the set , , and the definition function g on the basis of terms from SE.

KBS FOR PRODUCT LINES DEFINITION AND RATIONALISATION

In this section, we show how to involve the knowledge before defined in the definition or rationalisation of a PL. At this purpose, a knowledge base that uses the concepts just described is used as a core for a Knowledge Base System (KBS). The KBS inferences support the definition of the configuration function and therefore of the set , representing the right product variety for the PL. The first subsection of this paragraph discusses the KB formalisation by means of an ontology. The second subsection describes how the KBS support the definition and the rationalisation of a PL.

From the conceptual diagram to the knowledge base

Starting from the conceptual diagram just discussed (Fig. 5b), we define an ontology as the core of a KBS for the PL definition and rationalisation. The ontology has been formalised using a description logic (DLLite) [START_REF] Baader | The Description Logic Handbook: Theory, Implementation, and Applications[END_REF]. DLLite is based on the theory of sets and guarantees the decidability; therefore a verification of the consistency of the modelled artefact can be performed. Moreover DLLite is based on the open world assumption (OWA), thus the knowledge base can be easily extended. In order to translate the conceptual diagram into an ontology we used the mapping rules defined in [START_REF] Atkinson | A Detailed Comparison of UML and OWL[END_REF].

The key knowledge formalised in the ontology is about the function g, i.e. about the relationships between attributes representing customer variety and attributes representing product variety. As discussed in the previous section, this implies that the function g describes the interactions between the SoI and its environment.

In the ontology representing the KB, a class concerning the knowledge just described has been formalised: the class interaction. In this class, individuals describe the mathematical knowledge for calculating values of a required attribute, starting from values of the other attributes related to the interaction. The knowledge about interactions may come from physics, chemistry, experiments, personal experience, etc.. This class relates attributes describing the environmental expected effects and constraints with the system attributes (Fig. 6). The semantic difference between environmental expected effect and environmental constraints concerns the definition of the purpose shown in the previous section. Actually, a system purpose emerges whenever an unsatisfactory interaction between a person and that person's environment exists. Consequently a purpose represents something that the system, working in the system environment, has to change. This means that expected effects on the environment are derived starting from a purpose. On the other hand, environmental constraints represent something that the system, working in its environment, has to take into account as some perturbations. System attributes characterise the product variety. They represents what the system should do to get the environmental expected effects, respecting the environmental constrains.

For instance, we can consider temperature of a room as an environmental expected effect, the room usage and size as environmental constraints and the cooling system power as a system attribute. Interactions in the KB have to describe the mathematical relationships between the values of these attributes.

Environmental effects, constraints and system attributes are all related to the class attribute of the ontology. As discussed in the previous sections, every attribute is a measurable property. Every attribute can be related to different interactions and this relationship is characterised by a domain of validity. Returning to the previous example: if the knowledge contained in the KB is limited to temperature of 24, 25 and 26°C, these three values represent the domain of validity of the attribute along the considered interaction. In other words, if the system attribute is the power of a heating b f, g a system, for defined room characteristics, we know only this information related to maintaining the room temperature at 24, 25 and 26°C.

6.2.

Usage scenario for the KBS Fig. 7 shows the KBS usage scenario. The user selecting the purpose of the SoI in the system performs the first activity.

As shown in the conceptual diagram, the purpose for a customer segment is considered as unique. An example of purpose can be "maintain a good air quality in the room".

Algorithm 1 -interactions retrieval

The KBS retrieves the knowledge about the introduced purpose in the KB. If at least one correspondence is found, the algorithm1 checks for environment effects derived by the purpose. This algorithm builds a sort of tree of interactions. When an attribute is related to an interaction, the algorithm identifies the other attributes involved in the interaction.

Then, for each identified attribute, the algorithm retrieves interactions to which it is related and other attributes are identified. These tasks are iterated until an attribute is an environment constraint or, in the case of system attributes and environment effects, if there are no other interactions related to it. The result of the algorithm is a tree that has as roots the environment effects related to the purpose and as leaves the system attributes and the environmental constraints. Every attribute is related to a validity domain for the related interaction. According the example above, the algorithm would infer attributes on customer variety such as desired temperature, size of the room, usage of the room and so on. On the PL side, possible inferred attributes could be the power of the system, air-filtering features and so on.

When the tree includes alternative paths, more than one PL impacts the same purpose. This implies that a PL is defined by the attributes on the leaves of the tree. In other words, two PL can have the same purpose but cannot be addressed to the same customers segment, i.e. one PL for each customers segment. Returning to the example above, two different PL can affect the air quality in a room, but they can have different interfacing requirements with the environment, e.g. solar heating system, hydraulic system or cogeneration. In this case the customer variety is characterised by attributes that are completely different.

On one tree path built by the algorithm 1, the interactions represent the PL definition function g. The set of system attributes and their domain validity describe the variety in the product domain . The set of attributes for environment effects and constraints and their domain of validity define the variety in the customer domain, i.e. set . One element of or is a vector that has as component a value for each attribute describing the variety. The multivalued function g transforms a vector of system attributes representing a product variant into a vector of environmental effects and/or constraints representing the customer variety. The inference algorithm 1 is external to the ontology. This is due to the OWA. Actually we need to make design decision based only on the knowledge available at a defined time, i.e. condition on the end of iteration for the tree construction. For this kind of inferences, the closed world assumption (CWA) is required. An external algorithm manipulating the ontology can guarantee the CWA. Algorithm 2 -PL definition Starting from a customer segment characterised by certain features, the user should select a PL starting from the customer variety expressed by, i.e. environmental effects, constraints and related validity domains. The latter limits the environments in which the product variants can work for the defined purpose. For instance, if the attribute "room size" has an associated range of validity, this means that we are not able to propose variants that meet the purpose for room sizes outside of that range. Then the user can further characterise the customer variety defining the values for each attribute, i.e. environment effects and/or constraints. Only values inside the validity domains can be introduced. For instance, if it is known that there exists a minimum room size legally defined, the user can limit the domain validity of the related attribute. It is important to highlight that these characteristics allows determining a finite set representing the customer segment variety. Obviously, if the customer set is unbounded then an assessment of a limited PL variety is not feasible. Once the values for attributes of a customer variety are introduced, the algorithm 2 uses the interactions retrieved by the algorithm 1 for calculating constraints in terms of system attributes. These attributes limit the border of a space that represents the variety that the PL has to express in order to meet all requirements in the defined customer segment. Each system attribute and related validity domains represent respectively the dimensions and the limits of the space. Moreover, a validity domain for environmental effects and constraints can be characterised by a tolerance: the latter can allow making discrete a continuous interval; in each case, the space defined by the system attributes should be discrete. Notice that, on the product variety, a variant represents a physical object; therefore a product variety defined by continuous intervals would be nonsense. Even if limited, this space still does not represent the portion of the set defining the right product variety. Actually, represents the codomain and image (property 3) of the configuration function , where respects the property (2). To respect the property (2), the configuration function has to relate each customer with only one product variant. This implies that, in order to respect the property, only one product variant should be chosen. Since for the customer all these variants are equally fulfilling his needs, the most reasonable decision is to choose the best product variant for each identified environmental effect: for instance, an optimisation criteria could represent the lowest resource consumption for the development and the manufacturing of the related product. If the property (2) is respected, the set of product variants defined by system attributes and values represents the set , expressing the right product variety. Fig. 7 -Usage scenario for the KBS for PL definition and rationalisation Algorithm 3 -PL rationalisation When the aim is the rationalisation of an existing PL, the results of the algorithm 1 are used by another algorithm. This time, the user introduces values also for system attributes. These values represent the variety expressed by the existing product line. The algorithm 3 uses these values and the interaction in the tree to infer the coverage of the PL on the defined customer segment. The ranges of values for the attributes describing the customer variety define this coverage. Comparing these ranges with the defined customer segment, this algorithm allows to highlight lacks, redundancies and/or excess of variety in an existing PL: a lack represents a part of the defined customer segment that is not covered by the PL; a redundancy in the PL means that it is possible to identify more than one variant for a distinct customer; an excess of variety represents a part of the PL variety that cover customers outside the customer segment defined by the user.

CASE STUDY

In this section, an application of the proposed approach is presented. The aim of this case study is to show how the KBS should handle domain knowledge in order to rationalise the product variety.

The case study presented in typical of the major part of companies producing mature products, where the revenue is strongly dependent on scale economies more than on innovation lips. In such a kind of scenario, the careful definition of tacit and explicit customer requirements became a critical asset for revenue margins. The challenge for any company in mature market scenario is to increase the worthiness of money spent by customer, by providing satisfaction of the tacit customer's expectations in terms of product quality and reliability, while maintaining a high level of profitability. The mass craftsmanship paradigm is here thus implemented by applying the methodology proposed to solve this apparent contradiction.

KBS scenario

The KBS should allow the selection of a purpose for the PL.

The analysed PL has as purpose the "room air-cooling". In the KB, this purpose is related to some attributes representing the desired environmental effects for cooling the room, i.e. the room temperature. The algorithm 1 defines a tree of interactions for this attribute. The retrieved equations are the following:

Notice that more than one attribute can be related to the selected purpose; this should not affect the algorithms effectiveness. The tree has no alternative path and the attributes on the customer side (i.e. environmental effects and constraints) are: the room temperature ( ), the fluid type ( ), and input output temperatures ( , ), the static pressure ( ) of the duct and the power ( ) to be provided to the room depending on building features and the room usage. The attributes on the engineering side (i.e. system attributes) are the fan /air flow characteristic ( ), the air velocity ( ), the external coil surface ( ), the internal coil surface ( ), the number of coil rows ( ), the coil air heat exchange ( ), the coil fluid heat exchange ( ), the fin efficiency ( ), where the last three properties are the result of the interaction of the water and air flows with the coil geometry. The user has to characterise the customer segment introducing a range of values for each environmental constraint and effect. For instance we can consider 21°-25° C for the room temperature; only water as cooling vector (fluid) type; 5-12 °C for fluid input temperature and 10-17°C for output fluid temperature; 0-60 Pa for environment static pressure; 0.5-10kW for sensible power. Starting from the retrieved equations and ranges of values, the algorithm 2 should limit the values of the system attributes. In this case, considering the attributes range for static pressure ( ) (0-60 Pa) range of values, it is possible to add two more constraints to the retrieved equation , where Q is the airflow rate and k is the corrective constant depending on the fan type. Let us consider for a moment this interaction as the only one in the tree. This means that the environmental constraint can be fulfilled by couples of values for the airflow and the fan type. From the customer point of view, the choice of two couples of values generating the same static pressure makes no differences. Therefore engineers have to choose only the best one (e.g. on the basis of economic reasons) in order to preserve the property (2), i.e. one variant for each customer. Defining a tolerance values for the environment constraints and effects (e.g. for ), the constraints can support the definition of discrete intervals of system attributes and consequently a finite number of product variants. Variants should be selected defining some optimisation criteria to the defined constraints. The algorithm 3 for the PL rationalisation requires also the system attributes to be filled. Here the user has to describe the existing PL variety according to the inferred system attributes. The algorithm 3 should use the interactions retrieved by the algorithm 1 for projecting the PL variety on the customer segment. The algorithm should highlight lacks, excess and/or redundancies in terms of values for the static pressure, the room temperature and so on. The object of the case study is inspired by the works on the Trane fan-coils PL, named UniTrane TM FCD (Fig. 8). Trane is a company that designs, develops and commercialises heating and cooling systems. For confidentiality reasons, the knowledge we use to instantiate the ontology is not coming from the Trane PL, but the domain knowledge in (American Society of Heating, 2012) is used to show how the KBS should perform in this scenario. Fan-coils, as defined in their name, are products made by two main components: the coil is connected to the pipe circuit of the building; generating a resistance at the fluid flow, the coil transfers heating or cooling power from the fluid in the pipe to the air flow on the internal part of the fan-coil unit; a fan, connected to a suction and an injection duct, feeds this flow and allows the power transfer between the coil and the room that has to be heated or chilled. , where is the sensible cooling capacity of a coil, is the overall coefficient of heat transfer for sensible cooling (without dehumidification), is a coil shape coefficient, is the coil face area, is the coil rows number, and are the input and output air temperatures, and are the input and output fluid temperatures. In the ontology, this is an individual belonging to the class interaction. All variables in the formulas represent the attributes related by the interaction. Each attribute is marked as being an environmental constraint (customer variety), an environmental effect (customer variety depending on the purpose) or a system attribute (product variety). In the formula above:

, , , and are system attributes, is an environmental effect (approximation of the room temperature), is a system attribute and the fluid temperatures (

) are environmental constraints.

CONCLUSIONS AND PERSPECTIVES

In this paper an approach for the rationalisation of the product variety has been presented. Initially, a formal definition of the requirements for the rationalisation is proposed. Related concepts have been identified by means of a conceptual model based on system engineering (SE) terminology: customer has been represented as environment and the relationship with product as an interaction between the system and its environment. Concepts have been formalised and extended in an ontology for representing PL definition knowledge. Finally a scenario of usage for this ontology in a knowledge-based system (KBS) has been shown.

The whole approach defines a brand new point of view on product variety. In literature it is usually seen as a source of complexity for manufacturing, planning and scheduling systems. Several works are focused on how to cope with this complexity. In this paper we dealt with the customer variety, representing the causes of the product variety and consequently of this complexity. Linking the product variety with the customer domain, we showed that a system for defining only the rationalised PL variety can be defined. On the manufacturing side, the aim is to delete the unjustified variety and therefore to reduce the unjustified complexity. On the customer side, the aim is to define configuration systems that do not require a product-related knowledge for configuring the right product.

It is important to highlight the consequence on the configuration systems discussed. On one hand these are completely customer-oriented: the customer is asked to describe its environment and what he expects from the product. On the other hand, all optimisations in configuration system (e.g. price) are moved on the engineering side: a customer should represent a problem; only on the engineering side, appropriate algorithm can be deployed to identify the best solution (e.g. from a resources consumption point of view). Future perspective of the present research concerns the development of the algorithms to finalise the structure of the KBS. A larger KB, even with knowledge from different domains, will be used to test the algorithm two. Moreover a more complex PL will be treated: according to the presented approach, the more complex the system-environment interactions are, the more complex is the implementation of the approach. Finally, an integration of this work with the proposal in [START_REF] Giovannini | Ontology-Based System for Supporting Manufacturing Sustainability[END_REF] will be envisaged; the aim is to take into account the PL variety in an enterprise network.

9.

Fig. 2 -

 2 Fig. 2 -An holistic view of PL design and development,adapted from[START_REF] Jiao | Product Family Design and Platformbased Product Development: a State-of-the-art Review[END_REF]

Fig. 4 -

 4 Fig.4-Needs lifecycle[START_REF] Faisandier | Systems Architecture and Design[END_REF]

Fig. 5 -

 5 Fig. 5 -Conceptual models of discussed SE terms (a) and PL variety (b)

Fig. 6 -

 6 Fig. 6 -excerpt of the KB formalised in Protégé (Protégé)

Fig. 8 -

 8 Fig. 8 -Picture showing a variant of the Trane fan-coils PL