System Sizing with a Model-Based Approach: Application to the Optimization of a Power Transmission System

. We test the relevanceof a model-based approach for sizing and optimizing complex systems. Classically a model-based approach is characterizedby a clearpartition betweenthe problem description and thesolving process. In the caseof a design problem, we show that the sizing task could be systematically characterized and therefore could lead to a declarative model combining both system description and design requirements. Once translated into a constraint satisfaction problem, the resulting model can be solved with interval constraint programming methods and algorithms. Our first contribution to this approach is to precisely characterize the sizing task in design. The resulting terminology enables us to easily and systematically express the problem as a constraint satisfaction problem (CSP) which combines in the same model the system description and the design requirements. We have tested the approach on the optimal sizing problem of a power transmission system. Previous authors have described this scalable case study. They provide a mathematical formulation of the problem and solve it with an evolutionary algorithm. Starting from their description, we apply our methodology to model the problem as a CSP and then solve it with interval constraint programming algorithms. Our solutions are more adequate both in computational time and in optimization results than those published in the literature on the same problem. Moreover the declarative nature of constraint programming makes modifications or extensions easier than with evolutionary programming. The explanation of these results is our second contribution to the approach. However some important modelling issues remain to address in order to capture more and more complex system specifications. Further research is presented at the end of this paper.


Introduction
Following Pahl and Beitz [1], the design process can be divided into three main phases: conceptual design, embodiment design, and detailed design.
In this paper, we will focus on the embodiment design phase which is the first phase requiring calculus. More precisely, we intend to split the embodiment design phase into two subphases that will be called architectural generation and system sizing.
Broadly speaking, architectural generation fixes the structure of the system, i.e., the type and number of components used in the system building. System sizing focuses on setting the value of each physical and technological parameter.
Nowadays, virtually all products can be considered as systems. They are made up of components which are connected together and some components are themselves subsystems.
The resulting system has to fulfil the requirements deriving from the conceptual design phase such as physical performance. In the case of technical products, many other types of requirements matter like technological, normative, or even legal constraints.
The current paper lays emphasis on the use of computational methods for modelling technological system and for solving the system sizing problem.
This paper revolves around four chapters. The first offers to apply a model-based approach for system sizing. The second explains the scientific paradigm used to support our 2 Mathematical Problems in Engineering model-based system sizing method. This paradigm is known as constraint solving. The third presents the tool used to carry out this study and the last chapter is dedicated to the scalable case study of the sizing problem of a power transmission system.

System Sizing with a Model-Based Approach
In this chapter, we will point up a particular design phase which is commonly called "sizing". Putting it in informal terms, sizing a system is aimed at fixing its design in order to produce performances which will both fulfil the physical and technological constraints and meet the customer's requirements.
Over the last years, many authors have pointed out that the art of design can be considered as a kind of problem solving task [2] which relies heavily on all kinds of knowledge. In this perspective, the field has been widely investigated by Artificial Intelligence researchers. A lot of various reasoning techniques have been experimented on design applications such as rule-based, case-based, or model-based reasoning [3,4].
Broadly speaking, rule-based systems better suit expert knowledge while case-based systems are more suitable to experimental knowledge and model-based reasoning suit better with knowledge of the physical world. In the following, we will narrow down the study to engineering systems. These systems are artefacts which follow the laws of the physical world; therefore using a model-based reasoning approach for designing them, particularly for sizing them, stands to reason.
A model-based reasoning approach puts emphasis on the development of an abstract model which represents the system. This model offers a basis for any kind of reasoning underlying the system; the reasoning task is processed by an "engine" dedicated to intended task (planning, diagnosis, sizing, etc.). This engine combines the model knowledge with additional data to derive the results required.
Many kinds of models may be used. Their choice depends both on the application domain and on the intended task. Previous works in various technical fields [5,6] helped us to set some minimal characteristics of the models which are to be used for sizing and optimizing engineering systems.
Firstly these models must be quantitative because most parameters are continuous in engineering. Secondly, the appropriate behaviour of the targeted system has to be described. It may be (behaviour over time) dynamic behaviour or steady-state behaviour. Practically steady-state models are already of a great interest in design especially in preliminary design; hence we will limit our study to these hereafter. Thirdly we will set out some technological or regulation constraints applying to the system. Finally we will lay down the customer requirements that the system is required to fulfil. To summarize we need to build a quantitative model of the problem to solve (i.e., sizing or optimizing). This problem model is the combination of the steady-state model of the targeted system, the technological and regulation constraints model, and the requirements model.

