06 · 开发 · 月台探头
探头离线了，温度不能沿用上一车的数
物联网工程师把探头读数接成可核对的事件。采集不到就要显式失败，不能补一个看起来正常的值。能不能收货仍由业务服务判断。
- 06:00 对时。 探头时间和服务器差了四分钟，事件先校正再入库。
- 06:20 离线。 月台探头无心跳。收货页面显示无法测温，不显示昨天下午的温度。
- 07:10 恢复。 补传的数据带采集时间，不覆盖已经拒收的车次。
物联网工程师把设备和单据连起来，而不是只把数存下来
探头、扫码闸、电子秤、门禁都会往系统里送数。物联网工程师的特点是规定这些数在什么情况下有效。有心跳、时间可信、设备属于这个月台，三个条件缺一个，读数就不能参与收货判断。他把离线做成业务状态，交给收货流程：无法测温就走人工测温并留证据，而不是让系统自动填一个默认温度。默认温度会让不合格的车次看起来合格。
他和后端的分工：设备接入、协议、重连、补传由他负责；能否收货的规则仍由业务服务判断。他不在网关里直接改库存。网关只产生「某月台某时温度是多少」或「某时没有读数」的事件。没有读数也是事件，不能省略。
补传最容易把历史改错
网络恢复后设备会补发几小时的数据。如果按到达服务器的时间入库，早上的拒收会被下午的温度改写。物联网工程师要求事件时间用设备采集时间，并且业务单据一旦关闭就不再接受新的测温去改结论。补传只追加审计，不翻案。时钟漂移超过阈值的设备先告警，不参与判断，直到校时完成。
设备档案要有主人：这只探头属于哪个月台、校准到期日、替代探头是哪只。没有档案的设备上报，只进隔离区，不进生产规则。否则隔壁工地的测试设备会把数打进正式仓库。
沿用上一车温度的事故
冷链仓有一次探头离线，页面仍显示 2℃，那是上一车留下的缓存。新的一车实际更高，货却卸了。物联网工程师取消缓存展示，离线时接口返回无读数，收货服务拒绝自动放行。恢复后的补传写在车次日志里，已卸的那车走差异，不用新温度假装当时合格。之后心跳超过两分钟无更新，月台屏上就是离线，不再是一个静止的数字。
实施时他和仓管一起做一次拔网线演练。演练不过，设备不算接入完成。同一月台换探头时，他要求新旧编号有交接记录，历史温度仍归在当时的设备上。不交接就把新探头的数写进旧曲线，事故复查会以为温度一直正常。曲线可以续，编号不能偷换。设备维护时要有明确的停用状态，停用期间的读数不进规则。维护结束重新启用前，先看时钟、心跳和库位归属，三项齐了才让温度再次参与收货。
校准到期的探头他提前两周告警，到期当天退出自动判断，改成人工测温。不告警而继续使用过期探头，读数仍会很稳定，稳定的错数比离线更难发现。离线至少页面是空的，过期却会给出一个很像样的温度。
温区规则由行业顾问写入方案，本岗不改那条行业词。网关只产生「某月台某时温度是多少」或「某时没有读数」。没有读数也是事件。设备档案写明主人、校准到期日和替代探头。没有档案的上报只进隔离区。隔壁工地的测试设备不能把数打进正式仓库。拔网线演练不过，设备不算接入完成。行业顾问证明温区不能抄；物联网工程师证明离线不能装合格。