MTTR和MTBF的KPI逻辑

2020-08-16 11:55发布

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


你好大师,

以下是MTTR和MTBF的KPI。 这些列如下:我的业务给出的公式,输入,自定义表,PM顾问(Me)给出的逻辑。 我只想知道逻辑是否正确。 他们想要获得的度量单位也是"天"。 在我也给出了逻辑之后,我的技术人员仍然感到困惑。 请帮帮我。 您也可以输入给定的表格以供参考。 他想知道如何获得可用时间,故障时间和否。 故障。

谢谢。

MTBF(可用时间-分解时间)/分解次数班次日期ZTPM_DETENTION自定义1.在ZTPM_DETENTION中传递班次日期(SHIFT_DATE),其中DCODE = 007 *和DETENTION_MIN <> 0。
2.对于任何PLANT(植物)和ZSEC(Section)组合,计算两个连续条目之间的时间间隔,并获取给定时间段内所有条目的算术平均值(START_DATE:第二个条目的START_TIME)-(END_DATE:END_TIME 第一次进入)。 MTTR故障薄荷糖/号 细分日期班次日期ZTPM_DETENTION自定义访问表ZTPM_DETENTION。
1.在ZTPM_DETENTION中传递班次日期(SHIFT_DATE),然后选择拘留代码-DCODE = 007 *&DETENTION_MIN <> 0。
2.为所有SHIFT的每个ZSEC获取DETENTION_MIN。 将当天该部分的所有Detention_min的总和显示为MTTR。
3. 007 *类别下的拘留代码为007A,007B,007C。

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


你好大师,

以下是MTTR和MTBF的KPI。 这些列如下:我的业务给出的公式,输入,自定义表,PM顾问(Me)给出的逻辑。 我只想知道逻辑是否正确。 他们想要获得的度量单位也是"天"。 在我也给出了逻辑之后,我的技术人员仍然感到困惑。 请帮帮我。 您也可以输入给定的表格以供参考。 他想知道如何获得可用时间,故障时间和否。 故障。

谢谢。

MTBF(可用时间-分解时间)/分解次数班次日期ZTPM_DETENTION自定义1.在ZTPM_DETENTION中传递班次日期(SHIFT_DATE),其中DCODE = 007 *和DETENTION_MIN <> 0。
2.对于任何PLANT(植物)和ZSEC(Section)组合,计算两个连续条目之间的时间间隔,并获取给定时间段内所有条目的算术平均值(START_DATE:第二个条目的START_TIME)-(END_DATE:END_TIME 第一次进入)。 MTTR故障薄荷糖/号 细分日期班次日期ZTPM_DETENTION自定义访问表ZTPM_DETENTION。
1.在ZTPM_DETENTION中传递班次日期(SHIFT_DATE),然后选择拘留代码-DCODE = 007 *&DETENTION_MIN <> 0。
2.为所有SHIFT的每个ZSEC获取DETENTION_MIN。 将当天该部分的所有Detention_min的总和显示为MTTR。
3. 007 *类别下的拘留代码为007A,007B,007C。
付费偷看设置
发送
3条回答
奄奄一息的小鱼
1楼-- · 2020-08-16 12:42

早上好

我假设MTBF表示两次故障之间的平均时间。 故障一词通常会引起一些混淆-MTBF通常用于衡量"正常运行时间"-故障之间的时间间隔。

要计算两次故障之间的平均时间,您需要跟踪解决故障和开始故障的时间点。 解决与开始故障之间的时间间隔是故障事件之间的时间间隔-正常运行时间。

所有故障事件之间的所有时间段的总和除以故障事件的数量,将为您提供您正在考虑进行评估的一段时间内的平均故障间隔时间。

  上------> |  | ---------------> |  | -------------> |
            失败了失败了
  向下| ===========> |  | =========> |  | ===>

  时间=> 0 --------- 10 ------------- 20 -------- 25 ---------- 50-  -

 

在上面的示例中,我们有两个完整的运行周期,从10到20的10个单元和从25到50的25个单元。因此,在这里,我们有35个正常运行时间(在故障之间)和两个故障周期导致 至35/2 => 17.5单位之间的故障间隔时间。

为使生活更加复杂,一些组织不仅需要考虑停机时间与正常运行时间的二元状态,还需要考虑组件或系统何时需要运行。 如果组件或系统故障已解决,但正常运行时间未开始,则结束停机时间总和<>正常运行时间总和。

对于您的计算,由于我不了解您的客户特定的Z表设计,因此我无法确定您的伪代码。 我相信您可以根据您对Z表设计的了解使用上面的说明来达到一定的置信度。

能不能别闹
2楼-- · 2020-08-16 12:39

嗨,

我对您的自定义项尚不清楚 您指定的表格,因为我看不到这些表格的字段。

在开始讨论逻辑之前,您必须了解我们在谈话时客户端在通知级别输入的停机时间长度 关于MTTR/MTBF和MTTF。

如您所说,您的客户要将UOM设置为" Day",则可以使用自定义逻辑将小时数转换为" Day"。 您是在考虑总停工时间还是仅考虑技术对象的实际停工时间(不包括隔离/恢复时间等...)?

我可以说,捕获B的长度因企业而异/D在通知级别...如果您的客户在处理RCM概念方面非常有效,则必须了解所捕获的故障时间的长度。 我要强调的原因是,当主设备由于子设备故障而停止时,我们不能认为这是主设备的故障。 但是,我们可以将停机记录为生产的延迟,也可以使用系统可用性信息...如果我们有备用子设备,则在子设备发生故障时,我们可能会切换为备用设备。 在这种情况下,我们无法将停机时间更新为总停机时间...

< p>我们也必须考虑以下信息,才能满足您的要求。

此信息将提供故障前后技术对象的可用性。

我建议您在通知级别使用自定义屏幕,以便在用户输入自定义字段时可以更新自己的逻辑。 "故障数据"/"系统可用性"中的值,您可以在关闭通知期间根据业务需求转换参数,并可以在您的自定义字段中进行填充...通过这种方式,它可以帮助您的客户跟踪导致 停机,还可以帮助他们了解B/D之前和之后的系统可用性。​​

如果按照当前设置使用自己的自定义表格数据,我需要您 考虑以下关键点来计算您的MTTR/MTBF/MTTF ...

  • 该月的第一个/最后一次故障开始
  • 记录的故障数
  • < li>维修间隔时间
  • 实际故障数
  • 平均维修间隔时间
  • 该月的总停机时间
  • 平均维修时间 月

注意:请确保技术对象的启动日期,因为我们可能会拆除并重新安装在所需的F/L中...在放置自定义逻辑时我们必须小心 考虑特定F/L中设备的实际运行时间(小时/天)。 由于备用设备的运行时间可能不同...这将有助于评估每个位置/位置等方面的技术对象故障...

如果有时间和技术团队的帮助, ,您可以通过信息结构S070进行更清晰的了解。

您还可以参考以下信息以了解逻辑:

MTTR:总维护时间/总维修次数

MTBF:总运行时间/故障总数

注意:

由于备用设备可能正在运行,您可能必须了解其运行时间的维护策略 偶尔。

MTTF:总运行小时数/总单位数。

注意:MTTF是可靠性的基本量度,主要强调对象预期可以持续的时间长度 直到失败为止……这主要集中在类似的技术对象"平均失败时间"上。

问候,

Pardha Reddy.C

昵称总是被占用
3楼-- · 2020-08-16 12:42

一周热门 更多>