Combining Mathematical Programming and SysML ...

Proceedings of the ASME 2010 International Design Engineering Technical Conferences & Computers and Information in Engineering Conference Proceedings of the ASME 2010 International Design Engineering Technical Conferences & IDETC/CIE 2010 Computers and Information in Engineering Conference August 15-18, 2010, Montreal, Quebec, Canada IDETC/CIE 2010 August 15-18, 2010, Montreal, Quebec, Canada

DETC2010-28 DETC2010-28960

COMBINING MATHEMATICAL PROGRAMMING AND SYSML FOR AUTOMATED COMPONENT SIZING OF HYDRAULIC SYSTEMS

Aditya A. Shah The G.W. Woodruff School of Mechanical Engineering Georgia Institute of Technology Atlanta, Georgia, 30332 Email: [email protected]

Christiaan J.J. Paredis∗ The G.W. Woodruff School of Mechanical Engineering Georgia Institute of Technology Atlanta, Georgia, 30332 Email: [email protected]

Roger Burkhart Deere & Company Moline, Illinois, 61265 Email: [email protected]

Dirk Schaefer The G.W. Woodruff School of Mechanical Engineering Georgia Institute of Technology Savannah, Georgia, 31407 Email: [email protected]

ABSTRACT In this paper, we present a framework that improves a designer’s capability to determine near-optimal sizes of components for a given system architecture. Component sizing is a hard problem to solve because of competing objectives, requirements from multiple disciplines, and the need for finding a solution quickly for the architecture being considered. In current approaches, designers rely on heuristics and iterate over the multiple objectives and requirements until a satisfactory solution is found. To improve on this state of practice, we introduce advances in the following two areas: a) Formulating a component sizing problem in a manner that is convenient to designers and b) Solving the problem efficiently so that all of the imposed requirements are satisfied simultaneously and the solution obtained is mathematically optimal. An acausal, algebraic, equation-based, declarative modeling approach using mathematical programming (GAMS) is taken to solve these problems more efficiently. In addition the Systems Modeling Language (OMG SysMLTM ) is used to formulate component sizing problems to facilitate problem formulation, model reuse

∗ Address

all correspondence to this author.

and the automatic generation of low-level code that can be solved using GAMS and its solvers (BARON). This framework is demonstrated by applying it to an example of a hydraulic log splitter.

KEYWORDS MINLP, CSP, Mixed Integer Non-Linear Programming, Constraint Satisfaction Problems, SysML, Model Transformations, Component Sizing, Algebraic Equations, GAMS

INTRODUCTION In this paper, we focus on improving a designer’s capability to determine component sizes, such as during the architecture exploration phase in the design process. This can lead to more efficient ways of exploring large design spaces and ultimately allow a designer to consider more alternatives earlier in the design phase. The need to consider more alternatives is increasing because the design of modern systems is becoming increasingly complex, not only due to the associated 1

c 2010 by ASME Copyright

core technology of the system, but also due to the large number of often competing requirements that the system must simultaneously satisfy. These requirements come from a multitude of stakeholders involved in different engineering domains [1]. As a result, determining component sizes early in the design phase is hard. This is made more clear by understanding the role of component sizing and architecture exploration in design. The process of design can be considered as problem solving involving a repeated sequence of two steps: Synthesis and Analysis. Synthesis involves the process of generating a complete specification of a system. This includes the architecture (also known as topology) as well as the sizes for the components of the system. With a complete specification available, the analysis process determines the extent to which the system satisfies the requirements. For instance, a dynamic simulation or traditional machine design for a system is a type of analysis. Component sizing is a part of the synthesis process in which appropriate sizes for a particular architecture are determined to enable its subsequent analysis. The result of component sizing is a set of specifications while in analysis the result is a set of performance metrics. Component sizing is part of the architecture exploration phase because it is possible to reject or not even consider a near-optimal solution due to improper component sizing methods. Component sizing problems can be hard to solve and formulating them is also time-consuming. Component sizing is hard due to a number of factors, some of which are as follows. The large number of requirements imposed on the system come from different disciplines (cost, mass, performance, etc.), resulting in multiple competing objectives that must be handled simultaneously. Moreover, the requirements themselves are often formulated as inequalities, such as “The force shall be greater than x N” or “The cost shall be less than y dollars”. In such cases, it becomes non-trivial to find good sizes that satisfy all the requirements simultaneously and is near-optimal, i.e. it is difficult to find a better solution than the one obtained. In addition to being hard to solve, the formulation of component sizing problems is a time consuming effort. Due to the presence of numerous inequality relations it is often necessary to change the problem formulation based on the assumptions that have been made. For instance, a designer may use a different method to size a system given an engine specification versus sizing a system given a cylinder specification. Moreover, it is often difficult to formulate a representation that can take into account all of the aspects of the problem (multiple analyses, requirements in terms of inequalities, competing objectives). In this paper, therefore, a framework and tool is presented that can help designers not only find “good” component sizes quickly, but also help in conveniently formulating the problem during the design phase. In order to accomplish this, we use

an approach that consists of using constrained optimization for solving a problem and a model-based approach for formulating a problem. In particular, we use the acausal, algebraic, equation-based, declarative modeling approach of GAMS (General Algebraic Modeling System) and its associated solvers to solve a sizing problem, while the Systems Modeling Language by the Object Management Group (OMG SysML) [2] is used to formulate the problem. SysML is not an executable language; therefore model transformations are used to automatically generate executable GAMS code from SysML models. In this way, we can leverage the capabilities of existing solvers present in GAMS as well as the modeling formalisms present in SysML. Through the use of an example problem related to the component sizing of a hydraulic fluid power system, we demonstrate this process of describing the system in SysML and automatically transforming it into an executable model that can be solved in GAMS. The remainder of this paper is organized as follows. In the next section, related work is presented; thereafter, we describe the proposed framework for component sizing using SysML and GAMS. Next, we discuss the example problem and present results associated with using the proposed framework. Finally, conclusions and future work are discussed.

RELATED WORK AND THE USE OF GAMS AND SYSML FOR COMPONENT SIZING In this section, related work for component sizing is discussed from two perspectives: automated efforts for solving sizing problems and different ways of representing component sizing problems. Based on this, we describe the use of GAMS (General Algebraic Modeling System) and SysML for solving and representing component sizing problems respectively. Automated Efforts for Solving Component Sizing Problems In this section, we review two main approaches: Knowledge-based engineering (KBE) and Constraint Satisfaction Problem (CSP) based approaches. Based on the limitations of KBE approaches, we discuss an alternative approach using CSPs and discuss related work involving CSPs. Thereafter, we discuss the use of the General Algebraic Modeling System (GAMS) in this research for solving component sizing problems. The idea of automating design tasks and capturing knowledge through computers gained momentum through the use of Knowledge-Based Engineering (KBE) in the 1980s with the advent of artificial intelligence and expert systems [3, 4]. These efforts were characterized by two main features: a. Use of detailed design knowledge and b. Heuristics for sizing. For instance, this initial effort was strongly focused on the generation 2

c 2010 by ASME Copyright

