惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Latest news
Latest news
T
Troy Hunt's Blog
V
Vulnerabilities – Threatpost
L
LINUX DO - 热门话题
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Simon Willison's Weblog
Simon Willison's Weblog
V
V2EX
博客园 - 司徒正美
B
Blog RSS Feed
AWS News Blog
AWS News Blog
MyScale Blog
MyScale Blog
Scott Helme
Scott Helme
Cisco Talos Blog
Cisco Talos Blog
Last Week in AI
Last Week in AI
NISL@THU
NISL@THU
博客园 - Franky
P
Proofpoint News Feed
博客园_首页
C
CERT Recently Published Vulnerability Notes
雷峰网
雷峰网
S
Schneier on Security
P
Proofpoint News Feed
Hugging Face - Blog
Hugging Face - Blog
G
GRAHAM CLULEY
博客园 - 三生石上(FineUI控件)
月光博客
月光博客
WordPress大学
WordPress大学
The Hacker News
The Hacker News
T
Threatpost
阮一峰的网络日志
阮一峰的网络日志
A
Arctic Wolf
Microsoft Azure Blog
Microsoft Azure Blog
T
The Exploit Database - CXSecurity.com
Engineering at Meta
Engineering at Meta
罗磊的独立博客
T
The Blog of Author Tim Ferriss
D
Darknet – Hacking Tools, Hacker News & Cyber Security
I
Intezer
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
K
Kaspersky official blog
SecWiki News
SecWiki News
云风的 BLOG
云风的 BLOG
美团技术团队
C
Cybersecurity and Infrastructure Security Agency CISA
博客园 - 【当耐特】
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Security Latest
Security Latest
C
Cyber Attacks, Cyber Crime and Cyber Security
B
Blog
S
Security Affairs

博客园 - 明明1109

MBD笔记:PMSM直接转矩控制 MBD笔记:基于滑模控制PMSM矢量控制 MBD笔记:三相永磁同步电机的矢量控制(四) 自动控制:采样系统理论 MBD笔记:IPMSM 速度控制模型解析 MBD笔记:SPWM技术(三) 自动控制:自动控制系统数学模型 自动控制:基本原理 MBD笔记:SVPWM技术(二) MBD笔记:三相PMSM数学模型(一) 旋转编码器 计算机图形:高级GLSL 计算机图形:gamma校正 XMODEM协议解析 电机控制笔记:BLDC控制原理 STM32F407启动文件 MBD笔记:PWM与DC-DC变换器的模型设计 MBD笔记:放大器与滤波器模型设计 电机控制笔记:PMSM无位置传感器控制介绍 电机控制笔记:理解直流无刷电机矢量控制 拉普拉斯变换 FOC算法笔记 AUTOSAR笔记:模式管理 AUTOSAR笔记:SWC AUTOSAR笔记:IO系列驱动 AUTOSAR笔记:OS 电路基础:电感 电路基础:电容器 电路基础:交流电路 电路基础:戴维南定理、诺顿定理
AUTOSAR笔记:通信
明明1109 · 2025-07-11 · via 博客园 - 明明1109

这部分不包括诊断、标定的通信,以CAN为主.

通信基础

架构、术语

BSW中的Communication主要包含3个部分:

  • 通信服务(Communication Service)
  • 通信硬件抽象(Communication Hardware Abstraction)
  • 通信驱动(Communication Driver)

架构关系如下:

img

子模块:

  • COM:应用层传下来的数据,首先到这里,应用层无需关心收发的数据是通过什么总线传输,只需要将它传输给COM即可. 收发的数据,由用户DBC文件或ARXML文件定义好(主机厂提供). COM上传输的是单纯的数据,没有附加单位等物理意义的信息,应用层关心该数据的实际意义、数据大小. COM相对于一个信号接口,起网关转发的作用.

  • PDU Router: PDU——Protocal Data Unit, 协议数据单元. 该模块将COM下发信号数据分配到相应的总线,或者将不同总线上传信号传给COM,起到路由作用.

  • IPDU Mux: 解析一些特殊协议,比如CAN FD或用户自定义的一些协议,起统一CAN ID、不同信号layout的作用

  • CAN Tp:分包数据传输与错误检测,通常诊断时才会用到

  • CAN Interface:配置收发队列、组帧(FlexRay)、管理时间触发总线的调度表(LIN、FlexRay);与硬件无关.

  • CAN Driver:MCAL中MCU CAN模块的驱动;硬件相关

  • Trcv Driver:Trcv(Tranceiver),收发器驱动.

发送流程

APPL SWC➡COM➡PDU Router➡Bus Interface➡Bus Driver➡硬件发送报文

