Autosar4.4：软件组件模板-软件组件、端口和接口简介（2/3）
一口气对软件组件模板的各个方面进行详细介绍被认为过于复杂。因此，本章概述了软件组件，端口和接口的主要概念。然后在以后将概述细分为更多详细信息。
AUTOSAR概念的目标之一是在应用程序软件级别上支持可重用性。
换句话说：应该有可能重新使用现有的工件来创建更多的模型元素，而不是*从头开始创建每个单独的模型细节。这种方法的后果之一是应用了所谓的类型原型模式（见Generic Structure Template）。
除其他事项外，该概念允许创建具有任意复杂度的软件组件的分层结构。但是，层次结构的创建本身不会对整个系统的运行时行为产生影响。实际行为是在各个软件组件中完全定义的。
该结论基于以下理解：软件组件是针对所谓的虚拟功能总线（VFB）开发的，虚拟功能总线是一种抽象的通信通道，而无需直接依赖ECU和通信总线。 VFB不提供任何表达软件组件层次结构的方法。
当然，VFB的使用会对软件组件的设计产生进一步的影响，这些组件不应直接调用操作系统或通信硬件。结果，可以在开发过程的后期将软件组件部署到实际的ECU。
为了使描述更加精确，以下文本优选使用准确的元模型术语，而不是模糊的术语“组合”和“软件组件”。
本章有三节：
1、Software Component（软件组件）
2、Composition（组合）
3、Port Interface（端口接口）
本章分三部分讲解：
2、Composition（组合）
组合
CompositionSwComponentType
AUTOSAR CompositionSwComponentType的目的是通过聚合现有的软件组件来实现特定功能的封装。
CompositionSwComponentTypes的嵌套定义
由于CompositionSwComponentType也是SwComponentType，因此可以再次将其聚合到其他CompositionSwComponentTypes中。
重要的是要理解，尽管组合允许（子）系统抽象，但它们仅是用于实现模型可伸缩性的体系结构元素。 他们只是对现有软件组件进行分组，从而消除了查看或设计逻辑软件体系结构时的复杂性。
因此，CompositionSwComponentTypes的定义对软件组件与虚拟功能总线（VFB）的交互方式没有影响。
CompositionSwComponentTypes不会向它们聚合的软件组件已经提供的功能添加任何新功能。
CompositionSwComponentTypes没有任何二进制尺寸
作为主要结果，CompositionSwComponentTypes在ECU软件中没有任何二进制代码。
SwComponentPrototype
CompositionSwComponentType聚合SwComponentPrototypes
在AUTOSAR元模型方面，由元类CompositionSwComponentType实现的软件组件的组合聚合了SwComponentPrototype，而这些SwComponentPrototypes又由SwComponentType键入。
SwComponentPrototype实现特定角色
因此，SwComponentPrototype以特定角色实现SwComponentType的用法。
可以创建任意数量的SwComponentPrototypes
通常，可以创建引用特定SwComponentType的任意数量的SwComponentPrototype。
示例：SwComponentPrototype“ LeftDoorControl”履行为车辆左门实施SwComponentType“ DoorControl”的作用，而SwComponentPrototype“ RightDoorControl”履行对右车门的SwComponentType“ DoorControl”的作用。
委托端口
请注意，CompositionSwComponentType是SwComponentType，它也将PortPrototypes暴露给外界。但是，仅委派了PortPrototypes，并且与附加到AtomicSwComponentTypes的PortPrototypes角色不同。
成为委派端口的含义
附加到CompositionSwComponentType的PortPrototype具有以下含义：
•代表团必须遵守基本兼容性的规则。
•通过在特定的CompositionSwComponentType的表面上创建PortPrototypes，可以明确决定是否将CompositionSwComponentType中包含的“内部”端口的内容暴露给外界。
请进一步注意，PortPrototypes委托的语义与面向对象的编程语言中的封装机制（如公共和私有成员）相似。
CompositionSwComponentType概念的一个含义是，整个车辆的应用软件最终都由一个CompositionSwComponentType表示。这种所谓的*组合在AUTOSAR系统模板的背景下具有特殊作用。
但是，请注意，顶层组合可能具有（未连接的）PortPrototype，以便允许作为另一个系统的一部分进行重用。
CompositionSwComponentType的递归定义最终包含由相同CompositionSwComponentType键入的SwComponentPrototype的CompositionSwComponentType的递归定义将不可行。
连接器
SwConnector
请注意，CompositionSwComponentType还聚合了抽象的元类SwConnector，以相互连接所包含的SwComponentPrototype。
CompositionSwComponentTypes包含两种SwConnector：
• AssemblySwConnector
AssemblySwConnector互连作为CompositionSwComponentType一部分的SwComponentPrototypes的PortPrototype。
• 委托SwConnector
委托SwConnector从“内部” PortPrototypes连接到委托的“外部” PortPrototypes。
多个委托SwConnector引用了外部PortPrototype
如果一个外部PortPrototype被多个DelegationSwConnector引用，则语义是引用该外部PortPrototypes的AssemblySwConnectors的乘法。
两个特定PortPrototypes之间的SwConnector
每对PortPrototypes只能通过一个且仅一个SwConnector连接。
换句话说，不支持创建两个不同的SwConnector来连接同一对PortPrototype。
两个PRPortPrototypes之间存在SwConnector
上一条“两个特定PortPrototypes之间的SwConnector”也适用于两个PRPortPrototypes相互连接的情况。尤其是角色
• AssemblySwConnector.requester
• AssemblySwConnector.provider
• PassThroughSwConnector.providedOuterPort
• 在这种情况下，PassThroughSwConnector.requiredOuterPort不建立方向。
为了澄清起见，上述表示SwConnector表示两个PRPortPrototypes之间的双向通信能力。
CompositionSwComponentType内部的AssemblySwConnector
AssemblySwConnector只能连接由相同CompositionSwComponentType拥有的SwComponentPrototypes的PortPrototypes
CompositionSwComponentType内部的委托SwConnector
一个委托SwConnector只能连接一个SwComponentPrototype的PortPrototype，该SwComponentPrototype由相同的CompositionSwComponentType拥有，后者也拥有连接的委托PortPrototype。
在将一个MemberSwConnector附加到内部PRPortPrototype的上下文中，需要考虑一些歧义。特别地，从形式上来看，使用PPortInCompositionInstanceRef或RPortInCompositionInstanceRef是可行的。
任意使用一个或另一个元类的能力被认为是令人困惑的。 因此，下一条描述以消除不必要的*度。
PPortInCompositionInstanceRef将用于将委托SwConnector附加到内部PRPortPrototype
为了实现委派SwConnector对内部PRPortPrototype的附件的实现，应使用元类PPortInCompositionInstanceRef。
由DataInterface键入的未连接的RPortPrototype
对于由DataInterface键入的未连接RPortPrototype中的任何元素，必须有一个必要的ComSpec来定义一个initValue。
下图说明了SwConnectors应用的一种特定用例。 特定的CompositionSwComponentType存在两个变体中，其中一个（较复杂）变体预见到CompositionSwComponentType内部存在SwComponentPrototype，而另一个（因为它实现了更简单的语义）不需要SwComponentPrototype。
如果没有定义PassThroughSwConnector的能力，则只能通过在CompositionSwComponentType内部定义一个虚拟SwComponentPrototype来实现第二个变体。 但是，虚拟SwComponentPrototype将需要定义RunnableEntity，其创建的唯一目的是能够将数据从RPortPrototypes（例如，用于发送方-接收方通信）转换为PPortPrototypes。
这不仅麻烦，而且在运行时显然还需要其他资源（内存和代码）。 另外，附加的RunnableEntitys的存在也不必要地增加了在ECU内部流动的信息的传播延迟。
PassThroughSwConnector的作用
可以采用PassThroughSwConnector连接相同的CompositionSwComponentType拥有的PortPrototype。换句话说，PassThroughSwConnector在CompositionSwComponentType内部创建从“ requiredOuterPort”到“providedOuterPort”的旁路（反之亦然），而不涉及SwComponentPrototypes。
不允许创建涉及PassThroughSwConnector的循环
如果所需的外部PortPrototype直接或间接连接到提供的外部PortPrototype，而没有在SwConnectors链中放置由AtomicSwComponentType键入的SwComponentPrototype，则不允许PassThroughSwConnector。
换句话说，根据上述，不允许通过PassThroughSwConnector和至少一个AssemblySwConnector将requiredOuterPort连接到 providedOuterPort 来创建 “infinite loop(无限循环)” 。
特定于实例 RTEEvents
通过在角色InstantiationRTEEventProps中应用InstantiationRTEEventProps，可以指定RTEEvent的特定于实例化的属性。这允许在不同的时序方案中使用相同的ApplicationSwComponentType。 即使调度是SwcInternalBehavior的问题，也需要在CompositionSwComponentType级别上指定特定于实例的时序定义。
作为本条描述的示例，请考虑实现闭环控制算法的软件组件。
该软件组件可能会部署到“慢速”和“快速”控制方案中。 由于控制算法的实际时基是从RTE中实现的调度中得出的，因此，如果可以在“实例”级别上定义时序，则显然可以简化总体设计。
InstantiationTimingEventProps应该仅引用TimingEvent
InstantiationTimingEventProps应该仅在角色finefinedEvent中引用TimingEvent。 不支持对其他类型的RTEEvent的引用。