A specification language for problem partitioning in decomposition-based design optimization

The starting point of decomposition methods is the system design problem in integrated form: where z = [z ₁,...,z _n ] is the vector that contains the design variables of the entire system. Response variables \(\mathbf{r}=[r_1,\ldots,r_{m_\text{a}}]\) are intermediate quantities computed by analysis functions \(\mathbf{a}=[a_1,\ldots,a_{m_\text{a}}]\). These response variables are also known as coupling variables. With r = a(z,r), we mean to express that each analysis function a _i for response r _i may depend on the other responses r _i |i ≠ j, i.e. r _i  = a _i (z,r _j |j ≠ i). The response r _i may not depend on itself. \(\mathbf{f}=[f_1,\ldots,f_{\text{m}_\text{f}}]\) is the vector of objective functions, and constraints \(\mathbf{g}=[g_1,\ldots,g_{\text{m}_\text{g}}]\) and \(\mathbf{h}=[h_1,\ldots,h_{\text{m}_\text{h}}]\) are the collections of inequality and equality constraints, respectively. Although the majority of the coordination methods do not allow multiple objectives, we do so here for the sake of generality. We refer to the above formulation as integrated since it includes the variables and functions of all disciplines in a single optimization problem.

The purpose of partitioning is to distribute the variables and functions of the integrated problem (1) over a number of subproblems. These subproblems are typically mathematical entities that perform (possibly coupled) analyses, evaluate objective and constraint values, or solve optimization problems. The subproblems may therefore (partially) differ from the original disciplines from which the integrated problem was synthesized.

Three partitioning strategies are often identified (Wagner and Papalambros 1993): aspect-based, object-based, and model-based partitioning. Aspect-based partitioning follows the human organization of disciplinary experts and analysis tools. Object-based partitioning is aligned with the subsystems and components that comprise the system. Model-based partitioning relies on mathematical techniques to obtain an appropriately balanced partition computationally. Model-based partitioning methods often rely on graph theory or matrix representations of problem structure (see, e.g., Krishnamachari and Papalambros 1997; Michelena and Papalambros 1997; Chen 2005; Li and Chen 2006; Allison 2007, for examples of model-based partitioning methods).

Partitioning problem (1) requires a distribution of all variables and functions over a number of subproblems. To this end, the variables z are partitioned into M sets of variables \(\overline{\mathbf{x}}_j\) allocated to subproblems j = 1,...,M, and a set of system-level variables \(\overline{\mathbf{x}}_0\). Each set of subproblem variables \(\overline{\mathbf{x}}_j=[\mathbf{y}_j,\mathbf{x}_j,\mathbf{r}_j,\mathbf{r}_{mj}|\min\mathcal{N}_j]\) consists of a set of local design variables x _j associated exclusively to subproblem j, and a set of shared design variables y _j and response variables r _j and r _mj , \(m \in \mathcal{N}_j\). Here, \(\mathcal{N}_j\) is the set of neighbors from which subproblem j requires analysis responses, and r _mj is an auxiliary variable introduced at subproblem j for the responses received from subproblem m. The set of system variables \(\overline{\mathbf{x}}_0\) contains the system-level response variables r ₀.

Some of the shared variables y _j and all coupling responses r _mj are auxiliary variables introduced for decoupling the optimization subproblems. Interactions between the various shared and coupling variables are defined in a set of consistency constraints \(\mathbf{c}(\overline{\mathbf{x}}_0,\overline{\mathbf{x}}_1,\ldots,\overline{\mathbf{x}}_M)=\mathbf{0}\), where it is understood that these constraints depend only on the shared variables and coupling responses. For further details on the use of consistency constraints in distributed optimization, the reader is referred to Cramer (1994), Alexandrov and Lewis (1999), and Tosserams (2009a).

Objective functions f, constraints g and h, and analyses a are partitioned into M sets of local functions f _j , g _j , h _j , a _j , j = 1,...,M, and a set of system-wide functions f ₀, g ₀, h ₀, a ₀.