Sizing Model Specification.
Before giving further details about the structure of sizing models, let us now introduce some terminology that will be used further down. Many researchers in preliminary design [7,8] represent the knowledge related to the product to be designed by using a set of typed parameters. It stands to reason that apart from types, parameters can be characterized by many other attributes such as dimension, unit, type of value, range of value, and so forth and some of them, especially dimension and unit, are very important design modelling characteristics but they are beyond the scope of the present paper. Focusing on the type, we observe that the number, name, and above all the semantic of the considered types depend on the authors. X. Fischer in his Ph.D. Thesis [9] makes a typical proposal based on 3 kinds of parameters: the "design parameters", the "physical parameters", and the "objective parameters". Their semantic is informally defined as follows. The "design parameters" are related to the structural description of the system and its conceptual definition. The "physical parameters" are related to the physical behaviour of the system. The "objective parameters" are performance indicators which enable one to validate the quality of the design. This proposal is completed by an additional classification of parameters in known parameters (i.e., with a value) and unknown parameters. In a model-based approach, such a product description is destined to be translated into a mathematical model. We propose to refine the above model as follows by considering 4 types of elementary concepts: (i) Unknown design parameters (ii) Unknown physical parameters (iii) Objective parameters (iv) Known parameters Known parameters are translated into any kind of constant; in an obvious way, unknown design parameters are translated into Design Variables and unknown physical parameters are translated into Behavioural Variables.
Objective parameters will not be translated into variables but in criteria functions of some design or Behavioural Variables which will be called performance indicators.
Finally Table 1 summarizes the new classification. Let us give some examples in the field of mechanics. Assuming we have to design a mechanical product, (i) geometrical dimensions or material characteristics will be expressed with DVs; (ii) forces, movements, and energies will be expressed with BVs; (iii) total weight and whole cost will be expressed with PIs.
Moreover, sizing models are not only made up of constants and variables but also of relations. Many relations of different nature connect both DVs and PVs through a set of Mathematical Problems in Engineering 3 (i) equations expressing the laws of physics (e.g., conservation laws); (ii) inequalities expressing technological limitations (e.g., elastic limit) or regulation constraints (e.g., "minimum of two independent power sources in the system"); (iii) inequalities or optimization criteria expressing customer requirements (e.g., range min, mass minimization).
Finally a sizing model is a set of equations and inequalities linking together Design Variables and Behavioural Variables as it presents some significant characteristics: (1) the set of equations is usually nonlinear; (2) the number of inequalities can be greater than the number of equations; (3) the model combines continuous and discrete variables.
Indeed, most of the equations which are part of the model express physics laws which are nonlinear; therefore the whole model itself is usually nonlinear. In engineering domains, the number of technological limitations or constraints of conformity to standards is ever increasing. In many models, some Design Variables related to technological parameters are discrete either intrinsically (e.g., the number of teeth of a gear wheel) or because of standards (e.g., normalized screw diameters).

Sizing Task Features.
Following the previous definition of Design Variables and Behavioural Variables, sizing the system consists in finding an assignment of Design Variables and Behavioural Variables such that (1) the assignment of Design Variables determines the structure of the system; (2) the assignment of Behavioural Variables determines the behaviour of the system; (3) the whole assignment is consistent with all the elements of the sizing Model.
In classical engineering fields, most system behaviours are deterministic and ruled by a mathematical system of "n" behavioural equations and "n" unknown variables. These variables correspond to the Behavioural Variables in our terminology. Therefore finding the behaviour consists in solving a square system of equations. A number of more or less sophisticated mathematical methods are dedicated to this solving problem which remains intrinsically difficult especially in the presence of nonlinear equations. The task addressing the rendering of behaviour is a "simulation" task. This terminology mainly refers to dynamic behaviour that will also use it hereafter for stationary behaviour. Simulation can be and is effectively used in design, especially during the detailed design phase in order to check on the appropriate behaviour of the final product with respect to the requirements. However in earlier design phases (preliminary design, embodiment design) an important part of the problem is to determine the system structure of the future product itself. The task addressing this point is a sizing task. For a sizing task the number of behavioural equations remains the same but the number of unknown variables increases with the addition of some Design Variables to assign. Hence, we no longer obtain a square system but an underconstrained system of equations to solve. Therefore sizing a system is generally much more difficult than simulating it! Since the system is underconstrained, many solutions to the problem can be found out. Therefore it is worthwhile to use optimization criteria in order to come up with the ultimate solution amongst all the solutions of the "design space". It is important to notice that in such a search space solutions can radically differ from each other; therefore the optimization process has to be as global and exhaustive as possible in order not to be trapped in a local optimum.

