Важно, чтобы при применении руководств по моделированию к проекту учитывалось следующее:
Спецификация проекта модели должна быть определена до рассмотрения руководящих принципов. Это делает процесс определения того, какие руководящие принципы следует применять, и реализации руководящих принципов более эффективным.
Для примера в анализе простой модели может использоваться функция sldiagnostics чтобы выяснить, как часто используется конкретный блок. Скорректируйте список правил операции, указав часто используемые блоки, а не те, которые не используются.
Кроме того, переиспользуемость на более позднем этапе улучшается путем добавления правил, которые:
Унифицировать стили описания
Предвидите в усовершенствование человеко-часы, необходимые для коррекции моделей
Тенденции измерения, такие как размещение блоков с переменными состояния обратной связи (Unit Delay блок), должен ли блок Unit Delay находиться внутри или вне подсистемы или должен ли блок Abs быть установлен на выход стороне подсистемы, и должен ли он обрабатываться на вход стороне после приема сигнала.
В начале проекта следует определить, какие руководящие принципы применяются к каждому процессу разработки. Руководящие принципы следует оценивать и применять таким образом, чтобы они соответствовали процессу разработки. Факторы могут включать такие вопросы, как:
Будет ли руководство применяться только на этапе генерации кода?
Изменится ли принятое правило руководства для каждого этапа процесса?
Поле, к которому применяются инструкции, должно быть определено. Для примера, инструкции могут быть:
Ограничена моделью, которая представляет поле приложения AUTOSAR
Применяется к общему программному полю, такому как то, где модели реализуют прерывания (добавьте процессы, которые запрещают прерывание во время вычисления).
Характерно для полей, где генеральные инженеры редактируют модели. Целью этих правил является обеспечение того, чтобы модели были легко понятны в этих областях.
Примечание
Специализированные области могут быть исключены из ограничений этих руководящих принципов путем ограничения возможностей и применения уникального набора руководящих принципов, которые являются специфическими в этом окружении.
Специализированные поля, такие как те, где моделисты проектируют пользовательские библиотечные блоки, обычно не являются целевыми по этим рекомендациям.
Кроме того, при наличии модели управления, которая работает с быстрым прототипированием управления (RCP), вся модель не должна быть установлена как цель; вместо этого поле должно быть ограничено. Необходимо сгенерировать код и просмотреть области, которые реализованы во встроенном микрокомпьютере, а также области, которые не известны. Эти руководящие принципы не применяются к моделям управления, таким как те модели планировщика, которые сделаны исключительно для RCP и не реализованы, или для интерфейсных секций с блоками, которые соответствуют драйверам, таким как сигналы CAN и PWM для эксплуатации настоящих машин.
Руководящие принципы не должны приниматься в том виде, в котором они написаны, без дальнейшей оценки.
Реализации оценки руководящих принципов и рекомендаций по параметрам для определения воздействия на проект и используемые процессы разработки. В сложение фактора нужно принять во внимание эффекту о других рекомендациях и о том, как применение пользовательских параметров может повлиять на симуляцию или генерацию кода.
В начале проекта важно определить, как и когда будет оцениваться проект для обеспечения соблюдения руководящих принципов.
Очень важно решить, использовать ли автоматизированный механизм проверки (третью часть или внутреннюю) или выполнить проверку вручную. Также важен этап, на котором происходят проверки, а также разработка системы пересмотра критериев правил проверки.
Автоматическая проверка может значительно сократить время, необходимое для проверки. Рекомендуется, чтобы дополнительный, ручной анализ также был выполнен квалифицированным человеком, даже если все может быть проверено автоматически.
Решение применить руководство или правило может измениться. При этом важно определить процесс и процедуру определения первопричины запроса и оценить потенциальное влияние изменения на проект и организацию.
При оценке запроса на изменение сначала прослушайте потребности моделиста и определите первопричину запроса. Когда запрос основан на том, что пользователь не понимает использование блоков или правило руководства, обучение должно происходить вместо пересмотра правила.
Процедура ослабления правил по мере необходимости должна реализовываться при наличии ограничений из-за целей компании и контрольных спецификаций или оборудования (таких как микрокомпьютеры).