Last Updated on 2026-07-21 by MarsRain

CAN总线

CAN

与传统车辆内部结构区别

点对点的方式布线方法、成本、重量等缺陷过于明显，无论是对于后面的电器元件的扩展都十分不友好，所以CAN总线结构问世解决了这些缺点。

主要优点

总线的方式有良好的扩展性，只需要在总线挂相关的节点接入总线即可，线数也大量减少，减少成本
数据传输具有瓶颈，单线限制带宽

CAN内部结构

微控制器——与应用层的数据交互
CAN控制器——报文封装，用二进制码流传给收发器
CAN收发器——根据can协议，将数据比特流转发为电信号

CAN的整体结构——CAN_H CAN_L

数据链路层

寻址方式——确定发送与数据之间的关系，方法：
点对点的寻址——一对一
广播寻址——一对多

总线访问机制

节点没有主从之分，都可以访问主线。主线在任意时刻只能被一个节点访问
非破坏性仲裁机制——访问冲突时，根据报文的id进行优先级裁定。即使是没有被访问的报文，后续依然可以重复发送，直到被总线接收

仲裁厂——线与机制、回读机制

回读机制：根据节点发送的数据帧和总线报文帧数的比较，节点会根据不同的返回结果进入不同的机制。AB节点同时传输报文，会触发线与机制。此时AB传输的数据报文的同一帧会做与计算，最终计算出的帧数为0的数据流会被总线读取。假设A的数据被读取了，而未被读取的B的数据流会返回B节点，进入接收模式，等待下一次的发送机会。总线处理完A的数据之后，B就可以重新发送。这就是回读机制
注：每个报文id都具有唯一性，所以尽管前面的帧数会相同，总会有一个不相同的地方出发线与机制，决出优先级

访问优先级——当报文的高位0的个数越多，优先级越高

CAN报文结构

标准帧：id位11位big和0~8个有效字节组成
远程帧：不包括有效字节
扩展帧IDE：id有29bit，商用偏多
扩展远程帧：更少见

结构：
SOF真起始+仲裁厂+控制场+数据场+CRC校验场+AFK应答场+EOF真结束

位填充的规则

只要总线出现连续五个极性相同的位，就会在下一位填充一个极性相反的位。所以不可能在一个保温结构中出现六个连续极性相同的位。填充位也会纳入“连续五个极性相同”的计算

CAN数据传输的保护机制
CRC校验：对前面数据场的数据监控

错误帧

发送原则：当错误被检测到，立即发送下一位的错误帧

格式：
错误标志位+错误界定符

Error-Active Node：6个0+8个1
000000+11111111
其他节点报错的时候也会添加在“6个0”当中，最终结果可能会导致变成12个0

Erro-Passive Node：6个1+8个1

错误都是成对出现，所有参与通信的节点，可能都会出现错误。那么为了保持数据的一致性，所有的节点可能就会抛弃正在传输的数据，再次重新发送。

错误界定

主动错误/被动错误/Bus Off

根据两个参数寄存器——TEC、REC进行确定

对于每一个节点每次成功发送/接收一个帧，会-1；相反，则+8

对于发送节点在发送帧过程中，检测到一个错误，则TEC数值+8；接收节点率先接收到错误帧，REC+8，如果说在其他节点已经发现的错误帧的基础上仍然有错误帧，则REC+1

CAN FD

整体改善

随着时代的发展，车辆网中的数据传输量越来越庞大，而CAN总线很难满足过大的数据传输，所以CAN FD又在CAN的基础上升级。相较于CAN总线的1Mbit/s的数据流而言，FD在两个方面做出改善：

支持更高的传输速率

但并不是一直维持着高速率传输，而是可变速率传输。

FD报文结构：仲裁段和数据段
CAN FD最高能够支持8Mbit/s的通信速率

CAN FD数据场的扩充

传统CAN的数据场长度最多8个字节
CAN FD最大可达64个字节

CAN FD 协议

两个报文格式：
CAN FD标准帧：11bit，扩展到64字节
CAN FD扩展帧：29bit，扩展到64字节
删除远程帧

CAN FD报文结构

和CAN报文结构类似，只是添加了新的标志位：
RRS FDF BRS ESI

