Forum: PC-Programmierung Sinnvolle Definition einer State-machine


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andy W. (gastandy)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

es geht bei meiner Frage zwar nicht direkt um PC-Programmierung, aber 
ich denke, das Thema passt am besten in dieses Forum.

Momentan bin ich dabei die Software (Assembler) für ein Modul meines 
Hausbusses zu schreiben. Konkret soll das Modul im Aussenbereich Tür und 
Rolltor der Hauseinfahrt überwachen sowie die Lichtsteuerung dort 
übernehmen.

Es gibt 8 Eingangsgrößen, welche jeweils durch ein Bit repräsentiert 
werden:

1) Magnetkontakt obere Endlage Rolltoor
2) Magnetkontakt untere Endlage Rolltoor
3) Magnetkontakt Tür
4) Sabotageschleife aller 3 Magnetkontakte in Reihenschaltung
5) Stromerkennung Motor Rolltor
6) Bewegungsmelder Torinnenseite
7) Bewegungsmelder Toraussenseite
8) Helligkeitssensor

Ausgangsgrößen gibt es drei: Licht innen, Licht aussen und einen 
Signalgeber (Alarmsirene o.ä.)

Das Modul funktioniert soweit einwandfrei, d.h. die 8 Eingangsgrößen 
werden erfasst und die 3 Aktuatoren können betätigt werden.

Nun mein Problem: Wie verknüpfe ich die Eingangsgrößen mit den 
jeweiligen States im Modul?
Ein State könnte z.B. die Unterscheidung von Tag und Nacht sein oder ein 
anderer, ob die Objektüberwachung (Alarmanlage) aktiv ist oder nicht. 
Bei einer State-Machine ergeben sich 256 mögliche Kombinationen aus den 
obigen 8 Eingangsgrößen. Nur wie verknüpft man die sinnvoll?
So ist z.B. der Sabotagekontakt bei der Unterscheidung Tag/Nacht ohne 
Bedeutung, wenn die Alarmanalge aktiv ist, aber schon. Der innere 
Bewegungsmelder hingegen kann sowohl das Licht betätigen, als auch ggf. 
einen Alarm auslösen. Der Helligkeitssensor hat einen Einfluss auf das 
Einschalten des Lichts, ist aber unabhängig von der Alarmanlage. Da 
ergeben sich zig Abhängigkeiten.


Mir geht es nicht um Implementierungsdetails, mehr um ein generelles 
Verständnis. Geht man bei der Definition der States nach einer Art 
Hierarchie vor oder gibt es grundsätzliche Regeln?

Wenn jemand dazu sachdienliche Anregungen, Links, gerne auch 
Literaturtips hat, wäre ich sehr dankbar!

MFG
Andy

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hm. Man wird das nicht erschöpfend beantworten können, ohne an Deiner 
Stelle die State-Machine zu entwerfen (nicht zu definieren - das ist 
etwas anderes).

Es stellt sich aber, nach Deiner Beschreibung ohnehin die Frage ob eine 
State-Machine überhaupt notwendig ist.
Alle Abhängigkeiten, die Du genannt hast, sind rein kombinatorisch von 
den Eingangsgrössen abhängig, nicht aber davon, dass bestimmte 
Eingangsgrössen früher einmal bestimmte Werte hatten, als sie in den von 
Dir genannten hypothetischen Zuständen aktuell haben.
Es ist übrigens zwar dennoch möglich, bei rein kombinatorischer 
Abhängigkeit, diese als State-Machine zu beschreiben, aber es ist nicht 
nötig und kompliziert die Dinge für einen Anfänger nur unnötig.

Du wirst das evtl. noch nicht verstehen, aber ich rate Dir zunächst 
einmal zu versuchen, die Ausgangsgrössen ausschliesslich als von den 
jeweils gegenwärtigen Eingangsgrößen abhängig zu betrachten - und nicht 
auch noch von der Vorgeschichte dieser Eingangsgrössen.
Das entsprechende Paradigma dazu heisst "Entscheidungstabelle" (so wie 
die State-Machine ein Paradigma ist).

