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
>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;)
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.
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
Uwe Heydemann schrieb:
> Atemgas-Zusammensetzung
Atmegas
passen da am besten :-)
Sorry, den konnte ich mir nicht verkneifen.
Reinhard
> 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
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?).
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
>>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.
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.
>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.
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.
>>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.
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!
"Wieso ADA, wieso nicht C?" weil Ada gerne in sicherheitskritischen Anwendungen verwendet wird (Raumfahrt, Flugzeuge, AKW...)
"Hmm, also mehrere Programmierer. Wenn beide Fehler machen ist das Resultat immer noch eine Mischung" "Mehrere" sind drei. Dann gewinnt die Mehrheit...
Hi Die Diskussion gab es hier schon mal. Knackpunkt ist, das in den USA C für sicherheitsrelevante Sachen nicht zugelassen ist. MfG Spess
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.
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
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
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
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 :-)
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.
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
> 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.
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
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
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 ;-)
>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
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.
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
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.
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
> 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
Hi, ich würde einen PicAxe08M empfehlen. Der kann alles. Gruß Theo
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-online-2-josella/solarpow.html
>> 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...)
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?
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
>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
Ihr redet alle von Sicherheit und ADA, wie wäre es mit SafeRTOS ? http://www.safertos.com
1 | 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...
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.