JCISE, 30-06-2009 Continuous Pre-design Process for Mechatronic Systems based on SysML, Topological Modelling and Interval Analysis R. Plateaux*, S.A. Raka**, C. Combastel**, O. Penas*, J.Y. Choley*, H. Kadima***, A. Rivière* *

LISMMA EA2336 (SUPMECA PARIS), 3 rue F. Hainaut, 93407 Saint Ouen Cedex, France ECS – ENSEA (EA n°3649), 6 avenue du Ponceau, 95014 Cergy-Pontoise Cedex, France. *** LARIS – EISTI, avenue du Parc, 95011 Cergy-Pontoise Cedex, France. **

Abstract In order to describe a coherent and collaborative pre-design process for mechatronic systems, this paper seeks to deal with the practical example of a power lift gate. Firstly, functional analysis is carried out from user requirements. This allows one to define suitable architectures and associated test cases. Each of them has to be analysed and optimized separately in order to select the best architecture and the best set of key parameters. Secondly, a topological analysis is carried out in order to generate a set of equations with physical and topological constraints previously defined in the first step. Finally, an interval analysis is implemented in order to optimize the parameters under the constraint of the relevant test cases. 1.

Introduction

A system design process is a formalised, planned, reviewed, and continually evolving series of activities involving multiple engineering disciplines working co-operatively together to build a product. To accurately reflect an accepted systems engineering process, current industry standards such as IEEE 1220-1998 [1], ISO standard 15228 [2] and ANSI/EIA-63298 [3] have to be taken into account. Currently, system engineering problems are solved using a wide range of domain-specific modelling languages and tools. Nowadays, there is no single unified modelling language to model in sufficient detail the large number of system aspects and various components of multi-domain systems. It is also not realistic to create an all-encompassing systems engineering language capable of modelling and simulating every aspect of a system. However, mechatronic systems developments involve considering the modelling of their components together with their interactions. Models can be used to represent formally all aspects of a systems engineering problem, including requirements, functional, structural, and behavioural modelling. Additionally, simulations can be performed on these models in order to verify and validate the effectiveness of design decisions. This paper covers the pre-design phase of a mechatronic device. Following the recent advances in Model Based System Engineering (MBSE) [4], the pre-design can be viewed as a model transformation process [5]. Based on the example of a power lift gate, our goal is to show how the engineering knowledge can be formalized and used all along the three following phases of the pre-design process: - requirements definition and functional analysis, - geometrical and physical modelling, and - optimization. For multi-domain systems, a global approach is necessary. Indeed, each domain has its own methodologies and languages, thus impeding the coherency of the different modelling. Hence, a global optimization is difficult during the pre-design process of these systems. In this paper, a common approach is proposed with SysML, topological modelling and interval analysis (Figure 1). 1

Global Approach for System Pre-design SysML

Requirements Functional Analysis Architecture

Topological based modelling Generation of equations based on a topological approach

Optimization Interval analysis

Figure 1: Common approach for multi-domain predesign.

The System Modelling Language (SysML) [6] is a graphical modelling language adopted by OMG in 2006. It is built as UML profile and tailored to the needs of system engineers by supporting requirements, specifications, analysis and design of a broad range of systems and systems-of-systems. SysML provides the support for an object oriented formalization of high level knowledge. The main goal behind SysML is to unify different approaches and languages used by system engineers into a single standard. Additionally to software components design, SysML models may span different physical domains, for example mechanical, electrical, hydraulic, etc ...The different SysML models make it possible for engineers from various disciplinary fields to share a common view about the system (as well as the interactions with its environment). A model-based design requires the domain experts to contribute to the modelling of the overall system. Our purpose is to apply an approach coupling multi-physical (here mechanical) and geometrical parameters to conceptual design of mechatronic systems. Our method is based on a topological analysis and an associated algebraic diagram, in order to generate the simultaneous equations describing relations between physical and geometrical parameters [7]. Then, by a declarative approach, we can find expressions of unknown key parameters as functions of certain known variables. Thus, a significant effort has been made in order to derive as automatically as possible system equations from the given topology of the system being designed. Special emphasis is also placed on interval-based computational methods [8] allowing one to explore exhaustively the search space resulting from a declarative statement of constraints [9][10]. Given the previous high level vector model linked to a given topology, formal calculus can be used to avoid part of the tedious work consisting in giving the mathematical expressions of some constraints as required to run dedicated solvers. The use of interval computations within a constraint programming paradigm [9][11] also provides a computational support to quantify uncertainties and to detect inconsistencies. From a methodological point of view, the refinement inherent to the design process is underlined.

2

2.

Modelling power lift gate system with SysML

