运行在物理系统内部的 AI，与运行在云端的 AI，是两个截然不同的工程问题。部署在产线 PLC 上、车辆 ECU 中、变电站计算节点上或无人机飞控里的模型,必须守住实时 SLA、在网络分区中存活、遵守认证工程师将要审查的安全边界,并运行在成本须通过运营财务审批的硬件上。通用型云 AI 咨询公司做不了这项工作——它们的参考架构不适用,它们的团队也从未见过安全工程师。这属于 Hyperion 生命周期中针对物理系统做了调整的 Build 与 Ship 阶段:一段为期 16 周的嵌入式咨询,带领一个边缘 AI 试点走过安全发现、面向受限硬件的模型设计、与工业或车辆软件栈的集成,以及运营交接。我担任法国政府金融与商业数字化转型 AI 大使——这一身份对主权基础设施和战略产业工作至关重要——并已交付 10 个 AI 项目,其中包括自主系统方面的工作。最终交付物是一套你的运营团队会真正运行的部署,而不是你的数据团队会弃用的演示。
你那套云优先的数据平台从一开始就不是为了把模型推送到机器人单元 PLC、车辆 ECU、AGV 车队控制器或变电站计算节点而设计的——而对它进行改造,本身就是一个长达三个季度的项目。你的团队搭建的 MLOps 栈,假设的是弹性云推理、网络连通性,以及可以超额配置的硬件。这些假设在边缘端无一成立。你的数据团队训练出的模型,运行在你的运营团队掌控的硬件上,其约束是你的 MLOps 流水线无法表达的。
安全与认证工程师拥有否决权,而你却没有任何流程能产出他们所需的证据。模型在仿真中跑得很好。你的安全工程师要求提供危害分析、失效模式覆盖、边界违规测试,以及一条能经受 ISO 26262(ASIL)、IEC 61508(SIL)、无人机航电的 DO-178C 或机器人安全的 ISO 10218 认证审查的证据链——而你的数据团队从未产出过任何这类工件。项目卡在一场你的数据团队直到第十周才知道其存在的审查中。
你的 AI 团队和运营团队说着不同的语言,他们的工单系统也互不相通。数据科学家谈的是 F1 分数、验证集和模型卡。运营工程师谈的是 OEE、MTBF、PLC 扫描周期、车辆总线时序和 AGV 路径冲突率。缺少共同的语言和共同的运作节奏,你的团队交付的模型,永远不会被那个必须运行它的运营团队接受。这个项目不是在技术上失败,而是在社会层面失败。
模型在实验台规模上跑得很好,可一旦第一次遇到一个校准漂移有误的真实传感器,就垮了。训练数据是干净的。生产中的机器人单元有一个无人建模的热偏置、一个你的团队不知道存在的固件版本,以及一个维护团队已经容忍了三年的间歇性编码器故障。正是这种模糊地带,葬送了边缘 AI 项目。
这段咨询分为四个为期四周的阶段。第一阶段和最后一阶段我会驻场工作,中间两阶段则远程嵌入。你的工程、安全和运营团队都需投入既定的时间——这不是一个数据团队可以独自扛下的交付。产出是一套运行在生产硬件上、置于安全制度之下、并与运营栈集成的部署。
与安全工程团队、认证负责人、将要运行该系统的运营工程师,以及构建了试点的 ML 团队展开结构化研讨。我们记录安全边界、关键失效模式、所需的认证工件(视情况依据 ISO 26262 / IEC 61508 / DO-178C / ISO 10218 / EU AI Act 附件 III)、硬件约束(算力、内存、热、功耗)、网络拓扑与分区行为,以及模型必须满足的运营 SLA。到第四周末,我们将拥有一份成文的约束文档,由安全工程师签署、供 ML 团队据以构建。
为适配硬件和安全边界,模型架构与训练方案被重新设计:量化策略、延迟预算、内存占用、安全所要求处的确定性行为,以及传感器故障下的优雅降级。我们在真实硬件上运行消融实验——目标机器人控制器、车辆 ECU、AGV 计算板——而非在仿真中进行。我们还构建证据链——危害分析、失效模式覆盖、边界违规测试——以满足认证审查的要求。本阶段产出的模型,就是将要部署的那一个。
模型在真实硬件上与工业或车辆栈集成——PLC 编程环境、OT 网络、车辆 CAN/Ethernet 总线、AGV 车队管理系统、UAS 飞控接口或变电站自动化继电器。运营团队的监控系统接收模型将要产生的告警。固件更新路径、模型回滚机制,以及部署流水线(视情况采用空中下载或有线下载)均被构建并测试。到第十二周末,模型已在受控试点区域的生产硬件上运行。
由运营团队接管部署。我们构建他们将要使用的运行手册、与其现有运营节奏相匹配的告警阈值、无需 ML 培训即可读懂的模型性能仪表盘,以及凌晨两点固件更新出错时的回滚预案。我们从试点区域扩展到生产范围——逐个机器人单元、逐台 AGV、逐辆车、逐个站点——每一次扩展都由安全工程师签字确认。当我离开时,运营团队已能自行运行该系统。
将 AI 部署进机器人单元或 AGV/AMR 车队的制造商。在 ISO 26262 与 UNECE R155/R156 下将 AI 集成进 ADAS 或 AD 栈的汽车 OEM 和一级供应商。在 IEC 62443 下于变电站或电网边缘部署预测性 AI 的能源公用事业企业。在 DO-178C 或 EASA 框架下将 AI 集成进 UAS 自主栈的航空航天与国防主承包商。任何这样的运营方:其工程主管已经清楚云 AI 与物理 AI 之间的鸿沟真实存在,拥有项目必须通过的认证与安全制度,并且需要一位曾经把 AI 真正交付进物理系统的外部声音。这不适合纯软件公司——它们需要的是 Agentic System Engineering 服务。它同样不适合尚无试点在运行的组织;这段咨询的前提是已有一个现成的模型和一个可以交接的运营团队。
与他们并肩工作,边界清晰。你的自动化合作伙伴负责 PLC 编程环境、OT 网络和运营集成层。我负责模型架构、边缘推理部署、认证证据链和安全流程。咨询期间我们每周碰头,以确保各自的工作成果彼此对齐。我曾与大型工业自动化公司这样并肩协作过,只要双方都尊重这条边界,它就能干净利落地发挥作用。
这段咨询会产出认证证据链——危害分析、失效模式覆盖、边界违规测试——并映射到你的安全工程师所遵循的标准。我不是认证机构,也不会取代你的安全工程师;我按他们所需的结构构建证据,使审查不致卡壳。特别针对 EU AI Act 的高风险分类,证据链是依据附件 III 的要求来设计的。我不会把网络安全标准(UNECE R155/R156)与功能安全标准(ISO 26262/IEC 61508)混为一谈;它们治理的是不同的失效域,要求的也是不同的证据。
可以——而且往往必须如此。运行在车辆 ECU、偏远变电站、GPS 受阻的仓库区域内的 AGV,或在无线电链路范围之外作业的 UAS 上的模型,必须能在网络分区期间运行,并在链路恢复时同步状态。架构对此有明确处理:设备端推理、本地状态管理、遥测数据抵达中央平台时的冲突消解,以及依赖服务不可达时的优雅降级。
面向你的运营团队在未来十年里愿意审批并维护的那种硬件。第一周我们就会确定切合实际的硬件边界——采购会买什么、运营会安装什么、维护会维修什么。我曾在 Jetson、Intel、AMD 和定制芯片上都工作过。模型设计由硬件约束来决定,而非反过来。
实质上不能。这四个阶段各代表一门不同的学科——安全、ML 工程、工业集成、运营——每一个都需要它所需的时间。压缩安全阶段,会产出一套无法通过认证的部署。压缩集成阶段,会产出一套被运营团队拒收的部署。我有时能省下时间的唯一情形,是当一个现成的工业自动化合作伙伴已经完成了大量集成工作;此时咨询便聚焦于模型层与安全层,集成阶段或许可压缩至两周。第一周我就会告诉你这是否适用。
30 分钟。我会诊断你的处境，坦诚告诉你这项服务是否合适——如果不合适，什么才合适。