Ein gutes Hilfsmittel dazu, dass dazu noch fast jeder Computerbenutzer 
haben dürfte, ist ein Spreadsheet bzw. Rechenblatt-Programm, wie etwa 
Microsofts "Excel" bzw. LibreOffices "Calc". Es gibt auch unter dem 
Stichwort "Entscheidungstabelle" einige Vorlagen, die unter anderem 
helfen, alle möglichen Kombinationen zu berücksichtigen. Das geht aber 
bei 8 Eingangsgrössen durchaus noch von Hand.
Beschäftige Dich einmal damit - dazu gibt es unzählige Beschreibungen im 
Internet.

Erst wenn und falls Du feststellst, dass für Deine Anwendung auch die 
Vorgeschichte der Eingangssignale eine Rolle spielt - oder, in anderen 
Worten, es mindestens zwei Fälle gibt, in denen bei gleichen 
Eingangssignalen unterschiedliche Ausgangssignale erzeugt werden sollen, 
ist eine State-Machine überhaupt notwendig. Dann aber lies Dich einmal 
ein wenig in solche State-Machines ein. Dann kannst Du auch 
spezifischere Fragen stellen.

von Andy W. (gastandy)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Theor,

Danke für das ausführliche Feedback!

Ich hoffe, meine Erklärungen waren nicht missverständlich.

Bei Modulen mit Display nutze ich bereits eine State-Machine, d.h. bei 
jeder Transition wird ein spezifische Aktion durchgeführt. Das ist für 
die Menüführung mit einer beschränkten Anzahl von Bedienknöpfen 
nützlich/zwingend.

Nur ist mir nicht klar, wie ich das in dem geschilderten Anwendungsfall 
(sinnvoll) umsetze. Du hast Recht, vielleicht gibt es hier nicht 
wirklich Abhängigkeiten von den vorherigen Zuständen.

Zum Stichwort Entscheidungstabelle und State-Machines werde ich mich auf 
jeden Fall noch einmal ausführlich informieren.

MFG
Andy

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Andy W. schrieb:
> Ein State könnte z.B. die Unterscheidung von Tag und Nacht sein oder ein
> anderer, ob die Objektüberwachung (Alarmanlage) aktiv ist oder nicht.

Was du beschreibst, ist kein State. Ein State (zu deutsch: Zustand) ist 
keine Unterscheidung, sondern eben ein Zustand, in dem das System gerade 
ist. Eine Statemachine ist zu jeder Zeit dann in einem (und genau einem) 
ihrer Zustände. Auch Tag und Nacht sind eigentlich keine Zustände, 
sondern eher Inputs.

> Bei einer State-Machine ergeben sich 256 mögliche Kombinationen aus den
> obigen 8 Eingangsgrößen.

Die Besonderheit einer Statemachine ist, dass abhängig von ihrem 
aktuellen Zustand die Eingangssignale unterschiedlich behandelt werden 
können. Es sind also mehr Kombinationen, da der Zustand noch mit 
eingeht. Die Eingangssignale lösen dabei Übergänge zwischen den 
Zuständen aus.

> Nur wie verknüpft man die sinnvoll?
> So ist z.B. der Sabotagekontakt bei der Unterscheidung Tag/Nacht ohne
> Bedeutung, wenn die Alarmanalge aktiv ist, aber schon.

Da sehe ich keine Statemachine, sondern einfach eine boolesche 
Verknüpfung. Wie Theor schon schrieb, ist das eher ein kombinatorisches 
Problem.

> Der innere Bewegungsmelder hingegen kann sowohl das Licht betätigen, als
> auch ggf. einen Alarm auslösen.

Aber auch hier sehe ich eine einfache Verknüpfung:
WENN Alarmanlage an UND Bewegung registriert, DANN Alarm
WENN Alarmanlage aus UND Bewegung registriert, DANN Licht an

> Mir geht es nicht um Implementierungsdetails, mehr um ein generelles
> Verständnis. Geht man bei der Definition der States nach einer Art
> Hierarchie vor oder gibt es grundsätzliche Regeln?

Bei einer Statemachine gibt es keine Hierarchie, allerdings kann man 
mehrere Statemachines verschachteln. Es geht bei einer Statemachine in 
der Regel eher um einen Ablauf, der je nach Inputs unterschiedlich sein 
kann.

von P. P. (klatschnass)


Bewertung
0 lesenswert
nicht lesenswert
Deine Menge der Statusse ergibt sich aus den gültigen Zuständen deines 
Systems.
Diese Menge musst du für dein System definieren. Und da schließen sich 
bestimmte Aktionen bzw. Zustände schon aus, so dass diese Statusmenge 
schon wesentlich kleiner ist, als die Kombinationen aller Sensor- und 
Aktorenzustände.