In this section we propose a way of modelling a power lift gate system by means of appropriate SysML models at the early stages of the technical engineering process. The main device of a power rear lift gate is the electrical cylinder that replaces the usual gas strut. In order to ensure that the main requirements are fulfilled, such as opening period and power consumption, the electric cylinder has to be pre-designed whatever its internal structure is, meaning that: - the fixing points on the car-body and the lift gate have to be defined; - the force needed to open and maintain the lift gate has to be determined; - the full length and rest length have to be fixed. SysML provides an answer to the need for model integration. Using SysML, system engineers can abstract a domain-specific language to a level that allows its interaction with other system models. Our approach starts with a requirements specification phase which includes a requirements analysis producing the refined requirements. The latter are used as input for the system-level design phase where the system engineer has to describe the system by means of SysML diagrams such as Block Definition Diagram, Requirements, Allocation and Parametric diagrams etc… 2.1. Requirements Modeling Textual form requirements will always exist and is the starting point of requirement specification phase with SysML. Tracing requirements from the SysML Requirements Models to the system-level model clarifies how the engineer interpreted the requirements. As defined in the EIA 632 standard [3], a requirement is “Something that governs what, how well, and under what conditions a product will achieve a given purpose”. Id

Name

Text

U0

Usability

The system should be able to open/close the gate from any position, even in cold conditions or extreme angle conditions (car on a hill)

U1

Safety Usage

The system should be able to hold the gate in any medium position by itself without any external power (manual, electrical,…)

U2

Back drive ability

The system should include a manual function. The back drive ability of a lift gate means that the system should not block a movement created by an outside additional force on the gate.

U3

Minimal manual force

The system should ensure that the force the user has to deploy without electrical assistance should not be higher than a maximum level in any position or condition (opened, closed, intermediate position, cold, hot, uphill, downhill).

U4

Minimal changes on the car design

The system should be easily integrated in the car design. This means that, the number of modifications on the car design must be as low as possible (lower costs for the car manufacturer). Ideally, the system should also be easily adaptable to different models of cars.

Table 1: Power Lift Gate System User Requirement

3

This first phase in engineering process translates end-user, marketing, or customer source statements into formal requirements. summarizes some user requirements indispensable for our study: 2.2. System Functional Analysis The main objectives of this phase are to describe the problem defined by the requirements analysis in clearer detail and to identify and describe the desired functional behaviour of each system component or process without consideration of a specific design solution. Key tasks of this phase include: • Define operational scenarii; • Derive system behaviour model (and other models as needed) to reflect control and function sequencing, data flow and input/output definition; • Derive functional and performance requirements and allocate them to the behaviour model; • Define functional failure modes and effects. In this phase, we can use SysML Use Case Diagrams to describe system services and SysML Sequence Diagrams to describe operational scenarii associated to main use cases. Figure 2 shows the SysML Use Case Diagram of the power lift gate system.

Figure 2: Use Cases Diagram of Power Lift Gate System

SysML Requirement Diagram can be used to organize clearly user and derived system requirements. Figure 3 shows the SysML Requirement Diagram of the power lift gate system as a hierarchical tree of blocks. Each block is annotated with the “requirement” stereotype and has 4

a compartment for displaying text and identification fields. Requirements are related to other modelling elements using various dependencies such as “satisfy” and “verify”. The “satisfy” stereotype shows how requirements are fulfilled by the elements of the other diagrams and the “verify” stereotype shows how requirements can be verified by test cases.

Figure 3: System Requirement Diagram

In SysML, Block is the primary modelling unit. As defined in [6], it is a modular unit of a system description. A SysML Block Definition Diagram (BDD) is used to define block features and the relationships between blocks or other SysML constructs. Due to the complexity of mechatronic systems it is indispensable to structure them clearly. A Block Definition Diagram is a natural approach for modelling the structure of a system. Figure 4 depicts the structural definition of a power lift gate system. This system is made up of many subsystems and components. In this figure two important categories of properties are depicted. The first kind of property is a part property. Part Properties represent a subsystem or component of a system. Part properties can be depicted in the parts compartment of a block or using a composition association. The second kind of property is a value property. A value property appears in the values compartment of a block and represents a quantifiable characteristic of a block (e.g. force, mass, velocity) and must be typed to a SysML value type.

5

A value type is a special modelling element used to assign the units of measurement and dimension declared in its definition.

Figure 4: The SysML Power Lift Gate System BDD

By using a hierarchical representation of the requirements, clear gains can be made in the elaboration of requirements, in tradeoffs, as well as in the validation and the verification of requirements. Indeed, during design activities, verification activities need to be defined to satisfy system constraints and properties. Links between Requirements Diagrams and other models allow engineers to connect test criteria to test cases used throughout the development process (Figure 3 et Figure 5 ). In SysML, a test case is intended to be used as a general mechanism to represent all verification and simulation methods for system analysis process, test system constraints and physical properties, design space exploration etc. SysML has the capability for representing test cases and attaching them to their related requirements. In this paper, we restrict our case study to a few geometrical and dimensional parameters of the electrical cylinder. In order to ensure that the main requirements are fulfilled, such as opening period and power consumption, the electric cylinder has to be pre-designed whatever its internal structure. This means we have to determine: - additional force required to maintain the lift gate static equilibrium inferior to a threshold level. It refers here to the force ∆F defined as Fcyl = Fspring + ∆F, where Fcyl is the cylinder force required to maintain the static equilibrium and where Fspring is the force of the spring within the power cylinder used to downsize the electrical motor. - electrical cylinder length within a specified interval related to the aperture angle of the lift gate, - car body fixation point within a specified area, - lift gate fixation point within a specified area. All these points constitute some system constraints and properties to analyze. The first ones have to be verified through attached specific test cases as shown in Figure 3 and . One 6

