Day31-24｜11.1.3 信息物理系统的建设和应用：从概念验证走向可运营的闭环系统

一、教材定位

本节位于《系统架构设计师教程（第2版）》第11章“未来信息综合技术”的信息物理系统技术概述部分，承接 11.1.1“信息物理系统的概念”和 11.1.2“CPS 的实现”。前两节回答“CPS 是什么、由哪些技术实现”，本节进一步回答“CPS 如何建设、怎样在真实业务中运行并产生价值”。

系统架构设计师考试不会只要求考生背出 CPS 的定义。更常见的考查方式是给出智能制造、智慧交通、智能电网、智慧医疗或智能物流场景，要求分析系统建设目标、划分系统层次、说明数据与控制闭环、选择边缘和云的部署位置，并讨论安全、可靠性、实时性和运维问题。因此，学习本节要建立一条完整主线：

业务目标 → 物理对象建模 → 感知与连接 → 边缘控制 → 平台协同 → 应用决策 → 执行反馈 → 运营评价。

如果只写“采集数据、上传云端、人工智能分析”，答案通常停留在产品宣传层面；如果能写清楚控制对象、时延约束、数据质量、异常降级、权限边界和建设阶段，才符合高级系统架构设计师的答题要求。

二、什么是 CPS 建设

CPS 建设不是一次性采购一批传感器，也不是把传统系统简单迁移到云平台。它是将物理世界中的设备、人员、环境、流程和规则，与信息世界中的数据、模型、软件、网络和服务组织成一个可以感知、分析、决策、执行和反馈的工程系统。

可以将 CPS 建设理解为三个同时进行的过程。

第一是物理对象数字化。系统要识别设备、部件、位置、状态、能力和运行边界，把原来依靠人工经验或纸质记录表达的对象转化为可测量、可追踪的数字对象。

第二是控制闭环自动化。系统不只生成报表，还要根据感知结果进行诊断、预测、调度或控制，并把结果安全地作用于物理对象。闭环越接近实时控制，越需要确定性、冗余和失效安全。

第三是业务运营智能化。系统需要把设备数据与生产计划、维护工单、能源管理、质量管理和组织权限连接起来，使信息成为业务决策的一部分，而不是形成新的数据孤岛。

三、CPS 建设的目标分解

面对一个 CPS 项目，第一步不是选择产品，而是把目标拆成可验证的质量指标。建议从价值目标、控制目标、数据目标和治理目标四类进行分析。

例如，某工厂提出“建设智能生产线”。这句话不能直接指导架构设计，需要继续追问：是要实时发现设备振动异常，还是要自动调整工艺参数？异常发现允许延迟几秒？调整参数必须经过人工审批吗？网络中断后生产线是否可以继续？当传感器不可信时，设备进入降速、保持还是停机状态？这些问题决定了功能放在设备、边缘还是云端，也决定了系统的安全等级和测试方法。

四、CPS 的典型建设架构

一个通用的 CPS 建设架构可以分为物理层、接入层、边缘层、平台层、应用层和治理运维层。分层不是固定模板，而是为了说明职责、边界和数据流。

从数据流看，物理层产生观测数据，经接入层进入边缘层，边缘层进行校验、聚合和局部决策，再将必要数据发送到平台和应用；从控制流看，应用或平台生成的策略必须经过授权、状态检查和安全约束，才能下发到边缘和设备。数据流可以相对开放，控制流必须严格收敛。

五、建设生命周期

1. 需求与可行性分析

需求分析要同时识别业务需求和物理约束。业务人员关心产能、质量和成本，设备工程师关心接口、节拍和安全，运维人员关心故障恢复，安全人员关心身份、网络和审计。架构师需要将这些要求转换成可测量的质量场景。

例如，“设备故障要及时发现”应改写为：当关键设备的振动指标连续三次超过阈值时，边缘节点在 500 毫秒内生成告警，网络中断时本地保存告警，恢复后补传，维护人员在 2 分钟内收到通知。这样才可以验证架构是否满足要求。