The partitioned problem can then be written as: Similar to the integrated formulation, with \(\mathbf{r}_{j} = \mathbf{a}_j(\overline{\mathbf{x}}_j)\) we mean to express that a response in r _j may depend on other responses in r _j , but a response cannot depend on itself.

Although the above formulation assumes that the integrated problem (1) possesses a certain sparsity structure (i.e. the presence of local variables and functions), it is general enough to encompass many practical engineering problems. Several coordination methods have been developed for a subclass of (2), so-called quasiseparable problems that do not have coupling objectives f ₀, but may have additively separable coupling constraints g ₀ and h ₀ and analysis functions a ₀ (see Tosserams 2009a). For the remainder of this article, however, we consider partitioned problems of the form (2) with general coupling objectives f ₀, general coupling constraints g ₀, h ₀, and general analysis functions a ₀.

The artificially introduced variables in the above problem can be eliminated from the optimization variables through the consistency constraints c or the analysis equations. Whether or not these variables are eliminated is however a matter of coordination, and not a choice we want to make at the partitioning stage. Similarly, the coordination method determines how local and coupling variables and functions are treated. Hence, we will refer to problem (2) with all optimization variables included when we speak of the partitioned problem for the remainder of this article.

After partitioning, a coordination strategy prescribes how the partitioned problem is to be solved. Single-level methods typically act directly on the partitioned problem (2), while the use of multi-level methods involves the formulation of optimization subproblems for j = 1,...,M and a method for coordinating the solution of these subproblems. Each coordination method is unique in its treatment of variables and functions, the way in which the partitioned problem is reformulated, and how the reformulated problem is solved. For reviews of coordination methods, the reader is referred to the works of Wagner and Papalambros (1993), Cramer (1994), Balling and Sobieszczanski-Sobieski (1996), Alexandrov and Lewis (1999), and Tosserams (2009a). Note that partitioned problem specifications in Ψ are independent of the choice of coordination method.

Numerical and analytical studies indicate that the choice of coordination method has a direct influence on the computational performance with which a problem can be solved (Perez 2004; de Wit and van Keulen 2007; Yi 2008). Computational frameworks have been developed to facilitate the implementation and testing of coordination methods (see again the introduction section for references). The execution of the coordination algorithms is typically automated for these frameworks, and the user is required to supply a problem specification. Such a problem specification has two ingredients (Steps 1 and 2 of Fig. 1): Variable specifications typically include a definition of properties such as its name, a description, its type (e.g. real/integer, scalar/vector), its size, and upper and lower bounds. Function definitions include similar properties together with additional information regarding function arguments and outputs, and how these output values are actually computed. This may for example be an explicit expression or a path to a script that should be executed. The second ingredient is the specification of the partitioned problem. The specification describes how variables and functions are allocated to subproblems, and how their couplings are defined.

For the computational frameworks listed in the introduction, the problem specification needs to be supplied in the programming language environment in which the framework is implemented. This programming language is selected for its appropriateness as a computational environment, and its language elements are relatively well-suited for defining variable and function specifications. The definition of the problem partitioning may however be less intuitive. The language limitations become more pronounced if a decomposition has non-hierarchical couplings, or has multiple levels. For such decompositions, specifying the problem becomes a tedious process that is prone to errors (Alexandrov and Lewis 2004a, b). A more intuitive specification process is clearly desired. In addition, having partitioned problem specifications in a unified format promotes their portability between computational frameworks. In the following section, several representation concepts are reviewed with respect to their appropriateness for specifying the partitioned problem.

Several representations have appeared in research focused on model-based partitioning (see, e.g., Kusiak and Larson 1995; Krishnamachari and Papalambros 1997; Michelena and Papalambros 1997; Chen 2005). Model-based partitioning methods typically rely on matrix or graph abstractions of the couplings between variables and functions to define a sparsity structure of the integrated problem (1). Examples of such representations are the functional dependence table and the adjacency matrix. The use of matrices and graphs to specify the partitioning becomes prohibitive for larger systems due to the large number of variables and functions.