can express equation-based internal behaviour specifications of a component or a set of components. A test-case is simply a mechanism allowing to verify the constraints defined by this equation. 2.3. Architecture Analysis During this phase, system synthesis by assigning functions to identified physical architecture elements (subsystems, components) is carried out. This synthesis activity is performed to define design solutions and to identify subsystems and components that will satisfy the established requirements (Figure 6).

Figure 5: Test Case and System Requirements Attachment

Once the early design phases have been performed with SysML models, the physical modelling of the overall system has to be built, based on the topology of the system, in order to generate the equations required for the optimization phase. Once this has been done, the Design Space Exploration can be executed in order to discover the optimal design solution from all functional and architectural specifications and constraints. Indeed, the most efficient way to explore this design space is to reason about previous SysML models, thus proving in a mathematically rigorous way that all required properties and constraints are met. 3.

Vector-Based Mechanical Modelling Derived from System Topology

The previous SysML test cases bring to light the key parameters of the power lift gate system. In order to optimize these key parameters, this mechanical problem has to be translated into equations.

7

We propose to use a highly suitable method [12] for multi-domain (mechanics, electronics, computing…) systems such as automotive mechatronic components. Based on a topological analysis of the system, this generic method delivers equations that can be processed by a solver. It relies on the works of Kron [13], Branin [14] and Björke [15]. Here, our method is restrained to the mechanical study of the static equilibrium of the lift gate but it may also be used to express the internal structure of the electrical cylinder (screw and nut system, tubes, gearbox, spring, sensors, electrical engine and electronic components...). The isolated system includes the lift gate with the electric cylinder NM, the car body being an external system. Let us assume that: • Mechanical joints are perfect; • Points A, M and G belong to the system boundary; • There is neither external mechanical force nor torque on internal point N; • P is the external force on the gravity centre G; • FC is the force created by the electrical cylinder, which corresponds to the internal force RMN. In order to model the architecture of the system, a topological graph has first to be defined from geometrical and mechanical definitions of the problem (Figure 6). The boundary of the system is expressed by means of labels attached to each node and each branch: name (A, G, ...), boundary (nodes) or internal (branches), all of them inherited from SysML diagrams.

A

Lift gate

G

N

P=mg

G A

N

M Car body

Structure

M

Associated Topological Graph

Figure 6 : Lift gate and Electrical Cylinder

Then, the topology has to be mathematically expressed using a connexion (or incidence) matrix named C and an algebraic graph that allows one to connect nodes and branches. The topological structure (graph) is overlaid with an algebraic structure. This global structure connects nodes and branches of the graph, and may include physical parameters which govern the behaviour of the system. This method has been described thoroughly in previous papers [7] [12]. In order to use standard vector-based representation, the sign of the incidence matrix has to be changed. This explains why the incidence matrix as previously defined in [7] [12] are here preceded with -1.

8

Branches (internal)

 AN     MN   AG   

Nodes  −1 0 1 0  (external) C=(-1)  0 −1 1 0  A   −1 0 0 1    M  N    G 

Thus, the transposed matrix CT can be used to express the connection between internal and external mechanical forces and moments, defined with their associated static screws.  −1 0 −1  0 −1 0   CT =(-1)  1 1 0  TA   TAN + TAG         TAN  0 0 1 TM   TMN      = T     MN T − T − T   N AN MN T       AG   TG   −TAG  with TA standing for “screw of external mechanical action on point A” and TAN standing for “screw of internal mechanical action on AN structure”. As a result, an equation system is obtained, with the decomposition of screws in 4 force equations and in 4 moment equations expressed in the arbitrarily chosen point A:

  R AN       M AN  A   R    MN    M MN  A      R AG    M     AG  A 

 −1 0 −1  R A = R AN + R AG   0 −1 0    R M = R MN    CT =(-1)   1 1 0   R N = − R AN − R MN      R G = − R AG 0 0 1      M A = M AN + M AG    M M = M MN   M N = −M AN − M MN   M = −M  G AG  A

The equation system is simplified and can be solved:

9

 R A = R AN + R AG (1)   R M = FC (2)   R AN = R A + P (4) → (1) (9)    0 = − R AN − FC (3)   FC = − R A − P (9) → (3) (10)     P = −R AG (4)     M AN = AG × P (8) → (5) (11)    ⇒  0 = M AN + M AG (5)   M MN = − AG × P (12)  (11) → (7)  AM × R M = M MN (6)      ((2) → (6)) & (12) AM × FC + AG × P = 0 (13)  A  0 = −M AN − M MN (7)   AG × P = −M (8)  AG  A ⇒ (13) AM × FC + AG × P = 0 ⇒ ( AN + NM ) × FC + AG × P = 0

⇒ AN × FC + NM × FC + AG × P = 0, or NM // FC Thus AN × FC + AG × P = 0 (14) The equation (14) expresses the static equilibrium of the electrical cylinder and lift gate system. 4.

Computational support for the exploration of the solution space based on constraint programming and interval analysis

The aim of this section is to experiment computational methods allowing to exhaustively explore parts of the search space resulting from a declarative statement of constraints. Those methods based on interval arithmetic allow to explicitly take uncertainties (in the sense of deterministic imprecision rather than probabilistic variability) into account in the pre-design process. Given the topology-based high level vector model developed in the last section, formal computations can first be used to semi-automatically derive the inequality constraints expressions used as input of the interval solver. The use of interval computations within a constraint programming paradigm allows to partition the search space D into three sets (D = D0 ∪ D1 ∪ D?), the latter two being described by a box paving: • D0 : sub-domains of D where it is guaranteed that the constraints are never satisfied. • D1 : sub-domains of D where it is guaranteed that the constraints are always satisfied. • D? : sub-domains of D where the satisfiability of the constraints has not been decided (i.e. sub-domains where some solutions may exist but it is not sure). The size of the “Possible” area in the search space is often related to some precision criterion defining a condition for stopping the solution search which is based on a recursive partitioning of the search space. From a methodological point of view, the refinement inherent to the design process can be supported as follows : the poor initial knowledge results in a small number of constraints with few variables belonging to rather large intervals; then, the sequence of assumptions, trials and evaluations constituting the heart of an iteration within the design refinement loop allows the engineers to acquire knowledge, to organize it, and to gradually converge toward what will become the detailed solution. The formalization of such a detailed solution will often rely on many constraints and many variables belonging to rather small intervals. It must be noticed that the computational support of such a refinement process highly depends on the state of the art of the available solvers. Following [16] which underlines the potential interest in the crossfertilization between the engineering design and the reliable computing communities, this 10

paper investigates how an existing interval solver based on branch and bound (bissections) combined with constraint propagation (contractors) can be used to support the design of a mechatronic system such as a power lift gate. The methodological advantages as well as the current scalability drawbacks are discussed and pave the way for future works.

3.1. Constraint Satisfaction Problems and overview of an interval solver (RealPaver) A Constraint Satisfaction Problem (CSP) is usually defined by (X, D, C) where X = {x1, x2, …, xn} is a set of variables, D = {d1, d2, …, dn} is a set of domains such that ∀i∈{1,…, n}, xi ∈ di, and C = {C1, …, Cm} is a set of constraints depending on the variables in X. Each constraint includes information related to constraining the values for one or more variables. It is usual to distinguish between discrete CSP, where all the variables belong to a discrete set of values, and continuous CSP, where all the variables belong to continuous domains such as interval for scalars or boxes for vectors. A combination of both leads to the so-called mixed CSP. From an engineering design point of view, the variables in X can be a set of design parameters, the domains in D can be used to define the range of the search space of interest, and the constraints in C can be concurrently stated by several engineers in any order. Such a declarative modelling is a significant advantage of the CSP paradigm throughout the life cycle of a Computer Aided Engineering (CAE) application [9]. In the following, it is focused on continuous CSP which allow to address the test cases previously identified for the power lift gate example. In order to perform the computations related to constraint propagation and in order to output a paving of the search space characterizing the solution set, the interval solver RealPaver (version 0.3) has been used in conjunction with Matlab. The software package RealPaver [17] implements a modelling language and some interval-based algorithms to process systems of nonlinear constraints over the real numbers. The solver input is a text file defining a CSP (X, D, C) where the (equality or inequality) constraints Cj, j=1…m are non linear analytic expressions which do not need to be differentiable: Cj : fj(x1, …, xn) ◊ 0

where

◊ ∈ {≤, ≥, =}

(15)

RealPaver generates a set of n-dimensional boxes whose union encloses the exact CSP solution set S as follows: D1 ⊂ S ⊂ D1 ∪ D?

(16)

Boxes are generated from the initial domain D using a branch-and-prune algorithm, which is an iterative method that alternates pruning and branching steps until reaching some fixed precision. The pruning step aims at reducing a box, by eliminating inconsistent values. The branching step splits a box into a set of smaller boxes. Some details about the internal algorithms implemented in RealPaver can be found in [18]. A small example where the solution set corresponds to the intersection of two rings is reported in the Figure 7.

11

