Summary / Zusammenfassung
Beim Implementierungstyp „Send unit simulated to the scene (1.0.0)” kommt es zu widersprüchlichem Verhalten, sobald die ursprüngliche Standardmaßnahme angepasst wird.
Je nach gewähltem Ressourcenfilter entstehen zwei Fehlerbilder:
Filter auf Ressourcentyp (Ressource enthält/entspricht z.B. “-RTW-“)
→ Maßnahme erkannt/generiert**, aber kein positives Signal**, Alarmierung bleibt „tot“.
Filter auf konkrete ID (Ressource: ID # z.B. “12345“)
→ positives Signal vorhanden, aber die Maßnahme wird für alle Ressourcen generiert, statt nur für die gefilterten, auch z.B. Ressourcen mit ID “67890“.
Dadurch lassen sich differenzierte Alarmierungswege nicht zuverlässig abbilden.
Steps to Reproduce / Schritte zur Reproduktion
Variante A – Fehler bei Ressourcentyp-Filter
Eine funktionierende Standardmaßnahme des Typs „Send unit simulated to the scene (1.0.0)” duplizieren oder überschreiben.
Die Bedingung von „immer wahr“ auf „Ressource enthält/entspricht [Typ]“ ändern (z. B. „-RTW-“).
Einen Einsatz disponieren, sodass die gefilterte Ressource die Maßnahme erhält.
Beobachten:
Maßnahme wird korrekt erzeugt,
aber es wird kein positives Signal ausgelöst,
die Alarmierungsabfolge startet nicht, das Einsatzmittel rückt nicht aus.
Variante B – Fehler bei ID-basierter Filterung
Dieselbe Maßnahme erneut anpassen, diesmal Bedingung auf eine konkrete Ressourcen-ID setzen.
Einsatz disponieren, sodass nur diese Ressource die Maßnahme erhalten sollte.
Beobachten:
Positives Signal wird erzeugt, das Einsatzmittel rückt aus,
aber die Maßnahme erscheint zusätzlich bei allen anderen Ressourcen,
Filterlogik wird bei der Ausführung vollständig ignoriert.
Expected Behavior / Erwartetes Verhalten
Ressourcentyp-Filter müssen dennoch ein positives Signal auslösen, wenn die Maßnahme einer passenden Einheit zugeordnet wird. Ich filtere zwar nicht die konkrete ID welche das positive Signal zurückgibt, aber ich filtere einen Baustein, der die konkrete ID finden kann, dass sehe ich ja daran, dass die Maßnahme dem korrekten Einsatzmittel zugeordnet wurde.
ID-basierte Filter dürfen nur genau die vorgesehenen Ressourcen betreffen.
Implementierungstyp Send unit simulated to the scene sollte beide Filterformen korrekt unterscheiden.
Actual Behavior / Tatsächliches Verhalten
Typen-basierte Filter verhindern die Signalerzeugung vollständig.
ID-basierte Filter lösen Signale aus, ignorieren aber die ID bei der eigentlichen Ausführung und setzen die Maßnahme für alle gleich.
Impact on Usage / Auswirkung auf die Nutzung
Moderate:
Realistische Alarmierungslogik (DME, Schnittstellen, Wachalarm, Telefon-/SMS-Alarm usw.) kann nicht sauber umgesetzt werden. Entweder kommt es zu komplett fehlenden Alarmausführungen oder zu flächendeckenden Maßnahmen, die nicht zu den Ressourcen passen.
Inconsistent Filter Behavior in 'Send unit simulated to the scene (1.0.0)': Incorrect Signal Generation and Resource Misallocation [SIMD4-280] #280
The team is reviewing the issue based on provided information and will prioritize it next. Das Team prüft das Problem anhand der Angaben und wird es anschließend priorisieren.
ich möchte den vermeintlichen Fehler gern noch etwas ergänzen, weil ich inzwischen besser verstanden habe, was da eigentlich passiert. Die Maßnahme „Send unit simulated to the scene“ prüft die Bedingungen offensichtlich nicht für jedes einzelne Fahrzeug, sondern für den gesamten Einsatz:
Sobald in einem Einsatz irgendein Fahrzeug die Bedingung erfüllt, wird die Maßnahme anschließend für alle Fahrzeuge in diesem Einsatz erzeugt, auch wenn sie überhaupt nicht gemeint sind.
Ein Beispiel aus meinem Test. Ich filtere einmal nach RTW und einmal nach Mobile Retter. Im Einsatz befindet sich ein RTW und ein Mobile Retter. Eigentlich sollte der RTW nur den DME bekommen und der Mobile Retter nur die Mobile Retter Datenübertragung. Tatsächlich bekommen aber beide Fahrzeuge beide Maßnahmen. Das wirkt so, als würde das System nur prüfen, ob im Einsatz irgendwo ein RTW vorkommt und wenn das zutrifft, wird die Maßnahme dann einmal global für alle im Einsatz verteilt. Genau dasselbe passiert mit dem mobilen Retter. Und weil beide Bedingungen zutreffen, bekommt am Ende jedes Fahrzeug alles, egal ob es Sinn ergibt oder nicht.
Zusätzlich kommt hinzu, dass Alarmierungsmaßnahmen parallel fehlerhaft laufen. Eine davon wird fast immer falsch ausgeführt. Die Simulation kommt offenbar derzeit nur mit einer Alarmierungsmaßnahme je Fahrzeug zurecht. Möchte man differenziert simulieren (DME, Wachalarm/Gong, etc.) kann nur eine der Maßnahmen erfolgreich abgewickelt werden. Die restlichen sind fehlerhaft deklariert.
Eigentlich möchte ich ja sauber trennen. RTW sollen RTW Alarmwege bekommen und Mobile Retter sollen die Mobile Retter Übergabe bekommen. Bei Feuerwehren ebenfalls noch deutlich mehr Beispiele und Wege, welche ich nicht alle aufführen möchte. Das geht im Moment nicht, weil der Filter nicht auf das einzelne Fahrzeug angewendet wird, sondern auf den Einsatz als Ganzes. Sinnvoll wäre eine Zielzuordnung bei den Alarmierungsmaßnahmen in der Administration:
Parameter (hier nicht notwendig)
Bedingungen (kann man wie von mir beschrieben notieren)
Ziel (hier nochmalige Eingabe von Ressource, Ressource: ID # oder Ressource: Wache) Man kann Punkt 3 natürlich auch als Parameter verstehen und darber die Ziele festlegen)
Nur das Ziel erhält bei zutreffendem Parameter dann die Maßnahme als Ergebnis, vorausgesetzt es ist dem Einsatz zugeordnet.
Rein theoretisch müsste man sonst für jedes Fahrzeug eine eigene Maßnahme mit der exakten Fahrzeug ID anlegen, was völlig unpraktikabel ist.
Ich hoffe, das hilft, besser einzugrenzen. In der aktuellen Form ist eine gezielte Alarmierung mit verschiedenen Alarmwegen nicht vernünftig möglich.