AI驱动的遗留系统现代化：将机器智能集成到ERP、SCADA和本地化部署系统中

将AI集成到遗留系统是企业数字化转型中最关键、也最容易被低估的工程挑战之一。大多数AI项目的失败并非源于模型本身，而是因为数据存放在运行了15年的SAP实例中、使用专有协议的SCADA历史数据库中，或是无人敢碰的本地Oracle数据库中。

AI层本身的构建并不困难。真正让项目陷入停滞的，是从根深蒂固的遗留系统中提取干净、一致、实时的数据，并将处理结果回写到业务运营工作流中。

本指南涵盖工程团队在为涉及遗留基础设施的AI现代化项目选型供应商之前，需要理解的技术模式、集成策略和架构决策。

遗留系统AI集成为何失败

遗留系统的设计目标是保证事务完整性，而非分析可访问性。ERP系统针对记录管理进行了优化，SCADA系统针对实时控制进行了优化，本地数据库针对ACID合规性进行了优化。这些系统均未被设计为在推理时向机器学习模型提供特征向量。

数据所在位置与AI所需位置之间的鸿沟，造成了三个核心集成挑战：

提取（Extraction）：从未针对大规模查询设计的系统中获取数据
规范化（Normalization）：解决跨系统的Schema不一致、单位不匹配和时间对齐问题
回写（Actuation）：在不破坏现有流程的前提下，将模型输出回写到遗留工作流

只能解决上述三点中一到两点的供应商，提供的不是完整的解决方案——而是一个团队难以投入生产的原型。

遗留系统AI集成技术栈

flowchart TB
    subgraph AI["AI / ML 层"]
        A1[模型训练]
        A2[推理引擎]
        A3[监控 & 数据漂移检测]
    end

    subgraph INT["集成层"]
        I1[特征存储]
        I2[API网关]
        I3[CDC / 流处理器]
    end

    subgraph SRC["遗留系统"]
        S1["ERP\n(SAP / Oracle)"]
        S2["SCADA / IoT\n(OPC-UA / MQTT)"]
        S3["本地数据库\n& API"]
    end

    S1 -->|OData / BAPI / CDC| I2
    S2 -->|OPC-UA / REST| I3
    S3 -->|ETL / CDC| I3
    I2 --> I1
    I3 --> I1
    I1 --> A1
    I1 --> A2
    A2 -->|预测结果| I2
    I2 -->|数据回写| S1
    A3 -.->|告警| I2

核心洞察：集成层是最关键的中间层。大多数AI项目的失败发生在这里——而非模型本身。

按系统类型划分的集成模式

ERP系统（SAP、Oracle）

SAP、Oracle EBS、Oracle Fusion等ERP系统是采购、财务、制造和供应链运营的核心支柱。数十年积累的事务历史数据——采购订单、生产计划、库存移动、供应商绩效记录——对需求预测、异常检测和流程优化等AI应用场景具有极高价值。

集成挑战：SAP和Oracle通过BAPI、IDoc、OData API（SAP）和数据库视图的组合来暴露数据。强烈不建议直接访问数据库，否则有失去供应商支持协议的风险。

与SAP/Oracle ERP进行实时AI集成需要采用以下方法之一：

SAP集成套件 / Oracle集成云：无需直接访问数据库即可提供事件驱动数据流的原生中间件
变更数据捕获（CDC）：通过Debezium、Oracle GoldenGate或SAP Landscape Transformation进行基于日志的复制，将事务变更流式传输到下游数据平台
RFC/BAPI轮询：适用于低频批处理场景，但会引入延迟并增加ERP负载

方法	延迟	ERP负载	风险等级	适用场景
SAP集成套件 / OIC	低至中	低	低	事件驱动实时数据流
CDC（Debezium、GoldenGate）	近实时	极低	中	向数据平台的大容量流式传输
RFC/BAPI轮询	中至高	中	低	低频批处理场景
直接数据库访问	低	高	极高	⚠ 应避免——有失去供应商支持的风险

需要向供应商确认的问题：能否在不需要数据库凭证的情况下运行？是否具备SAP或Oracle认证连接器的实施经验？能否在ERP版本更新时处理IDoc解析和BAPI Schema演变？

ERP系统的AI应用场景：