可行性分析还要检查设备是否有可用接口、历史数据是否可信、现场网络是否覆盖、改造是否影响生产、人员是否能够维护，以及数据采集是否涉及隐私和关键基础设施安全。若忽略这些条件，项目可能在实验室成功、在现场失败。

2. 试点和概念验证

CPS 适合先选择边界清晰、风险可控、价值可量化的对象进行试点。试点不应只展示大屏，而要验证端到端闭环：设备能否接入，数据是否准确，边缘是否能独立运行，异常是否能触发动作，平台是否能留痕，人员是否能处理告警。

概念验证应设置基线和退出条件。例如改造前设备平均故障停机 20 小时/月，试点目标是降低到 15 小时/月；告警误报率不高于 10%；断网 30 分钟期间关键控制不失效；升级失败后 5 分钟内恢复到上一稳定版本。如果只有“用户觉得效果不错”而没有指标，就无法判断是否值得推广。

3. 规模化建设

试点成功后，架构要从“能运行”提升到“可复制”。需要统一设备模型、测点命名、单位、时间戳、接口协议、告警等级、身份管理、日志格式和版本规则。规模化时重点关注数量增长带来的问题：设备注册是否自动化，证书是否能批量轮换，边缘节点是否可远程管理，数据平台是否会被高频数据压垮，模型是否能适配不同设备。

规模化不等于所有设备使用完全相同的模板。应将共性能力平台化，将差异通过配置、插件和设备能力模型表达。把每种设备都写成一套独立代码，会导致维护成本随设备数量线性甚至指数增长。

4. 运行、评价和持续改进

CPS 上线后，设备、配置、模型、规则和证书都可能变化，因此必须建立持续运营机制。运维人员需要知道当前有哪些设备、运行什么固件、使用什么规则、连接到哪个边缘节点、最近一次校准是什么时候、是否存在未关闭告警。

运营评价应同时看业务指标和系统指标。业务指标包括产能、质量、能耗、故障率和维护成本；系统指标包括数据完整率、边缘在线率、控制时延、告警准确率、恢复时间、升级成功率和安全事件数。若系统指标很好但业务没有改善，说明采集与决策没有真正进入业务流程；若业务短期改善但安全事件和维护成本不断上升，说明架构不可持续。

六、关键技术与架构决策

1. 设备接入与协议适配

现场通常存在不同厂家、不同年代和不同协议的设备。接入架构可以采用协议适配器、统一设备模型和消息总线，将协议差异隔离在接入边界。适配器应保留原始报文、来源设备、时间戳和质量标识，避免转换过程丢失上下文。

对于只能单向采集的旧设备，先实现监测和告警，再逐步增加控制能力；对于具备开放控制接口的设备，也不能因为接口可调用就直接开放远程写入，必须经过安全互锁和审批策略。

2. 边缘计算与云计算的分工

功能部署要按时延、数据量、连接稳定性、隐私和全局性进行权衡。

边缘节点要有明确的离线策略：哪些规则可以继续运行，哪些功能必须停止，缓存保存多久，恢复后如何补传，云端策略过期如何处理。没有离线策略的“边缘计算”只是把服务器搬到了现场。

3. 数据质量与时间一致性

CPS 的数据不是普通业务表格。一个测点数值必须知道来源、时间、单位、精度、校准状态和质量码。应区分原始值、清洗值、估计值和预测值；应记录数据处理规则版本；对关键控制量应支持多源校验、范围校验和变化率校验。

时间一致性尤其重要。多个设备的事件如果没有统一时钟，可能把因果关系判断错误。架构设计时要规定时间同步机制、允许偏差、时间戳产生位置和异常时钟处理方式。跨系统分析不能只依赖数据库写入时间，因为网络延迟会改变事件顺序。

4. 安全与功能安全

CPS 同时面对网络攻击和物理风险，安全设计不能只停留在账号密码。设备应有唯一身份、安全启动、固件签名、密钥保护和调试接口管理；网络应进行分区分域、访问控制、加密和异常监测；平台应实行最小权限、租户隔离、命令审批和审计。

