In der DIN EN 61508-7 im Abschnitt E.18 lese sich "Überprüfung der defensiven Codierung ..." Wie sieht denn in der Praxis so eine "defensiven Codierung" aus? Wie äußert sich das in eurer Codierung (Programmierung)?
Bei mir äußert sich dass so, das ich bei eingehenden parametern immer von dem schlimmsten ausgehe. Also immer aufpassen, das du fehlerhafte werte abfängst.
Was heisst denn, das Schlimmste? Defensiv meint in diesem Zusammenhang, Abwehr und zwar von Fehlern.
Edgar M. schrieb: > Abwehr und zwar von Fehlern. Welchen Fehlern? Die des Programmierers? Oder später auftretende Hardwarefehler? Oder Datenfehler?
Das klingt wieder mal nach einem sehr hochtrabenden akademischen Ansatz, der in der Praxix eh meist völlig daneben ist. So ähnlich wie die partielle Rekonfiguration....
Man könnte darunter eventuell auffassen, z.B. bei Zustandsautomaten auch alle Zustände zu formulieren, die 'nie' auftreten können.
Lothar Miller schrieb: > Welchen Fehlern? > Die des Programmierers? > Oder später auftretende Hardwarefehler? > Oder Datenfehler? Nun, die gibt es ja nun allesamt und im Grunde sollte/muss man sie auch immer behandeln, wenn auch nicht alle zur Laufzeit :-) Je nach Anwendung kann es aber schon sinnvoll sein, verschiedene Fehler in Betracht zu ziehen und sie zur Laufzeit einer Fehlermenge zuzuordnen. Denkbar sind z.B. - schwankende, aber gültige Werte, die dennoch ausserhalb SPEC liegen - sporadisch falsche Werte infolge Analogeinstreuung / Rauschen - sporadisch falsche Werte infolge Digitaleinstreuung / Bitfehler - permament falsche Werte infolge Fehlcodierung des VHDLs in Fremdmodul - permament falsche Werte infolge Fehlschaltung eines Steckers - statische Fehler im FPGA (Exemplarproblem) Die Liste liesse sich fortsetzen. Ein beliebter Fall ist z.B. stockende oder fehlende Daten von kaputten HW-Modulen und Wandlern. Leider programmieren viele "Experten" nur den GUT-Fall und vernachlässigen die Fehlerfälle. Dabei ist genau das die grosse Schwierigkeit in der Softwareentwicklung: Fehlerfälle anhand der Daten von einander und vom Rauschen abzugrenzen, sie Fehlermengen zuzuordnen, einer FMEA zu unterziehen und die logischen Schlussfolgerungen für Entwicklung, Implementierung und Test abzuleiten. Der Code muss dafür entsprechend strukturiert und geordnet werden. Fehlermengen, die nur Programmierfehler, Hardwareverbindungs- und verkabelungsprobleme und Ähnliche entdecken sollen, kann man in einer finalen Version u.U. wegfallen lassen. Andererseits liegt genau hier der Hase im Pfeffer: Wenn in der Montage etwas geknickt, gekappt oder umgesteckt wird, lässt sich das oftmals nur durch (VHDL-)software entdecken und zwar dann, wenn man solche unsinnigen Fehler antizipiert. Sven P. schrieb: > Man könnte darunter eventuell auffassen, z.B. bei Zustandsautomaten auch > alle Zustände zu formulieren, die 'nie' auftreten können. Die sollte man ohnehin auf einen Fehlerzustand lenken, da das immer auf entweder einen schweren HW-Fehler oder Mangel in der Funktion (Fallabdeckung) hinweist. FSMs sind aber ein gutes Beispiel: In komplexen gesteuerten Rechenketten und pipelines bekommt man es mitunter nicht immer mit, wenn sich das System im Betrieb mal vertaktet und was Falsches auswirft. Bei Strahlung und hohen Feldstärken sind FPGAs nämlich durchaus vulnerabel!
Juergen Schuhmacher schrieb: > Lothar Miller schrieb: >> Welchen Fehlern? >> Die des Programmierers? >> Oder später auftretende Hardwarefehler? >> Oder Datenfehler? > > Nun, die gibt es ja nun allesamt und im Grunde sollte/muss man sie auch > immer behandeln, wenn auch nicht alle zur Laufzeit :-) > ... Einer der besten Beiträge, die ich hier gelesen habe. Ich bringe mal die Stichworte "Validierung" und "Verifikation" mit ein. Eventuell trifft ein Suchender den Thread.
Juergen Schuhmacher schrieb: > Fehlermengen, die nur Programmierfehler, Hardwareverbindungs- und > verkabelungsprobleme und Ähnliche entdecken sollen, kann man in einer > finalen Version u.U. wegfallen lassen. Das sollte man auch tunlichst tun, denn eine Laufzeit-Fehlerbetrachtung für Fehler, die entweder nie mehr auftreten können/werden, oder gar keine Auswirkungen haben, kostet Ressourcen und Energie. Man kann natürlich ein "fehlertolerantes" System aufbauen, nur braucht man das lustigerweise nur sehr selten. Wenn ein Telefonat wegen eines aufgetretenen Fehlers unterbrochen wird, dann ist das bestenfalls ärgerlich. Wenn ein Lauflicht Unsinn anzeigt, dann ist das hinnehmbar. Wenn ein Kaffee nicht ausgeschenkt wird, dann gehts auch mal ohne, usw. Nur die wenigsten Systeme sind dermaßen sicherheitsrelevant, dass sich zusätzlicher Aufwand zum expliziten Abfangen eines Fehlerfalls lohnt. > Andererseits liegt genau hier der Hase im Pfeffer: > Wenn in der Montage etwas geknickt, gekappt oder > umgesteckt wird, lässt sich das oftmals nur durch (VHDL-)software > entdecken und zwar dann, wenn man solche unsinnigen Fehler antizipiert. Gefunden werden kann auch nur das, was sich der Entwickler vorher ausgedacht hat. Wenn du 2 Achsen hast, und den Positionsgeber der einen Achse auf die andere steckst, dann wird trotz weitreichend plausibler Werte eine Fehlfunktion herauskommen. Und wenn du jetzt ausgefuchste Algorhitmen implementierst, um diesen Fall abzufangen, dann ist das weggeworfenes Geld. Sinn machen würde es erst dann, wenn du die Geber dann intern automatisch ummappst und es somit EGAL ist, wo welcher Geber angeschlossen wird. Juergen Schuhmacher schrieb: >> Man könnte darunter eventuell auffassen, z.B. bei Zustandsautomaten auch >> alle Zustände zu formulieren, die 'nie' auftreten können. > Die sollte man ohnehin auf einen Fehlerzustand lenken, da das immer auf > entweder einen schweren HW-Fehler oder Mangel in der Funktion > (Fallabdeckung) hinweist. Da möchte ich mal auf den Beitrag "Re: Force auf records anwenden - Modelsim VHDL" verweisen. Ich habe noch keine FSM "failsafe" implementiert, denn die einzigen Fehler, die ich im Zusammenhang mit "fehlerhaften" FSM beobachtet habe, hatten allesamt mit asynchronen Signalen zu tun. Und selbst eine "sichere" FSM garantiert ja nur, dass kein undefinierter Zustand auftritt. Sie garantiert aber nicht, dass keine undefinierte Transition passieren kann!
Sven P. schrieb: > Man könnte darunter eventuell auffassen, z.B. bei Zustandsautomaten auch > alle Zustände zu formulieren, die 'nie' auftreten können. Das sollte man auf keinen Fall im VHDL-Code machen! Wenn du Zustände behandeln willst, die "nie" auftreten, dann muss das das Synthesetool machen. Wenn du solche Zustände im VHDL-Code erwähnst, macht das Synthesetool dir da wieder was ganz anderes draus, mit noch mehr Zuständen die "nie" auftreten!
> Nur die wenigsten Systeme sind dermaßen sicherheitsrelevant, > dass sich zusätzlicher Aufwand zum expliziten Abfangen eines > Fehlerfalls lohnt. Kommt drauf an, womit man es zu tun hat. Ich arbeite fast ausschließlich an Systemen, bei denen ein Denk- oder Programmierfehler sehr viel Geld fürs Inbetriebnehmen und Fehlersuchen verursacht und ein Ausfall im Betrieb wiederum sehr hohe Kosten nach sich zieht und nicht selten Menschenleben kosten kann, bzw es kostet die falschen das Leben, wie bei Produkten für die (Achtung Wortwitz:) "defensive".
Juergen Schuhmacher schrieb: > bzw es kostet die falschen das Leben, Da fällt mir auf: wer darf entscheiden, wer der Richtige ist?
Das ist eine berechtigte und gute Frage, die zu erörten allerdings den hiesigen Rahmen sprengen würde. Naheliegend geht es aus technischer Sicht einmal darum, dass der, der ein System bedient, mit dem Knopf, den er drückt, zu jedem Zeitpunkt exakt das Ergebnis erreicht, das er hatte haben wollen und das System nicht etwa irgendein eigenständiges oder zufälliges Verhalten fabriziert. Das fängt beim Mobiltelefon an und hört beim Auto auf. Diesbezüglich liesse sich mal darüber nachdenken, ob man z.B. bei den heutigen Browsern immer und mit jedem Klick das bekommt, was die Intention war und ob z.B. Autonavigation, Autoausfüllen und ähnliche "Hilfen" nicht mehr Unsicherheit und Störung initiieren, als Nutzen bringen. Gerade im Bereich der Software ist es aber leider so, dass planlos realisiert wird, was der Baukasten hergibt und nicht etwa das, was zielführend gewesen wäre. Beispiele für eingebauten Unfug sind: - Sound beim Tastaturklick - Gezielt langsam öffnende Dateiordner - ungeordnetes und zielloses Einfärben von Bildschirmelementen - konkurrierendes Blinken von Elementen / Buhlen um Aufmerksamkeit - 50 verschiedene Schriftstile - generelle unnötige Leistungsverschwendung - etc... Leider hat die "Ich haue rein, was geht und bunt ist"-Mentalität auch bereits im Bereich FPGA schon Einzug gehalten. Da findet man soft cores, wo keine gebraucht werden, unnötig universelle Prozesse in multitasking, die aufwändig nachsynchronsiert werden müssen, massenweise Puffer und Speicher, wo keine gebraucht worden wären, wenn man geschickter geplant hätte, gross angelegte Cores mit pauschalen Hammerfunktionen und Auflösungen, wo es 3 Register getan hätten und Vieles mehr. Defensive Programmierung könnte man mithin auch so lesen, dass man sich beim unmotivierten Realisieren von "gewissen features" zurückhält :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.