基于历史销售订单和库存移动数据的需求预测
基于采购和交货绩效数据的供应商风险评分
基于工单和资产历史的预测性维护排程
基于应付账款事务模式的发票异常检测

闭环回写：AI输出必须以可执行记录的形式回写至ERP——采购订单建议、维护工单、标记事务——须通过授权API（SAP BAPI调用、Oracle REST API）进行，而非直接写入数据库。跳过此步骤的供应商提供的是仪表板，而非生产级AI。

SCADA与工业物联网

SCADA AI集成呈现出与ERP截然不同的特征。数据量大（1至100Hz的传感器轮询很常见）、延迟要求严格，集成错误的后果可能是物理性的——设备损坏、安全事故、监管违规。

集成挑战：SCADA历史数据库（OSIsoft PI、Wonderware、Ignition）使用专有的时序存储格式和查询语言。OPC-UA和OPC-DA是主要的工业协议，但OPC-DA仅支持Windows，基于COM/DCOM，与容器化环境的桥接极为困难。

现代SCADA机器学习集成方法：

OPC-UA到MQTT的桥接：将OPC-UA标签订阅转换为MQTT主题，通过消息代理（Mosquitto、EMQX、AWS IoT Core）摄入到流处理层
历史数据库REST API：OSIsoft PI Web API和Ignition内置REST接口提供时序查询，无需依赖专有SDK
边缘计算层：在工业边缘硬件（Advantech、Siemens IPC）上部署轻量级推理容器（ONNX Runtime、TensorFlow Lite），在数据源附近执行推理，降低延迟和云端往返带宽需求

网络隔离是硬性约束：大多数工业环境强制执行严格的IT/OT网络隔离（Purdue模型、ISA-95）。提议在不处理DMZ的情况下将原始SCADA数据直接传输到云端ML平台的供应商，尚未做好生产环境的准备。

Purdue模型：AI在OT网络架构中的位置

flowchart TB
    subgraph L4["第4层 — 企业网络"]
        ERP["ERP / IT系统"]
        AI["AI平台\n(训练 + 监控)"]
    end

    subgraph DMZ["DMZ / 防火墙"]
        GW["数据二极管 / 安全网关"]
    end

    subgraph L3["第3层 — 运营网络"]
        HIST["历史数据库\n(OSIsoft PI / Ignition)"]
        EDGE["边缘推理节点\n(ONNX / TFLite)"]
    end

    subgraph L2["第2层 — SCADA / HMI"]
        SCADA["SCADA / HMI"]
    end

    subgraph L1["第1至0层 — 现场设备"]
        PLC["PLC / DCS / 传感器\n(1至100Hz轮询)"]
    end

    PLC -->|OPC-UA| SCADA
    SCADA -->|标签订阅| HIST
    HIST -->|REST API| GW
    GW -->|规范化时序数据| AI
    HIST --> EDGE
    EDGE -->|推理结果| GW
    GW -->|工单 / 告警| ERP

AI推理应在第3层或边缘（第2至3层边界）运行。切勿将原始传感器数据跨DMZ传输到云端进行实时推理。

SCADA与工业物联网的AI应用场景：

应用场景	输入数据	模型类型	输出
预测性维护	振动、温度、压力	时序异常检测	故障概率 + 预计剩余寿命
流程优化	多变量传感器数据流	回归 / 强化学习	设定点推荐值
质量控制	在线传感器 + 生产参数	分类	合格/不合格 + 根因分析
异常检测	多变量传感器基线	自编码器 / 孤立森林	偏差分数 + 告警

供应商评估的关键问题：是否有在OT环境中的实际部署经验？是否理解历史数据库时序数据与事件驱动SCADA告警的区别？能否在气隙或DMZ约束的网络拓扑中运行？

本地数据库与内部API

本类别涵盖遗留基础设施的剩余部分：运行核心业务逻辑的PostgreSQL和SQL Server实例、封装在数十年前单体应用上的REST/SOAP API，以及来自过于老旧而无法暴露API的系统的基于文件的数据导出（CSV、XML、EDI）。

集成挑战：这些系统异构、文档不全，通常由少数掌握机构知识的工程师维护，且这些知识往往没有文字记录。Schema变更不频繁但影响重大。API契约非正式，有时跨版本不一致。

实用的本地AI集成方法：

