Dieser Beitrag erläutert diverse Modifikationen in der DeltaApp, die in verschiedenen Anwendungsfällen von Nutzen sein können. Damit führen wir den Beitrag „KPI-Wechsel in der DeltaApp“ fort, der im Oktober 2021 erschien.
Unser früherer Beitrag beschreibt den Wert- und Formatwechsel im Kontext eines KPI-Wechsels bei Navigationsschritten (Drill-down) innerhalb der DeltaApp. Dieser Wechsel wurde am Beispiel einer IoT-Anwendung zur Überwachung von Heizzentralen veranschaulicht: von einer Fallkennzahl (Alarm beim Über-/Unterschreiten eines gewissen Toleranzbereichs) hin zum konkreten Messwert, der von Temperatursensoren in den verschiedenen Heizobjekten gemeldet wird.
Im vorliegenden Beitrag beleuchten wir die folgenden Themen:
- Verwendung einer Farblogik, die unabhängig vom KPI-Wert ist
- Veränderung von Schwellwerten in der Farblogik
- Anzeige von 0 statt „n. v.“ bei nicht vorhandenen Daten
- Anzeige von Symbolen hinter Werten
- Anzeige von Statustexten
Als Anwendungsbeispiel nutzen wir wieder die Heizsystemüberwachung. Das Verständnis des Beitrags „KPI-Wechsel im Bissantz DashBoard“, sowie Grundkenntnisse zu der Datenbank, die aus DeltaMaster exportiert wird, setzen wir dabei voraus. Zum Editieren der Datenbank wird das Programm SQLite verwendet.
Verwendung einer vom KPI-Wert unabhängigen Farblogik
Dieser Abschnitt beschreibt die Verwendung einer Farblogik, die unabhängig vom KPI-Wert ist. Die Idee dahinter: Die Rot-Blau-Färbung eines KPI richtet sich nicht nach dessen Wert, sondern wird unabhängig davon aus einer anderen Kennzahl ausgelesen. Beispielsweise kann eine Warmwassertemperatur von 50 °C in Abhängigkeit von Ort, Monat oder Tageszeit innerhalb oder außerhalb eines definierten Toleranzbereichs liegen.
Für diese Funktion wird eine zusätzliche Kennzahl benötigt, welche im Folgenden als Farb-KPI bezeichnet wird. Für die originäre Kennzahl wird in den Feldern [T_APPDEF_DashboardKpis].[BIColorDashboardID] (Datentyp INTEGER) und [T_APPDEF_DashboardKpis].[BIColorKpiID] (Datentyp INTEGER) auf den jeweiligen Farb-KPI verwiesen. Voraussetzung dafür ist, dass der originäre und der Farb-KPI in der Tabelle [T_APPDEF_DashboardKpiStructures] dieselben Einträge und identische Strukturelemente besitzen, woraus sich die Empfehlung ableitet, pro originäre Kennzahl einen separaten Farb-KPI zu verwenden. Zudem muss im Feld [T_APPDEF_DashboardKpiValues].[KPISwitchExpression] die hinterlegte Bedingung zu Durchführung eines KPI-Wechsels für den Farb-KPI äquivalent zum originären KPI definiert sein.
Bezogen auf das Anwendungsbeispiel soll der KPI „Messwerte“ nicht nach seinem Wert, sondern nach dem Status der jeweiligen Messung eingefärbt werden, da sich die Toleranzbereiche zwischen verschiedenen Sensoren und Uhrzeiten unterscheiden können. Hierdurch kann kein allgemeingültiger Schwellwert für die Rot-Blau-Färbung über alle Sensoren definiert werden (Vergleich Abschnitt 3). Der Status einer Messung besitzt eine der folgenden drei möglichen Ausprägungen mit den entsprechenden Werten und der jeweiligen Farbgebung:
- Ausprägung Normal, Wert 1.0, Farbgebung dunkelblau
- Ausprägung Warnung, Wert -0.5, Farbgebung hellrot
- Ausprägung Alarm, Wert -1.0, Farbgebung dunkelrot
Für die originäre Kennzahl „Messwerte“ wird nun in den Feldern [T_APPDEF_DashboardKpis]. [BIColorDashboardID] und [T_APPDEF_DashboardKpis].[BIColorKpiID] auf den Farb-KPI verwiesen. Für unterschiedliche Sensoren kann demnach eine Warmwassertemperatur von 50 °C in der Farblogik positiv (blau) oder negativ (rot) gekennzeichnet werden (Abbildung 1).
Im Beitrag „KPI-Wechsel im Bissantz DashBoard“ wurde bereits der Wert- und Formatwechsel bei einem KPI-Wechsel erläutert. Bezogen auf das oben beschriebene Beispiel soll im Falle eines konfigurierten KPI-Wechsels von der Kennzahl „Anzahl Alarme“ auf die Kennzahl „Messwerte“ die Farbgebung durch den Farb-KPI nur bei Durchführung des KPI-Wechsels in der Strukturebene „Messwert“ angewandt werden. Damit bei Nicht-Durchführung des KPI-Wechsels die Färbung der originären KPI „Anzahl Alarme“ verwendet wird, muss für den Farb-KPI das Feld [T_APPDEF_DashboardKpiValues].[Expression] ein technisches NULL zurückgeben werden (CASE WHEN 1 = 1 THEN NULL ELSE NULL END). Im Feld [T_APPDEF_DashboardKpiValues].[CaseStructureExpression] wird für den Farb-KPI der Wert der Farbgebung zurückgegeben, der nur bei Durchführung des KPI-Wechsels für die Färbung der Kennzahl „Messwerte“ verwendet wird. Die Anzahl an Alarmen wird für ein Haus somit stets rot eingefärbt, während die einzelnen Messwerte eine Rot- oder Blaufärbung erhalten – in Abhängigkeit des jeweiligen Status (Abbildung 2).
Veränderung von Schwellwerten in der Farblogik
Der standardmäßige Schwellwert der Rot-Blau-Färbung von einer Kennzahl beträgt 0. Weist eine Kennzahl mit einem positiven Farbfaktor einen Wert kleiner 0 aus, so wird diese rot gefärbt. Bei einem Wert größer oder gleich 0 erhält diese KPI eine Blaufärbung. Bei KPIs mit einem negativen Farbfaktor verhält sich die Farbgebung umgekehrt.
Soll für einen KPI eine vom Standard abweichende Rot-Blau-Färbung angewandt werden, so kann das Feld [T_APPDEF_DashboardKpis].[BIColorThreshold] (Datentyp REAL) mit einem von 0 abweichenden Wert versehen werden. Der Farbfaktor von KPIs wird in Feld [T_APPDEF_DashboardKpis].[Factor] (Datentyp INTEGER) definiert.
Bezogen auf das Anwendungsbeispiel würde die KPI „Anzahl Alarme“ bei einem Wert von 0 standardmäßig rot eingefärbt werden, da der KPI einen negativen Farbfaktor besitzt. 0 Alarme verstehen wir allerdings als positiv, daher soll der KPI bei einem Wert von 0 blau eingefärbt werden. Hierzu kann das Feld [T_APPDEF_DashboardKpis].[BIColorThreshold] beispielsweise mit einem Wert von 0.01 definiert werden, sodass erst bei Vorliegen von einem oder mehreren Alarmen eine Rotfärbung der Kennzahl erfolgt (Abbildung 3).
Ein weiteres Beispiel ist eine Kennzahl namens „Service Level“, die einen positiven Farbfaktor besitzt. Diese Kennzahl ist ein Quotient aus der Anzahl an Messungen, die keinen Alarm ergeben, dividiert durch die Anzahl aller Messungen. Da ein Service Level unterhalb eines gewissen Schwellwerts, beispielsweise 80 Prozent, negativ gewertet wird, kann der Wert 80 in das Feld [T_APPDEF_DashboardKpis].[BIColorThreshold] eingetragen werden, um die inhaltlich passende Rot-Blau-Färbung zu erreichen (Abbildung 4).
Anzeige von „0“ statt „n. v.“ bei nicht vorhandenen Daten
Liegen für eine Kennzahl in einem Datenraum keine Werte vor, so wird standardmäßig als Wert „n. v.“ ausgewiesen. Soll für eine Kennzahl das Nicht-Vorhandensein von Werten als „0“ gewertet werden, so kann im Feld [T_APPDEF_DashboardKpis].[ReplaceNullByZero] (Datentyp INTEGER) eine 1 eingetragen werden, um eine Anzeige von „0“ statt „n. v.“ zu erzielen.
Im Anwendungsbeispiel wird diese Anpassung für den KPI „Anzahl Alarme“ vorgenommen, da das Nicht-Vorhandensein von Alarm-Daten durch die Sensoren als positiv zu verstehen ist und mit einer blau gefärbten „0“ ausgewiesen werden soll (Abbildung 5).
Anzeige von Symbolen hinter Werten
Sollen Symbole anstatt Einheiten hinter den Werten einer Kennzahl stehen, so lässt sich dies über das Feld [T_APPDEF_DashboardKpiValues].[Format] (Datentyp VARCHAR (20)) umsetzen. Hier können grundsätzlich anzuzeigende Maßeinheiten in Klartext hinterlegt werden (z.B. „°C“). Werden in diesem Feld in ASCII-Code codierte Zeichen hinterlegt, dann kann die DeltaApp diese interpretieren und das entsprechende Zeichen innerhalb ihrer Dashboards anzeigen.
In unserem Beispiel soll für die Kennzahl „Anzahl Alarme“ jeweils ein Warndreieck hinter dem Wert angezeigt werden. Durch Verwendung von „\u26A0\uFE0E“ im Feld [T_APPDEF_DashboardKpiValues].[Format] lässt sich dies realisieren. Das Ergebnis lässt sich in obiger Abbildung 2 erkennen: Hier wird hinter den Alarmen ein Warndreieck und hinter den Messwerten die angegebene Temperatur-Einheit „°C“ angezeigt.
Anzeige von Statustexten
Unter Umständen kann es hilfreich sein, in einem Dashboard auch Statustexte anstelle von Werten für KPIs auszuweisen: In unserem Anwendungsbeispiel gibt es einen zusätzlichen Sensor, welcher den Wasserdruck im Warmwasserkreislauf misst. Ist dieser Wasserdruck zu gering, soll ein entsprechender Statustext ausgegeben werden.
Mit einem Wert von „1“ im Feld [T_APPDEF_DashboardKpiValues].[IsStatusKPI] (Datentyp INTEGER) wird die Kennzahl als Status-KPI gekennzeichnet. Zusätzlich wird im Feld [T_APPDEF_DashboardKpiValues].[StatusStructureTable] (Datentyp VARCHAR (50)) eine Tabelle oder View zur Übersetzung der originären Werte in Statustexte angegeben.
Diese Übersetzungstabelle oder View muss dabei die folgende Struktur aufweisen:
- [ID] INTEGER PRIMARY KEY NOT NULL → dient zur Verknüpfung mit dem originären Wert der Kennzahl
- [SortID] INTEGER → dient zur Sortierung innerhalb einer Strukturebene
- [Name] VARCHAR (255) -> anzuzeigender Statustext
Bezogen auf das Anwendungsbeispiel entspricht ein Wert von „1“ einem ausreichenden Wasserdruck und ein Wert von „-1“ einem zu niedrigen Wasserdruck. Dementsprechend werden diese Zuordnungen in eine Übersetzungstabelle [T_Status_Wasserdruck] eingetragen, die zusätzlich in der db-Exportvorlage enthalten sein muss (Abbildung 6). Auf diese Tabelle wird wiederum im Feld [T_APPDEF_DashboardKpiValues].[StatusStructureTable] verwiesen.
In der DeltaApp werden nun anstelle der Werte „1“ und „-1“ die entsprechenden Statustexte ausgewiesen (Abbildung 7).
Fazit
Die gezeigten Modifikationen lassen sich selbstverständlich auf weitere Anwendungsfälle übertragen – sowohl aus dem IoT-Bereich als auch aus anderen Zusammenhängen, in denen Kennzahlen und ihre Darstellungen abweichend von der Standard-Logik abgebildet werden sollen. Damit verschaffen sie Anwendern mehr Flexibilität bei der Gestaltung von Dashboards in der DeltaApp.