功能安全关注“系统发生故障时如何避免造成不可接受的后果”。传感器不可信时，系统可以采用冗余测量、降级运行、限制输出或安全停止；控制器异常时，可以通过看门狗、备用控制器和人工接管恢复。网络安全措施不能替代功能安全，认证成功的恶意命令仍然可能造成危险，因此每一条控制命令都需要状态和范围校验。

5. 模型、规则与配置治理

CPS 的行为不仅由代码决定，还由规则、阈值、模型、设备参数和策略决定。这些对象应纳入版本管理，记录创建者、适用设备、发布时间、生效条件、回退版本和审批记录。模型上线前要验证训练数据质量、适用范围和漂移情况；规则变化要评估对控制闭环和告警数量的影响。

升级应采用签名、灰度、分批、健康检查和自动回退。边缘节点不可用时，平台不能无限重试造成现场压力；升级过程中也要保留安全策略，不能因为更换版本而失去急停和限位能力。

七、典型应用场景

1. 智能制造

在智能制造中，CPS 将机床、机器人、生产线、质量检测和生产管理连接起来。设备采集振动、温度、位置和能耗数据，边缘节点进行实时质量判断和设备联锁，平台进行预测性维护、产能分析和跨产线调度。架构重点是确定性通信、设备异构接入、实时控制、质量追溯和安全隔离。

2. 智慧交通

交通信号机、车辆、道路传感器、摄像头和中心平台形成 CPS。路口控制需要本地实时决策，中心平台进行区域协调和历史优化。通信中断时路口应进入预设安全策略，不能因中心不可达而失去基本通行能力。涉及视频和车辆数据时，还要考虑隐私保护、数据分级和访问审计。

3. 智能电网

智能电网需要同时处理发电、输配电、负荷和储能对象。系统既要保证实时保护，又要支持全局调度和状态估计。保护动作必须由本地高可靠系统完成，云端分析只能辅助决策。冗余、故障隔离、分区控制和恢复演练是架构重点。

4. 智慧医疗

医疗设备和患者状态数据形成 CPS 后，系统可以辅助监测和风险预警，但必须明确机器建议与医生决策的责任边界。高风险设备应保留人工确认和本地安全机制，数据要满足隐私、完整性和可追溯要求。不能因为算法预测准确率较高，就取消人工接管和异常处置流程。

八、案例分析：智能工厂 CPS 平台建设

某制造企业有三条生产线，设备来自多个厂家。企业希望降低非计划停机、提高良品率，并允许专家远程调整部分工艺参数。现状是设备协议不统一，部分设备只能通过网关读取，网络偶尔中断，历史数据缺少单位和校准记录。管理层提出“所有数据上云，由人工智能统一控制”的方案。

问题一：指出原方案的主要架构风险

参考答案：

1. 所有控制依赖云端，网络抖动或中断会导致实时控制和安全控制失效。
2. 不同设备的协议、单位、采样频率和时间戳不统一，直接汇总会产生错误分析。
3. 没有设备唯一身份和命令授权，远程控制存在伪造、越权和重放风险。
4. 未说明传感器异常、边缘节点故障、模型错误和升级失败时的降级策略。
5. 只强调人工智能，忽略业务流程、人员接管、工单闭环和责任审计。
6. 高比例原始数据直接上云会带来带宽、存储、隐私和成本压力。

问题二：给出改进后的分层架构

参考答案：

设备层保留传感器、执行器和本地安全互锁，完成最基本的实时控制、限位和急停。接入层为不同厂家提供协议适配器，并将设备能力映射为统一模型。边缘层负责数据校验、单位转换、时间同步、异常检测、局部规则、短期缓存和断网自治；对关键控制命令执行状态、范围、权限和时序检查。平台层负责设备目录、时序数据、告警中心、模型管理、工单和审计；云端完成跨产线分析、预测模型训练和全局调度建议。应用层提供监控、维护、质量分析和专家协同，但远程建议必须经审批和边缘安全校验后才可执行。治理层统一管理设备资产、证书、固件、模型、配置和应急演练。

问题三：设计一条远程调参控制链路

参考答案：

