www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Steuerung - Welcher Microcontroller


Autor: Uwe Heydemann (uwe1981)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo :-) Ich bin auf der Suche nach einem passenden Controller fuer 
mein Projekt und komm nicht so recht mit der Suche weiter. Es gibt ja 
bald mehr verschiedene Controller als Woerter im Duden :-)
Ich arbeite an einem Tauchgeraet, welches selbststaendig unter Wasser 
das jeweils erforderliche Gas zusammen mischt und gleichzeitig mittels 
der Tiefen- und Zeitdaten sowie der Atemgas-Zusammensetzung die 
Dekompression berechnet. Das ganze ist als Pilotprojekt zu betrachten, 
da es ein derart komplexes Steuersystem noch nicht auf dem Markt gibt. 
Deshalb steh ich etwas im Wald, wenn es um die Hardwareanforderungen 
geht. Vielleicht koennt ihr mir weiterhelfen, wenn ich den 
Funktionsablauf beschreibe:

Mittels drei Sensoren (analoges Signal) wird das Gasgemisch in Echtzeit 
analysiert. Ein analoges Ausgangssignal steuert entsprecht ein 
elektronisches Mengenventil, welches die Sauerstoffzufuhr (L/min) je 
nach Atemarbeit erhoet oder reduziert. Der prozentuale Anteil des reinen 
Sauerstoffs sollte zwischen einem vordefinierten min/max-Wert gehalten 
werden.
Weitere Sensoren/Signale:
4x Druck (analoges Signal)
4x Temperatur (analoges Signal)
6x Bedientaster 1/0
10x versch. Eingangssignale 1/0
8x Ausgangssignale 1/0 zur Relaisansteuerung

Dekompressionsberechnung durch Auswertung von Tiefe, Zeit
und 12 unterschiedlichen Faktoren im 2 Sek.-Takt, daraus Berechnung und 
Anzeige der Daten auf grafischem Display. Moeglichkeit zur Speicherung 
der Daten.

Eine zusaetzliche Anforderung waere ein Diagnoseprogramm, welches das 
System nonstop im Hintergrung ueberwacht und bei einer Unstimmigkeit 
oder eines Ausfalls auf ein Zweitsystem umschaltet, um einen Absturz 
oder Reset mit Funktionspause zu vermeiden.

So, jetzt kennt ihr ungefaehr den Leistungsumfang des Systems. Dazu 
benoetige ich nun die passende Hardware. Wer kann mir weiterhelfen? Da 
es sich um ein Tauchgeraet handelt, sollte die Hardware von bester 
Qualitaet sein um einen Ausfall durch Defekt moeglichst zu vermeiden. 
Programmiert wird das ganze uebrigens in Ada.

Liebe Gruesse
Uwe

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Programmiert wird das ganze uebrigens in Ada.

Wieso ADA, wieso nicht C? Such halt nach einem uC für den
es einen ADA Compiler gibt. Das dürfte die
Auswahl um einiges einschränken;)

Autor: Dummi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau doch erst mal für welche Controller du einen ADA Compiler findest,
das sollte die Auswahl schon stark einschränken.

Von den Anforderungen her sollten das schon die meisten packen.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bezüglich Rechenleistung sehe ich keinerlei Anforderungen. Jeder 
8-Bitter sollte es wuppen.
Warscheinlich verbraucht das GLCD die meiste Rechenpower.

Bezüglich Sensoren würde ich möglichst digitale Sensoren verwenden, sie 
liefern entweder nen richtigen Wert oder garkeinen.
Analoge Sensoren benötigen dagegen höchstwertigste Steckverbinder und 
Kabel, da eine Verfälschung nicht erkennbar ist.


Peter

Autor: Reinhard R. (reirawb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe Heydemann schrieb:
> Atemgas-Zusammensetzung
  Atmegas
passen da am besten :-)

Sorry, den konnte ich mir nicht verkneifen.

Reinhard

Autor: Fr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wieso ADA, wieso nicht C?

deswegen vielleicht:
>C schränkt direkte Speicherzugriffe kaum ein. Dadurch kann der Compiler
>(anders als zum Beispiel in Pascal) nur sehr eingeschränkt bei der >Fehlersuche 
helfen. Aus diesem Grund ist C für sicherheitskritische >Anwendungen 
(Medizintechnik, Verkehrsleittechnik, Raumfahrt) weniger >geeignet.
(Wikipediaartikel über C)

oder deswegen:
>hat sie sich vor allem in sicherheitskritischen Bereichen durchgesetzt, >zum 
Beispiel in der Flugsicherung, in Sicherheits-Einrichtungen der >Eisenbahn, in 
Waffensystemen, der Raumfahrt, der Medizin oder der >Steuerung von 
Kernkraftwerken.
(Wikipediaartikel über ADA)

oder weil sich millionen Fliegen doch irren können ;-)



>Such halt nach einem uC für den
>es einen ADA Compiler gibt. Das dürfte die
>Auswahl um einiges einschränken;)

Das wäre das erste, was ich machen würde.
Und dann die Hersteller der jeweiligen Controller anschreiben, was Sie 
darüber denken, ihre Controller in derart kritischen Anwendungen zu 
sehen.

>Ich bin auf der Suche nach einem passenden...
Das "einem" halte ich hier für sehr gefährlich. Deshalb solltest Du als 
nächstes zumindest für die Sicherheitsrelevanten Abschnitte des 
Projektes über diversitäre Redundanz nachdenken.
(mehrere Controller (ab Besten von verschiedenen Herstellern) die um 
systematische Fehler und Denkfehler zu umgehen, jeder durch eine andere 
Person programmiert wurden, die das Programm der jeweils anderen nicht 
kennen)

Frank

Autor: micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, was macht den das Budy Inspriation oder IDA-71 sonst mit den 
ganzen Daten? Sitchwort ist selbstmischender Rebreather, da gibt es sehr 
wohl ein paar. Dräger hat da IMHO auch was, aber das gibt's nicht zivil 
:-)
ADA ist übrigens angeblich in Mititärkeisen beliebt...

Kurze Rede, wenn Du nicht viel Ahnung davon hast, lass es. Ein 
Inspiration kosten so 5k€, Selbstbau wird (wenn es sicher sein soll) 
nicht billiger. Oder fang klein an. Es ein paar Selbstbau-Tauchcomputer 
Projekte im Netz (Peter Rachow?).

