01 时间性能系统技术领域知识
title: 时间性能系统技术领域知识
area: domain-knowledge
kind: technical-detail
topic: time-performance-analysis-technical
parent:
- ‘[时间性能系统领域知识](/20_Domain_Knowledge/23 时间性能分析/00 时间性能系统领域知识/)’
upstream: - ‘[时间性能系统领域知识](/20_Domain_Knowledge/23 时间性能分析/00 时间性能系统领域知识/)’
- ‘[工业数据接入](/20_Domain_Knowledge/21 工业数据接入/00 接入模式/)’
- ‘[工业智能平台总体架构](/10_Architecture/11 平台总览/工业智能平台总体架构/)’
related: - ‘[曲线分析系统技术领域知识](/20_Domain_Knowledge/22 曲线质量分析/02 曲线分析系统技术领域知识/)’
- ‘[PDM技术领域知识笔记](/20_Domain_Knowledge/24 预测性维护/01 PDM技术领域知识笔记/)’
作为业务领域知识的补充，本文聚焦系统架构、关键算法、数据口径与后续实现方向。内容保持在“可指导实现”的层面，不展开到方法级细节。
术语沿用业务文档中的定义，但本文只说明实现映射，不重复展开业务语义。
1. 技术定位
时间性能系统的技术目标，是把产线时序数据加工成可解释的节拍知识，再进一步沉淀为瓶颈诊断与改善分析的标准输出。
系统不是单纯计算某个时长，而是要形成一条稳定的数据链路：
- 从原始时序数据中提取有效节拍窗口
- 为不同对象建立可比的节拍基准
- 将实际节拍拆解为工作、等待、故障等结构
- 归集为瓶颈、负载和节拍分布等管理指标
更完整的业务含义见业务文档对应章节，本文只保留实现侧需要关注的映射关系。
2. 技术架构总览
| 时序数据 | → | 节拍分段 | → | 基准生成 | → | 实际拆解 | → | 报表输出 |
| 数据接入与清洗 | 节拍目标与基准 | 实际节拍与告警融合 | 瓶颈、负载、节拍分析 |
说明：
- 第一层解决“数据是否可用”，重点是时间窗、对象边界和异常数据过滤。
- 第二层解决“应该拿什么作比较”，重点是长期基准和设计基准的分离。
- 第三层解决“现场到底发生了什么”，重点是报警、等待和工艺耗时的拆解。
- 第四层把结果固化为可复用的管理指标，支撑诊断、对比和追踪。
3. 核心数据链路
3.1 目标数据链路
系统存在两条并行但互补的基准链路：
- 长周期基准：依托历史样本，强调跨工位的一致性和稳定性
- 设计基准：依托工艺设计与规则逻辑，强调新产线、新工艺和初始导入场景
两条链路最终都要落到统一的目标数据上，用于后续实际节拍拆解和报表汇总。
技术上更重要的不是“谁更准确”，而是“在什么场景下用哪一种基准更合适”。
更完整的业务解释见业务文档中“理论基准”的定义部分。
3.2 实际节拍链路
实际节拍以节拍窗口内的真实时长为主线，再把窗口内的告警片段叠加进去，形成可解释的结构化结果。
业务层面的损失解释见业务文档中的“节拍损失拆解图”，本文这里只描述技术处理顺序。
| 时序窗口 | → | 告警过滤 | → | 区间合并 | → | 节拍拆解 |
说明：
- 先在节拍窗口内截取有效告警，再合并重叠或连续的告警段，避免重复计算。
- 告警必须经过白名单和位号规则过滤，确保只保留与该研究对象相关的异常。
- 结果不是简单的“报警总时长”，而是能进入节拍结构分析的标准片段。
4. 关键算法
4.1 长周期基准生成
长周期基准的核心思想，是通过一组候选分位系数搜索出“跨对象更稳定”的基准值。
基本过程可以概括为：
- 先收集同一产线下满足条件的基准对象
- 在候选分位系数范围内逐个试算
- 对每个系数，计算各对象对应的分位值
- 以对象间方差更小作为更优解
- 输出最终的基准值和配套参数
| 候选系数扫描 | 对象分位值计算 | 跨对象方差评估 | 选择最优基准 |
说明：
- 这里的分位系数不追求极值，而追求稳定性。
- 关键不是“取最小或最大”，而是“让同类对象之间更一致”。
- 同一系数通常会同时驱动多个目标口径，保证基准体系的一致性。
4.2 设计基准生成
设计基准更偏规则驱动，适合新产线、初始导入或历史样本不足的场景。
其关键点是：
- 以设计时长作为基础输入
- 通过逻辑表达式组合出上层口径
- 在动态对象缺失时，允许用设计时长回退补齐
- 让基准可随工艺配置变化而变化，而不是依赖大量历史样本
说明：
- 长周期基准解决“过去通常是多少”。
- 设计基准解决“按工艺定义应当是多少”。
- 两者不是替代关系，而是不同场景下的基准来源。
4.3 实际节拍拆解
节拍拆解时，系统先识别节拍窗口内的有效报警，再把报警时长与实际时长差值做结构化拆分。
可以理解为：
- 报警时长优先归入故障贡献
- 实际时长与基准时长的差值，再继续拆成工作偏差和等待偏差
- 当实际时长短于基准时，保留负偏差，便于识别节拍压缩或提前完成
| 理论节拍 参考基线 |
⇅ |
实际节拍
|
说明：
- 理论节拍是参考基线，不与实际节拍处在同一维度。
- 实际节拍中的各项构成才是分析对象。
- 这个拆解图的目的，是把“偏快、偏慢、异常停顿”分开看，而不是简单相加。
4.4 口径聚合
聚合层主要做三件事：
- 将单次节拍结果汇总成产线级和工位级指标
- 将不同类型的节拍损失统一到一套口径里
- 将时间比例和数量比例同时输出，便于横向比较
核心上可归纳为三类结果：
- 瓶颈结果：关注工作占比、等待占比、故障占比和总体利用率
- 负载结果：关注浪费、搬运和工艺有效部分的结构关系
- 节拍结果：关注分布、稳定性和离散程度
5. 指标口径映射
5.1 瓶颈指标
瓶颈类结果在技术侧主要输出工作占比、等待占比、故障占比和总体利用率。
这些字段用于承接业务文档中的瓶颈解释，不在此重复展开判读逻辑。
5.2 负载指标
负载类结果主要输出浪费、搬运和工艺有效部分的结构关系。
它们用于支撑业务文档中的负载分析结论，技术侧重点是保证口径一致。
6. 异步与沉淀方式
系统更适合采用“分段计算、结果沉淀、报表读取”的方式，而不是每次查询都实时重算。
原因很直接：
- 节拍基准计算依赖样本搜索，成本较高
- 实际节拍拆解需要处理告警合并，过程不轻
- 报表通常按天、班次或周期生成，更适合读快照数据
因此更合理的实现方向是：
- 计算链路与查询链路分离
- 目标结果和最终结果分层存储
- 报表读取稳定快照，减少线上临时计算压力
7. 后续实现方向
这一部分对应业务文档的“后续优化方向”，这里仅补充实现侧需要优先建设的能力。
7.1 基准分层更明确
建议将基准体系明确分成三层：
- 历史稳定基准
- 设计定义基准
- 现场校正基准
| 历史稳定 | → | 设计定义 | → | 现场校正 |
说明：
- 目标不是让三者互相替代，而是按场景选择最合适的基准。
- 这样可以减少“历史样本不足”时的空窗，也可以保留设计意图。
7.2 瓶颈原因树
建议把瓶颈结果进一步沉淀成原因树，形成“指标到原因”的稳定映射。
| 瓶颈结果 | → | 结构拆分 | → | 原因树 |
说明：
- 先看损失结构，再看根因，不建议直接从单一指标跳到结论。
- 原因树可以优先覆盖故障、等待、工艺三大类。
7.3 置信度和可用性
建议给基准结果补一层“可用性标签”，至少考虑：
- 样本是否足够
- 基准是否稳定
- 告警是否完整
- 逻辑配置是否有效
说明：
- 这样做的意义是让系统知道“能不能信”，而不是只知道“算出来了什么”。
- 对于新产线和异常波动产线，这一层尤其重要。
7.4 可解释看板
建议后续把结果展示从“单表输出”升级为“诊断看板”，重点展示：
- 基准与实际的偏差
- 损失结构占比
- 告警与等待的重叠关系
- 瓶颈对象的变化趋势
说明：
- 看板的价值不在于图多，而在于让用户一眼看懂“慢在哪里、为什么慢、先改哪里”。
- 这类展示适合配合产线、工位和工艺三级视角一起使用。
8. 小结
时间性能系统的技术核心，可以归纳为三句话：
- 用稳定的基准把现场节拍统一到同一条比较线上
- 用告警与窗口重叠关系把实际损失拆得可解释
- 用分层聚合把结果沉淀成可执行的改善方向
如果后续要继续优化系统，优先方向不是增加更多口径，而是让基准更清晰、损失更可解释、报表更易落地。