Полезные компоненты модели имеют четко определенные возможности, выполняют функциональность, заданную требованиями, и образуют часть большей системы.
Когда вы задаете компонент, учитывайте эти потенциальные требования.
Споры с файлами - Вы можете иметь большие компоненты, если над каждым работает только один человек. Если необходимо обмениваться компонентами между несколькими людьми, следует разделить проект на меньшие логические части. Если один и тот же файл необходимо отредактировать нескольким людям, см. раздел «Объединение моделей Simulink» из отчета о сравнении.
Переиспользуемость - если вы ожидаете использовать группу блоков несколько раз в модели, задайте группу блоков в повторно используемом компоненте. Избегая дублирования, вы облегчаете поддержание модели. Чтобы рефакторить существующую модель с дублированием, смотрите Модели рефактора для улучшения повторного использования компонента (Simulink Check).
Генерация кода - Если вы должны сгенерировать автономный код для физического компонента, такого как цифровой контроллер, у вас должен быть один компонент, который представляет физический компонент и имеет четко определенный интерфейс.
Стоимость верификации - Если часть модели изменяется часто и имеет высокие затраты на тестирование, вы должны управлять этой частью модели как компонентом в отдельном файле. Когда компоненты определены в отдельных файлах, можно управлять и отслеживать изменения с помощью системы контроля версий проекта. Для получения дополнительной информации о системе контроля версий см. раздел Строения Management.
Скорость симуляции - Использование других решателей для компонентов с различными числовыми свойствами может увеличить скорость симуляции. Точно так же группировка блоков на основе их частоты дискретизации может увеличить скорость симуляции. Для получения дополнительной информации смотрите Solver Profiler и Улучшите Эффективность Симуляции Используя Performance Advisor.
Требования к моделированию могут влиять на размер ваших компонентов. Для примера модели с менее чем 500 блоками легче протестировать, чем большие модели. Однако симуляция может быть более быстрой для иерархий модели, когда модели-ссылки содержат более 500 блоков.
Различные типы Simulink® компоненты служат различным требованиям к моделированию.
Тип компонента | Определение | Источник содержимого | Реализация в модели |
---|---|---|---|
Подсистема |
Уникальная группа блоков с динамическим интерфейсом, который может быть визуальным или функциональным. |
Нет - Содержимое должно быть добавлено вручную к каждой подсистеме | Subsystem блок |
Ссылка на подсистему |
Ссылка на переиспользуемую группу блоков с динамическим интерфейсом, который может быть визуальным или функциональным. |
Файл подсистемы ( | Subsystem Reference блок |
Модель-ссылка |
Ссылка на модель с четко заданным интерфейсом, который является функциональным и независимым от родительской модели. |
Файл модели ( | Model блок |
Вариантная система |
Множественные реализации компонента с одной активной реализацией. Вариантные системы позволяют вам удовлетворять различные наборы требований в рамках одной модели. Вариантами могут быть любой другой тип компонента, включая комбинацию типов компонентов. |
Нет - варианты должны быть добавлены вручную в каждую вариантную систему | Variant Subsystem блок |
Связанный блок, который может быть связан с любым компонентом, хранящимся в библиотеке |
Связанный образец блока, который хранится в библиотеке. Если отключить ссылку на библиотеку, каждый образец связанного блока может быть уникальным. Когда вы перетаскиваете ссылку или модель-ссылку подсистемы из библиотеки в модель, она непосредственно ссылается на файл подсистемы или файл модели, который задает его содержимое. Она имеет ссылку на библиотеку, только когда родительский библиотечный блок имеет маску, примененную непосредственно к нему. Как правило, следует использовать маски модели, которые сохраняются в файле и не требуют ссылки на библиотеку. |
Файл библиотеки ( | Блок с библиотечной ссылкой |
Модели Simulink могут использовать любую комбинацию этих компонентов. Например, чтобы минимизировать конфликт файлов для большой модели, можно преобразовать подсистемы в ссылочные подсистемы и модели, обе из которых сохранены в отдельных файлах.
Этот график потока обеспечивает начальную точку для выбора типа компонента.
Перед реализацией компонента, основанного на результате этого графика потока, рассмотрите дополнительные требования к моделированию. Для получения информации о совместимости компонентов с требованиями моделирования смотрите Сравнение возможностей компонентов модели.
Если вы ожидаете, что подсистема вырастет, сделайте ее атомарной, чтобы она функционально группировала блоки и выполняла их вместе. Функциональная группировка блоков облегчает преобразование подсистемы в ссылочную модель.
Model | Subsystem | Variant Subsystem, Variant Model