Optimisation

Overview

The Business Objects for Optimisation allow the definition of the intent of an optimisation, i.e what are the variables and the objective. Additionally it can also define constraints, observations and the algorithm to be used in the optimisation. The elements all have a prefix of D2X or “Design to X”.

../../../_images/d2x_icons.png

Icons for Optimisation Objects

The objects provide the meta-data for the Optimisation, and link to Methodology Objects to declare what is to be optimised. This definition is then used by an “optimisation agent” to manipulate the programme objects accordingly. See Templates and Instances for more details on the Methodology and Programme objects.

Optimisation Objects and their usage

D2X Template

The D2X Template is the container for the elements of the Optimisation definition.

It has the following features:

  • Context: This can be a Collaborative Model Template [CMT] or a Methodology Library (see Templates and Instances).
    • If the context is a CMT, it is capturing the way that CMT can be exploited in a “design to objective” context.
    • If the context is a Methodology Library, they could have been created “on-the-fly” for an AssociativeModelNetwork, or they are defining an Optimisation for KeyValueTypes that are not in the context of a CMT.
  • Deployed by a Study
    • This indicates that the D2X Template should be deployed as part of the study. It is associated directly to the study so that it can be identified early, i.e. before the Associative Model Network [AMN]has been defined. There can be more than one associated to the study if the study is managing several AMN
  • Used by an Associative Model Network
    • This is in addition to the deployed by study relationship because a study could have more than one Optimisation happening in different AMNs that it is controlling, therefore need to know which is applicable to which AMN. It is also possible to have more than one D2X Template because initially you may not be sure which D2XTemplate to use, so could want to attach more than one (changed to one later when the Optimisation-Service Actor is added).
  • Optimisation service Actor
    • This is the service that is known to be able to control the Optimisation. It is most likely to be a Tool, but it set it to be Actor so that it could be a Person for manual iterations. It is optional because it may not me known, and there can be more than one because there may be more than one that can control the optimisation. This can be used as an indication to the AMN for which to chose as its Optimisation-Service.
    • Variables, Objectives, Constraints, Observations, Constants, Algorithm. All described in more detail below.

See SysML - D2XTemplate for more details.

D2X Design and External Variables

They have the following features:

There are two types of variables that can be defined for a D2X Template, a Design Variable and an External Variable. They are essentially behave the same but can be use to indicate whether they are under the control of the designer (Design Variables), e.g. Thickness, length. Or if they are something that varies but is not under the designers control, e.g. wind speed, environment temperature.

  • The variable references a KeyValueType. In the iterations the values of the KeyValueInstances of this Type will be controlled according to the definition of this variable.

  • The variable has an optional start value, which is the value to use in the first iteration.

  • The range is defined using a Distribution (see below).
    • This might appear to be an “overkill” for a simple range, but it is a way to have agreed sets of parameters for the different types of range, and also clearly state the “type” of the range with a classifiedBy. The resultant distribution for a simple range is to use a distribution (classified as uniform and continuous) that has two properties for the upperBound and lowerBound. This is flexible than just applying the properties to the D2XVariable, and only needs one extra element. Also using a distribution provides a common way to define all variables, so for example a Normal Distribution could be used to define the environment temperature in an External Variable, or a Discrete distribution can specify a file for the values, or properties for the values e.g. High, Medium, Low.

Distributions

There are two types of distribution, a Parametric distribution where the distribution is defined with parameters, and a Non-Parametric distribution where the the distribution is defined with a distributionData document.

The distributions can be classified for example to be “Continuous” or “Discrete”, then other classifications for the type of distribution e.g. “Normal” “Uniform” “Triangular” etc. There should then be an agreed set of parameters, or an agreed file format for describing the distribution.

Examples of simple distributions are shown below:

../../../_images/d2x_ea_distributions.png

Examples of Uniform, Continuous, Discrete distributions for use in D2X Variables See SysML - Distributions for more details.

D2X Objectives and Constraints

