Документация

Polyspace модулирует анализ на основе компонентов AUTOSAR

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>

Для этой модуляризации вы просто предоставляете две папки с ARXML и исходными файлами.

Polyspace для AUTOSAR использует тот факт, что необходимая информация уже присутствует в ваших спецификациях ARXML, и модулирует ваш код. Вам не нужно знать детали спецификаций ARXML или реализации кода для выполнения анализа. Вы просто предоставляете папки, содержащие ваши ARXML и исходные файлы.

Без этой автоматической модуляризации вы должны вручную добавить реализацию каждого программного компонента (файлы с функциями точки входа, реализующими runnables, функции, вызываемые внутри и так далее) к модулю. Не только это, вы должны задать интерфейс для каждого выполняемого, то есть область значений значений для входов на основе их типов данных.

Polyspace обнаруживает несоответствие между кодом и авто-РСА XML

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_ функционирует так, где тип data задается в ARXML.

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);

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.