Overview of Existing Methods and Tools.
A range of numerical tools are used in engineering. Our purpose in this paragraph is to make a survey of some of the most popular software tools currently used by engineers for their preliminary design studies. For each tool or type of tool, we will investigate whether their mathematical solving methods can suit or not the sizing task.

Simulators.
Simulators are more and more widely used in the study of systems. Many products with attractive user interfaces are hence available in various engineering domains (e.g., Simulink, Saber, AmeSim, and Modelica) and recent advances in modelling (multiphysics, higher level modelling language) aim at positioning them as favourite tools for system design and architecture evaluation like Modelica [10], one of the leading tools in the field. However the underlying characteristics of Modelica have remained since the beginning and are still available in the outset versions of the language, precluding the related tools from matching the sizing task. Indeed since both language and computational process are simulation task oriented, (1) only square systems of differential and algebraic equations are solved; (2) inequalities are not taken into account during the solving process.
Item (1) implies that the parameters you need to set in order to run a calculus are precisely the design parameters you want to compute. Item (2) implies that the solutions which are computed can be false solutions regarding the numerous technical and customer requirements which are laid down in terms of inequalities.

Optimizers. Amongst the commercial Analysis and
Decision tools, Excel is certainly one of the most widespread. This success can be explained by the large distribution of the Office Suite in companies. In particular, numerous design engineers resort to Excel as a convenient desk calculator that offers great functionalities to set out their work results. Regarding the engineering problems the basic solving capabilities of the calculus sheets (formula evaluation and iterations for the case of circular references) are inadequate; therefore Excel provides a solver as a complementary macro.
The solver of Microsoft Excel uses 2 optimization codes: (i) a mixed linear programming code designed and commercialized by Frontline Systems, Inc.; (ii) a nonlinear optimization code GRG2 ("Generalized Reduced Gradient") designed by Leon Lasdon, Texas University Austin and AllanWarren, Cleveland University.
GRG2 is the code that best matches engineering problems.
Unfortunately it shares the drawbacks of all iterative convergent methods: A good starting point has to be chosen in the search space and if the method converges, a local optimum is obtained. As explained above, the context of solving in a sizing task goes in the other direction: the structure of the search space is unknown and we search for globally optimal solutions. This kind of algorithm is available in the Matlab Optimization toolbox and is the most commonly used by engineers too. The case of stochastic algorithms like Genetic Algorithms available in Matlab too will be discussed later in the fourth part of this paper.
Apart from mathematical programming methods, namely, linear programming or gradient based nonlinear optimization, other types of numerical methods can be investigated to solve engineering sizing problems. We will focus hereafter on the use of constraint programming methods and more specifically of interval constraint programming. Constraint programming is a solving paradigm which combines an original solving approach with a problem description model called constraint satisfaction problem (CSP).

Constraint Solving Approach
Unlike iterative methods which start from an initial point and then build series of points converging towards a solution, the solving approach is based on the idea of exploring the whole search space. This approach has been initially developed for solving combinatorial problems [11]. Since these problems have a finite search space, it is theoretically possible to generate (i.e., enumerate) each potential solution and test whether or not it is a solution or not. This general "Generate and Test" method naturally leads to a first solving algorithm scheme which is in fact an exploration algorithm. Unfortunately this algorithm is computationally intractable whenever the size of the finite search space is huge. For this reason, the constraint programming community has developed numerous sophisticated methods for reducing the search space in order to avoid costly space explorations. The more advanced solving methods combine exploration methods and reduction methods. Developing a reduction method requires defining and maintaining the variation domain of all problem variables. Domains are reduced by various consistency methods which eliminate sets of values from domain variables which are inconsistent with the problem description [12]. Reasoning on variation domains in order to approximate the set of solutions characterizes the constraint solving approach.

