Polyspace® для AUTOSAR запускает статический анализ программы реализации кода компонентов программного обеспечения AUTOSAR. Анализ ищет возможные ошибки времени выполнения или несоответствие со спецификациями в AUTOSAR XML (ARXML).
Polyspace для AUTOSAR читает спецификации ARXML, которые вы обеспечиваете, и строит анализ из модулей на основе компонентов программного обеспечения в спецификациях ARXML. Анализ затем проверяет каждый модуль на:
Несоответствие со спецификациями AUTOSAR: Эти проверки стремятся доказывать, что определенные функции реализуются или используются в соответствии со спецификациями в ARXML. Проверки применяются к runnables (функции, обеспеченные компонентами программного обеспечения) и к использованию функций, предоставленных Средой выполнения (RTE). Смотрите также:
Например, если аргумент функции RTE имеет значение вне ограниченной области значений, заданной в ARXML, анализ отмечает возможную проблему.
Ошибки времени выполнения: Эти проверки стремятся доказывать отсутствие определенных типов ошибок времени выполнения в телах runnables (например, переполнение). Доказательство использует спецификации в ARXML, чтобы определить точные области значений для выполнимых аргументов и возвращаемых значений функции RTE и выходных аргументов. Например, доказательство рассматривает только те значения выполнимых аргументов, которые заданы в их типах данных AUTOSAR.
После анализа можно открыть результаты для каждого модуля в пользовательском интерфейсе Polyspace. При рассмотрении несоответствия между кодом и спецификациями ARXML, можно перейти к соответствующему извлечению ARXML.
Эта тема показывает, как Polyspace является AUTOSAR-aware и помогает в рабочем процессе разработки AUTOSAR. Для фактических шагов для рабочего Polyspace см.:
Polyspace для AUTOSAR строит ваш код из модулей путем многократного использования модуляризации, уже существующей в спецификациях ARXML. Модуляризация основана на компонентах программного обеспечения в спецификациях ARXML. Модульное исполнение вашего кода важно, чтобы избежать долгих аналитических времен и позволить более точный анализ.
Компонент программного обеспечения состоит из одного или нескольких runnables. Вы реализуете runnables через функции.
Компонент программного обеспечения (SWC) является модулем функциональности на прикладном уровне архитектуры AUTOSAR. Компонент программного обеспечения имеет внутреннее поведение, которое состоит из типов данных, событий, одна или несколько выполнимых сущностей (задачи) и другая информация.
AUTOSAR XML перечисляет внутреннее поведение компонента программного обеспечения как это (версия 4.0 XML-схемы AUTOSAR):
<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 для AUTOSAR создает проект с отдельным модулем для каждого компонента программного обеспечения. В одном модуле Polyspace собирает исходный код (.c и .h файлы), содержащий реализацию всего runnables в компоненте программного обеспечения и генерирует любой дополнительный заголовочный файл, требуемый для реализации.
Проект Polyspace с двумя модулями от двух компонентов программного обеспечения может выглядеть так:
Имя модуля соответствует полностью определенному имени внутреннего поведения компонента программного обеспечения.
Например, имя pkg.tst002.swc001.bhv001 соответствует этой структуре XML (версия 4.0 XML-схемы AUTOSAR):
<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 runnables связываются через Rte_ функции.
Реализация выполнимые функции использования AUTOSAR, обеспеченные средой выполнения (RTE) для связи с runnables в другом SWCs. Например, функциональный Rte_IWrite_ может использоваться к, обеспечивает доступ для записи к runnableПорт_variablevariable
Rte_IWrite_step_out_e4(self, e4);
Аргументам функции задали типы данных в ARXML.
Этим функциям задали подписи в стандарте AUTOSAR с типами данных параметров, которые детализированы в спецификациях ARXML. Например, стандарт задает подпись Rte_IWrite_ функционируйте как это, где тип data
void Rte_IWrite_re_p_o([IN Rte_Instance], IN data)
При развертывании реализации генератор Среды выполнения использует информацию в спецификациях ARXML, чтобы создать заголовочные файлы с определениями типов для приложения. При разработке реализации вы не должны волноваться о деталях связи с другим SWCs. Вы просто используете Rte_ функции и типы данных предусмотрели вашу реализацию.
Аналогично, типы данных входных параметров, выходных параметров и возвращаемого значения вашего выполнимого также перечислены в ARXML.
Можно ограничить типы данных в ARXML использование ограничений данных.
В ваших спецификациях ARXML вы часто ограничиваете значения, сопоставленные с типами данных с помощью ограничений данных. Ограничительная спецификация данных может выглядеть так (версия 4.0 XML-схемы AUTOSAR):
<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, ограничения данных прибывают из диапазонов сигнала в модели.
Во время выполнения ваша реализация кода может нарушить ограничения данных.
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_ функционируйте, чтобы проверять, ли аргументы в ограниченной области значений и также убеждаются, что тесты покрывают все пути к выполнению в выполнимом. В качестве альтернативы можно использовать статический анализ, который гарантирует что все продвижение путей к выполнению до Rte_ вызов функции рассматривается (до определенных разумных предположений). Polyspace использует статический анализ, чтобы определить если аргументы к Rte_ функции остаются в ограниченной области значений, заданной в файлах ARXML.
Проверки на обнаружение несоответствия в анализе Polyspace могут показать результаты как это. Здесь, второй аргумент в вызове RTE_IWrite_step_out_e4 нарушает ограничения данных в спецификациях ARXML.
Invalid result of AUTOSAR runnable implementation | Invalid use of AUTOSAR runtime environment function