Alternative matrix and graph representations have appeared in research on the decomposition of the system de sign process into individual design tasks (see, e.g., Steward 1981; Eppinger et al. 1994; Kusiak and Larson 1995; Browning 2001). The transfer of information between engineers defines precedence relations between the individual tasks that can be captured in matrices or graphs. For example, element i,j of the so-called design structure matrix is non-zero if task j requires information from task i, and zero otherwise. In a graph format, vertices can be defined for each task, and precedence relations between two task can be represented by directed edges between the associated vertices. Partitioning methods for process decomposition aim at obtaining a sequence of tasks that minimizes the amount of feedback coupling between tasks or maximizes concurrency of tasks. The main difference between process decomposition and optimization problem decomposition is that the amount of detail in process decomposition is much smaller than for optimization. The number of tasks in design processes is typically one or more orders of magnitude smaller than the number of variables and functions in system optimization.

To our opinion, the decomposition-based design community would benefit from an approach that allows the intuitive specification of partitioned problems from which matrix or graphs representations can be automatically generated, instead of working directly with matrices or graphs.

We propose to use a linguistic approach to specifying partitioned problems. The developed language is similar to the reconfigurable multidisciplinary synthesis approach (REMS) proposed by Alexandrov and Lewis (2004a, b). REMS is a linguistic approach to problem description, formulation, and solution that follows a bottom-up assembly process. The method starts from the definition of individual subproblems that are automatically assembled into a complete system optimization problem.

The language we propose in the next section follows a similar bottom-up process, but does not automate the assembly process. Instead, disciplines have purely local definitions of variables and functions, and it is the system designer that assembles the subproblem definitions into subsystems and systems. The advantage of having a multi-level architecture composed of subproblems, lower-level systems and higher-level systems is that a designer no longer has to work on the entire system. Instead, the designer can divide the assembly into multiple levels, where each level is associated to a level of abstraction in the system. The designer can control the complexity of the specification tasks and does not have to oversee the entire system. We expect that this controllability of the complexity improves a designer’s overview of the system, and provides control over the interactions between disciplines. This control over the assembly process is not available in the REMS approach.

An additional advantage is that variable and function definitions are local to subproblems. One designer does not have to worry about whether a variable defined locally also exists in another context somewhere else in the system. Instead, subproblems are free to use local nomenclatures, and the interactions between subproblem nomenclatures have to be defined explicitly at the system level. Such a decoupling of definitions appears to be appropriate in a distributed design environment.

The proposed specification approach is similar to the python-based format used for the pyMDO framework of Martins (2009). However, the pyMDO approach does not have local subproblem nomenclatures, nor does it allow the definition of multi-level systems.

The multi-level assembly process has another advantage. Since a different coordination method can be assigned to each system, a multi-level nested coordination process can be formulated. For example, one can nest a lower-level system that is coordinated with a multidisciplinary feasible formulation within a higher-level system that is coordinated with collaborative optimization. Note that it is the choice of the designer how to assign coordination tasks to lower-level systems.

The main building blocks of a partitioned problem definition in Ψ are components. These components are typically associated with analysis disciplines in aspect-based decompositions or with components in object-based partitions, but may also be purely computational subproblems that have no direct relation to the physical system. At the partitioning stage, we are not concerned with the assignment of analysis and/or optimization authorities to components. This is a choice that is made at the coordination stage, and does therefore not appear in the component definitions.

To illustrate the use of Ψ, consider the following optimization problem: This problem may be partitioned into two subproblems. The first subproblem has local variables {x ₁,x ₂} and local functions {f ₁,g ₁,a ₁}. The second subproblem has local variables {x ₃,x ₄,u} and local functions {f ₂,g ₂,a ₂}. The two components are coupled through the variables {y,r} and the system-wide objective {f ₀} that depends on variable x ₂ of the first subproblem and on x ₃ of the second. The partitioning structure is depicted in Fig. 2.

For this partitioned problem, the specification of the two components is given below.

comptFirst =

|[  extvarx₂, y, r

    intvar x ₁

    objfuncf₁ (x₁, x₂, y, r)

    confuncg₁ (x₁, y)

    resfunc r = a₁ (x₂, y)

]|

 

