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

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

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

Программный компонент состоит из одного или нескольких запускаемых модулей. Выполняемые функции реализуются с помощью функций.

Программный компонент (SWC) - это блок функциональных возможностей прикладного уровня архитектуры AUTOSAR. Программный компонент имеет внутреннее поведение, состоящее из типов данных, событий, одного или нескольких исполняемых объектов (задач) и другой информации.

В XML-файле AUTOSAR перечисляется внутреннее поведение программного компонента (схема XML AUTOSAR версии 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 файлы), содержащие реализацию всех исполняемых таблиц в программном компоненте и генерирующие любые дополнительные заголовочные файлы, необходимые для реализации.

Проект Polyspace с двумя модулями из двух программных компонентов может выглядеть следующим образом:

Имя модуля соответствует полному имени внутреннего поведения компонента программного обеспечения.

Например, имя pkg.tst002.swc001.bhv001 соответствует этой структуре XML (AUTOSAR 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 for AUTOSAR использует тот факт, что необходимая информация уже присутствует в спецификациях ARXML и модулирует код. Подробные сведения о спецификациях ARXML или реализации кода для выполнения анализа не требуются. Вы просто предоставляете папки, содержащие файлы ARXML и исходные файлы.

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

Polyspace обнаруживает несоответствие между кодом и спецификацией AUTOSAR XML

Polyspace for AUTOSAR обнаруживает несоответствие между спецификациями ARXML компонентов программного обеспечения AUTOSAR и их реализацией кода. Несоответствие может произойти во время выполнения между ограничениями данных в ARXML и фактическими значениями аргументов функции в коде. Обнаружение несоответствия происходит только для некоторых функций: функций, реализующих выполняемые и Rte_ функции, используемые в таблицах выполнения. Аргументы этих функций имеют типы данных, указанные в ARXML.

Runnables AUTOSAR обмениваются данными через Rte_ функции.

Реализация выполняемого AUTOSAR использует функции, предоставляемые средой выполнения (RTE) для связи с выполняемыми модулями в других SWC. Например, функция Rte_IWrite_runnable_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)

При развертывании внедрения генератор среды Run-Time использует информацию в спецификациях ARXML для создания файлов заголовков с определениями типов данных для приложения. При разработке внедрения не нужно беспокоиться о деталях связи с другими SWC. Вы просто используете Rte_ функции и типы данных, предоставляемые для внедрения.

Аналогично, типы данных входов, выходов и возвращаемых значений для выполняемой среды также перечислены в ARXML.

Типы данных в ARXML можно ограничить с помощью ограничений данных.

В спецификациях ARXML значения, связанные с типами данных, часто ограничиваются с помощью ограничений данных. Спецификация ограничения данных может выглядеть следующим образом (схема XML AUTOSAR версии 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 ограничения данных происходят из диапазонов сигналов в модели.

Во время выполнения реализация кода может нарушить ограничения данных.

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_ функция, чтобы проверить, находятся ли аргументы в ограниченном диапазоне, а также убедиться, что тесты охватывают все пути выполнения в выполняемом. Кроме того, можно использовать статический анализ, который гарантирует, что все пути выполнения, ведущие к Rte_ рассматривается вызов функции (до определенных обоснованных предположений). Polyspace использует статический анализ, чтобы определить, Rte_ функции находятся в ограниченном диапазоне, определенном в файлах ARXML.

Проверки на наличие несоответствий в анализе Polyspace могут показывать результаты, подобные этому. Здесь второй аргумент в вызове RTE_IWrite_step_out_e4 нарушает ограничения данных в спецификациях ARXML.