RRS替换RTR
FDF：添加在IDE（扩展帧）之后，用于识别是否为传统报文。FDF=0,传统报文;FDF=1,CAN FD报文
IED：IED=0是传统CAN扩展帧报文，IED=1,CAN FD扩展帧报文
BRS（速率切换位）：BRS=0,CAN FD保持恒定速度，BRS=1,切换较高的速率值
ESI（错误状态指示位）：发送节点会通过ESI通知其他节点此时的错误状态。ESI=1，被动在错误状态；ESI=0，主动错误状态

在CAN FD中的CRC检验场中，CAN FD会根据数据场的长度变化而使用不同的CRC校验。同时，还和CAN的CRC不同，使用的是固定位置的填充机制。

FlexRay

物理层

flexray可支持不限于任何物理限定的物理拓补，节点两端通过两根信号线——bp bm进行连接，线长还不得超过24m，以免影响通信。同时支持单双通道，
当节点存在四个或以上时，拓补结构可选择被动新型和总线型。

现实场景中，多个拓补图会组合使用来确保flexray总线正常运作

数据链路层

FlexRay使用类似TTCAN的总线获取方式来避免冲突。其中周期性的通信循环被分为静态部分以及可选地动态部分。其中的比特率有2Mbit/s、5Mbit/s、10Mbit/s，理论上可以做到更高的比特率。这点类似于MOST，它采用TDMA方案来进行信道访问，但是可以应用到两个物理连接（通道A、通道B），通道B用来发送相同的信息（作为冗余通信路径）或者发送不同的信息（增加有效的吞吐量）。

MOST

MOST是面向媒体的系统传输的英文缩写。顾名思义，相比于CAN和LIN，总线MOST设计时考虑到不同的需求，低延迟和高容错性是CAN和LIN的主要目标，而MOST则被设计为一个多媒体和信息娱乐的总线系统。

MOST的关键功能包括：

• 内置流媒体信道，对信息娱乐应用来说不可或缺。
• 高达150Mb/s的总数据带宽，远远大于CAN、LIN或FlexRay。
• MOST150支持以太网分组信道MEP，用于提供互联网协议（IP）功能。
• 支持多种光纤电缆布线方式，解决了EMC问题，并提供了电流隔离。
• OST也支持电源管理、睡眠模式和快速唤醒功能。

车载以太网

当前的车载网络大部分采用了速度相对缓慢的汽车专用网络技术，如CAN、LIN。随着汽车的内部运作变得更加智能和复杂，越来越多的智能传感器和高性能车载计算机被引入，应用于汽车的新网络技术不仅要更快、更经济、支持多节点互联，而且需要实现标准化和广泛应用，以保证不同供应商和行业之间的兼容和互通。

车联网

从网络角度看，车联网（IoV）是一个“端——管——云”三层体系

车联网本质上世物联网与移动互联网的融合。它通过整合车、路、人的各种信息和服务，最终做到以人为本，为人服务。

车载网络架构

传统分布式架构

优势：以最具有成本效益的方式有效地将各部件组合在一起

缺点：扩展困难、安全性能低、传输限制大

混合式架构

目前车辆采用较多的一种架构，通过网关的引入让车辆的各个功能域都有独立的运算能力，并且还有各功能之间还有相应的数据通道，同时在一定程度上还做了隔离。

中央计算式架构

通过中央服务器来汇总、集成、处理五个功能域传输过来的数据，这样中央处理器就会得到最优质的信息。但是，这样的传输路径是未经过任何过滤和修改的，这会对中央服务器造成较大负担。也因此，这样的架构就有一个很大的问题：中央服务器会变得各种意义上的庞大。

基于域的汽车架构

连接域

管理所有将汽车连接到外接的无线接口，连接域的首要要求是以下四点：

1. 汽车安全完整性等级（ASIL）B级
2. 安全性
3. 接收稳定性
4. 多标准传输共存

驾驶员替代产品域

为了防止歧义，这里的“驾驶员替代”是替代驾驶员的意思。通过机器学习，让车辆拥有一个自己的“大脑”，也是当前自动驾驶辅助AADS的一个重要区域。的首要要求是以下四点：

• ASIL D级
• 汽车资格认证
• 智能检测
• 成本/外形尺寸/性能权衡

传动与动力系统域

顾名思义，这是汽车的“心脏”，这里负责管理汽车的运动和速度。从以前的纯油车，油电混动过渡，再到现在的纯电车，都在慢慢地优化引擎、变速箱、驱动轴，这样才能让这些部件在高温和几乎持续不断地震动下工作。

