智能化生产技术架构：从设备接入到业务应用的完整设计

智能化生产技术架构技术架构总览

整体架构分层

一套可落地的智能化生产技术架构，通常分为设备层、边缘层、数据层、平台层、应用层和运维安全层。

设备层包括PLC、数控机床、机器人、传感器、视觉设备、仪器仪表及各类生产辅助设备。

边缘层负责协议转换、数据过滤、本地计算和断网续传，避免所有原始数据直接进入中心平台。

数据层负责时序数据、业务数据、文件数据及分析数据的分类存储，并建立统一的数据标准。

平台层提供设备管理、规则引擎、消息处理、流程编排、算法服务和统一接口等公共能力。

应用层承载生产看板、质量追溯、设备运维、能耗分析、工艺优化及排产调度等业务系统。

运维安全层覆盖身份认证、权限控制、日志审计、监控告警、数据备份及容灾恢复。

各层职责边界

架构设计要解决的关键问题，不是系统有哪些功能，而是每一层做什么、不做什么。

设备接入不能直接绑定业务应用，否则更换设备、协议或应用时，改造范围会迅速扩大。

数据层不应承担复杂业务流程。订单状态、工单流转和审批规则应放在平台服务或业务应用中。

应用层也不应绕过平台直接读取设备数据库，这会增加安全风险，并造成数据口径不一致。

建议通过事件总线和标准API连接各层，使设备变更、服务升级和应用扩展能够独立进行。

技术选型原则

技术选型应围绕业务规模、实时性、团队能力和预算展开，而不是单纯追求技术栈数量。

单工厂、设备少于500台时，可采用模块化单体加消息队列，没必要直接建设复杂微服务体系。

多工厂、设备超过3000台，且需要跨区域协同时，可采用微服务、容器平台和分布式数据架构。

实时控制通常留在PLC或边缘控制器中，平台更适合处理秒级监测、分钟级分析和业务协同。

采购评估时要问清楚：支持多少协议、单节点吞吐多少、扩容怎么做、接口是否开放、多少钱。

智能化生产技术架构数据层架构

数据采集方案

数据采集需要覆盖设备数据、生产数据、质量数据、能耗数据、环境数据和人员操作数据。

设备侧常见协议包括OPC UA、Modbus TCP、PROFINET、EtherNet/IP、MQTT及厂商私有协议。

建议在产线或车间部署边缘网关，将不同协议转换为统一的MQTT、HTTP或内部事件格式。

采集频率不能全部设为毫秒级。温度可按1秒采集，产量可按事件上报，状态变化应即时推送。

对于振动、声学等高频信号，可在边缘侧完成特征提取，只上传峰值、频谱和诊断结果。

边缘节点应具备本地缓存。网络中断后数据暂存，恢复连接后按时间顺序补传并校验完整性。

每条数据至少包含设备编码、测点编码、时间戳、数值、质量标识和数据来源六类信息。

设备编码和时间戳必须全厂统一，否则质量追溯与跨系统关联很难准确完成。

数据存储设计

生产数据类型差异较大，不建议把所有数据都存入同一种数据库。

设备测点、运行状态和能耗曲线适合存入时序数据库，如InfluxDB、TimescaleDB或国产时序产品。

订单、工单、物料、设备台账等事务数据，可使用MySQL、PostgreSQL或企业现有关系数据库。

图片、视频、工艺文件和设备说明书适合放入对象存储，并在业务数据库中保存索引和元数据。

大规模历史数据分析可采用数据湖或湖仓架构，把原始数据、清洗数据和主题数据分层管理。

热数据可保留30至90天，温数据保留1至2年，冷数据根据审计要求归档到低成本存储。

数据库表应按工厂、产线、设备和时间进行分区，避免单表数据量持续增长导致查询变慢。

对高频查询指标建立预聚合表。例如按分钟计算平均值，可减少看板反复扫描原始数据。

数据治理策略

数据治理要明确数据由谁产生、谁负责、谁能修改，以及出现异常后由谁处理。

企业应建立设备、物料、工艺、组织和质量缺陷等主数据标准，并分配唯一编码。

数据质量规则可设置完整率、及时率、准确率和重复率，低于阈值时自动生成治理任务。

生产指标必须统一计算口径。OEE、良品率、停机时长等指标应形成可版本管理的指标字典。

敏感数据要分类分级，关键工艺参数应加密存储，并记录查询、导出和修改行为。

数据治理不是一次性项目。建议每月检查数据质量，每季度评审指标和主数据变更。

智能化生产技术架构平台层架构

微服务架构设计

平台层可以按业务边界拆分为设备服务、数据服务、告警服务、工单服务和用户权限服务。

服务拆分不能只按页面或数据库表进行，否则会产生数量过多、调用链过长的问题。

每个服务应拥有明确的数据边界，并通过API或消息事件交换信息，避免直接读取其他服务的数据表。

设备服务负责设备注册、状态管理和属性模型，告警服务负责规则执行、通知和闭环记录。

工单服务管理派单、接单、处理和验收，数据服务则提供查询、聚合及指标计算能力。

服务数量少于20个时，可采用轻量注册中心和API网关。规模扩大后再引入服务网格。

容器镜像应统一基础环境、版本规则和漏洞扫描流程，避免不同团队重复维护运行环境。

接口变更需要保持向后兼容。无法兼容时，应保留旧版本并设定至少3个月的迁移周期。

微服务不是项目目标，它只适合解决团队协作、独立扩容和频繁发布等具体问题。

