第一章 诊断的起源 —— 从望闻问切到ECU自白

1.1 望闻问切——人类诊断的原型

你会看病吗？

这个问题听起来荒谬。你既不是医生，也没读过八年医学院，你当然不会看病。

但如果我换一种问法：你家里的路由器突然连不上网了，你怎么排查？

你可能会说，我先看看灯——电源灯亮吗？WAN口灯在闪吗？WiFi灯是什么颜色？——这叫望。

你可能会说，我打开手机看看WiFi列表——搜不搜得到这个路由器？搜到了但密码弹不弹？——这叫闻。

你可能会说，我ping一下192.168.1.1，看通不通。——这叫问。

你可能会说，我重启一下，按住reset 15秒强制恢复出厂。——这叫切（脉）。

你确实会看病。你只是没意识到自己在看病。当你面对一个不透明的系统、不能直接打开看它里面发生了什么的时候，你就进入了一个叫作诊断的人类古老活动里。路由器也好，保时捷的ECU也罢，诊断的姿态是相通的。

两千年前的那个下午

你是一个中医。诊室里躺着一个昏迷的病人。

你不能剖开他的身体。你不能打开胸腔看心跳有没有异常。你不能抽出血液做生化全套。你不能拍CT。你不能插窥镜。

你手里只有四种工具：

四诊之中，望和闻是被动收集——你接收病人自然散发的外部信号。问和切是主动探查——你发出一个刺激（“告诉我什么时候开始的”“我按这里你疼不疼”），观察病人的反应。

如果你仔细看这四种姿态，会发现它们落在两个正交的维度上。第一个维度是被动接收 vs 主动探查——望和闻是被动的，你接收系统自然散发的信号；问和切是主动的，你需要发出一个刺激（提问、按压）才能获得回应。第二个维度是外部信号 vs 返回信息——望和切作用于物理层面（面色、脉搏），闻和问作用于信息层面（呼吸声、患者陈述）。这两个维度交叉，恰好构成了诊断活动的完整覆盖。

核心洞察：一切诊断系统——无论对象是人体、发动机、还是分布式计算集群——都必须同时具备这两种能力。被动的监视让你知道异常何时发生。主动的探查让你在异常发生后确定它的位置和性质。缺了任何一边，你都不叫诊断——你叫猜测。

但两千年前的中医并没有发明诊断。他只是被发现了一个道理：要了解一个不透明系统的内部状态，你只能通过它向你暴露的接口。

机器的沉默

现在换一个场景。你站在1965年底特律的一家维修车间里。

一辆V8引擎轿车因“间歇性动力丧失“被拖进来。没有故障码。没有DTC。没有诊断座。你打开发动机盖，面对的是一只彻底沉默的金属疙瘩。当然，1965年的V8引擎还没有ECU——“说“的前提是电子控制单元的出现，而那个时代连晶体管收音机都还是奢侈品。

它会执行功能。踩下油门，活塞运动，曲轴旋转，尾气排出。但它从不解剖自身。它不告诉你每一个气缸的燃烧是否正常。它不告诉你进气歧管下面有一条只有在热胀时才显现的发丝裂纹。

你只能拆。

第一天：换分电器盖——没用。 第二天：调化油器混合比——没用。 第三天：把整个进气系统解下来。在进气管垫片上找到那条头发丝一样的缝。诊断完成。

诊断耗时：数天到数周。确诊手段：排除法。诊断的本质：这不是诊断，这是法医解剖。

把这段经历和中医诊脉对比：

区别不在人，在系统。病人会自我报告症状，机器（1965年的）不会。

核心洞察：一个系统有两种存在方式。第一种——只能做，不能说。它执行功能，从不解释状态。当它出问题时，你只能从外部观察、猜测、逐层拆解。第二种——不仅会做，还会说。它内置了自我监测回路。每个异常条件主动记录。每个内部状态愿意公开。当出问题时，它告诉你哪里不对、什么时候开始不对、附带什么上下文数据。整个UDS协议——以及更广义上的一切诊断系统——都是在回答同一个问题：如何让第一种系统变成第二种系统。

诊断的生命周期

不只是汽车。你回顾自己生活中每一个“排查故障“的场景，都会撞上同一套步骤：

第一步：发现异常。 你的WiFi突然不能用了。你怎么知道？不是因为你ping了网关——是因为手机屏幕上WiFi图标消失了。异常首先表现为外部可观测行为的改变。

第二步：缩小范围。 是你一个人不能用，还是全家人不能用？你问了室友——室友说我的也不行了。好了，不是你手机的问题，是路由器或者宽带的问题。

排除法为什么痛苦：每排除一个假设，往往需要一次完整的系统复位或环境重现。对于偶发故障，这可能意味着数小时的路试或数十次上电循环——你真正排查的不是故障，是在一次一次地等故障自己再出现一次。诊断协议之所以有价值，正是因为它让你从“排除所有可能性“变成“直接读取答案“。

排除法永远不是优选方案，却是最后的保底方案。