Z.B. gibt es keinen Zustand, in dem der Helligkeitssensor Tag=hell 
meldet und die Hoflampe angeschaltet ist. Und z.B. spielt die Helligkeit 
im Zustand "Tor wird geschlossen" keine Rolle.

Du solltest dir mal Gedanken machen, in welchen Zuständen das System 
sein kann.
Mir fielen jetzt mal beispielhaft solche Zustände ein, wie z.B. "Tag, 
Tor offen", "Tag, Tor zu", "Nacht, Tor zu", "Tor wird geschlossen", "Tor 
wird geöffnet" usw.

Diese Zustände verbindest du mit Aktionen. Z.B. gibt es zwei Übergänge 
von "Tag, Tor offen" zu "Tor wird geschlossen". Der erste Übergang ist, 
wenn jemand einen Taster "Tor schließen" drückt, der andere, wenn der 
Helligkeitssensor meldet, dass es dunkel wird.

von Andy W. (gastandy)


Bewertung
0 lesenswert
nicht lesenswert
Danke für Euer Feedback!

MFG
Andy

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andy W. schrieb:
> Nun mein Problem: Wie verknüpfe ich die Eingangsgrößen mit den
> jeweiligen States im Modul?

Kurze Antwort: die States einer State-Machine sind logische Zustände in 
zeitlicher Abfolge, wie etwa bei einer Datenübertragung Start, Daten, 
Prüfsumme, Ende. Solche States hat dein System garnicht, also brauchst 
du auch keine State Machine. Soweit aus deiner Beschreibung ersichtlich 
gibt es nur direkte logische Verknüpfungen der Art if Input 1 AND Input 
3 then Output 5 = 1 else Output 5 = 0.

Die brauchst du ja nur hinzuschreiben und in einer Endlosschleife 
ausführen.

Georg

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andy W. schrieb:
> Hallo Theor,
>
> Danke für das ausführliche Feedback!
>
> Ich hoffe, meine Erklärungen waren nicht missverständlich.
>
> Bei Modulen mit Display nutze ich bereits eine State-Machine, d.h. bei
> jeder Transition wird ein spezifische Aktion durchgeführt. Das ist für
> die Menüführung mit einer beschränkten Anzahl von Bedienknöpfen
> nützlich/zwingend.

Nun gut. Du benutzt das Schema einer State-Machine also schon in einem 
Fall. In einem Menüsystem ist das sicher nützlich, da bin ich Deiner 
Meinung.
Ob es zwingend notwendig ist kann man aber definitiv feststellen und 
braucht sich nicht auf seine Meinungen zu verlassen. Ich denke aber, das 
ist hier nicht der springende Punkt, sondern der ist lediglich Deine 
Mitteilung, dass Du mit State-Machines schon zu tun hattest.

> Nur ist mir nicht klar, wie ich das in dem geschilderten Anwendungsfall
> (sinnvoll) umsetze. Du hast Recht, vielleicht gibt es hier nicht
> wirklich Abhängigkeiten von den vorherigen Zuständen.

OK. Es scheint mir, als wenn es um den gedanklichen Übergang von der 
State-Machine eines Menüsystems zu dem einer Steuerung geht und das Dir 
insbesondere die notwendigen impliziten Annahmen, die Du treffen musst, 
Schwierigkeiten bereiten. Ich vermute mal, Du denkst dabei öfter mal 
sowas wie: "Hm. OK. Also dann ist das so ... Aber dann müsste doch ... 
Aber das ist ja dann anders, als ... Aber, wie denn nun?" und es fällt 
Dir schwer eine Ordnung da hinein zu bringen.

> Zum Stichwort Entscheidungstabelle und State-Machines werde ich mich auf
> jeden Fall noch einmal ausführlich informieren.
>
> MFG
> Andy

Das ist gut.
Ich möchte Dir noch einen Rat geben, wenn Du magst.

Du fragst insbesondere danach, wie Du so eine State-Machine entwirfst. 
Obwohl Du Dich sicher noch etwas mehr informieren solltest (wie Du ja 
auch vorhast) kann man da durchaus einen, allerdings etwas lakonisch 
klingenden Rat geben.