The “Objective” references the KeyValueType to be used as the objective in the Optimisation. Multiple “Objectives” can be identified with a “Design to X Template” to support its use in different contexts. If an algorithm is only suitable for single objective problems, then D2XConstraints can be used for the other “objectives”.

Properties related to the objective include:

  • directedAction: This is the goal of the Optimisation of this Key Value. e.g. Maximise or Minimise.
    • There are some choices for the enumeration that are not really suitable for objectives (e.g. <) but there are included to allow the same enumeration to be used for D2XObjective and D2XConstraint. The choice may also be restricted by the algorithm selected.

  • targetValue: The value for the goal (e.g. Target Optimum = 75.3)

  • targetValueType: the type for the targetValue (e.g. float, integer)

  • resolutionValue: for when there is a tolerance allowed on the goal of the Optimisation (e.g. TargetOptimum +- 5%, so resolutionValue = 5)

  • resolutionValueType: he type for the resolutionValue (e.g. float, integer)

  • resolutionType: what sort of tolerance is used e.g. percentage or delta

A “Constraint” identifies a KeyValueType (KVT) to be controlled to within a constrained value range.

Typically Constraints are placed on some calculated performance or integrity measure derived from modelling and simulation - i.e. the Key Value isExtractedFrom a calculated Model Type / Model Instance. For example, Performance < 0.4 When a constraint in a range is needed e.g 0.2 < Clearance <= 0.4 then two constraints should be created The constraint is a specialisation of D2XObjective so can have all the same properties. However some of the choices for the enumerations are not logical for a constraint (e.g. Minimise), though this is not restricted. Many algorithms only work with a single objective in an Optimisation, in which case the other “objectives” are set as constraints to discard solutions where the constraints are not met.

D2X Observations

This is something that particularly wants to be viewed and monitored (above the other key value types/instances in the network), but is not a constraint. It is an indication for the Optimisation-Service to say that we want this key value computed and stored in the Optimisation data results, so that it can be viewed. (e.g. optimise to minimise the weight, but tell me what the cost is doing at each iteration)

D2X Constants

This is to allow the Optimisation-Service to be able to set the value of one of the inputs so that it is not at the default value. For example, a network has the cruise altitude set to 30,000ft. For the optimisation to maximise range, the cruise altitude value could be changed to 35,000ft. Or for example one iteration fixes the passenger numbers to 300, another fixes it to 350.

D2X Algorithms

The Algorithm identifies the design-to-objective method or classes of methods applicable for this template. It is provided as guidance to the end-user of the D2X Template, and indicates the extent of testing of the related template. It does not indicate a warranty or guarantee. The end-user remains responsible to interpret and validate the results of their specific D2X study.

The Algorithm is a specialisation of a Method because:

  • It needs to have parameters, the number/name/definition of these depend on what software algorithm is used.
    • The number/name/definition of the parameters do not change regularly, but when they do this should be a new version of the D2XAlgorithm
    • The algorithm needs resources - the software that is the algorithm
    • It should have documentation attached to describe what the algorithm is.
    • We want to know what was “planned” and “actually” used in the Optimisation

Additionally, the algorithm has a string to declare they type of the algorithm. The values for these are a business rule, but examples could be:

  • Manual (user specifies the values of the Design Variables)
    • This type stops at the end of each iteration and has to be restarted with manually changed values. So it needs to notify a person that an iteration is complete, and that person needs to launch the next iteration
  • Design of Experiments algorithm
    • This type sets up all the iterations up front, and they run in parallel
  • Optimisation algorithm (e.g. fmincon, NSGA-II)
    • This type needs to be notified at the end of an iteration with the objective values, then it needs to launch the next iteration with new values. Could be argued that this is the same as Manual, but the Actor is a tool not a person.

The D2X Template then has a D2XAlorgithm that is the “instance” of this with the suggested values of the parameters for the template.

An example of an Algorithm is shown below.

../../../_images/d2x_ea_algorithm.png

Algorithm definition

See SysML - D2XAlgorithm for more details.

Section author: Judith Crockford