Autosar4.4：软件组件模板 - 端口接口细节（2/2）

虚拟功能总线（VFB）的规范解释了软件组件之间通信的主要通信范例：用于基于操作的通信的客户端/服务器，以及用于基于数据的通信的发送器/接收器。
两种通信范式的性质完全不同，SenderReceiverInterfaces和ClientServerInterfaces及其相关元类的建模也是如此。
PortInterface描述了信息交换的静态结构
PortInterfaces仅限于对交换信息的静态结构的描述；与通信相关的动态属性附加到PortPrototypes。

本章共有6小节

1、前言

2、发送/接收者通信

3、客户/服务通信

4、外部触发事件通信

5、通信模式

6、参数通信

本章分为两部分：

4、外部触发事件通信

5、通信模式

6、参数通信

 

4、外部触发事件通讯

外部触发事件通信的语义

外部触发事件通信的基本语义是触发源可以在连接的触发接收器中启动RunnableEntitys的执行。 通常（但不是必须），这些RunnableEntity按顺序执行。

触发器接口

TriggerInterface定义了一组在软件组件之间通信的触发器。 触发器代表一种特殊的事件，在这种情况下，触发器接收器将在
特殊的方式。

触发器接口与触发器

 

定期触发的时间段

触发器可以选择定义一个周期触发周期。 它通过元类MultiDimensionTime以时间或角度表示。 请注意，此操作的主要用例是在触发器来自基本软件（例如 从复杂驱动程序中获取，它不用作RTE生成器的输入。

除此之外，TriggerInterface不定义任何时序信息（例如，源期望接收器反应的速度）。 这是模板中时序信息的属性。

触发接收器和触发源

多个SwConnector不应引用由TriggerInterface类型的RPortPrototype，而SwConnector依次引用由包含具有相同shortName触发器的TriggerInterfaces类型的PPortPrototype。

归结为在n：1场景中不得实施触发通信的要求。

需要明确的是，触发器通信不支持n：1方案，因为它没有活动的用例。 支持将需要实现触发器通信的队列管理。

触发器的排队处理

可能至少在某种程度上触发源触发触发器的速度快于在触发接收器侧面进行处理的速度。 为了支持该用例，可以以排队方式处理触发事件通信。

在这种情况下，将触发器添加到队列中，在完成当前触发器的处理后，将从最前面的触发器中取出队列并对其进行处理。 请注意，队列大小不受本文档范围内的定义的限制。 实际队列大小是在RTE配置过程中定义的。

是否对触发器进行排队处理的规范由属性Trigger.swImplPolicy控制。

Trigger.swImplPolicy的允许值

属性Trigger.swImplPolicy的唯一允许值是STANDARD（在这种情况下，Trigger处理不使用队列）或QUEUED（在这种情况下，Triggers的处理肯定使用队列）。

请注意，Trigger.swImplPolicy的值不是针对特定触发器的队列实现的最后一句话。 集成商仍然有权否决应用软件开发人员的判决（如果适用）。

5、通信模式

通过端口进行模式通信有两种独特的用例：

1.实际的模式转换可以从模式管理器组件传递到其客户端组件，以实施模式切换。

2.模式转换的请求可以从任何组件传递到模式管理器。

模式信息的传播

为了传达模式切换（即第一个用例），软件组件模板描述了ModeDeclarationGroupPrototypes的通信概念，类似于VariableDataPrototypes的通信，但是使用了特殊类型的PortInterface：需要或提供的ModeDeclaration的集合 通过SwComponentType定义的ModeSwitchInterfaces用于键入SwComponentType拥有的PortPrototypes。

由于与RTE进行了强大的交互以处理模式切换，因此第一个用例不允许跨ECU边界进行通信：

本地通讯下的模式切换

具有ModeSwitchInterfaces的端口不能跨ECU边界连接。

不同的ModeDeclarationGroups应具有不同的简称

不允许软件组件使用ModeSwitchInterfaces键入多个PortPrototype，其中包含的ModeDeclarationGroupPrototypes引用具有相同shortNames但具有不同ModeDeclaration的ModeDeclarationGroups。

显然，上述的基本原理是避免在生成的RTE文件中发生冲突。

例如：

定义了两个具有相同的短名称“ Foo”的ModeDeclarationGroups。

ModeDeclarationGroup“ Foo”

包含模式声明“ X”，“ Y”，“ Z”

ModeDeclarationGroup“ Foo *”

包含模式声明“ W”，“ X”，“ Y”，“ Z”

在这种情况下，仅允许软件组件使用“ Foo”或“ Foo *”

ModeDeclarationGroupPrototype的SwCalibrationAccessEnum允许值

由ModeDeclarationGroupPrototype聚合的swCalibrationAccess唯一允许的值是notAccessible和readOnly。

在FlatInstanceDescriptor上下文中为MCD系统定义文字

 如果将ModeDeclarationGroupPrototype.swCalibrationAccess设置为readOnly，则引用的FlatInstanceDescriptor.swDataDefProps可以依次引用定义特定文字的CompuMethod。

