Simplico
Industry Microcontroller Security

教本地大模型”读懂”你的工厂车间:用 simpliSOC 解释安全告警与设备日志

September 3, 2026

在一家制造工厂里,两个人因为同一个底层事件收到了提示,但谁都没能以自己需要的方式看懂它。

安全运营中心(SOC)分析师——如果工厂配备了的话——看到的是一条 Wazuh 告警:FC 15 write multiple coils, srcip 10.0.4.71, dst PLC-04, 02:14。这是一个安全信号,只有懂 Modbus 功能码的人才能读懂。

车间班长什么都看不到,或者只在 HMI 上看到一个 FAULT 0x22 的报警和一盏红灯。这是一个运营信号,只有懂这条产线上 0x22 故障码含义的人才能读懂。

相关服务

两个人的困惑都情有可原。这两类日志都是为机器压缩的,不是为人准备的,而真正站在风险——无论是物理风险还是网络风险——最近处的那个人,往往并不是被训练来解读这种格式的人。本文要介绍的,是用一个本地语言模型来弥合这道鸿沟的思路:其中一半是 simpliSOC 今天已经在生产环境中做的事情,另一半则是我们认为值得沿着同一思路继续构建的延伸方向。

一、回顾:先要拿到 OT 层的可见性

模型要能解释什么,前提是有东西在"听"。我们在 Why Your Factory Floor Is the Softest Target in Your Network 一文中已经详细讨论过可见性这部分:在 OT 交换机上做被动网络分光(TAP)或使用 SPAN 端口,用 Zeek 传感器把 Modbus TCP 和 EtherNet/IP 解码成结构化日志,再由 Wazuh agent 把这些日志转发到 SOC 后端——全程不向可能扛不住的 PLC 发送任何主动探测报文。

这套架构能给你一条结构化的 OT 事件流:谁在什么时间,用什么协议、什么功能码,和哪台 PLC 通信过。这是原材料。本文要探讨的问题是:Wazuh 标记出异常之后,这条数据流会经历什么——以及同样的思路能否延伸到旁边那条设备健康日志流上。

flowchart TD
    PLC1["PLC Modbus TCP"]
    PLC2["PLC EtherNet IP"]
    HMI["HMI Workstation"]
    SW["OT Switch SPAN Port"]
    TAP["Network TAP"]
    ZEEK["Zeek Sensor"]
    WZ["Wazuh Manager OT Rules"]

    PLC1 --> SW
    PLC2 --> SW
    HMI --> SW
    SW --> TAP
    TAP --> ZEEK
    ZEEK --> WZ

二、前半部分:解释安全告警,这是今天已经在做的事

这部分不是设想。simpliSOC 产品页面中描述的 AI 辅助分诊功能,已经对符合条件的 Wazuh 告警运行本地大模型,通过部署在客户自有网络内、兼容 OpenAI 接口的服务端(Ollama、llama.cpp、vLLM、LocalAI)提供服务。它读取告警本身及周边活动,写出大白话的解释,并给出真阳性或误报的判断,既可以自动附加,也可以按需触发。

把同一套机制指向上面被动分光架构产生的 OT 规则,收益会比 IT 告警更大,因为面对的读者不同。SOC 分析师本来就"讲得懂" Wazuh 的语言,而车间的工艺工程师或班长通常并不懂,他们往往还是设备真正出问题时离现场最近的第一响应人。

对比一下原始告警和模型返回的内容:

Wazuh 原始告警:

rule.id: 100045
rule.level: 12
agent: zeek-ot-sensor-01
modbus.func_code: 15
modbus.dst_ip: 10.0.2.14 (PLC-04)
modbus.src_ip: 10.0.4.71
timestamp: 2026-09-02T02:14:03+08:00

模型的结构化输出:

{
  "severity": "high",
  "asset": "PLC-04(2号挤出线)",
  "summary": "一台此前从未向该 PLC 写入过数据的主机,在凌晨2点14分发送了写多个线圈的命令,超出了预定的22:00-23:00维护窗口。",
  "context_check": "今晚2号线没有开放的维护工单。源 IP 与供应商 VPN 网段不匹配。",
  "recommended_action": "escalate_and_verify_physically",
  "confidence": 0.78
}

第二段内容,班长即使不知道"线圈"是什么,也能据此采取行动。模型并不是凭空编出维护窗口的对比——SOC Integrator 会像它已经在为 IT 告警做的那样,拉取这类上下文(开放的工单、已知的供应商 IP 网段),具体模式在 Using Small Language Models to Detect Cyber Attacks from Wazuh Logs and Firewall Syslog 中已有说明。对 OT 而言真正需要改变的,只是提示词里的词汇,以及 SOC Integrator 用来充实上下文的字段——用资产名称代替用户名,用维护窗口代替办公时间,用供应商 VPN 网段代替员工 IP 网段。

三、后半部分:同样的模式指向设备健康日志——这是路线图构想,不是已交付的功能

这里必须把"已经存在的"和"我们认为应该存在的"区分清楚。simpliSOC 是一套安全技术栈。它今天并不读取 PLC 故障码、historian 位号漂移或 HMI 报警日志,本节内容不代表 simpliSOC 当前的能力。

我们认为值得构建的是:同一个本地模型,部署在同一个本地推理端点上,再承担第二项任务。它不再读取 Wazuh 的 OT 告警,而是读取像 simpliFactory 这类系统已经在车间层面采集的运营日志流——故障码、超出规格漂移的位号值、HMI 上密集出现的报警——并生成同样风格的大白话结构化解释,面向的是维修技师而不是安全分析师。

