1. 会话状态机为什么UDS诊断一上来总要谈“会话”1.1 会话是什么从“登录账号”说起做UDS诊断开发的人第一课基本都是0x10服务也就是DiagnosticSessionControl中文叫诊断会话控制。一开始接触的时候很多人会把它简单理解成“换个模式”但实际上会话是UDS诊断里最基础、最容易被忽略、又最能决定功能能否正常执行的前置条件。如果你用过Web应用可以这样类比会话Session就像用户登录系统后的登录态。你登录之后才能访问某些页面、执行某些操作超时之后登录态失效又要重新登录。UDS里的会话切换也是这样——ECU平时工作在默认会话Default Session在这个会话下只能做有限的诊断操作比如读故障码、读版本号。要想执行那些更“敏感”或更“重”的操作比如标定、刷写、故障码清除必须先请求切换到扩展会话Extended Session或者编程会话Programming Session。ECU不会让你在默认会话下直接干这些事这是安全设计上的基本逻辑防止非预期操作干扰车辆正常运行。UDS诊断协议ISO 14229-1定义的会话至少包括默认会话Default Sessionsub-function0x01编程会话Programming Sessionsub-function0x02扩展诊断会话Extended Diagnostic Sessionsub-function0x03安全系统诊断会话SafetySystemDiagnosticSessionsub-function0x04新增于较新版本多用于安全相关ECUOEM还可以基于这些标准会话定义自定义会话0x40~0x7F比如有些厂商定义“开发会话”“工厂模式”“产线末端会话”用途不同权限不同。所以你看市面上的诊断仪同样一个0x10服务不同车型回包内容甚至支持的子功能都不同这一点后面细说。1.2 为什么不能一直待在扩展会话我见过不少刚入行的工程师有个疑问既然扩展会话权限大那我诊断的时候直接发0x10 03进到扩展会话一直不切回去不就行了从现场测试角度讲这样确实能省很多事。但问题是ECU的设计目标首先不是“方便诊断仪”而是“安全、稳定、不打扰整车工作”。扩展会话意味着允许执行一些可能影响车辆行为的操作比如写入DID、清除故障码、运行例程、控制执行器。这些操作如果发生在车辆行驶过程中后果可能很严重。所以ECU有一种机制来避免长时间停留在非默认会话这就是S3定时器。S3定时器SessionTimeout也叫非活跃超时时间是一个倒计时器。只要ECU处于非默认会话并且没有收到诊断请求S3时间一到ECU就会自动切回默认会话。标准里S3 Server Timeout通常配置为5000ms左右具体值由OEM在ECU规范里定义常见的还有3000ms、10000ms。所以你会发现诊断仪在进入扩展会话之后如果接下来超过几秒没有发任何请求ECU自己就跳回默认会话了你以为还停留在扩展会话结果下一个功能服务直接吃一个NRC 0x22条件不满足排查半天才发现是会话掉了。要维持会话就得周期发送0x3ETesterPresent测试仪在线请求。0x3E和0x10的关系我会在后面专门讲但这里先记住一个结论在非默认会话执行较长时间任务尤其是刷写这类分钟级操作时0x3E是保命符。1.3 会话切换的几个关键时间参数会话切换背后有三个时间参数理解了它们基本就理解了整个超时体系P2 ServerECU收到请求后开始处理并给出首条响应所允许的最大时间通常为25ms~50ms标准默认是50ms。P2* Server如果ECU在P2时间内给不出最终响应比如正在擦除Flash它需要先发一个NRC 0x78ResponsePending响应挂起告诉诊断仪“我正在处理别急”然后P2计时器启动。在P2时间内ECU必须给出最终响应P2*通常是5000ms。S3 Server非默认会话的活跃保持时间超时自动回默认会话。这三个时间参数会直接体现在0x10服务请求和正响应报文里。0x10请求可以携带P2服务器最大值和P2服务器最大值正响应里ECU也会返回它实际支持的P2和P2参数。诊断仪要做的就是根据这些参数调整自己的超时判断否则你按固定500ms等响应而ECU实际P2*是5000ms中间必然误报超时。2. 0x10服务的请求与响应拆解2.1 0x10请求报文每个字节都别乱填0x10服务请求的标准格式是02 10 XX其中02是PDU长度指示后两个字节10是SIDService ID服务标识符XX是子功能Sub-function也就是目标会话。但实际开发中你会发现请求不总是只有3个字节因为0x10请求还可以带4个可选的定时参数02 10 03或者06 10 03 00 00 01 00这里06表示PDU长度是6个字节后面的00 00 01 00分别是P2 Server最大计数、P2* Server最大计数。注意这两个值不是直接填毫秒数而是先转化为一定单位的计数值再填入。标准里单位是P2最大计数单位为1msP2最大计数单位为10ms。比如你希望请求ECU将P2设为100ms那这里填0x0064十进制100希望P2设为5000ms就填0x01F4除以10500也就是0x01F4十进制500。不过这里有个容易搞混的点0x10请求里的定时参数叫“最大计数”它表示的是诊断仪建议ECU采用的辅助定时值ECU可以在正响应里返回自己实际的P2/P2*。实操中我习惯的做法是请求里带清晰参数然后以正响应返回的参数为准。再说子功能字节它还承担一个特殊功能——bit 6是抑制正响应标志位Suppress PosRsp。这是个非常容易踩坑的地方。比如你发送02 10 43这表示请求切换到扩展会话sub0x03但bit 6置1所以ECU不发送正响应。很多人看到ECU没有回正响应以为车出问题了实际是ECU按你的要求把正响应屏蔽了。这个开关的目的是在多ECU诊断场景减少总线负载普通单ECU测试建议不要随便用。2.2 正响应与NRC从报文看ECU的“真实能力”0x10的正响应格式是06 50 03 00 32 01 F4分解一下50是正响应SID0x10 0x4003是当前所切换到的会话模式后面的00 32表示P2 Server最大计数01 F4表示P2* Server最大计数。注意正响应里的定时值才是ECU“真实”的承诺值。00 32换算成十进制是50单位是1ms所以P250ms。01 F4换算成十进制是500单位是10ms所以P2*5000ms。实际看到这条报文后诊断仪必须调整内部超时第一个响应等50ms如果50ms内ECU只回了NRC 0x78而且没给最终结果那么继续等P2的时间。如果你还是按默认的150ms等那P2这种几千毫秒才能完成的操作必然失败。ECU在某些条件下不给正响应转而给负响应码NRCNegative Response Code。0x10服务常见的NRC包括NRC 0x12子功能不支持比如ECU根本没有编程会话很多非刷写ECU只支持0x01和0x03。NRC 0x13报文长度错误常见于请求长度不对或者带了定时参数但格式不对。NRC 0x22条件不满足比如当前状态不允许切换到该会话如防盗锁止状态下不允许进编程会话。NRC 0x33安全访问被拒绝有些ECU进入编程会话不仅需要安全解锁还要求满足其他安全条件。排查的时候建议先把NRC抓到再逐条对照标准。最怕的是总线上直接没有任何响应报文那就要查物理层、传输层、定时参数。后面我会讲这种“静默”的排查套路。2.3 一个完整的“请求-响应”报文明细实例用CANoe或者PCAN抓一条完整交互大概是这样的需求从默认会话切换到扩展会话。请求报文测试仪发到ECUCAN ID 0x7E0功能寻址时是0x7DF数据场02 10 03逐字节解释0x02是PCIProtocol Control Information表示随后的字节数。0x10是SID。0x03是子功能切到扩展会话。正响应报文ECU回CAN ID 0x7E8物理应答数据场06 50 03 00 32 01 F4解释0x06表示后面有6个字节。0x50是SID0x40。0x03表示当前会话扩展会话。0x003250是P2 Server最大计数。0x01F4500是P2* Server最大计数。从时间戳上看这个一来一回通常只有十几毫秒。如果你发现ECU对0x10 03的响应耗时超过500ms多半是ECU内部在处理一些额外逻辑比如记录DTC、切换通信模式、关闭某些报文这时候就靠P2*机制来缓冲正常现象。3. 一个完整实例默认会话→扩展会话→安全访问→执行例程3.1 实例1进入扩展会话后执行RoutineControl0x31我拿一个实际做过的项目来拆解这是某电控单元做产线测试时的一个典型序列。需求读取ECU里一个生产参数并校验该参数需要安全解锁后才能读。整个过程如下第一步发送02 10 03请求进入扩展会话。第二步安全访问0x27服务。这里需要先请求种子再发送密钥。假设种子是0x11223344经过特定算法计算出密钥0xA1B2C3D4请求发送06 27 02 A1 B2 C3 D4。如果密钥正确回50 02正响应如果错误会回NRC 0x35invalidKey或NRC 0x36exceedNumberOfAttempts。第三步发送02 31 01 02 00请求执行例程0x0200。正响应是04 71 01 02 00 00如果例程执行失败可能回NRC 0x22或0x31requestOutOfRange。第四步完成后发02 10 01切回默认会话或者在空闲S3超时后自动回默认会话。这个序列看起来很简单但实际产线跑起来有几个隐藏点安全解锁之后如果连续几次密钥错误ECU会进入延时锁定状态此时无论你发什么它都可能回NRC 0x36或者干脆不回必须等待一定时间。产线上最怕这种建议程序设计里预留错误计数提示。例程如果执行时间超过P2ECU会发NRC 0x78诊断仪不能在收到0x78后就判定失败应该等待P2*超时再下结论。0x31例程执行过程中如果S3超时触发ECU回到默认会话那解锁状态也会被清除。所以并发的0x3E保活要和例程执行配合好不能光发0x3E也要留够处理时间。3.2 实例2刷写流程中会话切换的位置UDS刷写是会话切换最典型的应用场景也是热词里提到的“uds刷写流程”。我梳理一个标准的基于CAN的刷写流程发送0x10 02进入编程会话Programming Session。很多ECU要求先进入扩展会话再切编程会话直接默认会话切编程会话会回NRC 0x22。发送0x85 02关闭DTC存储避免刷写过程中的中间状态被记录为故障。发送0x27安全访问解锁刷写权限。发送0x31例程控制执行擦除Flash操作比如例程0xFF00)。擦除可能耗时较长ECU会回0x78诊断仪等待P2*结束期间靠0x3E保活。请求下载0x34服务格式类似02 34 00 44 00 00 00 00 00 00高地址、长度等按ECU规范填。ECU回0x34正响应里面包含maxNumberOfBlockLength也就是每帧允许传输的最大数据长度这个必须遵守。循环发送0x36 TransferData传输数据格式02 36 01 00 数据。每帧数据长度不能超过0x34响应里的上限。全部传完发0x37 RequestTransferExit结束传输。发送0x11 ECU Reset执行复位或者先发0x10 01回默认会话再复位。复位后ECU重新上电可能需要再次进入诊断会话做刷写校验。这个流程里会话切换不只是开头那一次。有些ECU要求在0x27解锁前必须在扩展会话有些解锁后要求切编程会话才能擦除还有的在0x34请求下载前要求重新确认会话。你如果不按规范顺序走最常见的就是NRC 0x22。刷写过程往往几十秒甚至几分钟0x3E保活要一直发。我见过一个典型事故工具侧0x3E发送周期设置成了5秒恰好ECU的S3 Server超时是4秒结果每次刷到一半ECU就切回默认会话后续0x36全部NRC 0x22。排查了很久才发现是保活周期比S3还长纯属参数配置错误。3.3 会话切换对ECU内部状态的影响会话切换不是一个简单的模式位切换它会连带影响ECU的很多内部行为。举几个实操中观察到的现象从默认会话切到扩展会话ECU通常不会停发应用报文整车网络还正常。但如果切到编程会话有些ECU会主动停掉非诊断报文尤其网关类ECU会切断某些路由这是为了让刷写过程不被应用数据干扰。诊断仪不能因为“怎么没看到某条报文”就判定ECU故障先确认是不是会话切换引起的。部分ECU在离开默认会话时会记录一条“诊断会话激活”事件这本身可能触发DTC或者快照数据。回到默认会话后又可能触发另一条事件。这会影响后续DTC读取的结果排查时要想到这一点。安全解锁状态与会话强绑定会话一切回默认解锁直接失效。不要以为解锁了就能一直保持到重启很多ECU在1秒内不继续操作就自动锁定。IO控制0x2F和例程执行同样与会话绑定默认会话下执行IO控制基本都会失败。4. 会话切换中的常见坑与排查技巧4.1 常见NRC含义速查与处理现象常见NRC可能原因处理办法切换会话被拒0x12子功能不支持ECU没有该会话查看ECU诊断规范确认支持的会话列表切换会话被拒0x22当前状态不允许比如防盗锁止检查整车条件、供电状态、前置条件切换会话被拒0x13请求长度错误定时参数格式不对核对PDU长度和字节定义切编程会话失败0x33需要先安全解锁先执行0x27解锁流程再重试停留在非默认会话时操作失败0x22S3超时ECU已自动回默认会话重新发0x10切换同时用0x3E保活发了0x10后无任何响应无子功能bit 6置1导致正响应被抑制去掉抑制位或检查是否功能寻址发了0x10后无任何响应无ECU休眠/地址不对/波特率不对检查CAN ID、总线负载、电源0x12的问题多出现在OEM隐藏了某类会话。比如某些ECU在出厂后通过配置位关闭了编程会话即使你发02 10 02它也只回0x12这时要考虑是不是需要通过特定方式开启“刷写使能”常见手段包括特殊的DID写入或例程触发。0x22则需要结合状态机看。我调试过一个ECU它规定只有在车速为0、挡位P挡、蓄电池电压正常时才能切编程会话。诊断仪在台架上一切正常装车后偶尔失败排查下来是车速信号异常导致0x22。所以看到0x22不要只盯着UDS层要把整车条件一起拉出来。4.2 “没回包”的几种可能从物理层到传输层总线上一片安静原因是多层面的按优先级排查第一功能寻址 vs 物理寻址。诊断请求发到0x7DF功能寻址时所有支持该服务的ECU都可能响应但如果多个ECU同时响应就会冲突实际表现为看到自己的请求却没有稳定响应。所以你用功能寻址去切换会话可能部分ECU回、部分不回。开发阶段建议用物理寻址比如0x7E0逐个ECU精确对话。第二应用报文停发。切到编程会话后ECU可能停发原来的周期报文这会让总线上看起来“没动静”但ECU本身是活的你发诊断请求它照样回。遇到“没回包”先区分是总线上完全没数据还是没有该ECU的应用数据。第三CAN收发器或终端电阻问题。如果请求都发不出去那就不用谈响应。用CANoe的Bus Statistics看一下发送错误计数、总线负载排掉物理层问题再查上层。第四抑制正响应位。前面说过bit 6置1后ECU按协议不回复。这个在量产刷写工具里挺常见工具想减少流量就把正响应关了但你自己调试时容易误判。4.3 时序排查P2/P2*和S3是三个独立时钟很多“会话切不过去”的诡异问题根子都在时序。我分享一个排查思路第一步抓完整交互记录每个请求和响应的时间戳。第二步对比ECU规范里的P2/P2*默认值。如果响应耗时在P2内说明ECU处理正常。第三步如果收到0x78从0x78响应到最终响应之间的时间必须在P2*内超过说明ECU内部逻辑有问题或总线调度问题。第四步看S3。如果你在非默认会话停留超过S3再发下一个请求ECU已经悄悄回默认会话下一个请求大概率0x22。这时候要重新发0x10 03再组合0x3E维持在线。这里有一个非常容易被忽视的细节S3是从ECU收到的最后一条诊断请求开始算的还是从ECU发出最后一条正响应开始算的不同ECU实现有差异。标准语义是基于“接收到的请求”但部分ECU实现基于“发送响应后”。如果你按标准写完工具结果在某个ECU上总是莫名掉会话不妨查一下它协议里的S3处理说明必要时把0x3E发送周期压到2秒以内给“两边时钟计算差异”留出余量。5. 设计一个可靠的会话管理模块5.1 状态机与定时器实现如果你要自己写一个诊断仪或者台架测试脚本建议把会话管理设计成一个独立状态机核心逻辑如下状态DEFAULT(默认)、EXTENDED(扩展)、PROGRAMMING(编程)、SECURITY_UNLOCK(安全解锁后)、ROUTINE_BUSY(例程执行中)。事件收到正响应、收到NRC、收到0x78、S3超时、用户切换请求。动作收到0x10正响应后更新当前会话状态读取响应的P2/P2*参数并更新等待超时。收到0x78后启动P2*等待而不是立即报错。S3定时器在每个请求发出并收到响应后重置如果处于非默认会话且超过S3没有新请求状态切回DEFAULT同时清空安全解锁状态。对CANoe/CAPL实现来说可以用timer变量维护S3倒计时在每个on message里重置。但要注意CAPL的定时器最小精度和系统调度延迟量产工具上建议直接用外部硬定时器或实时系统避免在Windows消息循环里做毫秒级超时不准。5.2 0x3E保活什么时候发、多久发一次0x3ETesterPresent请求报文很简单02 3E 00子功能0x00表示不需要响应0x01表示需要响应。实践中大多数工具发02 3E 00把正响应关了降低总线负载。这没有问题但要注意子功能bit 6同样可以抑制响应0x3E本身子功能的值也影响行为。保活周期建议取S3 Server超时的一半到三分之一。如果ECU的S3是5000ms那0x3E最好2000ms发一次。太频繁会占用总线带宽太稀疏又可能在调度抖动下超时。多ECU并行诊断时比如同时刷多个控制器0x3E和各控制器自己的应用报文叠加总线负载会上去要提前估算负载率不能简单说“2秒一次肯定没问题”。还有一个细节0x3E不能解决所有“保活”问题。某些ECU规定在擦除Flash期间不接受诊断请求包括0x3E。那这种时候0x3E发再多也没用你能做的是在擦除前发最后一次请求然后等P2*过期期间不打扰它。擦除完成后ECU如果回到默认会话你就只能重新走一遍会话切换。5.3 测试用例设计与验证清单我自己写UDS会话功能测试用例时至少会覆盖以下场景默认会话下发送0x10 03验证正响应和会话状态切换。默认会话下发送0x10 02验证是否按OEM要求要先切扩展会话。非默认会话下等待S3超时验证ECU自动回默认会话。非默认会话下持续发送0x3E验证会话不丢失S3不会超时。0x10请求带不同P2/P2*参数看看ECU是否按请求调整实际超时还是忽略请求参数、固定用自己的配置。子功能bit 6置1验证无正响应但功能确实执行了。会话切换失败NRC 0x22、0x12验证后续服务不会被执行。异常场景0x10正响应丢失后诊断仪重发0x10验证ECU能正确响应二次请求。每一条用例都要有明确的通过标准和报文时间戳记录不能只说“响应正常”。比如“会话切换成功”的定义建议写成请求报文发送后在P2时间内收到对应正响应且正响应中的子功能字节与会话模式匹配且在S3超时前后续服务请求可以正常执行。如果是在台架或HIL上做自动化还可以把异常注入比如模拟NRC 0x78、故意不回正响应、模拟总线负载尖峰纳入回归这类问题在实车现场最容易冒出来提前在实验室压一遍能省后续救火的时间。6. 会话切换常见问题的现场排查实录6.1 实录一切到编程会话后ECU“消失”了一台ECU在刷写时一切入编程会话0x10 02诊断仪立刻收不到任何报文包括周期报文和诊断响应。排查过程先看总线是否bus off。CANoe trace显示“Busoff事件”吗没有。再看ECU是否停止发送trace里确实只有诊断仪发出的0x10 02请求之后没有任何ECU帧。查ECU规范发现该ECU设计如此编程会话下会关闭所有非诊断通信而诊断报文只在物理寻址下响应。我们的请求是发到功能寻址0x7DF的也就是说ECU认为是“广播诊断”切到编程会话后根本不处理这种寻址的请求。改为物理寻址0x7E0发送0x10 02ECU立即回复正响应。这个案例想说的是遇到“没回包”先看寻址方式。很多ECU对功能寻址和物理寻址的支持范围不一致尤其是在非默认会话下差别更大。6.2 实录二安全解锁成功的瞬间又回到默认会话另一个现场问题工具发送0x27解锁密钥成功ECU回50 02正响应紧接着工具发送0x31例程结果NRC 0x22。再发0x10读取会话状态发现当前已回到默认会话。逐时间戳分析trace后发现问题出在0x27请求和0x31请求之间隔了1.2秒而这台ECU的S3 Server Timeout是800ms。也就是说解锁成功后工具在等待用户确认界面停留超时触发ECU回默认会话安全解锁状态被清掉。0x31自然失败。解决办法是工具在安全解锁前就预判后续操作把0x27和0x31放到一个连续的自动流程里不要在中间等待人工输入或者在界面上只要有自动防超时机制持续发送0x3E。这个案例在售后诊断工具里特别常见因为人工操作是最大变量所以工具设计一定要把“零等待”作为原则凡是连续动作中间不要加任何人为确认步骤。6.3 实录三P2*误判导致擦除“失败”某次刷写脚本在擦除阶段总报“等待响应超时”排查后发现诊断仪的超时设置是固定的150ms而ECU擦除耗时约3秒。ECU发了NRC 0x78诊断仪虽然收到了但没有根据0x78切换到P2*等待还在用P2的超时值计算于是提前判定失败还发了一个不该发的下一帧请求。这个问题的本质是工具没有正确实现P2机制。0x10响应里明明把P2上报成了5000ms但工具侧没有读取这个值并更新内部超时。所以我在设计诊断栈时有一条铁律所有超时参数必须以ECU在0x10正响应中返回的值为准不能用常量写死。一旦写死换一个ECU型号就可能翻车。6.4 关于“没有session”类似热词的一个澄清有些朋友搜会话切换时会搜到“there is no session with id”“cookie和session的区别”这类内容那是Web开发领域的会话概念和UDS诊断不是一回事。UDS里的Session是ECU工作模式体现在ISO 14229协议层和浏览器、Cookie、Java后端Session没有任何关系。本文通篇讨论的是汽车电子诊断协议里的会话管理看的时候不要混淆。另外也有热词提到“uds 29服务”“uds 19服务”“uds 31服务”由于服务ID都是十六进制0x10、0x19、0x29、0x31这些容易看成序号。0x10就是本文的SessionControl0x19是读取DTC信息0x31是RoutineControl例程控制。需要把“会话切换”放在整个UDS服务矩阵里理解它是其他服务的前置服务典型的“门禁”角色。7. 会话切换后续还能怎么扩展会话切换相关的扩展方向不少顺手提几个我能想到的供读者按自己项目需求深挖。一是多会话与多安全等级的配合。很多新一代ECU除了标准扩展会话和编程会话外还有“安全系统诊断会话”0x04它的权限介于扩展和编程之间用于安全相关的标定与验证。调试这种ECU时会话切换失败的原因清单会多很多安全等级不匹配、校验失败、特定硬件状态不满足。需要把0x10的实现和0x27、0x2F、0x31做一个整体设计不能只把会话切成一块独立逻辑。二是UDS on IPDoIP下的会话管理。以太网诊断里0x10服务的报文格式基本一致但传输层和寻址方式不同且DoIP节点自带路由激活、TCP连接管理等机制。在DoIP环境中会话超时还会和TCP保活、DoIP AliveCheck交织在一起排查难度比CAN更高。搞过CAN UDS再转DoIP最容易忽略的就是“TCP连接还在但诊断会话没了”这种分层错位的问题。三是自动化测试平台中的会话状态监控。我见过很多团队把0x10切换后的状态保存在测试脚本变量里但不从ECU回读实际会话状态导致脚本逻辑和ECU实际状态脱节。更好的做法是在每个关键步骤之前通过0x10?注意0x10只负责切换不能读取当前会话读取当前会话通常通过读取DID F1xx或者0x22服务配合处理或者通过操作结果NRC反推状态。严格说ISO 14229并没有提供“读取当前会话”的标准服务实践中通过0x22读取F1 00sessionIdentifierData这类DID来确认或者直接观察后续服务是否工作来判断。自动化框架里一定不要只依赖脚本内部维护的状态要以ECU反馈为准。四是多控制器同时诊断时的会话协调。同一时刻总线上可能有网关、电驱、BMS等好几个ECU你发功能寻址0x10 03所有ECU都会切到扩展会话但它们各自的S3超时、P2参数可能不同。这时诊断仪要分别维护每一路会话状态不能用一个全局超时一把抓。保活0x3E也要按各ECU规范分别确认是否支持、支持哪个子功能。看起来只是“会话”两个字的服务落实到多ECU并行场景就是一笔不小的工程账。说了这么多会话切换这门“小技术”其实贯穿了整个UDS开发、测试、产线、售后各个环节。我个人在实际操作中最大的体会是不要把0x10当成一个“发一下就完事”的服务要把它背后的时间参数、状态清除条件、NRC条件都吃透遇到问题先查会话状态再查具体功能能少走很多弯路。如果读者之后在实车上遇到任何“明明请求发了就是没反应”的怪事我建议你第一步永远是抓完整报文看会话状态和时序参数——大概率问题就出在这两者之一。