“安全数据放在边缘端（Edge），碳数据放在云端（Cloud）”这句话很容易理解。因为气体风险警报需要立即响应，而长期碳分析需要大量存储空间和计算资源。然而，如果实际系统只被划分为这两类，一些重要问题就会被遗漏：安全事件的历史记录是否无需保存在云端？碳原始数据是否可以在互联网中断时丢弃？现场校正和质量检查应在哪里执行？
数据部署不应由数据名称决定，而应依据作出决策的时限、对连接中断的容忍度、原始数据保存、计算量、机密性和现场恢复能力来决定。同一次甲烷观测既可立即用于本地警报，也可在之后再次用于每日质量检查和每月碳汇总。因此，现实的架构并不是在 Edge 和 Cloud 之间二选一，而是划分各项功能和数据副本的作用。
纠正常见误解：先确定责任，再决定位置
Edge 可以指传感器内部、网关、农场服务器等靠近数据产生源的计算和存储区域。Cloud 则指远程且可扩展的存储与分析服务。NIST SP 500-325 指出，大规模、异构的物联网（IoT）以及高延迟可能给传统的云中心架构带来挑战，并介绍了将计算、管理和分析分布到网络近端的雾计算模型。
但 Edge 并不总是快速且安全，Cloud 也并不总是缓慢且不可靠。供电不稳的现场网关可能比云端更频繁地停机，而缺乏管理的本地设备可能难以修补和备份。相反，云端适合系统化地进行长期保存、版本管理、多农场比较和访问审计，却无法在外部网络中断时保证现场处置。
因此，应先确定各项功能的责任。危险阈值判断、警示灯启动和安全通风联锁是否必须在任何故障下都能在现场持续运行？原始数据采集和缓冲需要经受数小时还是数天的中断？为了保证可复现性和审批流程，应在何处以哪个代码版本执行碳计算？这些问题的答案决定部署位置。
第一项原则：保护生命和设备的控制回路要在现场闭环
与人员、动物或设备安全直接相关的功能，不能以互联网往返通信为前提。当气体浓度超过危险阈值时，发出警报或将通风设备切换到安全状态的判断必须继续在本地运行。云端可以监控状态并下发策略，但即使连接中断，也应依靠最后经过验证的安全规则和本地传感器输入维持保护功能。
这里不能把用于碳核算的甲烷分析与用于安全的气体检测混为一谈。二者的测量范围、响应时间、安装位置、认证和故障安全要求可能不同。一个传感器的数值能否兼用于两种用途，应通过设备规格和风险评估确认。不得假定碳模型的校正或 AI 异常检测可以替代法定或现场安全装置。
NIST SP 800-82 说明，OT 会感知物理环境或直接引发其中的变化，因此安全措施也必须考虑性能、可靠性和安全要求。安全控制路径需要具备最小功能、优先级、手动切换、故障状态和定期测试。应设置权限边界，防止云端指令绕过本地保护装置。
第二项原则：碳原始数据也必须能在 Edge 存活
碳数据在月末汇总，并不意味着无需现场存储。农村地区的通信可能中断，网关与云端之间也会发生延迟和重传。Edge 应按顺序缓冲原始数据并附加完整性信息，在连接恢复后重新发送。存储容量不应按平均数据产生量确定，而应根据预计最长中断时间、重传余量和安全日志的优先级来确定。
缓冲区不能只是简单的文件夹，还需要明确的队列策略。每条记录都应附有设备 ID、观测时间、接收时间、序号、单位、质量状态以及哈希或签名。只有收到上传确认后，才能依据本地保存策略删除记录；重复传输应通过唯一键安全处理。还必须确定存储空间不足时优先保留什么。安全事件原文以及校准和配置变更日志，可能需要比日常高频环境值保存更长时间。
本地汇总可以减少传输量，但也有过早丢弃原始数据的风险。如果只发送 1 秒读数的 10 分钟平均值，日后就很难重新检查峰值和设备异常。应先确定碳测量、报告与核查（MRV）所需的时间分辨率和可审计性，再为原始数据、摘要和事件设计不同的保存期限。
第三项原则：由 Cloud 承担长期沿袭关系和跨农场分析
云端的优势在于按照统一规则存储多个农场的数据、进行长期比较，并管理计算版本和审批历史。系统应能关联甲烷原始数据、校准记录、饲养数量、饲喂、通风和气象数据，计算基线与减排量；当方法学、排放因子或代码发生变化时，还应能够复现先前结果。
与其把云端存储的数值称为唯一事实来源，不如为各个数据阶段分别确定权威来源。设备原始信号、网关接收记录、校正数据、用于分析的清洗数据以及获批的报告结果，都是服务于不同目的的记录。不要覆盖原始数据，而要连接各个派生阶段和计算沿袭关系。OGC SensorThings 等标准模型可以作为一致交换异构传感器观测及其元数据的参考。
云端可以为多个农场运行大型模型，并检测整个设备群的漂移。但将训练后的模型或阈值下发到 Edge 时，必须管理版本、签名、审批人、适用对象和回滚。因为模型部署与固件一样，都是把远程代码引入现场决策的变更。
现场场景：36 小时通信中断
假设台风导致某农场的外部网络中断 36 小时。在良好的架构中，本地安全警报和通风保护会继续运行。网关以 UTC 时间和序号保存传感器观测以及风机和警报事件，屏幕上则显示云端连接异常和缓冲区的剩余可用时间。现场负责人能够查看本地状态并执行手动程序。
连接恢复后，网关从最早的观测开始重传。云端按照原始观测时间而非接收时间排列数据，在去重的同时检查原始序号是否缺失。系统重新执行 36 小时内未能运行的中央质量检查和汇总，并标记延迟上传的区间。只有在确认完整性后，才更新每月碳报告。
在不良架构中，安全警报会等待云端 API 的响应，碳原始数据会因没有缓冲而消失，或者恢复后所有数值都以当前时间存储。问题不在于选择 Edge 还是 Cloud，而在于没有设计故障期间各项功能的责任和恢复顺序。
决定数据部署位置的五个问题
第一，必须在几秒内作出决定？第二，连接中断几小时后功能仍需继续运行？第三，错误决定造成的损害会发生在安全、生产还是报告环节？第四，原始数据需要保存多久，才能实现复现和验证？第五，在设备和云端之间，哪一侧能够更稳定地执行安全修补、访问控制和审计？
根据这些问题对数据进行分类。例如，P0 安全控制负责本地判断和本地输出；P1 安全与运营事件采用本地即时保存和云端复制；P2 碳原始数据采用本地缓冲和可靠重传；P3 长期分析与报告采用云端计算和审批；P4 模型与配置采用集中管理和签名后的现场部署。具体等级名称可以按组织需要调整，但原则应保持不变。
实施检查清单
列出由数据支持的各项决策及其最大允许延迟，而不是只列数据本身。
测试安全控制能否在没有互联网和云端的情况下继续运行。
根据最长中断时间和数据产生量估算碳原始数据缓冲区。
在重传过程中也要保留观测时间、序号、设备 ID 和质量标记。
制定去重、缺失检测、上传确认和重试规则。
分别规定原始数据、摘要、事件和审计日志的保存期限。
为 Edge 和 Cloud 分别指定访问权限、密钥、修补、备份和恢复的责任人。
模型与配置的部署应采用签名、金丝雀发布、审批和回滚。
标示延迟上传和模型替代区间对碳结果的影响。
定期开展通信中断、存储空间不足和云端故障演练。
结论
“安全数据放在 Edge、碳数据放在 Cloud”是一个有用的起点，却不是完整的设计。安全判断必须在现场闭环，碳原始数据也必须在连接中断期间于现场存活。云端则在长期沿袭关系、多农场比较、大规模分析和经批准的报告方面具有优势。
良好的数据部署策略不会让 Edge 与 Cloud 相互竞争。它把即时性和韧性交给现场，把可扩展性和可复现性交给中央，并连接两者的责任，使同一记录能够无损流转。最重要的检验不是系统正常时的仪表板，而是切断互联网时的表现。此时，如果安全功能仍能维持、碳原始数据得到保存，并在恢复后回到同一时间轴上，就说明部署策略已经能够经受真实现场的考验。