Diskussion von diesen Thread abgezweigt (bitte erst dort lesen, um auf dem Laufenden zu sein): Beitrag "Hardwareaufbau Medizintechnikprodukt"
Autor: JL (Gast) Datum: 10.11.2009 11:58 OK, praktischeres: MCU: - eigentlich egal, jede ist fehlerträchtig - Signalverarbeitung und Entscheidungen sollten bei 2uCs unterschiedlich sein (eventuell auch nur eine Plausibilitätskontrolle durch den zweiten uC) - bei kommunikation zwischen den Controllern doppelt Datenübertragen, wenn möglich mit Zykluszähler, verschiedene Formatierung der daten, Checksumme Watchdog: - MCU intern als nicht existierend betrachten - immer einen externen zusätzlich einbauen Redundanz: - muss nicht immer ein dritter uC sein, oft reicht auch eine Hardware die den sicheren Zustand herstellt (or/and logic oder änderungen nicht zulässt). - immer die Signalgewinnung als Schwachpunkt mit einbeziehen, redundante Signalwege Grundlagen: - definieren von sicheren Zuständen, eventuell bedeutet das auch RESET bis zum Benutzereingreifen, ist immer von der Aufgabe abhängig - alle Fehlerpfade erkennen und bewerten (das ist der schwierigste Teil) SW: - tbc JL
Autor: DAC (Gast) Datum: 10.11.2009 12:10 @JL Jetzt hatten wir eine Überschneidung in den Beiträgen. Schön, dass du bereits den Anfang gemacht hast. Da hätte ich dann gleich ein paar Fragen dazu: >MCU: >- eigentlich egal, jede ist fehlerträchtig >- Signalverarbeitung und Entscheidungen sollten bei 2uCs unterschiedlich >sein (eventuell auch nur eine Plausibilitätskontrolle durch den zweiten uC) Das könnte man in SW lösen. Siehst du Vorteile darin, zwei unterschiedliche Derivate, oder gar von unterschiedlichen Herstellern einzusetzen? (Gibt es einen unentdeckten Bug in der Perpiherie, kann dieser durchaus in mehreren Derivaten des gleichen Herstellers enthalten sein - ein Fehler möglicher würde also auf beiden Systemen eingebaut) >- bei kommunikation zwischen den Controllern doppelt Datenübertragen, >wenn möglich mit Zykluszähler, verschiedene Formatierung der daten, >Checksumme Ok, zum Teil würde das eine Gegenmaßnahme zum vorherigen Punkt darstellen. >SW: >- tbc Oh, klingt für mich wie eine Krankheit. Da werde ich mal eine Suchmaschine bemühen müssen...
Autor: Bernd (Gast) Datum: 10.11.2009 12:22 Beschäftige dich mit dem Thema "Zweikanalig, einfehlersicher". Hierzu findet sich sicherlich einiges im www. MC's kannst du verwenden was du willst aber bei einem 2 kanaligen Aufbau in aller Regler 2 verschiedene Typen... z.B. nen 8051 mit nem AVR. Natürlich Temp. Bereich definieren, oft werden Notfall Geräte auch in erweiterten Temp. Bereichen eingesetzt. Externe Überwachung des Programmablaufs, Watchdog wurde erwähnt... IMMER extern, kann z.B. ein retriggerbares Monoflop sein. Dritten MC habe ich nie verwendet, es geht darum, dass Gerät in einen sicheren Zustand zu überführen. Stell dir vor du hast eine Infusionspumpe die plötzlich das falsche Volumen fördert. Das muß erkannt werden, das Gerät schaltet dann in den sicheren Zustand und löst einen Alarm aus. Nun kann das medizinische Personal eingreifen. Sollte eine falsche Volumenförderung unerkannt bleiben so hätte das fatale Folgen. Fehlerzustände zu definieren und zu Erkennen ist sehr komplex.
So, habe mal das wichtigste in diesen Thread übernommen.
Das fehlte noch: Autor: DAC (Gast) Datum: 10.11.2009 12:12 http://de.wikipedia.org/wiki/TBC Passt irgendwie alles nicht
Sorry, ich hatte unter dem selben Titel einen parallel-Thread gestartet. Diese Art Redundanz ist übrigens nicht sicherheitsrelevant ;) Wurde mittlerweile zum Glück gelöscht. zurück zum Thema: Zu TBC konnte ich bis jetzt noch nichts sinnvolles finden. Ist der Softwarehersteller mit diesem Kürzel gemeint oder handelt es ich um einen Zaunpfahl der Kategorie "RTFM"? ;)
Nochwas. Die Planung muss extrem langfristig erfolgen. Denn was zertifiziert wurde ist in Stein gegossen. Da sollte man nicht mal so ein neues Firmwareupdate aufspielen muessen, oder eine Komponente gegen eine guenstigere tauschen. Das betrifft auch Subsysteme. Auch wenn man diese Subsysteme zukauft. Dh mal eine guenstige Ladung Chinapowersupplies einbauen geht nicht, denn die gibt's in einem Jahr nicht mehr identisch. Ein Klacks - ja fuer ein Jahr oder Zwei. Nach zehn, fuenfzehn Jahren wird's aber aetzend. Ich bin Zulieferer einer Komponente zu einem Medizinprodukt. Der Kunde ist eine extremer Preisdruecker - ich werd mal demnaechst wegbrechen.
tschuldigung für die abkürzung tbc: aus der englischen Abkürzung überstetzt: "muss fortgesetzt werden" JL
@JL Danke für die Aufklärung. Bin schon gespannt auf die Fortsetzung.
SW:
- Entwicklung muss nach "state of the art" Methodik erfolgen
Ist eine nette Beschreibung ohne genaues auszudrücken
Also dem V-Model folgen:
Man beginnt mit der genauen Beschreibung was man entwickeln will am
besten schon heruntergebrochen auf Einzelanforderungen und deren
eindeutigen Nummerierung. Einfache Wortwahl und diagramme.
Man erstellt sich ein Design Dokument wie die Struktur der SW aussehen
soll, die Modularisierung in kleinere Komponenten und deren Interface.
Nein, nicht erst mit dem Code anfangen und später daraus irgendwas
schreiben damit man was zum zeigen hat.
Code erstellen mit klaren Regeln der Nomenklatur. (darf man sich auch
selber ausdenken, nur sollten diese Regeln irgendwo beschrieben und
nachvollziehbar sein).
Komplexität von Funktionen gering halten.
Kommentieren warum etwas gemacht wird (nicht wie, das steht ja schon als
Cod da)
Bei Berechnungen im Code einen Testcode erzeugen der auf Überläufe in
den Berechnungen testet.
Keine wilden casts.
Codereviews durchführen und dabei erklären warum es so umgesetzt wurde
(sieht man oftmals selber schon Fehler weil mans erklären muss und dabei
andere Gedankengänge hat). !Auch gegen das Designdokument prüfen, das
muss sich wiederfinden lassen.
Zu jedem Requirement Testfälle schreiben. Dabei immer bedenken auch
Negativfälle und Grenzwerte testen. Der Testumfang wird vom
Sicherheitslevel und deren Anforderungen festgelegt (siehe Tabellen in
der Norm). !Der Tester und Testschreiber sollte nicht der Programmierer
sein.
Codierregeln:
- im Funktionseinsprung werden alle Variablen die übergeben werden auf
Gültigkeit geprüft, bei Abweichung sofort die Fehlerbehandlung starten
-> sicherer Zustand.
- Zustandsvariablen/enum: niemals fortlaufende Nummernkreise verwenden,
am besten mehrfach bitweise Unterschiede.
z.B ON 0xA5; OFF 0x5A
- jedes switch case hat einen default Pfad
- Zustandsdiagramme prüfen Abläufe (wo komme ich her und von wo darf ich
herkommen - Erkennung von wilden Zustandswechseln)
- Wenn man sich an die Grundcodierregeln der Automobilbranche hält
(MISRA) hat man die gröbsten C-Fehler schonmal ausgeschlossen
- keep it simple, lieber eine Zeile mehr schreiben als zu komplex
*aa++ = ++b; muss so nicht sein -> separieren, dauert im Controller
deswegen auch nicht länger
- kritische Veriablen mehrfach ablegen in getrennten! Speicherbereichen
und bei Verwendung prüfen
- Variablen: alle Variablen bewusst! initialisieren
am besten eine Initroutine schreiben.
unsigned char aa = 12u;
ersetzen durch:
unsinged char aa;
module_xyz_init()
{
aa = 12u;
}
- Zahlen immer mit Wertebereich definieren
12 ist das jetzt unsigned 16 bit oder signed 8bit? - je nach Compiler
unterschiedlich -
immer angeben was gemeint ist
- Arrays: Indexbereichsprüfung vor Verwendung
- Pointer sind böse (nein nicht verboten, aber nicht übertrieben
benutzen)
so das wars erstmal für heute
JL
gute Stichworte zum Thema Sicherheit und Entwicklungsprozess sind auch: (A)SIL - (Automotive) Safety Integrity Level (automotove) SPICE - (Automotive) Software Process Improvement and Capability Determination MISRA - Motor Industry Software Reliability Association wobei die eher in Richtung Automobilindustrie gehen.
Da fällt mir auch noch etwas ein: Definierte Wertebereiche Bei allem Funktionsparametern einen gültigen Wertebereich definieren. Zum Beispiel bei Zahlen: Darf die Zahl negativ oder Null sein? Wie groß darf die Zahl maximal sein? Vor- und Nachbedingungen In den Funktionen Vor- und Nachbedingungen prüfen. Stimmen die Eingaben mit den Vorgaben überein? Stimmen die Ausgaben mit den Vorgaben überein? Es darf nicht sein, dass man nur davon ausgeht, dass der Parameter N nicht null sein wird. Berechnet die Funktion A/N, muss immer vorher geprüft werden, ob N nicht null ist. Das gleiche auch am Funktionsende direkt vor dem "return". Funktionsrücksprung nur am Funktionsende Das setzt vorraus, dass aus einer Funktion nicht zwischendurch zurückgesprungen wird. Das einzige "return" steht immer am Funktionsende. Speicher Nicht mit dem Speicher geizen. Passt das Programm nicht mehr hinein, einen größeren Prozessor nehmen. Nicht jedoch mit abenteuerlichen Konstrukten versuchen, ein paar Byte einzusparen. Bibliotheken Externen Bibliotheken nicht vertrauen (...die werden schon alles richtig machen...).
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.