语义层 / 数据虚拟化：dbt、Trino或Databricks Unity Catalog等工具无需物理移动数据，即可在分散的本地数据源上创建统一的查询接口
API网关抽象：将遗留SOAP服务或未文档化的REST端点封装在受治理的API网关（Kong、Azure APIM）之后，即使底层系统演变，也能为AI流水线提供稳定的集成接口
ETL到特征存储：定时ETL流水线（Airflow、Prefect）可提取、规范化并将特征加载到特征存储（Feast、Tecton、Hopsworks）中，ML模型在推理时无需接触生产数据库即可使用

需要警惕的情况：提议在实时推理时直接读取生产OLTP数据库的供应商，会引入降低应用程序性能的查询负载。应要求在生产系统与AI推理路径之间设置只读副本、物化视图或缓存层。

垂直集成：跨系统AI协同

当AI连接此前各自孤立的数据流时，AI驱动的垂直集成才真正展现其力量——同时构建横跨ERP、SCADA和运营数据库的智能。

案例：预测性维护与采购自动化的集成

某制造商使用SAP管理采购、使用OSIsoft PI监控设备，这两个数据源从未互相通信。垂直集成的AI层以闭环方式将它们连接起来：

sequenceDiagram
    participant PI as OSIsoft PI历史数据库
    participant EDGE as 边缘推理节点
    participant AI as AI / ML平台
    participant SAP as SAP ERP
    participant ENG as 工程团队

    PI->>EDGE: 振动 + 温度数据流（OPC-UA）
    EDGE->>EDGE: 运行异常检测模型
    EDGE->>AI: 故障概率分数 + 传感器快照
    AI->>SAP: 查询备件库存和交货期（OData）
    SAP-->>AI: 库存水平 + 供应商交货期
    AI->>AI: 计算采购紧急度评分
    alt 交货期 > 预测故障窗口
        AI->>SAP: 创建采购申请（BAPI）
        AI->>ENG: 发送维护建议告警
    else 在安全窗口内
        AI->>ENG: 仅发送建议性通知
    end

该架构关闭了跨系统边界的运营闭环，此前这些环节需要维护、采购和运营团队之间的人工交接——消除了以往依赖人工协调的流程中数天的延迟。

这需要能够做系统集成的供应商，而不仅仅是ML。 许多AI供应商在建模方面能力很强，但将集成视为别人的问题。在遗留系统现代化项目中，集成能力与建模能力同等重要。

架构设计原则

无论选择哪家供应商，在评估任何遗留系统AI集成架构时，都应坚持以下五项原则：

1. 非侵入式提取：AI流水线不得修改遗留系统的配置、Schema或性能。使用CDC、历史数据库API和只读副本——绝不直接写入生产系统。

2. 推理解耦：AI模型不得位于遗留系统运营的关键路径上。即使ML服务宕机，ERP事务和SCADA控制回路也必须不受影响地持续运行。

3. 双向审计追踪：每一个触及遗留系统的AI生成动作——工单创建、采购申请、告警生成——都必须可追溯至生成该动作的模型版本、输入数据和时间戳。这在受监管行业中既是运营要求，也是合规要求。

4. Schema演变容错：遗留系统会发生变化。AI流水线必须优雅地处理Schema漂移——在遇到意外变更时明确报错，而非悄无声息地生成错误特征。

5. 增量部署：全量切换风险极高。要求在激活任何自动化之前，设置一个AI建议与现有人工流程并行运行的影子模式部署阶段，以便在实际运营条件下验证模型性能。

供应商评估标准

在评估遗留系统AI现代化的供应商时，不要仅停留在模型基准测试层面。真正的差异化问题在集成层：

评估维度	需要确认的内容	危险信号
连接器深度	是否有针对您使用的ERP版本/历史数据库的生产级连接器？	声称"支持SAP"但无参考实施案例
OT/IT边界经验	是否有在Purdue模型网络拓扑中工作的经验？	提议从OT网络直接进行云端数据出口
回写能力	能否演示向遗留系统的闭环回写？	仅提供仪表板，无回写功能
数据驻留	流水线能否完全在本地或私有云中运行？	要求仅限云端部署
MLOps交接	部署后谁负责监控和重新训练？	无交接计划的永久供应商依赖
IP与数据所有权	合同结束后，谁拥有模型权重和训练数据？	合同中IP条款模糊或缺失