Polyspace Modularizes Analysis Based on AUTOSAR Components

Polyspace for AUTOSAR modularizes your code by reusing the modularization already present in your ARXML specifications. The modularization is based on the software components in the ARXML specifications. Modularizing your code is essential to avoid long analysis times and allow more precise analysis.

A software component consists of one or more runnables. You implement runnables through functions.

A software component (SWC) is the unit of functionality in the application layer of the AUTOSAR architecture. A software component has an internal behavior that consists of data types, events, one or more runnable entities (tasks), and other information.

The AUTOSAR XML lists the internal behavior of a software component like this (AUTOSAR XML schema version 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>

As a developer, you implement the bodies of these runnable entities through handwritten C functions or functions generated from a Simulink^® model.

iOperations_ApplicationError foo(
    Rte_Instance const self,
    app_Array_2_n320to320ConstRef aInput,
    app_Array_2_n320to320Ref aOutput,
    app_Enum001Ref aOut2)
{
  /* Your implementation */
}

Polyspace collects the source code for each software component into a module.

Using the information in the AUTOSAR XML, Polyspace for AUTOSAR creates a project with a separate module for each software component. In a single module, Polyspace collects the source code (.c and .h files) containing the implementation of all runnables in the software component and generates any additional header file required for the implementation.

A Polyspace project with two modules from two software components can look like this:

The module name corresponds to the fully qualified name of the internal behavior of the software component.

For instance, the name pkg.tst002.swc001.bhv001 corresponds to this XML structure (AUTOSAR XML schema version 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>

For this modularization, you simply provide the two folders with ARXML and source files.

Polyspace for AUTOSAR uses the fact that the required information is already present in your ARXML specifications and modularizes your code. You do not need to know the details of the ARXML specifications or code implementation for running the analysis. You simply provide the folders containing your ARXML and source files.

Without this automatic modularization, you have to manually add the implementation of each software component (the files with the entry point functions implementing runnables, the functions called within, and so on) to a module. Not only that, you have to define the interface for each runnable, that is, the range of values for inputs based on their data types.

Polyspace Detects Mismatch Between Code and AUTOSAR XML Spec

Polyspace for AUTOSAR detects mismatch between the ARXML specifications of AUTOSAR software components and their code implementation. The mismatch can occur at run time between data constraints in the ARXML and actual values of function arguments in the code. The mismatch detection occurs for certain functions only: functions implementing the runnables and Rte_ functions used in the runnables. The arguments of these functions have data types specified in the ARXML.

AUTOSAR runnables communicate via Rte_ functions.

The implementation of an AUTOSAR runnable uses functions provided by the run-time environment (RTE) for communication with runnables in other SWCs. For instance, the function Rte_IWrite_runnable_port_variable can be used to provides write access to variable from the current runnable.

Rte_IWrite_step_out_e4(self, e4);

The function arguments have data types specified in the ARXML.

These functions have signatures specified in the AUTOSAR standard with parameter data types that are detailed in ARXML specifications. For instance, the standard defines the signature of the Rte_IWrite_ function like this, where the type of data is specified in the ARXML.

void Rte_IWrite_re_p_o([IN Rte_Instance], IN data)

When deploying your implementation, an Run-Time Environment generator uses the information in the ARXML specifications to create header files with data type definitions for your application. When developing your implementation, you do not have to worry about details of communication with other SWCs. You simply use the Rte_ functions and the data types provided for your implementation.

Likewise, the data types of the inputs, outputs and return value of your runnable are also listed in the ARXML.

You can constrain data types in the ARXML using data constraints.

In your ARXML specifications, you often limit the values associated with data types using data constraints. A data constraint specification can look like this (AUTOSAR XML schema version 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>

When an Rte_ function uses data types that are constrained this way, the expectation is that values passed to the function stay within the constrained range. For instance, for the preceding constraint, if an Rte_IWrite_ function uses a variable of type n320to320, its value must be within [-320, 320].

If you generate the ARXML in Simulink, the data constraints come from signal ranges in the model.

At run time, your code implementation can violate data constraints.

The Rte_ functions represent ports in the SWC interface. So, in effect, when you constrain the data type of an argument in the ARXML, the ports are prepared for data within that range. However, in your code implementation, when you invoke an Rte_ function, you can pass an argument outside a constrained range.

For instance, in this call to 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™ checks for possible data constraint violations.

You can either test each invocation of an Rte_ function to check if the arguments are within the constrained range and also make sure that the tests cover all execution paths in the runnable. Alternatively, you can use static analysis that guarantees that all execution paths leading up to the Rte_ function call are considered (up to certain reasonable assumptions). Polyspace uses static analysis to determine if arguments to Rte_ functions stay within the constrained range defined in the ARXML files.

The checks for mismatch detection in a Polyspace analysis can show results like this. Here, the second argument in the invocation of RTE_IWrite_step_out_e4 violates the data constraints in the ARXML specifications.