Hallo allerseits
Ich bin gerade dabei, einen Mikrocontroller (ATmega2560) im Rahmen eines
Universitätsprojektes auf verschiedene Fehler hin zu untersuchen und wie
man diese softwaremäßig (z.B. mithilfe eins watchdogs) minimieren
kann...
(Es geht um AVR-Mikrocontroller, die in einem mechanischen Systemen
eingesetzt werden sollen, das sehr zuverlässig funktionieren soll, da es
kritischen Umgeungen eingesetzt wird.)
Z.Zt. habe ich hauptsächlich einige analoge Servos und mehrere Joysticks
an den Microcontroller angeschlossen... Besonders Sicherheitskritisch
sind hierbei die Signale zu den Servos.
Da sicherlich auch die Community hier davon profitieren würde, lade ich
zum mitmachen ein...
Ich wäre besonders froh über Vorschläge, und Erfahrungen, was schonmal
"schiefgelaufen" ist (auch simple Sachen, wie Stecker falschrum
einstecken, GND mit VCC verbinden, oder sonstige Kurzschlüsse
ausgelöst.)
Hat schonmal jemand Erfahrungen mit EMV gesammelt? (z.b. daß die PWM
Signale zu den Servos irgendwie verändert wurden)
Vielleicht kann ich auch Tests machen, die ihr euch nicht zurtraut, weil
ihr euren Mikrocontroller damit beschädigen würdet etc etc....
Ich werde meinerseits dann versuchen, möglichst viele Ergebnisse hier zu
posten...
Grüße, Thomas
Thomas wrote:
> Ich bin gerade dabei, einen Mikrocontroller (ATmega2560) im Rahmen eines> Universitätsprojektes auf verschiedene Fehler hin zu untersuchen und wie> man diese softwaremäßig (z.B. mithilfe eins watchdogs) minimieren> kann...
Es ist ein weit verbreiteter Irtumm, daß ein Watchdog ein Gerät
zuverlässiger mache, das ganze Gegenteil ist der Fall.
Insbesondere, wenn der Watchdog schon zu Beginn der Entwicklung
verwendet wird, macht er das System extrem unzuverlässig, da er
sämtliche Fehler im Softwareablauf oder EMV kaschiert.
Wenn es aber darum geht, Fehler in der externen Hardware zu erkennen,
z.B. ob der Motorstrom über eine bestimmte Zeit hinaus zu hoch ist
(Überlast), dann macht man diese Überwachungsprozesse mit den ganz
normalen Timern direkt im Programm in Kombination mit AD-Wandlern.
Die Zuverlässigkeit wird dadurch zwar nicht gesteigert, aber
Folgeschäden (z.B. durchgebrannte Motoren) können verhindert werden.
Und es können Diagnosemeldungen ausgegeben werden.
Wenn überhaupt ein Systemwatchdog verwendet werden soll, dann darf er
erst ganz zum Schluß hinzugefügt werden, nachdem alle Funktionen
einwandfrei laufen.
Ist eine Funktionserweiterung zu entwickeln, muß der Watchdog natürlich
zuerst deaktiviert werden, damit man die dabei gemachten Fehler wieder
erkennen kann.
Peter
Da hat Peter durchaus recht, ähnlich ist es z.B. mit "asserts" in
C-Code. Die macht man für die Release-Version am besten auch nicht raus,
obwohl das vielerorts so praktiziert wird...
Währe wie ein Autohersteller, der die Airbags wieder ausbaut, weil "die
ja auf der Testfahrt auf dem Firmengelände auch nicht gebraucht
wurden"...
Beim Watchdog wäre evtl folgendes Sinnvoll:
Nach dem Reset MCUCR prüfen, wenn vom Watchdog ausgelöst:
Alle Ausgänge in "sicheren" Zustand bringen, und danach in
Endlosschleife gehen, Warnled blinken lassen.
So sieht der Endanwender wenigstens, dass mit seinem Gerät was nicht in
Ordnung ist, und er ihm besser nicht mehr 100%ig vertrauen sollte.
Das hängt ein bischen davon ab, wozu das entwickelte Teil gut ist. Wenn
beim Ausfall einer Steuerung im Winter die Wasserrohre einfrieren, weil
das Modul zwecks Warnung des nicht anwesenden Entwicklers fröhlich
streikend vor sich hinblinkt, dann ist damit niemandem gedient.
Dass Watchdogs Fehler verdecken können stimmt. Aber das ist auch ein
bischen der Sinn der Sache. Denn die Vorstellung, dass man in einem
nicht trivialen Controllersystem innerhalb der Entwicklungsphase
wirklich alle Fehler findet, ist etwas gewagt.
Und dann wären da noch jene Fehler, die man schlecht kontrollieren kann.
Hardwarefehler, Stromunterbrechungen, strunzdämliche Bedienung, ...
Also: Auf das Problem hinweisen ist richtig. Deshalb gleich den Betrieb
einzustellen oft nicht.
Um ein paar "EMV"-Erfahrungen zu sammeln kannst Du mit einem
Piezo-Gasanzünder Hochspannung in Deine Schaltung einkoppeln.
Oder nehme ein Relais ohne Entstörschaltung und schalte den Öffner der
Relais in seine Zuleitung. Dann hast du einen einfachen Störgenerator.
1.Grundsätzliche EMV-Bedingungen einhalten. z.B. Geschirmtes Gehäuse
2.Einkoppelung in die Versorgungsleitungen
3.Einkoppelungen in die I/O-Leitungen die aus dem Gerät herausführen.
Geht was bleibend kaputt >> Hardwareschutz verbessern.
>>>Schutzdioden/Schutzkondensatoren/Varistoren
fällt die Software/Hardware nur während der Störung aus >> Auch
Hardwareschutz verbessern. Störungen "wegfiltern"
"Hängt" sich die Software bleibend auf >> Dann kommt der Watchdog oder
Systemreset.
In EMV-Laboren gibt es dafür spezielle Geräte die das qualitativ und
quantitativ besser können. Wenn Du kein Zugang zu einem EMV-Labor hast
musst Du die Störungen selber erzeugen.
Carsten wrote:
> ACK @ Ernst Bachmann>> "asserts" -> in VB "On Error Goto Next">> für die Basic MitBürger>> Gruß Fred
Naja. Nicht wirklich.
http://de.wikipedia.org/wiki/Assert
ok ok Simon K.
>Durch die Formulierung einer Zusicherung bringt der Entwickler eines >Programms
seine Überzeugung über bestimmte Bedingungen während der Laufzeit >eines Programms
zum Ausdruck und lässt sie Teil des Programms werden. Er >trennt diese
Überzeugungen von den normalen Laufzeitumständen ab und nimmt >diese Bedingungen
als stets wahr an. Abweichungen hiervon werden nicht >regulär behandelt, damit die
Vielzahl möglicher Fälle nicht die Lösung des >Problems vereitelt, denn natürlich
kann es während der Laufzeit eines >Programms dazu kommen, dass 2+2=4 einmal nicht
gilt, z.B. weil Variablen >durch Programmfehler im Betriebssystem überschrieben
wurden.
>Damit unterscheiden sich Zusicherungen von der klassischen Fehlerkontrolle >durch
Kontrollstrukturen oder Ausnahmen (Exceptions), die einen Fehlerfall >als
mögliches Ergebnis einschließen. In einigen Programmiersprachen wurden
>Zusicherungen auf Sprachebene eingebaut, häufig werden sie als Sonderform >der
Ausnahmen verwirklicht.
On Error Goto <Marke>
Carsten