这个思路之所以值得投入而不只是停留在图纸上,原因在于经济性。按照 Choosing Hardware for Local LLMs in 2026: A Practical Sizing Guide 中的方式部署运行的 7B–14B 本地模型,单次调用成本足够低,不需要靠单一场景来摊薄成本。一旦工厂已经有一个做安全分诊的本地端点,再增加一个使用不同提示词、不同输出结构的第二个调用方,更像是一次配置调整,而不是一个新项目——这正是走本地化路线的核心理由,详见 Why Enterprises in Southeast Asia and Japan Are Moving LLMs Inside the Firewall。对于中国大陆的制造企业而言,这一点尤其重要:《个人信息保护法》(PIPL)与《数据安全法》对生产运营数据的处理和出境都有明确约束,等保2.0对关键信息基础设施的安全防护等级提出了具体要求,而"数据不出境"这一原则本身,恰恰是本地大模型架构相对云端方案最直接的合规优势——也与许多地方政府推动的"智改数转"(智能化改造、数字化转型)项目对本地部署、自主可控的要求相吻合。

flowchart TD
    OTLOG["OT Security Log Stream Wazuh"]
    MESLOG["Machine Health Log Stream MES Historian"]
    LLM["Local LLM Endpoint Ollama or vLLM"]
    SOCOUT["Plain Language Security Explanation"]
    MESOUT["Plain Language Fault Explanation Roadmap"]

    OTLOG --> LLM
    MESLOG --> LLM
    LLM --> SOCOUT
    LLM --> MESOUT

设备健康这一侧可能的结构化输出示例——同样只是示意这一模式,并非真实存在的 schema:

{
  "asset": "2号挤出线 - 3号加热区",
  "fault_code": "0x22",
  "summary": "过去40分钟内,3号区温度持续低于设定值8%,这一漂移模式更符合加热元件部分失效,而非传感器故障。",
  "similar_history": "同样的漂移模式曾在2026年3月14日更换3号区加热器之前出现过。",
  "recommended_action": "schedule_inspection_before_next_shift",
  "confidence": 0.65
}

这与现成的预测性维护软件相比,有两点不同:它运行在已经通过安全场景验证过价值的同一套本地模型上;它用维修团队听得懂的语言解释故障,而不是让他们自己去看趋势曲线。

对于使用国产模型生态的团队,这套模式同样适用——本地部署的 Qwen 或 DeepSeek 等模型完全可以承担同样的角色,替换掉示例中提到的 Llama 系模型,底层架构不需要改变。

四、护栏对两个场景都适用,OT 场景的风险更高

安全这一侧的规则原封不动地延续下来,而且在这里更重要,而不是更次要:模型只提供建议。 它负责总结、分类和推荐,但从不自动关闭安全工单,也从不自动调整设定值或自动确认设备报警。任何超过预设严重等级阈值的操作,都需要人工确认。

这一点在 OT 场景比在 IT 场景更重要,因为失败模式是物理性的。在 IT 告警上判断错一次误报,浪费的只是分析师的时间。而在"不用管,这只是加热器在漂移"这句话上判断错一次假阴性——而实际上是一次未经授权的设定值变更——后果完全是另一个量级;反过来,把真实的机械故障当成安全事件处理,则意味着工厂会因为错误的原因停线。这套模式的安全侧和设备健康侧,都不应该被信任去做决策,而应该被信任去快速地向真正做决策的人解释清楚状况。

另一条护栏直接沿用自 OT 可见性方案:这里描述的一切都不会向 PLC 写入数据、调整设定值,或在 OT 网络上执行任何主动操作。模型只读取已经存在的日志,生成文本。这与 Zeek 传感器采用的被动姿态完全一致,只是把这种被动性从采集层延伸到了推理层。

五、这对工厂安全或 MES 项目意味着什么

如果你已经在运行带有 OT 规则的 Wazuh,把本地大模型解释层扩展到这些告警上,只是一次范围界定的讨论,而不是一次全新的架构设计——它复用的是已经在 IT 告警场景中投产的同一个端点、同一套 SOC Integrator 上下文增强模式,以及同一套护栏设计。

如果你还处在更早的阶段——已经有 MES 采集车间数据但还没有 OT 安全可见性,或者反过来——那么需要考虑的是先给哪条数据流装上"耳朵"。我们的默认建议是先从6月那篇文章中描述的被动 OT 分光和 Wazuh 规则开始,因为这是下行风险最高的缺口(未受监控的 OT 网络在今天就是一个真实存在的风险),之后再依次推进本地大模型解释层以及向设备健康方向的延伸——前提是已经有一条值得去解释的日志流。

常见问题

simpliSOC 目前能诊断设备故障,而不只是安全事件吗?
不能。simpliSOC 的本地大模型分诊是已经交付、面向安全告警的功能。本文描述的设备健康应用,是同一架构的延伸构想,并非当前已具备的能力。

这套方案会把工厂数据发送到工厂网络之外吗?
不会。本地大模型运行在客户自有网络内的硬件上,通过兼容 OpenAI 接口的服务端(Ollama、llama.cpp、vLLM 或 LocalAI)提供服务。无论是安全日志还是设备日志,都不需要离开网络就能让这套方案运转。

模型能不能对 PLC 执行操作,或者调整设定值?
不能。它只读取结构化日志数据并生成文本。所有推荐操作都需要人工执行,这套模式中没有任何一步会向 OT 设备写回数据。

相关文章

阅读全部文章 →

如果我们还没有 OT 网络可见性怎么办?
先从这一步开始。本地大模型解释层需要一条可读的日志流,而我们在 OT 可见性文章中描述的被动式 Zeek/Wazuh 分光方案,是在不触碰正在运行的 PLC 的前提下,获得这条日志流风险最低的方式。

来源:

最新文章

Ready to talk about your project?

Share goals and constraints. We'll assemble architects and engineers to move fast with you.

Get in touch