AUTOSAR SWC详解

Posted 嵌入式软件实战派

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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详解的主要内容,如果未能解决你的问题,请参考以下文章

详解AUTOSAR:SWC软件组件(理论篇—3)

详解AUTOSAR:AUTOSAR应用接口(理论篇—5)

AUTOSAR Port原理概念详解

AUTOSAR Port原理概念详解

AUTOSAR Port原理概念详解

SWC_RTE04-AutoSAR架构定义SR和CS接口