Общие сведения о структуре модели для создания скриптов

Проекты и планы тестирования для создания сценариев модели

Чтобы использовать Model Browser в продукте Model-Based Calibration Toolbox™, необходимо изучить структуру и функции дерева модели, чтобы перемещаться по видам. Чтобы использовать версию тулбокса в командной строке, необходимо понять ту же структуру и функции, то есть как проекты, планы тестирования и модели сходятся воедино. В следующих разделах описываются отношения между различными моделями, которые можно создать. Схемы в следующем разделе «Как дерево модели относится к объектам командной строки» иллюстрируют эти отношения.

  • Проекты могут иметь один или несколько планов тестирования.

  • Проекты могут иметь один или несколько объектов данных.

  • Планы тестирования имеют не более одного объекта данных.

  • Планы тестирования имеют объекты отклика.

    • Если одноэтапный план тестирования, они просто известны как ответы.

    • Если двухэтапный план тестирования, это иерархические отклики.

  • Планы тестирования имеют краевые древовидные объекты.

Сценарии модели отклика

Ответ является моделью, подобранной к некоторым данным. Вот типы ответов:

  • Иерархический ответ (уровень 0)

    Иерархический ответ (также известный как двухэтапный ответ) моделирует ResponseSignalName использование локального отклика и одной или нескольких функций отклика.

    Иерархический ответ имеет один или несколько различных локальных ответов (доступных через свойство LocalResponses) которые обеспечивают различные возможные модели ResponseSignalName. Один из них должен быть выбран в качестве наилучшего, и тогда это будет локальный ответ, используемый впоследствии. Функции отклика каждого из локальных ответов доступны непосредственно от этих локальных объектов отклика.

  • Локальный ответ (уровень 1)

    Локальный ответ состоит из моделей ResponseSignalName как функция от локальных входных факторов. Локальные входные факторы доступны через InputSignalNames свойство.

    Локальный ответ имеет одну или несколько функций ответа (доступных через свойство ResponseFeatures) содержащие модели, подобранные к тем функциям отклика локальной модели.

  • Ответ (уровень 1 или 2)

    • Для двухэтапных планов тестирования объекты отклика моделируют функции отклика локальных откликов (ResponseSignalName соответствует имени функции отклика). В этом случае ответ имеет значение уровня 2.

    • Для одноэтапных планов тестирования объекты отклика просто моделируют ResponseSignalName как функция от входных факторов. В этом случае ответ будет иметь значение уровня 1.

    Все ответы могут иметь нуль или больше альтернативных ответов (доступно через свойство AlternativeResponses) которые обеспечивают различные возможные модели ResponseSignalName. Все они сохраняют тот же уровень, что и ответ, для которого они являются альтернативой. Один из них должен быть выбран в качестве наилучшего, и в таком случае это будет ответ, использованный впоследствии.

См. рисунки в следующем разделе, «Как дерево модели относится к объектам командной строки», для примеров различных откликов и того, как они связаны друг с другом.

Обратите внимание, что каждый ответ содержит объект модели (mbcmodel.model), которым можно извлечь и манипулировать независимо от проекта. Можно изменить тип модели и настройки, подгонку к новым данным, изучить коэффициенты, регрессионые матрицы и предсказанные значения и использовать пошаговые функции, чтобы включить или удалить условия. Можно изменить тип модели, свойства и настройки алгоритма аппроксимации. Чтобы узнать о том, что вы делаете с объектом модели, смотрите Model Object. Если вы меняете модель, вы должны использовать UpdateResponse для замены нового типа модели в объекте отклика в проекте. Когда вы используете UpdateResponse новая модель подгоняется к данным отклика. См. UpdateResponse.

Краевые сценарии модели

Можно создавать и оценивать модели границ либо в проекте, либо в автономном режиме. Можно объединить модели контуров так же, как при использовании графический интерфейс пользователя редактора контуров. Граничные модели можно использовать как проект ограничения.

В проекте план тестирования имеет Boundary свойство, которое может содержать mbcboundary.Tree объект.

BoundaryTree = mbcmodel.testplan.Boundary
The BoundaryTree - контейнер для всех созданных моделей границ. Дерево пусто до тех пор, пока вы не создадите контуров, и если вы измените данные тестового плана, тулбокс удаляет контуры.

Краевые модели можно подгонять в mbcmodel проекты с использованием класса краевого дерева mbcboundary.Treeили можно подгонять граничные модели непосредственно к данным.

Чтобы создать краевую модель вне проекта, можно либо:

  • Используйте CreateBoundary функция пакета:

    B = mbcboundary.CreateBoundary(Type,Inputs)

  • Используйте fit метод создания и аппроксимации контура к некоторым данным X:

    B = mbcboundary.Fit(X,Type)

Чтобы создать краевую модель в проекте, используйте CreateBoundary метод краевого дерева:

B = CreateBoundary(Tree,Type)
Это создает новую модель контура, B, из mbcboundary.Tree объект, Tree. Входы плана тестирования используются, чтобы задать входы краевой модели. Новая краевая модель не добавляется в дерево, необходимо вызвать Add.

Чтобы создать новую модель контура из существующей модели контура, можно использовать CreateBoundary метод всех контуров моделей:

B = CreateBoundary(B,Type)

Можно объединить граничные модели при помощи InBest свойство краевого дерева. Это соответствует объединению моделей границ в best в графическом интерфейсе пользователя редактора границ, как описано в разделе «Объединение лучших моделей границ» в документации Model Browser. Можно также объединить модели границ с логическими операторами для использования в качестве проектных ограничений или внешних проектов.

Можно изменить ActiveInputs, Evaluate, и использование в качестве designconstraint.