Constraint Satisfaction Problem (CSP).
The problem description model is called CSP in constraint programming. A CSP [13] is usually defined by a triplet <X, D, C> where X is a set of variable, D is a set of domains, and C is a set of constraints and A relation should be any kind of mathematical linear or nonlinear equations, inequalities, logical formulas, and so forth.
As an example, let us study the following short CSP: A solution of a CSP is an assignment of all variables such that all constraints are satisfied. For instance, the unique solution of the above CSP is This solution can be interpreted as an elimination of values from domain variables: This global domain reduction proceeds from the application of CSP constraints which implement a local way to reduce the values of the variables. Following the current CSP example, (i) from x1<x2, we eliminate 1 from D x1 since there is no value of D x2 consistent with and then D x1 becomes {0}; (ii) from x1 ̸ =x2, we obviously eliminate 1 from D x2 and then D x2 becomes {1}.
After the reduction process, we have to enumerate the reduced search space. In our example, it is easy to check that the unique potential solution <x1, x2> = <0, 1> is a solution.
At this stage, it is worth noticing that a CSP is fundamentally a logical model expressed as a set of logical properties. In particular in a CSP model, Mathematical Problems in Engineering 5 (i) the order of constraints does not matter; (ii) constraints are noncausal properties; (iii) solving a CSP offers some logical guarantees such as proving there is no solution, finding all solutions or finding globally optimal solutions.
On the one hand, constraint programming provides a natural way of writing problem descriptions without requiring any kind of rewriting.
On the other hand, the overall impact of constraint solving naturally suits the sizing task, i.e., finding all solutions in the design space and globally optimizing the design.
However, we have to keep in mind that this global nature has a negative effect on the computational complexity of calculus methods. In particular, constraint solving methods are much more time and memory consuming than local iterative convergent methods. Therefore, the applicability of such methods on real engineering problems remains to prove since most papers focus on short scale problem solving [14].
Finally, it is important to point up that the constraint programming framework can be adapted to various calculus domains like finite, Boolean, rational, or real domains.

Interval Constraint
Programming. When real variables are considered, the domain is called interval constraint programming. The global approach remains the same as in constraint programming but domains are replaced by intervals and constraints and therefore domain reductions are developed from methods based on Interval Analysis [15] while search space methods are based on subboxes or subpavers exploration. The resulting interval solvers aim at finding all solutions of sets of nonlinear equations and inequalities or at finding a global optimum. This is called a Numerical Constraint Satisfaction Problem (NCSP).
We have decided to choose Constraint Explorer for our case study. The main reason for this choice is that unlike most of the other available tools which are general numerical solvers, Constraint Explorer has been specified with the aim of offering a design tool. This has led to software development presenting some characteristics which are relevant for our modelling and optimizing purposes and will be laid down hereafter. [6] is a software tool which is the major result of the CO2 project, a research project granted by the French Ministry of Research in 2002. It has been specified for modelling, sizing, and decision making in design.

Overview. Constraint Explorer
Constraint Explorer addresses design problems that can be expressed by a set of relations on integer or real variables. These relations are either equations or inequalities; they can be linear or nonlinear. Expert rules supplement the language in order to dynamically store in the model additional relations which are expressed in the right-hand side of the rules and activated according to the logical state of left-hand side conditions. Constraint Explorer supplies numerical algorithms based on solving methods supplied by the numerical constraint programming community.
Most of the functionalities are available through a graphical user interface (cf. Figure 1).

Modelling with Constraint Explorer.
As explained above, the language for modelling a CSP in constraint programming is the <V, D, C> model. The first experiments with various engineering problems have pointed out that this model was too poor for efficiently describing industrial design problems. If we make a kind of comparison between constraint programming and classical programming, we could say that <V, D, C> is closer from a low-level machine language than from a high-level end-user language. The Constraint Explorer language has extended this model in order to increase the power of expression and then to make the design problem solving easier. The most important features are (i) the introduction of constants as primitive elements of the model like variables or constraints; (ii) many types of variables depending on the nature of their variation domain: real, integer, enumerated integer, and enumerated real; (iii) declaration of functions, e.g., f( x, y) fl ( x+ y)/2; (iv) declaration of aliases, e.g., #m ab fl f(a, b); (v) declaration of matrix and matrix calculus.
is naturally expressed in the Constraint Explorer modelling language: Constraints building can use all these elements either to express equations or inequalities built from sophisticated mathematical expressions or to express n-ary user constraints built from an extension table of valid n-tuples, i.e., the set of all consistent values.
Moreover, additional syntactic sugars like n-ary sums and products operators for expressions, iterators for constraints, or meta-constraints like rules complete the language and still increase its modelling capabilities.

Solving with Constraint Explorer. The solving techniques implemented in CE rely on a branch and prune algorithm.
Pruning is provided by recent interval constraint consistency techniques (namely, Hull and Box consistency [20]). Branching allows you to explore the search space by bisecting the variable domains.
We can roughly distinguish three steps in the branch and prune algorithm: (1) Application of contractors (or reduction operators) that prune the domain variables over a single constraint.
(2) Propagation of the domain reduction from constraint to constraint until a fixed point on intervals is reached.
(3) Application of a bisection algorithm to exhaustively explore the design space.
Let us describe the branch and prune algorithm on a system with a nonlinear constraint: x + y = 50 x * y = 400 length is greater than the required precision, we bisect the domain and start a similar domain reduction on the left and right subproblems. The algorithm ends when no more bisection is possible. In our example, the left subproblem (x ∈ [10, 25]) leads to the first solution x = 10, y = 40 and the right subproblem (x ∈ [25,40]) leads to the second solution x = 40, y = 10. This example illustrates the essential property of this algorithm which is called completeness: no solution of the problem is lost.

System Description.
Let us apply those concepts, methods, and tools to our test case: the sizing of a three-stage power transmission mechanism. The goal of such a mechanism is to transmit a power and modify the ratio between the input speed and the output one (this is called the reduction ratio). This object should be modelled as a system. It can be decomposed into an input shaft and three interrelated subsystems called stages. Each of those subsystems is an aggregation of three interrelated parts (or components) (cf. Figure 2).

Overall Description.
As we said previously, a multistage transmission mechanism is a complex system. It should be split into an input shaft and several stages. Each stage should be first modelled as a component and interactions between components have to be expressed. Finally, global relations and geometrical (closure conditions) as much as technological ones (required reduction ratio) have to be modelled.

Design Variables.
Each stage of the transmission system is defined by seven design parameters: an angle, a module, the tooth number of the pinion, the tooth number of the wheel, a shaft radius, and a shaft length ( Table 2). As soon as the 3 x 7=21 Design Variables are valued under constraints, the system is fully defined. We should add two other Design Variables, i.e., the radius and the length of the input shaft of the mechanism.

One-Stage Description.
As we mentioned above, each stage has three elements: a pinion, a wheel, and an output shaft. This model includes local level constraints such as the equations describing each stage or each gear. We should find in annex A the nomenclature of the product. Let us recall the constraints of one stage [21]: (i) Acceptable maximum transmission powers with the surface pressure and the rupture of the teeth: We should find in Appendix B the expression of C 1 , . . .,C 6 and C B1 , . . .,C B6 .
(ii) Condition on the transverse contact ratio:

2
. tan (9) (v) Limit on the value of the face width compared to the diameter of pinion and wheel: (vi) Noninterference between shaft, pinion, and wheel (cf. Figure 3): (vii) Noninterference with the casing box (cf. Figure 4): y i x i z y y y y y y y y y y y y x x x x Geometrical Consistency and Global Relations (i) Speed ratio: (ii) Closure conditions (cf. Figure 5):

Design
Requirements. The main requirements are to size the components and to set them together in order to transmit a given power in a given reduction ratio u r with a tolerance Δu r and minimizing the space required for the system in overall dimensions. Obviously we need to satisfy the power transmission P min , the reduction ratio u r , and the tolerance Δu r requirements.

5.1.6.
Optimizing the Volume of the System. The goal is to minimize the overall volume of the mechanism defined as follows:   The comparison of this model with the related mathematical inequalities described beforehand illustrates the fact that the translation effort is minimized.

Problem Solving with Constraint Explorer.
Once modelled, the problem remains to be solved. As explained above, the solving method of Constraint Explorer is based on a generic branch and prune algorithm that combine space search reduction methods (pruning) with space search exploration methods (branching). The space search exploration consists in bisecting variables whose domain is not reduced to a value. It is well established that the choice of the variables to bisect may have a major impact on the performance of the branch and prune algorithm [22]. In order to improve its performance, Constraint Explorer may propose various heuristics for ordering variables which do not fall into the scope of the present paper and therefore will not be described here. However concerning the current power transmission problem, one must underline that all results and performances which are presented hereafter are issued from a static variables ordering that makes use (1) of the system architecture: in particular it is stage composition; (2) of the type of the variables: integer variables are bisected before enumerated variables and enumerated variables are bisected prior to real variables.
Therefore in a given stage, the pinion tooth number, the wheel tooth number, and the module value are bisected in this order.

