00 时间性能系统领域知识

---

title: 时间性能系统领域知识
area: domain-knowledge
kind: domain-overview
topic: time-performance-analysis
status: active
children:

• ‘[时间性能系统技术领域知识](/20_Domain_Knowledge/23 时间性能分析/01 时间性能系统技术领域知识/)’
  upstream:
• ‘[工业数据接入](/20_Domain_Knowledge/21 工业数据接入/00 接入模式/)’
• ‘[工业智能平台总体架构](/10_Architecture/11 平台总览/工业智能平台总体架构/)’
• ‘[数据能力估算](/10_Architecture/13 架构参考/数据能力估算/)’
  related:
• ‘[曲线质量分析](/20_Domain_Knowledge/22 曲线质量分析/00 曲线分析系统领域知识/)’
• ‘[预测性维护](/20_Domain_Knowledge/24 预测性维护/00 PDM业务领域知识笔记/)’

---

2. 核心业务对象

2.1 研究对象

研究对象是分析的基本组织单元，常见可以是：

• 产线
• 产线下的工位
• 工艺流下的子单元

研究对象通常具有层级关系，系统会按层级把数据汇总到不同管理层面。

2.2 节拍

节拍不是简单的时间段，而是带业务语义的时间片段。

节拍通常有两类：

• 主节拍：代表一个完整业务周期
• 子节拍：代表主节拍内部的动作、阶段或工艺步骤

一个节拍至少要能说明：

• 它什么时候开始
• 它什么时候结束
• 它属于哪个研究对象
• 它对应什么工艺或动作
• 它的理论上限和下限是什么

2.3 理论基准

理论基准代表“正常情况下应该花多少时间”。

理论基准通常分三部分：

• 总节拍基准
• 工作时间基准
• 工艺时间基准

从业务上看，它不是“理想化的空想值”，而是用来衡量实际生产偏差的参照物。

2.4 实际节拍

实际节拍是现场真实发生的结果，包含：

• 实际持续时间
• 理论基准
• 报警占用
• 故障损失
• 非必要等待
• 风险标识

实际节拍是后续分析报表的基础事实。

---

3. 节拍分段的业务逻辑

3.1 节拍分段不是固定切法，而是配置驱动

节拍如何切分，取决于生产线、工位、工艺、产品型号、工具、序列号等多种条件。

这意味着同一条线在不同产品、不同工况、不同工艺下，节拍边界可能不同。

3.2 节拍的层级结构

系统里，主节拍和子节拍共同构成完整的生产时间结构：

• 主节拍代表完整业务周期
• 子节拍代表主节拍内的动作拆解

后续所有统计和分析，最终都要回到主节拍，才能形成统一口径。

3.3 研究对象与工位的关系

系统不是直接把分析对象理解为“设备”，而是通过工位、节点、产线关系把现场数据归集到研究对象。

这说明系统更关注业务管理单元，而不是单纯关注设备点位。

3.4 设计时长与动态时长

并不是所有工艺都能用一个固定数值描述。

有些节拍会受到以下因素影响：

• 产品型号
• 棒长或物料规格
• 模具状态
• 工艺流变化
• 不同工况下的补偿逻辑

因此系统允许把理论时间拆成“基础时间 + 补偿时间”的形式，并支持按业务规则动态取值。

---

4. 理论基准的两种来源

4.1 长周期基准

长周期基准来自历史生产数据，更像“经验稳定值”。

它的特点是：

• 来自一段时间内的真实生产表现
• 重点不是极值，而是稳定性
• 目标是找到跨工位一致性较好的基准

工业上，这类基准更适合成熟产线，用来反映长期稳定状态下的合理节拍。

4.2 设计基准

设计基准来自工艺设计和配置逻辑，更像“标准理论值”。

它的特点是：

• 反映工艺设计意图
• 不依赖大量历史数据
• 适合新产线、新工艺、初期导入场景

工业上，这类基准更适合回答“这个工艺本来应该怎样运行”。

4.3 两类基准的区别

可以把它们理解成两种不同的知识来源：

• 长周期基准：统计经验型，更适合持续优化
• 设计基准：工艺规则型，更适合工艺标准制定

---

5. 实际节拍的解释逻辑

5.1 报警是故障证据，但不是全部损失

系统会把节拍窗口内真实发生的报警提取出来，作为故障损失分析的直接证据。

这一步的业务意义在于：