Nämlich: "Fange am Anfang an". Da gibt es aber zwei! :-) Ja. Zwei 
Anfänge. Das scheint etwas überraschend, ist aber sinnvoll so zu 
betrachten.


Nämlich den Anfangszustand der äusseren Situation und den 
Anfangszustand der Steuerung. Die "äussere Situation" ist erstmal die 
der Bewegungsmeldern in Abhängigkeit davon, ob sich ein Fußgänger oder 
ein Auto in deren Erfassungsbereich bewegt (oder befindet, je nachdem 
wie der Melder funktioniert).

Überlege Dir zuerst einmal einen Entwurf einer Zustandsmaschine für die 
Situation von Garagentor, Bewegungsmelder usw. Also nicht mit der 
Maschine der Steuerung beginnen, sondern mit den Abläufen in der 
Anordnung, die das Subjekt der Steuerung ist.

Was ist der Anfang der Situations-State-Machine? Das ist vielleicht 
Sonntag nacht, wenn keiner unterwegs ist, das Auto in der Garage steht 
und Du schlummernd im Bett liegst. Letztlich ist der Anfangszustand 
willkürlich, aber es hilft eine reale Situation zu wählen. Und am Ende 
des Enwurfs steht die Prüfung, ob Du alle möglichen Zustände der 
"Eingänge" der Situations-State-Machine berücksichtigt hast.

Was hilft Dir das aber nun?
Das hilft Dir zu kontrollieren, ob Deine Steuerungs-State-Machine auch 
wirklich alle relevanten realen Zustände der Situation berücksichtigt, 
die "relevanten" von den "irrelevanten" (weil garnicht real 
auftretenden) Zustände zu unterscheiden und zu kontrollieren ob die 
Steuerung auch wirklich sinnvoll auf jede Änderung der äusseren 
Situation reagiert.

Was ist der "Anfang" der Steuerungs-State-Machine? Das ist im 
einfachsten Fall, der Aus-Zustand. Natürlich kann von diesem Zustand 
durch keinerlei Änderung der Eingangssignale ein anderer Zustand 
erreicht werden - das kann nur durch das Einschalten geschehen. Aber es 
ist ein Anfang. Definitiv! :-)

Nun, stell Dir vor, Du schaltest die Steuerung ein. Dann ist sie in 
einem der Ein-Zustände. Ich sage absichtlich "einem der", weil der 
Zustand nach dem Einschalten nicht ausschliesslich von dem Fakt, dass 
die Steuerung mit Strom versorgt wird, abhängt. Er hängt schon im ersten 
Schritt von den Zuständen der Eingangssignale ab. Und die ergeben sich 
aus den Überlegungen zu den Zuständen der Situation. Man muss 
berücksichtigen, dass die Steuerung ja in jeder der möglichen realen 
Situation eingeschaltet werden kann. Welche reale Situationen es gibt, 
kannst Du aber feststellen in dem Du die Situation erstmal modellierst.

Das könntest Du Dir mal etwas detaillierter Überlegen. Vielleicht hilft 
Dir das weiter.

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ Andy

Ah. Sorry. Ich vergaß zu erwähnen: Du solltest trotz meiner 
Informationen in meinem vorherigen Beitrag prüfen, ob die Abhängigkeiten 
nicht doch rein kombinatorisch sind, bevor Du von einer State-Machine 
für die Steuerung ausgehst.

Aber die Situation kannst Du durchaus vorher mal modellieren. Das übt 
und ist auch noch einigermßen übersichtlich, weil die Anzahl der Input 
geringer ist. Auch kannst Du so Fehlerzustände gut deutlich machen; also 
solche, die Du im ersten Moment als "Unmöglich" bezeichnen würdest.

von Boris O. (bohnsorg) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Es geht bei einer Statemachine in der Regel eher um einen Ablauf

Noch nicht ganz: es geht um die Definition der Zustände (Knoten) eines 
(oft endlichen) Automaten und der Übergänge zwischen diesen (Kanten). 
Durch Kantenbewertungen oder Richtungseinschränkungen gibt das schöne 
Graphen und jede Menge theoretisches Beiwerk, Vorlesungen zu füllen. Man 
kann dann analysieren, wie man zwischen den Zuständen wechseln kann oder 
ob formale Paradigmen erfüllt/ nicht erfüllt sind.

