KL15电和KL30电

KL30 (Battery Positive Terminal)

历史与来源：KL30 最早出现在车辆的基本电气系统中，是最早定义的接点之一。随着电气系统的复杂化，它的功能从简单的电池正极连接发展为关键电源供应端。

详细作用：

永久供电：提供永久电源给重要的设备，比如车载报警系统、车载电脑、锁车系统等，即使在车辆熄火后，这些系统仍然需要供电以保持工作状态或数据存储。

电源管理：通过保险丝和分支电路，KL30 还为多种车载电子设备提供电源。

2、KL15 (Ignition Switch, Positive)6

历史与来源：KL15 是随着汽车点火系统的电气化而引入的，特别是在20世纪中期，车辆开始广泛采用电子点火系统。

详细作用：

启动控制：在点火开关打开后，KL15 向发动机管理系统供电，确保发动机在点火时能顺利启动并运行。

电气设备供电：它还向仪表盘、灯光系统以及其他需要在车辆运行时工作的电器设备提供电力。

就是一句话，就是可以当成信号线。

可以这样理解，摄像头在没有人接近的时候，是一直保持供电状态，即KL30供电，但是低功耗，当有人接近的时候，就会启动该KL15电，就会正常运行。

汽车CAN网络中的checksum和Rollingcounter的作用

Checksum，即CRC校验，8bit，位于报文数据段，用于判断CAN报文传输是否出错，发送方根据特定的检验算法计算CRC校验码并将其置于CAN报文中与报文中的其他信号一同发送至CAN总线，接收方也会根据收到的CAN报文(除CRC检验位)用同样的算法计算出CRC校验码，并将该校验码与接收到的CAN报文中的校验码进行比对，若两者一致，说明报文传输过程未出现错误，否则认为报文传输错误，该报文不可信，同时报CRC检验错误故障码。

checksum是为了防止发送的信息出差。

checksum的判断，连续三帧以上信号的checksum出现问题，可判断的信号的checksum出现问题。

Rolling count，报文计数器，4bit，位于CAN报文数据段，顾名思义，就是发送一条报文计数器加1，用于判断报文传输过程是否出现丢帧，从0累加到15，然后不断循环，其中若出现计数器不连续或首尾值不对，接收方会认为丢帧，同时会报报文丢失或超时故障码。

Rolling counter则是为了防止漏帧。

counter错误的判断，连续五次出现相同的counter值，或连续3次连续两帧之间的counter差值大于2，可判断为counter发生错误

lin线

什么是波特率，lin的波特率怎么测？

串口传输的波特率即为每秒钟传输二进制的位数。

在CANoe中以下红箭头表示的就是lin的波特率。

2.为什么要测波特率？

调节波特率的变化，使主节点同步场位速率变化，验证从节点能否通过同步段进行调节自身位速率。

trace中有波特率的数据表示，能够看到调节前后的变化。波特率越大，应答时间越短。

3.波特率测试注意事项：

CAPL函数linSetBaudrate规定此功能必须在LIN硬件不在主模式下使用，测试使用时注意需要把CANoe Hardware对应通道勾选取消Master mode。

调出此图需要按照以下步骤：

点hardware->network hardware->即可看见。常使用于波特率兼容测试。

4.lin结构

示波器实际波形

++https://blog.csdn.net/weixin_51954443/article/details/127124841?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522f148cab1c0966620a789777c3bb42399%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=f148cab1c0966620a789777c3bb42399&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2allfirst_rank_ecpm_v1~rank_v31_ecpm-4-127124841-null-null.142^v102^control&utm_term=lin%E7%9A%84%E5%B8%A7%E7%BB%93%E6%9E%84&spm=1018.2226.3001.4187++

++https://blog.csdn.net/weixin_43441058/article/details/139647617?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522e9f2cee292c22ea4d2520ddc37ddb2d3%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=e9f2cee292c22ea4d2520ddc37ddb2d3&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~~all~~sobaiduend~default-1-139647617-null-null.142^v102^control&utm_term=lin%E7%9A%84%E5%B8%A7%E7%BB%93%E6%9E%84&spm=1018.2226.3001.4187++

lin网络管理

在一个处于睡眠状态的LIN网络中，任何一个节点都可以发送唤醒信号。唤醒信号是一个250us(在20Kbit/s波特率下的0x0F)到5ms(在1Kbit/s波特率下的0x0F)的显性电平。主机节点的同步间隔段也可以充当唤醒信号，由于从机节点需要作初始化处理，因此主机节点所发的这个帧有可能不会被正常接收。

接收节点检测的唤醒信号(持续150us以上的显性位)。

当所有节点检测到唤醒信号后，在100ms以内完成初始化工作。当从节点发出唤醒信号之后150ms，主节点仍未发送报文，从节点可以再次发送唤醒信号。当连续发送了3次唤醒信号之后如果主节点仍未发送报文，则从节点必须等待1.5s，才可以再次发送唤醒信号。

CAN总线

1.用示波器测波特率方法

使用示波器，找到can线，显示出图像

每一个字节都有起始位+8个比特位+停止位，随便找到其中一个比特位波形，如下：

看这一波形上升沿和下降沿的时间差，比如上图2微秒，波特率是每秒发送的比特位数，所以1s=1000000us，1000000/2=500k的波特率。

也可以采用以下链接的方法

++https://blog.csdn.net/WE_BIG/article/details/146372737?fromshare=blogdetail&sharetype=blogdetail&sharerId=146372737&sharerefer=PC&sharesource=weixin_45871315&sharefrom=from_link++

对于LIN的位时间也是一样的计算，波特率为19200bps，每一位的时间为2微秒，根据每一个字节有8位，并会有起始位和终止位，从而得到一个区间具体的显隐性电平和区间宽度，并从而得到发送的报文数据。

2.什么是全双工，半双工？

当数据的发送和接收分流，分别由两根不同的传输线传送时，通信双方都能在同一时刻进行发送和接收操作，这样的传送方式就是全双工制。

若使用同一根传输线既作接收又作发送，虽然数据可以在两个方向上传送，但通信双方不能同时收发数据，这样的传送方式就是半双工制。

3.什么是同步通信、异步通信？

发送端在发送串行数据的同时，提供一个时钟信号，并按照一定的约定（例如：在时钟信号的上升沿的时候，将数据发送出去）发送数据，接收端根据发送端提供的时钟信号，以及大家的约定，接收数据。比如I2C、SPI这种信号。同步通信中双方使用频率一致的时钟。

异步通信：接收方并不知道数据什么时候会到达，收发双方可以有各自自己的时钟。

异步通信在发送字符时，所发送的字符之间的时间间隔可以是任意的。因为每一帧的数据都有开始和停止位，他们之间的数据位才是实际数据。所以接收方评判数据是否为完整的一帧数据的方式就是分析这一堆数据中的开始位和停止位。发送端可以在任意时刻开始发送字符，接收端必须时刻做好接收的准备。因为每传输一个数据帧都会有一个开始位和一个停止位，实际数据一般只占到5-8位，这就导致了异步通信的传输效率较低。但是要保证波特率相同。

CAN结构

CAN属于异步通信。CAN是一种差分信号，就是CAN_H-CAN_L的电压差，图上目前都是逻辑高逻辑低，只是规定的。

中间必须要有120欧电阻，要不然会出现以下图情况

++https://blog.csdn.net/qq_45868587/article/details/132040807?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522ec00a85526a094ed74b510e764868c8f%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=ec00a85526a094ed74b510e764868c8f&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~~all~~sobaiduend~default-2-132040807-null-null.142^v102^pc_search_result_base8&utm_term=%E6%B5%81%E6%8E%A7%E5%B8%A7%E6%A0%BC%E5%BC%8F&spm=1018.2226.3001.4187++

++https://blog.csdn.net/m0_73633088/article/details/141143872?ops_request_misc=%257B%2522request%255Fid%2522%253A%252241aa3bb5c6e4ddcfeb1baa0d67d517c2%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=41aa3bb5c6e4ddcfeb1baa0d67d517c2&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~~all~~first_rank_ecpm_v1~rank_v31_ecpm-8-141143872-null-null.142^v102^pc_search_result_base8&utm_term=can%E7%9A%84%E5%8D%95%E5%B8%A7%E7%BB%93%E6%9E%84&spm=1018.2226.3001.4187++

4.1CAN矩阵

CAN的数据场是先发送报文数据其中一字节的高位，再发低位。在CAN通信矩阵定义时，报文编码格式有Intel小端和Motorola大端两种

Intel小端传输：LSB在低字节的低位，MSB在高字节的高位

Motorola：LSB在高字节的低位，MSB在低字节的高位

++https://blog.csdn.net/weixin_43441058/article/details/139615058?ops_request_misc=&request_id=&biz_id=102&utm_term=motorola%E5%92%8Cintel%E5%8C%BA%E5%88%AB&utm_medium=distribute.pc_search_result.none-task-blog-2~~all~~sobaiduweb~default-0-139615058.142^v102^pc_search_result_base6&spm=1018.2226.3001.4187++

什么是Busoff

Bus Off就是总线关闭，总线为什么会出现Bus Off？其实这和CAN总线的错误处理机制有关。

ECU在向CAN总线发送消息时，出现发送失败。此时，ECU每发送失败一次，发送错误计数器就会累加，如果发送错误计数器的值累计达到最大阈值时，ECU会进入Bus Off模式。

Busoff的出现主要是为避免CAN总线上某个设备因为自身原因（例如硬件故障）导致无法正确收发报文而不断的破坏总线的数据帧，从而影响其他正常节点的通信。

当总线出现Bus Off后，会有一些恢复措施，最常用的就是快恢复和慢恢复的方法；所谓快恢复，就是产生Bus Off后，ECU尝试恢复发送报文，此时的发送周期通常为50ms左右，一般快恢复5次，如果发送成功，则Bus Off解除，否则进入慢恢复机制，通常慢恢复的时间为200ms。

CANNM网络管理

AUTOSAR网络管理节点内部有两个状态，一个是Requested - 被请求状态，另一个是Released - 被释放状态，当节点的应用层需要使用总线进行通讯的时候，会调用接口使得节点进入请求状态，当应用层没有通信需求的时候，调用接口使得节点进入释放状态。

需要注意的是，即使节点当前处于释放状态，节点的通讯依然有可能是处于开启状态，因为网络上的其它节点有可能正在请求总线。所以这个状态代表的是节点应用层是否有通信需求，并不代表总线开启或关闭。有通讯需求的时候处于请求状态，无通讯需求的时候处于释放，但总线是否在通讯不仅仅取决于当前节点自己，而是取决于网络上的所有节点。

用来做什么的？

一个最重要的作用就是为了省电。

UDS诊断

首先介绍一下UDS，UDS(unified diagnostic service)也叫统一诊断服务，它主要功能是诊断仪（Tester）向ECU发送诊断请求(Diagnostic request),ECU收到请求后向诊断仪给出诊断响应（Diagnostic response）的过程，也就是诊断通信的过程。其中请求和响应的内容和格式由ISO-14229定义同i标准，ISO 14229定义了诊断服务以及UDS在CAN总线上的实现。

诊断请求格式：

介绍一下请求格式中各位的含意：

Service ID: 简称SID，表示诊断请求的功能，占1byte的固定长度。

sub-function:表示诊断服务的子服务，可以理解为诊断请求的子功能，比如表示开启或者停止该诊断请求的功能等，占1byte的固定长度。其中sub-function的最高位表示肯定响应抑制位，剩下的7个bit才表示sub-function。如果最高位置为1，表示肯定响应抑制，那么ECU收到这条请求，不会做出肯定响应；如果最高位置为0那么ECU必须对该请求做出肯定响应。比如ECU再收到10 01、3E 00、85 02等诊断请求之后，必须做出肯定响应，而收到10 81、3E 80等诊断请求之后，不会作出肯定响应。响应抑制的原因是减少ECU不必要的肯定响应，节约通信资源！！

Parameter:诊断请求的参数，对不同诊断服务，Parameter的长度、内容、格式等通常都会不同。Parameter的内容可以作为标识符(CAN仲裁域的标识部分),表示诊断请求读取或者传递的数据参数。Parameter还可以表示诊断服务的限制条件，比如时间参数等等。

在UDS协议中，ServiceID(SID)是指服务标识符，用于标识要执行的服务。每个服务都有一个唯一的SID，在诊断会话中通过SID来区分要执行/响应哪种服务请求。

UDS报文 = 应用层（服务） + 传输层（ISO-TP） + 物理层（CAN）

肯定响应和否定响应的区别？

比如

可以在软件中这么写

10 服务（诊断会话控制）

诊断会话：可以将其理解为访问UDS服务的前提条件

用于启用服务器中的不同诊断会话

服务器中应该始终只有一个有效的诊断会话
服务器上电时应始终启动默认会话
该服务是在服务器端使能不同的会话模式，而诊断会话模式在服务器中用于启用一组特定的服务或者功能（e.g.刷写）。可以通过会话模式赋予不同诊断服务的执行权限。
无论何时客户端请求一个新的诊断会话，服务器均应在新会话的计时在服务器中激活之前发送DiagnosticSessionControl（诊断会话控制）肯定响应消息。
非默认诊断会话（programmingSession（编程会话）除外）中的诊断服务和诊断功能集是 defaultSession（默认会话）中提供的功能超集，这意味着切换到任何非默认诊断会话时还可以使用defaultSession（默认会话）的诊断功能。

UDS协议中定义了三个常用诊断会话：Default、Programming、Extern，其中将Default Session之外的会话模式统称为非默认会话，用户也可以自定义诊断会话；

通过会话模式赋予不同诊断服务不同的执行权限。

++https://blog.csdn.net/m0_67883547/article/details/146097147?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522cab1659e20febef580003d7d243fde7c%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=cab1659e20febef580003d7d243fde7c&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~~all~~first_rank_ecpm_v1~rank_v31_ecpm-1-146097147-null-null.142^v102^pc_search_result_base8&utm_term=uds%E4%B8%AD10%E5%AD%90%E6%9C%8D%E5%8A%A1&spm=1018.2226.3001.4187++

++https://blog.csdn.net/m0_56208280/article/details/134843388?ops_request_misc=&request_id=&biz_id=102&utm_term=uds%E4%B8%AD10%E5%AD%90%E6%9C%8D%E5%8A%A1&utm_medium=distribute.pc_search_result.none-task-blog-2~~all~~sobaiduweb~default-0-134843388.142^v102^pc_search_result_base8&spm=1018.2226.3001.4187++

注意肯定相应和否定相应，否定相应中的NRC优先级。

10服务是UDS诊断的基础，几乎所有其他诊断服务都依赖于适当的会话模式设置。

27（安全访问）

27服务，即 SecurityAccess（安全访问）服务，安全理念采用的是种子与密钥式关系。

针对27服务的安全解锁的过程是基于Seed-Key 机制来实现，具体过程可分为以下四个阶段：

1.Client向Server请求种子；

2.Server向Client发送随机种子；

3.Client基于接收到来自Server的随机种子计算出对应的Key并发送给到Server；

Server接受来自Client算出来的Key并与内部算出的Key比较，如果一致则解锁成功，否则解锁不成功；

简单来说，不同安全级别的请求种子和发送密钥是一一对应的，相邻的一对奇偶数对应一种安全级别，其中奇数代表请求种子，偶数代表发送密钥，例如：

0x01 和 0x02 分别代表一个安全级别的请求种子和发送密钥

0x03 和 0x04 分别代表另一个安全级别的请求种子和发送密钥

注意

1、请求种子和发送密钥的数字大小并不代表其等级的高低。

2、同一时刻最多只能有一个安全等级是解锁的状态，因此从一个安全等级接收到另外一个等级的请求并且解锁成功后，之前的安全等级将被重新锁定，而由于切换安全等级致使先前解锁的状态被锁定后，其依赖于被锁定的等级的服务和功能也一并被关闭。

3、如果被请求的安全等级当前是已经解锁的状态，那么在响应种子时，在放种子的位置都放上0，表示已经解锁了，你不要再请求了。并且实际上种子应该是一个随机数，一般全0和全F都不允许作为普通种子放到响应里。

延时机制

在连续N次请求安全访问失败后，需等待T s之后才能接受下一次的安全访问请求 RequestSeed。

1、当测试工具发送一个无效的秘钥， ECU将返回 NRC35 InvalidKey 。同时，安全访问错误计数器加1。该计数器需要存储并且初始值为0。

2、当安全访问错误计数器达到N（即收到N次无效密钥）， ECU将返回NRC36且需要等待Ts才能接受下一次的安全访问请求Request Seed。期间任何安全访问请求Request Seed都会被ECU反馈NRC37。

当T s等待时间结束后，安全访问错误计数器将减1(只减1次)，并允许尝试安全访问请求 RequestSeed，如果此次请求失败（由于发送了一个无效的秘钥），安全访问错误计数器将加1，并再次开启T s等待时间。任何一次ECU被成功解锁（密钥有效），失败计数器都将被重置为零。

ECU上电/复位后默认处于闭锁状态，需要检测安全访问错误计数器，若计数器为N，则需要启动T s的安全访问延时时间。

++https://blog.csdn.net/m0_56208280/article/details/135206597?ops_request_misc=&request_id=&biz_id=102&utm_term=uds%E4%B8%AD27%E5%AD%90%E6%9C%8D%E5%8A%A1&utm_medium=distribute.pc_search_result.none-task-blog-2~~all~~sobaiduweb~default-0-135206597.142^v102^pc_search_result_base8&spm=1018.2226.3001.4187++

0x27服务解锁ECU。诊断仪（Tester）需要先向ECU发送请求种子，种子就是ECU通过自己内部的随机算法，生成的一个随机的数值，常见的有两个字节，四个字节。然后ECU就会把生成的这个种子作为本次诊断的响应，返回种子给诊断仪（Tester）。同时ECU也会用安全算法，根据种子计算出一个钥匙（key），以便后面去进行验证。诊断仪也会用同样的安全算法，根据ECU返回的种子去计算一个钥匙（key）。接着诊断仪就会把这个key作为第二阶段的请求，再发送给ECU，让ECU去进行验证。ECU收到了诊断仪发出的key会跟它自己计算出的key进行对比。如果对比相同，则返回肯定响应；对不不同，则返回否定响应。

在测试的过程中，如果要测试27安全访问，要发送种子，要ECU接受然后响应。如果不需要上位机二次请求，需要把软件的指定位置删除掉。

19（读取故障码信息）

主要读取ECU上的故障状态信息，例如出现系统故障或者Bus-off故障，当故障发生的时候可以保留当前里程、电压、时间、速度等数据，用于定位分析问题。

DTC

DTC全称（Diagnostic Trouble Code）即诊断故障码，它是由车载诊断系统识别的故障状态的数字通用标识符。

如果车出现了故障时，维修人员可以通过专业的诊断仪器直接读取出当前车辆的故障码。他们之所以能读出故障码是因为汽车的车载控制器会时刻监控汽车的运行情况，在发现汽车故障的时候会将相关信息进行存储，维修人员通过诊断仪向汽车发送19服务（请求读取故障信息）的请求，车载控制器就会反馈对应的故障信息，而故障码DTC就是这些故障信息的身份ID。

DID

在UDS（统一诊断服务，ISO 14229）协议中，DID（Data Identifier，数据标识符）是一个用于唯一标识ECU（电子控制单元）内部特定数据或功能的2字节（16位）编码。它相当于诊断访问的“数据地址”，允许诊断仪（Tester）通过标准化的服务（如0x22读DID、0x2E写DID）读取或修改ECU内部的参数、状态或配置信息。

DID是诊断仪与ECU交互数据的桥梁，通过DID可以访问：

1.动态数据（如传感器实时值、故障计数器）。

2.静态数据（如ECU零件号、软件版本）。

3.配置参数（如标定值、功能开关）。

读取ECU信息的是0x22,修改参数的是0x2E,比如此测试项目

比如此测试项目

可以进行先读取22 F1 90，然后得到

再写入2E F1 90 —

快照

在UDS（统一诊断服务）和汽车诊断领域，快照（Snapshot）是ECU在检测到故障码（DTC）触发时，自动记录的一组关键运行参数和状态信息的集合，也称为冻结帧（Freeze Frame）。它相当于故障发生时的“黑匣子记录”，帮助工程师复现故障场景并分析根本原因。

++https://blog.csdn.net/LOVE135149/article/details/123004667++

功能寻址和物理寻址的区别？

功能寻址（Functional Addressing）

定义：功能寻址是一种广播式通信方式，消息发送给网络中的所有ECU，而不是特定的某个ECU。

目的：用于同时向多个ECU发送相同的诊断请求，适用于需要多个ECU协同操作的场景。

地址范围：功能寻址通常使用特定的功能地址（如0x7DF），所有ECU都会监听该地址。

应用场景：

同时读取多个ECU的故障码。

同时复位多个ECU的故障码。

同时请求多个ECU的状态信息。

优点：高效，减少通信负载，适用于批量操作。

缺点：无法针对单个ECU进行特定操作。

物理寻址（Physical Addressing）

定义：物理寻址是一种点对点通信方式，消息发送给特定的某个ECU。

目的：用于与单个ECU进行诊断通信，适用于需要精确控制或读取特定ECU信息的场景。

地址范围：物理寻址使用ECU的唯一物理地址（如0x7E0、0x7E1等），只有目标ECU会响应。

应用场景：

读取特定ECU的故障码。

写入特定ECU的配置参数。

执行特定ECU的诊断例程。

优点：精准，适用于对单个ECU的操作。

缺点：通信负载较高，尤其是在需要与多个ECU通信时。

8.ECU、EMS、VCU、BMS等区别？

ECU（Electronic Control Unit）电子控制器单元，又称汽车的“行车电脑”，它们的用途就是控制汽车的行驶状态及实现其各种功能。主要利用各种传感器、总线的数据采集与交换，来判断车辆状态及司机的意图并通过执行器来操控汽车。

EMS（Engine Mangement System）发动机管理系统，应用在包括汽油机PFI（如上图）、GDI，柴油机，混合动力系统等，主要控制发动机的喷油、点火、扭矩分配等功能。

TCU（Transmision Control Unit）自动变速箱控制单元，常用于AMT、AT、DCT、CVT等自动变速器中，根据车辆的驾驶状态采用不同的档位策略。

BCM（Body Control Module）车身控制模块，主要控制车身电器，比如整车灯具、雨刮、洗涤、门锁、电动窗、天窗、电动后视镜、遥控等。

ESP（Electronic Stability Program）车身电子稳定控制系统。ESP可使车辆在各种状况下保持最佳的稳定性，在转向过度或转向不足的情形下效果更加明显。ESP是博世公司的专门叫法，日产的车辆行驶动力学调整系统VDC，丰田的车辆稳定控制系统VSC，宝马的动态稳定控制系统DSC等。现如今很多中高端合资车、国产车都会配备这个模块。

BMS（Battery Management System）电池管理系统，此控制器是专门针对配备有动力电池的电动车或者混合动力车准备的。主要功能就是为提高电池的利用率，防止电池出现过度充电和放电，延长电池的使用寿命，监控电池状态。

VCU（Vehicle Control Unit）整车控制器，用于混合动力/纯电动汽车动力系统的总成控制器，负责协调发动机、驱动电机、变速箱、动力电池等各部件的工作，提高新能源汽车的经济性、动力性、安全性并降低排放污染。

UDS诊断中经常遇到的简称都是什么意思

FBL：https://blog.csdn.net/LIAOYUANGANG/article/details/124551348

DBC详解

DBC文件是用来描述CAN网络通信信号的一种格式文件。它可以用来监测与分析CAN网络上的报文数据，也可以用来模拟某个CAN节点。

报文中增强型校验和经典型校验的区别

经典校验

对报文中的数据按固定长度（如16位、32位）分段求和，最终取补码或反码作为校验值。

特点：
- 计算简单：适合硬件快速实现。
- 检测能力弱：
  - 只能检测单比特错误或部分随机错误。
  - 无法检测数据顺序交换（如两个字节位置对调）。
- 轻量级：常用于实时性要求高的场景（如网络协议头部校验）。

增强型校验

使用更复杂的算法（如CRC、哈希函数）生成校验值，显著提高错误检测率。

特点：
- 高检测能力：
  - 可检测多比特错误、突发错误、数据顺序错误等。
  - CRC能识别几乎所有≤校验位长度的突发错误。
- 抗篡改：哈希函数（如SHA-256）可防止恶意修改。
- 计算开销较高：适合对可靠性要求严格的场景。

在进行CRC校验时，可以通过

++https://linchecksumcalculator.machsystems.cz/++

进行CRC校验，如

通讯矩阵

位置：TCM-003F\SW\trunk\Doc08.ST](http://08.ST)\udsCanoePro\03_Dbc\通讯矩阵_SOP\udsCanoePro\03_Dbc\通讯矩阵_SOP)

BootLoader刷写

主函数在

bootloader 刷新流程数据流在：

地址：D:\svn\TCM-003\PM\00_客户相关\001_技术输入\软件规范

CANdelaStudio、CANdesc、CANbedded分别是什么？

CANdelaStudio用于诊断数据库（CDD/ODX）开发，支持符合 UDS（ISO 14229）和 OBD（ISO 15031）标准的诊断协议。

主要功能：

1.定义 ECU 诊断服务（如读故障码、刷写软件、读取数据流等）。

2.生成诊断描述文件（CDD、ODX），供 CANoe/CANape 等工具使用。

3.支持 AUTOSAR 诊断（DEXT）开发。

CANdesc定义 CAN 网络通信矩阵，描述 ECU 之间的报文和信号。

常见格式：

1.DBC 文件（CANoe、CANalyzer 使用）。

2.ARXML（AUTOSAR 标准格式）。

3.Excel/CSV（部分OEM使用）。

主要功能：

1.定义 CAN 报文（Message）、信号（Signal）及其属性（ID、周期、数据长度等）。

2.用于 ECU 通信开发、仿真测试（CANoe）和总线监控。

CANbedded：AUTOSAR 标准下的 CAN 协议栈，用于 ECU 软件开发。

主要功能：

1.提供符合AUTOSAR标准的CAN Driver、CAN Interface、CAN Transport Layer（CAN TP）。

2.支持CAN FD、CAN XL等新型总线协议。

3.与MICROSAR（Vector 的 AUTOSAR 基础软件）集成。

典型应用：

1.汽车ECU（如发动机控制、车身控制）的 CAN 通信底层软件开发。

2.用于 AUTOSAR CP（Classic Platform）项目。

协作流程示例：

1.OEM 使用 CANdesc（DBC/ARXML）定义CAN通信协议。

2.供应商使用 CANbedded 实现 ECU 的 CAN 通信（AUTOSAR）。

3.使用 CANdelaStudio 定义诊断服务，生成CDD/ODX供测试使用。

用 CANoe/CANalyzer 结合DBC和CDD进行测试。

CDD是什么

CANdela诊断描述（CANdela Diagnostic Descriptions，CDD）文件是诊断数据的数据库，与用于CAN消息和信号描述文件DBC（Data Base CAN）文件相当。

与CANdelaStudio的联系

汽车电子范畴内，经典的V-L模型：虚线上方表示OEM主机厂，虚线下发表示供应商。主机厂首先提出诊断需求规范，供应商基于诊断需求规范做功能实现，功能实现完后，会进行集成测试，测试的目的是验证功能实现是否是按照需求规范进行实现的。L模型在主机厂方，后有一些研发。在研发阶段，量产阶段，以及售后阶段的不同阶段，使用的诊断数据是一致的。

诊断数据在整个流程是怎样的体现

首先，用“CANdelaStudio”工具基于诊断需求规范来编辑生成一个CDD数据库；CDD数据库生成后，供应商会进行功能实现。

++https://blog.csdn.net/qfmzhu/article/details/106519211?ops_request_misc=&request_id=&biz_id=102&utm_term=CANdesc&utm_medium=distribute.pc_search_result.none-task-blog-2~~all~~sobaiduweb~default-3-106519211.142^v102^pc_search_result_base8&spm=1018.2226.3001.4187++

CANdelaStudio用于编辑机器可读的诊断数据库CDD文件的工具，在编辑CDD文件的时候我们需要有一个Template，也就是CDDt来保证我们CDD文件的一个有效性。

CDDt所对应的其实是主机厂提供的一个整车级别的诊断需求规范，而每一个CDD文件对应的是每一个ECU的一个诊断需求规范，所以CDDt通常会有两种可能，第1种，有一些主机厂向Vector定制了他们相对应的这个CDDt文件，或者他们自己有自己编辑好的这个相对应的CDDt文件，他可以直接释放给系统供应商去编辑CDD文件，另外也会有一些主机厂，它不提供CDDt文件。

所以Vector CANdelaStudio工具里面会自带这个Vector标准的一个CDDt文件，那么，在用户在编辑的时候，可以基于Vector标准的CDDt文件去编辑自己需要的CDDt，然后再建立自己需要的一个CDD文件。

我们建议在开发阶段使用CDD文件，而在生产后售后阶段使用ODX文件，为什么会有这样的建议呢，我们在开发阶段数据会一直变动，或者说我们的数据库文件会一直需要不断的进行修改，那相较于ODX文件，CDD文件是面向工程性的，所以它的可编辑性更强，而且行业内大部分人对CDD文件还是比较熟悉的，所以它编辑起来会更简单更容易一些，而到了我们生产售后阶段，我们可能会有不同的Tester的一个应用，那么这个时候我们需要一种国际标准的格式能够被不同的Tester去进行使用，去进行调用，那么这个时候我们就可以选择从前期开发阶段的CDD文件导出相对应的ODX文件，来应用到我们生产和售后阶段，然后适应我们不同Tester的需求。

DIVA是什么

DIVA 主要用于汽车诊断协议（如UDS、OBD）的自动化测试，帮助工程师高效验证ECU的诊断功能是否符合标准。

核心功能：

自动化诊断测试：支持 UDS和OBD协议测试；可自动执行诊断请求，并验证ECU的响应是否符合规范。
基于ODX/CDD的测试：直接导入诊断数据库，自动生成测试用例；无需手动编写测试脚本，提高测试效率。
回归测试与持续集成：支持批量执行测试用例，适用于ECU软件迭代测试；可与 Jenkins 等CI工具集成，实现自动化测试流水线。
测试报告生成：自动生成详细的测试报告，记录通过/失败的测试项，便于问题追踪。

链接脚本

链接脚本是一个由链接器使用的文件，用于控制程序的内存布局和如何将各种代码和数据段映射到目标文件。它可以让你精细控制程序在内存中的布局，非常适用于资源受限的嵌入式系统。

链接脚本可以帮助你管理和优化程序的内存使用，确保代码和数据被放置在正确的位置，避免冲突和溢出问题，这对于确保程序的正确运行是非常重要的。

在嵌入式系统中，资源通常非常有限，链接脚本可以帮你最大限度地利用这些资源，同时也可以为你的代码提供必要的保护和安全措施。

ELF(Executable and Linkable Format)是一种常用的可执行文件格式。它包含了程序的代码、数据、符号表等信息，可以帮助链接器正确地组合各个代码和数据段。

组成部分：

1.MEMORY区块的定义和属性；

SECTIONS的定义及其内部段的详解 (.text, .data, .bss等)；

.text：存放程序代码和常量数据。

.data：存放已初始化的全局和静态变量。

.bss：存放未初始化的全局和静态变量。

符号定义

在链接脚本中，我们可以定义符号来表示特定的地址或值，这样可以在我们的程序中使用它们。

内存分配策略

在软件开发过程中, 内存分配是一个核心和基本的主题。理解不同的内存分配策略可以帮助你更有效地管理程序的资源。我们将探讨两种主要的内存分配策略: 静态内存分配和动态内存分配，以及它们在栈和堆中的运用。

++https://zhuanlan.zhihu.com/p/656259964++

ISO CANFD与Non-ISO CANFD

ISO CAN FD和非ISO CAN FD（也称为Bosch CAN FD）是两种不同的CAN FD协议标准。它们之间的主要区别在于它们在设计和实现时所遵循的规范不同。

标准化和兼容性：

ISO CAN FD 是根据国际标准组织（ISO）的ISO 11898-1:2015标准制定的。这个标准是在2012年由Bosch公司和其他行业专家共同研发的CAN FD协议的基础上进一步标准化的结果。ISO CAN FD的引入，使得CAN FD协议能够在全球范围内得到统一的实施和应用。

非ISO CAN FD 是由Bosch公司预研开发，但并未完全遵循ISO标准。这个版本的CAN FD在某些实现细节上与ISO CAN FD存在差异，导致两者之间存在不兼容性。

CAN与LIN路由

先将CAN、LIN的通信打开，LIN用LDF视图打开，CAN用DBC视图打开

也可以看表格。

通过看表格和视图中的点击小箭头出现的信号名称，来输入数据来观察CAN、LIN信号的数据是否一样。

调出LIN发送数据方框

调出CANBDC发送方框

点击DBC发送，然后出现

通过改变对应信号数值进行信号的发送。

EMC是什么

EMC（电磁兼容）是指电子、电气设备或系统在预期的电磁环境中，不会因为周边的电磁环境而导致性能降低、功能丧失或损坏，也不会在周边环境中产生过量的电磁能量，以致影响周边设备的正常工作。

什么是伪随机数，什么是真随机数？

伪随机数是通过确定性算法生成的数列，看起来像是随机的，但实际上是根据初始值（种子）经过数学运算得到的。尽管伪随机数生成算法的输出序列在某些方面表现得像随机数，但在理论上是可预测的。

真随机数是从物理过程中获得的随机性数据。它们不是通过算法生成的，而是基于随机事件，如热噪声、放射性衰变、光子计数等，产生的数字。真随机数在理论上是不可预测的，因为它们源自不可预测的自然现象。

由于真随机数是从物理事件中获取的，所以在一些需要高度随机性和安全性的应用中，如密码学中的加密密钥生成，需要使用真随机数来避免伪随机数可能存在的可预测性问题。

CSE功能与使用

CSE是硬件加密模块，是芯片内部接口

CES开启后直接将数据放入RAM中，将DFLASH后64KB区域分区域给CSE。通过上图可知道CPU通过PRAM进行使用CSE接口，PRAM是一段连续的寄存器地址，由8个页组成，每页128位。PRAM的起始地址为0x14001000。应用程序通过 PRAM 接口来执行 CSE 模块相关命令。PRAM 第一个页总是从命令头开始，这必须是写入 PRAM 的数据序列中写入的最后一个数据，因为写入命令头会触发锁定 PRAM 接口，导致 CSE 命令开始执行。所以，要发送 CSE 命令前，应当首先输入数据信息，然后输入数据消息长度信息，最后写入命令头，触发 CSE 操作。

其中命令头格式为：