该域的首要要求是：

1. ASILD级。
2. 成本/外形尺寸/性能权衡。
3. 软件支持个性化且可升级。
4. 数据融合（汽车传感器和驾驶员输入）。

车身与舒适系统域

这一域要负责的是驾驶员和乘客的安全机制和访问机制，并且还会根据驾驶员和乘客的行为了解他们的偏好。

从内部的空调、座椅、倒车镜、车窗的控制，到外部雨刮器、照明系统等等，都是这一域负责。

该域的首要要求是：

1. 可升级功能。
2. 少维护。
3. 高能效。
4. 监控和学习能力。

车载体验域

车载体验域可以让汽车支持车上每个人的娱乐、工作和健康需求。

车载体验域基本上可以根据用户的偏好进行调整和智能学习，使用灵活、便于升级的软件，确保可通过任何现有硬件基础架构来访问内容，同时还需要现先进的无障碍人机界面（HMI），能够支持语音命令、手势、增强现实和高级个性化功能。

该域的首要要求是：

1. 空中（OTA）更新。
2. 监控和学习能力。
3. 支持内容访问的软件可升级性/灵活性。
4. 高级人机界面。

架构连接：网关和车载网络

基于域的汽车架构可以通过一个复杂的通信网络相互连接，让各个域利用串联和共享信息进行操作。为了保证数据能在正确的带宽中以安全可靠的方式进行分享，内部网络都会采用目前最先进的设置，包括以太网连接和安全网关（防火墙）。

从车载网络（IVN），包括各种传统汽车技术，如CAN、LIN、FlexRay等，都可以安全无忧地连接到各个域，确保正确分配汽车生成的数据。车载网关会将信息保存在汽车内，保护其免遭外部访问和外部攻击。网关用于保护子系统（构建防火墙），将各个子系统隔离开，避免意外交互。

该域的首要要求：

1. ASILD级。
2. 安全性。
3. 接收稳定性。
4. 低电磁辐射。
5. 多标准传输共存。

车载OTA测试

• SOTA（软件空中升级）：主要针对座舱域的应用和系统，比如地图、音乐App、语音包、HMI界面。它本质上只更新应用层，不涉及车辆底层控制。升级失败一般不影响行车安全，主要是功能体验问题。
• FOTA（固件空中升级）：针对车辆底层控制器，如三电系统（VCU/BMS/MCU）、自动驾驶域控（ADCU）、车身域、底盘域等。这是刻在ECU固件里的修改，直接影响动力、转向、制动。

FOTA的测试等级和风险远高于SOTA，是工作的重中之重。

完整升级链路

一台车要完成OTA，大致会经历云端-管道-车端-车内子节点的流程：

graph TD;
A[云端：OEM的OTA平台生成升级包，制定升级策略（车型、地域、灰度比例），签名加密后发布。]
B[管道：通过4G/5G或WiFi下发至车端T-Box或网关。]
C[车端主控：T-Box或中央网关（如ICGM）负责下载、解密、验签，并作为升级主节点。]
D[车内总线：主控通过CAN/FD、以太网（DoIP/SOMEIP）把固件分包发送给各个待升级的ECU。]
E[ECU自升级：各控制器在安全条件下（如驻车、下高压）执行刷写，并通过诊断协议反馈进度和结果。]

A-->B-->C-->D-->E

测试环境搭建

环境的搭建应该尽可能贴合所有会遇到的各种情况、环境，包括但不限于：地下车库、隧道、寒冬等会影响网络信号的环境；云端卡死，无法正常发送数据包等

法规标准

WP.29 UN R155（网络安全）和R156（软件更新）是用例的标准。特别是R156要求：

• 必须有RXSWIN（软件识别码），升级后必须可读取并验证。
• 升级过程中不得影响安全相关系统。
• 必须确保升级的真实性和完整性（验签）。
  在测试报告里，要能体现出对每个ECU的RXSWIN的验证记录。

GB 44495-2024《汽车整车信息安全技术要求》

这份国标是一个体系与产品并重的综合性评估，主要分为管理体系审查和车型技术测试两大部分。

第一部分：信息安全管理体系（CSMS）审查

