Разделите дизайн, когда это станет слишком комплексным для одного человека, чтобы знать все детали. Сложность увеличивается с размером дизайна и размером команды, например,
Размер дизайна и сложность:
Тысячи блоков
Сотни логических решений
Сотни вводов и выводов
Сотни времен большие промышленные примеры в некоторых случаях
Несколько различных настроек той же функциональности
Интегрирование команды:
Несколько человек, работающих на дизайне
Люди расположены в различных местах
Люди от различных компаний
Разделение вашего дизайна в компоненты помогает вам работать с крупномасштабными проектами. Разделение дизайна в компоненты дает модульный принцип, чтобы помочь вам уменьшить сложность, сотрудничать на разработке, тесте и компонентах повторного использования, и успешно выполниться с крупномасштабным модельно-ориентированным проектированием. Компонентно-ориентированное моделирование помогает:
Включите эффективную и устойчивую разработку системы.
Уменьшите сложность общего замысла путем решения меньших проблем.
Получите выигрыши в производительности та шкала.
Компоненты повторного использования через несколько проектов.
Упростите сотрудничество
Алгоритмы раздела, физические модели и тесты. Задайте архитектуру с точки зрения структурного и функционального разбиения дизайна с помощью заданных интерфейсов.
Сотрудничайте с командами через организационные контуры на разработке нового продукта. Команды могут разработать отдельные компоненты независимо, чтобы сделать моделирование завода, дизайн алгоритма и разработку тестовых обвязок.
Справьтесь с дизайном с инструментами системы контроля версий.
Улучшенная итерация, разработка и рабочие процессы верификации
Выполните итерации быстрее через более эффективное тестирование и повторное использование.
Устраните перетестирование на неизменные компоненты.
Модели среды повторного использования и алгоритм разрабатывают в различных проектах.
Создайте варианты проектов.
Тщательно продуманные компоненты независимо через четко определенные интерфейсы.
Справьтесь с эволюцией дизайна с инструментами управления конфигурацией.
Компонентно-ориентированное моделирование требует:
Механизмы для разделения моделей и определения интерфейсов
Инструменты и процессы для данных управления, моделей и среды
Используйте следующие методы для компонентно-ориентированного моделирования.
Компонентизация предоставляет преимущества для крупномасштабных проектов, но не необходима для маленьких проектов. Разделение вашего дизайна в компоненты требует дизайнерской работы и может увеличить время, потраченное, чтобы обновить схемы. Используйте отдельные компоненты только, когда ваш дизайн будет достаточно большим, чтобы извлечь выгоду из компонентизации.
Чтобы решить, нужно ли для вашего дизайна разделение, см. рекомендации в Инструкциях для Размера Компонента и Функциональности.
После того, как модели становятся большими и объединяют в зависимости от времени, трудно разделить их в компоненты, чтобы позволить нескольким инженерам работать на них параллельно. Разделение модели Simulink® в компоненты легче, если модель разработана для компонентизации от запуска. Разработка для компонентизации во-первых может помочь вам избежать этих трудностей:
Если единственный инженер разрабатывает модель с самого начала, добавляя блоки и группируя их в подсистемы, когда сложность модели увеличивается, трудно позже разделить модель в компоненты. Подсистемы в модели являются часто “виртуальными” и неатомарными. Когда вы преобразовываете их в атомарные подсистемы и затем в компоненты модели - ссылки, можно представить нежелательные алгебраические циклы, которые трудно диагностировать и решить.
Подсистемы, выращиваемые в зависимости от времени, не всегда представляют лучший способ разделить модель. “Лучше всего” здесь может означать самую полезную структуру для допускающих повторное использование компонентов в других моделях, или для генерации кода, который интегрируется с устаревшей функциональностью, или для выполнения Аппаратных средств в тестах цикла, и т.д.
При попытке расшириться, чтобы быть параллельными разработке, не разбивая на компоненты модели, трудно совместно использовать, работают в командах без длительного и подверженного ошибкам слияния подсистем.
Эти проблемы походят на взятие большой части кода (C, Java или код MATLAB®) и попытка разломать его на много отдельных функций. Значительное усилие требуется и может потребовать обширных модификаций к некоторым частям кода, если код не был разработан, чтобы быть модульным во-первых. То же самое верно для моделей Simulink.
Отсутствие компонентизации вызывает общие типы отказа при попытке поместить модели Simulink в управление конфигурацией, когда они растут, и вы хотите, чтобы больше чем один инженер работал на нем параллельно. Лучший способ избежать этих проблем состоит в том, чтобы разработать для компонентов от запуска. Можно использовать следующие функции Simulink, чтобы разработать модель, подходящую для компонентизации.
Если у вас уже есть дизайн, который вы хотите разделить на компоненты, видеть Раздел Существующий Дизайн.
Чтобы настроить ваш проект для команды продолжить работать, рассмотрите следующие инструкции по архитектуре модели для компонентов. Полезные компоненты:
Имейте четко определенные контуры интерфейса I/O.
Выполните заданный набор функций (действия), заданные требованиями.
Явитесь частью большей системы.
Имейте “правильный” размер:
Достаточно большой, чтобы быть допускающим повторное использование
Достаточно маленький, чтобы быть протестированным
Только один инженер, вероятно, захочет отредактировать каждую модель за один раз
Правильный размер может зависеть от размера команды. У вас могут быть большие компоненты, если только один человек работает на каждом, но если необходимо совместно использовать компоненты между несколькими людьми, вероятно, необходимо разделить дизайн на меньшие логические части. Это помогает двум голам: понимание дизайна и сокращение конкуренции файла и время потрачены на слияние.
Рекомендации:
В большинстве случаев, если у вас есть меньше чем 100 блоков, не делите дизайн на компоненты. Вместо этого используйте подсистемы, если вы хотите создать визуальную иерархию. Например, модель в качестве примера vdp не является достаточно большой, чтобы извлечь выгоду из компонентизации.
Если вы имеете 500–1000 блоков, полагаете, что создание модели - ссылки содержит тот компонент в отдельном файле. Стоимость верификации может уменьшить размер для компонентов. Например, если вы имеете маленький компонент 100 блоков с высокими затратами на тестирование и частыми изменениями, полагаете, что распадение что компонент в отдельный файл делает верификацию легче.
Рассмотрите деление основанного на модели на:
Физические компоненты (e. g., завод и контроллер, для генерации кода)
Логика алгоритма
Возможность многократного использования в других моделях
Тестируемость, например, для выполнения Аппаратных средств в тестах цикла
Частота дискретизации; рассмотрите группирующиеся компоненты, которые имеют ту же частоту дискретизации
Скорость симуляции; использование различных решателей для компонентов с различными числовыми свойствами может увеличить скорость симуляции
Доступность другим командам или другим в вашей команде.
В то время как вы не можете всегда планировать размер модели, если вы ожидаете, что несколько человек будут работать на дизайне, можно извлечь выгоду из методов компонентизации. Рассмотрите управление конфигурацией управления с помощью Проекта Simulink и деля дизайн с помощью Модели - ссылки так, чтобы команда могла работать на отдельных файлах одновременно.
| Размер компонента | Рекомендуемые методы компонентизации | Примечания |
|---|---|---|
Маленький <500 блоков | Создайте визуальную иерархию с помощью подсистем. | Маленькие проекты не извлекают выгоду из деления на отдельные файлы. Однако более многочисленные команды, которые вызывают конкуренцию файла или высокую стоимость верификации, могут сделать его стоящим делящих меньших компонентов в отдельные файлы вместо того, чтобы использовать подсистемы. |
| Большой> 500 блоков | Разделите компоненты на отдельные файлы с помощью Модели - ссылки или Библиотек. | Для нескольких инженеров или команд, работающих на дизайне, лучшой практикой является один файл на компонент. Чтобы уменьшить конкуренцию файла, стремитесь к компонентам, в которых только один инженер должен отредактировать каждую модель за один раз. |
Маленький <500 блоков, но ожидаемый расти в зависимости от времени | Используйте атомарные подсистемы для функционального блока, группирующегося вместо виртуальных подсистем. Атомарные подсистемы легче переместить, чтобы разделить компоненты файла позже. | Если возможно, план ваши компоненты от запуска, чтобы избежать боли миграции. |
Если ваш дизайн или команда являются достаточно большими, чтобы извлечь выгоду из распадающихся компонентов в отдельные файлы, эта таблица суммирует, когда применить каждый метод.
| Характеристики компонента | Метод | Преимущества | Затраты |
|---|---|---|---|
| Маленькие, низкоуровневые служебные функции, снова использованные во многих местах в дизайне | Модель библиотеки, содержащая единственную допускающую повторное использование атомарную подсистему |
|
|
| Группы блоков для совместного использования среди пользователей | Библиотека для группировки и хранения блоков Simulink Палитра Library ссылок на компоненты |
|
|
Компоненты верхнего уровня для крупномасштабных моделей:> 500 блоков Большие компоненты: запуск в ~ 500–5000 блоков для один или несколько допускающих повторное использование экземпляров, или меньший, если много экземпляров Компоненты на любом уровне иерархии модели, где команды должны работать независимо | Образцовая ссылка |
| Производительность может уменьшить немного при обновлении модели (схема обновления), потому что каждая эталонная модель проверяется на изменения, чтобы включить инкрементные сборки. То, когда компоненты являются достаточно большими (> 500 блоков), обновляют схему, быстрее в большинстве случаев. Смотрите раздел дизайн Используя модель - ссылку. |
Чтобы выполнить параллельную разработку, вам нужно компонентно-ориентированное моделирование. Лучшая практика для успешной основанной на команде разработки состоит в том, чтобы разделить модели в рамках проекта так, чтобы только один пользователь работал на каждой части за один раз. Компонентизация позволяет вам избежать или минимизировать длительное слияние. Чтобы настроить ваш проект для работы команды, рассмотрите следующие инструкции по архитектуре модели.
Эта таблица сравнивает подсистемы, библиотеки и ссылку модели для основанной на команде разработки.
| Моделирование процесса разработки | Подсистемы | Библиотеки | Образцовая ссылка |
|---|---|---|---|
Основанная на команде разработка | Не поддерживаемый Для подсистем в модели Simulink не предоставляет никакому прямому интерфейсу инструменты системы контроля версий. Чтобы создать или изменить подсистему, необходимо открыть файл родительской модели. Это может привести к конкуренции файла, когда несколько человек хотят работать на нескольких подсистемах в модели. Слияние подсистем является медленным и подверженным ошибкам, так же лучше всего избегаемое как процесс рабочего процесса. Однако Отчет Simulink Generator™ обеспечивает инструменты, чтобы помочь вам объединить подсистемы. Смотрите Слияние Модели Simulink из Отчета Сравнения. | Поддерживаемый, с ограничениями Можно поместить файлы библиотеки в систему контроля версий для системы контроля версий и управления конфигурацией. Можно использовать Проект Simulink взаимодействовать с системой контроля версий. Можно поддержать одну истину путем распространения изменений от единственного блока библиотеки до всех блоков, которые соединяются с той библиотекой. Чтобы уменьшить конкуренцию файла, используйте одну подсистему на библиотеку. Можно соединиться с тем же блоком библиотеки от многоуровневых моделей. Можно ограничить доступ для записи к компонентам библиотеки. | Хорошо удовлетворенный Можно поместить файлы модели - ссылки в систему контроля версий для системы контроля версий и управления конфигурацией. Можно использовать Проект Simulink взаимодействовать с системой контроля версий. Вы сохраняете модель, на которую ссылаются, в отдельном файле от модели, которая ссылается на него. Используя отдельные файлы помогает избежать конкуренции файла. Можно разработать, создать, моделировать и протестировать модель, на которую ссылаются, независимо от модели, которая ссылается на нее. Simulink не ограничивает доступ для изменения модели - ссылки. |
Большинство больших моделей использует комбинацию методов компонентизации. Никакой единственный подход не подходит для широкого спектра пользователей Simulink. Следующий совет описывает некоторые типичные процессы, чтобы показать то, что можно сделать с инструментами MathWorks®, чтобы выполнить основанную на команде разработку.
Чтобы выполнить эффективную параллельную разработку, повредите большую модель во многие отдельные файлы, так, чтобы члены команды могли работать независимо, и можно поместить каждый файл при управлении версиями. Компонентизация позволяет вам избежать или минимизировать длительное слияние. Чтобы настроить ваш проект для работы команды, рассмотрите совет в Инструкциях для Размера Компонента и Функциональности.
Основная цель компонентно-ориентированного моделирования состоит в том, чтобы позволить параллельную разработку, где различные инженеры могут работать на компонентах большей системы параллельно. Можно достигнуть этого, если каждый компонент является единственным файлом. Можно затем управлять и проследить изменения в каждой системе контроля версий использования компонента в Проекте Simulink. Смотрите управление конфигурацией.
Если у вас уже есть дизайн, который вы хотите разделить на компоненты, сначала решить, где разделить модель. Существующие подсистемы, которые растут в зависимости от времени, являются не всегда лучшим способом разделить модель. Рассмотрите деление основанного на модели на совете в Инструкциях для Размера Компонента и Функциональности.
Достижение соглашения об интерфейсе является полезным первым шагом в решении, как сломать функциональность большой системы в субкомпоненты. Можно сгруппировать данные раздела и сигналы. Смотрите Дизайн интерфейса.
После того, как вы решаете, как разделить ваш дизайн, инструменты Simulink могут помочь вам разделить существующую модель на компоненты.
Simulink может помочь вам модели раздела путем преобразования подсистем в файлы. Можно преобразовать в файлы с помощью Модели - ссылки или Библиотек. См. Инструкции для Размера Компонента и Функциональность для предложений на том, когда применить каждый метод.
Используйте Модель - ссылку, чтобы разделить компоненты на отдельные файлы так, чтобы команда могла работать на отдельных файлах одновременно. Можно также снова использовать модели в других моделях. Чтобы разделить модель с помощью модели - ссылки, смотрите Ссылочные Существующие Модели или Преобразуйте Подсистемы в Модели, на которые Ссылаются.
Пользуйтесь Библиотеками, содержащими единственную подсистему, чтобы содержать компонент в единственном файле. Пользуйтесь библиотеками, чтобы сохранить блоки, которые можно снова использовать в моделях. Соединенные блоки наследовали атрибуты от окружающих моделей, таких как типы данных и частота дискретизации. Используя этот метод для компонентизации имеет управление наверху ссылками библиотеки, описанными ниже.
Пользуйтесь Библиотеками, чтобы снова использовать блоки в многоуровневых моделях. Библиотеки работают хорошо на группировку и хранение блоков Simulink, чтобы совместно использовать. Лучшая практика для библиотек состоит в том, чтобы использовать их для хранения блоков, чтобы совместно использовать со многим пользователем и блоками, которые нечасто обновляются. Как грубая инструкция, уместно использовать Библиотеку Simulink, если ее содержимое обновляется один раз в несколько месяцев. Если вы обновляете его более часто, то библиотекой, вероятно, пользуются, чтобы выполнить управление конфигурацией. В этом случае заботьтесь, чтобы избежать типичных проблем, описанных в управлении Ссылкой Библиотеки.
Чтобы сделать блоки библиотеки доступными для повторного использования при сокращении конкуренции файла и применении управления версиями, используйте палитры библиотеки. Палитра является библиотекой, содержащей ссылки на другие компоненты. Если каждый компонент является единственной подсистемой в отдельной библиотеке или файлом модели - ссылки, можно достигнуть одного файла на лучшую практику компонента для компонентно-ориентированного моделирования. Можно использовать управление отдельной версией для каждого компонента, и можно также управлять палитрой.
Когда вы перетаскиваете блок от палитры библиотеки в вашу модель, Simulink переходит по ссылке назад на файл, где подсистема или модель - ссылка реализованы. Модели, которые используют компонент, содержат ссылку на компонент а не на палитру.
Ссылки библиотеки могут представить управление наверху, если вы используете их для управления конфигурацией. Всего хорошего, чтобы справиться:
Отключенные ссылки — Могут вызвать конфликты слияния и отказ обновить все экземпляры того же компонента модели. В иерархии ссылок можно случайно отключить все ссылки, не будучи знающими об этом, и только восстановить одну ссылку, в то время как отъезд других отключил.
Неработающие ссылки — Случайно неработающие ссылки являются тяжелой проблемой решить, потому что дизайном вы не можете обнаружить что неработающая ссылка, соединенная с ранее.
Параметризованные данные ссылки — может быть полезно изменить значение данных параметра, таких как значение усиления в блоке усиления, не отключая ссылку библиотеки. Это генерирует “данные ссылки” для того экземпляра только. Однако, для управления конфигурацией это может вызвать проблему, если вы принимаете, что все экземпляры идентичны, когда у каждого теперь есть различные свойства.
Инструменты Simulink помогают вам управлять ссылками библиотеки, чтобы избежать проблем:
Заблокируйте ссылки, чтобы предотвратить редактирование. Смотрите Ссылки Блокировки на Блоки в Библиотеке.
Используйте диагностические опции, чтобы проверить целостность ссылки библиотеки каждый раз, когда вы сохраняете модель. Можно установить проверки предупреждать, ошибка, или игнорировать, что модель отключила или параметризовала ссылки библиотеки. Вы выбираете эти настройки на модель. В диалоговом окне Configuration Parameters смотрите Диагностику> Сохранение.
Смотрите, что диагностическая Блок-схема настроек содержит отключенные ссылки библиотеки, и Блок-схема содержит параметризованные ссылки библиотеки.
Используйте Образцовые проверки Советника, чтобы сообщить относительно целостности ссылки библиотеки. Советник проверяет на отключенные и параметризованные ссылки в модели. Можно использовать получившийся отчет в качестве артефакта, чтобы зарегистрироваться в системе управления конфигурацией.
Смотрите Образцовые проверки Советника:
Используйте Инструмент ссылок, чтобы просмотреть и восстановить отключенные и отредактированные ссылки. Смотрите Восстановление Отключенные или Параметризованные Ссылки.
Эти инструменты управления ссылки могут обнаружить проблемы ссылки, но не могут предотвратить редактирование неправильных файлов. Если это - проблема, то используйте Модель - ссылку в качестве механизма разделения, чтобы избежать рисков, сопоставленных с отключенными, разорванными, и параметризованными связями.
