General Knowledge Base
- Alarms (E0) in TM Master
- Change Log TM Master (New Portal Address Soon)
- Common (Global) Data in TM Master v2
- Component Code Philosophy
- Data update through Microsoft Excel
- Department name needs to be displayed on PO print/report
- Description of Risk Analysis Documents
- Description of Work Permit
- Duplicate Critical Component Codes
- Exceptions in Windows Firewall
- GDPR and TM Master
- How the Average Running Hour Value is Calculated
- How To - Adding single unit to subfolders in Document Handling Module
- I get a Message Saying That TM Master is "Not responding".
- Import large Number of Order Lines From Excel in to a New Draft in TM Master
- Ionos No Longer Supported
- Last updated" Column is Red in PO Module
- Medic Module
- Missing Self Assessment Report
- Order line Number Assignment
- Pre-warning for Jobs
- SNAPS Integration - Settings
- Standard Jobs
- Supplier Self-Assessment Export: Unlocking Excel Sheet for Editing
- Technical guide for installations, upgrades, migrations, replication troubleshooting, etc.
- The Database Cleaning Tools for TM Master V2
- The Functions & Purpose of The Proforma Module
- The New Dive Module Rules
- TM Exchange Settings
- TM Master Rules and Regulations Interpretation For Time Sheet
How the Average Running Hour Value is Calculated
The formula for the running hour average is as follows.
Average running hours : (LRHAvrg * 0.4) + (LRHDiff / NDaysSLE * 0.6)
LDRHAvrg = Last Weighted Daily Running Hour Average.
LRHDiff = Last Running Hour Difference entered.
NDaysSLE = Number of days since last entry
As you probably see this “average” is not the real average but a weighted one (or a “moving average”). This is done In order to make the daily average responsive to changes in use.
For each entry the system calculates the mean between the existing average and the new entry’s average. The new entry’s average is weighted 60% and the existing 40%. This way, newer readings will have larger impact on the mean value. This makes the mean more responsive to changes in day to day usage. Which again, lead to a more correct representation of the components current usage, than with the use of a normal “average”.
As you can see in the example below the “real” average = 5,19 but since the use of the component has dropped the last 60 days, the weighted average reflects this much faster at “0,83”. The more entries added to the system the more unresponsive the real average will be to changes.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article