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