VSA - Variable Size Arrays for Autosar Data Types

Autosar allows for the definition of arrays which are flexible in terms of size, with a limit in the maximum number of elements in runtime, in the form of a Variable Size Array (VSA). For this purpose, two different approaches have appeared, old-world and new-world variable-size array data types. These can be defined both at the application data level (via ApplicationDataTypes) or at the implementation data level (via ImplementationDataTypes).

Today, we will focus on the new-world arrays and leave the comparison between the old and the new variations to another post. New-world variable-size arrays require the application to maintain its length element, therefore appearing within the data type that defines it. Some uses for such elements are data transformers, diagnostics and J1939.

Since the VSAs are defined via the category ARRAY, it defines a leaf element that specifies the data type of the array. This is our entry point for creating a VSA. The data type that defines the array is not required to be primitive data types, so one can define multiple dimensions. There are four ways to represent a new-world variable-size array data type in terms of dimensions, by setting a different value in the element dynamicArraySizeProfile:

• VSA_LINEAR – The variable-size array elements are not defined by a variable-size array data type.

• VSA_SQUARE – The variable-size array elements are defined by variable-size array data types characterized by the same number of maximum elements as the englobing array.

• VSA_RECTANGULAR – The variable-size array elements are defined by variable-size array data types with the same number of maximum elements between each other but a different value than the englobing array.

• VSA_FULLY_FLEXIBLE – The variable-size array elements are defined by variable-size array data types with possibly a different number of maximum elements between each other and the englobing array.

Examples of the different dynamicArraySizeProfiles

Modelling these new-world variable-size arrays can become tricky, as restrictions have been applied to keep their modelling straightforward. There are also some considerations when modelling them as ApplicationDataTypes and ImplementationDataTypes. These are outlined below.

VSA Defined as an ApplicationDataType

As for the meta-model, it can be created as an ApplicationDataType by specifying the ApplicationArraDataType.dynamicArraySizeProfile element and aggregating an ApplicationArrayElement which includes the arraySizeHandling (element at least for arrays with multiple dimensions).

The arraySizeHandling specifies how the size is handled when the array has multiple dimensions. This ability is manifested as size indicator, which is part of the ImplementationDataType, and any Software Component that changes the number of elements that are valid at a given point in time must update it.

The size indicator allows for the RTE to handle the array efficiently and the sender to inform the receiver of the current length of the array in use.

On the contrary, the same value is used to keep tabs on the current array length at all times. It also allows for all the parties involved in the communication of such arrays to optimize the process by only performing such operations over the valid elements.

The dynamicArraySizeProfile sets up the internal structure for the underlying ImplementationDataType when a variable length array of multiple dimensions is at hand. This can range from all elements being independent from each other (VSA_FULLY_FLEXIBLE) to each dimension being restricted to the same number of elements (VSA_SQUARE).

Depending on the dynamicArraySizeProfile specified in the ApplicationArrayDataType, the corresponding ApplicationArrayElement must follow a different set of rules. These rules can be observed in the table below:

Multi-dimensional arrays are defined when an ApplicationArrayElement references an ApplicationArrayDataType, creating a nested structure where the number of ApplicationArrayDataTypes (one plus the nested ones) denotes the number of dimensions of the array.

Regarding the type of the ApplicationArrayElement which stems from the inheritance of the meta-class ApplicationCompositeElementDataPrototype, some conditions apply.

For the VSA_LINEAR, it cannot be an ApplicationArrayDataType with a dynamicArraySizeProfile defined, as the leaf elements cannot be variable length arrays. The data type of a leaf element cannot be a variable size array.

As the VSA_SQUARE, it must be an ApplicationArrayDataType that refers to a group of nested ApplicationArrayDataTypes through their reference to the ApplicationArrayElements (except for the last one), denoting the different dimensions. The ApplicationArrayDataTypes referenced must not define the dynamicArraySizeProfile. The ApplicationArrayElements referenced by the ApplicationArrayDataTypes in the chain can be specified as in the table below:

The VSA_RECTANGULAR, it also must be an ApplicationArrayDataType with the same chain concept and restriction over the dynamicArraySizeProfile. The ApplicationArrayElements referenced by the ApplicationArrayDataTypes in the chain are described in the table below:

For the VSA_FULLY_FLEXIBLE, it must be an ApplicationArrayDataType with the same chain concept and not defining a dynamicArraySizeProfile. The ApplicationArrayElements referenced by the ApplicationDataTypes in the chain are specified in the table below:

Mapping of the ApplicationDataType VSA to an ImplementationDataType

Since the goal of ApplicationDataTypes is to separate the application from the implementation, new-world variable-size arrays modelled at the application level require a respective DataTypeMap to the respective ImplementationDataType.

The dimensions relate to the mapped ImplementationDataType via each ImplementationDataTypeElement defined, where each of these relates to each of the ApplicationArrayDataTypes (dimensions) specified in the application data level in their order within the chain.

The ImplementationDataType should be created with a category STRUCTURE and two sub-elements: an integer value that represents the size indicator and an array of the desired baseType for the variable-size array data type (which can be another variable-size array data type, as we have seen before).

VSA Defined as an ImplementationDataType

Variable size arrays can also be modelled as ImplementationDataTypes, independently from ApplicationDataTypes (and the respective DataTypeMappings).

When the array is of multiple dimensions, the handling of the array size is indicated by arraySizeHandling. The internal structure is defined by the dynamicArraySizeProfile, which can take the same values as the ApplicationDataTypes (VSA_LINEAR, VSA_SQUARE, VSA_RECTANGULAR, VSA_FULLY_FLEXIBLE and company-specific strings). These two attributes have the same meaning as their ApplicationDataType counterparts.

The VSAs are defined at the implementation data level through the category STRUCTURE and setting the attribute dynamicArraySizeProfile of a sub-element ImplementationDataType, representing the VSA Size Indicator. Furthermore, there is another ImplementationDataTypeElement which sets the payload of the VSA.

The VSA Size Indicator depends on if the ImplementationDataType that implements the VSA defines the dynamicArraySizeProfile attribute or not. If not, the value must be provided by a respective mapping to an ApplicationArrayDataType, which defines the dynamicArraySizeProfile. The Size Indicator is defined depending on the profile as follows:

• For VSA_LINEAR, VSA_SQUARE and VSA_FULLY_FLEXIBLE profiles, the IntegerDataTypeSubElement should be an integer large enough to accommodate the number of elements defined by the arraySize attribute.

• For the VSA_RECTANGULAR profile, an ImplementationDataTypeSubElement of category ARRAY is defined, where the arraySize holds enough elements for the dimension of the ApplicationArrayDataType or the VSA payload defined on the ImplementationDataType.

The ImplementationDataTypeElement related to the VSA payload is defined the same way, except for the ImplementationDataTypeElement it aggregates, which differs for each dynamicArraySizeProfile of its englobing ImplementationDataType. It must be of category ARRAY, and not define the arraySizeSemantics, arraySize and arraySizeHandling.

For the VSA_LINEAR profile, the ImplementationDataTypeElement aggregated by the VSA payload ImplementationDataTypeElement must set arraySizeSemantics to variableSize, define an arraySize (larger than zero) and set arraySizeHandling to allIndicesSameArraySize.

For the other standardized profiles, a chain of ImplementationDataElements is defined, one for each dimension. The last element in the chain if the same for these profiles, where the arraySizeSemantics is set to variableSize, the arraySize is defined (and larger than zero) and the arraySizeHandling is set to allIndicesSameArraySize.

The elements that precede it are defined according to the table below, where the VSA_FULLY_FLEXIBLE profile specifies a pair of ImplementationDataTypeElements (except for the last one, which is defined the same way as the other two profiles):

None of the ImplementationDataTypeElements that are not the last in the chain can set the category TYPE_REFERENCE.

Closing Notes

So, this is how the VSAs are created, both as ApplicationDataTypes and ImplementationDataTypes. This is also a small glimpse of what you can expect from the first ebook, as this (and other data types) will be provided with examples and exercises. Do not forget to get yourself on the waiting list!

Author: Micael Coutinho (opens in a new tab)

References:

• Software Component Template - Autosar Specification (opens in a new tab)