Ersteinmal vielen Dank für Eure Anteilnahme.
Mal eben zu den letzten Threads:
Ich habe auch jahrelang NUR Assembler programmiert, musste notgedrungen auf "C umsteigen,
wobei ich die neuen Generationen von Prozessoren auch nicht mehr nur in Assembler programmieren möchte,
aber regelmässig mir den erzeugten Assembler Code vom C-Compiler anschaue und dann tatsächlich
Fehler finde, was der Compiler falsch gemacht hat.....
Natürlich nur weil ich es ihm nicht eindeutig erklärt habe was ich machen wollte.
----------------------------------------------------
Gut getestete Bibliotheken die von zig Programmieren verwendet werden, haben natürlich
viele Vorteile, eben weil Fehler bei dem einem oder anderem schon aufgetaucht wären
oder sind und dementsprechend beseitigt wurden.
Open Source hat auf jeden Fall Vorteile. Wobei bei größeren Projekten
oder Bibliotheken das auch keiner mehr bis ins Detail nachvollziehen kann.
Das Rad immer wieder neu erfinden ist wirklich SEHR zeitaufwändig, da kann ich ein Lied von singen.
Und ich würde lügen, wenn da nicht etliche von Fehlern beseitigt werden musten, bis es "augenscheinlich" richtig funktionierte.
Auch ich schaue gerne mal in fremden Code und schaue mir an wie andere das lösen.
Dabei lernt man ja auch und auch da gab es "bessere" Lösungen an denen ich mich gerne orientiere.
Die vielen Analyse-Tools, die man uns gerne "andrehen" möchte, ohne diese jetzt schlecht machen zu wollen,
können schon div. Unzulänglichkeiten, Fehler usw finden.
Leider ist eine sichere Funktion deshalb aber trotzdem nicht gewährleistet.
Die Analyse Tools können nicht die Hardware abbilden und da liegt schon ein riesen Problem.
Den Code durch einen Compiler jagen und mit dutzenden Parametern füttern ist sicher
eine grobe Abschätzung aber z.B. Read/Modify/Write Probleme kann man damit nicht finden.
Ebenso wird ein AnyseTool nicht die Problematik mit den Interrupts beim ARM Code aufzeigen.
Wenn hier nämlich in der letzen Softwarezeile das IRQ-Bit gelöscht wird, kann,
aber muss es nicht funktionieren, das hängt vom erzeugten Code ab.
Da hilft nur Testpunkte/Oszilloskop und viel Geduld und Erfahrung.
Ich brauch ja nur ein Häkchen im Compiler ändern und schwupps steht das ganze System.
Deshalb werden bei mir die Tests mit "allen möglichen" Optionen auf Speed/Size usw durchgeführt.
Die Software MUSS in allen Compilaten einwandfrei laufen.
Das kostet richtig viel Zeit, aber ich fühle mich für meine Software auch verantwortlich.
Wenn es um die Risikobewertung geht, muss ich ja auch die Hardware, also die Prozessoren selbst
mit einbeziehen und ich kenne keinen, für den es nicht einen/mehrere Errata Sheets gibt,
in denen Probleme beschrieben werden.
Auch nach Jahren werden diese Dokumente immer länger, weil irgendwann irgendwer ein Problem
unter bestimmten Bedingungen erkannt hat.
Hier muss ich eigentlich regelmäßig gucken, ob es nicht neue Fehler gibt, welche mein
System/Patienten gefährden könnten.
Ein "zertifizierte Compiler" ist auch auch ein heikles Thema.
Darf ich einen GNU-Compiler verwenden oder nicht ?
Mit Sicherheit ein SEHR gut getesteter Compiler und Open Source.
Wobei ich hier ja schon eine "speziell compilierte" Variante für die ARM Prozessoren verwende,
wobei ich hier auch nicht weis was wie zusammengelinkt und compiliert hat.
Wie Peter schon richtig schrieb: Ist die Benutzung der Prozessoren immer auf eigene Gefahr und
nicht für Lebenserhaltene Systeme gedacht.
Glücklicherweise konnte ich in meinen Geräten bisher immer eine zusätzliche Hardware einbauen,
die im Fehlerfalle das System in einen unkritischen Zustand versetzt.
Das steht auch in meiner Risikoanlyse, dass eine ausreichende Sicherheit ohne zusätzliche
Hardwaremaßnahmen NICHT gewährleistet werden kann.
Damit bin ich erstmal fein raus, da kann die Software oder der Prozessor machen was er will.
Doppelte Sicherheit ist ja IMMER angesagt in unserem Bereich.
------------------
Hier mal ein Ausschnitt aus meiner Rechtfertigung, der zusätzlichen Hardwaresicherung:
Der benutzte Prozessor Kern CORTEX-M3 enthält Fehler, es gibt verschiedene Revisionen.
Die Firma NXP verbaut diese fehlerhaften Kerne in einen Microcontroller, hiebei kommen weitere Fehler hinzu.
NXP hat also auch verschiedenen Revisionen.
Mit der Entwicklungssoftware (welche ebenfalls) Fehler enthalten kann, wird eine Geräte-Software entwickelt.
Eine Sicherstellung auf einwandfreie Funktion von 93.582 Dateien in 9.967 Ordnern der IAR Entwicklungsumgebung ist unmöglich.
Mit einer Programmiersoftware (z.B Flashmagic), welche ebenfalls Fehler beinhalten kann, wird der Chip programmiert und ausgeliefert.
Die interne Bootloader des Chips (Software) könnte auch Fehler beinhalten.
Die Endsoftware versucht Probleme mittels Checksumme zu ermitteln. Die Checksummen Funktion kann aber nicht alle Fehler erkennen, und/oder könnte selbst Fehlerhaft sein.
Dann bleibt offen:
Welche Revision des Controllers hat später der Bestücker verbaut ?
Welcher CORTEX-Kern wurde dabei verwendet ?
Mit welcher Revision wurde programmiert ?
Und zum Schluss:
Welche unentdeckten Fehler befinden sich in der Geräte-Software ?
Eigentlich ein schier endloses Grab an Fehlermöglichkeiten.
Eine ausreichende Sicherheit nur mittels Software kann NICHT gewährleistet werden.
Es ist zwingend erforderlich ein zusätzliches mechanisches/elektromechanisches Sicherungssystem zu integrieren.
Also eigentlich egal ob SOUP oder nicht, ich muss eh gegensteuern um ausreichende Sicherheit zu gewährleisten...
Ich wünsche Euch ein erholsames Wochenende
Siro
Zitieren
Zitat von Siro
Lesezeichen