Definition
Report Analytics performs statistics, summarization, and visualization on device data and operation and maintenance metrics (MTTR, online rate, number of alerts, etc.). It can integrate with BI, Tableau, Power BI and supports custom reports and export.
Key Metrics and Data Sources
Report Analytics covers device online rate, active device count, alert statistics, OTA success rate, MTTR, device health distribution, and more. Data sources include Time Series DB time series database, device metadata, Event Stream event stream, and work order system. It supports aggregation by product, group, region, and time dimension; supports year-on-year and month-on-month comparison, trend analysis. The platform can provide predefined report templates or customize dashboards through Dashboard.
Integration with BI Tools
The Device Management Platform exposes aggregated data through OpenAPI or RESTful interfaces for tools such as Tableau, Power BI, and Grafana. It supports scheduled export, real-time connection, and Webhook push. Reports can be embedded into business systems or exported as PDF/Excel, meeting the needs of management reporting and compliance audits. When deeply integrated with BI platforms, it enables joint analysis of device data with business data such as ERP and EAM.
Use Cases
Suitable for operation KPI dashboards, equipment utilization analysis, fault trend reports, SLA achievement statistics, cost analysis, and more. Report analysis is a key capability of the Device Management Platform from "managing devices" to "using data," supporting operational decisions and continuous improvement.
The metric definition comes before the chart layout
Report analysis fixes the numerator, the denominator, and the time boundary of each number first. The chart comes second. Online counted as "the session is up at the query instant" and online counted as "it connected at least once that day" are two results that cannot be compared. Repair time from alarm creation to work-order close includes the wait for parts. Repair time from when someone started work reflects only the time after hands-on work began. Mix the two definitions on one report and a rise versus the previous period cannot be explained. Write the definition on the metric itself, not in a footnote under the legend that the reader is left to guess.
State which layer the number was taken from. Raw telemetry, a one-minute mean, and a duration typed by hand on a work order cannot be added together. A spike already discarded by the aggregation layer cannot be described again in the report as "no limit was crossed." An exported file should carry the definition version and the time it was generated, so a table exported two months ago and a table of the same name today are not dropped into one comparison. Change the definition and keep the old name, and the historical curve shows a false step on the day of the switch.
When aggregation grain matches the sampling period
A report grain is usable when it is no finer than the grain the data actually retains. If a device reports every five minutes and the report draws a continuous curve by the second, the points in between are interpolation. They cannot be used to judge an instantaneous fault. The other way around, if only a daily rollup is kept, the report cannot say whether the fault was in the morning or the afternoon. Before choosing a grain, confirm the time-series retention policy and whether the work-order time fields are complete. Count records with missing fields on their own. Do not quietly drop them from the denominator.
A grouping dimension has to exist in the source data. A rollup by site assumes each device has one site during the period being counted. A device transferred midway must be assigned to the source site, the destination site, or split by the hour. Without that rule, adding the device counts of two site reports exceeds the total. A report compared with a service level agreement may use only the metrics named in the agreement. Do not substitute a number that looks better. The summary a manager sees and the detail an operator sees should drill through the same identifier. When the summary does not match the detail, check against the detail's definition.
Mixing the online rate and the activity rate into one number
Online describes whether a connection exists. Active describes whether there was business data during the period. A device that holds a long connection but no longer reports measurements is still online and is not active. Using the online rate in place of the activity rate counts a device that has stopped measuring as running normally. The reverse, defining online by report count, counts a healthy low-frequency device as offline. List the two metrics separately, and state which message types count as active. A heartbeat is not a business report.
Upgrade success is easy to count too wide as well. If the denominator includes only devices that already returned a result, silent failures disappear and the ratio looks good. The denominator should be the devices the task planned to cover. The numerator is the devices that reached the target version inside the observation period. Devices that timed out with no report are listed on their own. Adding alarm counts directly is distorted in the same way. If one root alarm fans out into dozens of repeat notices, the report should be able to count events after suppression, and still keep the raw count so suppression can be checked for being too aggressive. Showing only the raw count makes a notice storm look like a rise in the number of faults.
Each published report should keep a detail index generated with the chart. The index holds the device identity, the counting window, and the reason that device was included or excluded. When a reader doubts the total, they can follow one device through that reason instead of guessing the formula again. Count the exclusion reasons themselves: not provisioned, scrapped, clock untrustworthy, no sample inside the window. A sudden rise in those exclusions usually means collection or master data has gone wrong, not that the business metric truly improved. The total on the chart should equal the included items. If the two disagree, stop sending that issue externally. Before an external send, someone who did not build the table should recompute at least one sample from the index. If the recomputation disagrees, send the whole issue back. Do not fix it by editing the label on the chart.