Elektronik, diesmal gusseisern

Nein, nicht wenn der Code exakt zur Spezifikation paßt. Und ja, dazu gehört auch die Spezifikation der möglichen Eingabedaten sowie der korrekte Umgang mit ungültigen Eingabedaten.

Sehr vereinfachend formuliert muß die vollständige Spezifikation zumindest umfassen: - vollständige Beschreibung der gültigen Eingabedaten, sowie Verhalten bei ungültigen Eingabedaten (was durchaus "Notabschaltung" sein kann, sofern so spezifiziert), - vollständige Beschreibung der Aktionen über diese Eingabedaten sowie eventueller Transformationen dieser Daten, - vollständige Beschreibung der gültigen Ausgabedaten, dann kann das Entwicklungssystem nämlich u.a. auch diese Punkte prüfen.

Bei typischen Systemen wird dabei von korrekt arbeitender Hardware ausgegangen (keine kippenden Bits im RAM usw.), aber für extreme Anforderungen kann man sogar mit potentiell fehlerhafter Hardware umgehen. Das ist _nicht_ trivial, aber möglich. Systeme, die sterbende Prozessoren und andere Subsysteme ohne Fehlverhalten überleben können wurden bereits gebaut. Ja, der Aufwand ist typischerweise erheblich.

Man liest sich, Alex.

In article , Frank Buss writes: |> |> Ich brauche mir für einen Beweis ja nicht alle Zustände anzusehen, sondern |> nur nachzuweisen, daß der Zustandsautomat die Spezifikation implementiert.

Nein, eben nicht. Eventuell kann der Zustandsautomat nämlich noch viel mehr, was Du bewußt gar nicht hineinentworfen hast und was auch nicht in Deiner Testabdeckung erscheint.

Mal ein Beispiel aus der Historie: $ENTWICKLER bastelt eine PAL-basierte Steuerung, deren Herz ein Zustandsautomat mit 6 Zuständen ist. Mit dem Chip von $ANDERER_HERSTELLER funktionierte der wunderbar -- dummerweise war der abgekündigt, also kam er zu meinem damaligen Brötchengeber.

Nun stellte er fest, daß das Ding mit unseren Chips in 40% der Fälle toter Mann spielte.

Des Rätsels Lösung: Aufgrund der schnelleren Laufzeiten im neuen Chip nahm dieser auch irgendwelche Glitches mit, so daß der Zustandsautomat in einen der beiden "toten" Zustände fiel.

Beim Test nach Spezifikation ("Signal-Ankunftsrate im 25ns-Raster") fiel das aber nicht auf...

Anderes Ding, was bei uns am Institut als Nebeneffekt einer Dissertation über Korrektheitsbeweise herauskam: $HERSTELLER vertreibt eine Telefonanlage. Herzstück dieser Telefonanlage ist -- mal wieder -- ein Zustandsautomat.

Gemäß Pflichtenheft-Test funktionierte dieser auch und erfüllte alle in ihn gestellte Anforderungen. Dummerweise auch eine weitere, denn unter bestimmten Umständen erschoß sich die Anlage und wollte neu gebootet werden.

Dummerweise gab's nämlich auch hier ein paar zusätzliche Zustände, die sich beim Pflichtenheft-Test nicht zeigten und im Feld dann für viel Spaß sorgten.

Das wurde dann erst bei einer formalen Analyse des Zustandsautomaten erkannt.

Rainer

Hehe, Grundregel für robustes Design: Traue den Eingabedaten nicht. Eine der Standardtechniken im Computersicherheitsbereich nennt sich "Fuzzing" - man bewirft das zu testende System solange mit zufälligen und ggf. bewußt kritisch gestalteten Eingabedaten bis es crasht oder sich anderweitig "interessant" verhält. Die Trefferraten sind erschreckend hoch.

Gute Lösung, aber wohl leider oftmals zu teuer[0] :-(

Man liest sich, Alex. [0] Merke: Es gibt immer jemanden, der es noch ein bisschen billiger und schlechter macht.

Noe, von Windows halte ich qualitativ wenig. Muss es halt benutzen.

Das muss ein System aushalten.

Das muss es auch aushalten. Was wuerde passieren, wenn zufaellig eine Hummel dagegen tachelt?

Hiess bei Fernsehern frueher "Oma Taste", jetzt "Auto-Set".

Nein, aber ich habe ein belgisches Telefon, was wirklich aus Druckguss ist :-)