Einen Ablauf kann ich auch mit einem Programmablaufplan, einem 
UML-Sequenzdiagramm oder Pseudo-Code bewerkstelligen, um den Preis der 
Formalisierung aller Zustände und ihrer Übergänge.

Welche Fragen hast du genau zum Beispiel aus dem Artikel zur 
Statemachine?

: Bearbeitet durch User
von Andy W. (gastandy)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

vielen Dank für Eure ausführlichen Rückmeldungen!

Vielleicht sollte ich noch ein paar Infos liefern, damit mein Anliegen 
klarer wird:

Die von mir verwendeten State-Machines haben eine tabellarische Form, 
ein Zahlenpaar pro Input und State, wobei eine Ziffer die beim Übergang 
ausgefürte Routine indiziert und die andere den nächsten State.

Da ein gedrückter Button eine einfache Eingangsgröße ist, ist das für 
Menüs mit der Tabelle noch halbwegs überschaubar (z.B. 5Buttons=5Inputs 
"MENÜ","+","-","SAVE","CANCEL" usw.)

Nun zurück zur Lichtsteuerung.
Wenn ich die Alarmüberwachung als weiteren binären Input annehme, 
ergeben sich 9 Eingangsgrößen, wobei - im Gegensatz zu den Menübuttons - 
sowohl die 0/1 als auch 1/0 Übergänge relevant sind. Das wären 18 Inputs 
pro State! (Die State-Machine wird nicht zyklisch, sondern nur bei einer 
Zustandsänderung bei einer der Eingangsgrößen aufgerufen!)


Nun wird es interessant. Beim Neustart des Moduls habe ich state_0 und 
alle Eingangsgrößen werden erstmalig eingelesen. Jetzt muss ich auf 
Basis der Eingangsgrößen entscheiden, welcher der erste definierte 
Zustand nach state_0 ist, da ja noch keine Zustandsänderung erfolgte.
Nun frage ich mich, was wären sinnvolle Zustände?
Mein Problem ist nicht, wie ich 2^18 mögliche Kombinationen abbilde (wie 
von Euch richtig angemerkt, ergeben ja nicht alle Kombinationen Sinn). 
Es geht mir mehr darum, nach welchen Eingangsgrößen ich die Zustände 
unterscheide und welche Aufsplittung überhaupt sinnvoll ist.

Mein jetziger Ansatz wäre, die States nur auf die wichtigsten 
Eingangsgröße zu beziehen, z.B. die Alarmüberwachung und den Lichtsensor 
(deswegen die Frage nach einer Hierarchie im meinem ersten Post)
und von hier aus auf die anderen Sensoreingänge zu reagieren.

state_o:
state_alarm_off_day:
state_alarm_off_night:
state_alarm_on_day:
state_alarm_on_night:

BTW: Ich muss das Problem der Lichtsteuerung nicht zwingend mit einer 
State-Machine lösen! Nur wenn ich mit wenigen Zuständen auskäme, wäre 
das für mich codetechnisch irgendwie symphatischer (da überschaubarer), 
als mehrfache Abfragen und Verzweigungen in Assembler.

Ich hoffe, Ihr könnt nun nachvollziehen, was mein Problem ist :-)
Als Nichtinformatiker ist das echt schwer in Worte zu fassen...


MFG
Andy

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andy W. schrieb:
> Mein jetziger Ansatz wäre, die States nur auf die wichtigsten
> Eingangsgröße zu beziehen,

Du hast absolut nichts verstanden. Du hast garkeine States, du kannst 
höchstens welche erfinden um die Sache kompliziert zu machen. Aber, nur 
zum Beispiel, Tag/Nacht ist kein State im Sinn einer State machine, denn 
da muss kein Zustand gespeichert werden, es ist Tag wenn es hell ist und 
Nacht wenn es dunkel ist.

Da soll wohl die Logik brutal vergewaltigt werden, um ganz einfache 
Zusammenhänge in ein theoretisches akademisches Konzept zu zwängen. Da 
musst du dir halt beliebige States ausdenken, die möglichst überhaupt 
keine Auswirkungen haben, damit nicht auch noch unnötige Fehler 
eingeführt werden.

Wenn dein Ausbilder dich zwingt das so zu machen, dann kannst du 
natürlich einen State "Nacht" definieren, und der wird gesetzt, wenn der 
Sensor von Hell auf Dunkel wechselt, und zurückgesetzt, wenn er von 
Dunkel auf Hell wechselt.