/* rings.rp */ Constants x0 = 2, y0 = 1 , r1 = 1, r2 = 1.5, d1 = 2, d2 = 2.8; Variables real x in ]-oo, +oo[ , real y in ]-oo, +oo[ ; Constraints /* First ring */ r1^2 <= (x-x0)^2 + (y-y0)^2 , (x-x0)^2 + (y-y0)^2 <= r2^2 , /* Second ring */ d1^2 <= x^2 + y^2 , x^2 + y^2 <= d2^2 ;

Figure 7: Example of a continuous CSP solved with RealPaver. (Left: input file, Right: output paving plotted in Matlab after 0.5s)

Remark: RealPaver being a standalone software, the interface with Matlab is our contribution. In order to convert the original console output of RealPaver into a Matlab m-file, a small executable file named realpaver2matlab.exe has been developed using the C language and the OS redirection capability (pipeline) for the sake of speed. The execution of the m-file within the Matlab environment defines some workspace variables such as Boxes used to plot RealPaver’s output paving with a specific function called plot_boxes. As a result, the matlab code used to obtain the results reported in Figure 7 is: ! realpaver -paving rings.rp | realpaver2matlab > rings_paving.m rings_paving, plot_boxes(1,2,Boxes) The color code used in Figure 7 will be the same all along this paper when reporting RealPaver outputs: D0 is white (background color), D1 is the red paving, D? is the blue paving. According to the definition of rings in rings.rp (Figure 7), it can be observed that (16) holds. Moreover, the size of D? (blue paving) depends on an exploration stopping precision criterion. The following of this section is dedicated to the analysis of how the pre-design of a mechatronic system like the power lift gate application example can benefit from the use of an interval CSP solver, as well as a discussion of the methodological impact related to the availability of such computational tools. 3.2. Semi-automatic formulation of the constraints related to the test cases The proposed pre-design of the power lift gate focuses on the choice of the electrical cylinder fixation points. Two points should be determined: M on the car body and N on the lift gate (Figure 8).

12

JL

A

JB IL

FC

IB θ

N

γ

G

Cylinder

M

Lift gate

mg J

Car Body

Ground

K

I

Figure 8: References and notations used to express the pre-design constraints.

In the Figure 8, the point A refers to the projection in the plane (I,J) of the axis of the pivot joint between the car body and the lift gate which is in the same direction as K. A is assumed to be the origin of all the reference frames used in this section: (xA, yA, zA) = (0, 0, 0). θ stands for the lift gate opening angle (θ ∈ [0,80°]). γ represents the lift gate angle with respect to the vertical when the lift gate is closed. γ is constant under the assumption that the car is on a road with constant slope. According to the system under study and the pre-design goals, it seems reasonable to begin with a 2D analysis in the plane (I,J). Then, the definition of a CSP (X, D, C) further used to choose the fixation points M and N should be such that {xMB, yMB, xNL, yNL} ⊂ X where xMB, yMB are the 2D coordinates of M in the reference frame [IB, JB] linked to the car body (17) and xNL, yNL are the 2D coordinates of N in the reference frame [IL, JL] linked to the lift gate (18). More precisely, the 2D reference frames [IB, JB] and [IL, JL] respectively result from the 2D projection in the plane (I,J), P2D = [I, J]T, of the rotation (denoted Rotation) of [I, J] around K with an angle -π/2+γ and, respectively, -π/2+γ+θ: [IB, JB] = P2D.Rotation(K, -π/2+γ, [I, J] ))

 sin(γ )

cos(γ )

=   − cos(γ ) sin(γ )   sin(γ + θ )

cos(γ + θ )

[IL, JL] = P2D.Rotation(K, -π/2+γ+θ, [I, J] )) =   − cos(γ + θ ) sin(γ + θ ) 

(17) (18)

(17) and (18) will be respectively called the car body frame and the lift gate frame. As A is the origin (i.e. xA=0 and yA=0), the 2D coordinates of the fixation points M and N in the same (ground) frame can thus be respectively expressed as in (19) and (20):  xM   x MB    = P2D.AM = [IB, JB]   yM   y MB 

(19)

xN   x NL   y  = P2D.AN = [IL, JL]  y   N  NL 

(20)

The aim of the following of this subsection will be an explicit formulation of the constraints related to the test cases: Test case 1: “The additional force (scalar) value ∆F required to maintain the lift gate static equilibrium has to be inferior to a threshold level denoted ∆Fmax”. The additional vector force ∆F is defined such that FC = FS + ∆F, where FC is the cylinder force required to maintain the 13

static equilibrium and where FS is the force of the spring within the power cylinder used to downsize the electrical motor. Following the relation FC // MN, let uMN be a unit vector oriented from M to N. Substituting FCuMN for FC in the static equilibrium vector equation (eq. 14) projected along K allows to link the cylinder force FC to the parameters defining the configuration of the power lift gate system: FC = -(AG×P)•K / (AN×uMN)•K