消息中间件选型

设备遥测数据量大、实时性要求高时，可选MQTT Broker或Kafka处理数据流。

需要业务事务、可靠投递和延迟消息时，可评估RabbitMQ、RocketMQ等消息中间件。

选型要对比每秒消息量、消息大小、顺序要求、保留周期、集群节点数和运维成本。

生产事件应携带唯一消息编号，消费端要做幂等处理，防止重复消息造成重复工单。

关键消息不能只依赖内存队列，应开启持久化、副本机制和失败重试，并配置死信队列。

缓存与性能优化

设备状态、用户会话、权限信息及常用配置可放入Redis，减少数据库访问压力。

缓存时间要按数据变化频率设置。设备状态可缓存数秒，基础配置可缓存10至30分钟。

高并发看板不应每次读取原始明细，可通过预聚合、增量计算和分层缓存提升响应速度。

常用查询接口的目标响应时间可设为500毫秒以内，大屏核心指标可控制在2秒以内。

批量导出应改为异步任务。用户提交后由后台生成文件，再通过站内消息提供下载地址。

数据库优化需要同步处理索引、慢查询、连接池和分页方式，不能只靠增加服务器解决。

压测场景应覆盖早班交接、集中报工、批量设备上线和管理层大屏刷新等真实业务高峰。

容量规划可按日均流量的3倍设计，并保留30%的资源余量，以应对设备扩容和数据突增。

智能化生产技术架构应用层架构

前端技术方案

管理端可采用Vue或React，配合统一组件库建设设备、工单、告警和报表页面。

车间终端要适配工业平板、大屏和触摸设备，按钮尺寸及颜色不能照搬普通办公系统。

实时数据可通过WebSocket或SSE推送，避免浏览器每秒轮询平台接口。

大屏展示应限制单页图表数量。建议控制在8至12个核心组件，减少浏览器渲染压力。

弱网车间可采用PWA或本地缓存，保证任务查看、数据录入和异常上报等基础操作可用。

API设计规范

API可采用REST风格，设备实时流和内部服务调用也可根据场景使用gRPC。

接口地址需要包含版本号，例如“/api/v1/devices”，避免升级时影响现有系统。

所有接口统一返回请求编号、状态码、提示信息和业务数据，便于定位跨系统调用问题。

列表接口必须提供分页、排序和过滤条件，禁止一次返回全厂全部设备或历史数据。

写入接口应支持幂等键，关键操作需要记录操作者、调用来源、请求时间及变更前后内容。

对接ERP、MES、WMS时，应提供接口文档、示例报文、错误码和测试环境。

权限与安全机制

权限模型可采用RBAC，将用户关联角色，再把角色关联菜单、接口和数据范围。

集团型企业还要增加工厂、车间、产线和设备级数据权限，防止跨组织查看敏感信息。

身份认证可接入企业AD、LDAP或单点登录平台，并对管理员启用多因素认证。

设备接入建议使用独立证书或密钥，禁止数百台设备共用同一个账号和固定密码。

平台接口应设置签名、时间戳、防重放和访问频率限制，外部接口通过网关统一开放。

安全审计日志建议至少保留180天，关键工艺、质量和用户权限变更可保存1至3年。

智能化生产技术架构部署架构与运维

部署方案选择

智能化生产技术架构可部署在工厂本地机房、私有云、公有云或边云协同环境中。

涉及实时采集和生产连续性的服务适合部署在工厂侧，管理分析服务可放在集团数据中心。

单工厂项目可采用3至5台服务器组成基础集群，覆盖应用、数据库、消息和备份服务。

多工厂场景可使用Kubernetes管理容器，实现统一发布、弹性扩容和资源隔离。

若企业团队缺少容器运维能力，可先采用虚拟机部署，避免平台复杂度超过实际收益。

部署前要计算服务器、数据库授权、操作系统、网络改造和三年运维费用，不能只看软件报价。

监控与日志体系

监控体系需要覆盖基础资源、中间件、应用服务、接口、数据库和设备连接状态。

Prometheus可采集性能指标，Grafana负责展示，日志可使用ELK或Loki集中检索。

关键指标包括CPU、内存、磁盘、接口延迟、错误率、消息积压和数据库连接数。

设备侧还要监控在线率、数据延迟、采集中断次数及边缘网关本地存储使用率。

告警需要分为提示、一般、严重和紧急等级，并配置短信、电话或企业微信通知。

每条告警应关联负责人、处理时限和操作手册，避免平台只发消息却没人处理。

应用发布应采用灰度或滚动升级，发布失败时可在10分钟内回退到上一稳定版本。

容灾与备份策略

生产平台要明确RPO和RTO。核心生产系统可将RPO设为15分钟，RTO控制在2小时内。

数据库可采用主从复制或高可用集群，消息系统至少部署3个节点，避免单节点故障。

业务数据库建议每日全量备份、每小时增量备份，并将备份副本存放到独立存储设备。

配置文件、证书、容器镜像和边缘网关程序也要纳入备份，不能只备份数据库。

同城容灾适合处理服务器和机房故障，异地备份则用于火灾、洪水及区域性网络中断。

备份文件需要定期执行恢复测试。建议每季度至少演练一次，并记录恢复时间和数据完整率。

上线验收时应模拟断网、断电、节点宕机和数据库切换，验证系统能否按设计继续运行。

采购合同中还应写明故障响应时间、备件周期、数据归属、源码交付边界和退出机制。

常见问题