Das ist aber meiner Meinung nach verglichen mit der einfachen Tatsache 
"Nacht = dunkel" nicht nur hirnrissig, sondern auch noch sehr viel 
unsicherer, denn gemerkte Werte sind weit weniger zuverlässig als der 
direkte Input - geht der Zustand "Nacht" aus irgendeinem Grund mal 
verloren, wird der Fehler nach deiner Programmbeschreibung ja erst beim 
nächsten Wechsel des Eingangs bemerkt und korrigiert, also u.U. erst 
nach fast 12 Stunden.

Ich verabschiede mich hier aus dem Thread, der führt zu nichts.

Georg

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Theor schrieb:

> Nämlich: "Fange am Anfang an". Da gibt es aber zwei! :-)
> Ja. Zwei Anfänge.

Nun, ohne Dir jetzt direkt widersprechen zu wollen: Ich
mache es anders. Aus meiner Erfahrung heraus fange ich
immer mittendrin an.

Für mich hat sich die Methode bewährt, mir den stationären
("eingeschwungenen") Fall vorzustellen und dort die
einzelnen Zustände so wegzuprogrammieren, wie sie mir
gerade unterkommen.

Anfangszustände, Initialisierung, Fehlerbehandlung,
Abdichtung gegen unzulässige Übergänge mache ich immer
hinterher.

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andy W. schrieb:

> Mein jetziger Ansatz wäre, die States nur auf die
> wichtigsten Eingangsgröße zu beziehen, [...]

Nein. Begriffliches Chaos.

Auch wenn es unkuhl ist: Man DARF sich allgemeinverständlich
ausdrücken. Die "state machine" ist eine sinnentstellende
Übertragung des englischen "finit state machine", was soviel
wie "endlicher Automat" bedeutet. (Das "endlich" bezieht sich
auf die Zahl der Zustände; unendliche Automaten sind z.b. die
Turing-Maschine oder der Kellerautomat.)
Ein "state" ist einfach ein Zustand.

So. Jetzt das Hintergrundwissen: Ein endlicher Automat ist
durch fünf Dinge vollständig gekennzeichnet:
- die Menge X der Eingangssignale,
- die Menge Y der Ausgangssignale,
- die Menge Z der Zustände,
- die Überführungsfunktion,
- die Ausgabefunktion.
Details, auch zu Moore/Mealy, sind anderswo nachzulesen.

Zustände sind (NUR!) dann notwendig, wenn auf IDENTISCHE
Kombinationen von Eingangssignalen UNTERSCHIEDLICH reagiert
werden muss. Der Zustand "merkt" sich die Vorgeschichte.

Jetzt zu Deiner Frage, so wie ich sie verstehe: Ich weiss
nicht, ob es eine formal definierte Methodik gibt, die
Zustände zu identifizieren.
Ich würde mit einer Zuordnungstabelle anfangen, in der ich
zu jedem Eingangsvektor den gewünschten Ausgangsvektor
aufschreibe. Interessant sind jetzt die Fälle, in denen es
zu DEMSELBEN Eingangsvektor mehrere sinnvolle/erwünschte
Ausgangsvektoren gibt. Das sind genau die Fälle, wo man
"Hilfsvariablen" braucht, um die jeweils richtige Ausgangs-
belegung auszuwählen -- und diese Hilfsvariablen sind genau
die Zustandsvariablen.

Das ist jetzt nur ein Schuss aus der Hüfte; ich habe das so
noch nie bewusst gemacht.

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Boris O. schrieb:

> Einen Ablauf kann ich auch mit einem Programmablaufplan,
> einem UML-Sequenzdiagramm oder Pseudo-Code bewerkstelligen,

Ja, sicher?!

Das sind nur andere Möglichkeiten, denselben Automaten zu
definieren (wenn es derselbe Ablauf ist).

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ Andy

Ganz offen gesagt, geht es mir ein bisschen wie Georg. Ich kann leider 
nicht definitiv den Finger auf den wunden Punkt legen. Es gibt eher 
viele kleine "Halbverständnisse", aus denen Du eine Gesamtheit machen 
willst, aber es kommt was Krudes dabei heraus.