comptSecond =

|[  extvarx₃, y, r

    intvarx₄,u

    objfuncf₂(x₃,x₄,y)

    confunc g₂(x₃,x₄,y,u)

    resfunc u = a₂(x₃,x₄,r)

]|

The first component has name First and has four variables x ₁,x ₂,y,r and three functions f ₁,g ₁,a ₁. The language distinguishes between two types of variables: external variables defined after the keyword extvar, and internal variables defined after the keyword intvar. External variables can be accessed by the system the component is part of. External variables can be shared variables or coupling variables that are communicated between components, or local variables on which system-wide functions depend. Variables y,r fall in the former category and x ₂ falls in the latter since it is an argument of the system-wide objective f ₀. Internal variables are only accessible within the component.

The reason for taking a division of variables different from the traditional local and coupling/shared variables is that from a system designer’s viewpoint it is relevant to know which variables have an influence beyond the component in which they are defined. From this perspective, external variables are those variables that affect other components and systems and therefore also include local variables that are arguments of system-wide functions.

Three groups of functions are available in the Ψ language: objective functions, constraint functions, and response functions. In component First of the example, function f ₁(x ₁,x ₂,y,r) is a local objective with four arguments x ₁,x ₂,y,r, and function g ₁(x ₁,y) is a local constraint with two arguments x ₁,y. Function a ₁(x ₂,y) is a response function that determines the values of variable r. A response function may have multiple variables as outputs. It is possible to apply the same function multiple times with different arguments.

Definitions of variables and functions in components (and systems) have a local scope. Variables and functions defined in one component may have the same name as other variables and functions of another component without being automatically coupled. Instead, interactions between components have to be specified in systems.

Once the components of a partitioned problem are defined, they can be assembled into systems. A system definition includes two or more subcomponents and describes the couplings between them. The subcomponents of a system can be components or other systems. In the latter case, a multi-level system is obtained.

The system definition for the example partitioning of problem (3) is given by

systProblem=

|[  subA:First, B:Second

    linkA.y -- B.y, A.r -- B.r

    objfuncf₀(A.x₂, B.x₃)

]|

The system is named Problem and has two subcomponents: A of type First, and B of type Second. Multiple subcomponents of the same type can be instantiated in a system. The expression A ₁,A ₂: First instantiates two subcomponents A ₁ and A ₂ of the same type First. These multiple instantiations are useful for systems that have many identical components, such as structural systems consisting of many similar elements.

The consistency constraints between the two components are given by the link statement that connects variables y and r of component A to variables y and r of component B, respectively (note that the linked variables need not have the same local name). In systems, the dot notation A.y denotes variable y from component A.

The specification of the system is completed by the definition of the system-wide objective function f ₀ that depends on variable x ₂ of A and x ₃ of subcomponent B. Systems can also have system-wide constraint functions or response functions.

In contrast to components, a system does not have design variables of its own. However, response variables associated with the coupling analysis functions have to be included as variables of the system definition. Similar to components, the keywords extvar and intvar are used to define which response variables are external and which are internal.

The final ingredient of the partitioned problem specification for the example partitioning of problem (3) is the statement

    topsyst Problem

which instantiates the partitioned problem by defining that the highest system in the hierarchy is Problem. The definitions for components First and Second, system Problem, and the topsyst statement comprise the specification of the partitioned problem for our example problem.

The compiler checks a partitioned problem specification in Ψ for errors, and translates it into a specification in INI format. The compiler checks for around 50 semantic requirements such as Informative error messages are generated to assist the user in debugging incorrect specifications. Checking partitions in this early stage assures that further automated processing at later stages does not require to do so and can rely on correctly specified partitions. The reader is referred to the user manual (Tosserams 2009b) for a complete list of the semantic requirements that are checked for.

After a specification is checked for errors, an INI-specification is generated. The generated INI-specifications are less compact and harder to read than specifications in Ψ, but have the advantage that they can be easily interpreted by programs in other languages (Cloanto 2009). The INI-format serves as a normalized format between Ψ and coordination frameworks. Figure 3 illustrates the relations between the different files and the associated compiler and generators.