• 报警时间不能直接等同于全部损失
• 但报警是最重要的故障证据之一
• 需要结合节拍窗口进行裁剪、合并和过滤

5.2 故障损失和非必要等待的拆分

系统会先看节拍实际消耗与理论基准之间的差值，再根据报警时长进行拆分：

• 先判断差值是否为负
• 再判断差值是否落在报警时长以内
• 超出报警时长的部分，归入非必要等待

这背后的业务理解是：

• 故障损失更像“明确可归因的异常停顿”
• 非必要等待更像“流程协同、节奏匹配、搬运、排队等造成的额外耗时”

5.3 四个关键时间口径

系统在管理上常用四个口径描述节拍损失结构：

• 工作时间：真正用于生产推进的时间
• 必要等待：工艺上不得不等待的时间
• 非必要等待：流程或协同造成的额外等待
• 故障时间：设备、报警、质量、维护等引起的损失

这四个口径不是互相独立的物理事实，而是从节拍事实中拆出来的管理视角。

5.4 节拍损失拆解图

这张图把一个节拍的时间结构拆成了四层：工作时间、必要等待、非必要等待和故障时间。
它的作用不是展示数学公式，而是帮助业务人员快速看出，实际节拍为什么会偏离理论节拍。
这里要特别注意，理论节拍和工作时间不在一个维度上：

• 理论节拍是参考基准线，用来衡量是否偏离
• 工作时间、必要等待、非必要等待、故障时间是实际节拍的构成项

读这张图时，建议优先关注三件事：

• 左边的工作时间，是不是足够稳定
• 中间的等待时间，是不是存在流程衔接问题
• 右边的故障时间，是不是存在明显的异常停顿

理论节拍（参考基线）

实际节拍

工作时间

必要等待

非必要等待

故障时间

图里的关系可以这样理解：

• 理论节拍：说明这是一条参考基线，不参与实际节拍构成
• 实际节拍：说明这是现场真实发生的总耗时
• 工作时间：说明这部分时间是价值推进的核心部分
• 必要等待：说明这部分时间是工艺上必须接受的停留
• 非必要等待：说明这部分时间多半来自上下游节奏不一致
• 故障时间：说明这部分时间需要优先排查设备、报警和质量问题

---

6. 瓶颈识别的业务逻辑

6.1 瓶颈不是一个点，而是一种损失结构

时间性能系统的瓶颈识别，不是只找“最慢的地方”，而是看整个损失结构：

• 哪个研究对象的有效利用最差
• 哪个研究对象的故障损失最高
• 哪个研究对象的等待损失最高
• 哪个研究对象的理论与实际偏差最大

所以瓶颈判断通常不是单一结论，而是多指标共同支持的结果。

6.2 瓶颈工位的典型判断思路

一个工位是否构成瓶颈，通常要看：

• 是否长时间占用关键资源
• 是否持续拖慢上游或下游节拍
• 是否在班次、周期或月度统计里反复出现
• 是否伴随大量故障或等待

6.3 瓶颈工艺的典型判断思路

一个工艺是否构成瓶颈，通常要看：

• 工艺动作是否过长
• 工艺顺序是否不平衡
• 理论工艺时间是否明显高于同类工艺
• 该工艺是否引起大量等待或故障

6.4 瓶颈原因的三层结构

工业现场的瓶颈通常来自三层原因：

1. 设备层
2. 工艺层
3. 协同层

设备层常见原因包括：

• 报警
• 停机
• 维修
• 互锁

工艺层常见原因包括：

• 节拍设计不合理
• 工艺顺序不均衡
• 参数波动
• 工艺切换成本高

协同层常见原因包括：

• 搬运等待
• 排队等待
• 上下游节奏不匹配
• 物料供应不及时
• 信息同步滞后

---

7. 报表体系的业务含义

系统不是只做一个报表，而是从不同角度看同一件事。

7.1 节拍分布

节拍分布关注的是单个节拍的波动情况，回答：

• 节拍稳定不稳定
• 是否有极端异常
• 大多数数据落在哪个区间

适合判断：

• 工艺是否稳定
• 现场是否存在波动性风险

7.2 负载分析

负载分析关注的是时间被花在什么地方：

• 工艺时间
• 搬运时间
• 浪费时间

它更适合回答：

• 时间到底花在创造价值上，还是花在无效消耗上

7.3 瓶颈分析

瓶颈分析更聚焦于：

• 故障损失高不高
• 非必要等待高不高
• 必要等待是否过长
• 整体有效利用率是否偏低