Zunächst einmal hat die State-Machine der Benutzeroberfläche nicht 
zwingend etwas mit der State-Machine der damit kontrollieren Steuerung 
zu tun. Im Gegenteil, wird man sich von selbst anbietenden 
hierarchischen Strukturen auch so modellieren und implementieren, weil 
das die Übersicht erhöht. Du aber hörst Dich so an, als wolltest Du die 
State-Machine der Oberfläche mit der der Steuerung irgendwie 
verheiraten.

Ob nun eine State-Machine auf Flanken reagiert oder Zustände ist ein 
Implementierungsdetail der State-Machine selbst, aber kein notwendig 
festzulegendes Detail beim Entwurf.

Auch spielt es überhaupt keine Rolle für den Entwurf ob der Mechanismus 
einer State-Machine nur bei Zustandsänderungen aktiv wird oder zyklisch, 
denn im zweiten Fall, würde sich ohne Änderung der EIngangsgrössen kein 
neuer Zustand und kein veränderter Output ergeben.

Dann sind State-Machines selbst kein Entwurfsmittel, mit dem Fokus auf 
eine Strukturierung. Es hilft nicht dabei, irgendwelche "wichtigen" 
Zustände zu finden. Auch werden damit verschiedene Eingangszustände 
nicht in relevant oder irrelevant unterschieden. Das sind 
Entscheidungen, die Du treffen musst. Sie ergeben sich nicht aus der 
Verwendung des Entwurfsmusters.

Es sind hier an sich nicht so sehr Begriffe der Informatik die fehlen, 
meine ich, sondern die Denkweise - die Betrachtung des grundsätzlichen 
Unterschieds von Kombinatorik und zustandsabhängigen Systemen, wie sie 
sich gliedern und hierarchisieren lassen.

Das kann man zwar erklären, aber zum Verständnis ist unbedingt auch das 
Üben nötig. Auch das Üben der Implementierung in einer imperativen 
Sprache.

Ich rate Dir ernsthaft, zunächst einmal einfache State-Machines zu 
entwerfen. Und im Vergleich einmal etwa die State-Machine eines an sich 
kombinatorischen Problems (etwa ein UND-Gatter) und dazu eine eines 
inhärent zustandsbehafteten Systems (etwa eine Ampelsteuerung).

Ich glaube, wenn ich mehr versuchte zu erklären, würde die Verwirrung 
nur noch grösser.

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ Andy

An einer Stelle will ich aber mal direkt einhaken:

Du schreibst:
> Es geht mir mehr darum, nach welchen Eingangsgrößen ich die Zustände
> unterscheide und welche Aufsplittung überhaupt sinnvoll ist.

Es gibt zwei Arten der Abhängigkeit bzw. Unabhängigkeiten:

1. Es gibt manchmal Gruppen von Eingangssignalen deren Zustände sich auf 
einen bestimmten Teil des Outputs (der Wirkung) nicht auswirken. - Das 
ist eine einzelne State-Machine. Insgesamt also mindestens zwei davon.
2. Es gibt Gruppen von Eingangssignalen, die, falls ein weiteres 
Eingangssignal einen bestimmten Zustand hat, sich nicht mehr weiter auf 
den den Ablauf auswirken. Die Signale bilden keine Bedingung mehr für 
die Erreichung des letztlich entscheidenden Zustandes.

Es gibt aber eine Möglichkeit sich den Anfang noch etwas zu 
vereinfachen:
Die naheliegendste Variante richtet sich nach den Ausgangssignalen! Denn 
die sind es die in der Aussenwelt tatsächlich etwas bewirken.

So. Jetzt bin ich aber auch still. :-)

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
OK. Noch eines: :-)

Ich habe Dir oben geraten:

"Ich rate Dir ernsthaft, zunächst einmal einfache State-Machines zu
entwerfen. Und im Vergleich einmal etwa die State-Machine eines an sich
kombinatorischen Problems (etwa ein UND-Gatter) und dazu eine eines
inhärent zustandsbehafteten Systems (etwa eine Ampelsteuerung)."

Aber ich möchte das korrigieren. Entwirf zunächst eine Kombinatorik als 
State-Machine und dann ein einfaches Flip-Flop - und erst später eine 
Ampelsteuerung.

von Andy W. (gastandy)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

super, Danke für die konstruktive Kritik, speziell die sachdienlichen
Anregungen von Theor und Possetitjel. Da waren ein paar ganz wichtige 
Infos dabei!

Ich wünsche Euch noch einen schönen Abend!

MFG
Andy

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]
  • [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.