После проверки Simulink® модель для стандартов податливости и ошибок проектирования, можно сгенерировать код из модели. Перед развертыванием можно выполнить финальный слой проверки ошибок сгенерированного кода при помощи Polyspace®. Проверки обнаруживают такие проблемы, как мертвая логика или неправильные опции генерации кода, которые могут остаться, несмотря на тесты на модели.
Ниже приведены примеры проблем, которые обнаруживаются в сгенерированном коде, но могут быть исправлены в исходной модели.
Прежде чем запускать Polyspace из Simulink, необходимо связать Polyspace и MATLAB® установки. См. «Интеграция Polyspace с MATLAB и Simulink».
Чтобы открыть модель, используемую в этом примере, в Командном окне MATLAB, запустите:
openExample('polyspace_code_prover/FixIssuesInGeneratedCodeFoundWithPolyspaceCodeProverExample')
Модель CruiseControl_RP
содержит диаграмму Stateflow с проблемами проекта. Проблемы преобразуются в возможные ошибки времени выполнения или недоступные ветви в сгенерированном коде.
Сгенерируйте код С из модели и проверьте сгенерированный код на ошибки времени выполнения с помощью Polyspace Code Prover™.
Чтобы сгенерировать код, на вкладке Apps выберите Embedded Coder. Затем на вкладке C Code выберите Generate Code. Следите за прогрессом генерации кода в Simulink Diagnostic Viewer.
Для получения дополнительной информации смотрите Сгенерировать код С из моделей Simulink (Embedded Coder).
Анализ Code Prover по умолчанию запускает только проверки во время выполнения Code Prover. Включите MISRA C®Проверка 2012 года в дополнение к проверкам по умолчанию.
На вкладке Polyspace выберите Settings, чтобы открыть окно Simulink Параметры Конфигурации. В раскрывающемся Settings from выберите Project configuration and MISRA C 2012 checking
.
На вкладке Polyspace щелкните в любом месте холста. В Analyze Code from поле показано имя модели. Выберите Run Analysis. Следите за прогрессом анализа кода в Командном окне MATLAB.
Для получения дополнительной информации смотрите Запуск анализа Polyspace на коде, сгенерированном с помощью Embedded Coder.
Результаты Code Prover открываются в пользовательском интерфейсе Polyspace. Результаты содержат некоторые серые проверки (недоступный код) и оранжевые проверки (потенциальные ошибки времени выполнения).
Выберите одну из двух проверок Unreachable code. Проверьте код, который недоступен.
if ((CoastSetSw_prev != CruiseControl_RP_DW.CoastSetSw_start) && CruiseControl_RP_DW.CoastSetSw_start && (CruiseControl_RP_Y.tspeed > (real_T)mintspeed)) { /* Transition: '<S1>:74' */ CruiseControl_RP_DW.is_ON = CruiseControl_RP_IN_Coast; CruiseControl_RP_DW.temporalCounter_i1 = 0U; /* Entry 'Coast': '<S1>:73' */ CruiseControl_RP_Y.tspeed -= (real_T)incdec; }
Нажмите на Transition:'<S1>:74'
ссылка в if
блок. Переход подсвечивается в модели.
Обратите внимание на проект недостаток. Условие для исходящего перехода 3 не может быть верным без условия для исходящего перехода 2, также являющегося истинным. Поэтому переход 3, который выполняется позже, никогда не достигается. Этот проект недостаток на графике переводится в недоступное if
блок в сгенерированном коде.
Устранить проблему можно различными способами. Одной из возможностей является переключение порядка выполнения переходов 2 и 3. Для начала щелкните правой кнопкой мыши переход 3.
Если вы регенерируете и повторяете код, вы больше не видите серые проверки Unreachable code.
Выберите одну из двух проверок Division by zero. Проверьте код.
if (CruiseControl_RP_DW.temporalCounter_i1 >= (uint32_T)(incdec /
holdrate * 10.0F))
holdrate
. Вы видите, что это глобальная переменная, значение которой может быть нулем.Тот факт, что holdrate
- глобальная переменная, подсказка о том, что она может быть задана вне модели. Откройте окно Model Explorer. В иерархии модели выберите базовое рабочее пространство. Поиск holdrate
в списке параметров. Видишь, что holdrate
имеет значение 5, но может варьироваться от 0 до 10. Анализ Code Prover использует эту область значений и обнаруживает деление на нули.
Можно изменить сгенерированный код или строение анализа:
Измените код:
В окне Model Explorer измените класс памяти holdrate
от Global
на Define
. Сгенерированный код задает typedef, который гарантирует, что holdrate
имеет значение 5.
#define holdrate 5
Измените строение анализа:
На вкладке Polyspace выберите Settings. Измените опцию Настраиваемые параметры, чтобы использовать данные калибровки. Анализ Code Prover использует значение 5 для holdrate
вместо области значений [0.. 10].
Если вы регенерируете и повторно анализируете код, вы больше не видите проверки оранжевого Division by zero. Вы также не видите другие оранжевые проверки, потому что они имеют ту же первопричину. На Dashboard панели показано, что все проверки зеленого цвета.
Выберите нарушение правила 3.1:
The character sequences /* and // shall not be used within a comment.
typedef struct { uint8_T CC_Mode; /* '<Root>/CC_Mode' */ boolean_T RES; /* '<Root>/RES//+' */ boolean_T SET; /* '<Root>/SET//-' */ real_T SpeedSet; /* '<Root>/Speed_Set' */ real_T SpeedAct; /* '<Root>/Speed_Act' */ boolean_T Break; /* '<Root>/Break' */ } ExtU_CruiseControl_RP_T;
//
в код комментариях в определении структуры.Чтобы перейти к соответствующему местоположению в модели, нажмите '<Root>/RES//+'
в код комментарии. Вы видите, что комментарий происходит от переменного входа RES/+
который содержит /
символ.
Переименуйте переменную, а также SET/-
чтобы они не использовали /
символ. Когда вы повторно анализируете код, вы больше не видите нарушений правила 3.1.