The specification of the partitioned problem in INI format is defined by a number of sections. Each section contains a section header \([\textit{section}]\) and a number of key/value pairs of the form \(\textit{keyname}~=~textit{value}\). Separate sections are introduced for each variable, each function, each component, each coupling link, each system, and one for the top-level system. The collection of sections contains the necessary information to uniquely represent the partitioned problem.

The contents of the normalized file generated from the Ψ-specification for the example partitioning of problem (3) are given in Fig. 4. The order of sections and keys in this file may appear unconventional, but this is not an issue since the file is intended for further automatic processing rather than for human understanding.For variable and function sections, the key-value pairs define, respectively, the variable’s/function’s name in the Ψ-specification (name), the component or system definition in which it is specified (defined_in), and the instantiation path of this definition (path). Function sections also include the keys argvars and resvars that define the arguments and responses of a function, respectively (where only analysis functions have responses).

Component and system sections include keys for its definition name (type), the name of its instantiation (name) and the associated instantiation path (path), its shared and local variables (coupling_vars ² and local_vars, only for components), its coupling and local responses (coupling_resvars and local_ resvars), and its objective, constraint, and response functions (objfuncs, confuncs, resfuncs). System sections also include a list of sub-components (sub_comps) and links (links). Note that the local and shared variables correspond to the definitions of x _j and y _j in the partitioned problem (2). Response functions r _j are split into local (i.e. disciplinary) responses and coupling responses similarly.

A coupling section (link_) includes the variables that it couples (coupling), the name of the system definition in which it is defined (defined_in), and the instantiation path of this system (path). A coupling can be defined between two shared design variables or between two coupling response variables. Finally, the top section includes the key system whose value denotes the name of the top-level system.

The first generator translates the INI output into Matlab problem specification files that can be used as input for our Matlab implementation of the augmented Lagrangian coordination algorithm (ALC, Tosserams 2008, 2009c). This ALC-generator was the original motivation for the work presented in this article. It is beyond the scope of this article to discuss the ALC method or the details of the input files in greater detail. Our intention is to present the generated ALC files to demonstrate the possibilities that the compiler-based approach offers. The interested reader is referred to the references given above for further details on the ALC method.

The ALC input files make use of matrices, vectors, and similar data types, which are easily processable with standard Matlab commands. Although the ALC format is very different from Ψ or normalized specifications, the generator can automatically generate ALC files from the partitioned problem specification in INI format. The contents of the generated Matlab file for the example partitioning of problem (3) is given in Fig. 5. The ALC toolbox does not allow response functions or response variables, and the response functions r = a ₁(x ₂,y) and u = a ₂(x ₃,x ₄,r) of the example have been included as constraint functions h ₁(r,x ₂,y) = r − a ₁(x ₂,y) = 0 and h ₂(u,x ₃,x ₄,r) = u − a ₂(x ₃,x ₄,r) = 0 for this purpose. The ALC-generator automatically checks whether a Ψ specification has response functions or not. The reason for including these checks in the ALC-generator (and not in the compiler) is that Ψ is generic, i.e. independent of the coordination method.The difference between the Matlab and Ψ specifications is obvious, as well as the difference in readability between the two. Specification of the partitioned problem using Ψ is clearly more intuitive than specifying them using the ALC format in Matlab.

A second generator creates a file that contains the functional dependence table (FDT) of the specified problem. The FDT is a matrix whose rows and columns are associated with the functions and variables of the problem, respectively. The (i,j)-th entry of the matrix is 1 if the function of row i depends on the variable of column j. The FDT and related mathematical representations are typical inputs to model-based partitioning methods such as those proposed by Krishnamachari and Papalambros (1997), Michelena and Papalambros (1997), Chen (2005), Li and Chen (2006), and Allison (2007).