这个部分不直接上车测试，而是审查车厂是否建立了覆盖车辆全生命周期的信息安全管理体系。审核内容包括：

• 风险管控：是否有识别、评估、分类和处置信息安全风险的流程。
• 测试验证：是否有验证信息安全措施有效性的流程。
• 监测响应：是否有对网络攻击、威胁和漏洞的监测、响应及上报机制。
• 供应链管理：是否有效管理了与供应商之间的信息安全依赖关系。

第二部分：信息安全技术要求测试（车型技术测试）

该部分是在实车或零部件上进行的128个具体测试项目，覆盖四大技术防线。

1. 外部连接安全

• T-BOX无线通信：检查加密传输协议（如TLS/SSL）、证书有效性、身份鉴权机制等。例如，验证通信链路是否使用了不低于TLS 1.2的加密协议。
• Wi-Fi与蓝牙：测试热点接入认证、蓝牙配对方式是否安全。
• 物理接口（OBD、USB）：
  • OBD接口：检查是否有访问控制（如PIN码）、权限划分是否合理。例如，测试通过OBD口是否能非授权修改车辆关键参数。
  • USB接口：测试是否能通过U盘注入恶意代码、绕过文件访问限制。例如，检查USB口是否只允许读取指定格式的文件，如.apk文件
• 漏洞扫描：对远程控制等功能系统进行漏洞扫描，确保不存在权威平台公布的、6个月以上未处置的高危漏洞。

2. 通信安全

• 车云通信：验证与制造商云平台的通信是否进行双向身份认证，并使用加密和完整性保护。
• 车内网络（CAN、以太网）：
  • 防篡改/重放：检测关键控制报文（如转向、制动）是否有身份认证或完整性校验机制。例如，重放录制的关键指令，验证车辆是否会错误执行。
  • 网络隔离：验证内部网络是否有区域划分和边界防护，跨域请求是否遵循默认拒绝和最小权限原则。
• V2X通信：验证V2X直连通信时，是否对证书的有效性和合法性进行验证。

3. 软件升级安全
主要确保升级包的真实性和完整性。检测方法包括：

• 真实性测试：篡改升级包的签名值，验证车辆是否会拒绝安装。
• 完整性测试：篡改升级包的数据域，验证车辆是否会拒绝安装。

4. 数据安全

• 密钥保护：验证存储的对称密钥和私钥是否通过安全访问或硬件安全模块（HSM）等技术保护。
• 敏感数据保护：检查存储在车内的敏感个人信息（如轨迹、音视频）是否加密。
• 防篡改/删除：
  • VIN码：测试VIN等身份识别数据是否能被非授权删除和修改。
  • 关键数据：测试制动参数、安全气囊阈值等关键数据是否能被非授权篡改。
  • 安全日志：测试安全日志是否能被修改或非授权删除。
• 数据出境：这是一个关键项。测试会抓取车辆的对外通信数据包（时长不少于3600秒），并解析其中的目的IP地址，检查是否包含境外IP。

GB 44496-2024《汽车软件升级通用技术要求》

GB 44496专注于规范软件升级的整个过程，其检测同样分为管理体系审查和车辆技术测试两部分。

第一部分：软件升级管理体系（SUMS）审查

此部分同样是文件审查和人员访谈，审查车厂是否建立了覆盖软件升级全生命周期的管理体系。内容包括：

• 流程制度：是否有书面化的升级管理流程，覆盖从需求、开发、测试到发布的各环节。
• 版本控制：是否能唯一标识所有软件版本。
• 风险评估：是否有流程评估升级对型式批准、车辆安全等的影响。
• 记录留存：是否有流程确保所有升级活动的信息被记录并安全存储（至少保存至车型停产后10年）。
• 应急管理：是否有处理升级突发事件的应急机制。

第二部分：车辆要求测试（VTA实车验证）

此部分在实车上进行，分为8项通用测试（所有支持软件升级的车辆）和6项在线升级（OTA）附加测试。

8项通用测试（所有升级功能都需测试）