Autor: Uwe Heydemann (uwe1981)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Redundanz ist sich von Vorteil, deswegen zwei unabhaengig arbeitende 
Controller :-) Ada genau deshalb, weil es fuer lebenssichernde Systeme 
die einzig wirklich nutzbare Sprache ist. Ich arbeite am Flughafen und 
mache u.a. Pre-Flight-Checks, deswegen bin ich mit der Zuverlaessigkeit 
von Ada etwas vertraut. Programme laufen generell unter Ada etwas 
langsamer, aber deutlich fehlerfreier und absolut stabil. Jedenfalls ist 
mir kein Fall bekannt, in der ein Pilot seine Muehle in der Luft reseten 
musste lol

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>hat sie sich vor allem in sicherheitskritischen Bereichen durchgesetzt, >zum
>Beispiel in der Flugsicherung, in Sicherheits-Einrichtungen der >Eisenbahn, >in
>Waffensystemen, der Raumfahrt, der Medizin oder der >Steuerung von
>Kernkraftwerken.

Vor Programmfehlern schützt das aber auch nur begrenzt.
Wenn er seinem Taucher aufgrund eines Programmierfehlers
100% Sauerstoff spendiert ist der trotzdem tot.

Autor: Uwe Heydemann (uwe1981)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo micha, sicher gibts ein Buddy Inspiration und auch ein IDA (was 
uebrigens nicht elektronisch steuert). Ein Buddy will ich nicht, da es 
a: gut ausgestattet 9000 Schleifen kostet und b: mich daran hindert 
eigene Ideen umzusetzen. Das Argument "Was man nicht kann, sollte man 
lassen" tausch ich mal durch "Wo Wissen fehlt, sollte man ergaenzen und 
ausprobieren" aus. Sonst haettest Du sicher heute keinen Beruf, oder 
konntest Du bereits alles schon von Geburt an? Ich hab Spass am basteln 
und am umsetzen neuer Ideen und denke, dass das sicher nicht falsch ist.
Uebrigens, mit Peter Rachow hab ich Kontakt, von ihm sind die Formeln 
fuer die Dekompressionsberechnung. Nur hab ich Sie noch etwas erweitert 
nach RGBM-Standard.

Autor: Fr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Vor Programmfehlern schützt das aber auch nur begrenzt.
>Wenn er seinem Taucher aufgrund eines Programmierfehlers
>100% Sauerstoff spendiert ist der trotzdem tot.

Deshalb habe ich auf die diversitäre Redundanz verwiesen.

Autor: Coder (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh Mann, nimm einfach C und gut ist, Ada rettet dir auch nicht den 
Hintern wenn du was vermurkst.
Die von dir beschriebene Steuerung ist sehr einfach umzusetzen und mit 
fast nix an Power machbar, einzig die Herausforderung das es weitgehend 
Fehlerfrei sein muss macht es überhaupt interessant.

Wenn ein Programm "abschmiert" hat das ansich nix mit dem Compiler zu 
tun, es ist, Hardwarefehler mal ausgenommen, der Programmierer der es 
versemmelt.
C ist zugegebenermaßen da nicht besonders Deppenfreundlich, aber solange 
der Programmierer weis was er tut ohne Probleme einsetzbar.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Vor Programmfehlern schützt das aber auch nur begrenzt.
>>Wenn er seinem Taucher aufgrund eines Programmierfehlers
>>100% Sauerstoff spendiert ist der trotzdem tot.

>Deshalb habe ich auf die diversitäre Redundanz verwiesen.

Hmm, also mehrere Programmierer. Wenn beide Fehler
machen ist das Resultat immer noch eine Mischung
aus Richtig und Fehlern. Wer macht nun was richtig? Wer
entscheidet darüber was richtig ist? Da kann einem
echt der Kopf rauchen;)

Und der Taucher ist immer noch tot.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nichts gegen ADA, aber wie heist es so schön: Man kann in jeder Sprache 
Fortran Programme schreiben.

Wer sein Handwerk beherrscht kann in C genauso sichere Programme 
schreiben wie in ADA. Es ist nicht die Sprache die das ausmacht.
Und das das DoD auf ADA steht, ist auch leicht erklärt: Sie haben die 
Sprache entwickeln lassen.

Redundanz ist gut. Aber tu dir das Prozedere mit mehreren Prozessoren, 
die sich gegenseitig überwachen nicht an. Ein Watchdog im Prozessor 
aktiviert, nur zur Sicherheit, und gut ists. Diese Dinger mit 
Backup-system und dergleichen klingen zwar gut, sind aber der absolute 
Horror. Du wirst dir mit sowas mehr Fehler einbauen, als du ohne Backup 
System hättest. Und ein 'Absturz mit Funktionspause nach dem Reset' geht 
so schnell, dass dein Taucher gar nicht merken wird, wenn der Prozessor 
tatsächlich einmal resettet (was bei einem vernünftig geschriebenen 
Programm nicht vorkommen wird. Auch dann nicht, wenn es in C geschrieben 
ist)

Die Anforderungen die sich aus deiner Beschriebung ergeben, sind auch 
so, dass du aus C nichts wirklich kritisches oder besonders kniffliges 
benutzen musst. Wenn du deine Sensoren auswerten kannst und die 
Messwerte mittels Formeln verknüpfen kannst, muss man nur noch darauf 
achten, dass zwischendurch in den Berechnungen keine Overflows 
entstehen. Das ist in ADA auch nicht anders. Du hast keine dynamischen 
Speicherallokierungen und das man Arrayzugriffe in Tabellen (so welche 
vorkommen) mit den Arraygrenzen absichert ist auch in C keine 
Raketentechnik.

Nur so am Rand mal eine Frage: Kannst du ADA oder irgendeine andere 
Programmiersprache? Denn die beste Sprache ist immer die, die man schon 
beherrscht. ADA hin oder her!

Autor: Realist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wieso ADA, wieso nicht C?"

weil Ada gerne in sicherheitskritischen Anwendungen verwendet wird 
(Raumfahrt, Flugzeuge, AKW...)

Autor: Realist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Hmm, also mehrere Programmierer. Wenn beide Fehler
machen ist das Resultat immer noch eine Mischung"

"Mehrere" sind drei. Dann gewinnt die Mehrheit...

Autor: testit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bascom kann das auch rechnen

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Die Diskussion gab es hier schon mal. Knackpunkt ist, das in den USA C 
für sicherheitsrelevante Sachen nicht zugelassen ist.