在MCD系统中用于显示测得的ModeDeclarationGroupPrototypes的值。

该用例的存在是将“ AI”放置在compuMethod和FlatInstanceDescriptor的交集上的原因。

另一个可能的情况（不一定必须与ModeDeclarationGroupPrototypes相关，而通常与MCD系统的文字定义有关）是FlatInstanceDescriptor不存在（例如，因为受影响的数据存在于基本软件中），但仍然存在具有定义用于在MCD系统中显示值的特定文字的能力将是很好的。

每个ModeSwitchInterface的ModeDeclarationGroupPrototype

实际将ModeDeclarationGroupPrototype聚合到ModeSwitchInterface的多重性限制为1。

诚然，支持 [0 .. *] 多重性没有技术上的限制，但另一方面，对于这种情况，似乎没有任何合理的用例存在。

如果以某种方式SwComponentType必须考虑两个或更多个ModeDeclarationGroupPrototype，则很可能这些将成为不同ModeSwitchInterfaces的一部分。

通过在ModeSwitchInterface中包含ModeDeclarationGroupPrototype，可以显式定义在SwComponentPrototype之间进行通信的SwConnector，并可以定义用于与ServiceSwComponentTypes通信的服务接口。 由于PortInterfaces的兼容性规则（请参阅第6章），每个SwComponentType都可以依赖于所需模式激活的可用性。

模式切换接口

请注意，每个SwComponentType都可以（通过其PortPrototypes和ModeSwitchInterfaces）定义所需和提供的ModeDeclarationGroupPrototypes的列表。

CompositionSwComponentType需要并提供其包含的SwComponentPrototypes所需或提供的模式

最终，CompositionSwComponentType需要并提供其包含的SwComponentPrototypes所需或提供的模式。 这些模式从SwComponentPrototypes到封闭的CompositionSwComponentType的委派由MemberSwConnectors明确描述。

软件组件的形式描述不对所需和提供的ModeDeclarationGroupPrototypes的语义进行任何假设。

它仅需要并按名称提供ModeDeclarationGroupPrototypes。 

要求模式变更

通过SenderReceiverInterface在VFB上对请求模式（即第二种用例）的能力进行了建模，对于RTE，这就像通常的通信一样，这意味着连接器也可以跨越ECU边界，并且所传递的dataElements必须基于 AutosarDataTypes。

但是，为了与第一个用例保持语义一致性，还应将通信模式请求映射到相应的ModeDeclarationGroup。 这可以通过映射类定义，如下图。

然后可以在PortInterface中使用映射到某个ModeDeclarationGroup的ImplementationDataType来将关联的ModeDeclarationGroup的ModeDeclaration表示为数值：

模式到数据类型的明确映射

在一个DataTypeMappingSet中，ModeDeclarationGroup不应映射到不同的ImplementationDataTypes。

模式和数据的映射方式

ModeRequestTypeMap的限制

对于由ModeSwitchInterface键入的PortPrototype中使用的ModeDeclarationGroupPrototype引用的每个ModeDeclarationGroup，必须存在一个ModeRequestTypeMap，它指向ModeDeclarationGroup以及合格的ImplementationDataType。

ModeRequestTypeMap应由DataTypeMappingSet聚合，该数据类型是从同时拥有PortPrototype的ApplicationSwComponentType拥有的SwcInternalBehavior中引用的。

模式声明映射

用作ModeRequestTypeMap.implementationDataType的ImplementationDataTypes

ModeRequestTypeMap引用的ImplementationDataType应该是VALUE类别，或者是TYPE_REFERENCE类别，后者又引用了VALUE类别的ImplementationDataType。

ImplementationDataType引用的baseType必须已将BaseTypeDirectDefinition.baseTypeEncoding属性的值设置为NONE。

 ApplicationDataType定义ModeDeclarationGroup中使用的值的子集

请注意，相应的ApplicationDataType定义了ModeDeclarationGroup中使用的值的子集，并且所使用的标签可能与ModeDeclarations中使用的名称不同。

系统设计者有责任根据功能需要维护数据类型和ModeDeclarationGroups。

例如，一个ModeRequester可能只请求可用模式的子集（通过SenderReceiverInterface或ClientServerInterface）。 ModeManager可以另外决定指示失败。
 

6、参数通讯

当然，作为ParameterInterface一部分的ParameterDataPrototypes的“通信”并不能建立实际的数据传输。

该术语在概念上使用； 像ParameterInterface之类的东西的存在是通过将校准参数在软件组件的表面上以与其他数据的公开相同的正式级别统一的单纯思想来证明的，即通过键入的PortPrototype 通过PortInterface。

由ParameterInterface键入的PortPrototypes

由ParameterInterface键入的PortPrototypes可以是PPortPrototypes或RPortPrototypes。 不支持使用由ParameterInterface键入的PRPortPrototypes。