一旦你的边缘AI变成了实体AI
边缘AI的讨论一直被性能、更小的模型、更快的推理和更低的功耗所主导。在该框架中，关键的基准是每毫瓦的太太操作率（TOPS）和以微秒计的延迟。将人工智能应用到受限硬件上确实很难，工程界在这方面取得了显著进展。
但性能基准测试没有达到一个阈值。这是人工智能系统停止观察而开始行动的时刻;当推理输出不是屏幕上显示的数字，而是发送给电机、阀门、刹车或手术器械的指令时。那一刻标志着边缘AI与物理AI的分界，跨越它将改变模型底下的一切。
感知是信息性的;驱动是必然的
用于对传送带上物体进行分类的视觉系统是一种边缘人工智能应用。当其输出直接控制机械臂来分类、抓取或拒绝这些物体时，同样的系统是一个物理人工智能应用。模型可能相同。它底下的固件不属于同一风险类别。
这一区分很重要，因为嵌入式软件社区花费数十年时间构建了管理相关系统框架：工业安全功能由IEC 61508、汽车安全由ISO 26262、医疗设备为IEC 62304。这些标准的存在正是因为驱动物理结果的软件可能以导致人员受伤、设备损坏和责任的方式失效，而这些责任没有基准评分能解决。
物理人工智能继承了所有这些监管背景。人工智能层不位于其之上;它位于其中。
缝隙开口处
如今，大多数嵌入式团队构建实体人工智能系统，正处于两个历史上不讲同一种语言的社区之间的交汇点。机器学习社区专注于模型准确性、训练流程和推理优化。嵌入式安全社区以ASIL级别、工具资格、静态分析和确定性执行为思考。
他们都说得对。差距在于重叠部分。
考虑一个典型的物理人工智能架构：一个运行控制环路的微控制器（MCU）、产生决策的神经网络推理引擎，以及执行器驱动程序实时执行这些决策。模型的配重会被闪光灯固定。主机固件、初始化、内存管理、中断处理以及调用推理引擎并将其输出路由到执行器的代码，均用C或C++编写。该主机代码必须遵守与其他任何安全关键固件所承担的所有义务：MISRA 合规、静态分析、运行时验证、可追溯测试以及认证工具链。
模型就是智能。固件是安全底线。而大多数实体AI团队在固件方面投入不足，因为压力在于模型的准确性。
这是演示阶段没人问的认证问题
在原型阶段，物理人工智能系统会根据能力进行评估。机械臂能否避开障碍物？预测性维护系统能否捕捉异常？假肢控制器能否在10毫秒内响应？
这些是原型的正确问题。但它们不足以成为产品所需的充分问题。
决定物理AI系统是否能在受监管市场发货的问题则不同：你能否证明该软件是在受控、有文档的体制下开发的;使用合格的工具链构建的;根据定义的编码标准进行分析;并以可追溯的覆盖进行测试？你的审计员能否重建从源代码到部署的二进制文件的路径？
这不是监管形式。这是区分物理AI演示器与物理AI产品的关键操作问题。将合规案例视为能力验证后应处理的团队，会发现其事后推翻了开发过程中的假设、工具链选择、分析漏洞以及推理包装代码中未经过测试的执行路径。
发现的代价会随着发现的时间晚短而增加。
开发流程的变化
将嵌入式开发流程适应物理人工智能并不意味着放弃现有的安全工程实践。而是将其扩展到AI模型所涉及的系统部分。
包裹推理引擎的主机固件应从一开始就被视为安全关键组件。这意味着对每个提交进行静态分析;MISRA C/C++、CERT C/C++ 和 CWE 检查与构建同步运行，而非作为下游审计步骤。这意味着在测试时进行运行时验证，以发现静态分析无法察觉的缺陷类别，如模型执行时的内存访问违规、峰值推理负载下的堆栈溢出，以及推理输出与执行器命令之间控制路径中的未定义行为。
这意味着展示测试套件的代码覆盖率实际上锻炼了重要的执行路径，包括开发者自然低估的错误处理分支，因为他们假设模型不会产生病态输出。模特偶尔会这样做。
这意味着设备生命周期内的工具链稳定性。2026年出货的实体AI产品，到2033年可能仍在工厂生产。在该生命周期内发布的固件维护、安全补丁和安全更新必须在与原始认证配置一致的环境中构建。工具链寿命不是采购考虑因素;这是一个产品生命周期的决策。
尺度改变了这个方程
认识到需要发生的事情是比较容易的部分。更难的是在整个团队中持续完成这项工作，因为开发速度不断加快，且每代产品都让物理AI架构变得越来越复杂。
这时，持续集成/持续交付/部署（CI/CD）不再是DevOps的便利，而是成为一项安全基础设施的需求。当每次提交都自动触发构建、运行静态分析、执行测试套件并产生结构化合规工件时，质量管理是由流水线而非单个学科强制执行的。证据无需在审计前汇总，因为它们自首次提交以来一直在积累。
对于物理人工智能来说，容器化构建环境为其增加了另一层保障。将工具链、编译器配置和分析工具打包到版本化容器镜像中，意味着开发者工作站、云运行器或本地CI服务器上的每条流水线都能在相同的环境中运行。认证的工具链边界清晰且固定。当监管者询问哪个工具版本在哪个配置下生成了给定的二进制时，答案在容器图像中，而非从内存中重建。
这也解决了实体AI团队面临的一个更实际的挑战：协调不同硬件变体和处理器架构间的固件开发。一条涵盖Arm Cortex-M和RISC-V的单一容器化流水线，涵盖了雷萨电子的RA、RX、RZ、RH850、RL78和RZ/Five等MCU生态系统，即使硅片变化，也能保持合规态势的一致性。构建可重复性，作为认证工作的基础，成为流水线的特性，而非发布时的人工操作。
让实体AI可运送的层
IAR平台正是为这种工作流程设计的。
该层包括经过 TÜV SÜD 认证的工具链，符合 IEC 61508、ISO 26262 和 IEC 62304 标准，消除团队在审计时自我验证工具行为的需求。IAR 构建工具是无头的，并集成了标准 CI 平台，包括 GitHub Actions、GitLab CI 和 Jenkins，确保在每次流水线运行中，内置的 CI 与开发者机器上的构建完全一致。
C-STAT 在构建步骤中执行静态分析，强制执行 MISRA C/C++、CERT C/C++ 和 CWE 标准，并在提交时标记违规，而非集成审查时。C-RUN 将这种覆盖扩展到测试执行时的运行时行为，捕捉推理引擎在受限硬件下实际运行时出现的动态缺陷。这些包括内存访问违规、峰值推断负载下的堆叠压力，以及仅靠静态分析无法达到的驱动路径中未定义的行为。
对于同样面临安全义务的物理人工智能系统，以及任何连接的物理人工智能系统，根据《欧洲网络韧性法案》（CRA）和联合国R155，IAR Embedded Trust将固件签名和安全启动集成在同一流水线中，而非将安全视为构建后的步骤。
长期支持版本确保构建环境可以在初始认证多年后复现，因此设备生命周期第六年发布的补丁可以追溯到与原始发布相同的合格工具链配置。
这些都不能取代模型。所有这些都是该型号合法驱动受监管产品执行器之前的必要条件。
关键的界线
边缘人工智能和物理人工智能共享基础设施。它们没有相同的风险特征。一旦推断输出驱动执行器，模型下的软件栈就不再只是性能基底，而是安全产物。如今构建能够通过认证审查的实体AI产品中的嵌入式团队，正是那些早期意识到这一点，并在审核员要求之前就建立了匹配的开发体系。模特成为头条新闻。工具链赢得了认可。
关于作者
Rafael Taubinger 是 IAR 的产品市场经理。他曾在 IAR 担任全球 FAE 经理和高级 FAE 经理。Taubinger 在嵌入式行业拥有超过 20 年的经验，拥有电气工程学士学位和工商管理硕士（MBA）。
