mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Zweikanalig, einfehlersichere Schaltungen


Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diskussion von diesen Thread abgezweigt (bitte erst dort lesen, um auf 
dem Laufenden zu sein): 
Beitrag "Hardwareaufbau Medizintechnikprodukt"

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, habe mal das wichtigste in diesen Thread übernommen.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das fehlte noch:


Autor: DAC (Gast)
Datum: 10.11.2009 12:12

http://de.wikipedia.org/wiki/TBC

Passt irgendwie alles nicht

Autor: DAC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"? ;)

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: JL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tschuldigung für die abkürzung
tbc: aus der englischen Abkürzung überstetzt: "muss fortgesetzt werden"

JL

Autor: DAC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@JL

Danke für die Aufklärung. Bin schon gespannt auf die Fortsetzung.

Autor: jl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.