Results and Validation.
We would now like to illustrate our approach with a set of numerical results. The initial domains given by the expert for the constraint variables are presented in Table 3  Δu r = 0.01, and after the first propagation, the intervals are reduced as in Table 3 column 2.
The solving process (i.e., a branch and prune mechanism) ends on a first admissible solution presented in Table 3 column 3. The last step gives an optimal solution as shown in Table 3 column 4. As a result, we found an optimal solution with f obj = 8.1 10 6 mm 3 . Calculations took a computing time of two-and-halfminute computing time on a Intel(R) Pentium(R) M 1.6GHz 512Mo RAM and a process time of 50 seconds on a Dell Optiplex 740 AMD Athlon Dual Core Processor 5400B 2.81 Ghz, 1.93 Go de RAM.
We checked the validity of those results in two ways: (i) We implemented a dedicated C code to measure the differences between the values of the design and performance variables given by CE and those processed in the C program by the instantiated formulas. The maximum difference is approximately 1e-12, which means that CE seems to be quite a robust solver.
(ii) We built a working drawing to check the closure and noninterference conditions of the instantiated mechanism.

Comparing with Other Approaches.
Usually, a constrained optimization problem on mix variables as the power transmission one is modelled as follows: = ( 1 , 2 , . . . , ) a set of variables. The value of each should be in R or in Z.
: R × Z − → R a scalar f unction to minimize (25) such that  [23,24] can be used to find the global optimum. Moreover, when f is a quadratic function, the right way is to use Mix Sequential Quadratic Programming (SQP) algorithms [25]. Unfortunately a lot of functions are nonlinear in the engineering field. MLP and SQP should take account of such functions by increasing the number of variables in the problem. On the one hand, however, this increases the complexity while users, on the other hand, have to make specific transformations to set a nonlinear problem into a linear or a quadratic one if possible. Thus, particularly in the case of design problems, the structure of the initial model (i.e., the nonlinear equations and inequalities) is lost.
In technical literature, the main approach to design problem solving is the evolutionary (genetic) algorithm method. Fauroux and Lafon [18] implemented and applied a Genetic Algorithm to solve the problem addressed in this paper. Although Genetic Algorithms are actually most useful we would like to focus on two key points: On the one hand, the capability to find the global optimum depends on the crossing operators used, the frequency of mutation tuning, and the simulation duration. On the other hand, the and h j functions are mainly integrated as penalty functions (i.e., within the objective function) and in this case again, the structure of the design problem is lost.
Moreover, in such an approach, it is necessary to study the set of equations and inequalities of the problem to minimize the number of variables by doing substitutions of variables and rewriting of expressions. This is not the case with the CSP approach because the lack of a declarative and modular modelling language negatively impacts software maintenance and upgrading. As a consequence, the capability of models capitalization is very weak.
Although stochastic methods seem to be easy to program, in counterpart the computational performance is poor and the related optimization process is nonglobal with a reasonable finite time.
By way of example, [18] implements a final objective function as follows: where is a penalty factor, progressively increased during the resolution. Moreover, the system of equations and inequalities is simplified manually. The aim is to remove all the Behavioural Variables from the problem. As a result, the authors found an optimal solution with = 3.74 10 7 mm 3 . It took 45 min computer time to work out the calculations on a HP PA-RISC 8600 750 MHz.

Conclusion
We have shown that specifying a design sizing problem is possible with a model-based approach using constraint solving technology.
Our proposal consists in two main points: A specification of system sizing problem based on a dedicated terminology: Design Variables, Behaviour Variables, and Performance Indicators.
An efficient modelling and solving process combining model-based approach and constraint solving paradigm.
The application of our model-based approach to a power transmission system has shown that it is possible to successfully apply this approach to a scalable problem and with good results. More precisely, they are better than those obtained with a stochastic one (i.e., with Genetic Algorithm) in terms of both performance and quality. Moreover the problem model does not require any kind of tedious rewriting. Requirements are naturally expressed and added to the model as inequalities.
Constraint modelling gives us a chance to start defining a language accounting for both system description and elicitation of needs. Nevertheless, there remains a gap to address engineering needs. Even if equations and inequalities are directly translated, the structure of the system (i.e., components structure and relations between components and subsystems) is lost. A work is in progress to define a new higher level structured modelling language for design problem specifications.

A. Nomenclature of Parameters and Variables
Requirements

Data Availability
The problem we addressed is fully described inside this manuscript. That is to say, all variables, equations, and inequalities of the problem are available inside this document. Readers can use this data as they want.