--- title: 'Lange Sitzungen' description: 'Flottenknoten, deren Kommunikationssitzungen relativ zu ihrer eigenen Norm ungewöhnlich lange dauern, mit knotenindividuellen IQR-Schwellenwerten, einem Schweregrad-Score und einer vorfallbasierten Ursachenanalyse.' section: AI Analytics weight: 7 related: - ai-analytics/fleet-reports/events-explorer --- import Alert from '@/components/docs/Alert.astro'; import Image from '@/components/docs/Image.astro'; Der Bericht **Lange Sitzungen** analysiert die Kommunikationssitzungen der Telemetrie über die gesamte Flotte der Zählknoten hinweg und ermittelt Geräte, Standorte, Tage und Mengenumwerter-Typen, bei denen die Kommunikation instabil arbeitet oder die Datenübertragung übermäßig viel Zeit beansprucht. Berichtskopf mit sieben KPIs Der Berichtskopf trägt sieben KPIs: Unternehmen, Flottenabdeckung, Datenbereitschaft, Anzahl der Knoten mit Anomalien, Anzahl der anomalen Sitzungen, maximale Sitzungsdauer, Gesamtzahl der stündlichen Vorfälle und den Analysezeitraum. Die Leitkennzahl ist die Anzahl der Knoten mit Anomalien im Verhältnis zur Gesamtzahl der Flotte; Vorfälle sind stündliche Cluster, in denen fünf oder mehr Knoten gleichzeitig lange Sitzungen aufweisen. Der Bericht beantwortet praktische betriebliche Fragen: - welche Knoten Kommunikationssitzungen haben, die zu lang sind; - welche Sitzungen für genau diesen Knoten als anomal gelten; - wo das Problem lokal ist: Antenne, SIM-Karte, Stromversorgung, Modem, Installationsort; - wo das Problem wie ein Vorfall an einer Basisstation oder beim Mobilfunknetzbetreiber aussieht; - ob es flottenweite stündliche Massenvorfälle gibt; - welche Tage am problematischsten waren; - welche Mengenumwerter-Typen häufiger in lange Sitzungen geraten; - wie viel Energie ungefähr für Neuübertragungen oder verlängerte Übertragungen aufgewendet wurde; - welche Knoten einen Vor-Ort-Einsatz mit externer Antenne, Repeater oder SIM-Prüfung erfordern; - wo der Mobilfunknetzbetreiber oder die Abdeckungsqualität an einem konkreten Standort überprüft werden sollte. Der Bericht bewertet nicht die Richtigkeit der kommerziellen Gasmessung und ist kein forensischer Bericht über die Umgehung der Messung. Er analysiert ausschließlich Kommunikationssitzungen: Dauer, Häufigkeit von Anomalien, Ausmaß von Vorfällen, Signalqualität und die wahrscheinliche Ursache langer Sitzungen. ## Wo der Bericht einzuordnen ist Der Bericht gehört zur operativen Diagnostik der Telemetrie. Er darf zwei verschiedene Situationen nicht vermischen: 1. **Überhaupt keine Kommunikation.** Der Knoten verbindet sich nicht, es liegen keine Daten vor. 2. **Kommunikation besteht, aber die Sitzungen sind zu lang.** Der Knoten überträgt Daten, tut dies jedoch langsam, instabil oder mit Wiederholungen. Dieser Bericht analysiert die **zweite** Situation. Wo es überhaupt keine Kommunikation, kein Archiv oder keine Daten gibt, verwenden Sie den Bericht „Top-Problemknoten“; wo Sie prüfen müssen, ob die Daten eines einzelnen Knotens für die Messung geeignet sind, verwenden Sie „Verbrauchsanalytik“. ## Für wen der Bericht bestimmt ist | Rolle | Was der Bericht ihr liefert | | ----------------------- | --------------------------------------------------------------------------------- | | Betriebsleiter | Gesamtbild der Flotte, Anzahl der Knoten mit Anomalien, Massenvorfälle | | Kommunikationsingenieur | Liste der Knoten mit schlechtem RSSI, langen Sitzungen und lokalen Problemen | | Disponent | priorisierte Liste der Tickets und der Problemtage | | Außendienstteam | Top-Knoten für Antennen-, SIM-, Strom- und Installationsort-Prüfungen | | Integrationsingenieur | Diagnostik der Datenbereitschaft, API-Abdeckung und Fälle fehlender Sitzungsdaten | | Einkaufsfachkraft | vergleichende Aufschlüsselung nach Mengenumwerter-Typ | | Flottenanalyst | Ursachenhypothesen: Basisstation, Netzbetreiber, Firmware, lokaler Knoten | ## Was der Bericht nicht leistet Der Bericht darf nicht: - ohne Vor-Ort-Einsatz beweisen, dass ein bestimmtes Modem defekt ist; - eine lange Sitzung als direkten Beweis für ein schlechtes Gerät werten; - automatisch dem Server oder dem Mobilfunknetzbetreiber die Schuld geben; - „keine Daten“ mit „keine Anomalien“ vermischen; - die Sitzungsdauer aller Knoten an einem einzigen gemeinsamen Schwellenwert messen; - einen kurzen Zeitraum mit wenigen Sitzungen als statistisch zuverlässig behandeln; - Schlüsse über die Qualität eines Gerätemodells ziehen, ohne die Anzahl der Geräte in der Stichprobe zu berücksichtigen; - eine funktechnische Untersuchung des Installationsorts ersetzen; - die Schätzung des Batterieverlusts als präzise Messung behandeln; - den KI-Kommentar als Quelle der Diagnostik verwenden. ## Schlüsselbegriffe | Begriff | Bedeutung | | --------------------- | ------------------------------------------------------------------------------------------ | | Kommunikationssitzung | eine Episode der Verbindung des Geräts mit dem Datenübertragungssystem | | Sitzungsdauer | Zeit vom Sitzungsbeginn bis zum Abschluss | | Normale Sitzung | eine Sitzung, deren Dauer innerhalb der individuellen Norm des Knotens liegt | | Lange Sitzung | eine Sitzung, deren Dauer den individuellen IQR-Schwellenwert des Knotens überschreitet | | `IQR` | Interquartilsabstand: `Q3 − Q1` | | `Q1` | erstes Quartil der Sitzungsdauern | | `Q3` | drittes Quartil der Sitzungsdauern | | `UpperFence` | obere Grenze der Norm: `Q3 + 1.5 × IQR` | | `RSSI` | Funksignalpegel, dBm | | `CSQ` | GSM-Signalqualitätsindex, kann in dBm umgerechnet werden | | `Btm` | Batteriespannung oder Indikator der Geräte-Stromversorgung | | `Long share` | Anteil der langen Sitzungen an allen Sitzungen eines Knotens | | `Severity score` | abschließende Bewertung des Problemgrads eines Knotens nach langen Sitzungen | | Vorfall | stündliches Cluster, in dem lange Sitzungen gleichzeitig an mehreren Knoten auftraten | | `RCA` | Analyse der wahrscheinlichen Ursache: Basisstation, Netz, Server, Firmware, lokaler Knoten | | `Battery loss` | ungefähre Schätzung der für die überschüssige Übertragungsdauer aufgewendeten Energie | ## Allgemeine Berichtslogik Der Bericht ist als flottenweite Analyse der Kommunikationssitzungen aufgebaut. ```text Liste der Flottenknoten → Kommunikationssitzungen abrufen → Datenbereitschaft prüfen → individuelle Sitzungsnorm für jeden Knoten → Suche nach langen Sitzungen über IQR → Score für jeden Knoten berechnen → lange Sitzungen zu stündlichen Vorfällen gruppieren → wahrscheinliche RCA-Ursache bestimmen → Hypothesen auf die Knoten verteilen → Top-Problemknoten → Aufschlüsselung nach Mengenumwerter-Typ → Aufschlüsselung nach Tagen und Monaten → Empfehlungen für den Betrieb ``` Das Hauptprinzip: ```text eine lange Sitzung wird relativ zur Norm eines konkreten Knotens definiert, nicht relativ zu einem gemeinsamen festen Schwellenwert über die gesamte Flotte. ``` Das ist wichtig, weil verschiedene Geräte, Regionen, Mobilfunknetzbetreiber und Abfragemodi unterschiedliche normale Sitzungsdauern haben können. ## Laufparameter | Parameter | Bedeutung | | ------------------------------------------ | ------------------------------------------------------------------------------------------- | | Von-Datum / Bis-Datum | Grenzen des Analysefensters | | Analysefenster, Tage | Ausweichfenster, das bei leeren Datumsangaben verwendet wird (Standard 30) | | Knoten pro Mengenumwerter-Typ | Stichprobengröße pro Typ; `0` bedeutet alle Flottenknoten | | Mindestanzahl Sitzungen pro Knoten für IQR | Mindestanzahl an Sitzungen, die ein Knoten benötigt, um sich zu qualifizieren (Standard 30) | | Anzahl der Problemknoten im Bericht | Größe der Top-N-Tabelle (Standard 50) | | LLM-Analyse | optionale KI-Erzählung zur Erläuterung der Ergebnisse | | Versorgungsunternehmen | beschränkt die Analyse auf die Flotte eines einzelnen Versorgers | ## Eingangsdaten ### Hauptdaten | Daten | Wofür sie benötigt werden | | ----------------------- | ----------------------------------------------------------- | | Liste der Knoten | die zu analysierende Flotte bestimmen | | Mengenumwerter-Typ | die Aufschlüsselung nach Modell aufbauen | | `Equipment ID` | Sitzungen eines konkreten Geräts abrufen | | Kommunikationssitzungen | Kern des Berichts | | Sitzungsstartzeit | Gruppierung nach Tagen, Monaten und Stunden | | Sitzungsdauer | der wichtigste analysierte Kennwert | | `RSSI` / `CSQ` | Schätzung der Funksignalqualität | | `Btm` / Batterie | Schätzung des Einflusses der Stromversorgung | | Organisation / Standort | Zuordnung des Vorfalls: lokaler Kunde, Basisstation, Flotte | ### Erforderlicher Mindestumfang Für eine korrekte Analyse eines Knotens werden benötigt: - Gerätekennung; - mindestens die Mindestanzahl an Sitzungen; - Dauer jeder Sitzung; - Zeitstempel jeder Sitzung. Fehlt die Sitzungsdauer, nimmt diese Sitzung nicht an der IQR-Analyse teil. ## Datenbereitschaft: das Daten-Gate Diagnostik der Datenbereitschaft Bevor Anomalien berechnet werden, prüft der Bericht, ob eine Analyse überhaupt durchgeführt werden kann. Der Block zur Datenbereitschaft zeigt die Flottengröße, die Größe nach dem Unternehmensfilter, wie viele Knoten Sitzungsdaten zurückgegeben haben und wie viele davon das Sitzungsminimum für IQR bestanden haben. Dies ist eine **kritisch wichtige** Diagnostik – ohne sie wird „keine Anomalien“ leicht mit „keine Daten für die Analyse“ verwechselt. ### Wichtigste Bereitschaftsindikatoren | Indikator | Formel / Wert | | ----------------------------------------------- | -------------------------------- | | Knoten in der Flotte | `N_park` | | Knoten in der Stichprobe | `N_sampled` | | Knoten mit Sitzungsdaten | `N_with_data` | | Knoten, die das Sitzungsminimum bestanden haben | `N_qualified` | | Sitzungen gesamt | `N_sessions` | | API-Aufrufe | `N_calls` | | API-Fehler | `N_errors` | | API-Fehlerrate | `N_errors / N_calls × 100%` | | Datenabdeckung | `N_with_data / N_sampled × 100%` | | IQR-Stichprobenabdeckung | `N_qualified / N_sampled × 100%` | ### API-Fehlerrate $$ APIErrorRate = \frac{N_{errors}}{N_{calls}} \times 100\% $$ ### Datenabdeckung $$ Coverage_{with\_data} = \frac{N_{with\_data}}{N_{sampled}} \times 100\% $$ ### Abdeckung durch IQR-taugliche Knoten $$ Coverage_{qualified} = \frac{N_{qualified}}{N_{sampled}} \times 100\% $$ ### Bereitschaftsstatus | Status | Bedingung | Was er bedeutet | | -------------- | ---------------------------------------------- | --------------------------------------------- | | `OK` | ausreichende Stichprobe für IQR vorhanden | der Bericht kann als belastbar gelesen werden | | `DEGRADED` | Stichprobe ist klein, aber Analyse ist möglich | Schlussfolgerungen sind vorsichtig | | `INCONCLUSIVE` | viele Fehler oder kritisch niedrige Abdeckung | Anomalie-Schlüsse sind unzuverlässig | | `NO_DATA` | keine Sitzungsdaten | Analyse ist unmöglich | | `NO_FLEET` | keine Knoten nach Filterung | nichts zu analysieren | ### Kritische Bedingungen Die Analyse gilt als unmöglich, wenn: $$ APIErrorRate \ge 50\% $$ oder: $$ Coverage_{with\_data} < 5\% $$ oder: $$ N_{qualified} = 0 $$ „Keine Anomalien“ und „keine Daten für die Analyse“ sind unterschiedliche Zustände. Fehlen Sitzungsdaten, darf der Bericht nicht aussagen, dass keine Anomalien gefunden wurden. ## Mindestanzahl Sitzungen pro Knoten Für eine zuverlässige IQR-Analyse muss jeder Knoten eine ausreichende Anzahl an Sitzungen aufweisen. ### Mindestschwelle Standardmäßig: $$ N_{sessions,station} \ge 30 $$ Hat ein Knoten weniger Sitzungen, gilt die individuelle Norm als statistisch unzuverlässig und der Knoten besteht den IQR-Filter nicht. ### Warum ein Minimum nötig ist IQR nutzt Quartilschätzungen. Bei einer geringen Anzahl an Beobachtungen wird das Quartil instabil: - eine zufällige lange Sitzung kann den Schwellenwert überhöhen; - ein kurzer Kommunikationszeitraum kann den Schwellenwert unterschätzen; - es wird unmöglich, die Norm des Knotens vom Zufall zu unterscheiden. ## Individuelle Norm der Sitzungsdauer ### Warum die Norm individuell ist Man kann nicht einen einzigen gemeinsamen Schwellenwert für die gesamte Flotte verwenden, z. B. „alle Sitzungen länger als 10 Minuten sind schlecht“. Verschiedene Knoten haben unterschiedliche Kommunikationsbedingungen: - unterschiedliche Mengenumwerter-Typen; - unterschiedliche Mobilfunknetzbetreiber; - unterschiedliche RSSI; - unterschiedliche Archivvolumina; - unterschiedliche Abfragepläne; - unterschiedliche Installationsorte; - unterschiedliche Antennen. Daher wird für jeden Knoten seine eigene statistische Norm berechnet. ### Auswahl gültiger Dauern Für jeden Knoten werden nur positive Dauern herangezogen: $$ D = \{d_i \mid d_i > 0\} $$ dabei gilt: - `d_i` — Dauer der i-ten Sitzung in Sekunden. ### Quartile Die Dauern werden aufsteigend sortiert. $$ D_{sorted} = sort(D) $$ Erstes Quartil: $$ Q1 = percentile(D, 25\%) $$ Median: $$ Q2 = median(D) $$ Drittes Quartil: $$ Q3 = percentile(D, 75\%) $$ ### Interquartilsabstand $$ IQR = Q3 - Q1 $$ ### Tukey-Zaun: obere Grenze der Norm Für jeden Knoten wird eine individuelle obere Grenze der Norm berechnet: $$ UpperFence = Q3 + 1.5 \times IQR $$ Dies ist die klassische Tukey-Zaun-Regel zur Erkennung von Ausreißern. ### Lange Sitzung Eine Sitzung gilt als anomal lang, wenn: $$ d_i > UpperFence $$ dabei gilt: - `d_i` — Sitzungsdauer; - `UpperFence` — der individuelle Schwellenwert dieses Knotens. Hat ein Knoten üblicherweise kurze Sitzungen, ist sein Schwellenwert niedrig. Hat ein Knoten üblicherweise längere Sitzungen, ist sein Schwellenwert höher. Der Bericht erkennt eine Anomalie **relativ zur eigenen Norm des Knotens**. ## Grundlegende Knotenkennwerte Für jeden Knoten werden die folgenden Kennwerte berechnet. ### Gesamtzahl der Sitzungen $$ N_{total} = count(D) $$ ### Anzahl der langen Sitzungen $$ N_{long} = count(d_i > UpperFence) $$ ### Anteil der langen Sitzungen $$ Pct_{long} = \frac{N_{long}}{N_{total}} \times 100\% $$ ### Durchschnittliche Dauer aller Sitzungen $$ AvgDuration = \frac{\sum d_i}{N_{total}} $$ ### Durchschnittliche Dauer der langen Sitzungen $$ AvgLongDuration = \frac{\sum_{d_i > UpperFence} d_i}{N_{long}} $$ ### Maximale Dauer $$ MaxLongDuration = max(d_i \mid d_i > UpperFence) $$ ### Durchschnittlicher RSSI $$ RSSI_{avg} = \frac{\sum RSSI_i}{N_{RSSI}} $$ dabei ist `N_RSSI` die Anzahl der Sitzungen mit einem verfügbaren RSSI-Wert. ## Problem-Score des Knotens ### Bedeutung des Scores Der Score zeigt, wie problematisch ein Knoten hinsichtlich langer Sitzungen ist. Er berücksichtigt drei Dimensionen: 1. **Anteil der langen Sitzungen**; 2. **wie stark lange Sitzungen die Norm überschreiten**; 3. **absolute Anzahl der langen Sitzungen**. Dieser Ansatz vermeidet eine Überbewertung eines einmaligen Ausreißers und vermeidet eine Unterbewertung eines Knotens mit einer großen Anzahl mäßig langer Sitzungen. ### Komponente A — Anteil der langen Sitzungen $$ A = min(100,\;4 \times Pct_{long}) $$ Interpretation: | Anteil langer Sitzungen | A | | ----------------------: | --: | | 5% | 20 | | 10% | 40 | | 25% | 100 | | >25% | 100 | ### Komponente B — relative Dauer $$ B = min \left( 100,\; 8 \times \frac{AvgLongDuration}{max(1, MedianDuration)} \right) $$ dabei ist `MedianDuration` die mediane Sitzungsdauer des Knotens. Interpretation: | AvgLong / Median | B | | ---------------: | --: | | 2× | 16 | | 5× | 40 | | 10× | 80 | | 12.5× | 100 | ### Komponente C — Anzahl der langen Sitzungen $$ C = min(100,\;N_{long}) $$ Das heißt, 100 oder mehr lange Sitzungen liefern den maximalen Beitrag dieser Komponente. ### Endgültiger Score $$ Score = 0.5 \times A + 0.3 \times B + 0.2 \times C $$ dabei gilt: - `A` — Anteil der langen Sitzungen; - `B` — relative Dauer der langen Sitzungen; - `C` — absolute Anzahl der langen Sitzungen. Der endgültige Score ist auf den Bereich beschränkt: $$ 0 \le Score \le 100 $$ ### Interpretation des Scores | Score | Stufe | | ----: | ------------------------------- | | ≥ 80 | kritischer Kommunikationsknoten | | 60–80 | hohe Priorität | | 40–60 | mittlere Priorität | | 20–40 | Beobachtung / geplante Prüfung | | < 20 | schwaches Signal | Der Score beweist keine Ursache. Ein hoher Score besagt, dass der Knoten häufig und/oder stark seine eigene Norm der Sitzungsdauer überschreitet. **Die Ursache wird separat über RCA bestimmt.** ## Schätzung des Batterieverlusts bei langen Sitzungen ### Bedeutung Eine lange Sitzung erhöht die Übertragungszeit und kann zusätzlich die Batterie belasten. Der Bericht gibt eine **ungefähre** Schätzung des überschüssigen Energieaufwands. Dies ist keine präzise Batteriemessung, sondern eine betriebliche Schätzung. ### Überschüssige Übertragungszeit Für jede lange Sitzung wird der Überschuss gegenüber der medianen Norm des Knotens berechnet: $$ ExtraTime_i = max(0,\;d_i - MedianDuration) $$ Gesamter Überschuss an Zeit: $$ ExtraTime_{total} = \sum_{i \in LongSessions} ExtraTime_i $$ ### Übertragungsstrom Für die ungefähre Schätzung wird ein Basis-Übertragungsstrom verwendet: $$ I_{TX} = 340 \; mA $$ ### Batterieverlust $$ BatteryLoss_{mAh} = \frac{I_{TX} \times ExtraTime_{total}}{3600} $$ dabei gilt: - `ExtraTime_total` — in Sekunden; - `I_TX` — Strom in Milliampere; - Ergebnis — in mAh. Für die Anzeige in Ah: $$ BatteryLoss_{Ah} = \frac{BatteryLoss_{mAh}}{1000} $$ ### Einschränkung Diese Schätzung berücksichtigt nicht: - das tatsächliche Stromprofil des konkreten Modells; - den Schlafmodus; - Wiederholungen auf Modemebene; - die Sendeleistung; - die Temperatur; - das Alter der Batterie; - die Batteriekapazität; - die Netzqualität im Moment der Übertragung. Sie sollte daher als **Größenordnungsschätzung** gelesen werden, nicht als Labormessung. ## RSSI und CSQ ### RSSI `RSSI` zeigt den Funksignalpegel in dBm. Je näher der Wert an null liegt, desto stärker ist das Signal. Ungefähre Interpretation: | RSSI | Bewertung | | ----------: | ------------ | | ≥ −65 dBm | gutes Signal | | −65…−75 dBm | akzeptabel | | −75…−85 dBm | schwach | | < −85 dBm | sehr schwach | ### CSQ Manche Geräte übertragen nicht RSSI in dBm, sondern `CSQ` — den GSM-Signalqualitätsindex. Sieht der Wert nach CSQ aus, kann er umgerechnet werden: $$ RSSI_{dBm} = -113 + 2 \times CSQ $$ Beispiel: $$ CSQ = 29 $$ $$ RSSI = -113 + 2 \times 29 = -55 \; dBm $$ ### Lokal schwaches Signal Wenn: $$ RSSI_{avg} < -85 \; dBm $$ und die Anomalien des Knotens nicht mit flottenweiten Massenvorfällen zusammenfallen, kann die Ursache klassifiziert werden als: ```text schwaches Signal am Installationsort ``` ## Gruppierung langer Sitzungen zu Vorfällen Register der Vorfälle Anomalien werden zu stündlichen Fenstern gruppiert. Wenn mehrere Knoten in derselben Stunde lange Sitzungen erhalten haben, ist dies **kein lokales Knotenproblem**, sondern ein Netz-, Server- oder Betreibervorfall. Die Hypothese wird automatisch anhand der Breite der Abdeckung bestimmt — der Anzahl der Knoten, Modelle und Kunden im Fenster. ### Warum eine Gruppierung nötig ist Sind lange Sitzungen bei vielen Knoten in derselben Stunde aufgetreten, handelt es sich höchstwahrscheinlich nicht um ein lokales Problem eines einzelnen Geräts. Es könnte sein: - ein Problem an einer Basisstation; - eine lokale Überlastung des Netzbetreibers; - ein flächendeckender Netzvorfall; - eine geplante Serveroperation; - eine Besonderheit der Firmware eines bestimmten Modells. ### Stündlicher Korb Jede lange Sitzung wird in einen stündlichen Korb einsortiert: $$ Bucket(t) = floor\left( \frac{t}{1h} \right) \times 1h $$ Das heißt, alle Ereignisse innerhalb einer Stunde fallen in einen Korb. ### Vorfall Ein stündlicher Korb gilt als Vorfall, wenn mindestens: $$ N_{stations,bucket} \ge 5 $$ Knoten betroffen sind. ### Vorfallkennwerte Für jeden Vorfall werden berechnet: | Indikator | Formel | | ----------------------------- | -------------------------------- | | Anzahl der Knoten | `count(unique station_id)` | | Anzahl der Modelle | `count(unique equipment_type)` | | Anzahl der Kunden / Standorte | `count(unique customer_id)` | | Anzahl der Sitzungen | `count(long sessions in bucket)` | | durchschnittlicher RSSI | `average(RSSI)` | | Top-Modelle | `top equipment types by count` | ## RCA: Zuordnung der Vorfallursache Zusammenfassung der Ursachenuntersuchung Die Flottenzusammenfassung benennt den Hauptverursacher — Funkmast, Server, Netz, Firmware oder lokaler Knoten — liefert eine Schuldzuordnung über die Knoten mit Anomalien hinweg und stellt einen Maßnahmenplan auf. Eine optionale KI-Erzählung am Ende erläutert die Zahlen in einfacher Sprache, verändert sie aber nicht. RCA ist die Klassifizierung der wahrscheinlichen Ursache langer Sitzungen. ### Mögliche Hypothesen | Hypothese | Bedeutung | | ----------------- | ------------------------------------------------------------- | | `Server driver` | Ausfall des Massensammlungstreibers | | `Server routine` | reguläre Serveroperation oder Wartung | | `Network outage` | Ausfall des Mobilfunknetzbetreibers | | `Cell tower` | Problem mit einer bestimmten Basisstation oder einem Standort | | `Firmware` | Problem mit Gerätemodell / Firmware | | `Local signal` | schwaches Signal am Installationsort | | `Battery low` | niedrige Stromversorgung / Batteriedegradation | | `Isolated device` | lokale Störung eines bestimmten Knotens | | `Mixed causes` | gemischte Ursachen | ### Breiter Servervorfall Ein Vorfall wird als Servervorfall klassifiziert, wenn viele Knoten, viele Modelle und viele Kunden gleichzeitig betroffen sind. Bedingt: $$ N_{stations} \ge ServerWideStations $$ $$ N_{models} \ge ServerWideModels $$ $$ N_{customers} \ge ServerWideCustomers $$ Im Bericht bedeutet dies: ```text breiter Flottenvorfall, nicht vergleichbar mit einem lokalen Einzelknotenproblem. ``` ### Ausfall des Betreibernetzes Sind mehrere Modelle und mehrere Kunden betroffen, das Ausmaß erreicht jedoch keinen Serverausfall: $$ N_{models} \ge 3 $$ und: $$ N_{customers} \ge 3 $$ dann lautet die Hypothese: ```text Mobilfunkausfall / Betreibervorfall ``` ### Problem an der Basisstation Sind viele Knoten betroffen, gehören jedoch zu einem oder zwei Standorten / Kunden: $$ N_{customers} \le 2 $$ und: $$ N_{stations} \ge CellMinStations $$ dann lautet die Hypothese: ```text Problem an der Basisstation oder lokales Abdeckungsproblem ``` ### Firmware- oder Modellproblem Ist ein Modell betroffen, jedoch über verschiedene Kunden hinweg: $$ N_{models} = 1 $$ und: $$ N_{customers} \ge 3 $$ dann lautet die Hypothese: ```text Firmware- / Gerätemodell-Besonderheit ``` ### Gemischte Ursachen Ergeben die Bedingungen keine eindeutige Klassifizierung, erhält der Vorfall den Status: ```text gemischte Ursachen ``` ## Wiederkehrende Server-Routine Manchmal treten Massenservervorfälle zur selben Tagesstunde auf. ### Bedingung Gibt es mindestens drei breite Servervorfälle zur selben Tagesstunde: $$ N_{server\_incidents,same\_hour} \ge 3 $$ können sie klassifiziert werden als: ```text Server-Routine ``` ### Bedeutung Dies kann auf einen regelmäßigen nächtlichen Job, eine Archivwartung, einen Stapelprozess oder eine Massenoperation hindeuten, die die Sitzungsdauer beeinflusst. ## Ursachenzuordnung pro Knoten Nach der Suche nach Flottenvorfällen bestimmt der Bericht, was an jedem Knoten dominiert: externe Vorfälle oder ein lokales Problem. ### Anteil der Anomalien eines Knotens, die in Flottenvorfälle fallen $$ InIncidentPct = \frac{N_{long,in\_incidents}}{N_{long}} \times 100\% $$ ### Wenn die meisten Anomalien mit Flottenvorfällen zusammenfielen Wenn: $$ InIncidentPct \ge 70\% $$ dann wird die dominierende Ursache des Knotens aus dem Flottenvorfall übernommen: ```text network_outage / cell_tower / firmware / server ``` Das bedeutet: ```text das Gerät ist wahrscheinlich nicht der Hauptverursacher; es hat zusammen mit anderen gelitten. ``` ### Prüfung auf niedrige Batterie Werden die Anomalien nicht durch Flottenvorfälle erklärt, wird die Stromversorgung geprüft. Sei: $$ Btm_{first} $$ der erste verfügbare Batteriewert in den langen Sitzungen, und: $$ Btm_{last} $$ der letzte verfügbare Wert. Der Abfall: $$ BtmDrop = Btm_{first} - Btm_{last} $$ Die Hypothese `battery_low` ist möglich, wenn: $$ Btm_{first} < 3500 \; mV $$ und: $$ BtmDrop > 200 \; mV $$ ### Prüfung auf lokal schwaches Signal Wenn: $$ RSSI_{avg} < -85 \; dBm $$ dann lautet die Hypothese: ```text schwaches Signal am Installationsort ``` ### Isolierte Knotenstörung Wenn: - die Anomalien nicht mit Flottenvorfällen zusammenfallen; - die Batterie das Bild nicht erklärt; - der RSSI nicht kritisch schwach ist; dann wird die Ursache klassifiziert als: ```text lokale Störung des Knotens ``` ## Verteilung der Hypothesen über die Flotte Verteilung der Hypothesen Für jeden Knoten wird die dominierende Ursache ausgewählt. Wenn die meisten Knoten unter Flottenvorfällen gelitten haben, ist der Knoten selbst nicht schuld; nur eine Minderheit hat ein isoliertes lokales Problem. Das ändert den Maßnahmenplan: Der Hauptaufwand fließt in Basisstationen und den Netzbetreiber, nicht in einen Massen-Vor-Ort-Einsatz zu jedem Knoten mit Anomalien. Der Bericht zeigt, wie viele Knoten jeder dominierenden Ursache zugeordnet werden. ### Formel für den Hypothesenanteil $$ Share_{hypothesis} = \frac{N_{stations,hypothesis}}{N_{stations,with\_anomalies}} \times 100\% $$ ### Ursachengruppen Für die Management-Zusammenfassung können die Hypothesen gruppiert werden: | Gruppe | Umfasst | | --------------------- | ----------------------------------------------------------------- | | Netz / Server | `server_driver`, `server_routine`, `network_outage`, `cell_tower` | | lokale Geräteprobleme | `isolated_device`, `local_signal`, `battery_low` | | Modell / Firmware | `firmware` | | gemischt | `mixed` | ### Interpretation | Dominiert | Was zu tun ist | | ----------------- | ------------------------------------------------------------------------- | | `Cell tower` | Abdeckung, Netzbetreiber, externe Antennen bei betroffenen Kunden prüfen | | `Local signal` | Vor-Ort-Einsatz zum konkreten Knoten, Antenne, Repeater, Installationsort | | `Isolated device` | Diagnostik von Modem, SIM, Strom, Firmware | | `Firmware` | Softwareversion prüfen und den Lieferanten kontaktieren | | `Server routine` | reguläre Plattformprozesse prüfen | | `Network outage` | den Mobilfunknetzbetreiber nach Zeit und Zone abfragen | ## Top-Problemknoten Top-Problemknoten Die Tabelle der Top-Problemknoten ordnet die Knoten nach einem zusammengesetzten Score (0–100), der sich aus dem Anteil der langen Sitzungen, ihrer durchschnittlichen Dauer und ihrer Anzahl ergibt. Ein Klick auf eine Zeile klappt die längsten Sitzungen des Knotens mit RSSI- und `Btm`-Werten auf — wird zur Planung eines Vor-Ort-Einsatzes verwendet. ### Zweck Die Tabelle zeigt, wohin man gehen oder was man zuerst prüfen sollte. ### Tabellenspalten | Spalte | Bedeutung | | ------------------- | -------------------------------------------- | | Knoten | Name und ID des Knotens | | Mengenumwerter | Gerätetyp | | Sitzungen | Gesamtzahl der gültigen Sitzungen | | Lang | Anzahl der anomal langen Sitzungen | | Anteil | Prozentsatz der langen Sitzungen | | Durchschnitt lang | durchschnittliche Dauer der langen Sitzungen | | Maximale Sitzung | schlechteste gefundene Sitzung | | `RSSI` Durchschnitt | Funksignalqualität | | Batterieverlust | geschätzte überschüssige Energie | | Score | zusammengesetzter Problem-Score | ### Wie man die Top-Liste liest Ein hoher Score kann aus verschiedenen Gründen entstehen: - ein großer Anteil langer Sitzungen; - sehr lange einzelne Sitzungen; - eine große absolute Anzahl langer Sitzungen; - eine Kombination dieser Faktoren. Für die Planung eines Vor-Ort-Einsatzes lesen Sie nicht nur den Score, sondern auch: - `RSSI`; - die RCA-Hypothese; - den Batterieverlust; - die maximale Sitzung; - ob der Knoten in Flottenvorfälle fällt; - den Mengenumwerter-Typ. ## Top-Problemtage Top-Problemtage Alle anomalen Sitzungen werden nach Kalendertag gruppiert. Der Tag mit der größten Anzahl an Anomalien ist höchstwahrscheinlich der Tag, an dem ein Flottenvorfall auftrat. Jeder Tag klappt zur Liste der Knoten mit ihren Anomalien, der maximalen Sitzung und Verknüpfungen auf. Dies ist nützlich, um Massenereignisse zu untersuchen und die Wiederholung zu prüfen. ### Zweck Die Aufschlüsselung nach Tagen zeigt die Tage, an denen lange Sitzungen massenhaft über die Flotte hinweg auftraten. ### Tageskennwerte | Indikator | Bedeutung | | -------------------- | -------------------------------------------- | | Datum | Kalendertag | | Lange Sitzungen | Anzahl der langen Sitzungen des Tages | | Knoten | wie viele Knoten betroffen sind | | Durchschnitt lang | durchschnittliche Dauer der langen Sitzungen | | Maximale Sitzung | schlimmster Fall des Tages | | Schlechtester Knoten | Knoten mit der maximalen Sitzung | ### Interpretation | Bild | Mögliche Ursache | | ---------------------------------- | ----------------------------------------------------------------- | | viele Knoten an einem einzigen Tag | Netz- oder Flottenvorfall | | ein Knoten an jedem Tag | lokales Problem | | ein Ausschlag am Wochenende | Betreibernetz / Wartungsarbeiten | | Ausschläge zur selben Uhrzeit | regelmäßige Aufgabe oder Zeitplan | | monatliches Wachstum | Netzdegradation, saisonale Überlastung, Änderung des Abfragemodus | ## Aufschlüsselung nach Mengenumwerter-Typ Abdeckung nach Mengenumwerter-Typ Der Abdeckungsblock zeigt, was für jeden Mengenumwerter-Typ aus der Flotte geprüft wurde: wie viele Knoten in der Stichprobe sind, wie viele Daten zurückgegeben haben, wie viele IQR bestanden haben und wie viele Anomalien aufweisen. Zeigt ein Typ „Norm“, kamen Daten an, es wurden jedoch keine Anomalien gefunden. „Keine Daten“ bedeutet, dass der Typ die Sitzungsdauer in der API nicht zurückgibt — für manche Modelle ist das normal. Detaillierte Aufschlüsselung nach Mengenumwerter-Typ Klappen Sie einen Typ auf, um alle seine Knoten mit Anomalien zu sehen; klappen Sie einen Knoten auf, um seine konkreten langen Sitzungen mit Zeit, Dauer, RSSI und `Btm` zu sehen. Die Hervorhebungsfarbe der Sitzung hängt davon ab, um wie viel länger die Sitzung als die Norm des Knotens ist. ### Zweck Die Aufschlüsselung nach Mengenumwerter-Typ zeigt, welche Modelle häufiger in anomal lange Sitzungen geraten. ### Kennwerte nach Typ | Indikator | Bedeutung | | ------------- | ----------------------------------------------------- | | In Stichprobe | wie viele Knoten dieses Typs in der Flotte sind | | Mit Daten | wie viele Knoten Sitzungsdaten zurückgegeben haben | | IQR bestanden | wie viele Knoten die Mindestanzahl an Sitzungen haben | | Anomalien | Anzahl der langen Sitzungen | | Zustand | Norm / Anomalien / keine Daten | ### Wichtige Einschränkung **Man kann Mengenumwerter-Typen nicht allein anhand der Anzahl der Anomalien direkt vergleichen.** Zu berücksichtigen sind: - wie viele Geräte dieses Typs in der Flotte sind; - wie viele davon Daten zurückgegeben haben; - wie viele das Sitzungsminimum bestanden haben; - wo sie installiert sind; - in welchen Netzen sie betrieben werden; - ob sie denselben Abfrageplan haben; - ob sie bei einem einzigen Kunden konzentriert sind. ### Normalisierter Anomalieanteil nach Typ Für einen korrekten Vergleich können Sie verwenden: $$ TypeAnomalyRate = \frac{N_{long,type}}{N_{sessions,type}} \times 100\% $$ oder: $$ TypeAffectedRate = \frac{N_{stations\_anomalous,type}}{N_{stations\_qualified,type}} \times 100\% $$ ## Aufschlüsselung nach Zeit: Dynamik und Monate Dynamik der langen Sitzungen nach Tag Das Diagramm der täglichen Dynamik zeigt, wie viele anomale Sitzungen an jedem Tag des Fensters über die Flotte hinweg auftraten. „Aufflackern“ wird sichtbar — Tage mit schlechter Kommunikation über das gesamte Netz hinweg. Eine Spitze, die mit dem Register der Vorfälle zusammenfällt, ist typischerweise eine Reihe von Problemen an Basisstationen an einem einzelnen Standort. Aufschlüsselung nach Monaten Die Aufschlüsselung nach Kalendermonaten hilft, Saisonalität oder einen langfristigen Trend zu erkennen. Eine monatliche Massenspitze entspricht derselben Reihe von Vorfällen, die in der täglichen Dynamik zu sehen ist; ein allmähliches Wachstum über die Zeit ist ein Kandidat für eine Kommunikations- oder Batteriedegradation. ### Zweck Die Aufschlüsselung nach Monaten zeigt Saisonalität oder einen langfristigen Trend langer Sitzungen. ### Monatskennwert $$ N_{long,month} = count(long\_sessions \; in \; month) $$ ### Monatsanteil Wenn ein Anteil dargestellt werden soll: $$ Share_{month} = \frac{N_{long,month}}{\sum N_{long,all\_months}} \times 100\% $$ ### Interpretation | Bild | Mögliche Erklärung | | ------------------------- | ------------------------------------------- | | scharfe monatliche Spitze | Netzänderung, Massenausfall, saisonale Last | | allmähliches Wachstum | Kommunikations- oder Batteriedegradation | | Winterspitze | Witterungsbedingungen, Netzlast, Strom | | Spitze nach einem Update | Firmware, Einstellungen, Abfrageplan | ## Farbliche Hervorhebung pro Sitzung Längste Sitzungen eines Knotens Wird ein Knoten aufgeklappt, werden seine einzelnen langen Sitzungen nach der Stärke der Überschreitung des individuellen Schwellenwerts hervorgehoben, und die genauen RSSI- und `Btm`-Werte im Moment jeder langen Sitzung werden angezeigt. Das ist es, was das Außendienstteam benötigt: ein niedriger RSSI weist auf ein Funksignalproblem hin, während eine normale Batteriespannung die Batterie ausschließt. ### Überschreitungsverhältnis $$ Ratio_i = \frac{d_i}{UpperFence} $$ ### Interpretation | Ratio | Farbe / Stufe | | ----: | ----------------------- | | 1–2× | schwache Überschreitung | | 2–5× | mittlere Überschreitung | | ≥5× | starke Überschreitung | Dies hilft, mäßig lange Sitzungen schnell von extremen zu unterscheiden. ## Was anhand der Berichtsergebnisse zu tun ist ### Wenn die Ursache eine Basisstation ist Prüfen: - die Abdeckungsqualität am Standort; - einen alternativen Mobilfunknetzbetreiber; - eine externe Antenne; - einen Repeater; - die Wiederholung von Vorfällen nach Tag; - benachbarte Knoten am selben Standort; - die Netzüberlastung zu bestimmten Stunden. ### Wenn die Ursache ein lokaler Knoten ist Prüfen: - Antenne; - SIM-Karte; - Modem; - Stromversorgung; - Batterie; - Steckverbinder; - Installationsort; - Störungen; - Firmware-Version; - Einstellungen des Übertragungsplans. ### Wenn die Ursache ein schwaches Signal ist Maßnahmen: - RSSI vor Ort messen; - versuchen, die Antenne umzusetzen; - Antennenausrichtung prüfen; - einen alternativen Netzbetreiber prüfen; - eine externe Antenne oder einen Repeater installieren. ### Wenn die Ursache die Batterie ist Maßnahmen: - `Btm` vor Ort prüfen; - die Batterie bei Bedarf ersetzen; - den Verbrauchsstrom prüfen; - die Wiederholungshäufigkeit prüfen; - prüfen, ob das Gerät das Netz mit Wiederholungen überlastet. ### Wenn die Ursache das Modell / die Firmware ist Maßnahmen: - Knoten nach Softwareversion gruppieren; - die Release Notes des Lieferanten prüfen; - bekannte Probleme erfragen; - mit anderen Modellen an denselben Standorten vergleichen; - den Kommunikationsmodus im Labor testen. ## KI-Kommentar KI-Plan für den Vor-Ort-Einsatz Der optionale KI-Kommentar liest die RCA und verfasst einen kurzen, gut lesbaren Plan für den Vor-Ort-Einsatz des Teams. Dies ist eine **sprachliche Erläuterung, keine Quelle der Diagnostik** — alle Zahlen und Ursachen werden durch die obigen Formeln und Regeln bestimmt. ### Was die KI leisten kann - die RCA kurz wiedergeben; - den wahrscheinlichen Hauptverursacher erklären; - Top-Knoten hervorheben; - einen Plan für den Vor-Ort-Einsatz formulieren; - die Aufschlüsselung nach Modellen erklären. ### Was die KI nicht leisten kann Die KI **kann nicht**: - den IQR-Schwellenwert ändern; - die Liste der langen Sitzungen ändern; - den Score ändern; - die wahre Ursache ohne Daten bestimmen; - eine funktechnische Untersuchung ersetzen; - einen Vor-Ort-Einsatz ersetzen; - als Beweisgrundlage dienen. Die Analyse ist deterministisch. Der KI-Kommentar ist ausschließlich als erläuternder Text zu lesen — alle numerischen Schlussfolgerungen werden durch Formeln und Regeln bestimmt. ## Typische Interpretationsfehler ### Fehler: lange Sitzung = schlechtes Gerät Falsch. Eine lange Sitzung kann durch das Netz, die Basisstation, ein schwaches Signal, eine Server-Routine, eine lokale Antenne, die SIM-Karte oder die Batterie verursacht werden. ### Fehler: viele Anomalien bei einem Modell = das Modell ist schlecht Falsch. Man muss nach der Anzahl der Geräte, der Anzahl der Sitzungen, den Standorten und den Mobilfunknetzbetreibern normalisieren. ### Fehler: keine Anomalien = alles in Ordnung Falsch, wenn keine Sitzungsdaten vorliegen oder die Abdeckung zu niedrig ist. ### Fehler: hoher RSSI schließt ein Kommunikationsproblem aus Nicht immer. Es kann Betreiberprobleme, Überlastung, Firmware, serverseitigen Empfang, Wiederholungen oder Protokollfehler geben. ### Fehler: Batterieverlust = exakter Batterieverbrauch Falsch. Dies ist eine Schätzung auf Basis der überschüssigen Übertragungszeit und eines fiktiven Stroms. ### Fehler: eine einzige extrem lange Sitzung macht den Knoten zum Hauptproblem Nicht immer. Der Score berücksichtigt nicht nur das Maximum, sondern auch den Anteil, die durchschnittliche Dauer und die Anzahl der langen Sitzungen. ## Mindestkriterien für einen vollständigen Bericht Ein Bericht gilt als methodisch vollständig, wenn er Folgendes enthält: - Analysezeitraum; - Flottenabdeckung; - Status des Daten-Gates; - Anzahl der Knoten in der Flotte; - Anzahl der abgefragten Knoten; - Anzahl der Knoten mit Sitzungsdaten; - Anzahl der Knoten, die den IQR-Schwellenwert bestanden haben; - Anzahl der Sitzungen in der Stichprobe; - Anzahl der langen Sitzungen; - Anzahl der Knoten mit Anomalien; - maximale Sitzungsdauer; - Anzahl der stündlichen Vorfälle; - Verteilung der RCA-Hypothesen; - Formel des IQR-Schwellenwerts; - Formel des Knoten-Scores; - Formel des Batterieverlusts; - Regeln der RCA-Klassifizierung; - Tabelle der Top-Problemknoten; - Aufschlüsselung nach Tagen; - Aufschlüsselung nach Mengenumwerter-Typ; - Aufschlüsselung nach Monaten; - Hinweis auf die ungefähre Natur des Batterieverlusts; - Hinweis auf die Rolle der KI; - Handlungsempfehlungen. ## Konsolidierte Berichtsformel Für jeden Knoten: $$ D = \{d_i \mid d_i > 0\} $$ $$ IQR = Q3(D) - Q1(D) $$ $$ UpperFence = Q3(D) + 1.5 \times IQR $$ $$ LongSessions = \{d_i \mid d_i > UpperFence\} $$ $$ Pct_{long} = \frac{|LongSessions|}{|D|} \times 100\% $$ $$ A = min(100,\;4 \times Pct_{long}) $$ $$ B = min \left( 100,\; 8 \times \frac{AvgLongDuration}{max(1, MedianDuration)} \right) $$ $$ C = min(100,\;|LongSessions|) $$ $$ Score = 0.5A + 0.3B + 0.2C $$ Schätzung des überschüssigen Batterieverbrauchs: $$ ExtraTime_{total} = \sum_{d_i \in LongSessions} max(0,\;d_i - MedianDuration) $$ $$ BatteryLoss_{mAh} = \frac{340 \times ExtraTime_{total}}{3600} $$ Gruppierung von Vorfällen: $$ Bucket(t) = floor(t / 1h) \times 1h $$ $$ Incident = Bucket \; where \; N_{unique\_stations} \ge 5 $$ ## Empfohlener Haftungsausschluss ```text Der Bericht erkennt anomal lange Kommunikationssitzungen relativ zur individuellen Norm jedes Knotens. Das Ergebnis dient der Priorisierung der Diagnostik von Kommunikation, Antennen, SIM-Karten, Strom, Netzbetreibern und Basisstationen. Der Bericht ist kein Beweis für die Störung eines bestimmten Geräts ohne Vor-Ort-Einsatz und bewertet nicht die Richtigkeit der kommerziellen Gasmessung. ``` ## Bezug zu anderen Berichten | Wenn Sie verstehen müssen | Verwenden Sie | | --------------------------------------------------------------------- | -------------------- | | welche Knoten lange in Kommunikation bleiben und die Batterie leeren | diesen Bericht | | welche Knoten keine Kommunikation oder kein Archiv haben | Top-Problemknoten | | ob der Zeitraum für einen bestimmten Knoten abgeschlossen werden kann | Verbrauchsanalytik | | ob ein Verdacht auf Unterzählung besteht | Verdächtige Knoten | | warum ein bestimmter Knoten verdächtig ist | Umgehung der Messung | | wann Batterien zu ersetzen sind | Batterieprognose | Diese Trennung verhindert, dass lange Kommunikationssitzungen mit kommerziellen, messtechnischen und forensischen Schlussfolgerungen vermischt werden.