Re: Zielladen trotzdem durchführen obwohl SOC fehlt
Verfasst: Mo Jul 29, 2024 12:00 pm
Die grundsätzliche Frage ist ja, ob man einen erkannten Fehlerzustand als gesonderten Zustand in der weiteren Verarbeitung betrachten mag. So wie sich das für mich hier liest, ist das aktuell nicht der Fall und ein Fehlerwert wird nicht explizit als Fehler betrachtet. Da müsste also noch nachgebessert werden und bei jedem Messwert entschieden werden, wie im Fehlerfalle darauf zu reagieren ist.
Dass das nicht für alle gleich ist, kann man am fehlerhaften SoC schön erkennen: der eine will das Auto geladen haben, damit er morgens vom Hof kommt und der andere möchte lieber nicht laden, als zu riskieren inakzeptabel hohe Strompreise bezahlen zu müssen.
In der Konsequenz bedeutet das, dass es je Messwert und Entscheidung einstellbar sein muss, wie die Entscheidung bei einem Fehlerwert zu fällen ist. Ist ein Haufen voll Arbeit, den man sich damit so aufhalst.
Die generelle Aussage, im Fehlerfalle einen konstanten Wert anzunehmen und damit weiterzuarbeiten wäre handwerkich nicht in Ordnung halte ich auch nicht für grundsätzlich korrekt. Dafür habe ich in meinem
Leben schon zu oft das Ergebnis einer Division durch Null auf Null gesetzt, weil das in der Anwendung dem erwarteten Programmverhalten am Nächsten kam. Der Auftraggeber wäre in den meisten Fällen auch nicht in der Lage gewesen, da etwas besonderes uu spezifizieren. Und das gesamte Ergebnis einer Auswertung auf NaN, NULL oder n/a zu setzen ist aus Anwendersicht inakzeptabel.
Um nochmal auf den SoC und die Null zurückzukommen: zu laden obwohl der SoC nicht kommt ist ja letzten Endes nur dann doof, wenn man am nächsten Tag das Auto nicht braucht. Womit wir beim kalenderabhängigen Fehler-Default-Verhalten wären…
Dass das nicht für alle gleich ist, kann man am fehlerhaften SoC schön erkennen: der eine will das Auto geladen haben, damit er morgens vom Hof kommt und der andere möchte lieber nicht laden, als zu riskieren inakzeptabel hohe Strompreise bezahlen zu müssen.
In der Konsequenz bedeutet das, dass es je Messwert und Entscheidung einstellbar sein muss, wie die Entscheidung bei einem Fehlerwert zu fällen ist. Ist ein Haufen voll Arbeit, den man sich damit so aufhalst.
Die generelle Aussage, im Fehlerfalle einen konstanten Wert anzunehmen und damit weiterzuarbeiten wäre handwerkich nicht in Ordnung halte ich auch nicht für grundsätzlich korrekt. Dafür habe ich in meinem
Leben schon zu oft das Ergebnis einer Division durch Null auf Null gesetzt, weil das in der Anwendung dem erwarteten Programmverhalten am Nächsten kam. Der Auftraggeber wäre in den meisten Fällen auch nicht in der Lage gewesen, da etwas besonderes uu spezifizieren. Und das gesamte Ergebnis einer Auswertung auf NaN, NULL oder n/a zu setzen ist aus Anwendersicht inakzeptabel.
Um nochmal auf den SoC und die Null zurückzukommen: zu laden obwohl der SoC nicht kommt ist ja letzten Endes nur dann doof, wenn man am nächsten Tag das Auto nicht braucht. Womit wir beim kalenderabhängigen Fehler-Default-Verhalten wären…