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