MfG Spess

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Realist schrieb:
> "Wieso ADA, wieso nicht C?"
>
> weil Ada gerne in sicherheitskritischen Anwendungen verwendet wird
> (Raumfahrt, Flugzeuge, AKW...)

Schon klar.
Fakt ist aber auch, dass nur die Verwendung von Ada alleine noch kein 
sicheres Programm ausmacht.

Ausserdem reden wir hier nicht über Code der aus >200 Modulen und >3 
Millionen Lines of Code besteht :-) Das was der TO vor hat, lässt sich 
noch leicht überschauen.

Die wichtigste Frage ist immer noch: Welche Vorkentnisse hat der TO. Und 
welche Vorkentnisse hat er im Speziellen mit Ada.
Wenn ich sowas programmieren wollte, würde ich auf keinen Fall Ada 
nehmen, ganz einfach deswegen weil ich keine Erfahrung damit habe. Ich 
habe aber jede Menge Erfahrung mit C. Dazu kommt, dass hier in Europa, 
ausser in den bisher genannten Bereichen, meines Wissens kein Mensch Ada 
benutzt. Es ist daher wesentlich schwieriger Hilfestellung von aussen zu 
bekommen.

Autor: Bertram S. (bschall)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So adHoc: MSP430, genügend I/O Analoge Peripherie und die Rechenleistung 
is so wie so kein Thema! MSp fällt mir ein wegen dem Stromverbrauch.
Dazu ein passendes LCD... da gibts doch auch was... mal nachsehen...
Druck Temperatursensorkombi: MS5541 oder ähnliches (intersema)...

Was den Kompiler anbelangt... gute Frage

