
AutoSAR软件组件的类型有什么不同?
1 问题?
这位粉丝的原话如下:请教一下:关于软件组件的类型中的 Application\SensorActuator\Calibration\Non-Volatile Memory Block\I/O Hardware Abstraction\ComplexDriver\ServiceProxy的区别是什么,比如Application 选择有 xx能力 关闭xx能力,Calibration有xx能力 关闭xx能力,能否扩展一下细节。
2 软件组件类型
首先我们熟悉一下概念,通过这些概念你也知道这些软件类型的不同。详细的教程可参考目录[AutoSAR入门和实战系列总目录专栏的【AutoSAR RTE 和 SWC】部分]。应用程序:应用程序是设计用于执行特定任务或一组任务的软件组件。它可以是一个独立的程序,也可以是一个更大的软件系统的一部分。更大的软件系统一般使用复合软件组件【Composite Software Component】表示,复合软件组件类型聚合了软件组件原型。它们不实现任何功能。它们只是聚合负责实现功能的各个软件组件。
2.1 SensorActuatorSwComponent类型软件组件
(SensorActuatorSwComponentType) 是一种特殊类型的AtomicSwComponentType,因为它依赖于特定的硬件,因此不能在不同的ECU上重新使用(因为使用的硬件仅在特定的 ECU 上可用)。注意这里要弄清楚一个概念:SensorActuatorSwComponentType类型的软件组件是在VFB级别设计的,VFB的思想是它可以重用在任何的ECU上,和具体硬件无关,但是由于SensorActuatorSwComponentType这个传感器可能就跟某一种类型的ECU的传感器相关,和其他类型的ECU的传感器无关,就不能用在另外一种类型的ECU上,你测量压力的ECU,我不能吧温度传感器类型的组件部署在你之上。
SensorActuatorSwComponentType通常是为特定的传感器或执行器编写的,因此(通常)位于与传感器/执行器相同的ECU 上, 通过EcuAbstractionSwComponentType从IO 硬件抽象层读取表示电气值的AUTOSAR 信号,并将其转换为表示物理值的 AUTOSAR 信号【 AUTOSAR 信号就是可用于应用软件组件的传感器或执行器的物理值】。虽然它非常特定于硬件,但传感器-执行器软件组件位于 RTE“之上”,通过它我们连接了应用软件组件和 ECU抽象层。传感器软件组件通常有一个带有ClientServerOperation OP_GET 的客户端端口,以便从 EcuAbstractionSwComponentType的软件组件检索传感器数据。另一方面,执行器软件组件使用客户端端口与ClientServerOperation OP_SET 以向执行器输出提供控制数据。ClientServerOperation OP_GET和ClientServerOperation OP_SET是 SensorActuatorSwComponentType 与EcuAbstractionSwComponentType 之间的“标准接口”。请注意,尽管传感器-执行器软件组件访问RTE“下方”的 ECU 抽象软件组件的端口,但这些接口不是标准化的 AUTOSAR 接口,因此接口的属性isService未设置为 TRUE。SensorActuatorSwComponentType 需要引用相应的sensorActuator,而sensorActuator又包含对ECU 资源描述中描述的HwType 的引用.
EcuAbstractionSwComponentType 或复杂设备驱动程序也引用硬件元素。
2.2 ComplexDeviceDriverSwComponentType类型软件组件
复杂设备驱动程序 (CDD) 软件组件用于对不能被AUTOSAR 基本软件堆栈涵盖的的功能进行建模,以进行复杂或资源关键的传感器执行器进行控制,特别是对于 AUTOSAR 不直接支持的硬件(如有一些刚出来的芯片,或者是一些项目特定ASIC) . ComplexDeviceDriverSwComponentType 可以定义端口以通过AUTOSAR 接口直接与软件组件交互,也可以通过标准化接口直接与基本软件模块交互。需要通过SwcBswMapping映射到对应的BswModuleDescription.
2.3 ApplicationSwComponentType类型软件组件
应用软件组件(ApplicationSwComponentType) 是一个独立于硬件的 AtomicSwComponentType 。它实现(部分)软件应用程序 并可以使用所有 AUTOSAR 通信机制和服务。为了与传感器或执行器交互,它通过Sensor-Actuator Software Components进行通信。
2.4 ParameterSwComponentType类型软件组件
Parameter Software组件主要用于从ECU获取和提供标定参数,并提供给其他软件组件。在使用 MCD 工具(测量、校准和诊断)执行校准过程时,校准工程师需要在运行时对 CPU 内的数据有特定的了解。这种洞察力是通过访问 ECU 内部变量(也称为测量值)以及校准参数提供的。Parameter 软件组件仅由提供者端口 (PPort) 定义。
2.5 NvBlockSwComponentType类型软件组件
此软件组件作为 BSW 层的 Nv Manager一个代理,允许该软件组件访问非易失性数据。
2.6 ServiceSwComponentType类型软件组件
此软件组件用于为给定的 ECU 配置服务。在使用 CompositionSwComponentType 对应用程序软件进行建模时不应使用这些组件,它们仅在 ECU 配置阶段添加。
2.7 EcuAbstractionSwComponentType类型软件组件
ECU抽象软件组件 (EcuAbstractionSwComponentType) 是基础软件的一部分,特别是ECU 抽象层,因此可以通过标准化接口与其他基础软件模块交互。它包含对相应硬件元素的引用,并通过端口向到感器-执行器软件组件提供对ECU特定 IO 功能的访问。
2.8 ServiceProxySwComponentType类型软件组件
ServiceProxySwComponentType提供对相同或不同 ECU(电子控制单元)中另一个软件组件提供的服务的访问。服务代理充当请求组件和提供组件之间的中介,允许组件相互通信而无需了解其他组件的实现细节。
服务代理可用于提供多种好处:
- 它允许组件使用标准化接口相互通信,而不必依赖特定的实现。这使得在不影响请求组件的情况下更容易更改或替换提供组件。
- 它解耦了请求和提供组件,使得独立开发、测试和维护每个组件变得更加容易。
- 它允许提供组件位于不同的 ECU 上,从而使系统架构具有更大的灵活性。
- 它可以提供额外的功能,例如错误处理和日志记录,这对于调试和诊断很有用。
- 服务代理是 AUTOSAR 架构的关键部分,因为它们允许组件以标准化和灵活的方式相互通信,从而支持开发具有多个 ECU 的复杂系统。
3 答案
本质上的不同就是每种组件类型的模板不同(学过c++,java天然由优势,理解unl也很快),具体可能是属性和拥有的方法不同,举个例子:传感器/执行器它需要定义硬件的配置和物理值和autosar signal的映射。具体的配置参数:sensorAcutator。类似的逻辑你可以看一下其他类型的SWC需要的一些特殊属性,具体参考SoftwareComponentTemplate文档。
文章转载自公众号:车端
