Autosar CP系列：传感器/执行器设计模式

设计模式是解决软件问题的通用方案，掌握设计模式是从程序员到工程师的必经之路，本文讲解Autosar CP相关的设计模式，先讲解传感器/执行器模式。

从信号流到设计模式

下图的一个实例，讲解了ECU内传感器和执行器的信号流，是一个典型的信号流处理方式：

车速信号：车速传感器根据车速变化，输出电流信号，经过电气接口进入到ECU内，转化为电压信号，传输到微控制器，由MCAL调用AD模块处理该信号，该信号经过ECU抽象层，被传感器SWC接收，后续其他的应用SWC从该传感器SWC获取车速信息，进行逻辑处理；

灯光控制：灯光相关的应用SWC，和灯光执行器SWC通信，传输灯光控制信息，执行器SWC传输信号到ECU抽象层，ECU抽象层通过MCAL将电压值信号传输到ECU硬件电路，硬件电路转化电压信号为电流信号，控制灯光执行器。

传感器/执行器摸设计模式

该设计模式将上述方式进行了细化，提出在传感器执行器的组合中采用三层分层结构，分别是电气设备驱动层、传感器 / 执行器设备驱动层、虚拟设备驱动层。

每层由单个软件组件类型（SwComponentType）或包含多个软件组件类型的组合软件组件类型（CompositionSwComponentType）表示，电气设备驱动层必须包含至少一个传感器 / 执行器软件组件类型（SensorActuatorSwComponentType），该组件是唯一被允许访问 ECU 抽象软件（ EcuAbstractionSwComponentType）的组件。

信号流
 

设备抽象

该设计模式下，对传感器和执行器进行抽象，见下图的传感器设备抽象和执行器设备抽象，设备抽象运行于RTE之上。

闭环执行器：带有传感器，进行信息反馈的执行器

开环执行器：不带传感器反馈的执行器

信号流

下图描述了该设计模式下信号流处理路径，信号从ECU抽象层流到设备抽象，

ElecRaw：表示 “电气原始值（Electrical Raw Value）”，是由 ECU 抽象提供的电气传感器原始值，通常是未经滤波的，其值可以用电压、电流、（周期）时间、二进制值、频率、占空比等表示。

ElecBascFild：代表 “电气基本滤波值（Electrical Basic Filtered Value）”，是对电气原始值进行基本滤波后的结果。

Raw：指 “原始值（Raw Value）”，是通过对基本滤波后的电气值（ElecBascFild）进行简单转换得到的物理值。

Measd：指 “测量值（Measured Value）”，是经过最终滤波和偏移校正后的传感器物理值，也可称为标准传感器值。

Consold：表示 “合并值（Value）”，可以是测量值（Measd）或建模值（Estimd），当无法提供物理传感器值（如故障、不合理或其他原因）时，用于提供替代值 / 默认值或冻结值。

Estimd：表示“估计值（Estimated Value）”，是一个建模的物理传感器值或标准传感器值，可以用作Measd物理传感器值的替代。

Outp：代表 “输出值（Output Value）”，是控制器的输出值，用于请求控制器到达最终的设定点，通常以百分比表示。

Sp：指 “设定点值（Setpoint Value）”，是最终请求的物理设定点，通常以百分比表示。

Reqd：表示 “请求设定点（Requested Setpoint）”，是最终请求的物理设定点，通常以百分比表示。

Cpby：代表 “能力（Capability）”，提供动态即时能力，通常用于输出限制，但也可能包含对合并值变化率的限制，以百分比表示。

分层能力

电气设备驱动层：包含至少一个传感器 / 执行器软件组件类型（SensorActuatorSwComponentType），负责处理来自传感器或执行器的原始电气信号，为上层提供经过初步处理的电气数据。

以汽车速度传感器为例，该层的电气设备驱动组件会接收来自传感器的原始电流或电压信号（如 0 - 20mA 或 0 - 5V），这些信号是未经处理的，包含了传感器所测量的原始信息，有电气噪声干扰。

传感器 / 执行器设备驱动层：位于电气设备驱动层之上，它对从电气设备驱动层获取的信号进行进一步处理，使其更接近实际物理量的表示，并根据传感器或执行器的特性进行特定的操作和调整，分别处理传感器信号和执行器的控制信号。

对于传感器信号，传感器设备驱动组件会进行高级滤波（如去除噪声、平滑信号）、偏移调整（使测量值更准确地反映物理量）、零点调整（确保在特定条件下测量值为零）等操作。

对于执行器控制信号，执行器设备驱动组件会根据设定点和反馈信息进行输出值的调整，例如进行抖动处理以克服静态摩擦、限制输出值以保护执行器、进行闭环或开环控制等。

虚拟设备驱动层：是最上层的驱动层，它提供了一个抽象的、虚拟的设备视图，将传感器和执行器的功能进行整合和抽象，为应用软件提供了一个统一的接口，使其能够更方便地与传感器和执行器进行交互，而无需了解底层的硬件细节和复杂的信号处理过程。

包含虚拟设备协调器（DevCoorrVirt）和虚拟设备传感器（DevSnsrVirt）等组件，虚拟设备协调器主要负责协调和管理传感器和执行器的整体操作，例如转换和线性化物理请求值、提供诊断测试接口、处理设定点的相关操作（如抖动、释放功能）以及协调执行器的激活和停用等。

虚拟设备驱动器则主要负责处理传感器信号的替代和补偿、信号质量评估、提供诊断测试接口以及进行一些与传感器特性相关的操作（如惯性补偿）。

虚拟设备部署

虚拟设备的不同层次的组件，可以部署在同一个ECU或不同ECU上，使用RTE进行连接交互。

在不同ECU上的部署
 

同一个ECU上的部署
 

实际例子

节气门的设备抽象，按电气设备层、设备驱动层、虚拟设备层的设计方式，对节气门的处理，将从ECU抽象层获取/设置电气信息，对外提供传感器信息和控制执行器的能力，信号流在这个虚拟设备内部流转的路径如下。

开源了几个项目：
基于UDS on CAN的Bootloader的刷写上位机：
https://github.com/sydyg/UDS-on-Bootloader.git
OSEKNM协议栈：
https://github.com/sydyg/OSEK_NM
嵌入式、汽车电子学习笔记：
https://github.com/sydyg/Vehicle_Soft_Class.git