img
from ref. [1]

  1. 应用层SWC send 1个数据到COM
  2. COM写信号到PDU Buffer
  3. PDU被PDU Router立刻发送或按周期发送(每个PDU都有一个独立的ID),之后PDU Router根据不同总线,将PDU下发
  4. Interface根据不同通道,将报文写入不同队列
  5. Driver根据报文优先级立刻发送报文

接收流程

接收流程反过来:

硬件接收报文 ➡Bus Driver➡Bus Interface➡PDU Router➡COM➡APPL SWC

img
from ref. [1]

接收报文,可以用中断,或循环接收. 如果是中断接收:

  1. 硬件接收报文
  2. Driver发出Rx中断,通过RxIndication,数据传输到Interface
  3. 传递到PDU Router
  4. 传递到COM,如果SWC使用Data Reception Trigger,就通知RTE;否则,暂存到Buffer
  5. 信号被RTE读取,然后应用层读取

协议数据单元PDU

一般主机厂要求才会用IPDUM.

下图跟前面的架构图略有区别:一般通过PDUR与COM连接,迫不得已才会IPDUM与COM直连.

img
from ref. [1]

IPDUM将IPDU灵活分割、解析,适用于CAN FD、自定义协议.

IPDUM将IPDU分为:静态部分(static part)、复用部分(multiplexed part). 复用部分可通过一位或多位作为标识符,来使用不同layout,静态部分是固定不变的. 下图黑色或灰色部分代表有效的payload(有效载荷)

img
from ref. [1]

PDU转换图

  • I-PDU: Interaction PDU
  • N-PDU: Networkd PDU
  • L-PDU: Link PDU

img

信息发送的Filter机制

Filter机制

从COM将IPDU发送给PDUR时,会用到Transmission(TxComMode)Modes的机制,作用:通过对被发送信号数据本身的过滤,自动选择发送机制.

例如,我们要发送一个PWM占空比信号给另1 ECU,周期10ms;但我们想减少总线负载,在占空比长期为0时,可以慢点,如周期100ms. 此时,可判断我们发送的数据是否为0,然后自动调整发送周期.

实际情况,可能还需要考虑IPDU上其他数据,最终形成的机制如下图:

img
from ref. [1]

对pdu每个信号做Filter判断(见下文);
然后,根据每个信号的判断结果(True/False),进入模式判断;
模式判断会做或运算(or),只要有一个True,就进入Transmission Mode True模式,否则进入... False模式;
最后,在对应模式中进行相应处理.

Filter判断

根据传入信号做True/False判断,Filter判断(COM Signal Filters)有8类判断方式:

1)None
不做Filter,最常用

2)Always
判断结果永远True

3)Never
判断结果永远False

4)MaskedNewDiffersMaskedOld

当 (new & mask) != (old & mask) 时,系统会返回此状态码

old = 00001010b
new = 10111001b
mask = 00001111b -> true
mask = 00001100b -> false

5)MaskedNewEqualsX
当 (new&mask)==x 时,系统返回此状态码

new = 10111001b
x = 9 // 1001b
mask = 00001111b -> true
mask = 10010000b -> false

6)MaskedNewDiifersX
当 (new&mask) !=x 时,系统返回此状态码

new = 10111001b
x = 9 // 1001b
mask = 00001111b -> false
mask = 10010000b -> true

7)NewIsOutside

当 ((new < min) || (new > max))时,系统返回此状态码

8)NewIsWithin

当 ((new >= min) && (new <= max))时,系统返回此状态码

信息发送模式(Transmission Modes)

所有Filter判断完后,做所有的Filter结果 或运算(or),然后根据结果进入不同的发送模式.

发送模式有:

1)None
不发送该PDU

2)Direct
可设置重复次数、重复周期,然后直接按配置的次数和周期发送(发送次数完成后,停止发送)

3)Periodic
周期发送. 可设置周期(Period)、偏移(Offset),即延迟Offset之后,按周期发送. 通常使用较多

4)Mixed
混合发送,direct + Period

例子

我们想发送pwm占空比信号(PDU中只有这一个信号)给另一个ECU,每10ms发一次;我们想减少总线负载,在占空比长期为0时,每100ms发一次. 此时,需要判断发送的数据是否为0,然后自动调整发送周期.

1)用 MaskedNewEqualsX 方式Filter,设置Mask=11111111b, x=0

根据 (new&mask)==x 判断方式,new为0,那么结果一定为True,其余时候为False

2)判定结果为True时,设置 Transmission Modes(发送模式)为Periodic,Period1=100ms,offset1=40ms;
判定结果False时,设置 Transmission Modes为,Periodic,Period1=10ms,offset1=0ms

通信机制

Signal Groups

Signal Groups由通信矩阵定义,通常由OEM设计.

信号组(Signal Groups):将作用相近的信号放到一组里方便管理. 如果组中一个信号失效,那么该组所有信号被认为失效.

