1. 制造时序数据平台导论
在离散制造与流程制造现场，设备每时每刻都在产生带时间戳的观测值：注塑机的锁模压力、数控机床的主轴振动、烧结炉的温区曲线、AGV 的电池 SOC、PLC 的扫描周期计数。这些数据一旦按“设备—测点—时间”三元组组织起来，就构成了制造时序数据。它与互联网日志、金融行情最大的不同，在于数据背后绑定着物理实体、工艺约束和产线节拍，任何一条异常曲线都可能对应一次真实的停机、废品或安全事故。
制造场景中的时序数据特征
制造时序数据的第一特征是高频与多源异构并存。一条 SMT 贴片线，贴片机的吸嘴真空度可能以 1 kHz 采样，而回流焊的温区热电偶只需 1 Hz；同一时刻，MES 记录的是工单与批次，SCADA 记录的是设备状态字，边缘网关记录的是原始波形。第二特征是强时间对齐需求：要判断“炉温偏高是否导致焊接不良”，必须把温区曲线、传送带速度、工单批次在统一时间轴上对齐，而不同系统时钟偏差可能达到数百毫秒。第三特征是数据质量参差：传感器漂移、网络抖动丢点、网关重启造成的重复上报，都会让原始序列出现缺口、跳变和重复。第四特征是生命周期价值分层：原始波形用于故障诊断，秒级聚合值用于 OEE 统计，分钟级均值用于能耗分析，不同精度对应不同保留策略。
下面这张图把制造现场从物理量到平台可用数据的链路，以及各环节的典型时间尺度与质量风险放在同一视图中，便于建立整体印象。
为什么需要平台化，而不是“一设备一脚本”
早期做法通常是：每台设备配一个采集脚本，把数据写进本地 CSV 或单机数据库，需要分析时再人工导出。这种方式在设备数量少于十台、分析需求固定时还能运转，但一旦扩展到整条产线甚至多工厂，问题会集中爆发。第一，测点语义无法复用：A 线叫“1#注塑机-锁模压力”，B 线叫“IMM01_ClampP”，跨线对比时无法自动关联。第二，时间基准不统一：各脚本用本机时间打戳，跨设备关联时误差不可控。第三，查询能力受限：CSV 无法支撑“过去 30 天同一工艺参数在三个班次下的分布对比”这类即席查询。第四，运维成本线性增长：每新增一台设备就要重复部署、调试、监控脚本。
平台化的本质，是把“采集—传输—存储—建模—服务”这些横切能力从具体设备中抽离出来，形成可复用的基础设施。设备侧只负责按统一协议上报，平台侧统一处理时钟、质量、模型和生命周期。这样，新增设备接入从“写脚本”变成“注册测点并绑定采集模板”，分析人员也能用同一套查询接口访问所有产线数据。
架构工程视角：把平台当作可演进的系统来设计
“架构工程”强调的不是一次性选型，而是在约束下做可验证、可演进的决策。制造时序数据平台面临的核心约束包括：数据量增长（设备数 × 测点数 × 采样率）、查询模式多样（实时告警、历史回溯、批量特征）、可用性要求（产线不能因平台故障停线）、以及合规与成本（原始数据保留周期、存储成本）。
架构工程视角要求我们回答几个具体问题：数据在哪个环节做降采样，才能既满足告警实时性又控制存储量？测点模型用扁平标签还是层级设备树，才能兼顾查询灵活性与写入性能？边缘缓存保留多久，才能在网络中断 30 分钟后仍不丢关键数据？这些问题没有唯一答案，但每一个都需要有明确的判断依据和验证方法。例如，对于 1 kHz 振动信号，若告警只需检测 RMS 超限，可在边缘计算 1 秒 RMS 后只上传聚合值，原始波形仅在触发告警时上传前后 10 秒片段——这样既保留诊断能力，又把常态数据量降低约三个数量级。