Learn more about Model-Based Calibration

Understanding Model Structure

On this page…
Overview of Model Structure Projects Test Plans Responses Boundary Models

Overview of Model Structure

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.

Back to Top

Projects

• Projects can have one or more test plans.

• Projects can have one or more data objects.

Back to Top

Test Plans

• 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.

Back to Top

Responses

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 coeffficients, regression matrices and predicted values, and use stepwise functions to include or remove terms. You can change model type, properties and fit algorithm settings. See ModelsModel Object. 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.

Back to Top

Boundary Models

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, the test plan has a Boundary property that can contain an 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 package function:

  B = mbcboundary.CreateBoundary(Type,Inputs)

• Use the 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 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 .

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

B = CreateBoundary(B,Type)

You can combine boundary models by using the property of the boundary tree. This corresponds to combining boundary models in best in the Boundary Editor GUI, as described in Combining Best Boundary Models in the Model Browser documentation. You can also combine boundary models with logical operators, for use as design constraints or outside projects.

You can change the ActiveInputs, Evaluate, and use as a designconstraint.

For a complete list of boundary model classes, methods and properties, see Boundary Models in the Model-Based Calibration Toolbox reference documentation.

Back to Top

Processes You Can Automate

How the Model Tree Relates to Command-Line Objects

© 1984-2009- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS