1. 被测对象先看清LIN帧在示波器上的七个可测量片段做LIN协议测试的人十个里有八个是从接上分析仪、打开报文窗口、看数据对不对这一步开始的然后一遇到偶发错误就抓瞎因为手边只有一堆十六进制报文根本不知道总线上的电平到底长什么样。我在车上第一次调车门模块的时候就吃过这个亏分析仪显示校验和错误我改了三天软件最后发现是从节点晶振在低温下飘得太厉害同步场没把它拉回来。所以这篇东西不讲怎么点按钮先讲清楚LIN帧在物理层上到底由哪些片段组成每个片段的测试意义是什么。LIN是单线、主从、时间触发调度的低成本总线走的是一根线加车身地波特率典型值从2400bps到20kbps常用9600和19200。它的帧结构比CAN简单得多但简单不等于好测因为它的时钟基准完全依赖主机每一帧重新广播的同步场从机每次都要重新校准。这就决定了LIN协议测试的核心不是数据对不对而是时序余量够不够。一帧完整的LIN报文从示波器上看可以切成七段同步间隔场Break、间隔场分隔符Delimiter、同步场Sync固定0x55、受保护标识符PID、响应空间里的数据字节1到8个、校验和Checksum、以及帧与帧之间的间隔。测试点基本就挂在这七段上。下面几节按哪一段最容易出问题、出了问题怎么量来展开。1.1 同步间隔场与同步场位时间的唯一权威基准同步间隔场是LIN帧的起点规定是至少13个连续显性位后面跟至少1个隐性位的分隔符。很多测试新手只看分析仪能不能解出报文却从不测这个13位到底够不够结果就是某些UART实现严格按11位连续显性才认Break来设计主机发的Break只要被中断打断、少了那么一两个位从机就直接开始等下一帧。我在用某款国产MCU做从节点时就遇到过主机换成另一个供应商的模块后从节点偶发丢帧拿示波器一看Break只有12位宽卡在设计边界上。测量方法很直接把示波器触发设在LIN总线的下降沿时基调到5us/格19200bps时一位约52us数Break的显性宽度再数分隔符的隐性宽度。判据是Break的显性时间不小于13倍标称位时间留5%到10%余量更稳分隔符不小于1位。这里有个细节LIN规范允许Break更长但过长会影响下一帧的调度余量所以测试报告里要把实测范围写清楚而不是只写合格。同步场固定是0x55即01010101加上起始位形成一串规整的方波。它是从节点计算位时间的唯一依据从节点用起始位下降沿到最后一个数据位的上升沿取8个位时间实际实现常取同步场内的下降沿间隔之和算出自己的波特率分频然后整帧都用这个值采样。所以同步场测试的重点是边沿是否干净和占空比是否接近50%。如果总线电容太大、上拉电阻偏大同步场的上升沿会被拉长从节点算出来的位时间偏大后面采样点整体后移最终表现就是高波特率下间歇性校验错误。实测经验在19200bps下用4.7kΩ上拉、总线长度超过10米、挂6个从节点时同步场上升沿能达到8到10us占空比明显偏离。这时候要么减小上拉电阻注意不能小于1kΩ否则显性电流太大要么降低波特率。这个取舍必须在测试阶段用数据说话不能靠应该没问题。1.2 受保护标识符ID与奇偶位最容易写错的六位PID是6位帧ID加2位奇偶校验组成的一个字节。6位ID的范围是0x00到0x3F其中0x3C和0x3D留给诊断主请求帧和诊断从响应帧0x3E留给用户自定义0x3F保留。奇偶位的计算规则是P0等于ID0、ID1、ID2、ID4的异或P1等于ID1、ID3、ID4、ID5异或后再取反。注意第二个是取反我第一次实现的时候就栽在这儿写成了不取反结果所有PID位都反了从节点全部不应答。测试的时候不要只对报文ID要单独验证PID字节。用示波器解码或者抓分析仪的裸字节把6位ID和两位校验位拆出来手工核一遍。批量测试可以写个脚本给定ID范围0x00到0x3F枚举出所有合法PID跟实测值做集合比对。这样能一次性发现奇偶位算法错误比逐帧抓报文高效得多。另一个坑是ID规划冲突。两个不同的信号如果被分配到同一个ID主机调度表里就会出现两处引用同一ID的帧从节点不知道该响应哪个总线上的实际行为是谁先被调度谁应答表现是某一帧的数据偶尔串到另一个信号上。测试用例里应该包含一个ID唯一性检查把LDF文件里的帧定义全部导出来做重复检测这个动作很多人会漏。1.3 响应与校验和经典与增强的岔路口校验和是LIN协议测试里最容易出看起来对、实际错的地方。LIN 1.3用经典校验和只把数据字节求和取反LIN 2.x用增强校验和把PID也算进求和。两条规则并存节点手册里写支持LIN 2.1不代表所有帧都用增强校验和——诊断帧0x3C和0x3D永远用经典校验和这条是硬规定不随协议版本变。我见过一个项目诊断功能在实验室里怎么调都不通最后发现从节点的诊断响应帧按增强校验和算主机按经典算两边都没错就是算不到一块儿去。测试方法准备两组期望值普通数据帧按增强算诊断帧按经典算写进测试脚本自动比对。更稳的做法是在分析仪里配置校验和类型时明确区分帧类型不要图省事全局设成一种。响应空间的长度由LDF决定1到8字节。测试要覆盖边界最短1字节和最长8字节。长度错误在物理层上的表现很有意思——如果从节点发的字节数比主机期望的多多出来的字节会被主机当成下一帧的开始整个调度表错位。这种错误不会报帧错误只会表现为下一帧怎么突然不对了所以测试用例里必须有一项专门验证响应长度严格匹配。1.4 帧间隔与总线空闲调度表能不能跑通的隐性条件帧间隔指的是上一帧校验和结束到下一帧Break开始之间的时间。这个值不是随便定的它由调度表的时间槽决定。测试时要在示波器上量每一帧的实际起点和标称起点的偏差把所有帧的偏差画成一张趋势图。如果发现偏差是单调递增的说明主机时基有问题如果是随机跳变说明有从节点响应拖尾。总线空闲状态是隐性电平。如果测到总线在空闲时是显性说明有节点在持续拉低要么是收发器坏了要么是软件把TX脚一直拉低要么是某个从节点进入了错误状态。这个现象在整车路试里很常见尤其是在唤醒阶段某个节点唤醒后没进正常通信就死拉总线导致整个网段瘫痪。测试用例里要加一项唤醒后总线空闲电平检测用万用表或者示波器直流耦合看判据是空闲电平接近电池电压而不是0V。2. 主从调度的时序测试单帧通、整表崩的根因在哪调LIN最典型的现象就是单帧发得好好的整张调度表跑起来就丢帧。原因在于LIN不是事件驱动的总线主机按固定时间槽轮询每一帧都有自己的预算时间超了就得让位。测试要做的不是看某一帧对不对而是看时间槽的利用率。我在一个座椅模块项目里统计过整表最紧张的那一帧用掉了标称时间的92%常温下没问题一到零下二十度从节点晶振变慢直接超时丢帧。如果你只做常温单帧测试这个坑永远发现不了。2.1 帧时隙的标称值与1.4倍余量LIN规范里给帧时隙留了余量最大帧时间等于标称帧时间的1.4倍。这个1.4倍不是拍脑袋定的它覆盖了从节点时钟漂移典型±14%、主机时基精度±0.5%、以及收发器传播延迟的总和。测试时的判据应该是实测帧时间不超过标称值的1.3倍留一点安全边际且整表的最坏帧与下一个时间槽起点之间至少有10%的空闲。计算标称帧时间有个常用公式核心变量是位时间、帧内总位数含Break、Sync、PID、数据、校验和、以及各段的字节间延迟和响应空间长度。字节间延迟不是零收发器在字节之间会有几个位时间的处理延迟19200bps下大约1到3个位时间。测试报告里要把这个延迟实测出来代入不然算出来的标称值会比实际乐观。我一般会用一个Excel或者脚本把整张调度表的每一帧排出来列出标称时间、1.4倍上限、实测平均、实测最大、以及余量百分比。真正做到量产阶段这张表是排查偶发丢帧的第一份材料。2.2 抖动从哪里来主节点精度、从节点唤醒延迟、收发器斜率抖动的三大来源要分开测。主节点精度用主节点的时钟输出或者示波器长时基观察帧起点优秀实现能控制在±0.5%以内。从节点唤醒延迟指的是从节点从收到Break到开始驱动响应空间的时间这个延迟在数据手册里通常不给得实测。方法是双通道示波器一路看Break下降沿一路看从节点响应第一个字节的起始位下降沿两者之差就是唤醒延迟典型值几十微秒。收发器斜率是可配置的很多LIN收发器有正常模式和低斜率模式两档低斜率模式为了压EMI上升下降沿会变缓长线束下更明显。测试时要在最恶劣的线束配置最长、最多节点、最高温度下测同步场占空比和响应空间的边沿把收发器斜率配置和实测波形一一对应记录下来。这份数据在后期做EMC整改时非常值钱。实测心得抖动大的时候先别怀疑软件先看从节点的供电和晶振。我遇到过一批模块从节点用内部RC振荡器常温下能跑装车后温度上到85度RC频率飘了3%同步场拉不回来直接丢帧。换成外部晶振立刻好了。这个教训写进测试用例就是从节点时钟源必须做全温区波特率实测。2.3 响应超时判定与重试策略的实测边界从节点如果在规定时间内没把响应空间填满主机就要做超时处理。LIN没有硬件级的应答机制超时全靠软件定时。测试要验证的是主机超时阈值设得合不合理。设太短正常从节点的响应延迟就被误判为超时设太长一帧卡住会拖垮后面的调度。合理的做法是用实测的最坏响应延迟乘以1.5到2倍作为阈值并且超时后不要立即重试同一帧而是跳到下一帧等下一轮调度再重试。原因是从节点的异常往往需要时间恢复连续重试只会把总线占满。重试策略的测试要用故障注入来做人为让某个从节点在若干帧内不应答观察主机的行为是否符合设计跳过、计数、恢复。这部分很多团队只在代码里写了从没测过等到车上真出问题才发现重试逻辑会把整张调度表挤垮。3. 诊断帧测试0x3C/0x3D通道上的那些坑LIN诊断是基于0x3C主机请求帧和0x3D从节点响应帧两条固定ID走的传输层协议上面载的是UDS服务。它的测试难度比普通数据帧高一档因为涉及多帧分段、流控和会话状态。诊断测试做不透量产下线检测和售后诊断都会出问题。3.1 诊断帧为什么永远用经典校验和前面提过0x3C和0x3D强制使用经典校验和即使节点声明支持LIN 2.x。这条规则的测试验证要单独做构造一帧诊断请求手工算出经典校验和的值跟总线上实测的校验和字节比对。如果发现用的是增强校验和说明从节点或者主机实现有缺陷必须改。顺带一个容易忽略的点诊断帧的数据长度固定为8字节不足的要填充。填充字节通常是0xFF但填充值本身不参与语义只参与校验和计算。测试时要确认填充值在全网一致因为有些分析工具默认用0x00填充混用会导致校验和算错。3.2 传输层PCI与多帧时序STmin、N_As、N_Cr的LIN映射诊断报文超过6字节就要分段传输层的首帧、连续帧、流控帧的PCI编码和CAN上的UDS类似但不完全一样。LIN诊断的时序参数包括N_As发送方发出后等确认的时间、N_Cr接收方等待下一帧的时间和STmin连续帧最小间隔。这些值在LIN上通常放宽因为总线速率低。测试时要做的是发一条需要分3段以上的长诊断请求抓完整时序量首帧到流控帧、流控帧到第一个连续帧、连续帧之间的实际间隔跟LDF和诊断规范里定的值比对。常见的失败模式是连续帧发太快接收方处理不过来或者STmin设成0触发接收方的缓冲区溢出。实测数据在19200bps下一条8字节的诊断请求如果分成首帧加两个连续帧加上调度表的轮询间隔端到端响应时间通常在30到80毫秒之间。如果你的系统要求100毫秒内完成下线检测就得把诊断帧在调度表里的出现频率调高或者优化分段策略把长报文尽量压到单帧。3.3 节点配置服务下发后的结果回读LIN 2.1之后有节点配置服务用来给从节点分配帧ID、设置NAD节点地址等。这部分测试的核心是下发—回读—复位后复验三步。配置下发的时序通常要求主机进入特定的会话模式然后按顺序发配置请求从节点逐条响应。测试要点是配置过程中不能有普通数据帧插入干扰所以调度表要能切换到纯诊断模式。有个高频坑配置成功后没有复位从节点配置参数没写进非易失存储掉电再上电就恢复默认了。测试用例必须包含配置—断电—上电—回读的完整闭环。我在一个项目里就是因为漏了这一步产线刷完配置直接进入下一工序装车后发现一半节点的NAD是默认值返工成本很高。4. 用单片机UART模拟LIN自测环境怎么搭才不像玩具很多人手上的LIN测试环境不方便或者想先在软件层面验证逻辑就会用单片机的UART来模拟LIN。这个路子可行但有几个硬性子必须处理不然做出来的东西只能跑自己跟自己挂到真总线上就废。这个思路对应搜索里常被问到的在LIN模式下串口发送出去的数据会触发接收中断吗这一节把硬件、软件、双板对测三个层次讲清楚。4.1 硬件侧LIN收发器的TX/RX与单线总线的关系UART的TX和RX是两根独立的TTL线LIN总线是一根双向线中间必须挂一个LIN收发器比如TJA1020、TJA1021、ATA6622这类。收发器的作用是把MCU的TX转成总线上的显性/隐性同时把总线状态回读给RX。注意方向MCU的TX接收发器的TXDMCU的RX接收发器的RXD收发器再把TXD和总线连起来。很多收发器的RXD在本地发送时是不会把本地TXD回读给MCU的因为它内部是单线驱动加接收比较器发送时总线电平由TXD决定接收比较器看到的也是同一电平有些器件会因此把RXD拉成跟TXD一致有些则保持隐性。这个行为因器件而异查数据手册里的回读或者是local echo说明。如果不回读MCU软件就自己知道发了什么如果回读软件要处理自己发的字节又被自己收到的情况否则会被当成从节点响应。用UART模拟LIN主节点时还需要一个能产生13位Break的机制。标准UART的一个字节只有起始位加8数据位加停止位凑不出13位连续显性。解决办法有几种有的MCU的UART有多余的LIN模式位可以在硬件层面产生Break没有的话就把波特率临时调低发送0x00得到一段足够长的显性时间再切回正常波特率发同步场。这个切换必须干净中间不能有残留实测时用示波器看最可靠。4.2 软件侧Break场怎么发、采样点怎么设、帧错误怎么用用普通UART模拟LIN从节点时Break的检测靠帧错误。因为波特率没变主机发的13位显性会被从节点的UART认成起始位加9个0加停止位停止位检测到0触发帧错误标志。软件在帧错误中断里判断是不是Break然后准备接收同步场。这个机制几乎所有支持LIN的MCU都内置但要注意帧错误标志必须在读取数据寄存器后清掉不然会一直触发。采样点的问题更隐蔽。UART默认在起始位下降沿后的某个位置采样常见是16倍过采样、第8或第9个采样点。LIN的从节点需要按同步场重新校准很多MCU的LIN模式会自动校准普通UART模式就得软件自己去量同步场的边沿间隔。如果用的是普通UART采样点固定同步场只用来测波特率偏差不重建位时间那在长线束和温度变化下就比较脆弱。做自测环境时尽量选带硬件LIN模式的MCU省掉这一层麻烦。4.3 发送时会不会触发接收中断一次实测的结论回到那个反复被问的问题在LIN模式下串口发送出去的数据会不会触发接收中断。结论是取决于收发器和MCU配置不取决于LIN模式这个词本身。几种典型情况如果用的是单线收发器且RXD在发送时不回读MCU自己的接收中断不会被触发但总线上其他节点发的数据仍然会让RX出现信号从节点应答时如果自己的RX也连在总线上就可能收到。如果用单板自发自收TX和RX短接那所有发出的数据都会进接收中断这是纯软件回环跟LIN无关。如果用的是带本地回读的收发器本地发的每个字节都会在RX上出现接收中断会被触发此时软件必须在接收中断里按这个字节是我自己发的还是别人的来过滤判断依据是时间窗口——自己刚发完的几十微秒内收到的几乎肯定是回读。实测建议搭好硬件后先做一次发送空载测试——只发不回看接收中断计数。如果计数不为零说明有回读或者总线上有干扰先把这个现象搞清楚再往下做否则后面主从对测时的收发逻辑会乱成一锅粥。4.4 双板主从对测把自发自收升级成闭环验证单板回环只能验证软件逻辑真正有用的是双板对测一块做主机一块做从机中间用真实线束连接加上若干个假负载节点用电阻电容模拟总线电容。主机跑调度表从机按LDF响应两边都开日志。这个环境下能测出的问题包括时序余量、同步场校准、校验和一致性、以及超时恢复。双板对测要造几个场景正常全速跑、从机断电、从机复位后重新上线、总线短路到地、总线断开。每个场景下主机的行为都要记录。我一般会连续跑8小时以上统计丢帧率和恢复时间。这个数据比任何单次抓包都有说服力。5. 故障排查链路三个典型现象从现象到根因测试做久了大部分故障会归到几类。这里给出三条排查链路重点是先看什么、再看什么、每一步的判据是什么而不是直接给答案。5.1 偶发校验和错误先怀疑什么现象是大部分帧正常偶发几帧校验和错误重发就好。排查顺序先看错误帧在时间上的分布。如果集中在某个时间点比如整点、或者某个功能触发时大概率是EMI或者某个节点在那一刻有大电流动作。再看错误位置。如果错误总在同一个字节位说明是位时间偏差导致的采样错误去查同步场占空比和从节点时钟。如果错误位置随机看是不是总线电容太大导致边沿变缓。测同步场上升时间超过20%位时间就要关注。最后才怀疑软件。软件导致的校验和错误通常是系统性的全错或全对不是偶发。这条链路的关键是先排除物理层再查协议层。我见过太多人一上来就改校验和算法改了一周发现是线束问题。5.2 从节点完全不应答物理层倒推法现象是主机发出帧头响应空间一直是隐性从节点一声不吭。倒推顺序第一步用示波器量从节点端的Break和Sync确认从节点真的收到了帧头。有时候分析仪能解出帧但从节点因为线束压降或者收发器损坏压根没收到。第二步量从节点的供电和收发器使能脚。LIN收发器通常有EN脚休眠状态下不工作。第三步确认从节点的PID和校验和类型配置正确。这两个不对从节点会静默丢弃。第四步换一块已知好的从节点交叉验证。如果换板就好问题在从节点硬件或软件如果换板也不好问题在主机或者线束。5.3 长线束下的误码斜率、终端与地偏移整车环境下LIN线束可能拉十几米跨几个车身区域。误码的三大来源斜率被电容拖慢、终端不匹配导致反射、以及各节点地电位不一致。测试方法是把线束换成实际长度加上实际节点数在极端温度下跑长时间。地偏移要用示波器差分测量单端测量看不出问题。如果偏移超过几百毫伏就要检查接地点的布置必要时增加地线或者改用双绞。这里有个经验LIN的抗干扰主要靠低速和斜率控制不是靠屏蔽。所以线束布置比线材规格更重要尽量远离大电流线束别和电机线捆在一起。6. XCP on LIN标定测量场景下的额外测试项XCP on LIN是把标定和测量协议跑在LIN上用于那些没有CAN或者以太网的低成本节点。它的测试重点和普通LIN诊断不一样因为XCP对时序和数据吞吐有额外要求。6.1 XCP报文如何塞进LIN的8字节响应XCP的CTO命令传输对象和DTO数据传输对象都要塞进LIN的8字节响应里。CTO长度有限一条命令往往需要拆成多个LIN报文靠XCP自己的分帧机制重组。测试时要验证分帧编号的连续性、重组后的完整性以及错误帧比如编号跳变的处理。6.2 DAQ/STIM与调度表的资源冲突XCP的DAQ数据采集模式会周期性上传测量数据这会和普通信号帧抢调度表的时间槽。测试要覆盖最坏情况DAQ全速上传加普通信号满负载看调度表还剩多少余量。如果余量不足就要调整DAQ周期或者降低信号频率。这部分测试很容易被忽略因为标定工程师和测试工程师往往是两拨人各自测各自的合起来跑就出问题。6.3 量产前的耐久与一致性回归XCP相关的固件在量产前要做一致性回归不同批次的主机、从机、不同版本的固件混搭跑同一套测试脚本看结果是否一致。LIN的互操作性比CAN脆弱不同厂家的实现细节差异大混搭测试是发现兼容性问题的唯一有效手段。我一般会准备至少三套不同来源的主从设备两两组合跑把不兼容的组合单独建档。实际做下来LIN协议测试这事儿最耗时间的从来不是测出问题而是确认测出来的到底是不是问题。分析仪报的错误有一半是工具配置造成的误报另一半里又有一半是测试环境本身引入的。我的建议是搭好环境之后先做一轮空跑基线全正常配置下连续跑几个小时把基线数据存下来以后所有异常都跟基线比这样判断起来才有依据。另一个体会是把所有测试脚本固化下来别每次手点手工测试的复现性太差尤其是偶发问题。最后示波器一定要常开在总线上它比任何分析仪的日志都诚实。