of geometry during the detailed design phase, resulting in a variety of commercial CAD software such as Knowledge Fusion (part of NX by Siemens PLM) or KnowledgeWare (part of Catia by Dassault Syst`emes). These tools were typically add-ons to existing mechanical CAD tools and usually required low-level design knowledge (e.g., modeling mass based on complex relations between material properties and detailed geometry). Concurrently, in the hydraulics domain, a few efforts toward KBE have been reported in the literature [5–10]. In particular, da Silva developed an expert system for configuring hydraulic components based on a high-level characterization of loading conditions [9]. This expert system is entirely rule-based and does not involve any analysis models. Its heuristics can identify a reasonable configuration among the known hydraulic circuit configurations, but does not attempt any component-level or system-level optimization. The framework presented in this paper differs from the above mentioned approaches in two distinct areas, namely:

At a high-level, there are different types of constraints associated with the design of a product, such as behavioral constraints (e.g. fundamental laws of nature) that are not controllable by the designer as well as requirements that reflect a designer’s preferences and goals. In both cases, it is possible to formulate design problems in terms of variables and constraints with the intent of selecting values for the variables that satisfy all of the constraints simultaneously. Such a formulation is known as a Constraint Satisfaction Problem (CSP) and has been commonly used in many different areas, such as artificial intelligence, operations research and computer science since the 1960’s [15]. Moreover, algorithms to solve such problems have also been in development and have become increasingly powerful at solving problems belonging to a wide variety of domains [16]. The declarative nature of constraints in CSPs are one of its main advantages. A designer can specify constraints without worrying about causality; therefore multiple alternatives can be explored using the same set of constraints. In spite of these advantages, CSPs are not that widespread in engineering design. In the literature, the use of CSP for engineering design has been reported by Chenouard et al. [17], O’Sullivan [18] and others. One of the reasons for the limited use of CSPs is that CSP tools are not well known within the community; therefore, it is perceived to be difficult to formulate problems for a particular CSP tool. In addition, different solvers may be preferred depending on the problem requirements and type [17]. There are different languages and solvers available depending on the type of CSP. For discrete CSPs, common solvers include Gecode [19], Choco [20], and others. However for the continuous case, which is common in engineering, there are a limited number of tools, such as Elisa [21], RealPaver [22], BARON [23], etc. In this framework we use GAMS (General Algebraic Modeling System), a “high-level modeling system for mathematical programming and optimization” [24]. GAMS supports a variety of solvers for different types of optimization problems. This is advantageous from a framework and tool perspective, since solvers can be changed for different problems while using the same modeling language. GAMS is well-suited for mathematical programming, which is commonly found in operations research in which problems can be described without the need for subsystems and components. Moreover there are solvers such as BARON that support MINLP (Mixed-Integer Non Linear Programming) problems, which is the common class found in engineering. However, GAMS is not well suited for describing engineering design problems due to their hierarchical nature. Engineered systems are commonly composed of multiple levels of subsystems that ultimately consist of individual component models. In addition, there is a large amount of model reuse in engineering systems and corresponding design problems, such as using multiple cylinders within a hydraulic system. These

1. The use of tradeoff models [11] instead of low-level detailed design models that rely on physical principles 2. The use of analysis models instead of heuristics Low-level models are used to establish relations between the sizing attributes of components, such as maximum power output, cost or mass. However, such low-level models are not usually available during system-level decision making. As an alternative, tradeoff models that consist of discrete observational data from existing components (supplier catalogs) or continuous models fitted using the discrete data are used. By definition, a tradeoff model is an “abstract representation of a system in terms of a predictive relationship between its top-level attributes” [11]. Therefore, we utilize discrete component data to establish system-level relations between component attributes. In addition to tradeoff models, analysis models are used in place of heuristics. In the context of this research, the analysis models consist of algebraic equations that describe a model’s performance as well as the physical laws that it must obey at component interfaces where energy flow takes place. For instance, in the electrical domain this refers to the two Kirchoff’s Laws, in which the potentials between two connections are equal and the currents flowing in and out of each connector sum-to-zero. These principles are found in other domains as well in which some kind of energy flow takes place between components. Consequently, it is possible to define self-contained analysis models that can be connected together to form larger systems. The approach for automating this connection behavior is similar to approaches used in languages such as Modelica [12, 13] (a dynamic simulation language). In this way, component sizing can be viewed as a two part process. First, constraints are specified that limit a designer’s selection (analysis models), and then the different alternatives that satisfy these constraints are explored (tradeoff models) [14]. 3

c 2010 by ASME Copyright

characteristics imply the need for an object-oriented perspective and different semantics, which GAMS and other CSP tools do not support.

Languages (DSLs) and model transformations, which has its roots in model-based software development concepts as well as recent applications in systems engineering [27]. In particular, we discuss the process of representing the analysis knowledge related to component sizing in SysML in a form that is convenient to designers. Along with capturing this analysis knowledge, we discuss the process of transforming such a representation into a form that can be solved by external solvers in GAMS. The approach presented in this paper involves the following steps:

Representing Component Sizing Problems There has been a recent trend in the CSP tools described in the previous section to separate the process of defining and solving problem, such as Zinc [25] for discrete CSPs or GAMS for mathematical programming problems. However, there is limited to no support for object-oriented modeling of CSP problems, even if the tool is used within an object-oriented language such as Java or C++. This is a major limiting factor for CSPs to be used in the design of engineered systems. One example of research in this direction is by Chenouard et al., in which they implemented a platform (s-COMMA GUI) that allows users to graphically define constraint models [26]. However, some of its features restrict its use in engineering design, such as limited support for defining continuous CSPs as well as continuous CSP solvers (only RealPaver). In addition, it is a custom GUI in which only constraint models can be defined. Therefore, we propose to integrate an external modeling language with GAMS, in order to leverage the existing capabilities provided by GAMS. There are different options available for this, some of which are discussed below. There are a variety of formal languages available that can be used for representing component sizing problems, such as UML (Unified Modeling Language), OWL (Web Ontology Language), AutoSAR (AUTomotive Open System ARchitecture), AADL (Architecture Analysis & Design Language), ACME (ACME Architectural Description Language and Design Environment) and SysML (Systems Modeling Language). Custom languages are not considered since the use of standardized languages would promote its adoption by industry. SysML has a number of advantages compared to other languages, such as standardized Systems Engineering constructs. This is unlike languages like OWL, in which all of the constructs must be defined by the application developer. In addition, there is commercial tool support, growing community of users in industry and academia, and it is easily customizable. This ability to customize SysML is an important advantage which is used to define semantics specifically for GAMS and component sizing. This process of extending mathematical programming of GAMS in SysML is described in the next section.

1. Formal Capture of GAMS Domain Using Metamodels. 2. Representing GAMS Compliant Models in SysML using Profiles 3. Model Transformations to Support Hierarchical Object-Oriented Modeling In the following sections, we discuss each of these steps in detail. Formal Capture of GAMS Domain Using Metamodels In order to support the representation of the component sizing problem in SysML and its solving in GAMS, the system model is formally described in SysML. This would provide a structured and object-oriented way to process the model into GAMS. When dealing with a single tool, this is normally done through internal data-models that are customized for the particular software tool, such as the source code for GAMS. Instead of using this internal data-model we use a metamodel to describe the concepts appearing in a valid model as well as to represent the links between these concepts, such as inheritance and composition. To support model and metamodel driven systems, OMG established the Meta Object Facility (MOF) standard, which provides a framework for “defining, manipulating, and integrating meta-data and data in a platform independent manner” [28, 29]. Since we want to extend the functionality supported by mathematical programming tools such as GAMS, the approach we have taken is to convert the implicit metamodel for GAMS (i.e., the data structures used internally) into a formal and explicit metamodel compliant with the MOF standard. In addition, we extend the GAMS metamodel to support additional features such as object-oriented modeling. The GAMS metamodel is shown in Fig. 1, in which the constructs in GAMS are represented as classes (GamsSolve, Model, GamsVariable, etc.). According to mathematical programming approaches in GAMS, the model that gets passed onto a solver consists only of a collection of equations. As a result, a GAMS model is flat i.e., there is no concept of a class or visibility (public / private). To overcome this, we establish associations (A_owner_ownedModels, A_model_variables) to define the scope of constructs within models. Through the use of such a metamodel, we can

EXTENDING MATHEMATICAL PROGRAMMING OF GAMS USING SYSML In this section, we present our approach for using SysML to extend the current mathematical programming formalism of GAMS to model and solve component sizing problems. This process is based on the specification of Domain Specific 4

c 2010 by ASME Copyright

pkg [Profile] GamsProfile[

GAMSProfile]

GamsSolve nam : Strin modelTyp : Strin optimizeDirectio : Strin mode : Mode solverType : Strin objVarNam : Strin

solve

nam : Strin mode : Mode domainNam : Strin type : Strin

1

_gamsSolve_model model

«stereotype» Block [Class]

GamsVariable

variables

*

model

1

1

-isEncapsulated : Boolean [0..1]

«stereotype» GamsSolve [Class]

_model_variables owner

-modelType : GamsModelType [1] = minlp -optimizeDirection : GamsOptimizeDirectionKind [1] = minimize -solverType : GamsSolverType [1] = BARON -objVarName : String [1] = null

_owner_ownedModels

Model

GamsMode

0..1

nam : Strin equation : GamsEquatio [* solve : GamsSolv ownedModels : Mode [* owner : Mode variable : GamsVariabl sets : GamsSe [* parameter : GamsParamete [*

ownedModels

GamsSet nam : Strin

model

set

1

*

_model_sets

model

1

model

1

*

equations

*

parameters

GamsParameter nam : Strin specification : Strin mode : Mode domainNam : Strin

«metaclass» Port

«metaclass» Property

*

_model_parameters

«stereotype» GamsModel [Class]

specification : Strin mode : Mode domainNam : Strin

«stereotype» GamsVariable [Property]

«stereotype» OwnedGamsModel [Property]

-causality : GamsCausality [1] = inout

-flowFlag : FlowFlag [1] = nonflow -sizing : SizingFlag [1] = non-sizing -domain : ValueProperty [0..*] -domainName : String -type : GamsVariableType [1] = free

_model_equations

«stereotype» GamsPort [Port]

GamsEquation definitio : Strin nam : Strin mode : Mode domainNam : Strin

«metaclass» Constraint {com.nomagic.magicdraw.validation.rules.ConstraintRules.isConstraintValid, com.nomagic.magicdraw.validation.rules.OpaqueExpressionRules.mustHaveExpression}

FIGURE 1. GAMS METAMODEL DEFINITION. SEMANTICS OF GAMS ARE REPRESENTED AS OBJECTS IN THE METAMODEL.

«stereotype» GamsSelectionConnectionEquation [Constraint]

«stereotype» GamsEquation [Constraint]

«stereotype» GamsPhysicalConnectionEquation [Constraint]

-domainName : String

now customize SysML to support these features and thereafter transform from a SysML representation to an executable representation in GAMS. This customization of SysML is done through profiles, which is discussed in the next section.

FIGURE 2. PROFILE TO EXTEND MATHEMATICAL PROGRAMMING SEMANTICS IN SYSML. USED TO ENABLE OBJECT-ORIENTED MODELING OF COMPONENT SIZING PROBLEMS IN SYSML

Representing GAMS-Compliant Models in SysML Using Profiles In order for SysML to be used for modeling a particular type of problem, in this case component sizing problems, the necessary semantics must be included within SysML. Since SysML is a general purpose modeling language, it lacks the detailed, formal semantics needed for representing a problem in a domain-specific way [30]. For instance, without customization, GAMS-specific semantics such as variable or parameter or set would all be represented using the same SysML construct (property). Consequently, there is model ambiguity when converting it to an executable format. In addition, it can be cumbersome for domain experts to create models in SysML, thereby limiting the acceptance of general SysML for specific domains. To overcome this limitation SysML provides several mechanisms for customization, such as customizing the SysML Profile with new constructs or defining profiles that extend existing SysML/UML constructs [31]. Profiles are preferred since they do not modify the underlying UML metamodel, thereby retaining tool support. A portion of a profile created

for representing component sizing problems based on GAMS semantics is shown in Fig. 2. The profile is constructed as per the MOF metamodel (Fig. 1). For instance variable, parameter and set each have their own stereotype defined but all extend the SysML Property class. As previously discussed, mathematical programming languages such as GAMS are not suited for representing design problems. Therefore, in addition to constructs related to GAMS, we define new stereotypes to extend conventional mathematical programming semantics and support new features such as hierarchical modeling and the capturing of the physics related to energy-based systems that are typically encountered during engineering design. Model hierarchy is established through existing composition associations in SysML and this allows the designer to logically decompose a system into its individual components. A common feature found in energy-based systems is the existence of interfaces through which energy is transferred between components. To support this, we extend the concept of Port and Connection in SysML to identify the connections 5

c 2010 by ASME Copyright

Source Metamodel

Refers to

Conforms to Source View

Transformation Definition

Refers to

Executes Reads

Transformation

GamsModelUsage2GamsModelPartProperty to link a topLevelGamsModelPartProp object of type Property in SysML to a topLevelGamsModel object of type GamsModel in the GAMS metamodel (refer Fig. 4). Model transformations are then defined using the correspondence metamodel to relate elements of the source and target views with one another. The transformations are written in a declarative and graphical manner through the use of story diagrams [35]. The model transformations described in this paper are defined in MOFLON, which automatically generates Java Metadata Interface (JMI) code that implements the transformations in Java. This JMI code is combined with a JMI-compliant SysML tool, such as Magic Draw [36], in the form of a plugin that can be executed from within SysML. These transformations have a left-hand side (pattern of a graph to be matched) and a right-hand side (replacement graph). One such transformations is shown in Fig. 4, in which the input is a SysML block (stereotyped with GamsSolve) that contains solver information and the model to be solved. The output of this model transformations is the creation of an equivalent model based on the GAMS metamodel defined previously. In this way, a sequence of model transformations are executed to solve a component sizing problem described in SysML using solvers in GAMS (Fig. 5). In conclusion, we have shown that it is possible to extend the mathematical programming formalism of GAMS to support the definition and solution of component sizing problems, which is a part of the engineering design process. In the next section, we present an example problem related to fluid power using the framework presented in this paper.

Target Metamodel Conforms to

Writes

Target View

FIGURE 3. PROCESS OF MODEL TRANSFORMATION FROM SOURCE TO TARGET MODEL (Czarnecki et al. [33])

between the interfaces of the components. We can then encode the logic of these connections within SysML and automatically generate the corresponding equations. This logic is based on the law of energy conservation and can generally be formulated through two equations: a sum-to-zero equation for flow variables (e.g. force, flow, torque) and and equality equation for potential variables (e.g. pressure, velocity, angular speed). This is a generic logic that applies to multiple domains including fluid power, mechanics (translational / rotational). These additional capabilities are defined within SysML, thereby making it easier for designers to create new circuits and analyze them. Thus, the combination of profiles and metamodels provides the framework in which model transformations can be applied to automatically execute a design problem specified in SysML. This is discussed in the next section on model transformations. Model Transformations to Support Hierarchical Object-Oriented Modeling As discussed in the previous sections, our SysML profile extends the mathematical programming formalism by supporting hierarchical modeling as well as capturing physics-based connection knowledge while the MOF metamodel mainly defines GAMS-specific constructs. Therefore, model transformations are used to convert the SysML model into an intermediate object-oriented GAMS model which is then transformed into a flat executable GAMS model that can be solved by external solvers. Since the domain MOF metamodel and SysML profile can be described in terms of graphs [32], graph transformations can be used to transform between the different views and models. In this case, the domain semantics (metamodel and profile objects) represent the nodes, and associations represent the edges. As is shown in Fig. 3, the transformations are defined in a declarative fashion at the meta-model level and are then compiled into an executable that performs the transformations at the user-model level. A correspondence metamodel is used to maintain relations between the elements of the input SysML model and the resulting GAMS model [29, 34]. This is necessary when retrieving information from the solver’s output to update the SysML model. Although not shown in this paper, an example of a correspondence link involves using an object gmu2gmpp of type

HYDRAULIC LOG SPLITTER DESIGN EXAMPLE In this section, we discuss the application of our framework to a case study of sizing a hydraulic log splitter. Problem Description The example considered in this paper is that of a horizontal acting hydraulic log splitter (Fig. 6). A log splitter is a system used to divide roughly cylindrical pieces of wood into two or more pieces, generally longitudinally along the grain of the wood. Log splitters are usually portable and so the critical requirements include the ram force available to split the log, total cycle time involved, total mass, and total cost of the machine. These attributes represent competing objectives, out of which the designer must make tradeoffs to find a specification that satisfies all of them simultaneously. We limit the scope to the hydraulic subsystem; the mechanical structure is not considered. In Fig. 7, a block diagram of the log splitter is shown. The subsystems that are considered include a gas engine, hydraulic fixed displacement 6

c 2010 by ASME Copyright

SysML2Gams::createDslStructure (solveBlock: Class): GamsSolve

SysML Activity Diagram [

XformSequence]

Solve Block in SysML create corresponding GamsSolve object in DSL, independent of SysML

Generate Physical Connection Equations solveBlock gamsSolveBlock «create»

Generate Sizing Connection Equations

GamsSolveBlockToGamsSolve gsb2gs

«create» gsb2gs :GamsSolve2GamsSolveBlock

Transformation to Convert SysML Model to MOF Model (as per GAMS Metamodel)

gs2gsb

GamsSolveToGamsSolveBloc «create» gamsSolve

«create» Transformation to Convert MOF Model to Flattened MOF Model

gamsSolve :GamsSolve name := solveBlock.getName()

modelType := getTaggedValue(solveBlock, "GamsSolve", "modelType" optimizeDirection:= getTaggedValue(solveBlock, "GamsSolve", "optimizeDirection"

Print Flattened Model into a GAMS executable text file

solverType := getTaggedValue(solveBlock, "GamsSolve", "solverType") objVarName := getTaggedValue(solveBlock, "GamsSolve", "objVarName"

Execute Model using Solvers in GAMS

Update SysML Model with Results

A block can have multiple owned elements. Iterate through all and find property whose type is of stereotype "GamsBlock". Then solveBlock

1: //dispMsg("Prop1 name: "+prop1.getName()

owner

A_ownedElement_owner ownedElement

FIGURE 5. SEQUENCE OF MODEL TRANSFORMATIONS TO SOLVE THE COMPONENT SIZING PROBLEM. CONVERTS FROM SYSML MODEL TO GAMS EXECUTABLE MODEL AND RETURNS OUTPUT OF SOLVER TO SYSML

topLevelGamsModelPartProp :Property

[ each time ]

[ else ] //Statement [ checkAppliedStereotype(topLevelGamsModelPartProp, "OwnedGamsModel ]

topLevelGamsModelPartProp

Log Loading & Splitting Area

«create» topLevelGamsModel :GamsModel

gamsModelPartProperty

[ end ]

Directional Control Valve

name := topLevelGamsModelPartProp.getName()

Engine & Pump

«create»

PartPropertyToGamsMode

gamsModel «create»

GamsModelUsageToPartPro gmpp2gm

Hydraulic Cylinder & Ram

model

A_gamsSolve_mode

gm2gmupp

«create» gmu2gmpp :GamsModelUsage2GamsModelPartProperty

«create» solve

gamsSolve

1: addGamsModelFromGamsModelProperty(topLevelGamsModelPartProp, topLevelGamsMode

gamsSolve

FIGURE 4. MODEL TRANSFORMATION TO CONVERT SYSML MODEL TO MOF MODEL (AS PER GAMS METAMODEL)

(credit: Dave Thompson)

FIGURE 6. SPLITTER

pump, directional control valve, double acting cylinder, load and tank. Since the system is horizontal, only a horizontal load requirement is considered. As discussed in the Introduction, we restrict ourselves to a specific configuration and consider the problem of automatically sizing the components under different scenarios. The log splitter considered in this paper possesses the characteristics that belong to larger, more complex models. This includes the presence of multiple types of interfaces (hydraulic, translational, rotational) as well as competing objectives

Engine

A HORIZONTAL ACTING HYDRAULIC LOG

Pump

Directional Control Valve

Tank

Cylinder

Load

Hydraulic Connection Mechanical Rotational Connection Mechanical Translational Connection

FIGURE 7. A BLOCK DIAGRAM FOR A HORIZONTAL ACTING HYDRAULIC LOG SPLITTER

7

c 2010 by ASME Copyright

(minimize cost versus maximize force). The implementation of our framework is discussed in more detail in the following sections.

ibd [GamsModel] OpenCenterCkt[

f

l

a

n

g

e

A

OpenCenterCkt ]

:

T

r

a

n

s

C

o

n

n

e

c

t

o

r

F

P

cylinder : CylinderFP

«GamsPhysicalConnection»

fixed : FixedFP

f

l

a

n

g

e

B

flange : TransConnectorFP

Mathematical Representation of Requirements in SysML One of the features of SysML is the ability to model requirements and assign dependencies between requirements and model elements. In the case of component sizing, the requirements help to define the composition of the system in terms of relevant analyses as well as define requirements mathematically in terms of constraints. In Fig. 12 (see Appendix), a SysML requirements model is shown in which requirements are decomposed hierarchically until they can be described mathematically. For instance, the forward phase hydraulic analysis consists of two requirements: the force produced by the cylinder should be greater than a specified limit and the maximum pressure in the circuit should be less than the specified max pressure. In this way, requirements modeling helps to derive mathematical constraints that are then included in the SysML analysis model, which is described in the next section.

valve : ValveFP

portA «GamsPhysicalConnection»

portA portB portT

p

o

r

t

B

«GamsPhysicalConnection» «GamsPhysicalConnection»

portP : FluidConnectorFP «GamsPhysicalConnection»

portP : FluidConnectorFP pump : PumpFP

portT «GamsPhysicalConnection»

flange : RotConnectorFP portP

portT

«GamsPhysicalConnection» tank : TankFP

flange : RotConnectorFP engine : EngineFP

FIGURE 8. SYSML INTERNAL BLOCK DIAGRAM (IBD) VIEW FOR THE HYDRAULIC OPEN CENTER CIRCUIT. A DESIGNER CAN CONSTRUCT CIRCUITS BY CONNECTING COMPONENTS TOGETHER. EQUATIONS ARE AUTOMATICALLY GENERATED FOR THE CONNECTIONS BETWEEN PORTS (BASED ON ENERGY CONSERVATION)

SysML Representation of a Component Sizing Problem As discussed in the previous section, requirements modeling helps in decomposing a problem into different analyses such as fluid power analysis, cost analysis and mass analysis (see Appendix Fig. 13). In addition, analyses such as the FluidPower Analysis can be composed of multiple use-phases, each describing a particular state or period of time in the system’s operation. For instance, in the log splitter case, we consider two independent use-phases - the forward motion of the cylinder and its reverse motion. The next level of decomposition involves the fluid power circuit, which in turn is composed of individual component models connected together. In Fig. 8, an Internal Block Diagram for the hydraulic circuit is shown. By defining transformations to capture connection equations, it is possible to specify circuits through individual component models and their connections. In this way, we can compose a SysML model representing the algebraic behavior of the system. Another important feature of the SysML model involves specifying the sizing variables and ensuring their consistency throughout the model. When describing a problem in terms of multiple analyses, variable duplication is likely. This is because each analysis uses different models that all refer to the same hydraulic component. For instance the forward and reverse use phases each contain a cylinder model that has a variable for bore diameter, which is a sizing variable for the Cylinder component. From a systems perspective, the selection of the Cylinder depends on both use-phases. Therefore, to ensure that the same sizing variable is referred to throughout the system model, we establish a separate system sizing model

(SystemSizingDescription – see Appendix, Fig. 13) that contains the sizing variables used throughout the system. We then explicitly define connections between component models used in the analyses with the component models included in the system sizing model (SystemSizingDescription – see Fig. 9). Constraints are then automatically generated for all of the variables included at each end of the connection, since both ends of the connection refer to the same sizing model. The system sizing model also contains models related to sizing options i.e., either discrete values corresponding to catalog entries or continuous models corresponding to fitted tradeoff models (see Malak et al. [11]). In this way, a complete component sizing model for the log splitter is defined. Then through model transformations executable GAMS code is generated that can be solved using available solvers. The results obtained from this model is discussed in the next section. 8

c 2010 by ASME Copyright

ibd [] SystemLevelModel[

SystemLevelModel]

costAnalysis : CostAnalysis

Force produced in forward phase: 𝐹𝐿𝑓𝑜𝑟𝑤𝑎𝑟𝑑 ≥ 50,000 N Total time taken by system: 𝑡𝑡𝑜𝑡𝑎𝑙 ≤ 20 s Total Cost of Components: 𝐶𝑡𝑜𝑡𝑎𝑙 ≤ $1,000 Total Mass of Components: 𝑚𝑡𝑜𝑡𝑎𝑙 ≤ 150 kg

massAnalysis : MassAnalysis

cylinder : CylinderCost

cylinder : CylinderMass

size : CylinderSizing

size : CylinderSizing

FIGURE 10. MATHEMATICAL REPRESENTATION OF REQUIREMENTS IN TERMS OF EQUATIONS. CHANGE IN REQUIREMENT LEVELS AFFECT THE COMPONENT SIZES OBTAINED.

«GamsSelectionConnection» «GamsSelectionConnection» systemSizing : SystemSizingDescription cylinder : CylinderSizing

engine : EngineSizing

pump : PumpSizing

«GamsSelectionConnection»

BARON [37] in GAMS was used to solve the example log splitter problem. An important aspect to note is that the component models used in this example do not consider losses such as leakage or friction, i.e. they model ideal physical behavior. This assumption has been made because these models represent the first time that GAMS-compliant declarative models are been used. Since losses do not alter the fundamental behavior of the component, including them will only serve to make the model more complex but will not invalidate the use of GAMS for solving this class of problems. In order to understand the results obtained for the scenarios, it is necessary to identify the coupling between the different components of the log splitter. The log splitter’s function is to split wood by using force generated by a cylinder. The force produced by a cylinder directly depends on the bore diameter and pressure of the fluid inside it. Therefore, to produce more force, either the bore diameter or pressure can increase or both. Higher pressure at the cylinder means that the pump needs a greater input torque, which places a demand on the engine for higher torque. An increase in the bore diameter results in a decrease in flow rate in the cylinder, which increases the time taken to split the wood. Moreover, the maximum flow that can be handled by the system is limited by the valve that is used. Thus, with inequalities in the constraints it is difficult to determine manually what the best solution is to a given scenario. Before discussing the individual scenarios, Table 1 provides an overall comparison of the results obtained. It appears that the results are appropriate, since the objective to be optimized in each scenario is better (smaller or larger, depending on optimization direction) than its corresponding value in the other scenarios. In addition to the overall results, the actual component sizes for each scenario are also described below, along with a discussion to understand the logic behind the values obtained.

«GamsSelectionConnection» fpAnalysis : FPAnalysis forward : ForwardPhaseFPAnalysis

reverse : ReversePhaseFPAnalysis

oc : OpenCenterCkt

oc : OpenCenterCkt

cylinder : CylinderFP

cylinder : CylinderFP

size : CylinderSizing

size : CylinderSizing

FIGURE 9. SYSML INTERNAL BLOCK DIAGRAM (IBD) VIEW SHOWING THE EXPLICIT CONNECTIONS THAT MAINTAIN CONSISTENCY BETWEEN SIZING VARIABLES THROUGHOUT ALL OF THE ANALYSES AND USE-PHASES.

RESULTS In this section, we present results associated with solving the log splitter component sizing problem for different scenarios. As discussed in the Introduction, the motivation for this research is the investigation of new frameworks that can represent and solve component sizing problems more efficiently. Therefore, in addition to describing the actual solutions obtained for various scenarios, a discussion is provided regarding the use of SysML versus other tools such as MATLAB or GAMS. In the current scope of this research, investigation into the global optimality of solutions is not considered; such validation is beyond the current scope of this research and is left for future work. Based on available component catalog data, sizing was performed on four components: a gas engine with 45 possible options, a fixed displacement pump with 64 possible options, a double acting cylinder with 158 possible options, and an open center directional control valve with 34 possible options. Five scenarios are considered: maximizing the cylinder force during the forward phase, minimizing total cost, minimizing total mass, minimizing total time, and minimizing a multi-objective function that is a combination of the other four objectives. The requirements imposed on the system, in terms of constraints, are shown in Fig. 10. These requirements act in addition to the constraints already imposed by individual component behavior models. The global MINLP solver

Interpretation of Results for a Specific Scenario: Maximize Force In this scenario, the problem is to find the sizes for the components so that the maximum force can be produced to split the log, which is the force produced in the forward phase. The 9

c 2010 by ASME Copyright

TABLE 1. COMPARISON OF OUTPUT OF SOLVER FOR DIFFERENT SCENARIOS. COMPONENT SIZING IS REPRESENTED THROUGH THE SELECTION OF A COMPONENT FROM THE CATALOG (ID VALUES) Component Sizing (Selection Id from Catalog) Scenario Maximize Force (N) Minimize Total Time (s) Minimize Total Cost ($) Minimize Total Mass (kg) Minimize Multiobjective z

Selected Variable Values Total Mass Total Cost Total Time (kg) ($) (s)

CPU Execution Time (s)

Cylinder Id

Pump Id

Engine Id

Valve Id

Forward Force (N)

HMW-5032

SKP1NN_012

DP340E

NT-2020

139,833

94.9

993.5

20

0.4

2.82

HMW-3010

SKP1NN_012

DP390E NT_Prince-2036

50,000

51.87

843.97

4.9

0.25

3.54

HMW-4010

SKP1NN_012

DP240

NT-2020

53,698

51.3

657.4

9.69

0.26

2.45

PMC-5414

SNP2NN_4_0

DP160V

MSCDirect01825629

52,013

32.25

708.6

9.15

0.25

78.13

HMW-5010

SKP1NN_012

DP390

NT-2020

147,437

71.53

866.3

13.79

-0.4

5.65

z

Multiobjective function: z = 0.25*((totalMass/300) + (totalTime/20) + (totalCost/1000) - (forwardForce/50000))

TABLE 2. COMPONENT SIZES TO PRODUCE MAXIMUM LOG SPLITTING FORCE (N) 0.13 0.81 17200000 293.5 56.1

Displacement (m3/rev) Max Operating Pressure (Pa) Pump: Max Operating Speed (rpm) SKP1NN_012 Cost ($) Mass (kg)

0 11997000 2000 230 1.65

Max Torque (N-m) Speed at Max Torque (rpm) Engine: Max Power (W) DP340E Speed at Max Power (rpm) Cost ($) Mass (kg)

23.4 2500 8200 3600 399.99 32.65

Max Flow (m3/s) Valve: Max Operating Pressure (Pa) NT-2020 Cost ($) Mass (kg)

0 1.38E+07 70 4.53

Max Op. Speed for Pump (2010 rpm) Max Torque Point (from engine spec)

20

Engine Torque in N-m

Bore Diameter (m) Stroke Length (m) Cylinder: Max Operating Pressure (Pa) HMW-5032 Cost ($) Mass (kg)

Engine Model: DP340E 25

component sizes obtained are presented in Table 2. Since this scenario only cares about maximizing force, it is logical to assume that the other requirements (Fig. 10) would remain at the bounds. The cylinder selected has a large bore diameter, resulting in greater force but increasing the time taken to complete one cycle. This is reflected in the total time lying at the boundary of the constraint, i.e. 20 seconds. Similarly, the total cost ($993) is very close to the boundary of the constraint on total cost ($1000). The large bore diameter results in smaller flow for the same pressure and in this case it is only 0.0004 m3/s. Therefore, the consideration for valve selection lies mainly on the cost in order to maintain a total cost below the requirement. Since the objective is to maximize force, the possibility is to increase bore diameter and increase the pressure. The increase in bore diameter has been taken into account by selecting a large size cylinder. Higher system pressure is possible if the input torque to pump is higher, which leads to engines with higher possible torques. The logic underlying the selection of engine and pump is shown in Fig. 11. In Fig. 11 the torque-speed curve for the engine selected by the solver is shown, in which the region below the curve represents the feasible operating region of the engine. A clarification regarding the position of the max torque point is required: the curve represents a quadratic curve fitted through

15

Feasible engine operation region (under the solid curve)

10

5

0 500

Max Power Point (from engine spec)

Determined by solver: Operating Point of Engine in Forward Phase (21 N-m @ 2010 rpm)

Feasible pump operation region (left of the dashed line)

1000

1500

Determined by solver: Operating Point of Engine in Reverse Phase (0.36 N-m @ 2010 rpm) 2000

2500 3000 Speed in rpm

3500

4000

4500

FIGURE 11. ENGINE OPERATING POINT FOR FORWARD PHASE OF OPERATION, AS DETERMINED BY SOLVER. THE OPERATING POINT IS BELOW THE SPEED AT MAX TORQUE (AS PROVIDED BY ENGINE SPECIFICATION), WHICH IS COUNTERINTUITIVE TO A DESIGNER.

the two operating points specified by the vendor. Also shown is the maximum operating speed for the selected pump (red dashed line). Therefore, based on the intersection of these two feasible regions (engine and pump), the solver determined the operating point to be 21 Nm 2010 rpm. This result is counter-intuitive to what a designer would normally expect. A designer may assume that to achieve maximum torque input to pump, the maximum torque point for the engine should be considered first. Thereafter, a pump with suitable maximum operating speed would be selected. In that case, the designer would have outright rejected the pump 10

c 2010 by ASME Copyright

TABLE 3. COMPARISON OF SELECTED PUMP (SKP1NN 012) WITH OTHER PUMPS IN THE CATALOG Pump Id

Displacement (m3/rev)

Maximum operating Pressure (Pa)

Maximum operating RPM (rpm)

Mass (kg)

Cost ($)

SKP1NN_78 SKP1NN_010 SKP1NN_012 SNP3NN_022 SNP3NN_026 SNP3NN_033

7.58721E-06 9.94695E-06 1.19953E-05 2.21225E-05 2.62193E-05 3.31019E-05

2.00E+07 1.50E+07 1.20E+07 2.50E+07 2.50E+07 2.50E+07

3000 2000 2010 3000 3000 3000

1.39 1.55 1.65 6.80 6.80 7.17

225.45 227.99 230.01 410.94 415.67 426.41

component sizing problems. Although “easier” is subjective, there are characteristics that can be used to illustrate the usefulness of SysML and model transformations; in particular, scalability and reduction in the time required to model a sizing problem. As discussed in the example, component sizing problems consist of a number of different models such as multiple analyses and use-phases, energy-based analysis models, and catalog models (Fig. 12 to Fig. 9). Since the example presented in this paper is not very complex, it can be argued that the problem could have been formulated manually and directly in GAMS instead of in SysML in a similar time frame. However, as larger and more complex problems are considered, it would quickly become cumbersome and error prone to formulate the problem manually. Therefore a formal representation, such as that presented in this paper, becomes more important to a designer. In addition, this framework also reduces the time required by supporting reusable model libraries. Through the use of energy-based modeling, ports, and a common sign convention it is possible to define independent and self-contained models that captures its steady-state behavior. Moreover, additional constructs related to inheritance (similar to those found in Modelica) would enable the creation of a standard library that can be used for a wide variety of problems. Although there is some effort required to initially create models, this time is offset by the savings obtained when models are reused, such as across multiple use-phases or multiple components in a system. In addition, with a library of components available, system models can quickly be composed by connecting them together through their ports. Arguably the largest benefit of using this framework for representing component sizing problems is the model-based graphical nature of SysML, which is similar to the way designers construct schematics and other models. Thus, without these model transformations or SysML, a designer would have to manually define the entire problem directly in terms of an executable model consisting of equations and variables. This is non-intuitive for designers and would increase the occurrence of errors that are unrelated to the problem being solved. Thus, it is clear that the use of SysML and GAMS together is better than using GAMS alone for solving component sizing problems. However, this paper is only a first step towards defining a complete framework for representing and solving component sizing problems. Therefore, many of the limitations of the current work serve as a basis for future work. In particular, future work involves applying the framework to more complex engineering problems: with larger number of component catalog data, more components in the system, component models that include losses, etc. In addition, support for more complex use phases is also necessary in order to broaden the scope of problems that can be solved using this framework. Other areas include standardizing of the sign conventions used in different domains in order to conveniently

selected by the solver for being too slow. Therefore, in order to understand why the solver selected this particular pump, a closer look is required. In Table 3, the selected pump is compared with some of the other pumps available in the catalog. Since the total time is 20 seconds, the flow rate is low and consequently the pump displacement needed is also small. The two pumps with smaller displacements (SKP1NN 78 and SKP1NN 010) cannot generate enough flow in the system to have the total time under 20s. Pumps with larger displacements can be chosen, but their costs are much higher (around $400 compared to $230 for the selected pump). This comes with the disadvantage of a much lower maximum operating speed of 2010 rpm. Thus, the solver selects the pump SKP1NN 012 and chooses the engine operating points to be at 2010 rpm and 21 Nm, at the bounds of both the engine and pump feasible operating regions. This is interesting because such a solution would likely have been overlooked by a designer performing sizing manually.

DISCUSSION AND FUTURE WORK This paper aims to provide designers with improved capabilities for both representing and solving of component sizing problems. In particular, we have presented a framework for representing component sizing problems in SysML and solving them automatically using the mathematical programming language GAMS and its associated solvers. This paper does not claim to provide a complete framework that can be used for all types of component sizing problems; such validation is beyond the current scope. There are two main conclusions that can be derived from the example application. The first relates to solving component sizing problems more efficiently. The results obtained using solvers such as BARON show that solutions can be found quickly (approximately 2-5 seconds depending on the scenario). In addition, conventional languages such as MATLAB are limited in their ability to support acausal modeling as well as defining inequality constraints. The second conclusion from the example is related to the need for better tools that can make it easier to formulate 11

c 2010 by ASME Copyright

define new, reusable analysis models that can be used in multiple problems. Such an approach may lead to a new modeling language similar to Modelica, in which mathematical programming is used to solve engineering design problems. In conclusion, the “Model-Based Mathematical Programming” approach presented in this paper provides designers with the ability to quickly define systems using model libraries and explore solutions for different requirements and objective functions.

[9]

[10]

[11] ACKNOWLEDGMENT This work has been funded by Deere & Company. Additional support was provided by the Woodruff School of Mechanical Engineering at Georgia Tech and the ERC for Compact and Efficient Fluid Power, supported by the National Science Foundation under Grant No. EEC-0540834. No Magic Inc. provided access to its MagicDraw UML / SysML tool. Their in-kind support is gratefully acknowledged. The authors would like to thank Aleksandr Kerzhner for the discussions that helped crystallize the ideas presented in this paper and Richard Malak for providing access to a previously compiled database of commercially available hydraulic component data.

[12] [13] [14]

[15] REFERENCES [1] Sage, A. P., and Armstrong, J. E. J., 2000. Introduction to Systems Engineering. John Wiley & Sons. [2] OMG, 2008. Systems Modeling Language v 1.1. http://www.omg.org/docs/formal/08-11-02.pdf. [3] Coyne, R. D., Rosenman, M. A., Radford, A. D., Balachandran, M., and Gero, J. S., 1989. Knowledge-Based Design Systems. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. [4] Dym, C. L., and Levitt, R. E., 1991. Knowledge-Based Systems in Engineering. McGraw-Hill, Inc., New York, NY, USA. [5] Westman, R., Sargent, C., and Burton, R., 1987. “A Knowledge-Based Modular Approach to Hydraulic Circuit Design”. Computers in Engineering, 1, pp. 37–41. [6] Sargent, C. M., Burton, R. T., and Westman, R. W., 1988. “Expert Systems and Fluid Power”. In Proceedings of the 8th International Fluid Power Symposium, pp. 68–272. [7] Dunlop, G., and Rayudu, R., 1993. “An Expert Design Assistant for Hydraulic Systems”. In Artificial Neural Networks and Expert Systems, 1993. Proceedings., First New Zealand International Two-Stream Conference on, pp. 314–316. [8] Fujita, K., Akagi, S., and Sasaki, M., 1995. “Adaptive synthesis of hydraulic circuits from design cases based on functional structure”. In Proceedings of the 1995 ASME International Design Engineering Technical Conferences

[16]

[17]

[18]

[19] [20] [21] [22] [23]

12

- 21st Annual Design Automation Conference, Vol. 82, pp. 875–882. da Silva, J. C., and Back, N., 2000. “Shaping the Process of Fluid Power System Design Applying an Expert System”. Research in Engineering Design, 12(1), pp. 8–17. Hughes, E. J., Richards, T. G., and Tilley, D. G., 2001. “Development of a Design Support Tool for Fluid Power System Design”. Journal of Engineering Design, 12, pp. 75–92. Malak, R. J., Tucker, L., and Paredis, C. J., 2008. “Composing Tradeoff Models For Multi-Attribute System-Level Decision Making”. In Proceedings of the ASME 2008 International Design Engineering Technical Conferences & Computers and Information in Engineering Conference. IDETC/CIE 2008., ASME. Paper number 49970. Modelica, 2009. Modelica Language Specification v 3.1. http://www.modelica.org/documents/ModelicaSpec31.pdf. Fritzson, P., 2004. Principles of Object-Oriented Modeling and Simulation with Modelica 2.1. IEEE Press. Gross, M. D., 1986. “Design as Exploring Constraints”. PhD thesis, Massachusetts Institute of Technology, Dept. of Architecture. Russell, S. J., and Norvig, P., 2003. “Constraint Satisfaction Problems”. In Artificial Intelligence: A Modern Approach, 3 ed. Prentice Hall, ch. 5, pp. 137–160. Freuder, E. C., and Mackworth, A. K., 2006. “Constraint Satisfaction: An Emerging Paradigm”. In Handbook of Constraint Programming, F. Rossi, P. van Beek, and T. Walsh, eds. Elsevier, ch. 2, pp. 13–28. Chenouard, R., S´ebastian, P., and Granvilliers, L., 2002. “Solving an Air Conditioning System Problem in an Embodiment Design Context Using Constraint Satisfaction Techniques”. In Principles and Practice of Constraint Programming - CP 2007, 13th International Conference, CP 2007, Providence, RI, USA, September 23-27, 2007, Proceedings, C. Bessiere, ed., Vol. 4741 of LNCS, Springer, pp. 18–32. O’Sullivan, B. A., 1999. “Constraint-Aided Conceptual Design”. PhD thesis, Department of Computer Science, University College Cork, Ireland, July. http://www.cs.ucc.ie/ osullb/phd.html. Gecode, 2006. Gecode system. http://www.gecode.org. Choco, 2009. Choco Solver. http://www.emn.fr/z-info/choco-solver/index.html. Marc, C., Granvilliers, L., and Sorin, V., 2005. Elisa. http://sourceforge.net/projects/elisa/. Granvilliers, L., 2003. RealPaver User’s Manual, version 0.3. http://realpaver.sourceforge.net/. Sahinidis, N. V., 1996. “ BARON: A general purpose global optimization software package ”. In Journal of Global Optimization, Vol. 8. Springer, ch. 2, pp. 201–205. c 2010 by ASME Copyright

[24] GAMS, 2009. General Algebraic Modeling System (GAMS). www.gams.com. [25] Nethercote, N., Stuckey, P., Becket, R., Brand, S., Duck, G., and Tack, G., 2007. “MiniZinc: Towards a Standard CP Modelling Language”. In Principles and Practice of Constraint Programming - CP 2007, 13th International Conference, CP 2007, Providence, RI, USA, September 23-27, 2007, Proceedings, Vol. 4741, pp. 529–543. [26] Chenouard, R., Granvilliers, L., and Soto, R., 2008. “Model-driven constraint programming”. In PPDP ’08: Proceedings of the 10th international ACM SIGPLAN conference on Principles and practice of declarative programming, ACM, pp. 236–246. [27] Kerzhner, A. A., and Paredis, C. J. J., 2009. “Using Domain Specific Languages to Capture Design Synthesis Knowledge for Model-Based Systems Engineering”. In Proceedings of the 2009 ASME International Design Engineering Technical Conferences & Computers and Information in Engineering Conference, ASME. Paper number 87286. [28] OMG, 2006. Meta Object Facility (MOF) Core Specification v 2.0. http://www.omg.org/docs/formal/06-01-01.pdf. [29] K¨onigs, A., and Sch¨urr, A., 2006. “Tool Integration with Triple Graph Grammars - A Survey”. Electronic Notes in Theoretical Computer Science, 148(1), pp. 113–150. [30] Brucker, A. D., and Doser, J., 2007. “Metamodel-based UML Notations for Domain-specific Languages”. In 4th International Workshop on Software Language Engineering (ATEM 2007). [31] Weisem¨oller, I., and Sch¨urr, A., 2008. “A Comparison of Standard Compliant Ways to Define Domain Specific Languages”. In Models in Software Engineering, Workshops and Symposia at MoDELS 2007, Nashville, TN, USA, September 30 - October 5, 2007, Reports and Revised Selected Papers, H. Giese, ed., Vol. 5002, Springer, pp. 47–58. [32] Baresi, L., and Heckel, R., 2002. “Tutorial Introduction to Graph Transformation: A Software Engineering Perspective”. In Graph Transformation, First International Conference, ICGT 2002, Barcelona, Spain, October 7-12, 2002, Proceedings, A. Corradini, H. Ehrig, H.-J. Kreowski, and G. Rozenberg, eds., Vol. 2505 of LNCS, Springer, pp. 402–429. [33] Czarnecki, K., and Helsen, S., 2006. “Feature-Based Survey of Model Transformation Approaches”. IBM Systems Journal, 45(3), pp. 621–645. [34] Sch¨urr, A., 1995. “Specification of graph translators with triple graph grammars”. In Graph-Theoretic Concepts in Computer Science, 20th International Workshop, WG ’94, Herrsching, Germany, June 16-18, 1994, Proceedings, E. W. Mayr, G. Schmidt, and G. Tinhofer, eds., Vol. 903,

Springer, pp. 151–163. [35] Fischer, T., Niere, J., Torunski, L., and Z¨undorf, A., 2000. “Story Diagrams: A New Graph Rewrite Language Based on the Unified Modeling Language and Java”. In Theory and Application of Graph Transformations, 6th International Workshop, TAGT’98, Paderborn, Germany, November 16-20, 1998,, H. Ehrig, G. Engels, H.-J. Kreowski, and G. Rozenberg, eds., Vol. 1764, Springer, pp. 157–167. [36] NoMagic, 2009. MagicDraw. http://www.magicdraw.com. [37] Sahinidis, N. V., 2003. “Global Optimization and Constraint Satisfaction: The Branch-and-Reduce Approach”. In Global Optimization and Constraint Satisfaction, First International Workshop, COCOS 2002, Valbonne-Sophia Antipolis, France, October 2-4, 2002, C. Bliek, C. Jermann, and A. Neumaier, eds., Vol. 2861, Springer, pp. 1–16.

Appendix: SysML Diagrams Used in the Log Splitter Example

13

c 2010 by ASME Copyright

14

c 2010 by ASME Copyright

«requirement» Mass

Id = "2.1.1.1" Text = "Force shall be greater than 10000 N"

«requirement» ForceF

Id = "2.1.1.2" Text = "System pressure shall be less than 3e7 Pa "

«requirement» PrF

«verify»

«deriveReqt»

Id = "2.1.2.2" Text = "System pressure shall be less than 3e7 Pa "

«requirement» PrR

Id = "2.1.2.1" Text = "Force shall be greater than 1000 N "

«requirement» ForceR

«deriveReqt»

Id = "2.1.2" Text = "Performance during reverse phase shall be maximized"

Id = "2.1.1" Text = "Performance during forward phase shall be maximized" «deriveReqt»

«requirement» Reverse Phase

«deriveReqt»

Text = "Total cycle time shall be less than 20 s "

«deriveReqt» Id = "2.1.3"

«requirement» CycleTime

«requirement» Forward Phase

«verify»

«verify»

Id = "2.1" Text = " The hydraulic performance shall be maximized"

«requirement» HydraulicSystem

FIGURE 12. SYSML REQUIREMENTS MODELING FOR LOG SPLITTER PROBLEM. REQUIREMENTS MODELING AIDS IN DECOMPOSING THE PROBLEM INTO DIFFERENT ANALYSES

reverse : ReversePhaseFPAnalysis

forward : ForwardPhaseFPAnalysis

fpAnalysis : FPAnalysis

costAnalysis : CostAnalysis

massAnalysis : MassAnalysis

«requirement» Cost

Id = "2.3" Text = "Total cost shall be less than $1000 "

«verify»

«GamsModel» SystemLevelModel

«verify»

«requirement» TotalSystem

Id = "2" Text = "System Performance shall be maximized"

LogSplitterReq]

Id = "2.2" Text = "Total mass shall be less than 300 kg "

«verify»

req [Package] Requirements[

bdd [Package] LogSplitterProblem[

SystemLevelView ] «GamsSolve» Solve

Equations to maintain consistency between sizing variables Equations from Requirements

«GamsSolve»

modelType = minlp objVarName = "fpAnalysis.forward.cylinder.force" optimizeDirection = maximize solverType = BARON

Model Hierarchy «OwnedGamsModel» -systemLevelModel «GamsModel» SystemLevelModel {systemSizing.cylinder.cost =e= costAnalysis.cylinder.size.cost, systemSizing.cylinder.boreDiameter =e= fpAnalysis.forward.cylinder.size.boreDiameter, systemSizing.cylinder.boreDiameter =e= fpAnalysis.reverse.cylinder.size.boreDiameter, systemSizing.cylinder.mass =e= massAnalysis.cylinder.size.mass} ...

«OwnedGamsModel» -fpAnalysis

«OwnedGamsModel» -massAnalysis

«GamsModel» FPAnalysis {totalTime =e= forward.cylinder.time + reverse.cylinder.time, totalTime =l= 40}

«GamsModel» MassAnalysis {totalMass =e= cylinder.size.mass + pump.size.mass + engine.size.mass, totalMass =l= 100}

values

totalTime : GamsFree

parts

cylinder : CylinderMass pump : PumpMass valve : ValveMass tank : TankMass engine : EngineMass

«OwnedGamsModel» -forward values

totalMass : GamsFree

«OwnedGamsModel» -costAnalysis «GamsModel» CostAnalysis {totalCost =e= cylinder.size.cost + pump.size.cost+ engine.size.mass, totalCost =l= 1000} parts

cylinder : CylinderCost pump : PumpCost tank : TankCost valve : ValveCost engine : EngineCost values

totalCost : GamsFree

Equations from Physical Connections (Law of Energy Conservation)

FIGURE 13.

«OwnedGamsModel» -reverse

«GamsModel» ForwardPhaseFPAnalysis {oc.cylinder.force =g= 100000, oc.engine.control =e= 1, oc.pump.portP.p =l= 3e7, oc.cylinder.length =g= 0.25, oc.valve.control =e= 1}

«OwnedGamsModel» -oc

«GamsModel» ReversePhaseFPAnalysis {oc.cylinder.force =g= 1000, oc.engine.control =e= 0, oc.valve.control =e= 0}

«OwnedGamsModel» -oc

«GamsModel» OpenCenterCkt {pump.portP.p =e= valve.portP.p, pump.portP.q + valve.portP.q =e= 0, pump.portT.p =e= tank.portP.p, pump.portT.q + tank.portP.q =e= 0, valve.portT.p =e= tank.portT.p, valve.portT.q + tank.portT.q =e= 0, valve.portA.p =e= cylinder.portA.p, valve.portA.q + cylinder.portA.q =e= 0, valve.portB.p =e= cylinder.portB.p, valve.portB.q + cylinder.portB.q =e= 0, engine.flange.w =e= pump.flange.w, engine.flange.tau + pump.flange.tau =e= 0, cylinder.flangeA.v =e= fixed.flange.v, cylinder.flangeA.f + fixed.flange.f =e= 0} parts

cylinder : CylinderFP pump : PumpFP tank : TankFP valve : ValveFP engine : EngineFP fixed : FixedFP

Relating sizing variables to catalog component data -systemSizing

«GamsModel» SystemSizingDescription {cylinder.boreDiameter =e= sum(cylCat.id, cylCat.select(cylCat.id)* cylCat.boreDiameterCatData(cylCat.id)), cylinder.strokeLength =e= sum(cylCat.id, cylCat.select(cylCat.id)* cylCat.strokeLengthCatData(cylCat.id)), cylinder.mass =e= sum(cylCat.id, cylCat.select(cylCat.id)* cylCat.massCatData(cylCat.id)), cylinder.cost =e= sum(cylCat.id, cylCat.select(cylCat.id)* cylCat.costCatData(cylCat.id)), cylinder.maxPressure =e= sum(cylCat.id, cylCat.select(cylCat.id)* cylCat.maxPressureCatData(cylCat.id))} parts

pump : PumpSizing cylinder : CylinderSizing engine : EngineSizing cylCat : CylinderCat engineCat : EngineCat pumpCat : PumpCat

SYSML BLOCK DEFINITION DIAGRAM (BDD) VIEW FOR THE LOG SPLITTER COMPONENT SIZING MODEL.

15

c 2010 by ASME Copyright