1. 升级包真实性与完整性验证：用篡改工具修改升级包，验证系统能否识别并拒绝。这是安全底线。
2. 软件识别码（SWIN）读取：通过OBD接口读取ECU的软件识别码，验证是否与申报信息一致。
3. 用户告知：核对升级前车机屏幕展示的升级信息（目的、时长、风险等）是否完整准确。
4. 用户确认机制：验证升级必须在用户明确确认后执行，不能自动进行；断电重启后不能自动续刷。
5. 电量保障：模拟不同电量，验证低电量时系统能否正确拦截升级，且拦截阈值必须保证有足够电量完成升级和回滚。
6. 行驶中升级安全：验证车辆在行驶状态下能否被禁止启动OTA升级。
7. 兼容性验证：推送不匹配的升级包，验证系统能否识别并拒绝。
8. 升级记录可追溯性：升级完成后，检查是否有完整记录（时间、版本变化、结果）。

6项在线升级（OTA）附加测试（仅支持OTA的车辆需测试）

1. 多通道用户告知一致性：比对车机、手机APP、短信等不同渠道的升级信息是否完全一致。
2. 前置条件检查：验证系统升级前的自检机制是否覆盖了所有强制条件。
3. 车门防锁止：这是关键测试项。在升级中模拟多种故障（如断电），验证车内机械解锁能否正常打开车门。
4. 升级失败处理与回滚：测试升级中断电、断网等极端情况后，系统能否完整回滚到旧版本或进入安全状态。
5. 断点续传：验证升级包下载中断后，能否从断点处恢复，而非重新下载。
6. 安全相关功能不受影响：验证在升级过程中及升级后，车辆的安全相关功能是否正常工作。

总结下来：496面向的软件升级，其中牵扯到的东西包括切不仅限于ECU、OTA、软件PIN码识别、软件升级包的真实性、完整性测试；升级结果测试……本博客旨在记录用到的工具和相关的案例（均已做隐私处理）以做后续参考。

针对升级包需要做以下的测试：

• 真实性
• 完整性
• 在线升级
• 离线升级

真实性

指官方升级包的签名值和篡改后的升级包位数一致，只是其中部分细节有出入。例如：

Base64
官方包：MIIEpAIBAAKCAQEAu1SU1LfVLPHCYZM6s8LqE2j8rDqHnZxQyW3...
篡改后：MIIEpAIBAAKCAQEAu1SU1LfVLABCDZM6s8LqE2j8rDqHnZxQyW3...

完整性

指篡改后的数据包，常常出现在文件损坏、人为恶意破坏等场景。例如：

Base64
官方包：MIIEpAIBAAKCAQEAu1SU1LfVLPHCYZM6s8LqE2j8rDqHnZxQyW3...
篡改后：MIIEpAIBAAKCAQEAu1SU1LfVLABCDEM6s8LqE2j8rDqHnZxQyW3...

每一个用例都应该有两方面的截图：

• 官方包的升级成功案例
• 官方包的升级过程
• 篡改包的升级失败案例
• 篡改包的升级过程

检测方法

Winhex

Winhex是经典的二进制编辑工具，在这里主要作用篡改软件升级包的签名值。修改完之后需要和未修改前的升级结果作对比。如果上传篡改包，系统升级失败，证明该条例成功。

例如，针对某品牌车辆的软件升级包，可以通过winhex修改里面的参数，随机篡改（真实性）或添加删除（完整性）

真实性——篡改签名包

完整性——篡改数据包

后续将该升级包以OTA方式下载或通过车内物理连接传输至车辆，执行升级；检查记录升级结果即可。

针对不同的ECU的后续结果可能都会不同，但显示的“成功/失败”的结果都可以用作测试报告

车联网软件成分分析平台

一个已通过权威机构的标准符合性测试工具测评平台，一般需要企业购买账号后使用。可以针对厂商提供的软件包进行检测，然后查出是否存在近6个月的安全漏洞。下图是示例图。

具体操作流程很简单，只需要按照指引即可

1. 新建项目
2. 软件包导入
3. 勾选需要扫描的项目
4. 开启扫描

对于部分功能，可能不适用于大型文件（大小超过2GB），这时候可能需要将文件包解压后选取分片再次压缩成小文件才能重新分析。这一部分会相对其他检测更加耗时，甚至需要8个小时以上去检测，一定要注意分配时间，以免错过ddl，耽误了报告和整理公告的时间。

Notepad++

通用的文本编辑软件，具备高度的自定义，安装各种插件满足个人需求。在这里主要用作对数据和签名的修改。

完整性——数据包

真实性——签名包

展示的图片只是用作举例，没有任何实际意义