4. 质量数据平台架构
质量数据平台不是单一系统，而是把检验计划、检验执行、质量判定、缺陷数据、设备状态与供应商质量等对象统一承载的数据基础设施。它的核心价值在于：让质量数据从“分散记录”变成“可追溯、可分析、可服务”的资产。因此，平台总体架构必须围绕“采集—存储—服务—应用—集成”五层展开，并保证层与层之间职责清晰、接口稳定、数据可回溯。
一、总体架构：五层分工与数据流向
平台总体架构采用分层设计，自下而上依次为数据采集层、数据存储层、数据服务层、应用层，集成层则横向贯穿各层，负责与MES、ERP、WMS、SCADA、LIMS等外部系统对接。分层的关键原则是：采集层只负责“取数”，存储层只负责“管数”，服务层只负责“供数”，应用层只负责“用数”，集成层只负责“通数”。任何一层都不应越界承担其他层职责，否则平台会迅速退化为难以维护的“大泥球”。
二、数据采集层：多源异构数据的统一入口
采集层面对的是“多源、异构、高频、易错”的现实。典型数据源包括：检验设备（如三坐标、影像仪、拉力机）的测量结果，PLC/SCADA的工艺参数，人工录入的检验记录，以及MES/ERP同步过来的工单、批次、供应商信息。采集层需要解决三个问题：协议适配、数据清洗、幂等写入。
协议适配方面，设备侧常用OPC UA、Modbus TCP、MQTT；系统侧常用RESTful API、数据库直连、文件交换。采集层应提供统一的“采集适配器”抽象，把不同协议转换为内部标准事件格式。数据清洗则要处理单位换算、量纲统一、异常值标记、时间戳对齐。幂等写入用于防止重复采集导致的数据膨胀，通常以“设备ID+批次号+测量时间+测点编号”作为唯一键。
{
"source": "CMM-01",
"batchNo": "B20240612-007",
"inspectTime": "2024-06-12T09:23:15+08:00",
"items": [
{"code": "DIA-01", "value": 12.034, "unit": "mm", "result": "PASS"},
{"code": "DIA-02", "value": 12.061, "unit": "mm", "result": "FAIL"}
]
}三、数据存储层：按数据特征选型
存储层不能只用一种数据库。质量数据至少分为四类：主数据与检验计划（关系型）、测量结果与工艺参数（时序型）、检验报告与影像（对象存储）、分析宽表与历史归档（数据湖/列式存储）。选型原则是“按访问模式选存储”，而不是“按技术偏好选存储”。
| 数据类型 | 典型内容 | 推荐存储 | 关键要求 |
|---|---|---|---|
| 主数据 | 物料、供应商、检验计划、测点定义 | 关系库 | 强一致、事务 |
| 测量数据 | 尺寸、扭矩、温度、压力 | 时序库 | 高写入、时间窗口查询 |
| 非结构化 | 检验报告、缺陷照片、PDF | 对象存储 | 低成本、可追溯 |
| 分析数据 | SPC宽表、质量指标汇总 | 数据湖/列式 | 批量扫描、聚合快 |
四、数据服务层：把数据变成可复用能力
服务层是平台从“数据仓库”走向“数据服务”的关键。它对外提供查询API、指标服务、订阅推送和权限审计。查询API面向应用层，支持按批次、工单、设备、时间范围检索；指标服务把CPK、PPM、合格率、缺陷率等计算逻辑封装为可复用服务，避免每个应用重复实现；订阅推送用于质量预警，当某测点连续偏移或超差时主动通知；权限审计确保不同角色只能访问授权范围内的数据。
五、应用层与集成层：面向场景与系统协同
应用层直接面向质量工程师、检验员、班组长和管理者，典型应用包括质量看板、SPC分析、追溯查询、预警与报表。应用层不应直接访问数据库，而应通过服务层获取数据，以保证安全与解耦。集成层则负责与MES、ERP、WMS、SCADA、LIMS等系统协同：从MES获取工单与批次，向ERP回传质量结果，从WMS获取物料批次，从SCADA获取工艺参数，与LIMS交换检验项目与结果。
六、案例与常见误区
某汽车零部件企业在建设质量数据平台时，最初把采集、存储、分析全部塞进一个单体应用，结果设备一增加，查询就变慢，报表经常超时。后来按五层架构重构：采集层用适配器统一接入12类设备，存储层把测量数据迁到时序库，服务层封装CPK与PPM指标，应用层只调用API。重构后，单批次追溯从分钟级降到秒级，SPC分析可支持近30天数据在线计算。
综上，质量数据平台的架构设计应坚持“采集标准化、存储分类化、服务API化、应用场景化、集成松耦合”。只有五层各司其职，平台才能支撑检验计划执行、质量追溯、SPC分析与持续改进等核心业务，并为后续的数据治理与智能分析打下稳定基础。