西门子 2024 年报告估算,计划外停机每年给《财富》500 强企业造成约 1.4 万亿美元损失。工业现场真正棘手的地方,不只是设备发生故障,还包括网络不稳定、专家无法及时到场,以及运维人员难以快速定位问题。生成式 AI 可以把手册检索、告警解释和排障建议带到现场,但前提是应用不能把公网和云端模型当作唯一依赖。
离线优先不是简单地在边缘设备上运行一个模型,而是让数据采集、知识检索、推理、审计和任务同步在断网期间仍能形成闭环,恢复连接后再与 AWS 云端协调。
把实时路径留在现场
一套面向工业边缘的生成式 AI 应用,可以将工作负载拆成两条路径:
- 现场实时路径:采集设备状态,检索本地知识库,调用本地模型,生成排障建议并保存审计记录。
- 云端增强路径:同步遥测与诊断结果,更新模型和知识库,执行需要更大模型或更多上下文的分析。
可以这样实践:在边缘节点使用 AWS IoT Greengrass 管理组件和部署版本,通过 AWS IoT Core 接收恢复联网后的消息;设备数据可按业务需要进入 AWS IoT SiteWise、Amazon S3 或其他存储;云端生成式 AI 请求可以由 Amazon Bedrock 承担。这里的服务组合是参考架构,具体服务边界仍要根据设备协议、区域可用性和合规要求确认。
关键设计原则是:云端增强结果,但不阻塞现场操作。例如,轴承温度异常时,本地系统应立即结合最近传感器数据和维修手册给出检查步骤,而不是等待云端请求超时。恢复联网后,系统再上传事件摘要,并在允许的情况下请求更强的模型复核。
本地推理也需要完整的数据闭环
边缘生成式 AI 通常不是直接把传感器数值塞进提示词。更可靠的处理链路包括:
- 将原始信号转换成稳定的特征,例如最近五分钟均值、变化率和告警持续时间。
- 从本地知识库检索对应设备型号、错误码和安全规程。
- 用固定模板限制模型角色、上下文和输出格式。
- 校验输出,明确区分建议、事实和必须人工确认的操作。
- 把输入摘要、模型版本、知识版本和最终响应写入本地队列。
本地知识库也必须能够版本化。不要只复制一批 PDF 到设备上;应为每个文档片段保留设备型号、适用固件、发布日期和安全等级。这样,当模型建议“复位控制器”时,应用才能判断这条程序是否适用于当前产线。
生成式 AI 输出不能直接绕过工业控制边界。模型可以解释告警、生成检查清单或推荐文档,但涉及停机、开阀、修改 PLC 参数等动作时,应通过确定性的规则引擎和人工审批执行。
一个可改造的 Greengrass 离线组件
下面是一个最小参考项目。假设边缘设备已经安装 AWS IoT Greengrass Core,Python 3 可用,并且本地推理服务监听 http://127.0.0.1:8080/generate。示例将事件写入 SQLite,因此断网时不会丢失待同步记录。
目录结构:
edge-assistant/
├── recipe.yaml
└── artifacts/
└── com.example.EdgeAssistant/
└── 1.0.0/
└── assistant.py
recipe.yaml:
RecipeFormatVersion: "2020-01-25"
ComponentName: "com.example.EdgeAssistant"
ComponentVersion: "1.0.0"
ComponentDescription: "Offline-first diagnostic assistant"
ComponentPublisher: "Example"
ComponentConfiguration:
DefaultConfiguration:
InferenceUrl: "http://127.0.0.1:8080/generate"
DatabasePath: "/greengrass/v2/work/offline-assistant/events.db"
Manifests:
- Platform:
os: linux
Lifecycle:
Install: "python3 -m pip install --user requests"
Run: >-
python3 {artifacts:path}/assistant.py
--url '{configuration:/InferenceUrl}'
--db '{configuration:/DatabasePath}'
Artifacts:
- URI: "s3://REPLACE_WITH_BUCKET/components/assistant.py"
运行前需要把 REPLACE_WITH_BUCKET 改成自己的 S3 存储桶,并按 Greengrass 组件目录要求上传 assistant.py。组件脚本可以这样实现:
#!/usr/bin/env python3
import argparse
import json
import sqlite3
import time
from pathlib import Path
import requests
def init_db(path: str) -> sqlite3.Connection:
Path(path).parent.mkdir(parents=True, exist_ok=True)
conn = sqlite3.connect(path)
conn.execute(
"""
CREATE TABLE IF NOT EXISTS events (
id INTEGER PRIMARY KEY AUTOINCREMENT,
created_at INTEGER NOT NULL,
payload TEXT NOT NULL,
synced INTEGER NOT NULL DEFAULT 0
)
"""
)
conn.commit()
return conn
def diagnose(url: str, observation: dict) -> dict:
prompt = {
"system": (
"You are an industrial diagnostic assistant. "
"Use only the supplied observation. Return JSON with "
"summary, checks, and requires_human_approval."
),
"observation": observation,
}
response = requests.post(url, json=prompt, timeout=20)
response.raise_for_status()
return response.json()
def main() -> None:
parser = argparse.ArgumentParser()
parser.add_argument("--url", required=True)
parser.add_argument("--db", required=True)
args = parser.parse_args()
conn = init_db(args.db)
observation = {
"asset_id": "pump-07",
"alarm": "BEARING_TEMPERATURE_HIGH",
"temperature_c": 91.4,
"five_minute_average_c": 86.2,
}
try:
result = diagnose(args.url, observation)
except (requests.RequestException, ValueError) as exc:
result = {
"summary": "Local inference unavailable",
"checks": ["Inspect sensor wiring", "Follow the approved manual"],
"requires_human_approval": True,
"error": str(exc),
}
event = {"observation": observation, "diagnosis": result}
conn.execute(
"INSERT INTO events(created_at, payload) VALUES (?, ?)",
(int(time.time()), json.dumps(event)),
)
conn.commit()
print(json.dumps(event, indent=2))
if __name__ == "__main__":
main()
这个示例刻意把“生成建议”和“执行控制动作”分开。即使本地模型不可用,应用也会返回保守的检查步骤并记录失败事件。生产系统还应增加本地知识检索、JSON Schema 校验、磁盘配额、数据加密和同步重试机制。
组件打包后,可以使用 AWS CLI 创建并部署 Greengrass 组件。以下命令中的账户、区域、存储桶和核心设备名称需要替换:
aws greengrassv2 create-component-version \
--region us-east-1 \
--inline-recipe fileb://recipe.yaml
aws greengrassv2 create-deployment \
--region us-east-1 \
--target-arn arn:aws:iot:us-east-1:123456789012:thing/MyCoreDevice \
--deployment-name offline-edge-assistant \
--components '{"com.example.EdgeAssistant":{"componentVersion":"1.0.0"}}'
恢复联网后的同步策略
同步程序不应上传数据库中的所有原始内容。更稳妥的做法是为事件定义状态机:pending、uploading、synced 和 dead_letter。每条事件携带全局唯一 ID,云端接口按该 ID 实现幂等写入,避免网络抖动造成重复工单。
同步优先级也应区分:安全告警和模型失败记录优先上传,常规遥测可以批量压缩。若现场数据包含人员、配方或生产参数,应在边缘侧先做脱敏,并通过设备证书、最小权限 IAM 策略和传输加密限制访问。
云端模型返回的结果不应悄悄覆盖现场结论。可以保存“本地初判”和“云端复核”两个版本,记录模型 ID、提示词版本、知识库版本和时间戳。这个差异数据还能用于评估小模型是否持续满足现场需求。
上线前检查边界,而不只是准确率
采用离线优先架构时,可以用以下清单评审:
- 断网 24 小时后,告警解释和本地知识检索是否仍然可用?
- 本地队列达到容量上限时,是丢弃低优先级遥测,还是阻塞关键事件?
- 模型、提示词和知识库能否独立回滚?
- 每条建议是否能追溯到输入、模型版本和参考文档?
- 高风险动作是否始终需要确定性校验或人工批准?
- 云端恢复后,重复、乱序和过期事件如何处理?
- 边缘硬件是否留出了模型加载、热管理和存储磨损余量?
边缘生成式 AI 的价值,不在于把最大的模型塞进工厂,而在于缩短从异常出现到形成可执行判断的时间。让现场路径在断网时独立运行,让 AWS 云端负责分发、汇总和增强,再用严格的控制边界约束模型输出,才是更适合工业部署的落地方式。