(21)

In (21), the × and • respectively stand for the cross product and the dot product operators. Denoting m the lift gate mass and g the magnitude of the gravity field, the weight force is P = -mgJ. The coordinates of the vector AN are (xN, yN) in the reference frame (A,I,J) and a constant r such that: AG = rIL is assumed to be known. Moreover, the magnitude of the spring force FS can be expressed as FS = k(l0-||MN||) where k is the stiffness coefficient of the cylinder spring and l0 is a constant related to the free length of this spring. In order to downsize the electrical motor as much as possible, the constraint C∆F aims at imposing that the additional force remains inferior to a threshold level denoted ∆Fmax. Obtaining an expression of the constraint C∆F as required to formulating a CSP leads to a set of tedious formal substitutions that can easily be achieved by a symbolic computation software. More precisely, C∆F should be such that ∆F is expressed as a function of the design parameters, that is to say, the variables xMB, yMB, xNL, yNL in the proposed study. Such an approach aims at reducing as much as possible the number of variables of the CSP and, consequently, to reduce the dimensionality of the search space which often constitutes an obstacle when a rather precise paving of the solution set is expected as output. The sequence of formal substitutions used to automatically express ∆F as a function of the design parameters (xMB, yMB, xNL, yNL) is reported in the equations (22) and (23).

∆F = FC(AG(r,IL(γ, θ)), AN(xN, yN), uMN(xM, yM, xN, yN), P(m, g)) … - FS(xM, yM, xN, yN, k, l0) {xM, yM, xN, yN}(xMB, yMB, xNL, yNL, θ, γ)

(22) (23)

Consequently, an expression of ∆F as a function of the design parameters (xMB, yMB, xNL, yNL) also depends on the opening angle θ and on a constant parameter vector:

∆F(xMB, yMB, xNL, yNL, θ, [γ, m, g, k, l0])

(24)

∆F not only depends on the design parameters (xMB, yMB, xNL, yNL), but also on the lift gate opening angle θ ∈ [θ], where [θ] is the interval [θmin, θmax] = [0°, 80°] in the application example. The formulation of the test case implies that ∆F should be inferior to ∆Fmax in any case, and, in particular, for any value of θ ∈ [θ]. The constraint can be thus formalized as follows: C∆F : ∀θ ∈ [θ], |∆F(θ, xMB, yMB, xNL, yNL)| ≤ ∆Fmax

(25)

Let C∆F(θ) be the constraint defined for a fixed real value of θ as: C∆F(θ): |∆F(θ, xMB, yMB, xNL, yNL)| ≤ ∆Fmax

(26)

14

A direct evaluation of C∆F([θ]) is too restrictive to provide any result in practice because [θ] is a large interval and the dependency on θ is lost between its many occurrences in the expression of ∆F(θ, xMB, yMB, xNL, yNL). A usual way to keep some dependencies into account consists in partitioning the domains in order to deal with smaller intervals. Here, in order to limit the search space to X = {xMB, yMB, xNL, yNL}, the interval [θ] has been partitioned into a set of p (smaller and contiguous) intervals, [θ] = [θ]1 ∪ … ∪ [θ]p. Then, a new formulation of the constraint related to the test case is derived: C∆F([θ]1:p) : { C∆F([θ]1), …, C∆F([θ]p) }

(27)

According to (27), C∆F([θ]1:p) is a set of p constraints of the form C∆F([θ]i). The single original constraint C∆F is thus turned into a set of p constraints as indicated in (27). This strategy is made possible because the search space variables are the coordinates of M in the car body frame and the coordinates of N in the lift gate frame. Otherwise, the coordinates of M (respectively N) would not be consistent for the different values of [θ]i and the problem formulation would be then unnecessarily over-constrained.

Test case 2: “The electric cylinder length L has to remain within the interval [Lmin, Lmax]”. Following a similar approach as the one detailed for the test case 1, a first expression of the constraint CL related to the test case 2 is CL : Lmin ≤ L ≤ Lmax. Considering that L = ||MN||, expressing L as a function of the design parameters leads to L(xMB, yMB, xNL, yNL, θ, γ). Under the assumption that γ is constant (it will be omitted in the following for the sake of clarity), CL can be reformulated as: CL : ∀θ ∈ [θ], Lmin ≤ L(θ, xMB, yMB, xNL, yNL) ≤ Lmax

(28)

Instead of introducing a partition of [θ] as in the formulation of the constraints related to the test case 1, the monotone increase of L with respect to θ within a large part of the search domain of interest in the power lift gate application allows to reformulate (28) as: Monotone increase of L wrt θ ⇒ CL : { Lmin ≤ L(θmin, …), L(θmax, …) ≤ Lmax }

(29)

For the pre-design to be correct, the monotone increase of L with respect to θ should be proven for any value of the design parameters. Even if it is not always easy a priori, the validation of that monotony assumption can be achieved a posteriori, when the pre-design refinement process has focused on a rather small area of the initial search space in order to satisfy the constraints related to all the test cases.

