摘要

  • RFC 3433 中的 entPhySensorValue 不是自解释读数。传感器类型、十进制量级和定点精度共同决定整数含义；运行状态、时间戳与更新率则限制它能否代表当前观察。
  • 更新率为零有三种可能：按需更新、事件驱动更新，或代理不知道更新率。ok(1)也只表示代理能够取得数值，不证明校准正确或物理事实真实；阈值报警属于另一个机制。

“315”究竟是什么

管理平台从机箱里读到整数 315。界面可以立刻画出一个数字，却还不能说它是 31.5 摄氏度、315 转每分钟、315 瓦、任意相对量，还是早先轮询留下的旧值。若它其实是溢出标记，把它画进趋势线还会制造一个看似精确的谎言。

2002 年 12 月发布的 RFC 3433为这类物理传感器定义 Entity Sensor MIB。它的纯文本、RFC Editor 资料页、IETF 页面、历史、引用关系和勘误检索保存的是 Standards Track 表示合同，不是某台设备的实测报告。

该模块稀疏扩充 Entity MIB 中 entPhysicalClass 为 sensor(8) 的物理条目。传感器行复用同一个 entPhysicalIndex；代理应在创建物理实体时建立传感器行，在物理实体消失时删除它。RFC 3433 当时依赖 RFC 2737 的 Entity MIB；后来的第四版 RFC 6933延续物理实体索引框架。

这一步先回答“代理说的是哪一个部件”，再谈数值。若身份行已经换过，旧数据即使格式相同，也不能无条件接在同一条曲线上。

三个字段才把整数变成量

RFC 3433 把类型、量级和精度放在数值旁边。类型区分交流电压、直流电压、电流、功率、频率、摄氏温度、相对湿度、转速、气流、真假值，以及 other 和 unknown。量级提供从 yocto 到 yotta 的十进制 SI 前缀。精度对定点数说明小数位，或说明有效准确数字的数量。

三者共同定义 entPhySensorValue 的语义。一个量程 0 至 100 摄氏度、最小步进 0.1 度的传感器，可以用 units 量级、精度 1，并返回 0 至 1000 的整数。此时 315才是 31.5 度。只要类型、量级或精度换一个，同样的 315 就成为另一项主张。

定点类型还把 -1,000,000,000 与 +1,000,000,000 保留为下溢和上溢。它们不是普通测量值。读取者若只保存整数，日后就无法区分极端实值与错误哨兵。

这套设计建立在 SMIv2 上：RFC 2578定义管理信息结构，RFC 2579提供 textual convention，RFC 2580规定一致性声明，RFC 2119解释规范词的强度。

连量级表本身也需要来源回执。已验证勘误 2008 指出原文把 peta(14) 与 exa(15) 的注释次序写反：两者应分别对应 10^15 与 10^18。只读枚举值的程序与只抄注释的人，可能因此对同一数值产生三个数量级的分歧。

小数位不等于测量准确度

“精度”最容易诱导过度结论。RFC 3433 的字段描述定点表示的小数位置或准确数字数量，并不单独证明校准、测量不确定度、溯源链或行业准确度等级。

后来的电力与能耗 MIB RFC 7460明确写出这条边界：RFC 3433 没有 ANSI C12.x 所需的电表准确度等级，所以电力测量另设 eoPowerAccuracy。一个设备能报告一位小数，不代表它真的准确到 0.1 单位。显示位数可以增加，系统误差不会因此消失。

entPhySensorUnitsDisplay也只是面向显示的单位文字。机器解释仍应以类型与量级为准，不能把本地化文字反向当作权威数据模型。

状态是代理知道什么

运行状态有三种。ok(1)表示代理能取得传感器值；unavailable(2)表示目前取不到；nonoperational(3)表示代理认为传感器坏了，包括断线这类硬故障，也包括越界、抖动或剧烈波动等软故障。

这些词刻意描述代理的认知。ok不是独立校准证明，也不保证探头安装位置正确、代理映射无误或现实世界正如整数所示。nonoperational也不能单独诊断根因。

RFC 3410对 Internet 标准管理框架的说明有助于保持层次：MIB 是代理暴露的虚拟信息存储。它经过设备软件、采样策略和访问控制，不能直接等同于物理现实。

时间戳存在，零更新率却没有唯一含义

entPhySensorValueTimeStamp记录代理上次取得状态和/或数值时的 sysUpTime。正数的 entPhySensorValueUpdateRate表示代理两次轮询更新之间可能经过多少毫秒，而且规范承认这个值可能只是估计。

真正值得警惕的是零。对象定义给零列出三种含义：收到请求时按需更新、数值变化时事件驱动更新，或者代理不知道更新率。前两者可能非常新，第三者则明确承认未知。一个数值把两种策略与一种无知压在一起，读取者不能把它自动翻译成“实时”。

规范概览说零表示代理返回当前数据而不是上次轮询值，详细定义却保留三叉语义。负责任的系统应保留原始更新率、采集时刻、sysUpTime、值时间戳、运行状态与实现说明；若无法区分三种零，就应保存“不确定”，而不是替规范作决定。

正数也不是新鲜度证书。它只声明可能的轮询间隔。采集端可以判断时间戳是否落后于预期间隔，却仍不知道传感器内部转换发生在何时，也不知道测量是否准确。

传感器表没有内置报警器

RFC 3433 没有定义专用传感器阈值机制，而是建议采用 RFC 2819 的 RMON Alarm 与 Event 等通用机制。

这意味着数值越过阈值、报警引擎检测到越界、通知成功送达、控制器执行动作，是四项不同事件。Entity Sensor MIB 只提供只读表示，不能证明有人配置了阈值、收到了通知、关闭了硬件或修复了故障。

审计历史高温值时也必须重建整个元组：类型和量级是否正确，状态是否可用，数值是否新鲜，策略当时是否要求动作。单独一条高整数不够。

只读数据仍可能敏感

RFC 3433 特别指出 entPhySensorValue 可能暴露设备的物理传感器信息。它警告 SNMPv1 本身不是安全环境；即使外围网络用了 IPsec，也不等于网内任何主体都有权读取每个对象。

规范建议使用 RFC 3414 的 SNMPv3 USM 与 RFC 3415 的 VACM。认证、隐私与可见视图属于访问回执，不属于温度或电压数值本身。

一次成功 GET 可以证明某个获准主体收到了代理暴露的表示，却不能证明传感器校准正确、物理索引映射无误或返回值仍对应此刻世界。

来源与证据边界

本文也采用 Heng Lu 关于现实层次与运行代码作为一手证据的分析纪律：规范字段、代理实现、GET 返回值、物理电压、报警事件与运营结果互相关联，却不可互换。

这 20 个来源定义历史合同及其后来边界，不证明任何具名产品部署、采用率、传感器准确度、现实事故、安全入侵、报警送达、修复或业务结果。RFC 3433 的持久价值更克制：它拒绝让一个裸整数冒充完整测量。