Dashboards and KPIs¶

1. Optimize refresh rate based on time range and use case¶

Align the refresh rate of a dashboard with both the specific use case and the selected time range. While a high refresh frequency (for example, every 30 seconds) may initially seem beneficial, it is only justified for real-time monitoring scenarios, such as machine tracking or live data analysis over short time windows.

In systems like Energy Manager, each refresh typically triggers data queries, KPI evaluations, and aggregation calculations across all widgets. Unnecessarily frequent refreshes can significantly increase backend load and negatively impact overall system performance and responsiveness.

For larger time ranges, such as daily, weekly, monthly, or yearly dashboards, frequent refreshing is typically unnecessary, as the underlying data does not change significantly within short intervals. In these cases, configure a lower refresh frequency to reduce system load and ensure stable performance, especially when multiple users access dashboards simultaneously.

Follow the general guidelines below:

Use high refresh rates only for short time ranges (for example, last hour or current shift) where near real-time insights are required.
Use lower refresh rates for longer time ranges (for example, weeks, months, years) where historical analysis is the focus.

Consider that dashboard refreshes affect all widgets simultaneously, which can amplify system load when multiple KPIs or complex calculations are involved.

Avoid combining long time ranges with high refresh frequencies, as it results in unnecessary data processing, increased backend load, and reduced system stability.

Balance data freshness with system efficiency so that your dashboards deliver meaningful insights without overloading the platform.

Use widget-level time configuration to increase flexibility and optimize performance. This lets you override the global dashboard time range and calculation context for individual widgets.

Design your dashboards more efficiently by separating the following KPIs:

Operational KPIs (short time range, high refresh)
Analytical KPIs (long time range, low refresh and higher aggregation)

For example, combine in a single dashboard the following KPIs:

A real-time KPI showing results for the last hour
A historical KPI tracking production trends over a week or month

Avoid applying the highest refresh requirement to the entire dashboard and configure each widget according to its specific purpose.

3. Optimize calculation period (aggregation Level)¶

Select the calculation period (aggregation level) based on both the time range and the analytical goal of the visualization.

Using very fine granularity (e.g., second-level resolution) for large time spans provides little additional value, as such detail cannot be effectively interpreted in overview dashboards. At the same time, it significantly increases the number of processed data points and the computational effort required.

Displaying too many individual data points reduces readability and limits insight generation. Effective dashboards focus on clear trends and meaningful patterns, not raw data density.

Follow the recommendations below:

Hourly aggregation for daily dashboards
Daily aggregation for monthly dashboards
Monthly aggregation for yearly dashboards

This approach reduces the amount of data that needs to be processed and transmitted while improving visual clarity.

For deeper analysis, rely on drill-down capabilities, to investigate anomalies or peaks at a more detailed level without compromising overall dashboard performance.

4. Understand KPI calculation behavior¶

By default, KPIs are calculated on-the-fly whenever they are requested. Every dashboard refresh triggers a full recalculation of all KPIs used across all widgets.

This behavior ensures up-to-date values, but it can also cause significant performance issues, in the following scenarios:

KPIs are based on large datasets.
Multiple data sources are combined.
Complex formulas or aggregations are used.
Long time ranges are requested.

The combination of high refresh rates and complex KPIs can result in excessive system load.

5. Use KPI storing for performance optimization¶

To improve performance and scalability, store and reuse KPI results instead of recalculating them on demand.

By storing KPIs, you can write computed values to variables at defined intervals, so that dashboards only need to retrieve precomputed results rather than execute full calculations on every refresh.

This approach provides the following advantages:

Faster dashboard loading times
Reduced computational effort on the backend
Improved system stability and scalability

Consider this approach for the following scenarios:

Complex KPIs with multiple dependencies
Aggregations over long time ranges
Frequently accessed dashboards

Align the KPI storage cycle with business requirements and maintain a proper balance between data freshness and performance.

Example: A yearly KPI used for monthly reporting may only require daily recalculation, rather than recalculating values on every dashboard refresh.

To structure the KPI storage efficiently, follow the guidelines below:

Assign each stored KPI its own dedicated aspect and variable.
Avoid grouping multiple stored KPIs in a single aspect, as this increases processing overhead when writing values.

6. Follow an iterative optimization approach¶

Approach performance optimization iteratively rather than attempting to optimize everything at once.

Start with the most critical or resource-intensive dashboards (e.g., those with large time ranges or complex KPIs) and gradually apply improvements.

Typical optimization steps include:

Adjusting refresh rates
Increasing aggregation levels
Introducing KPI storing

To validate the impact and avoid unintended side effects, monitor system behavior and performance after each change.

7. Balance real-time requirements and performance¶

Use real-time data only where it provides clear operational benefit.

In many business scenarios, near-real-time updates (for example, every few minutes or on an hourly basis) are entirely sufficient for decision-making.

Overusing real-time refreshes does not necessarily improve insights but can significantly increase system load and reduce stability.

Focus on delivering relevant and actionable insights, rather than maximizing data frequency at the expense of performance.

Except where otherwise noted, content on this site is licensed under the Siemens Inner Source License .