В этом разделе описывается основанный на компонентах подход к проверке кода AUTOSAR с Polyspace. Для подхода интегрирования анализа смотрите Выбор между основанным на компонентах и Интегрировании анализом кода AUTOSAR с Polyspace.
Polyspace® для AUTOSAR запускает статический анализ программы по реализации кода программных компонентов AUTOSAR. Анализ ищет возможные ошибки времени выполнения или несоответствие спецификациям в AUTOSAR XML (ARXML).
Polyspace для AUTOSAR считывает спецификации ARXML, которые вы предоставляете, и модулирует анализ на основе программных компонентов в спецификациях ARXML. Затем анализ проверяет каждый модуль на:
Несоответствие спецификациям AUTOSAR: эти проверки направлены на то, чтобы доказать, что определенные функции реализованы или используются в соответствии со спецификациями в ARXML. Проверки применяются к выполняемым средам (функции, предоставляемые компонентами программного обеспечения) и к использованию функций, предоставляемых средой Runtime Environment (RTE). См. также:
Например, если аргумент функции RTE имеет значение, выходящей за пределы ограниченной области значений, заданного в ARXML, анализ помечает возможную проблему.
Ошибки времени выполнения: Эти проверки направлены на то, чтобы доказать отсутствие определенных типов ошибок времени выполнения в телах бегущих (для образца, переполнения). Доказательство использует спецификации в ARXML, чтобы определить точные области значений для запускаемых аргументов, возвращаемых значений функций RTE и выходных аргументов. Например, доказательство рассматривает только те значения выполняемых аргументов, которые заданы в их типах данных AUTOSAR.
После анализа можно открыть результаты для каждого модуля в пользовательском интерфейсе Polyspace. При рассмотрении несоответствия между кодом и спецификациями ARXML можно перейти к соответствующему извлечению ARXML.
В этом разделе показано, как Polyspace поддерживает AUTOSAR и помогает в рабочем процессе разработки AUTOSAR. Фактические шаги для выполнения Polyspace см. в:
Polyspace для AUTOSAR модулирует ваш код, повторно используя модуляризацию, уже имеющуюся в спецификациях ARXML. Модуляризация основана на программных компонентах спецификаций ARXML. Модуляризация вашего кода необходима, чтобы избежать длительного анализа и позволить более точный анализ.
Программный компонент состоит из одного или нескольких исполняемых элементов. Вы реализуете runnables через функции.
Программный компонент (SWC) является модулем функциональности в прикладном слое архитектуры AUTOSAR. Программный компонент имеет внутреннее поведение, которое состоит из типов данных, событий, одной или нескольких выполняемых сущностей (задач) и другой информации.
В AUTOSAR XML перечислено внутреннее поведение программного компонента, подобного этому (AUTOSAR XML schema версии 4.0):
<APPLICATION-SW-COMPONENT-TYPE> <SHORT-NAME>swc001</SHORT-NAME> <INTERNAL-BEHAVIORS> <SWC-INTERNAL-BEHAVIOR> <SHORT-NAME>bhv001</SHORT-NAME> <DATA-TYPE-MAPPING-REFS> ... </DATA-TYPE-MAPPING-REFS> <EVENTS> ... </EVENTS> <RUNNABLE-ENTITY> <SHORT-NAME>foo</SHORT-NAME> ... </RUNNABLE-ENTITY> </SWC-INTERNAL-BEHAVIOR> </INTERNAL-BEHAVIORS> <APPLICATION-SW-COMPONENT-TYPE>
Как разработчик, вы реализуете тела этих выполняемых сущностей через рукописные функции C или функции, сгенерированные Simulink® модель.
iOperations_ApplicationError foo( Rte_Instance const self, app_Array_2_n320to320ConstRef aInput, app_Array_2_n320to320Ref aOutput, app_Enum001Ref aOut2) { /* Your implementation */ }
Polyspace собирает исходный код для каждого программного компонента в модуль.
Используя информацию в AUTOSAR XML, Polyspace for AUTOSAR создает проект с отдельным модулем для каждого программного компонента. В одном модуле Polyspace собирает исходный код (.c
и .h
файлы), содержащая реализацию всех runnables в программном компоненте и генерирующая любой дополнительный заголовочный файл, необходимый для реализации.
Проект Polyspace с двумя модулями из двух программных компонентов может выглядеть следующим образом:
Имя модуля соответствует полному наименованию внутреннего поведения программного компонента.
Например, имя pkg.tst002.swc001.bhv001
соответствует этой структуре XML (авто-РСА XML версии 4.0):
<AR-PACKAGE> <SHORT-NAME>pkg</SHORT-NAME> <AR-PACKAGES> <AR-PACKAGE> <SHORT-NAME>tst002</SHORT-NAME> <ELEMENTS> <APPLICATION-SW-COMPONENT-TYPE> <SHORT-NAME>swc001</SHORT-NAME> ... <SWC-INTERNAL-BEHAVIOR> <SHORT-NAME>bhv001</SHORT-NAME> ... </SWC-INTERNAL-BEHAVIOR> </APPLICATION-SW-COMPONENT-TYPE> </ELEMENTS> </AR-PACKAGE> </AR-PACKAGES> </AR-PACKAGE>
bhv001
имеет одну выполняемую foo
Polyspace собирает файлы, содержащие функцию foo
и функции, вызываемые в foo
в один модуль.Для этой модуляризации вы просто предоставляете две папки с ARXML и исходными файлами.
Polyspace для AUTOSAR использует тот факт, что необходимая информация уже присутствует в ваших спецификациях ARXML, и модулирует ваш код. Вам не нужно знать детали спецификаций ARXML или реализации кода для выполнения анализа. Вы просто предоставляете папки, содержащие ваши ARXML и исходные файлы.
Без этой автоматической модуляризации вы должны вручную добавить реализацию каждого программного компонента (файлы с функциями точки входа, реализующими runnables, функции, вызываемые внутри и так далее) к модулю. Не только это, вы должны задать интерфейс для каждого выполняемого, то есть область значений значений для входов на основе их типов данных.
Polyspace для AUTOSAR обнаруживает несоответствие между спецификациями ARXML программных компонентов AUTOSAR и их реализацией кода. Несоответствие может происходить во время исполнения между ограничениями данных в ARXML и фактическими значениями аргументов функции в коде. Обнаружение несоответствия происходит только для определенных функций: функций, реализующих runnables и Rte_
функций, используемых в runnables. Аргументы этих функций имеют типы данных, указанные в ARXML.
Выполняемые функции AUTOSAR взаимодействуют через Rte_
функций.
Реализация выполняемой функции AUTOSAR использует функции, предоставляемые окружением выполнения (RTE), для связи с выполняемыми в других SWC. Например, функция
может использоваться для предоставления доступа для записи в Rte_IWrite_<reservedrangesplaceholder0 >
_ port
_ variable
из текущей выполняемой.variable
Rte_IWrite_step_out_e4(self, e4);
Аргументы функции имеют типы данных, заданные в ARXML.
Эти функции имеют сигнатуры, указанные в стандарте AUTOSAR, с типами данных параметров, подробно описанными в спецификациях ARXML. Например, стандарт определяет сигнатуру Rte_IWrite_
функционирует так, где тип
задается в ARXML.data
void Rte_IWrite_re_p_o([IN Rte_Instance], IN data)
При развертывании реализации генератор Окружение использует информацию спецификаций ARXML для создания заголовочных файлов с определениями типов данных для вашего приложения. При разработке вашей реализации вы не должны беспокоиться о деталях связи с другими SWC. Вы просто используете Rte_
функций и типов данных, предоставленных для вашей реализации.
Точно так же типы данных входов, выходов и возвращаемого значения вашей выполняемой функции также перечислены в ARXML.
Можно ограничивать типы данных в ARXML с помощью ограничений данных.
В спецификациях ARXML часто ограничиваются значения, связанные с типами данных с помощью ограничений данных. Спецификация ограничения данных может выглядеть так (авто-РСА XML версии 4.0):
<APPLICATION-PRIMITIVE-DATA-TYPE> <SHORT-NAME>Float_n100p4321to100p8765</SHORT-NAME> <CATEGORY>VALUE</CATEGORY> <SW-DATA-DEF-PROPS> ... <DATA-CONSTR-REF DEST="DATA-CONSTR">n320to320</DATA-CONSTR-REF> ..</SW-DATA-DEF-PROPS> </APPLICATION-PRIMITIVE-DATA-TYPE> ... <DATA-CONSTR> <SHORT-NAME>n320to320</SHORT-NAME> <DATA-CONSTR-RULES> <DATA-CONSTR-RULE> <PHYS-CONSTRS> <LOWER-LIMIT INTERVAL-TYPE="CLOSED">-320</LOWER-LIMIT> <UPPER-LIMIT INTERVAL-TYPE="CLOSED">320</UPPER-LIMIT> <UNIT-REF DEST="UNIT">/pkg/types/units/NoUnit</UNIT-REF> </PHYS-CONSTRS> </DATA-CONSTR-RULE> </DATA-CONSTR-RULES> </DATA-CONSTR>
Когда Rte_
функция использует типы данных, которые ограничены таким образом, ожиданием является то, что значения, переданные функции, остаются в ограниченной области значений. Для образца, для предыдущего ограничения, если Rte_IWrite_
функция использует переменную типа n320to320
, его значение должно быть в пределах [-320, 320].
Если вы генерируете ARXML в Simulink, ограничения данных исходят из диапазонов сигнала в модели.
Во время исполнения ваша реализация кода может нарушить ограничения данных.
The Rte_
функции представляют порты в интерфейсе SWC. Итак, в эффект, когда вы ограничиваете тип данных аргумента в ARXML, порты готовятся к данным в этой области значений. Однако в вашей реализации кода, когда вы вызываете Rte_
функция, можно передать аргумент вне ограниченной области значений.
Например, при этом вызове на Rte_IWrite_step_out_e4
:
Rte_IWrite_step_out_e4(self, e4);
Rte_IWrite_step_out_e4
может иметь ранее определенный тип данных n320to320
. Но во время исполнения ваша реализация кода может передать значение вне области значений [-320, 320]. Аргумент может быть результатом ряда предыдущих операций, и одна из этих операций может привести к значению вне области допустимого.app_Enum001 e4; e4 = Rte_IRead_step_in_e4(self); ... /* Some operation on e4*/ ... Rte_IWrite_step_out_e4(self, e4);
Polyspace Code Prover™ проверяет возможные нарушения ограничений данных.
Можно либо протестировать каждый вызов Rte_
функция, чтобы проверить, находятся ли аргументы в ограниченной области значений, а также убедиться, что тесты охватывают все пути выполнения в runnable. Кроме того, можно использовать статический анализ, который гарантирует, что все пути выполнения, ведущие к Rte_
рассматривается вызов функции (вплоть до некоторых разумных допущений). Polyspace использует статический анализ, чтобы определить, будут ли аргументы Rte_
функции находятся в ограниченной области значений, заданном в файлах ARXML.
Проверки на несоответствие в анализе Polyspace могут показать такие результаты. Здесь, второй аргумент в вызове RTE_IWrite_step_out_e4
нарушает ограничения данных в спецификациях ARXML.
Invalid result of AUTOSAR runnable implementation
| Invalid use of AUTOSAR runtime environment function