Autor: Frank B. (frankman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Bezüglich Rechenleistung sehe ich keinerlei Anforderungen. Jeder
> 8-Bitter sollte es wuppen.
> Warscheinlich verbraucht das GLCD die meiste Rechenpower.

Das sehe ich absolut anders:

Zu den Sensoren:

1. Sensor mit ADC erfassen
2. Digitales Filter
3. Mittelwertbildung
4. Berechnen der physikalischen Größe
5. Analyse, ob Sensor Daten plausibel sind.
6. Kalibrierung der Sensoren
7. Überwachung, ob Kalibrierung wirklich stimmt
8. Überwachung der Sensoren auf richtige Funktion

Zu der Berechnung des Atemgases:
1. Berechnung der Gasmenge in Abhängigkeit von der Temperatur--> riesige 
Look-Up-Tables
2. Plausiblitätsprüfung

Zum yC Selbsttest:

Zyklischer Selbsttest, d.h. alle Fehler, die einen gefährlichen Zustand 
herbeiführen können, müssen überwacht werden.
1. Speichertest
2. Über- und Unterspannung vom Prozessor muß erkannt werden, die 
Überwachungsschaltung muß ebenfalls auf Funktion geprüft werden
3. Watchdog vom Prozessor muß vorhanden sein und ebenfalls überwacht 
werden


Zum GLCD:
Verschiedene Schriften  --> viel Speicher
Verschidene Knöpfe , Slider, Anzeigen ---> Viel Speicher


Dazu kommt dann noch die doppelte Redundanz--> Zwei unterschidliche 
Prozessoren verweden, die mit unterschiedlichen Compilern programmiert 
wurden, um zu vermeiden, das ein Compilerfehler bei beiden Systemen den 
selben Fehler herbeiführt.( Am besten ebenfalls von zwei 
unterschiedlichen Entwicklern)


Also:
yC mit DSP-Funktionen
yC mit viel Rechenleistung (32bit, mit Floating Point Funktionen)
yC mit viel Speicher


Ich würde das Pferd von hinten aufzäumen und gleich den Prozessor mit 
maximalen Speicher und Rechenleistung verwenden.
Wenn mann dann später merkt oder absehen kann, das das etwas zu viel des 
Guten war, kann mann immer noch für die Serie auf einen kleineren Typ 
umsteigen. Wenn mann allerdings mitten im Design feststellt, das die 
Recourcen nicht reichen, fängt man wieder von Null an.


Ich würde warscheinlich einen DsPic32 einsetzen....oder etwas von 
Renesas

Autor: Frank B. (frankman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> Redundanz ist gut. Aber tu dir das Prozedere mit mehreren Prozessoren,
> die sich gegenseitig überwachen nicht an. Ein Watchdog im Prozessor
> aktiviert, nur zur Sicherheit, und gut ists. Diese Dinger mit
> Backup-system und dergleichen klingen zwar gut, sind aber der absolute
> Horror.


Sorry, auch hier muss ich wiedersprechen:

Ein Taucher in 30m tiefe ist absolut von seinem Atemgas abhängig:
Ein Fehler ist hier absolut tötlich!
Deshalb ist dieses Gerät als "Lebenserhaltend" einzustufen.

Ich würde hier auf jeden Fall die Medizinnorm 60601 ansetzen und das 
Gerät als "Klasse 3 " Gerät einstufen.

Um es kurz zu machen:

Das Gerät muß in einen "Sicheren Zustand" gehen, wenn ein Fehler, egal 
welcher Art, auftritt.
(Das gilt für den "ersten" Fehler.
Jeder Fehler, der einen " gefährlichen Zustand" führen kann, muß erkannt 
werden und mit einer geeigneten Maßnahmen verhindert werden.
Wird vermutet, das ein Fehler nicht erkannt wird, so muß das System auch 
bei Auftreten des zweiten Fehlers in den sicheren Zustand gehen.
--> Dabei gilt natürlich wieder Regel eins

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard R. schrieb:
> Uwe Heydemann schrieb:
>> Atemgas-Zusammensetzung
>   Atmegas
> passen da am besten :-)
>
> Sorry, den konnte ich mir nicht verkneifen.
>
> Reinhard

Dank Forum Kontext hab ich auch erst mal Atmegas gelesen :-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank B. schrieb:
> Karl heinz Buchegger schrieb:
>
>> Redundanz ist gut. Aber tu dir das Prozedere mit mehreren Prozessoren,
>> die sich gegenseitig überwachen nicht an. Ein Watchdog im Prozessor
>> aktiviert, nur zur Sicherheit, und gut ists. Diese Dinger mit
>> Backup-system und dergleichen klingen zwar gut, sind aber der absolute
>> Horror.
>
>
> Sorry, auch hier muss ich wiedersprechen:
>
> Ein Taucher in 30m tiefe ist absolut von seinem Atemgas abhängig:
> Ein Fehler ist hier absolut tötlich!
> Deshalb ist dieses Gerät als "Lebenserhaltend" einzustufen.

Bis hier her sind wir uns einig.

Worum es mir geht:
Es sagt sich leicht: na da bauen wir halt ein Mehrprozessorsystem, am 
besten noch mit unterschiedlichen Prozssoren. Im Space SHuttle haben sie 
es ja auch so gemacht.

Aber die Praxis ist nun mal schwieriger als die Theorie. Auf dem 
Pflichtenheft kann ich das leicht hinschreiben.

Ein derartiges System ist nun mal komplexer und zwar um einiges 
komplexer als ein simples Ein-Prozessorsystem. Dazu die Fragestellung: 
Wer überwacht eigentlich die Überwacher? (Und damit hast du wieder einen 
Single-Point of Failure)
Und Hand aufs Herz: Wer von uns hat schon erlebt, dass ein AVR (um jetzt 
nur einen bestimmten µC zu benennen) im Betrieb bei sachgemäßem Layout 
und Platinenfertigung einfach so aussteigt. Bei meinen hab ich das noch 
nie beobachtet. Auch hat sich ein AVR aus heiterem Himmel noch nie 
verrechnet (es sei denn ich habe bei der Programmierung einen Fehler 
gemacht).

Nochmal: Überwachung ist gut. Das man das Rechenergebnis auf 
Plausibilität überprüft ist auch gut. Das man bei derartig 
sicherheitskritischen Anwendungen jeden Arrayzugriff auf 
Bereichüberschreitung prüft sollte auch selbstverständlich sein. Das man 
hierbei nicht auf Speed sondern möglichst defensiv arbeitet ist auch 
normal. Dass jede Schleife einen zusätzlichen Counter bekommt, der einen 
Überlauf detektiert, wenn die eigentliche Schleifenbedingung 'nie' 
einzutreten scheint (und daher zb ein Hardwaredefekt vermutet werden 
kann) ist auch gut.

Aber ich bin der Meinung, dass man die Hardware so einfach wie nur 
möglich machen sollte. Ein Mehrprozessorsystem, die parallel laufen und 
bei der es einen Entscheidungsträger gibt, ist für mich nicht einfach. 
Einfaches System - einfache Fehler, komplexes System - komplexe Fehler.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleine Anmerkung zu ADA <-> Ada erzwingt programming by contract wenn 
ich mich da richtig erinnere, d.h. ich MUSS mit assertions arbeiten, was 
natürlich hilft fehlerhafte Werte immer zu erkennen, nur:

Echtes ADA hat noralerweise einen Garbage Collector (ok, man kann den 
auch abschalten) und Ada, das vom DoD anerkannt wird und wirklich für 
Sicherheitskritische Anwendungen zugelassen ist braucht einen Compiler 
der zertifiziert ist, was ich bei einem sourceforge compiler bezweifle.

Ich denke C ist auf jeden Fall ok, aber eben mit der gleichen Sorgfalt 
programmieren wie Ada, d.h. genug testfälle einbauen und die hinweise 
von oben beachten.

Eventuell würde ich für das Display einen getrennten µC verwenden um 
kritische Anwendung vom UI zu trennen, so dass ein Fehler im UI, wird 
schließlich von einem USER bedient, (daher nicht alle zustände 
vorhersehbar), nicht die lebenswichtigen funktionen beeinträchtigen 
kann.

Möglicherweise wäre auch ein xScale prozessor ne Lösung, da bereits 
eingebaute Grafikinterface und genug rechenpower, eventuell mit nem 
8-Bitter mombiniert zur Fehlerüberwachung und falls notwenig reset des 
xScale. (ist aber nur so ne idee die mir gerade kommt)

Gruß
Tom

Autor: Frank B. (frankman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und Hand aufs Herz: Wer von uns hat schon erlebt, dass ein AVR (um jetzt
> nur einen bestimmten µC zu benennen) im Betrieb bei sachgemäßem Layout
> und Platinenfertigung einfach so aussteigt. Bei meinen hab ich das noch
> nie beobachtet. Auch hat sich ein AVR aus heiterem Himmel noch nie
> verrechnet (es sei denn ich habe bei der Programmierung einen Fehler
> gemacht).


Da stimme ich auf jeden Fall zu, solange das "Werk" nur für den einen 
selbst ist. Soll das Gerät zugelassen werden, kommt der TÜV, die CE, die 
UL, die FDA und noch zehn weitere "Institute", die das leider völlig 
anders sehen.

Wie wirds also gemacht:
Ein System, welches das Gerät steuert.--> Prozessor eins
- also einsammeln der Sensor-Werte.
- GLCD
- Berechnung der Gasmengen,  und was weiss ich noch alles
- Macht beim Einschalten einen Displaytest
- Macht beim Einschalten einen Test der Alarmgeber (Pipser, LED)
- Gibt Alarm aus, wenn ein Fehler auftritt

Ein System, welches das Gerät überwacht--> Prozessor zwei.
- Überwacht System auf Über-und Unterspannung
- Überwacht den Watchdog und Reset-Baustein
- Prüft zyklisch die Sensoren auf richtige Funktion
- Prüft zyklisch den "Gas-blender" auf richtige Funktion
- Läßt den ersten Prozessor zyklisch einen Speichertest machen
- Prüft, ob beim Einschalten Knöpfe Klemmen
- Überwacht ggv. Schutzschaltungen die Über und Unterspannung 
detektieren. bzw. Prüft diese zyklisch.
- Überwacht und prüft, ob Alarmgeber richtig funktionieren.
- Stellt sicher, das das System bei einem Hardware-Fehler in den 
sicheren Zustand geht.
- Gibt Alarm aus, wenn ein Hardware-Fehler auftritt.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:

>Die Diskussion gab es hier schon mal. Knackpunkt ist, das in den USA C
>für sicherheitsrelevante Sachen nicht zugelassen ist.

Ich würde mal sagen, wer in den USA solch ein Gerät auf den Markt 
bringt, mit dem vom Threadersteller bisher gezeigten Kenntnissstand, 
kann das auch in C programmieren. Da kommt es dann auch nicht mehr drauf 
an.

Uwe Heydemann schrieb
>Hallo :-) Ich bin auf der Suche nach einem passenden Controller fuer
>mein Projekt und komm nicht so recht mit der Suche weiter. Es gibt ja
>bald mehr verschiedene Controller als Woerter im Duden :-)

Du stellst für solch ein Projekt einfach die falschen Fragen.

Die Sache ist normalerweise ganz einfach: Für sowas nimmt man den 
Prozessor, auf dem man schon jahrelange Erfahrung in Dutzenden von 
sicherheitskritschen Projekten gesammelt hat, von dem man die Errata 
auswendig kennt und automatisch im Schlaf daraus entstehenden Fallen 
umschifft, und der sich in solchen sicherheitskritischen Anwendungen 
bewährt hat und zugelassen ist.

Oliver

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank B. schrieb:
> 1. Sensor mit ADC erfassen
> 2. Digitales Filter
> 3. Mittelwertbildung
> 4. Berechnen der physikalischen Größe
> 5. Analyse, ob Sensor Daten plausibel sind.
> 6. Kalibrierung der Sensoren
> 7. Überwachung, ob Kalibrierung wirklich stimmt
> 8. Überwachung der Sensoren auf richtige Funktion

Schön und gut, aber wo wird hier Rechenleistung benötigt?
Der Mensch macht doch keine 10.000 Atemzüge pro Sekunde.
Das ist alles vollkommen schnarchlahm aus CPU-Sicht.


> 1. Berechnung der Gasmenge in Abhängigkeit von der Temperatur--> riesige
> Look-Up-Tables

Du brauchst das Atemgas nicht auf 0,0001% genau zu berechnen.
Ganz abgesehen von der Genauigkeit der Sensoren.
1% sollte reichen, d.h. ne Lookup-Table hat max 100 Einträge.
Wenn es ne Formel gibt würde ich aber lieber rechnen, damit die CPU sich 
nicht gar so langweilt.


> Zyklischer Selbsttest, d.h. alle Fehler, die einen gefährlichen Zustand
> herbeiführen können, müssen überwacht werden.
> 1. Speichertest
> 2. Über- und Unterspannung vom Prozessor muß erkannt werden, die
> Überwachungsschaltung muß ebenfalls auf Funktion geprüft werden
> 3. Watchdog vom Prozessor muß vorhanden sein und ebenfalls überwacht
> werden

Auch dazu sagt ein 8-Bitter nur: Gääähn


> Zum GLCD:
> Verschiedene Schriften  --> viel Speicher

LOL, das ist natürlich das wichtigste.
In großen Tiefen ist die Warnehmung eingeschränkt, da hat Lesbarkeit die 
absolute Priorität, Gimmicks sind tabu!
Abgesehen davon, in die 256kB des ATmega2561 passen ne Menge Schriften 
rein.


> Verschidene Knöpfe , Slider, Anzeigen ---> Viel Speicher

Du bist bestimmt Windows-Programmierer, daß Du denkst, Bedienelemente 
sind speicherhungrig.
Du willst bestimmt auch unter Wasser alles über nen Touchscreen 
bedienen.
Das würde ich dann als lebensgefährlich bezeichnen.


> Dazu kommt dann noch die doppelte Redundanz--> Zwei unterschidliche
> Prozessoren verweden, die mit unterschiedlichen Compilern programmiert
> wurden, um zu vermeiden, das ein Compilerfehler bei beiden Systemen den
> selben Fehler herbeiführt.( Am besten ebenfalls von zwei
> unterschiedlichen Entwicklern)

Glaubst Du wirklich, der TO will sich >100k€ Entwicklungskosten ans Bein 
binden?


> Also:
> yC mit DSP-Funktionen
> yC mit viel Rechenleistung (32bit, mit Floating Point Funktionen)
> yC mit viel Speicher

LOL.
Und nochmal LOL.

Du mußt Windows-Programmierer sein, anders ist diese maßlose 
Übertreibung nicht zu erklären.


> Ich würde warscheinlich einen DsPic32 einsetzen....oder etwas von
> Renesas

Aber bloß nicht nen Chip, der massenhaft eingesetzt wird. Könnte ja 
sonst sein, man kriegt zu leicht Hilfe bei Problemen.


Peter

Autor: micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Uwe!

Du hast Dich ja schon gut informiert und scheinst ja etwas Background zu 
haben. Solange es "nur" für Dich ist, ist etwas Interesse+Basetlwut 
schon OK :-) Ich würde aber trotzdem mit dem was Du machst vorsichtig 
sein.