它更适合回答：

• 哪些地方最值得优先改善

---

8. 时间性能系统的领域知识模型

阶段	输入	输出	业务含义
节拍定义	工位、工艺、偏移、上下限、规则、设计时长	可切分的节拍结构	定义节拍边界和解释方式
理论基准	历史表现或设计规则	理论总节拍、工作时间、工艺时间	定义“正常应该是多少”
实际节拍	时序数据、报警、现场白名单	实际节拍结果	还原真实生产过程
损失拆分	实际节拍、理论基准、报警时长	故障时间、等待时间、工作时间	解释损失来自哪里
瓶颈识别	节拍结果、损失结构、班次、周期	瓶颈工位、瓶颈工艺、瓶颈原因	判断优先改善点
管理输出	多维统计结果	报表、对比、趋势	支撑管理决策和持续优化

---

9. 对系统建设最重要的业务认知

这部分是对前文的归纳，不再展开新的概念，而是把前面的结论收拢成三条最关键的判断原则。

9.1 先看损失集中度

瓶颈的本质不是单点速度慢，而是损失在某个位置持续集中。优先看哪里最常出现故障、等待和偏差，而不是只看谁“最慢”。

9.2 再看原因层级

同一个瓶颈，通常会同时受到设备、工艺、协同三层因素影响。判断时应先分层，再归因，避免把结果当原因。

9.3 最后看基准选择

不同场景要用不同基准。成熟产线更关注长周期基准，新工艺更关注设计基准，二者的差异本身也是重要的管理信息。

---

10. 后续优化方向

这一章不是再讲原理，而是把后续建设拆成五个更具体的优化方向。每个方向都对应一类管理动作，也对应一张更适合沟通的业务图。

10.1 建立瓶颈原因树

目标是把“瓶颈在哪里”继续追问到“为什么会在这里”。
建议把原因分成三层：结果层、原因层、证据层，这样业务人员可以沿着树往下追，而不是只看一个结论。

瓶颈结论

故障类

等待类

工艺类

协同类

报警

排队

工艺切换

上下游节奏不匹配

这类图适合用在管理讨论中，先把问题归类，再去找证据，最后再决定先改哪一类。

10.2 强化基准分层

目标是明确“用哪一条线作为参考”。
建议把基准分成三层，并在图表中固定显示它们的适用场景，避免成熟产线、新工艺、短期波动混在一起比较。

设计基准	长周期基准	短周期参考
回答“应该怎样运行”	回答“长期平均表现如何”	回答“近期是否波动”

这张图的重点是把“标准值”和“观察值”分开，避免把工艺设计、长期经验和短期扰动放到同一个口径里比较。

10.3 提高瓶颈结论的可信度

目标是让瓶颈结论不只是“看起来像”，而是“有足够证据支持”。
判断可信度时，建议同时看三件事：是否重复出现、是否多指标一致、是否能被现场验证。

重复出现	多指标一致	现场可验证
在多个班次、周期里都出现	故障、等待、节拍偏差指向同一位置	能在现场动作、报警或工艺记录里找到对应证据

这类图适合用来判断一个瓶颈是否值得优先治理，避免把偶发问题误判成长期问题。

10.4 强化子节拍的业务解释

目标是让每个子节拍不只是一个切分结果，而是一个能被业务人员理解的动作单元。
建议把子节拍和工艺动作、设备状态、管理含义放在同一张图里，帮助现场从“时间段”理解到“业务动作”。

子节拍	对应动作	管理含义
开始段	准备、定位、启动	是否存在前置准备过长
执行段	核心加工、输送、装配	是否是效率主区段
结束段	收尾、复位、等待释放	是否存在收尾拖尾

10.5 从报表走向诊断面板

目标是把“结果展示”升级成“诊断展示”。
诊断面板不只显示数值，还要把基准、实际、损失和上下文放在一起，方便快速定位。

当前节拍	理论节拍	故障损失	等待损失	工艺损失
现在到底怎么样	应该是多少	哪里停了	哪里等了	哪里慢在工艺上

诊断面板的价值在于把“看报表”变成“看问题”，让管理动作更直接。

---

11. 一句话总结

时间性能系统的核心，是把产线时序数据转化成一套可解释的节拍知识，通过理论基准、损失拆分和瓶颈归因，把“哪里慢”进一步变成“为什么慢、慢在哪里、该先改什么”。