Test case 3: “The car body fixation point M has to be within a specified area”. The specification of an area on the car body where M should lie in can easily be formulated through a set of inequality constraints having the following form with a defined function B: CM : BM(xMB, yMB) ≤ 0

(30)

Test case 4: “The lift gate fixation point N has to be within a specified area”. Similarly to the test case 3 and (30),

15

CN : BN(xNL, yNL) ≤ 0

(31)

(30) and (31) only depends on the design parameters and, consequently, no transformation is required to introduce them in the formulation of the CSP used as input for the chosen interval solver. 3.3. Pre-design of the power lift gate system based on interval CSP In order to analyse and explore how the design parameters values are constrained by the constraints derived from the system requirements, the solution sets of several CSP have been searched using an interval solver (RealPaver). Some notations are first introduced to define those CSP before commenting the obtained results. Variables X2 = {xMB, xNL} X4 = {xMB, xNL, yMB, yNL}

Domains D2 = {[0, 1.5], [0, 1.5]} D4 = {[0, 1.5], [0, 1.5], [-0.2, 0], [-0.01, 0.02]}

Constants (among others) yMB = -0.1, yNL = 0.01 -

Table 2: Variables and domains used to formulate the CSPs used to analyse and explore the search space.

The pre-design of the power lift gate has been decomposed into the following steps: • Understanding the influence of the opening angle on the position of fixation points, • Choosing a partition of [θ] in order to find a reasonable trade-off between the number of constraints (small p) and the accuracy of the output paving (ideally, D? as small as possible): [θ]1:55 = {[0°,0.5°], …, [9.5°,10°], [10°,12°], …, [78°,80°]}. • Validation of the pre-design taking all the constraints related to [θ]1:p into account, • Refinement: selection of an area in the solution space.

Precision

Box nb

Time (s)

Understanding the influence of the opening angle: CSP1 = (X2, D2, {C∆F(0°), CL}) CSP2 = (X2, D2, {C∆F(40°), CL}) CSP3 = (X2, D2, {C∆F(80°), CL}) CSP4 = (X2, D2, {C∆F(0°), C∆F(40°), C∆F(80°), CL}) CSP5 = (X4, D4, {C∆F(0°), C∆F(40°), C∆F(80°), CL})

10-3 10-3 10-4 10-4 10-3

2.104 2.104 2.104 2.104 2.104

10 11 13 13 75

Validation of the pre-design: CSP9 = (X4, D4, {C∆F([θ]1:55), CL}) CSP10 = (X4, D4, {C∆F([θ]1:55), CL})

10-3 10-3

2.104 8.104

13×60 42×60

Refinement by choosing an area in the solution space: CSP11 = (X4, D4, {C∆F([θ]1:55), CL, CM, CN})

10-3

2.104

6×60

CSP

Table 3: Trace of the main pre-design steps based on interval CSP

Understanding the influence of the opening angle

16

(a) CSP1 : θ=0°

(b) CSP2 : θ=40°

(d) CSP4 : θ=0°, 40°, 80° : intersection of (a), (b), (c)

(c) CSP3 : θ=80°

(e) CSP5 : θ=0°, 40°, 80° Solution set in (xMB, xNL)

Figure 9: Understanding the influence of the opening angle

The Figure 9 illustrates the influence of the opening angle on the solution set and the influence of the dimensionality of the search space. Validation of the pre-design:

(a) CSP9, [θ]1:55 Solution set in (xMB, xNL)

(b) CSP10, [θ]1:55 Solution set in (xMB, xNL)

(c) CSP10, [θ]1:55 Zoom in (xMB, xNL)

Figure 10: Validation of the pre-design

In the Figure 10, the partition [θ]1:55 is used to express the constraints related to ∆F. this validates the first analysis reported in the Figure 9. Moreover, a longer (i.e. a more refined) search allows to enlarge the red set D1 corresponding to the regions where the CSP is guaranteed to be always satisfied. Refinement by choosing an area in the solution space

17

CM : { xMB ≥ 0.41, yMB ≤ -0.18, yMB ≥ 0.83xMB-0.55 }

(a) CSP11, Point M : Solution set in (xMB, yMB)

(b) CSP11, Point N : Solution set in (xNL, yNL)

(32)

(c) CSP11, Solution set in (xMB, xNL)

Figure 11: Refinement by choosing an area in the solution space

Focusing on an area in the search space corresponds to the refinement related to the predesign process. The reduced search area allows a more precise exploration while preserving a reasonable computation time. The proposed refinement iteration aims at being reproduced all along the pre-design process in order to converge toward the solution that will be kept to initiate the detailed design of the power lift gate.

