关键基础设施验证仿真 网络物理系统仿真

核心要点

• 网络物理系统需要一种验证方法，将软件、时序、传感器和被控对象的行为视为一个整体。
• 关键基础设施测试的效果最佳，是在将各种场景按运营后果和恢复影响进行排序的情况下。
• 只有当验收标准能将测试结果与安全响应、服务连续性以及操作人员的清晰度联系起来时，它们才具有意义。

只有将时序、传感和控制作为一个闭环进行测试，关键基础设施的验证工作才能有效。

网络物理系统将软件逻辑与电气、机械及工艺行为相连接，因此故障往往出现在代码与物理世界的交界处。约 全国约85%的关键基础设施 由私营部门拥有和运营。这种由传统资产、定制控制系统和行业规则构成的混合环境意味着，您无法依赖通用的软件验证方法。您需要仿真 测试方案，能在部署前重现信号、延迟、故障以及操作员的操作。

“一种设计在离线分析中看似正确，但在实际运行中仍可能发生跳闸、失速或振荡。”

网络物理系统将计算与物理过程的时序相结合

网络物理系统将计算、通信和物理过程结合在一起，其运行受制于对安全和服务至关重要的时限。控制器扫描信号若延迟到达，可能会改变阀门位置、继电器吸合状态或制动力。这种紧密耦合使得验证成为一项系统级任务。仅靠软件测试无法涵盖这一方面。

一个馈线继电器很好地说明了这一点。电流采样信号进入模拟前端，保护逻辑计算出跳闸条件，断路器线圈必须在设定的时间窗口内动作。水泵站的工作原理与此相同，因为压力、电机转速和网络延迟都会反馈到控制逻辑中。每条路径都会产生时间上的影响和物理上的后果。

您需要将设备与控制器建模为一个闭环系统，以便系统能够模拟实际运行时的行为。这意味着需要再现传感器分辨率、执行器限位、通信抖动以及故障瞬态现象。那些将网络和物理部分分开处理的团队通常会忽略复合故障。这些疏漏往往在后期才显现出来，届时修复成本更高，而现场的信心却更低。

当时间假设未经过测试时，验证将失败

当工程师将时间视为常量而非测试变量时，验证就会失败。扫描周期、任务抢占、总线延迟和中断处理都会影响控制响应。一种设计在离线分析中看似正确，但在实际运行中仍可能发生跳闸、死锁或振荡。时序需要直接测试。

压缩机控制回路揭示了这一问题。该模型或许能在1毫秒的步长内将压力维持在限定范围内，但在通信突发期间，嵌入式目标系统可能无法满足时限要求，从而发出错误的阀门状态指令。这种故障在代码审查中不会显现，而是在执行时间、I/O更新与被控对象响应相互作用时才会显现。

性能测试不能仅依赖最坏情况下的 CPU 数据。您应引入延迟、调整调度器负载，并记录控制质量开始下降的确切时刻。这种方法能将无害的延迟与会改变物理行为的延迟区分开来。一旦明确了这一临界点，设计变更就能从推测性转变为针对性。

传感器仿真 与受力条件下的实际行为相符

传感器仿真必须再现现场仪表在受压时如何出现误读、饱和、漂移以及恢复的情况。干净的信号能产生准确的结果，但关键系统很少仅处理干净的信号。若要获得有效的证据，测试输入必须包含与实际运行中影响控制器响应的相同缺陷。

当距离继电器接收理想电流波形时，其工作状态看似稳定，直到故障导致电流互感器饱和为止。管道压力控制器看似运行准确，直到泵启动后变送器产生噪声为止。这些情况绝非无关紧要的细节，它们直接决定了跳闸时机、报警质量以及操作人员的信任度。

良好的传感器仿真 量程限制、量化误差、数据包丢失、值卡死以及校准误差。此外，故障持续时间也至关重要，因为20毫秒的信号中断与2秒的卡死会触发不同的逻辑处理。与实际现场行为的吻合程度比信号数据量更为重要。一小套可信的传感器故障案例所提供的信息，远比数千次完美的运行数据更有价值。

嵌入式系统测试需要闭环执行保真度

嵌入式系统测试需要闭环执行，以便代码、I/O 和被控对象的响应以相同速率相互作用。开环回放虽能验证功能，但无法揭示控制不稳定、未满足时限要求或不安全的状态转换等问题。这里的“保真度”意味着控制器能立即看到执行结果。正是这一点，将台架测试转变为系统验证。

一个电机驱动控制器便能说明原因。在软件调试器中看似稳定的固件，一旦脉冲更新、ADC采样和负载转矩以精确的时序作用于硬件，便可能产生振荡。开发团队通常会使用OPAL-RT等平台，将控制器硬件与被控对象模型连接起来，并在现场测试前验证这些交互。这种设置揭示了“代码能运行”与“控制能稳定”之间的区别。

