AUTOSAR SWC详解

温馨提示：关注公众号“嵌入式软件实战派”回复“AUTOSAR”获得整个AUTOSAR实战教程。

1. SWC原理特点

只要了解过AUTOSAR的都知道，AUTOSAR分四层：Application、RTE、BSW和MCAL。

而SWC一般位于AUTOSAR架构的Application层（不完全是，但可以暂且这么认为，看完以下内容就会大概理解了）。

SWC即Software Component缩写。

也许有很多人会疑惑，到底什么是SWC，里面包含什么？

对于这个问题，首先要了解下什么是Component。

Component这个概念很广泛，有时候概念会模糊或者容易混淆。例如Module和Component的概念混淆。

这里先从UML规范角度来看看。

OMG UML 规范（UML Superstructure Specification, v2.1.1, p.148）指出：

Component表示系统的模块化部分，它封装了其内容，并且其表现形式在其环境中是可替换的。

Component根据提供的和所需的接口定义其行为。 因此，Component作为一种类型，其一致性由这些提供和必需的接口定义（包括它们的静态和动态语义）。

一个Component可以由多个类或组件拼凑而成。随着较小的Component组合在一起以创建更大的组件，最终系统可以在Component图中以构建块样式进行建模。

回到AUTOSAR上来，AUTOSAR上的Component有以下特点和属性

在DavinciDeveloper上面，可以看到Component有好几类。

至少在其Object Browser界面上可以看到有Application ComponentTypes和Service component Types

而ApplicationComponent Types里面又分Application、SensorActuator……

下面我做了个汇总：

以上这个图是根据Davinci Developer的配置情况做的分类。

其实，AUTOSAR官方的Component的模型关系，也许会让你更清晰其结构关系，如下

下面参考官方文档里面的解释，做个Component的名词解释汇总：

Component	Description
AtomicSwComponentType	An atomic software  component is atomic in the sense that it cannot be further decomposed and  distributed across multiple ECUs.
ParameterSwComponentType	The  ParameterSwComponentType defines parameters and characteristic values  accessible via provided Ports. The provided values are the same for all  connected SwComponentPrototypes
CompositionSwComponentType	A  CompositionSwComponentType aggregates SwComponentPrototypes (that in turn are  typed by SwComponentTypes) as well as SwConnectors for primarily connecting  SwComponentPrototypes among each others and towards the surface of the  CompositionSwComponentType. By this means hierarchical structures of software-components  can be created.
ApplicationSwComponentType	The  ApplicationSwComponentType is used to represent the application software.
NvBlockSwComponentType	The  NvBlockSwComponentType defines non volatile data which data can be shared between  SwComponentPrototypes. The non volatile data of the NvBlockSwComponentType  are accessible via provided and required ports.
ComplexDeviceDriverSwComponentType	The  ComplexDeviceDriverSwComponentType is a special AtomicSwComponentType that  has direct access to hardware on an ECU and which is therefore linked to a  specific ECU or specific hardware. The ComplexDeviceDriverSwComponentType  introduces the possibility to link from the software representation to its  hardware description provided by the ECU Resource Template.
ServiceSwComponentType	ServiceSwComponentType  is used for configuring services for a given ECU. Instances of this class are  only to be created in ECU Configuration phase for the specific purpose of the  service configuration.
EcuAbstractionSwComponentType	The ECUAbstraction  is a special AtomicSwComponentType that resides between a software-component  that wants to access ECU periphery and the Microcontroller Abstraction. The  EcuAbstractionSwComponentType introduces the possibility to link from the  software representation to its hardware description provided by the ECU  Resource Template.
SensorActuatorSwComponentType	The  SensorActuatorSwComponentType introduces the possibility to link from the  software representation of a sensor/actuator to its hardware description  provided by the ECU Resource Template.
ServiceProxySwComponentType	This class provides the ability to express a software-component which  provides access to an internal service for remote ECUs. It acts as a proxy  for the service providing access to the service. An important use case is the request of vehicle mode switches: Such  requests can be communicated via sender-receiver interfaces across ECU  boundaries, but the mode manager being responsible to perform the mode  switches is an AUTOSAR Service which is located in the Basic Software and is  not visible in the VFB view. To handle this situation, a  ServiceProxySwComponentType will act as proxy for the mode manager. It will  have R-Ports to be connected with the mode requestors on VFB level and  Service-Ports to be connected with the local mode manager at ECU integration  time. Apart from the semantics, a ServiceProxySwComponentType has these  specific properties: * A prototype of it can be mapped to more than one ECUs in the system  description. * Exactly one additional instance of it will be created in the  ECU-Extract per ECU to which the prototype has been mapped. * For remote communication, it can have only R-Ports with  sender-receiver interfaces and 1:n semantics. * There shall be no connectors between two prototypes of any  ServiceProxySwComponentType.

如果不想看这些英文描述，可以直接看下面这个简化版的（适合初学了解）

SWC	描述/用途
Parameter  SWC/Calibration	此SWC用于将（其所在的ECU）的Calibration参数共享给外部设备。与Application SWC或SensorActuator SWC不同，这些SWC没有任何内部行为。
Composition SWC	这个SWC是在系统配置期间单一ECU里面的SWC的集合。这种SWC有助于抽象和标准化AUTOSAR目标的软件开发。
Atomic SWC	这个是相对Composition SWC而言的，是单个不再拆解的SWC，也算是个抽象的概念。
Application SWC	一般只包含应用程序的SWC
SensorActuator SWC	专门处理和sensor/actuator相关的SWC
Nvblock SWC	这种SWC是用于访问NVRAM或Memory的
Complex Device Driver  SWC	用于开发CDD(Complex Device  Driver)或者AUTOSAR标准不支持或未定义的一些组件
ECU Abstraction SWC	这类SWC通过直接与特定的 BSW 模块交互来提供对 I/O 的访问。严格来说其他 SWC 不能用于访问 I/O，只能使用这个。
Service SWC	这类SWC为BSW模块提供AUTOSAR指定的服务。
Service Proxy SWC	这种SWC充当代理，为一个或多个remote ECU提供内部服务。它的主要用途是在整个系统中分发车辆的模式信息。可以简单理解为跨ECU用的。

以上不同类型的Component type的实际应用场景，后续根据具体情况再做详细解释或使用指导。

2. SWC配置实践

通过上面的解释，我相信你对SWC大概的内容应该有个大致的了解了，那么，这些SWC在AUTOSAR实际开发中应该怎么配置呢？

对初学者，这个会让人不知从何下手，有个详细的教程步骤会让你少走很多弯路。

下面将配置几个SWC的过程步骤和注意事项写在这给大家参考吧。
(以下内容，请关注公众号阅读)