第三步：收集信息。 你先做被动的——望：去看路由器指示灯。电源灯亮了吗？WAN口灯在闪吗？WiFi灯是什么颜色？——灯全正常，但WiFi连不上。再做主动的——问：打开cmd、ping 192.168.1.1——通了，路由器的CPU还活着，那就不是硬件坏了，问题出在WiFi链路。“被动观察在先，主动探查在后“的顺序，与中医四诊的“望闻为先、问切为后“如出一辙。

第四步：干预/修复。 拔电源、等10秒、插上电——回魂了。你执行了一次硬复位。如果这样不行，按住reset 15秒——执行了一次强制恢复出厂设置。

注：此处“问“先于“切“对应中医四诊的“先问后切“顺序——先通过对话收集信息（ping），再执行干预式检查（reset）。

这四步——发现→定位→收集→修复——横跨人体医学、计算机网络、汽车维修、航空航天诊断，没有例外。本章描述的是一套哲学框架，后续章节将按 ISO 14229-1 定义的标准诊断流程展开。 因为所有复杂系统都遵循一条铁律：

系统的内部状态无法被直接观测。你无法把脑袋伸进路由器芯片看寄存器值，无法实时观测手机刷写时每个存储单元的电荷状态变化。你只能通过系统暴露给你的有限接口，推断它里面发生了什么。

工程师为什么需要诊断协议

你可能会说，我不能买工具吗？——1965年底特律的技师用了数天到数周排查一个进气漏气故障，如果当时有OBD诊断仪和UDS协议，他大概只需要30秒。工具一直在进步。

但工具需要遵守一种语言。你买了一个五万元诊断仪，屏幕上五彩斑斓，柱状图动态跳动——但如果这辆车的ECU说一口你从来没听过的私有协议，你的五万元诊断仪和一块石头没有区别。

语言的本质不是让说话的人更舒服——是让听话的人能理解。诊断协议的本质不是让ECU更方便地描述自己——是让诊断仪不用猜。

核心洞察：诊断协议解决的不是“机器能不能说话“的问题。解决的是“不同人做的机器，能不能对同一个人说一种话“的问题。标准化，永远是诊断的核心议题。

一切诊断都有一个主谓宾结构

回顾你面对过的所有排查场景，去掉技术细节，你会发现所有诊断活动都遵循一个不变的语构骨架：

诊断仪（主语）  向  ECU（宾语）  发出一个  请求（谓语）。
ECU（主语）  向  诊断仪（宾语）  返回一个  响应（谓语）。

汽车电子把它定式为 Client（诊断仪） — Server（ECU） ，这是一个经典的不对称C/S模型——发起者总是诊断仪，ECU被动应答。为什么不是双向的？从总线仲裁角度看：CAN总线上如果几十个ECU都能随时主动发起诊断通信，优先级竞争和帧碰撞将导致网络利用率急剧下降（你让发动机ECU和车窗ECU同时说话，谁先谁后？）。从会话管理角度看：诊断活动总是由外部工具发起——ECU不知道诊断仪什么时候连上来、想问什么，因而被设计为仅被动响应。这是一个经过简化比喻的解释——真实的CAN总线仲裁和诊断会话管理远比这复杂，将在第3章和第2.2节中详细展开。

望闻问切在汽车上的映射是这样的：

趣味延伸：如果继续用中医治疗手段延伸，可以将 0x31 RoutineControl（执行ABS泵自检等预设流程）类比为“针灸“——一种标准化的高强度干预方案（注：部分Routine实际是不可逆操作，此处仅为帮助记忆的非精确类比）；将 0x34/0x36/0x37 固件刷写类比为“手术“——结构的永久性改变。这些类比能帮助记忆，但超出了“四诊“原范畴，特此标注。

两千年后，你一头扎进ISO 14229标准的时候，本质上还是在做两千年前那套动作——只是把银针换成了CAN帧，把脉象换成了DTC状态字节。

本篇小结

1. 诊断的本质是通过有限的外部接口推断不透明系统的内部状态。这个命题横跨人体医学、计算机网络、汽车维修——不变的是推导逻辑，不是具体工具。
2. 诊断能力需要两部分构成：被动监视（望、闻）让系统自动报告异常；主动探查（问、切）让人在异常发生后确定位置和性质。
3. 1965年的车只有第一种（做），没有第二种（说）。诊断=拆开看。整个汽车诊断的历史，就是把“拆“变成“问“的历史。
4. 诊断协议的核心价值不在于让ECU说话——某个ECU从一开始就有能力说话——在于让不同ECU说同一种话。标准化永远是诊断的第一议题。

术语说明：本书后续将统一把外部诊断工具称为诊断仪（Client） ，把被诊断的控制器称为ECU（Server） 。Client/Server这对概念在诊断语境中是不对称的——发起方总是Client，Server仅被动响应。在UDS标准（ISO 14229-1）中，这对术语称为诊断仪（tester）和ECU，本书交替使用中文与英文术语以便读者习惯两种语境。

【下集预告】：古代的中医面对病人只能说望闻问切。1980年代，第一代ECU出现了——汽车有了第一盏“我会喊疼“的灯。那盏黄色的Check Engine灯，是汽车学会说的第一个人类词语。它是怎么来的？为什么只亮灯，不多说一个字？我们下集走进——“听诊器到故障灯：汽车诊断的第一次哭喊”。