The generated functional dependence table file for the example partitioning of problem (3) is given in Fig. 6. Having to specify a problem’s structure in a functional dependence table is clearly a tedious process that is prone to errors and becomes increasingly prohibitive as systems become larger. Specifying problem structures using Ψ provides a much more intuitive environment for this purpose. The FDT can be automatically generated from the Ψ specification, using the INI normalized format.

Being able to generate different types of input files from the same Ψ specification not only saves time, but also leads to consistent definitions of the partitioned problem. These advantages make comparing results from different computational frameworks easier.

The partitioned problem given in Kim (2003) is specified in Ψ below, and is illustrated in Fig. 7a. The system Chassis has seven sub-components: Vehicle, Tire, Corner, two of type Suspension, and two of type Spring. Each sub-component includes its relevant set of optimization variables and functions. The similarity of the front and rear suspensions and springs is exploited by defining a single suspension and a single spring component. By instantiating these components twice in system Chassis, two independent subproblems are defined, each with a separate set of design variables.

compVehicle =

|[  extvar \(a,b,K_\text{sf},K_\text{sr}, K_\text{tf},K_\text{tr},C_{{\alpha}\text{f}},C_{{\alpha}\text{r}}\)

    intvar \(\omega_\text{sf},\omega_\text{sr},\omega_\text{tf},\omega_\text{tr},k_\text{us}\)

    objfunc \(\mathbf{f}(\omega_\text{sf},\omega_\text{sr},\omega_\text{tf},\omega_\text{tr},k_\text{us})\)

    resfunc \((\omega_\text{sf},\omega_\text{sr},\omega_\text{tf},\omega_\text{tr},k_\text{us})=\)

           \(\mathbf{a}_1(a,b,K_\text{sf},K_\text{sr}, K_\text{tf},K_\text{tr},C_{{\alpha} \text{f}},C_{{\alpha}\text{r}})\)

]|

 

compt Tire=

|[  extvar \(a,b,K_\text{tf},K_\text{tr},P_\text{if},P_\text{ir}\)

resfunc \((K_\text{tf},K_\text{tr})= \mathbf{a}_3(P_\text{if},P_\text{ir},a,b)\)

]|

compt Corner=

|[  extvar \(a,b,C_{{\alpha}\text{f}},C_{{\alpha}\text{r}},P_\text{if},P_\text{ir}\)

    resfunc \((C_{{\alpha}\text{f}},C_{{\alpha}\text{r}}) = \mathbf{a}_4(P_\text{if},P_\text{ir},a,b)\)

]|

 

comptSuspension =

|[  extvar \(K_\text{s},K_\text{L},K_\text{B},L_\text{0}\)

    intvar \(Z_\text{s}\)

    confunc \(\mathbf{g}_1(Z_\text{s},K_\text{L},K_\text{B},L_\text{0})\)

    resfunc \(K_\text{s} = \mathbf{a}_2(Z_\text{s},K_\text{L},K_\text{B},L_\text{0})\)

]|

 

compt Spring =

|[  extvar \(K_\text{L},K_\text{B},L_\text{0}\)

    intvar D,d,p

    confunc g₂(D,d,p)

    resfunc \((K_\text{L},K_\text{B})=\mathbf{a}_5(D,d,p,L_\text{0})\)

]|

 

syst Chassis =

|[  sub    V: Vehicle, T: Tire, C: Corner

       , \(S_\text{f}, S_\text{r}\): Suspension, Sp \(_\text{f}\), Sp \(_\text{r}\): Spring

    link   V.a -- {T.a,C.a}, \(T.P_\text{if}\) -- \(C.P_\text{if}\)

        , V.b -- {T.b,C.b}, \(T.P_\text{ir}\) -- \(C.P_\text{ir}\)

        , \(V.K_\text{tf}\) -- \(T.K_\text{tf}\), \(V.C_{\alpha \text{f}}\) -- \(C.C_{\alpha \text{f}}\)

        , \(V.K_\text{tr}\) -- \(T.K_\text{tr}\), \(V.C_{\alpha \text{r}}\) -- \(C.C_{\alpha \text{r}}\)

        , \(V.K_\text{sf}\) -- \(S_\text{f}.K_\text{s}\), \(V.K_\text{sr}\) -- \(S_\text{r}.K_\text{s}\)

        , \(S_\text{f}.K_\text{L}\) -- \(Sp_\text{f}.K_\text{L}\), \(S_\text{f}.L_0\) -- \(Sp_\text{f}.L_0\)

        , \(S_\text{r}.K_\text{L}\) -- \(Sp_\text{r}.K_\text{L}\), \(S_\text{r}.L_0\) -- \(Sp_\text{r}.L_0\)

        ,\(S_\text{f}.K_\text{B}\) -- \(Sp_\text{f}.K_\text{B}\)

        , \(S_\text{r}.K_\text{B}\) -- \(Sp_\text{r}.K_\text{B}\)

]|

 

