主要内容

Understanding Model Structure for Scripting

Projects and Test Plans for Model Scripting

To use the Model Browser in the Model-Based Calibration Toolbox™ product, you must understand the structure and functions of the model tree to navigate the views. To use the command-line version of the toolbox, you must understand the same structure and functions, that is, how projects, test plans, and models fit together. The following sections describe the relationship between the different models that you can construct. The diagrams in the following section, How the Model Tree Relates to Command-Line Objects, illustrate these relationships.

  • Projects can have one or more test plans.

  • Projects can have one or more data objects.

  • Test plans have no more than one data object.

  • Test plans have response objects.

    • If a one-stage test plan, these are simply known as responses.

    • If two-stage test plan, these are hierarchical responses.

  • Test plans have boundary tree objects.

Response Model Scripting

A response is a model fitted to some data. These are the types of responses:

  • Hierarchical Response (Level 0)

    A hierarchical response (also known as a two-stage response) models a ResponseSignalName using a local response and one or more response features.

    A hierarchical response has one or more different local responses (accessible via the property LocalResponses) that provide different possible models of the ResponseSignalName. One of these must be chosen as the best, and that will then be the local response used subsequently. The response features of each of the local responses are available directly from those local response objects.

  • Local Response (Level 1)

    The local response consists of models of the ResponseSignalName as a function of the local input factors. The local input factors are accessible via the InputSignalNames property.

    A local response has one or more response features (accessible via the property ResponseFeatures) containing the models fitted to those response features of the local model.

  • Response (Level 1 or 2)

    • For two-stage test plans, response objects model the response features of local responses (ResponseSignalName corresponds to the name of the response feature). In this case, the response has a level value of 2.

    • For one-stage test plans, response objects simply model the ResponseSignalName as a function of the input factors. In this case, the response will have a level value of 1.

    All responses can have zero or more alternative responses (accessible via the property AlternativeResponses) that provide different possible models of the ResponseSignalName. These all retain the same level as the response for which they are an alternative. One of these must be chosen as the best and that will then be the response used subsequently.

See the illustrations in the following section, How the Model Tree Relates to Command-Line Objects, for examples of different responses and how they relate to each other.

Note that each response contains a model object (mbcmodel.model) that can be extracted and manipulated independently of the project. You can change the model type and settings, fit to new data, examine coefficients, regression matrices and predicted values, and use stepwise functions to include or remove terms. You can change model type, properties and fit algorithm settings. If you change the model, you must use UpdateResponse to replace the new model type in the response object in the project. When you use UpdateResponse the new model is fitted to the response data. See UpdateResponse.

Boundary Model Scripting

You can create and evaluate boundary models either in a project or standalone. You can combine boundary models in the same way as when using the Boundary Editor GUI. You can use boundary models as design constraints.

In a project, a test plan mbcmodel.testplan property that can contain an mbcboundary.Tree object.

BoundaryTree = mbcmodel.testplan.Boundary
The BoundaryTree is a container for all the boundary models you create. The tree is empty until you create boundaries, and if you change the testplan data the toolbox deletes the boundaries.

You can fit boundary models in mbcmodel projects using the boundary tree class mbcboundary.Tree, or you can fit boundary models directly to data.

To create a boundary model outside of a project, you can either:

  • Use the CreateBoundary namespace function:

    B = mbcboundary.CreateBoundary(Type,Inputs)

  • Use the fit method to create and fit a boundary to some data X:

    B = mbcboundary.Fit(X,Type)

To create a boundary model within a project, use the CreateBoundary method of the boundary tree:

B = CreateBoundary(Tree,Type)
This creates a new boundary model, B, from the mbcboundary.Tree object, Tree. The test plan inputs are used to define the boundary model inputs. The new boundary model is not added to the tree, you must call Add.

To create a new boundary model from an existing boundary model, you can use the CreateBoundary method of all boundary model types:

B = CreateBoundary(B,Type)

See Also