Was kam zuerst - der Zustand oder ein Übergang?

In der Regel wird im Zustand geprüft, ob ein Ereignis eintritt und dann 
der entsprechende Übergang eingeleitet. Ansonsten verbleibt man im 
Zustand.

So habe ich es jedenfalls immer implementiert.

X,Y,Z  - Eingangsvector, Ausgangsvector, Zustandvector

Z(t+1) <= f(Z(t),X(t)); #Uebergang

Y(t)  <= g(z(t));       #Ausgabe

Das ist schlüssig, allerdings habe ich mehrere Übergänge, die in 
verschiedenen Zuständen auftreten können. Die erforderlichen Prüfungen 
müssten dann mehrfach aufgerufen oder implementiert werden.
Ich werde wohl versuchen, dass die Prüfung in der Übergangsfunktion 
erfolgt. Die wartenden Übergänge werden vom Zustand bestimmt.
Daraus ergibt sich aber auch das Problem, dass das Ziel (der neue 
Zustand) bestimmt werden muss.
Alles eine Frage der Sprache :-(

Die Frage ist an sich interessant, aber man muss doch sehr aufpassen, 
dass man sie präzise formuliert und dabei die Verarbeitungsmodelle von 
finiten Automaten und Prozessor auf passende Weise vergleicht.

Zu den theoretischen Aspekten empfehle ich einige Lektüre zur 
Übersicht.


Die praktische Antwort auf Deine Frage ist kurz so:

1. Es ist möglich und nützlich von einem Ausgangszustand auszugehen, der 
von keiner Bedingung abhängt. Man kann es anders machen, aber es handelt 
sich erst einmal um eine völlig freie Wahl und das führte im 
wesentlichen nur zu einer Variation.

2. In diesem Zustand implementiert man alle "möglichen" Übergänge von 
ihm weg (plus der zu ihm selbst führenden). Die Implementierung sieht 
einfach wie eine Bedingung aus mit einem Kontroll-Statement aus. Also 
ein if in C.

Mehr brauchts nicht.

Denke an die gute alte Daumenregel: So einfach wie möglich und so 
kompliziert wie nötig.

N.A. schrieb:

> Implementierung eines Endlichen Automaten: wie wird ein
> Übergang ausgelöst,

Durch ein Eingangssignal ("Ereignis").

> und wo wird er erfasst?

Der Übergang? I.d.R. nirgendwo.
Der Zustand? In der Zustandsvariablen.

Man kann bei Bedarf den Übergang identifizieren, indem man
eine zusätzliche Variable für den vorigen Zustand verwendet
("History"). Start- und Endzustand legen i.d.R. den Übergang
eindeutig fest.

> Prüfe ich im Zustand die Ereignisse, die einen Übergang
> auslösen, und führe diese dann aus

Das ist sinnvoll, wenn Du einen Automaten mit einem
aktiven Zustand implementieren willst.

> oder sind mögliche Übergange ständig "aktiv" und prüfen
> ihr Startereignis; sobald es eintritt, werden die anderen
> gesperrt/deaktiviert.

Das ist sinnvoll, wenn Du mehrere Automaten simultan
implementieren willst. In der SPS-Programmierung macht(e)
man das so.

Karl H. schrieb:

> N.A. schrieb:
>> Das ist schlüssig, allerdings habe ich mehrere Übergänge,
>> die in verschiedenen Zuständen auftreten können. Die
>> erforderlichen Prüfungen müssten dann mehrfach aufgerufen
>> oder implementiert werden.
>
> Ja. Und?

Verstehe ich nicht.

Der gegenwärtige Zustand ist ja bekannt. Also muss nur für
jeden Übergang, der aus dem gegenwärtigen Zustand herausführt,
die dazu notwendige "Freigabe" geprüft werden.

Jede erforderliche Prüfung muss genau einmal implementiert
werden.

In jedem Zustand wird jede implementierte Prüfung höchstens
einmal aufgerufen.

Möglicherweise!

Der Punkt ist ja, das beim Automatenmodell jedwede Verarbeitung im 
engeren Sinne fast nie behandelt wird. Also etwa eine Umrechnung. Auch 
ist das "lesen eines Portpins" eine intrinsische Eigenschaft eines 
Automaten während sie bei einem uC oder uP ausdrücklich hingeschrieben 
werden muss.

Dieser Satz mit dem "mehrfachen Hinschreiben" deutet irgendwie in die 
Richtung, "falls ich mich nicht irre". (Sam Hawkins)

Wie erstellst Du denn Deinen Automaten bevor Du anfängst zu coden ?
Normalerweise malt man sich den auf ein Blatt Papier und hat dann 
Zustandsblasen an denen dann die Übergänge als Pfeil auf den nächsten 
Zustand zeigen.
Wenn Du nun mehrere Übergänge von einem Zustand hast kannst Du nun 
entweder in Deinem Zustand die einzelnen Übergänge ansprechen oder Du 
erzeugst "Zwischenzustände" so das es immer nur einen Übergang gibt.
Wenn man ja wüßte was es werden soll ?

Karl H. schrieb:
> Am schreiben einer Funktion wirds ja
> wohl hoffentlich nicht scheitern.

Doch, das ist ein bisschen das Problem, denn ich habe nur proprietäre 
"Flowcharts", mit denen ich das Ganze umsetzen muss. Naja, mal sehen.
Danke für die Beiträge.