1. 项目概述这不是一个普通VI而是UDS刷写流程的“心跳发生器”你打开LabVIEW项目找到那个名字略长、图标灰扑扑的TOOMOSS_SendAndWaitResp.vi——它不像主界面VI那样有炫酷控件也不像数据记录VI那样输出漂亮图表。但只要你开始做CAN总线上的ECU固件升级这个VI就是你整个上位机逻辑里最不能出错的一环。它不处理用户点击不绘制波形图不生成报告它只干一件事把一条UDS诊断请求比如0x31 01 FF 00精准打包通过图莫斯硬件发出去然后屏住呼吸在毫秒级时间窗内盯住总线等那条带NRC或正响应的报文回来最后把原始字节流、响应状态、耗时全部打包返回。它不是“发送接收”的简单拼接而是UDS协议在实时性、确定性、错误容忍三重约束下的精密编排。关键词里的“图莫斯”决定了物理层驱动和时序精度“CAN”框定了帧结构与仲裁机制“UDS”定义了服务ID、子功能、响应格式与超时规则“LabVIEW”则要求它必须在图形化数据流中保持可读、可调试、可复用。如果你正在做汽车电子、工业控制器或BMS的OTA升级上位机又恰好选了图莫斯作为CAN接口卡那么这个VI就是你所有刷写逻辑的基座——就像盖楼的地基看不见但承重最大。它不炫技但一旦它抖一下整个刷写流程就会卡在0x78等待响应、0x7F拒绝服务、或者干脆超时断连。我见过太多人花三天调通UDS 0x22读数据却在0x31刷写时反复失败最后发现根源是SendAndWaitResp里一个15ms的超时值设成了20ms导致ECU在擦除Flash时返回0x78而上位机误判为超时丢弃。所以这篇不是讲怎么拖拽控件而是带你拆开这个VI的每一层封装看清它如何把“发一帧、等一帧、判一帧”这件事做到工业级可靠。2. 核心设计思路为什么必须是“Send AND Wait”而不是“Send THEN Wait”2.1 UDS协议对通信基座的根本性要求UDSUnified Diagnostic Services不是TCP/IP那种“尽力而为”的协议它是嵌入式系统里典型的“强状态、弱连接”诊断协议。它的每一条服务请求都隐含着严格的时序契约。以最常用的0x31RoutineControl刷写例程为例当ECU收到0x31 01 FF 00启动下载例程后它必须在规定时间内完成Flash擦除并返回0x78requestCorrectlyReceived-ResponsePending表示“正在处理请稍候”。这个“稍候”不是模糊概念——ISO 14229-1标准明确定义了P2ClientMax客户端最大等待时间和P2ClientMax扩展等待时间通常P2ClientMax为50msP2ClientMax为5000ms。这意味着上位机不能发完就走也不能死等5秒。它必须在50ms内先检查是否有0x78响应若无则继续等待直到5000ms上限。这就是“SendAndWaitResp”命名的由来Send是动作Wait是策略Resp是目标。如果拆成两个独立VI——一个SendCANFrame一个WaitForResponse——你会立刻掉进三个坑第一无法保证Wait操作紧随Send之后立即启动中间可能被其他VI抢占CPU时间片导致首帧响应被漏捕第二无法将Send时刻精确锚定为Wait计时起点P2ClientMax超时判断必然失准第三无法将请求帧ID、DLC、Data与响应帧做原子级关联当总线上同时存在多路诊断会话如同时刷MCU和SBC时极易张冠李戴。图莫斯硬件本身支持CAN ID过滤和FIFO缓冲但UDS的会话状态Session Control、安全访问Security Access等上下文信息全在上位机软件层维护这就要求通信基座必须是“请求-响应”绑定的原子单元。2.2 图莫斯硬件特性如何塑造VI架构图莫斯TOOMOSS系列CAN卡如TMC104、TMC208在LabVIEW生态中之所以被广泛选用核心在于其NI-VISA兼容的底层驱动和极低的API调用开销。但它的优势也带来了独特约束硬件本身不解析UDS协议只负责CAN帧的收发所有协议解析、超时管理、重传逻辑必须由LabVIEW软件实现。这就决定了TOOMOSS_SendAndWaitResp.vi必须承担四重职责帧构造层将UDS服务ID如0x22、子功能如0xF1、数据如0x00 0x10 0x01按ISO 15765-2CAN TP分段规则组装成多个CAN帧单帧SF、首帧FF、连续帧CF。例如发送12字节数据需生成1个FF帧ID0x7E0, DLC8, Data0x10 0x0C ... 1个CF帧ID0x7E0, DLC8, Data0x21 ...。时序控制层严格遵循ISO 15765-2的STmin分离时间和BS块大小参数。ECU在0x27安全访问成功后会通过0x67响应告知STmin值如0x2032msVI必须在发送每个CF帧前精确延时否则ECU会因帧间隔过短而返回NRC 0x72busyRepeatRequest。状态机层内置有限状态机FSM管理从“空闲”到“发送中”到“等待响应”再到“超时/成功/失败”的完整生命周期。状态切换必须基于硬件事件如TX Complete中断、RX Frame Available中断而非轮询否则CPU占用率飙升。错误隔离层当总线出现错误帧、ACK丢失、或ECU返回NRCNegative Response Code时VI需区分可恢复错误如NRC 0x78与致命错误如NRC 0x33内存忙并向上层提供清晰的状态码如enum: Success / Timeout / NRC_78 / NRC_33 / BusOff而非简单抛异常。这四层不是堆叠而是深度耦合帧构造结果决定STmin起始点时序控制触发状态机跳转状态机决策又反向影响下一次帧构造。因此这个VI绝不能是几个子VI的线性调用而必须是一个闭环反馈系统。我实测过若将STmin延时放在While循环外做静态配置当ECU动态调整STmin时某些BMS在高温下会延长STmin整个刷写流程会在第3个CF帧后卡死——因为VI还在用旧的20ms延时而ECU已要求50ms间隔。2.3 LabVIEW数据流范式下的关键取舍LabVIEW的图形化编程本质是数据流驱动这既是优势也是枷锁。在TOOMOSS_SendAndWaitResp.vi中我们做了三个关键取舍第一放弃“零拷贝”追求确定性。有人试图用Shared Variable或Network Stream直接传递原始CAN帧数组避免数据复制。但实测发现在高负载如同时采集10路ADC下Shared Variable的更新延迟波动可达±5ms远超UDS P2ClientMax的50ms容限。最终方案是每次调用VI时输入端子明确接收一个簇Cluster——包含TargetIDECU的RX ID、ServiceID、SubFunction、DataArray、Timeout_ms、STmin_ms等字段VI内部用移位寄存器Shift Register暂存当前会话状态所有计算基于副本进行。虽然多了一次内存拷贝但换来的是微秒级的执行确定性。第二用“错误簇”替代“错误代码”。LabVIEW传统做法是返回一个整数错误码如-10001表示超时。但UDS场景需要更丰富的上下文是P2ClientMax超时还是P2*ClientMax超时NRC是0x78还是0x33响应数据长度是否匹配预期因此VI输出端子是一个自定义错误簇Error Cluster内含errorStatusenum、responseFrameU8 Array、responseLengthI32、elapsedTime_msI32、nrcCodeU8等字段。这样上层VI只需连线一个Case结构就能分流处理不同错误无需再解析字符串或查表。第三牺牲“通用性”换取“可调试性”。网上有些开源VI试图做成“万能CAN通信VI”输入一个任意CAN ID和数据就发。但在UDS场景这种设计等于埋雷。我们的VI强制要求输入ServiceID和SubFunction并在框图中内置服务ID校验如0x10 SessionControl必须带子功能0x01/0x02/0x03。当用户误输0x10 0x00时VI在执行前就报错“Invalid SubFunction for Service 0x10”而不是发出去再等ECU返回NRC 0x12subFunctionNotSupported。这种“提前拦截”让调试效率提升3倍以上——你不用抓CANoe看总线就能知道问题出在上位机逻辑层。3. 核心细节解析从VI图标到框图的逐层解剖3.1 前面板设计为什么只有5个输入和3个输出打开TOOMOSS_SendAndWaitResp.vi的前面板你会惊讶于它的“简陋”没有指示灯、没有波形图、甚至没有超时进度条。只有5个输入控件和3个输出显示。这种极简主义不是偷懒而是面向工业现场的刻意设计。Inputs输入TargetID (U32)ECU的CAN接收ID单位为十进制。例如ECU RX ID为0x7E0此处填1984。为什么不用十六进制因为LabVIEW数值控件默认十进制且UDS文档如AUTOSAR SWS中ID均以十进制标注避免工程师在十六进制/十进制间反复换算出错。ServiceID (U8)UDS服务ID如0x22ReadDataByIdentifier、0x2EWriteDataByIdentifier。这里强制U8类型杜绝输入0x100这种非法值。SubFunction (U8)子功能如0x01defaultSession、0x03extendedDiagnosticSession。对于无子功能的服务如0x3E TesterPresent此值设为0x00VI内部自动忽略。DataArray (U8 Array)原始数据字节数组。注意这是“应用层数据”不包含UDS头SIDSF。例如读取DID 0xF190DataArray应为[0xF1, 0x90]VI会自动在前面添加0x22。Timeout_ms (I32)总等待超时单位毫秒。典型值P2ClientMax50P2*ClientMax5000。此值必须大于STmin_ms否则逻辑冲突。Outputs输出errorStatus (Enum)预定义枚举含Success、Timeout_P2Client、Timeout_P2Star、NRC_78、NRC_33、BusError、InvalidInput等12种状态。枚举值与ISO 14229-1标准NRC严格对应方便团队统一理解。responseFrame (U8 Array)原始响应帧数据含CAN ID高位、DLC、Data。例如ECU返回0x62 F1 90 01 02 03 04responseFrame为[0x00,0x00,0x00,0x00,0x06,0x2F,0x19,0x00,0x01,0x02,0x03,0x04]前4字节为ID第5字节为DLC后续为Data。elapsedTime_ms (I32)从Send开始到Resp返回的精确耗时用于性能分析和动态调整超时策略。提示不要在前面板加“Cancel”按钮。UDS通信是原子操作中途取消会导致ECU进入未知状态如Flash擦除一半。所有取消逻辑必须由上层VI在调用前决策本VI只负责执行。3.2 框图核心逻辑一个状态机的七步生死劫双击打开框图主循环是一个While循环但真正的灵魂是循环内的状态机State Machine。它并非LabVIEW模板里的“经典状态机”而是针对UDS优化的“轻量级事件驱动状态机”共7个核心状态State 0: Idle空闲等待调用。当VI首次运行或上一次操作结束进入此状态。关键操作清空图莫斯接收FIFO调用TOOMOSS_ClearRxBuffer.vi防止残留帧干扰。过渡条件收到有效输入TargetID≠0ServiceID有效跳转至State 1。State 1: BuildFrame构建帧根据ServiceID/SubFunction/DataArray按ISO 15765-2规则生成CAN帧序列。重点计算帧数。若DataArray长度≤6字节生成单帧SFDLC2DataLenData[0]0x00|DataLenData[1..]原始数据。若6字节生成首帧FFDLC8Data[0]0x10|(DataLen8)Data[1]DataLen0xFFData[2..7]前6字节。输出FrameQueue队列存储待发帧数组、ExpectedResponseIDTargetID0x08如ECU RX0x7E0则期待0x7E8。State 2: SendFirstFrame发送首帧调用TOOMOSS_WriteCANFrame.vi将FrameQueue[0]发出。启动P2ClientMax定时器使用Tick Count (ms)获取起始时间。过渡条件发送成功跳转至State 3。State 3: WaitForFirstResp等待首响应进入紧密循环Loop Time 100μs轮询图莫斯RX FIFO。检查每帧ID是否等于ExpectedResponseIDDLC是否≥2Data[0]是否为0x6X正响应或0x7F负响应若收到0x78requestCorrectlyReceived-ResponsePending记录时间戳跳转至State 4WaitForPending。若收到0x6X跳转至State 6ParseResponse。若超时elapsed Timeout_ms跳转至State 7Error。State 4: WaitForPending等待挂起响应此状态专为0x78设计。启动P2*ClientMax定时器更长的等待窗口。持续轮询RX FIFO但增加“静默期”收到0x78后暂停轮询5ms模拟ECU处理时间再恢复。避免高频轮询导致CPU占用过高。过渡条件收到非0x78响应跳转至State 6超时跳转至State 7。State 5: SendConsecutiveFrame发送连续帧当首帧后需发CF时激活如0x31刷写大文件。从DataArray剩余部分取7字节构造CFData[0]0x20|seqNumData[1..7]数据。严格插入STmin_ms延时使用Wait (ms)函数。seqNum自增循环发送直至DataArray耗尽。State 6: ParseResponse解析响应提取responseFrame剥离ID/DLC提取Data部分。若Data[0]0x7F解析NRCData[2]映射到errorStatus枚举。若Data[0]0x6X验证长度0x22响应应≥3字节0x62 DID0x31响应应≥2字节0x71。计算elapsedTime_ms 当前Tick - 发送起始Tick。输出所有结果跳转至State 0。State 7: Error错误处理根据超时类型、总线状态调用TOOMOSS_GetBusStatus.vi检查BusOff、输入合法性设置errorStatus。清空所有缓冲区确保下次调用干净。强制跳转至State 0。这个状态机的精妙在于“等待”不等于“空转”。State 3和State 4的轮询循环内嵌了“最小化CPU占用”逻辑每次轮询后调用Wait (ms) 0.1既保证响应捕获及时性1ms延迟又将CPU占用率压到5%以下。我对比过纯While True循环无Wait在i5-8250U上CPU飙到40%导致LabVIEW主界面卡顿。3.3 图莫斯硬件交互驱动层的关键参数TOOMOSS_SendAndWaitResp.vi的可靠性50%取决于它如何与图莫斯硬件对话。我们深度定制了三个底层VITOOMOSS_WriteCANFrame.vi输入CAN IDU32、DLCI32、DataArrayU8 Array核心调用TOOMOSS DLL的TOOMOSS_WriteCANFrame函数。关键参数bTransmitType设为0x01Standard Frame禁用扩展帧除非ECU明确要求。wTxPriority设为0x00最高优先级确保诊断帧不被其他CAN消息如传感器数据抢占。dwTimeout设为100ms这是硬件级发送超时防止单帧发送卡死。TOOMOSS_ReadCANFrame.vi输出CAN IDU32、DLCI32、DataArrayU8 Array、TimestampU64核心调用TOOMOSS_ReadCANFrame函数一次读取FIFO中所有可用帧。关键技巧dwReadCount设为10一次最多读10帧避免单次读取过多导致处理延迟。lpTimestamp启用获取硬件时间戳精度1μs用于精确计算P2ClientMax耗时而非依赖LabVIEW软件时钟误差可达10ms。TOOMOSS_ClearRxBuffer.vi作用清空硬件RX FIFO防止历史帧干扰。为什么必须在Idle状态调用因为若在WaitForFirstResp中清空可能刚收到响应帧就被清除。实测数据图莫斯TMC104 FIFO深度为128帧若不清空连续刷写10次后第11次的首响应可能被第1次的残留帧覆盖。注意所有TOOMOSS DLL调用必须在“Call Library Function Node”中勾选“Run in UI Thread”。图莫斯驱动非线程安全若在后台线程调用会导致LabVIEW崩溃。这是官方文档未强调但我们踩了三次坑才确认的铁律。4. 实操过程从零部署到稳定运行的完整链路4.1 环境准备LabVIEW版本与图莫斯驱动的黄金组合别急着写代码先确保地基牢固。我们实测验证过的“黄金组合”是LabVIEW版本2018 SP1 或 2020 SP1。避开2019SP0有VISA内存泄漏Bug、2021图莫斯DLL签名不兼容。2018 SP1是工业界最稳定的版本90%的车厂诊断工具基于此开发。图莫斯驱动TMC_Driver_V3.2.0.02022年10月发布。必须安装配套的TOOMOSS LabVIEW Toolkit非NI官方VI库。Toolkit中包含所有底层VI如TOOMOSS_OpenDevice.vi它们已预编译比自己调DLL稳定10倍。硬件连接图莫斯TMC104卡插入PCIe插槽CAN_H/CAN_L接ECU的OBD-II 6号CAN_H和14号CAN_L针脚。务必使用120Ω终端电阻我们曾因省略电阻导致0x31刷写时CF帧ACK丢失ECU反复返回NRC 0x72。安装步骤安装LabVIEW 2018 SP1官网下载勿用破解版驱动签名验证会失败。安装TMC_Driver_V3.2.0.0运行setup.exe勾选“Install LabVIEW Toolkit”。重启电脑打开LabVIEW进入Tools → Options → Paths确认“LabVIEW Resource Path”包含C:\Program Files\TOOMOSS\LabVIEW Toolkit。在项目浏览器中右键“我的电脑” → “添加VI库”选择TOOMOSS_Toolkit.lvlib。提示若遇到“LabVIEW安装错误”或“can not open com port”90%是驱动未正确安装。打开设备管理器检查“TOOMOSS CAN Interface”是否带黄色感叹号。若有卸载后重新以管理员身份运行setup.exe。4.2 VI调用示范一个真实的0x22读DID流程现在让我们用TOOMOSS_SendAndWaitResp.vi读取ECU的VIN码DID 0xF190。新建一个VI命名为Read_VIN.vi前面板放置一个“TargetID”数值控件设为19840x7E0。放置一个“ServiceID”数值控件设为0x22。放置一个“SubFunction”数值控件设为0x000x22无子功能。放置一个“DataArray”数组控件右键→“Representation”→“U8”输入值[0xF1, 0x90]。放置一个“Timeout_ms”数值控件设为5000。放置一个“errorStatus”枚举显示控件从TOOMOSS_SendAndWaitResp.vi拖入。放置一个“responseFrame”数组显示控件。框图从项目浏览器拖入TOOMOSS_SendAndWaitResp.vi。连线TargetID → TargetIDServiceID → ServiceIDSubFunction → SubFunctionDataArray → DataArrayTimeout_ms → Timeout_ms。将errorStatus、responseFrame、elapsedTime_ms输出端子连线到前面板对应控件。关键一步在TOOMOSS_SendAndWaitResp.vi上方放置一个“Sequence Structure”将“Open Device”、“Set Baudrate”、“Start CAN”三个VI放入Frame 0。其中TOOMOSS_OpenDevice.viDevice Index设为0第一块卡。TOOMOSS_SetBaudrate.viBaudrate设为500000500kbps主流车载CAN速率。TOOMOSS_StartCAN.vi启动CAN控制器。运行Read_VIN.vi若一切正常responseFrame应显示类似[0x00,0x00,0x00,0x00,0x08,0x62,0xF1,0x90,0x31,0x45,0x32,0x33,0x34,0x35,0x36]。解析DLC0x08Data0x62 F1 90 VIN字符串“1E23456”。实操心得第一次运行失败别慌。打开CANoe或PCAN-View将同一CAN通道设为监听模式。若看到上位机发出0x22 F1 90但ECU无任何响应说明ECU未进入诊断会话。此时必须先调用TOOMOSS_SendAndWaitResp.vi发送0x10 0x03Extended Session再发0x22。UDS是状态机协议没有“直连”这回事。4.3 性能调优让P2ClientMax从50ms降到35ms的实战技巧UDS标准P2ClientMax是50ms但实际ECU响应往往更快。缩短超时值能加速刷写流程但风险是误判。我们通过三步调优将可靠超时值压到35ms第一步硬件层抓取真实响应分布用CANoe录制100次0x22读DID的完整通信。导出CSV用Excel统计响应时间95%的响应在28ms内最大值32ms平均值22ms。结论35ms是安全阈值。第二步LabVIEW层消除软件抖动在TOOMOSS_SendAndWaitResp.vi的State 3WaitForFirstResp中将轮询循环的Wait (ms)从0.1改为0.05。将Tick Count (ms)替换为High Resolution Relative Seconds精度100ns避免ms级时钟的舍入误差。关闭LabVIEW前面板所有非必要控件如波形图、表格减少UI线程负担。第三步系统层锁定CPU资源在Windows任务管理器中将LabVIEW进程设为“高优先级”。禁用所有后台程序杀毒软件、云同步、浏览器。BIOS中开启“Intel SpeedStep”和“Turbo Boost”确保CPU在响应瞬间能飙到最高频。调优后实测1000次0x22读取失败率从0.3%降至0平均耗时从25ms降至21ms。别小看这4ms刷写1MB固件约2000个0x31帧可节省8秒——在产线节拍中这足够多测一个ECU。4.4 故障排查NRC 0x78、0x33、0x72的根因与对策UDS刷写失败80%集中在三个NRC上。TOOMOSS_SendAndWaitResp.vi已将它们映射为清晰的errorStatus但你需要知道背后的故事NRC Code中文含义根本原因解决方案实测案例0x78requestCorrectlyReceived-ResponsePendingECU正在处理请求如Flash擦除需等待增加P2*ClientMax超时在State 4中加入“静默期”刷写BMS固件时0x31启动擦除后必返0x78等待3秒后才返回0x71成功0x33SecurityAccessDenied未通过安全访问Security Access先发0x27 0x01seedECU回0x67 0x01 seed计算keyXOR/算法再发0x27 0x02 key某ECU的key算法是seed左移2位我们误用右移连续10次NRC 0x330x72busyRepeatRequest帧间隔STmin过短ECU忙不过来严格遵守ECU返回的STmin发送CF前插入精确延时ECU在0x27成功后返回0x67 0x01 0x20STmin0x2032ms但VI误用20ms导致第2个CF被拒常见问题速查表Q调用VI后errorStatus一直是“Timeout_P2Client”但CANoe显示ECU已发0x62响应A检查ExpectedResponseID是否正确。ECU的RX ID是0x7E0其TX ID通常是0x7E80x7E00x08但某些ECU用0x7E0广播回复。在VI中将ExpectedResponseID设为0x7E0试一次。QresponseFrame数据长度总是0A图莫斯RX FIFO为空。检查CAN物理连接用万用表测CAN_H-CAN_L电阻是否为60Ω、ECU是否上电、CANoe是否占用了同一端口图莫斯不支持多进程共享。Q连续调用VI第二次就报“BusError”A图莫斯硬件进入BusOff状态。原因是上一次发送失败后未调用TOOMOSS_ResetCAN.vi复位。在State 7Error中必须加入“Reset CAN”子VI。5. 经验总结那些文档里不会写的血泪教训写完这个VI我把它用在了三个量产项目中某车企的ADAS域控制器刷写、某电池厂的BMS固件升级、某工程机械的ECU OTA。每一次部署都让我对“通信基座”这个词的理解更深一层。这里分享几个绝对不写在手册里的硬核经验第一永远不要相信ECU的“标准响应时间”。ISO标准说P2ClientMax是50ms但某BMS厂商的ECU在低温-20℃下0x31擦除Flash要210ms才返回0x78。我们最初按50ms设超时产线每天报废20块板子。后来在VI中加入了温度补偿逻辑读取ECU的环境温度DID0xF186若-10℃自动将P2*ClientMax从5000ms提升到10000ms。这个补丁让良率从92%升到99.98%。第二图莫斯的“自动重传”是把双刃剑。TMC104驱动默认开启CAN TX自动重传Auto Retransmit。这在总线干扰大时很友好但UDS刷写中它会制造灾难当ECU返回0x78后上位机还没来得及发下一个CF图莫斯因ACK丢失自动重发上一个CFECU收到重复帧直接返回NRC 0x22conditionsNotCorrect。解决方案在TOOMOSS_StartCAN.vi中将bAutoRetransmit参数设为False所有重传逻辑由VI软件层控制——只在NRC 0x72时重发CF其他情况绝不重发。第三LabVIEW的“并行循环”是UDS的大敌。新手常想“一边发0x31一边读0x22状态”于是用两个While循环并行跑。结果两个循环争抢图莫斯的RX FIFOA循环读走0x78B循环就再也收不到响应。正确做法所有UDS会话必须串行化。用一个全局变量Global Variable或Functional Global VIFGVI管理“当前会话ID”任何新请求必须等待当前会话的errorStatus变为Success或Fatal Error后才能启动。最后也是最重要的这个VI的终极价值不在于它多快而在于它多“笨”。它不猜测ECU意图不自动重试不隐藏错误。它把每一个字节、每一毫秒、每一个NRC原封不动地交到你手上。当你看到errorStatus是NRC_33你就知道该去翻安全访问算法文档当你看到elapsedTime_ms是3200ms你就知道该去查ECU的擦除时间规格书。它强迫你直面UDS协议的本质——不是魔法而是精确到毫秒的工程契约。我在产线调试时曾连续72小时盯着这个VI的errorStatus枚举看着它从NRC_78跳到NRC_33再跳到Success。那一刻我明白所谓“上位机开发”不是堆砌华丽界面而是成为CAN总线与ECU之间那个最冷静、最守信、最不容出错的信使。TOOMOSS_SendAndWaitResp.vi就是这个信使的身份证。