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