Für ein gut funktionierendes Greät musst Du Dir z.B. auch Gedanken zur 
Stömung innerhalb des Systems machen. Wenn z.B. der Kalkbehälter nicht 
richtig durchströmt wird, könnte es sein, dass dort eine lokale 
Sättigung auftritt und dann gibts Probleme. Nimm am besten Teile von 
vorhandenen Kisten und nicht einfach einen leeren Marmeladeneimer ;-) 
IMHO bekommt man von Dräger sehr Vieles als Erstzteil. Bzgl. der 
Programmiersprache (ADA<>C), macht ADA auf einem (kleinen) µC wenig aus 
bzw. bringt wenig Sicherheitsgewinn. Ich würde jetzt auch eher C nehmen. 
Redundanz hast Du ja schon angesprochen (2-3 unabh. Einheiten + 
Supervisor). Welches Deko-Modell und Lösungschema Peter verwendet weiss 
ich nicht, aber dass kann man ja auch "trocken" testen.

Ist insgesamt sicher ein spannendes Projekt -aber wenn Du allein bist 
und dich auch noch in Elektornik+µC einarbeiten willst, mach Dich auf 
viel Frust+hohen Zeitaufwand gefasst. Mit einem Inspiration könntest Du 
gleich Druck auf der Birne haben ;-)

Autor: Frank501 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Oh Mann, nimm einfach C und gut ist, Ada rettet dir auch nicht den
>Hintern wenn du was vermurkst.

>Nichts gegen ADA, aber wie heist es so schön: Man kann in jeder Sprache
>Fortran Programme schreiben.
>
>Wer sein Handwerk beherrscht kann in C genauso sichere Programme
>schreiben wie in ADA.

Bloß weil jeder C verwendet heißt es noch lange nicht, das es auch das 
Gelbe vom Ei ist. Fakt ist : es gibt für viele Anwendungen bessere 
Sprachen als C, die nur kaum jemand verwendet. Womit wir wieder bei den 
millionen Fliegen wären.
Ich habe nichts gegen C wo es angebracht ist, tue es mir aber selber nur 
an, wenn es nicht anders geht.


