Fließkomma Arithmetik in Sicherheits-kritischen Systemen
-
Guten Morgen, ich mal wieder:)
Aus meinem bisherigen Kenntnisstand und auch Erfahrung in Projekten mit Sicherheits-kritischen Systemen wird bisher auf
Fließkomma Arithmetik in Berechnungen verzichtet, da nicht sichergestellt werden kann , dass immer die "selben" Ergebnisse erwartet werden können auf unterschiedlichen Hardware Plattformen.Wenn bspw. 2 Kanalig Sicherheit Berechnungen ausgeführt werden , und evtl. auch unterschiedliche Compiler verwendet werden etc. kann die sehr schwer werden....
Auch die IEEE 754 Norm (so wie ich mich bissel eingelesen haben) erlaubt schon unterschiedliche Rundung-methoden etc.
Hier kann nur Abhilfe geschaffen werden, wenn man bspw. https://github.com/libdfp/libdfp
Hat von euch jemand Erfahungen in diesem Gebiet? Sichherheut => fließkomma?
Vielen Dank für eueren Input;)
-
Wenn es bei deiner Fließkommarechnung auf exakte Nachkommastellen ankommt, hast du nicht verstanden, was die Idee und Zweck von Fließkommazahlen sind. Für ihren Zweck sind sie aber genau das richtige Mittel (duh!) und es gibt keinen Grund, sie nicht einzusetzen.
Wo du einen Sinn und Zweck von Fließkommazahlen bei Sicherheitsanwendungen siehst, wenn du solche Fragen stellst, da wird mir Angst und Bange. Ich hoffe, es geht nicht um IT-Sicherheit, und du hast nicht vor, damit irgendwelche großen Primzahlen darzustellen. Für etwas aus dem Bereich der Messtechnik, wo eine Maschine bei bestimmten Verhalten von Kenngrößen abgeschaltet werden soll, da kann das das richtige Mittel sein.
-
@SeppJ sagte in Fließkomma Arithmetik in Sicherheits-kritischen Systemen:
Wenn es bei deiner Fließkommarechnung auf exakte Nachkommastellen ankommt, hast du nicht verstanden, was die Idee und Zweck von Fließkommazahlen sind. Für ihren Zweck sind sie aber genau das richtige Mittel (duh!) und es gibt keinen Grund, sie nicht einzusetzen.
Wo du einen Sinn und Zweck von Fließkommazahlen bei Sicherheitsanwendungen siehst, wenn du solche Fragen stellst, da wird mir Angst und Bange. Ich hoffe, es geht nicht um IT-Sicherheit, und du hast nicht vor, damit irgendwelche großen Primzahlen darzustellen. Für etwas aus dem Bereich der Messtechnik, wo eine Maschine bei bestimmten Verhalten von Kenngrößen abgeschaltet werden soll, da kann das das richtige Mittel sein.Nein, das sind reine Gedanken und Fragen
Ein Zitat eine Kollegen war :"In der Sicherheitstechnik sollte auf Fließkommazahlen verzichtet werden, da die Genauigkeit nicht wiederholgenau sei, bzw. Plattformabhängig ist.. "Aber Sepp, mal angenommen ein Auto Assistenz-System möchte sicher Bremsen, wenn ein Objekt in den Geschwindigkeit-Schutzfeld kommt, mit Radar system Kamera o.ä. ich denke da Läufte das ganze ja auch auf Fließkomma Berechnungen!?
-
Das ist ein konkreter Fall von meiner Maschine, die bei bestimmten Kennwertverhalten etwas tun soll. Es ist doch egal, ob dein Schutzfeld 52.5734830 Meter vor dir endet oder 52.5734831. Wenn du das so knapp kalkulierst, machst du etwas falsch. Hauptsache es fängt an zu bremsen wenn da ein Objekt 52 Meter oder weniger vor dir auftaucht, und ich hoffe du hast genügend Puffer vorgesehen, dass auch 45 Meter noch reichen würden, wenn du 52.5734830 berechnet hast.
Man könnte auch ein Argument für eine Festkommazahl für so eine Anwendung machen, weil beim Bremsweg die Größenordnungen der beteiligten Zahlen vermutlich immer ungefähr gleich sein dürfte, aber das kann nur der Macher des Systems mit Sicherheit sagen. Aber Festkommazahlen bringen ja keinen direkten Vorteil, außer ein paar Bit mehr Genauigkeit bei gleicher Hardware, und ob man nun wirklich 32 statt 24 Bit braucht um die 52.5734830 Meter noch ein paar Stellen genauer berechnen zu können, bezweifle ich.
-
@SoIntMan sagte in Fließkomma Arithmetik in Sicherheits-kritischen Systemen:
Aber Sepp, mal angenommen ein Auto Assistenz-System möchte sicher Bremsen, wenn ein Objekt in den Geschwindigkeit-Schutzfeld kommt, mit Radar system Kamera o.ä. ich denke da Läufte das ganze ja auch auf Fließkomma Berechnungen!?
Und was machst du, wenn ein Sensor ausfällt? Oder wenn ein Sensor Müll liefert? Selbst die besten Sensoren sind nicht von Ausreißern gefeilt.
Du muss im sicherheitskritischen Bereich unabhängig von evt. double Problemen eh auf Probleme bei Sensorfehlern oder Regelgrößen achten. Eine Vollbremsung z.B. beim autonomen Fahren nur weil ein Sensor ausfällt, ist sicherlich nicht gut.
Und wenn du im sicherheitskritischen Bereich bist, so wird oftmals auch ein Test auf der Zielplatform gemacht. Und dann dürften die Testreihen bei (double) Problemen anschlagen.
-
Was hat das mit der Zahlendarstellung zu tun? Die Messgröße ist "Auto bremst auch bei ausgefallenem Sensor", nicht "Bit 24837393 im Speicher muss eine 0 sein"
-
@SeppJ sagte in Fließkomma Arithmetik in Sicherheits-kritischen Systemen:
Was hat das mit der Zahlendarstellung zu tun? Die Messgröße ist "Auto bremst auch bei ausgefallenem Sensor", nicht "Bit 24837393 im Speicher muss eine 0 sein"
Was meinst du denn damit?
Ich beziehe mich auf folgende generelle Aussage:
Aus meinem bisherigen Kenntnisstand und auch Erfahrung in Projekten mit Sicherheits-kritischen Systemen wird bisher auf Fließkomma Arithmetik in Berechnungen verzichtet, da nicht sichergestellt werden kann , dass immer die "selben" Ergebnisse erwartet werden können auf unterschiedlichen Hardware Plattformen.
Und da bin ich mir nicht sicher woher diese Forderung kommt. Ist es wirklich ein Problem, oder ein mögliches numerisches Problem, oder eine Art Code Styling Regel wie z.B. Mirsa C oder als "Schutz" vor gewissen Seiteneffekten (z.B. exakter Vergleich auf Fließkommazahlen)?
Und ich sage in einem sicherheitskritischen System muss man eh fehlertolerant sein und exzessiv testen. Und dies gilt um so mehr, je hardware-näher man ist. Und dann kann man ruhig sagen "Don't panic, in einem sauberen Entwicklungsprozess muss ein Fließkomma-Problem auffallen. Sonst hat man ein generelles Problem."
Von daher halte ich einen Verzicht auf Fließkomma Arithmetik als nicht sinnvoll.
BTW: Ich hätte auch keinen Spaß daran eine GNSS Berechnung geozentrische Koordinaten -> UTM Koordinate ohne Fließkomma Arithmetik zu machen. Und da ist selbst mit double nicht viel Spielraum.
Und ich mache noch eine Aussage: In einem sicherheitskritischen System wird ein Programm nicht einfach auf einer Hardware laufen gelassen ohne zuvor einen Qualifizierungstest durchlaufen zu haben.
-
Ahh, dann habe ich deine Aussage glaube ich falsch verstanden.
-
@SeppJ sagte in Fließkomma Arithmetik in Sicherheits-kritischen Systemen:
Das ist ein konkreter Fall von meiner Maschine, die bei bestimmten Kennwertverhalten etwas tun soll. Es ist doch egal, ob dein Schutzfeld 52.5734830 Meter vor dir endet oder 52.5734831. Wenn du das so knapp kalkulierst, machst du etwas falsch. Hauptsache es fängt an zu bremsen wenn da ein Objekt 52 Meter oder weniger vor dir auftaucht, und ich hoffe du hast genügend Puffer vorgesehen, dass auch 45 Meter noch reichen würden, wenn du 52.5734830 berechnet hast.
Ja da hast du recht, ich denke da kann mit einer Genauigkeit von 2 stellen nach dem Komma umgegangen werden.
@Quiche-Lorraine sagte in Fließkomma Arithmetik in Sicherheits-kritischen Systemen:
Und da bin ich mir nicht sicher woher diese Forderung kommt. Ist es wirklich ein Problem, oder ein mögliches numerisches Problem, oder eine Art Code Styling Regel wie z.B. Mirsa C oder als "Schutz" vor gewissen Seiteneffekten (z.B. exakter Vergleich auf Fließkommazahlen)?
Und ich sage in einem sicherheitskritischen System muss man eh fehlertolerant sein und exzessiv testen. Und dies gilt um so mehr, je hardware-näher man ist. Und dann kann man ruhig sagen "Don't panic, in einem sauberen Entwicklungsprozess muss ein Fließkomma-Problem auffallen. Sonst hat man ein generelles Problem."
Von daher halte ich einen Verzicht auf Fließkomma Arithmetik als nicht sinnvoll.Das ist eine interessant. Die Problematik ist ehr diese, wenn man z.b 2 Kanal Hardware hat, und jeder Kanal auch ne andere CPU Architektur verwendet. Da ist wohl nicht sicherzustellen dass beide CPUs"exakt" die selben Ergebnisse liefern.
Mal angenommen das Ergebnisse muss auf nur 2 Stellen nach dem Komma genau sein, und bei de CPUs liefern bis dahin auch die selben Ergebnisse, aber haben bis auf die 5 stelle unterschiedliche zahlen. Ob das dann Sichheitstechnisch toleriert werden kann. Gedankenspiel.
Bei 2 Kanaliger HW mit den selben CPUs muss ja definitiv die selben Ergbenisse liefern, da muss aber davon ausgegangen werden dass die arithmetik keine fehler halt, welche im obigen beispiel ehr ausgeschlossen werden kann.
-
@SoIntMan sagte in Fließkomma Arithmetik in Sicherheits-kritischen Systemen:
Bei 2 Kanaliger HW mit den selben CPUs muss ja definitiv die selben Ergbenisse liefern, da muss aber davon ausgegangen werden dass die arithmetik keine fehler halt, welche im obigen beispiel ehr ausgeschlossen werden kann.
Das würde ich so nicht unterschreiben. Man stelle sich vor eine Kanalsoftware wäre mit Visual Studio 6 und die andere mit Visual Studio 2019 kompiliert worden. Da hat sich einiges bezüglich Gleitkommamodell getan (z.B. /fp:strict), bei den sprintf Funktionen hat sich das Rounding verändert und der Optimierer ist aggresiver geworden und hat mir meine Kahan Summe wegoptimiert :->
Benutzt jeder Kanal eigene Sensoren, so können diese fast keine selben Ergebnisse liefern. Denn jeder Sensor rauscht von Natur aus. Und da stellt sich mir die Frage wie wiederholgenau ein Sensor ist. Und ferner wie numerisch stabil ein evt. Verarbeitungsalgorithmus.
Ein Beispiel: Bei einer wiederholten GNSS / GPS Messung wird ein Unterschied im Längengrad von 0.05° entdeckt. Ist das viel? Eine Abschätzung: tan(0.05°) = Diff / Erdradius -> Diff = tan(0.05°) * Erdradius = tan(0.05°) * 6370 km = 5,558km. Und so nimmt die Drohne einen Ausflug in die Pampa anstatt ihr Paket abzuliefern.
-
@SoIntMan sagte in Fließkomma Arithmetik in Sicherheits-kritischen Systemen:
Das ist eine interessant. Die Problematik ist ehr diese, wenn man z.b 2 Kanal Hardware hat, und jeder Kanal auch ne andere CPU Architektur verwendet. Da ist wohl nicht sicherzustellen dass beide CPUs"exakt" die selben Ergebnisse liefern.
Das ist aktuell noch nicht einmal bei derselben CPU gewährleistet! Wenn man multithreaded Algorithmen nutzt, dann hängt es von diversen externen Faktoren ab, ob das Ergebnis gleich ist oder nicht. Das Assoziativgesetz ist bei Gleitkommaarithmetik nämlich nicht erfüllt: .
-
Mensch, das ist ja ein spannendes Thema. Würde Problematisch wäre es denn wenn man statt der build-in fpu eine Lib wie z.b. https://en.wikipedia.org/wiki/Libfixmath#History verwenden würder, welche alles in fix-komm rechnet? Abgehen das so die performance vermutlich wesentlich schlechter ist.
Und ja ich würde mal davon ausgehen, dass bei Kanäle exakt den selben Input (selbe Sensor) verwenden.
-
@SoIntMan sagte in Fließkomma Arithmetik in Sicherheits-kritischen Systemen:
Mensch, das ist ja ein spannendes Thema. Würde Problematisch wäre es denn wenn man statt der build-in fpu eine Lib wie z.b. https://en.wikipedia.org/wiki/Libfixmath#History verwenden würder, welche alles in fix-komm rechnet? Abgehen das so die performance vermutlich wesentlich schlechter ist.
Ich verstehe immer noch nicht, wo du hier ein Problem siehst. Der Output der Kanäle ist so etwas wie "jetzt bremsen" oder "jetzt nicht bremsen". Nicht 43.328329377324.
Und ja ich würde mal davon ausgehen, dass bei Kanäle exakt den selben Input (selbe Sensor) verwenden.
Lol, was? Dann kannst du dir Redundanz auch sparen, wenn du das kritischste und gefährdetste Bauteil davon aussparst.