Conclusion In this paper we have presented a proven solution for a global multi-domain constraintsbased pre-design supported by a robust design methodology in conformance with ISO IEEE 15288 System Engineering Standard. This solution, based on three interactive design environments (SysML, Topological modelling and Intervals analysis) and illustrated by a mechatronic example, demonstrates the power of collaborative engineering in model-based design. SysML allows one to define the high-level relationships between requirements and functional, structural and operational architectures of a system, but lacks detailed semantics to capture some domain-specific properties, for instance, geometry for mechanical systems. For this reason, the chosen modelling method based on a topological representation of the whole system, allows one to generate all multi-physical equations, including geometrical parameters. This approach improves the global optimization of both geometrical and physical parameters. Then, a refinement methodology based on a sequential decision process and on a declarative statement of constraints is shown to be well supported by the interval CSP paradigm. The use of an interval solver illustrates both the methodological interest in using such tools for pre-design purposes as well as the need to improve their scalability. This will be the subject of future works. As a result, Model-Based System Engineering simplifies the development of mechatronic and other multi-domain systems by providing a common approach for design and communication across different engineering disciplines.

18

References: [1] [2] [3] [4]

[5]

[6] [7]

[8]

[9] [10]

[11]

[12]

[13]

[14]

[15] [16]

IEEE 1220, Application Management of Systems Engineering Processes, the Institute of Electrical and Electronics Engineering, New York, 1998. ISO/IEC 15228, Systems lifecycle Processes, International Electro-technical commission, Brussels, 2001. Government Electronics & Information Technology Association EIA norm for Processes for Engineering a system. EIA Standard 632, April 1998. Jeff A. Estefan, “Survey of Candidate Model-Based Systems Engineering (MBSE) Methodologies”, Rev. B, May 23, 2008, http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf. Alan Hartman, D. Kreische (Eds) "Model Driven Architecture - Foundations and Applications", First European Conference, ECMDA-FA 2005 Nuremberg, Germany, November 2005 Proceedings Springer. Object Management Group, 2007, “OMG System modeling Language Specification” http://www.omg.org/cgi-bin/doc?ptc/07-09-01. R. Plateaux, O. Penas, A. Rivière, J-Y Choley, Need for the definition of a topological structure for the complex systems modelling, CPI 2007, Rabat, Morocco, October 22-24 2007. L. Jaulin, M. Kieffer, O. Didrit, and E. Walter, Applied interval analysis, with examples in parameter and state estimation, robust control and robotics. Springer, 2001. Raphael B., Smith I.F.C., Fundamentals of Computer-Aided Engineering, John Wiley & Sons Ltd, 2003. Yannou B., Simpson T.W., Barton R.R., Towards a computational design explorer using meta-modelling approaches and constraint programming. In DETC/DAC: ASME Design Engineering Technical Conferences / Design Automation Conference, Chicago, Illinois, USA, September 2-6, 2003. Bliek C., Spellucci P., Vicente L.N., Neumaier A., Granvilliers L., Monfroy E., Benhamou F., Huens E., Van Hentenryck P., Sam-Haroud D., Faltings B., Algorithms for solving non linear constrained and optimization problems: the state of the art, The Coconut Project, Deliverable D1, June 8, 2001. R. Plateaux, J-Y. Choley, O. Pénas, A. Rivière, F. Cardon, A. Clément. A piezoelectric mechatronic systems modelling based on a topological analysis. 7th France-Japan congress, Mechatronics 2008, Le Grand Bornand, France, May 2123, 2008. G. Kron, Tensor Analysis of Networks (New York: John Wiley & Sons, Inc., 1939), "A short course in tensor analysis for electrical engineers ". Wiley, New York; Chapman & Hall, London, 1942. 250 pp. Republished as Tensors for Circuits. With a new Introduction and List of Publications of Gabriel Kron. Dover, New York, 1959. F.H. Branin Jr., "The algebraic-topological basis for network analogies and the vector calculus ", in Proceedings of the Symposium on Generalized Networks, Polytechnic Institute of Brooklyn, 1966. Ø. Bjørke, "Manufacturing systems theory – a geometric approach to connection ", Tapir publisher, ISBN 82-519-1413-2, 1995. Aughenbaugh J. M., Paredis C. J. J., Why are intervals and imprecision important in engineering design ? NSF Workshop on Modeling Errors and Uncertainty in Engineering Computations, REC’2006, hosted by Georgia Tech Savannah, February 22-24, 2006.

19

[17] L. Granvilliers, RealPaver user’s manual : solving nonlinear constraints by interval computations, Edition 0.3, for RealPaver Version 0.3, Institut de Recherche en Informatique de Nantes (IRIN), July 2003, http://www.sciences.univnantes.fr/info/perso/permanents/granvil/realpaver/src/realpaver-0.3.pdf. [18] L. Granvilliers, F. Benhamou. Algorithm 852: Realpaver: an Interval Solver using Constraint Satisfaction Techniques. ACM Transactions on Mathematical Software, 32(1):138-156, 2006.

20