为什么我们不要你的 CAN 协议
有一句话卡住的车联网项目，比任何硬件问题都多：*「请提供你们的 CAN 协议。」*
它听起来像个技术要求，其实是个组织问题 —— 而且项目往往就死在这里。不是因为提要求的人不讲理，
而是因为被要求的那一方没法很快给出答复。这篇讲：我们为什么从不问这句话，改问什么，以及它在
实践中改变什么。
这句话本质上是在要一份内部文件的对外释放
如果你是做整机的，你的 CAN 定义就是内部文档。它描述了你控制器的信号、标度、时序和故障语义。
把它交给供应商，意味着：
- 要走内部审批 —— 因为协议文档通常不止包含供应商要的那一个信号；
- 要过法务 —— 因为文档描述的是你产品的行为；
- 要面对维护问题 —— 一旦外面有了副本，每次固件改版，让那份副本跟上就是你的活。
这些都不是做不到，而是都慢，而且都不在供应商的排期里。于是一个本该三月启动的项目拖到九月 ——
到那时预算的负责人可能已经换人了。
这才是那句话的真实成本：不是手续，是拖延。
我们改问什么
我们只要一张清单。要求就这么点：
1. 哪些值重要 —— 油压、液压温度、工作小时、载荷、转速，机器需要报什么就写什么。要名字，
不要映射。
2. 你习惯用什么单位 —— bar 还是 kPa，摄氏度，小时，计数。
3. 每个值多久报一次才有意义 —— 温度一分钟一次足够；故障标志必须立刻。
4. 数据要到哪里 —— 你的平台、你的车队系统、一个文件，还是一个 ERP 接口。
有了这张清单，我们在自己这一侧做采样计划，把数值通过 API 交出去。你信号到我们报文的映射写一次，
写成一份文档留给你，改动权也在你。
关键的是「没有离开你组织」的那些东西：协议文档、DBC 文件、固件。
为什么这不等于 OBD 那类行车电脑读取
有一种常见误解：任何不靠协议就能读整车数据的设备，都是在用标准化诊断做文章。那是另一类产品，
也有另一个限制 —— 它只看得到通用诊断层暴露的那一小部分，而那一小部分远小于机器真正知道的东西。
我们不做这个交换。设备直接读 CAN 总线，按机器实际的波特率，报文按项目选。区别只在于
定义由谁持有 —— 由你持有，我们基于你开放的哪些数据点工作。所以当那个真正有价值的信号
不在任何标准诊断集里时，这套做法依然成立。
客户实际怎么用它（四种）
定时查询。 平台按自己定的间隔要一个值。适合慢信号 —— 液压温度、电池电压、小时表：趋势比瞬间
更重要。终端应答，不做连续推流。
变化触发上报。 数值越过阈值或发生变动时报一次，再加一个心跳，让你知道机器在线且没变化。
对车队来说这是运行成本上最大的一处差别 —— 安静是便宜的，持续推流不是。
远程调参。 CAN 波特率和采样点可以远程改。这件事的意义比听起来大：同一款终端就能服务不同机型，
一个混合机队不会变成混合备件问题。
CAN 透传升级外挂 ECU / VCU。 终端转发 CAN 流量，让远端工具能和外挂控制器对话 —— 改参数，
以及在项目允许的范围里做固件升级。这属于定制范围，按项目约定，不是目录上的功能。
还得谈定的事（这块我不粉饰）
诚实比一个漂亮说法更重要，所以说清这套做法没有省掉什么：
- 数据点清单仍然是一份规格。 你那边得有人决定值不值得报。我们没法从一个型号猜出来。
- API 契约要写。 报文字段、单位、时间戳，以及某个传感器漏读一次时报文长什么样 —— 这是文档，
要双方各出一个小时。
- 消费端是你的活。 平台侧的对接是你的；我们交数值，不替你接看板。
- 改装是现场活。 终端装哪儿、怎么取电、线束怎么走，是现场决定，不是软件决定。
为什么第一个数据点来得快
第一个数据点常常在一天左右的联合工作内能跑通，不是因为工程简单，而是因为关键路径短：没有
协议释放要批，没有文档要脱敏，没有信号定义要过法务。两个工程师对五个字段名和一个间隔达成一致，
数字就开始来了。
这就是全部论点。差异化不在硬件，在审批路径。
接下来看哪里
如果你在回答的问题是「能不能拿到机器数据、又不交 CAN 定义」，答案是可以 ——
架构在 CAN 转 4G 车联网页，更细的接口说明在 CAN 协议 API 页。
如果你要的是接口选型而不是 API，CAN 总线车联网 讲了三种接法。
如果你要记的是工况而不是报警，车队数据记录器 讲变化上报那套。
如果你已经知道自己要什么，把清单发过来：哪些值、什么单位、多久一次、发到哪里。有这四条就够
我们书面回答：硬件暴露什么、你的集成方还需要做什么。把数据清单发给我们。