topsyst Chassis

A second partitioning of the problem as shown in Fig. 7 is used to demonstrate how multi-level coordination can be facilitated by including systems as sub-components of other systems. This partition has a subsystem SuspSpring that includes a Suspension and a Spring component. Two instantiations of this lower-level system are included in a system Chassis ₂ that also includes the Vehicle, Tire, and Corner components of the first definition above. The differences between the two partitioned problems are illustrated in Fig. 7. The specification of the systems SuspSpring and Chassis ₂ for second problem partitioning is given below.

syst SuspSpring =

|[ sub  S: Suspension, Sp: Spring

link \(S.K_\text{L}\) -- Sp.\(K_\text{L}\), S.L₀ -- Sp.L₀, \(S.K_\text{B}\) -- Sp.\(K_\text{B}\)

alias \(K_\text{s}=S.K_\text{s}\)

]|

 

syst Chassis₂ =

|[ subV: Vehicle, T: Tire, C: Corner

   , \(S_\text{f},S_\text{r}\): SuspSpring

link V.a -- {T.a,C.a}, \(T.P_\text{if}\) -- \(C.P_\text{if}\)

, V.b -- {T.b,C.b}, \(T.P_\text{ir}\) -- \(C.P_\text{ir}\)

, \(V.K_\text{tf}\) -- \(T.K_\text{tf}\), \(V.C_{\alpha \text{f}}\) -- \(C.C_{\alpha \text{f}}\)

, \(V.K_\text{tr}\) -- \(T.K_\text{tr}\), \(V.C_{\alpha \text{r}}\) -- \(C.C_{\alpha \text{r}}\)

, \(V.K_\text{sf}\) -- \(S_\text{f}.K_\text{s}\), \(V.K_\text{sr}\) -- \(S_\text{r}.K_\text{s}\)

]|

 

topsyst Chassis₂

The couplings between the variables of Suspension and Spring are included in the system SuspSpring. Two systems SuspSpring are instantiated in system Chassis ₂, and links between the different sub-components are defined accordingly. With this second partitioning, the coordination of the SuspSpring lower-level systems can be performed nested within the coordination of the top-level system Chassis ₂.

System SuspSpring includes the definition of an alias (\(K_\text{s}\)), which is introduced to make this variable of component Suspension accessible by system Chassis ₂. In general, aliases are used in systems that are themselves part of another system, and are included to make a variable of a sub-component accessible by a higher level system. An advantage of using aliases instead of an identifier such as N.S.v is that the higher-level systems do not need to have detailed knowledge of the structure of its subsystems. Additionally, the definition of the higher level system does not need to be changed if the structure of the subsystem is modified. Observe that an alias definition does not define a consistency constraint; aliases are simply used to forward variable values of lower to higher levels in the problem hierarchy.

For the first partitioned problem, the compiler and both generators are used to automatically generate the three input files from the Ψ-specification. Note that for the purpose of the ALC input file, the response functions have been included as constraint functions, similar to Section 4.2.

The generated normalized file, the ALC input file, and the FDT file are given in Figs. 8, 9, and 10, respectively. The advantages of being able to generate the ALC and FDT formats automatically are obvious since neither of these two formats is attractive for specification of the partitioned problem structure. Valuable time and effort can be saved by specifying partitioned problems using the intuitive and compact Ψ language.