3. 数字工厂架构设计方法论

离散制造数字工厂的架构设计,不能从“买什么软件、上什么平台”开始,而应从“企业靠什么业务能力赚钱、哪些能力必须被数字化固化”开始。业务架构、应用架构、数据架构、技术架构、安全架构这五层,本质上是一条从业务意图到物理实现的递进链:上层定义“做什么、为什么做”,下层回答“用什么做、怎么稳定地做”。任何一层缺失或倒置,都会导致系统建得起来、业务用不起来。

五层架构的递进关系

业务架构是起点,描述企业的价值流、业务能力、组织与流程。在离散制造中,典型价值流是“接单—计划—采购—加工—装配—检验—入库—交付”。业务架构要回答:哪些环节是瓶颈、哪些决策依赖人工经验、哪些数据必须实时。例如某机加工企业发现“插单排产”平均耗时4小时且依赖调度员经验,这就是业务架构层面的痛点,也是后续数字化的靶点。

应用架构承接业务架构,把业务能力映射为应用系统与服务。离散制造常见应用包括ERP(订单、物料、成本)、MES(工单、报工、追溯)、APS(排产)、PLM(BOM、工艺)、QMS(检验、SPC)、WMS(库位、批次)。应用架构的关键不是罗列系统,而是明确边界与集成关系:ERP下发工单到MES,MES回传完工与消耗;APS从ERP取订单、从MES取产能,输出排产结果。边界不清,就会出现“同一张工单在三个系统里状态不一致”。

数据架构是应用架构的“血液系统”。离散制造的数据主线是物料—BOM—工艺路线—工单—批次—设备—质量记录。数据架构要定义主数据(物料、BOM、工艺、设备、供应商)的唯一来源、编码规则、版本管理,以及事务数据(工单、报工、检验、库存)的流转与留存。例如物料编码若在ERP与MES中各有一套,追溯就会断裂。数据架构还决定数据是“实时流”还是“批量同步”,直接影响排产与看板的时效。

技术架构是承载应用与数据的物理与逻辑底座,包括云/边/端部署、网络(工业以太网、5G、TSN)、计算(服务器、边缘网关)、集成中间件(ESB、消息队列、API网关)、数据库与数据平台。离散制造车间环境复杂,技术架构必须回答:设备数据如何采集(PLC、OPC UA、Modbus)、边缘侧做哪些实时计算、云端做哪些分析与存储。技术架构选型错误,会导致数据延迟高、系统扩展困难。

安全架构贯穿四层,而非最后附加。它包含网络安全(分区隔离、防火墙、VPN)、数据安全(加密、备份、权限)、应用安全(身份认证、审计)、工控安全(OT与IT隔离、白名单)。离散制造中,OT侧设备一旦被攻击可能导致停产,因此安全架构必须与业务架构同步设计,而不是等系统上线后再补。

离散制造数字工厂五层架构递进关系 业务架构 价值流:接单→计划→采购→加工→装配→检验→交付 | 业务能力、组织、流程、痛点 定义“做什么” 应用架构 ERP | MES | APS | PLM | QMS | WMS | 边界划分与集成关系 映射“用什么做” 数据架构 主数据:物料·BOM·工艺·设备·供应商 | 事务数据:工单·报工·检验·库存 | 编码·版本·流转 定义“数据从哪来” 技术架构 云/边/端 | 工业以太网·5G·TSN | OPC UA·Modbus | 消息队列·API网关 | 数据库·数据平台 承载“怎么稳定做” 安全架构 网络安全 | 数据安全 | 应用安全 | 工控安全(OT/IT隔离·白名单·审计) 贯穿四层,同步设计 约束与反馈

TOGAF与Zachman在离散制造中的裁剪使用

TOGAF的ADM(架构开发方法)提供了一套完整的循环:预备、架构愿景、业务架构、信息系统架构(应用+数据)、技术架构、机会与解决方案、迁移规划、实施治理、变更管理。对离散制造企业而言,完整跑一遍ADM往往过重。实际裁剪方式是:保留业务架构、数据架构、技术架构三个核心阶段,把应用架构并入信息系统架构,安全架构作为贯穿性需求在每个阶段评审。例如在“架构愿景”阶段就明确“本次数字化范围是机加工车间排产与追溯”,而不是全厂全流程,避免范围蔓延。

Zachman框架则提供二维分类:行是视角(范围、业务模型、系统模型、技术模型、详细表示、运行),列是问题(数据、功能、网络、人员、时间、动机)。离散制造中,Zachman最适合用来检查架构描述的完整性。例如“工单”这个对象:业务模型行回答“工单在计划员眼中是什么”,系统模型行回答“工单在MES中如何建模”,技术模型行回答“工单数据存在哪张表、通过什么接口传输”。如果某一格空白,说明该视角缺失,实施时必然出现盲区。

两者结合的使用建议是:用TOGAF的ADM组织项目阶段与交付物,用Zachman的矩阵做逐格检查。在离散制造场景中,尤其要关注Zachman的“时间”列(排产时序、工单优先级、设备可用时间)和“动机”列(为什么插单、为什么换型),这两列在通用框架中容易被忽略,却是离散制造的核心变量。

裁剪落地的关键判断

裁剪不是随意删减,而是基于企业规模、产品复杂度、订单模式、现有系统存量四个维度做取舍。例如:多品种小批量、插单频繁的企业,APS与MES的实时集成是重点,数据架构必须支持分钟级工单状态同步;而大批量少品种的企业,重点可能在PLM与ERP的BOM一致性。安全架构的裁剪则取决于是否涉及军工、汽车等强合规行业,若涉及,OT/IT隔离与审计追溯必须完整保留。

裁剪检查清单(示例):
  • 业务架构是否覆盖了从接单到交付的完整价值流,并标注了瓶颈环节?
  • 应用架构是否明确了每个系统的边界与集成接口(谁发谁收、频率、格式)?
  • 数据架构是否定义了主数据唯一来源与编码规则,事务数据保留周期是否满足追溯要求?
  • 技术架构是否区分了边缘实时计算与云端分析存储,网络是否满足车间环境?
  • 安全架构是否在业务架构阶段就识别了OT/IT隔离需求,而非上线后补丁?

最后需要强调:五层架构的递进关系不是单向瀑布,而是上层定义约束、下层反馈可行性的迭代过程。技术架构的选型会反过来影响应用架构的集成方式,数据架构的现状会限制业务架构的数字化范围。在离散制造中,最务实的做法是:先画业务架构的价值流与痛点,再画数据架构的主数据与事务流,然后倒推应用与技术,安全架构同步嵌入。这样建出来的数字工厂,才是业务驱动、数据贯通、技术可落地、安全可管控的。