War mal so frei ;-)

Wenn er soviele Werkzeuge hat, warum schneidet er dann die Elektroden mit einem Schweizer Taschenmesser aus, statt eine vernünftige Schere zu nehmen?

F=FCr Anwendungen in explosionsgef=E4hdeten R=E4umen gabs tats=E4chlich T= elefone in Gu=DFausf=FChrung. Heutzutage aus Glasfaserverst=E4rktes Polyester. D=FCrfte f=FCr dich aber= nix sein ;-) Alternativ w=E4re das doch auch etwas:

Viel Vergn=FCgen ;-)

--=20 mfg hdw

In article , Alexander Schreiber writes: |> |> Falsch.

Komisch, auf die Aussage hin hätte ich nun einen Widerspruch erwartet, stattdessen formulierst Du lediglich meine verkürzte Aussage aus und zeigst einen exemplarischen "Workaround" für das Problem.

Rainer

Ja, eh klar, inzwischen wissen wir das ja :-)

Jau; nur, daß anstelle BOS jetzt der normale Industriearbeiter einzusetzen ist. Vor allem Anlagen in Gießereien oder Schmieden sind schon, äähm, beansprucht.

Ralph.

Bei uns liegt da kein Standard-Setting, sondern die komplette firmware. Das Konzept ist, drei gleichgroße Speicherbereiche zu nutzen. In den ersten kommt die Auslieferfirmware und bleibt da auch, die kann nur überschrieben, wenn man das Ding zerlegt, ein paar Sperren umgeht und per JTAG auf den DSP geht. Die anderen beiden Bereiche sind gleichberechtigt und werden im Wechsel durch die updates beschrieben, die wir an den Kunden ausliefern. Somit ist immer fallback auf die vorherige VErsion bzw. auf die Werksversion möglich. Nach einem upgrade wird der Speicherbereich nur dann gültig markiert, wenn die Prüfsumme stimmt.

Ralph.

Ralph A. Schmid, dk5ras schrieb:

Eine großer Zerlegebetrieb hatte AFAIK regelmäßig Probleme mit den ersten Touchscreen-Generationen, weil die weder Blut noch die gelegentlich etwas ruppige Bedienung durch die Schlachter abkonnten. Nur spritzwassergeschützt kann ja jeder. ;-)

Direkt im "Nahkampfbereich" verbieten sich normalerweise auch jegliche Komponenten, die auf Lüfter angewiesen sind. Spätestens wenn zwischen den Schichten der Hochdruck-Reiniger eingesetzt wird, zeigt sich warum man da keine Luftlöcher in unmittelbarer Nähe möchte...

Gruß Bernd

Naja, wir wissen was du meinst. Aber um dich zu ärgern: Es könnten auch Compiler-Features dazugekommen sein. *gröhl*

- Henry

Ralph A. Schmid, dk5ras schrieb:

"First law of debugging: First hit all the right keys - then hit all the wrong ones."

Hanno

Wir haben nur intern einen Lüfter, der die Luft umwälzt, aber keine Luftlöcher...

Ralph.

Ja, wir haben ja schon nachgedacht, das Ding einfach mit Gummibällen zu bewerfen :-)

Nun ja, das macht zweistellige Centbeträge aus, wenn's hochkommt, dann einen Euro. Egal :-) Die Geräte kosten so viel wie ein Auto, da ist das schon drin.

Wir leben davon, daß es die Anderen zwar ein wenig billiger, aber sehr viel schlechter machen. Die Zweifler kaufen oftmals doppelt, zuerst bei der Konkurrenz, dann doch irgendwann verschämt bei uns, teilweise verschleiernd über Dritte *g*

Ralph.

And then the keys that do not exist.

Ralph.

Joerg schrieb:

Soweit ich das verstanden habe (Hörensagen - Korrekturen willkommen!) war das ein Managementfehler auf anderer Ebene: irgendein Manager hat Features verkauft, die mit den Plänen bis dahin einfach nicht umzusetzen waren (so a la Multimedia an allen Plätzen, irgendwas in der Preislage). Die Kabel waren einfach nicht unterzubringen, umfangreiche Redesigns waren nötig, und das hat dann die bekannten Verzögerungen zur Folge gehabt.

Hanno