>Redundanz ist gut. Aber tu dir das Prozedere mit mehreren Prozessoren,
>die sich gegenseitig überwachen nicht an. Ein Watchdog im Prozessor
>aktiviert, nur zur Sicherheit, und gut ists.

>Denn die beste Sprache ist immer die, die man schon
>beherrscht. ADA hin oder her!

Andere Sprachen kann man erlernen und sich darin einarbeiten,genau so, 
wie man irgend wann einmal C oder auch seine Muttersprache gelernt hat.
Ich hoffe nur, das Leute mit so einer Meinung keine AKW's oder 
lebenserhaltende Systeme die auf der Intensivstation stehen entwickeln 
dürfen...
Denn das Endergebnis, egal wie komplex ein System ist, an dem Leben 
hängen (ob eines oder tausende ist egal) ist das selbe : es gibt kein 
75% tot, sondern nur 100% oder 0%.



>Ein Taucher in 30m tiefe ist absolut von seinem Atemgas abhängig:
>Ein Fehler ist hier absolut tötlich!
>Deshalb ist dieses Gerät als "Lebenserhaltend" einzustufen.
>
>Ich würde hier auf jeden Fall die Medizinnorm 60601 ansetzen und das
>Gerät als "Klasse 3 " Gerät einstufen.

dem Stimme ich voll und ganz zu. Egal, ob es ein "simpler" Tauchcomputer 
ist oder eine komplexere Anwendung. Sicherheit geht in einem solchen 
Fall vor.



>Es sagt sich leicht: na da bauen wir halt ein Mehrprozessorsystem, am
>besten noch mit unterschiedlichen Prozssoren. Im Space SHuttle haben sie
>es ja auch so gemacht.
>
>Aber die Praxis ist nun mal schwieriger als die Theorie. Auf dem
>Pflichtenheft kann ich das leicht hinschreiben.

>Dazu die Fragestellung:
>Wer überwacht eigentlich die Überwacher? (Und damit hast du wieder einen
>Single-Point of Failure)

Das es leicht ist, hat ja niemand behauptet.
z.B. Dreifache Redundanz lässt sich aber relativ einfach erreichen indem 
man die Ausgänge hardwaremäßig so verknüpft, daß mindestens 2 den selben 
Wert haben müssen, um eine Aktion herbei zu führen, da gibt es 
niemanden, der die anderen überwachen muß.
Wenn man das dann noch zusätzlich in Software implementiert, so daß 
jeder sein Ergebnis mit denen der anderen vergleicht und Abweichungen an 
die anderen meldet, überwachen sich die Überwacher gegenseitig.



>...Auch hat sich ein AVR aus heiterem Himmel noch nie
>verrechnet (es sei denn ich habe bei der Programmierung einen Fehler
>gemacht).

Und um genau das abzufangen gibt es diversität.
Und mal ehrlich, wer kann von sich selbst behaupten, daß er in einem 
Programm, welches über das "Hallo Welt" hinaus geht, keinen Fehler 
eingebaut hat?
Ich nicht. Ich weiß, daß in mindestens jedem 2ten Programm, welches ich 
schreibe, ein Fehler drinne ist, den ich wegen Betriebsblindheit 
übersehe, der aber vermutlich nur in 1/100% aller Fälle zum tragen 
kommen wird.
Würde ich meine Programme anderen zum überprüfen geben, was ich nicht 
tue, weil ich "nur" hobbymäßig programmiere, würden mit sicherheit 
einige Fehler ans Tageslicht kommen.

Frank

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank501 schrieb:

>>...Auch hat sich ein AVR aus heiterem Himmel noch nie
>>verrechnet (es sei denn ich habe bei der Programmierung einen Fehler
>>gemacht).
>
> Und um genau das abzufangen gibt es diversität.

Nur, das hilft dir nichts, wenn alle 3 Prozessoren dasselbe Programm 
abarbeiten. Alle 3 Prozessoren durchlaufen dann denselben 
Programmfehler. Deine hochgelobte Redundanz durch mehrere Prozessoren 
ist nichts anderes als ein Selbstbelügen. Du gewinnst dadurch nicht mehr 
Sicherheit. Stecke die Arbeit lieber in einen einzigen Prozessor (oder 
in 2 Prozessoren, die eine strikte Aufgabentrennung haben, wie weiter 
oben von Frank vorgeschlagen), da haben alle mehr davon.

Jede einzelne Berechnung muss untersucht werden, ob es eine Möglichkeit 
für einen Overflow gibt und entsprechende Tests im Programm gemacht 
werden. Das ist in Summe viel sicherer, als nach Redundanz durch mehrere 
parallel am selben problem arbeitende Prozessoren zu schreien.

Um es einmal ins Absurde zu treiben:
Angenommen man hätte irgendwo ein Relais. Nun kann dieses Relais 
ausfallen, die Kontakte können kleben, die Spule kann durchbrennen, die 
Kontakte können abbrennen. Also schaltet man nach dem Relais noch einen 
Sensor, der feststellt ob das Relais geschaltet hat. Soweit so gut. 
Dagegen hat niemand was.
Aber jetzt kommts. Um absolut sicher zu gehen, schaltet man zum Realis 
noch ein weiteres parallel und dahinter dann noch eines, welches 
umgeschaltet wird, wenn das erste ausfällt und so dem ersten Relais die 
Kompetenz entzieht. Natürlich alle mit den entsprechenden Sensoren um 
festzustellen, ob es auch wirklich geschaltet hat.
Anstatt einem einzigen popeligen Relais hat man plötzlich 3 im System. 
Aber hat man dadurch auch einen Sicherheitsgewinn? Das ist es was ich 
bezweifle. Wird das einzige Relais von vorneherein gleich richtig auf 
seine Aufgabenstellung ausgewählt (plus eine Sicherheitsmarge), dann 
braucht es diese Redundanz gar nicht. Sie verkompliziert das 
Gesamtsystem nur und öffnet ein neues Loch für neue Fehler, die man ohne 
diesen komplizierten Klapperatismus gar nicht hätte.

> Und mal ehrlich, wer kann von sich selbst behaupten, daß er in einem
> Programm, welches über das "Hallo Welt" hinaus geht, keinen Fehler
> eingebaut hat?

