本文主要是介绍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的过程步骤和注意事项写在这给大家参考吧。
(以下内容，请关注公众号阅读)
这篇关于AUTOSAR SWC详解的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