专家提出参数调整后，系统先校验专家身份、角色、工厂范围、设备范围和审批状态；再检查参数是否在允许范围、设备是否处于可调状态、当前生产批次是否允许变更。平台为命令生成唯一编号、有效期和签名，边缘节点验证签名、序列号、防重放信息和本地安全规则。执行前记录旧值，执行后读取设备反馈并验证结果；异常时回退旧值或进入安全模式，同时创建告警和工单。所有请求、审批、下发、执行和结果都写入审计记录。网络中断或命令过期时必须拒绝执行。

九、综合知识练习

题1

为什么 CPS 建设必须先进行业务目标和物理约束分析？

参考答案：CPS 同时影响软件系统和物理对象，业务目标决定建设价值和优先级，物理约束决定采样、控制、时延、安全和环境要求。若不先明确目标，可能采集大量无用数据；若忽略物理约束，可能产生无法实时执行或会造成危险的设计。

题2

“数据上云后统一决策”为什么不能作为所有 CPS 的通用架构？

参考答案：云端网络存在时延、抖动、中断和资源竞争，无法保证硬实时和确定性；部分数据还涉及隐私和带宽成本。安全控制、局部闭环和断网自治应放在设备或边缘，全局分析和跨区域优化才适合中心平台。

题3

CPS 规模化建设时为什么要统一设备模型和数据规范？

参考答案：统一模型可以隔离厂家和协议差异，确保名称、单位、时间、状态和能力具有一致含义，便于平台复用、跨设备分析、模型训练和运维管理。如果每类设备采用一套含义不同的数据，规模扩大后会形成新的数据孤岛。

题4

请列举 CPS 上线前至少五类应开展的异常测试。

参考答案：设备断电与重启、传感器漂移或失真、网络延迟与中断、重复或乱序消息、边缘节点故障、云平台不可用、控制命令越权、固件升级失败、模型异常输出和人工接管。测试应明确预期安全状态、恢复时间和证据留存。

十、论文写作素材

论文中可以围绕“CPS 平台建设与架构治理”展开。开篇说明传统系统存在设备异构、数据孤岛、故障响应慢或控制闭环不完整等问题；随后以业务指标为牵引，采用设备、接入、边缘、平台、应用和治理运维分层架构。重点描述三项决策：一是把硬实时控制和失效安全放在设备或边缘，保证断网仍可运行；二是通过统一设备模型、时间戳、质量码和数据治理实现跨设备协同；三是通过身份认证、最小权限、命令校验、签名升级、审计和人工接管保障安全。

可直接使用的论述如下：

“在建设信息物理系统时，我没有将‘数据全部上云’等同于架构目标，而是依据控制时延、连接可靠性、数据敏感程度和全局协同需求进行部署。设备侧负责感知、执行和安全互锁，边缘侧负责协议适配、数据质量检查、局部闭环、短期缓存和断网自治，平台侧负责设备资产、历史数据、模型、工单和跨区域分析。所有远程控制命令都经过身份、权限、有效期、当前状态、参数范围和防重放校验，模型、固件和配置采用签名、灰度和可回退机制。通过故障注入、网络中断、传感器失真、升级失败和人工接管测试，验证系统在异常情况下仍能保持可控和可恢复。”

十一、今日复盘

1. CPS 建设的核心不是设备联网，而是建立感知、分析、决策、执行和反馈的可验证闭环。
2. 建设过程应经历需求分析、试点验证、规模化复制和持续运营，不能只关注上线时刻。
3. 设备、边缘、平台和应用的分工应由时延、确定性、数据量、连接稳定性和全局性决定。
4. 数据必须带有来源、时间、单位、质量和版本信息，控制命令必须经过严格安全校验。
5. 网络安全、功能安全、可靠性和人工接管共同构成 CPS 的运行保障。
6. 案例题要写出业务目标、分层架构、数据流、控制流、异常场景和验证指标；论文题要写出决策依据、实施措施和效果证据。

完成本节后，应能回答：某个物理对象为什么需要接入？哪些功能必须留在本地？断网时系统如何运行？数据如何证明可信？控制如何证明安全？故障如何被发现、隔离、恢复并追责？这些问题正是高级系统架构设计师在 CPS 场景中的核心能力。