В этом разделе описывается компонентный подход к проверке кода AUTOSAR с помощью Polyspace. Подход к интеграционному анализу см. в разделе Выбор между компонентным и интеграционным анализом кода AUTOSAR с Polyspace.
При использовании методологии AUTOSAR для разработки программного обеспечения с командой build для компиляции можно повторно использовать существующие артефакты для указания исходных файлов и параметров компиляции для программы Code Prover.
Можно повторно использовать спецификацию исходного файла в XML-файлах AUTOSAR.
Polyspace ® может считывать спецификации AUTOSAR XML и извлекать исходные файлы, используемые в каждом программном компоненте, в модули для последующих проверок времени выполнения программы Code Prover. При использовании методологии AUTOSAR для разработки программного обеспечения можно повторно использовать встроенную в эту методологию модуляризацию для модульного анализа Prover кода. Посмотритеpolyspace-autosar.
Можно повторно использовать параметры компиляции, указанные в команде build.
Polyspace может отслеживать вашу команду build и обнаруживать вызываемый компилятор вместе с параметрами компиляции, такими как пути к стандартным включениям и определения макросов. Посмотрите polyspace-configure.
В этом разделе показано, как объединить эти два подхода и автоматизировать анализ проверки кода.
![]()
Для выполнения действий, описанных в этом учебном пособии, используйте демонстрационные файлы в В этом примере используется макияж на основе Linux и разделители путей Linux. Чтобы запустить пример в Windows ®, внесите соответствующие изменения. |
Скопируйте содержимое демонстрационной папки во временную папку, например: /tmp/demo/. Перейдите в эту папку.
cd /tmp/demo |
Запуск программы проверки кода для ARXML и исходных файлов во вложенной папке mRtwDemoAutosar_autosar_rtw. Сохранить результаты в папке /tmp/res.
polyspace-autosar -create-project /tmp/res \ -arxml-dir mRtwDemoAutosar_autosar_rtw \ -sources-dir mRtwDemoAutosar_autosar_rtw |
Обратите внимание на ошибки компиляции. Например, в /tmp/res/.extract папка, откройте файл GPIO_read.log. Вы видите #error директива, потому что макрос MY_DEFINE_FROM_SIMULINK не определен.
При открытии файла GPIO_read.c в /tmp/demo/mRtwDemoAutosar_autosar_rtw, вы видите линию, вызывающую проблему.
#ifndef MY_DEFINE_FROM_SIMULINK #error Missing MY_DEFINE_FROM_SIMULINK #endif |
Эта строка должна вызвать ошибку во время предварительной обработки, если только макрос не MY_DEFINE_FROM_SIMULINK определяется.
![]()
makefile mRtwDemoAutosar.mk в /tmp/demo/mRtwDemoAutosar_autosar_rtw определяет макросы и пути для включения папок. Например, ранее отсутствовавший макрос MY_DEFINE_FROM_SIMULINK определяется в строке:
DEFINES_CUSTOM = -DMY_DEFINE_FROM_SIMULINK |
Перейдите в папку, содержащую make-файл.
cd /tmp/demo/mRtwDemoAutosar_autosar_rtw |
Извлечение параметров компиляции из команды построения, использующей этот make-файл mRtwDemoAutosar.mk. Например, если вы установили MATLAB ® в/usr/local/MATLAB/R2018bВы можете отследить файл макияжа вот так.
polyspace-configure -no-sources \ -output-options-file psoptions -allow-overwrite\ make -B -f mRtwDemoAutosar.mk START_DIR=.. \ MATLAB_ROOT=/usr/local/MATLAB/R2018b buildobj |
Опции компиляции в make-файле преобразуются в опции анализа Polyspace и сохраняются в файле опций. psoptions. -no-sources опция гарантирует, что polyspace-configure извлекает только параметры компиляции, но не источники. START_DIR и MATLAB_ROOT являются переменными, специфичными для демонстрационного make-файла и могут не потребоваться в других makefile, которые вы используете.
Удаление результатов из любого предыдущего прогона polyspace-autosar команда.
rm -r /tmp/res |
Предоставьте файл параметров psoptions создан на предыдущем шаге к polyspace-autosar команда.
polyspace-autosar -create-project /tmp/res \ -arxml-dir . \ -sources-dir .\ -extra-options-file psoptions |
Ошибки компиляции больше не отображаются, так как программе проверки кода известны параметры компиляции, использованные в команде build.
![]()