例如,陀螺仪x,y,z轴3个方向加速度信号,放到一个信号组. 如果陀螺仪失效,其中有一个信号失效,那么这组信号都无意义.

Update Bit

Update Bit 由通信矩阵定义,通常由OEM设计.

signal中保留1bit用做update bit,该bit一般和deadline monitoring超时监控一起使用. 该bit专门指示信号是否被应用层更新了. 如果长时间未更新,那么启用超时处理.

从下图流程,来看update bit作用:

  1. sender在应用层更新signal A的数据,然后COM模块自动将update bit置位,代表该信号被更新;signal B未被更新,对应update bit是0;
  2. 将signal A、B通过通信传送给接收方;
  3. 接收方接收到signal A、B之后,开始解析,发现
    1)signal A被更新过了可用数据(update bit=1),就进入signal notification处理;
    2)signal B未被更新,进入监控超时处理.

img
from ref. [1]

Notification Mechanisms

Notification Mechanisms(通知机制),有多种类别,常用接收(Rx indication)、发送(Tx confirmation)成功的通知,都在Communication->Signals中配置.

通知机制有以下几种:

  • 接收成功通知
  • 发送成功通知
  • 超时通知
  • 错误通知
  • 失效通知
  • 更新位通知

重要属性:立即通知(Immediate)、延迟通知(Deferred),在Communication->PDUs中设置.

  • 立即通知:接收/发送成功,立即中断方式进入通知函数
  • 延迟通知:在下一次Task中调用Com_MainFunctionRx()或Com_MainFunctionTx(),触发通知

Deadline Monitoring

1. 超时监控(Deadline Monitoring)

可分为2个等级:

  • IPDU级:当一个Rx IPDU没有在规定时间内收到有效数据,就启动超时处理
  • Signal级:如果没有收到Update Bit,就启动超时处理

Dev、Cfg的COM都能配置Deadline Monitoring的Timeout Time,但最后都要同步到Cfg中做代码生成.
IPDU的Timeout Time的来源是Signal的最小Timeout Time. 例如,IPDU有2个Signal:A和B. 其中,A的Timeout Time=100ms,B的Timeout Time=50ms,那么该IPDU的Timeout Time=50ms.

超时监控监控到超时,如何处理?
这就涉及到超时处理.

2. 超时处理

COM超时处理:

  • 超时后,会有超时的Notification被调用:Rte_COMCbkTout_<ComSignalName>
  • 可选,可选择将超时信号复位为初始值(需配置ComRxDataTimeoutAction)

RTE超时处理:

  • 超时后,可触发一个Runnable来处理
  • 使用相关Rte_Read_<Pp>_<De>的时候,会返回错误RTE_E_MAX_AGE_EXCEEDED
  • 使用Rte_IRead这类Buffer类型S/R接口时,状态可由Rte_IStatus决定

Invalidation

1. 失效机制

失效机制(Invalidation):当一个Signal Groups中任一Signal被设置为无效时,整个Groups被设置为无效,不允许一半有效、一半无效的signal出现. 失效的信号,可通过 Rte_Inmalidate(explicit API)Rte_IInvalidate(implicit API)来发送一个失效值.

2. 失效处理

有3种方式:

  • Keep:保持原值不变
  • Replace:用一个初始值替换
  • None:不做任何处理,相对于失效机制未起作用

Data Mapping

数据映射(Data Mapping)

概述

Cfg中,数据不能直接放在IPDU上,必须要映射到相应的Signals才行. Signals一般由通信矩阵定义,但通信矩阵并不知道APP用哪个数据进行传输,需要我们在Dev中定义数据(Data Elements)和Signal(Network Signals)相应映射,才能正常使用.

Dav中,映射可以至下而上、之上而下,在Cfg和Dev中都能配置这一功能,之后导入另一方即可. 分两种情况:

  • ECU SW Composition层级中,Cfg和Dev中都能配置Data Mapping,但需要做Delegation Ports,将我们的通信ports做一个逻辑上的与其他ECU相连的操作
  • Atomic SWCs层级中,只能在Cfg中配置,同时不需要Delegation Ports

配置

Delegation Ports(委托端口) 是一种用于组件间通信的机制,主要应用于SWC与ECU抽象层或CDD之间的接口传递.

1)Dev中,做Delegation ports操作:在完成端口的实体化后,可右键> Complete Ports...,然后出现下面对话框,选择Delegation Ports Only,就能看见端口延伸出去了

含义是连接上更高一级的SWC

img
from ref. [1]

2)在Dev中做Data Mapping后,出现的结果

img
from ref. [1]

3)Cfg中,也会出现相应提示信息

img
from ref. [1]

参考

[1] AutoSAR入门到精通系列讲解