为了对相关的元模型元素进行简洁的描述,本章集中讨论和解释了概念方面的内容。
阅读本章并不是理解后面章节的先决条件。
它只是为本文档其他各章中使用的概念方面的详细描述提供了一个中心位置。
基础概念分8节:
1、测量和校准
2、运行时和数据一致性方面
3、软件组件模板中的变量处理
4、组成组件类型的通信规范
5、PRPortPrototype
6、假装联网
7、可变大小的数组数据类型
8、结构中的可选元素
基础概念分四部分讲述,本章讲述:
7、可变大小的数组数据类型
8、结构中的可选元素
AUTOSAR支持定义数组数据类型,其中实际有效负载的大小在运行时会有所不同。就配置而言,可以指定运行时不得超过的最大数组元素数。
为了正确理解该方法,有必要了解对可变大小数组数据类型的支持是在两次浪潮中引入的,每一次浪潮都有不同的动机。
在第一波中,对可变大小数组数据类型的支持仅限于基本上可以归结为基本类型是长度为一个字节的无符号整数数据类型的数组。
此方案的主要用例来自诊断要求以及对J1939通信协议的支持。
在这两种情况下,都可以根据上下文确定可变大小数组数据类型的实际长度,即通过诊断基本软件模块或通过J1939 TP的实现来确定。
由于缺乏更好的术语,本规范区分了“旧世界”动态大小数组和“新世界”可变大小数组数据类型。有必要明确定义可以消除“旧世界”动态大小数组和“新世界”可变大小数组数据类型之间歧义的特征。
通过ApplicationArrayDataType定义“旧世界”动态大小的数组数据类型
未定义属性dynamicArraySizeProfile并在存在属性arraySizeSemantics并将其设置为variableSize值的位置聚合ApplicationArrayElement的ApplicationArrayDataType应被视为“旧世界”动态尺寸数组数据类型。
在某些情况下,必须在没有相应的ImplementationDataType的情况下区分“旧世界”动态大小数组和“新世界”可变大小数组数据类型。
通常,如果相应的ImplementationDataType的定义可用,则消除歧义变得多面(但不一定会更容易)。
通过以下方式定义“旧世界”动态大小数组数据类型
ImplementationDataType的方式
(在解析所有类型引用之后)满足以下所有条件的ImplementationDataType应被视为“旧世界”动态大小数组数据类型:
• 属性类别的值设置为ARRAY
• ImplementationDataType没有定义属性dynamicArraySizeProfile
• ImplementationDataType聚集一个subElement,其中
–存在属性arraySizeSemantics,并将其设置为值variableSize
–属性arraySizeHandling不存在
• ImplementationDataType.swDataDefProps.baseType存在并且属性
– baseTypeEncoding存在并将其设置为值NONE
– baseTypeSize存在并且设置为值8
总的来说,“旧世界”动态大小数组的定义特征是缺少属性ApplicationArrayDataType.dynamicArraySizeProfile或ImplementationDataType.dynamicArraySizeProfile的定义。
根据规定,不支持“旧世界”动态大小的数组通过数据转换器进行传输。可以使用数据转换器传输的唯一受支持的VariableSize Array数据类型是“新世界”可变大小数组。
与此相反,第二次支持可变大小数组数据类型的浪潮是由应用程序软件层本身推动的。
在这里,情况完全不同,因为实际大小无法由任何上下文软件模块确定。应用程序本身负责在运行时维护可变大小数组数据类型的正确长度。
因此,运行时实际数组大小的规范需要通过用于承载“可变大小数组数据类型”的数据类型的结构来反映。
通过ApplicationArrayDataType定义“新世界”可变大小数组数据类型
满足以下所有条件的ApplicationArrayDataType应被视为“新世界”动态大小数组数据类型。
•ApplicationArrayDataType定义属性ApplicationArrayDataType.dynamicArraySizeProfile。
•ApplicationArrayDataType聚合定义属性ApplicationArrayElement.arraySizeHandling的ApplicationArrayElement。
通过ImplementationDataType定义“新世界”可变大小数组数据类型
满足以下所有条件的ImplementationDataType应被视为“新世界”动态大小数组数据类型。
•ImplementationDataType定义属性ImplementationDataType.dynamicArraySizeProfile。
•ImplementationDataType聚集定义定义属性ImplementationDataTypeElement.arraySizeHandling的ImplementationDataTypeElement。
与上述第一种使用情况相反,不能根据数组数据类型的基本类型来限制应用程序驱动的VariableSize数组数据类型,即,将基础数据类型限制为长度为正好为零的无符号整数数据类型。一个字节不是一个选择。
最重要的是,需要可变大小数组数据类型的几种可能的结构。此方面在下图中进行了描述。
用于定义可变大小数组数据类型的配置文件的定义
可变大小数组数据类型的可能变体是:
线性可变大小数组数据类型本身的元素的数据类型不包含可变大小数组数据类型。
这种情况对应于属性dynamicArraySizeProfile的可能值VSA_LINEAR。
正方形可变大小数组数据类型本身的元素的数据类型由可变大小数组数据类型组成,其中所有“第二阶”数组中的最大元素数与“第一阶”数组中的最大元素数相同”数组。
这种情况对应于属性dynamicArraySizeProfile的可能值VSA_SQUARE。
矩形可变大小数组数据类型本身的元素的数据类型由可变大小数组数据类型的数据类型组成,其中“第二阶”数组中元素的最大数量相同,但该值通常不等于最大值“一阶”数组中的元素数。
这种情况对应于属性dynamicArraySizeProfile的可能值VSA_RECTANGULAR。
完全灵活可变大小数组数据类型本身的元素的数据类型由可变大小数组数据类型组成,其中“二阶”数组中元素的最大数量不一定彼此相同,(显然)不一定等于“一阶”数组中元素的最大数量。
这种情况对应于dynamicArraySizeProfile属性的可能值VSA_FULLY_FLEXIBLE。
所描述的情况直接对应于下图中不同类型的变量化数组的描述:
•值VSA_LINEAR对应于标签(a)。
•值VSA_SQUARE对应于标签(b)。
•值VSA_RECTANGULAR对应于标签 (c)。
•值VSA_FULLY_FLEXIBLE对应于标签(d)。
大小可变的数组数据类型的结构多样性
请注意,可变大小数组数据类型中的叶子元素不必是原始数据类型。如前所述,可以定义多维可变大小数组数据类型。
可以这样识别“终端”元素,因为它们不再建立更多的可变大小数组数据类型。
请进一步注意,可变大小数组数据类型的建模是一个复杂的步骤,受一系列规则和约束的支配。
该规范的明确意图是使规则集的复杂度尽可能低,同时仍为用户提供强大的建模框架。
该结论的主要结果是使建模尽可能简单。换句话说:故意删除某些建模变体,对于这些变体,建模框架本身内存在可接受的解决方法。
这种限制的一个具体示例是,对于ImplementationDataTypes,只能在AutosarDataType级别上定义可变大小数组数据类型。
有意不支持在ImplementationDataTypeElement级别上定义可变大小数组数据类型,因为可以通过将TYPE_REFERENCE值分配给ImplementationDataTypeElement.category来实现预期的语义,然后让它引用另一个实现该实现的语义。可变大小数组数据类型。
另一方面,用于实际托管VariableSize Array数据类型的数据类型直接对应于ImplementationDataType的级别。
在这里,可以定义如何使用ImplementationDataType来定义可变大小数组数据类型。
AUTOSAR元模型中的ImplementationDataType定义具有一定的通用性,在此级别上对可变大小数组数据类型的支持来自元模型中专用属性的混合以及如何支持的一组配方可变大小数组数据类型的不同用例。
这意味着,如果在不同的AUTOSAR软件实现中复制了这些数据类型的结构,则仅出于创建可变大小数组数据类型的目的而定义ImplementationDataTypes的机会就大了。
因此,AUTOSAR定义了一种通用方式,该方式应如何定义实现数据类型以创建可变大小数组数据类型,以使实现数据类型为STRUCTURE类别,并具有以下子元素:
1.确定实际尺寸的数值。在整个文档中,此元素应称为“大小指示器”。
2.可变大小数组数据类型的基本类型的数组,用于实现可变大小数组数据类型的有效负载。数组的尺寸应定义为适合元素的最大预期数量。
可变大小数组数据类型的大小指示符可保存数组的有效元素数。该信息对于RTE有效地处理阵列是必需的。
在发送方,该指示符由软件组件主动更新,这是唯一知道数组中有多少个元素有效的实例。
因此,应用程序必须使有效元素的数量和大小指示器保持一致。当软件组件通过RTE发送数据时,RTE会将数据移交给变压器。
转换器可以评估大小指示器(取决于转换器),并且只能在有效的数组元素上工作。变压器的输出长度可以变化,仅包含必要的数据。因此可以节省更多资源。
在接收方,执行顺序中的最后一个转换器将还原数组的数据元素和“大小指示器”的值。该输出由RTE移交给软件组件。现在,应用程序知道数组中有效元素的数量。
AUTOSAR经典平台支持在SOME / IP传输层上使用TLV4数据编码。 TLV通常用于仅部分可选地存在至少一部分传输数据并用有意义的值填充的情况。
换句话说:在一个数据传输实例中,数据结构的可选部分可能存在并带有有意义的值,而在另一数据传输实例中则完全丢失。
接收软件需要能够识别可选部分是否存在并相应地读取其值。
如果这种数据结构的可选部分在特定的通信实例中不存在,则接收软件还需要能够以有意义的方式执行。
因此,有必要能够精确地识别数据结构的某些部分,这些部分对于特定的数据传输实例可能是可选的。
就AUTOSAR元模型而言,标识原则上可以附加到各个抽象级别:
AutosarDataType在这种情况下,仅出于通信目的所需的可选性在所有其他数据类型的用法中仍然存在。这似乎是不平衡的。
诚然,对于同一数据类型的不同可选配置的定义可能会导致存在一堆结构相同的数据类型,这些数据类型仅在可选性方面有所不同。但是,变化点的存在可能有助于减轻这种影响。
PortInterface在这种情况下,在实际需要的地方定义了可选性。
但是,原则上可以为由同一AutosarDataType键入的DataPrototypes定义不同的可选性。
这将导致在相同PortInterface上下文中为定义C数据类型付出更多的努力。
在AUTOSAR经典平台的RTE API定义的上下文中已经确定了其他约束,这些约束最终使该选项不可行。
ComSpec在这种情况下(有关更多信息,请参阅第4.5节),与PortInterfaces级别上的可选性定义相比,可选性的定义甚至更加具体。
最重要的是,在大多数情况下定义可选性的任务是由OEM完成的,而ComSpec级别的模型定义要求存在SwComponentTypes,并且在许多情况下,此定义在供应商的范围内。
由于这种考虑,AUTOSAR选择了在AutosarDataType级别上定义定义可选性的概念的实现。