Das kommt auf das Programm an. Ein Hallo Welt ist natürlich extrem. Aber 
wenn du die Aufgabenstellung im Geiste einmal durchgehst, dann stellst 
du fest, dass von den schwierigeren Dingen, die im wesentlichen alle mit 
dynamischer Speicherallokierung zu tun haben, nichts gebraucht wird. Das 
ist alles mit statischer Allokierung zu machen. Im wesentlichen geht es 
darum Sensorwerte zu holen, die aufgrund von vorgegebenen Formeln 
miteinander zu verknüpfen und mit dem Rechenergebnis Ventile 
anzusteuern. Wenn die Formeln stimmen und so implementiert sind, dass es 
zu keinen Überläufen kommen kann und auch die Charakteristik von 
Gleitkommerechnungen auf einem Computer berücksichtigt werden, dann kann 
es hier zu keinem Fehler kommen. In so einem Gerät berechnet der 
Computer nicht 2 Millionen mal eine Formel mit immer denselben 
Eingangswerten richtig und beim 2 Millionen und erstem mal verrechnet er 
sich.

Wenn ich auf Nummer sicher gehen will, dann gebe ich den kritischen Code 
zu 3 oder 4 anderen Leuten um einen Code-Review zu machen.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na das mit den mehreren Controllern macht natürlich nur dann Sinn wenn 
darauf programme von verschiedenen Entwicklern mit der selben 
Funktionalität laufen, wie schon oben erwähnt, da geht es ja nicht nur 
um Hardwareredundanz.

Gruß
Tom

Autor: micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stichwort Redundanz: optimal sind natürlich verschiedene System mit 
unabhängigen Implementierungen um sich vor Software-Fehler zu schützen.

In diesem Fall geht es aber eher darum bei einem Hardware-Fehler/Unfall 
(z.B. Wassereinbruch ins Gehäuse, Abreissen einer Verbindung etc.) noch 
ein einigermassen sichers Austauchen zu ermöglichen. Dann kann man 
durchaus (auch im Sinne der Kosten) auf ein zweites, identisches 
Sicherheitssystem setzen. Insgesamt ist die Komplexität vergleichsweise 
gering und die Korrektheit der Implementierung (nicht der Sensordaten, 
das ist eine andere Geschichte) lässt sich IMHO sehr gut validieren.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es werden hier unnütze Überlegungen angestellt, als ginge es um ein AKW.
Der TO will doch kein kommerzielles Produkt herstellen, sondern nur 
basteln.

Mit etwas gesunden Menschenverstand geht das auch ohne großes Risiko und 
ganz ohne Sicherheits-Hokuspokus.

Es passiert ja auch mit normalen Atemreglern, daß die ausfallen. Und 
dann wird eben mit der Reserveflasche geatmet oder abwechselnd mit dem 
Tauchpartner.

Es muß also keiner gleich tot umfallen, wenn man mal beim Programmieren 
ein Bit falsch gesetzt hat.


Man könnte natürlich den Atemregler als extra MC realisieren (z.B. 
ATtiny25) und sich bei dessen Programmierung besondere Mühe geben.
Und beim Dekompressionsrechner reicht ne LED, um Steigen oder Halten 
anzuzeigen.

Und dann kann man sich beim MC für den Grafik-Schrunz richtig austoben, 
schlimmstenfalls wird Unsinn angezeigt. Aber er hat keinerlei Einfluß 
auf Lebensfunktionen.


Peter

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es passiert ja auch mit normalen Atemreglern, daß die ausfallen. Und
> dann wird eben mit der Reserveflasche geatmet oder abwechselnd mit dem
> Tauchpartner.
leider merkt der Taucher es nicht, wenn ihm 100% Sauerstoff zugeführt 
wird. Er wird einfach Ohnmächtig

Autor: Theo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich würde einen PicAxe08M empfehlen. Der kann alles.
Gruß Theo

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu ADA und den Schwächen gabs mal ein paar Kurzgeschichten in der ct:

http://www.josella-simone-playton.com/pragma_i.html

http://www.herwig-huener.homepage.t-online.de/t-on...

Autor: micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> leider merkt der Taucher es nicht, wenn ihm 100% Sauerstoff zugeführt
>> wird. Er wird einfach Ohnmächtig

Na ja, 100% O2 ist kein Problem wenn der ppO2 nicht zu hoch (IMHO < 1.5 
bar) und und die Zeit nicht zu lang ist. Ausserdem wird in einem 
Rebreather in der Regel kein 100% Sauerstoff zirkulieren (der Witz beim 
Slebstmischer dass nur der verbrauchte Sauerstoff wieder aufgefüllt 
wird. Das dabei entstehnde CO2 wird im Atemkalk gebunden). D.h. es gibt 
ein Inertgas (Stickstoff/Helium...) Effekte einer Sauerstoffvergiftung 
treten AFAIK auch nicht plötzlich Ohnmachtsanfallmässig auf sondern 
kündigen sich an. Aber das ist Off-Topic...)

Autor: Uwe Heydemann (uwe1981)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal danke fuer die vielen Antworten :-) Zu den hier gestellten 
Fragen:

Ich baue kein Seriengeraet sondern ein Geraet allein fuer mich. Es 
handelt sich immer noch nur um ein Tauchgeraet, nicht um ein AKW und 
nicht um ein Waffenkontrollsystem zur U-Boot-Abwehr lach Die Sprache 
Ada beherrsche ich groesstenteils, habe aber zusaetzlichen noch einen 
guten Kollegen, der sie perfekt beherrscht. Ada hat hervorragende 
Moeglichkeiten zur Selbstanalyse und Prozessueberwachung, die bei C nur 
eingeschraenkt oder mit hoeherem Umfang moeglich sind.

Kurzes Statement zu den Leuten hier, die offensichtlich Ahnung von 
Rebreathertechnik haben: Ich tauche seit 7 Jahren mindestens 80-120 mal 
jaehrlich Kaltwasser, habe alle Scheine bis Full-Trimix OpenCirciut + 
Inspiration-Lizenz fuer Trimix. Mein Eigenbau-Rebreather ist kein 
Marmeladeneimer mit Gartenschlauch :-) Ich hab sehr viel Zeit und 
Energie reingesteckt (mal abgesehen vom Geld) und kann behaupten, das 
jedes Einzelteil knueppelhartem Industriestandard entspricht und 
mindestens 2mal mehr Beanspruchung aushaelt, als im Normalgebrauch je 
auftreten wird.