闭环保真度并非指所有地方都要达到最大细节程度。您需要在决定控制响应的接口处保持高保真度，尤其是PWM定时、中断服务、网络通信和保护逻辑。如果次要子系统不会改变这些接口，则可以保持简化。这种平衡既能确保测试的可信度，又不会使模型成为维护负担。

关键基础设施的验证工作始于基于后果的场景分析

关键基础设施的验证工作应从后果入手，因为并非所有故障都值得进行同等深度的测试。冗余控制柜上的误报与馈线跳闸失效或阀门错误的开启指令是截然不同的。测试范围应根据影响程度来确定。这样才能让宝贵的实验室时间物尽其用。

由于行业覆盖面广泛，因此有必要进行优先级排序。加拿大将关键基础设施划分为 10个领域，而每个领域涉及的流程、故障成本和响应时间各不相同。医院备用电源控制器所需的测试场景与污水提升站截然不同。统一的测试计划在纸面上看似井井有条，但在实践中却行不通。

基于后果的计划会根据服务中断程度、安全风险、恢复时间以及操作员工作量对各种场景进行排序。这种排序有助于您判断哪些故障需要进行硬件在环测试，哪些需要更长时间的耐久性测试，以及哪些可以仅通过模型审查。虽然无法消除所有不确定性，但您可以将精力集中在那些错误假设会导致最高成本的环节上。

“安全证据必须包含网络事件造成的实际后果。”

电网保护需要基于硬件在环的故障分析

电力系统保护需要采用“硬件在环”的故障分析，因为继电器是针对快速暂态响应的，而非平均行为。动作阈值、逻辑时序和断路器协调取决于精确的电流和电压波形。静态模型会忽略这些细节。故障分析必须以保护系统的运行速度进行。

一次馈线保护试验可在同一试验序列中模拟单相接地故障、电流互感器饱和、断路器故障以及延时远程保护等多种情况。此时，继电器将面临与实际系统运行中相同的波形畸变和时序压力。正是在这种情况下，保护动作不足、动作过早以及误动作等问题才会显现出来。那些看似保守的设定，在受力条件下可能会被证明是不稳定的。

电网团队还需要测试跳闸后的恢复逻辑。在故障发生后，重合闸计时器、同步检查和阻塞信号之间可能会产生意想不到的交互作用。因此，保护验证必须涵盖整个事件过程，从故障前的稳态到故障后的恢复。如果仅基于初始跳闸结果判定通过，就会忽略序列中风险较高的部分。

安全测试必须衡量系统在遭受攻击时的确定性响应

针对网络物理系统的安全测试必须衡量确定性响应，而不仅仅是入侵检测。攻击之所以重要，是因为它会在特定时刻改变时间点、数据质量或控制状态。如果您的测试无法展示工厂在该时间窗口内的响应情况，那么您就无法了解其运营风险。

假设对变电站的测量数据流发起重放攻击。数据包内容看似有效，但时间戳已过期，这可能导致控制器处于不安全状态或延迟跳闸。当伪造的水位信号抑制了水泵停机时，水处理模块也会面临类似问题。安全证据必须包含网络安全事件造成的物理后果。

确定性响应测试侧重于可控的结果。您应测量最大安全延迟、最大可容忍数据包丢失率，以及备用逻辑接管控制的临界点。该方法为运维人员提供了在压力情况下可遵循的规则。此外，它还能确保安全工作与工厂实际运行状况紧密关联，而非依赖抽象的严重性评分。

验收标准应在部署前反映运营风险

验收标准应在部署前体现运营风险，因为只有当测试结果与服务、安全及恢复目标相符时，通过测试才有意义。您需要设定阈值，明确何时时间误差可接受、何时传感器偏差可容忍、以及何时必须启用备用行为。这才是真正重要的标准。

一套有用的验收标准既要具体到足以筛除设计缺陷，又要简单到让团队能够始终如一地应用。某次继电保护测试可能在跳闸速度方面通过，但在断路器锁定后的复位稳定性方面仍会失败。某台泵控制器可能将流量控制在限定范围内，却因发出模棱两可的报警而使操作人员不堪重负。良好的验收标准应能全面反映整个运行过程，而非仅关注某个孤立的瞬间。

• 延迟限制与其所影响的保护或控制功能相关。
• 传感器误差范围包括故障状态下的漂移、失效和饱和。
• 后备模式可在规定的恢复窗口内恢复到安全状态。
• 当报警、强制运行和跳闸同时发生时，操作员的操作步骤依然清晰明确。
• 通过测试的结果要求在额定工况和受载工况下均能保持一致的性能。

那些始终将这些标准置于显眼位置的团队，随着时间的推移会形成更精准的判断力，因为每一项测试结果都对应着具体的运行风险。这种严谨性远比一份充斥着孤立合格标记的长篇报告更为重要。OPAL-RT正是在许多实验室中被广泛采用，用于完成此类执行工作——在这些场景中，控制器硬件、系统模型和故障工况需要作为一个同步运行的系统协同工作。其价值源于严谨的测试设计和客观的验收标准，因为正是这些将仿真 切实的证据。