Unter Redundanz verstehe ich nicht drei Prozessoren, die sich 
gegenseitig ueberwachen. Weil, wie bereits gesagt, wurden alle drei den 
selben Programmfehler lesen und umsetzen.
Redundanz erzeuge ich durch zwei voellig autonom arbeitende Controller, 
sprich das komplette Steuersystem ist zweimal vorhanden. Einzig und 
allein die Sensoren und die Energieversorgung werden gemeinsam benutzt. 
Und die sind mehrfach gegen Wassereinbruch durch Doppelwandung und einer 
Art Entwaesserungspumpe geschuetzt, die bei Wassereinbruch das Wasser 
wieder rausbefoerdert und das Innenleben trocken haelt.
Eine dritte Redundanz ist die Moeglichkeit, die Gaszufuhr zum elektr. 
Steuersystem mittels Sperrventil komplett stillzulegen und das komplette 
System per Handbetrieb ueber Nadel- und Impulsventil zu steuern, um bei 
einem Totalausfall sicher austauchen zu koennen.
Vierte Redundanz waere dann immer noch der Atemregler, um Gas direkt aus 
der Flasche zu atmen.

Reichen vier Redundanzen aus? Halt, die wichtigste hab ich vergessen: 
Nr. 5 ist mein Tauchpartner, der neben mir taucht und mir jederzeit 
seinen Zweitregler zur Verfuegung stellt.

So, zurueck zum Thema. Das MSP430 hab ich auch bereits ins Auge gefasst. 
Wie siehts da mit der Moeglichkeit eines farbigen, grafischen Displays 
aus, welches auch ein paar optische Anzeigen in Form von Manometern oder 
Balken enthalten soll? Wird das nicht ein bisschen eng mit der 
Rechenleistung?

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe Heydemann schrieb:

> Wie siehts da mit der Moeglichkeit eines farbigen, grafischen Displays
> aus, welches auch ein paar optische Anzeigen in Form von Manometern oder
> Balken enthalten soll? Wird das nicht ein bisschen eng mit der
> Rechenleistung?

Wenn es Dir darum geht, dass check doch mal Prozessoren der 
xScale-Familie nur dür das Display und Bedienelemente. Das sind die 
selben Prozessoren die in vielen Handhelds drin sind. Da kannst Du 
Grafisch alles mit machen.

Gruß
Tom

Autor: Frank501 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>abarbeiten. Alle 3 Prozessoren durchlaufen dann denselben
>Programmfehler. Deine hochgelobte Redundanz durch mehrere Prozessoren
>ist nichts anderes als ein Selbstbelügen.

Genau deshalb sollen ja auch alle Prozessoren ein anderes Programm 
durchlaufen, welches nur die selben Informationen bekommt, wie die 
anderen und die selben Ergebnisse liefern soll. Also von verschiedenen 
Programmierern auf verschiedenen systemen mit verschiedenen Compilern 
erzeugt werden, damit eben NICHT der selbe Fehler zum tragen kommen 
kann.

"Das Wort Diversität bedeutet Vielfalt oder Verschiedenheit."


>Jede einzelne Berechnung muss untersucht werden, ob es eine Möglichkeit
>für einen Overflow gibt und entsprechende Tests im Programm gemacht
>werden.

Richtig. Egal, ob es nur einer oder mehrere Prozessoren sind, die an 
einer Aufgabe arbeiten.


>Das ist in Summe viel sicherer, als nach Redundanz durch mehrere
>parallel am selben problem arbeitende Prozessoren zu schreien.

Nur, wenn jemand 100%ig dafür garantieren kann, daß sich nicht doch ein 
Fehler eingeschlichen hat. Und wer kann das? Wer ehrlich zu sich selbst 
ist, wird das nicht tun.

>Wird das einzige Relais von vorneherein gleich richtig auf
>seine Aufgabenstellung ausgewählt (plus eine Sicherheitsmarge), dann
>braucht es diese Redundanz gar nicht. Sie verkompliziert das
>Gesamtsystem nur und öffnet ein neues Loch für neue Fehler, die man ohne
>diesen komplizierten Klapperatismus gar nicht hätte.

[ironie]
Also werfen wir alle Not-Aus Relais, Zweihandrelais, Überwachungsrelais 
und für sicherheitsrelevante aufgaben zertifizierte Steuerungen aus dem 
Lieferprogramm der Distributoren und setzen statdessen bei allen 
Kontaktgebenden Elementen wie Endschalter, Not-Aus Taster usw. dicke 
Kontakte mit einer Nennspannung von 1000V und einem Nennstrom von >50A 
ein und steuern Pressenanlegen, Walzwerke, Schweißroboter usw. durch 
Schütztechnik von vor 25 Jahren und niemandem kann etwas passieren...
[/ironie]



>Im wesentlichen geht es
>darum Sensorwerte zu holen, die aufgrund von vorgegebenen Formeln
>miteinander zu verknüpfen und mit dem Rechenergebnis Ventile
>anzusteuern. Wenn die Formeln stimmen und so implementiert sind, dass es
>zu keinen Überläufen kommen kann und auch die Charakteristik von
>Gleitkommerechnungen auf einem Computer berücksichtigt werden, dann kann
>es hier zu keinem Fehler kommen.

Richtig, es kann zu keinem Fehler kommen, WENN die Formeln richtig sind 
und auch richtig implementiert wurden.


>In so einem Gerät berechnet der
>Computer nicht 2 Millionen mal eine Formel mit immer denselben
>Eingangswerten richtig und beim 2 Millionen und erstem mal verrechnet er
>sich.

Das kann man nur beweisen, wenn man die Formel mit allen möglichen, und 
nicht nur den wahrscheinlichen werten füttert und das Ergebnis mit dem 
gewünschten vergleicht.

Frank

Autor: Leser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ihr redet alle von Sicherheit und ADA, wie wäre es mit SafeRTOS ? 
http://www.safertos.com
A fully pre-certified 'off-the-shelf' kernel used in Medical, Aerospace, and Industrial applications do reduce risk and shorten time to market.

Ist meines Wissens auch in C geschrieben, wenn nicht bitte mich 
korrigieren.
Ein Ableger davon wäre ja FreeRTOS bzw. OpenRTOS.

Klar geht es beim obigen Thema um die zu verwendete Programmiersprache, 
möchte dies aber trotzdem mal ins Spiel bringen.

P.s.: Ja ich weiß, der Beitrag ist schon etwas her...

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.