Unter www.oksimo.org findet man die Basis und die gesamte Diskussion. Will man jetzt aber mit dem System praktisch arbeiten, muss man zu www.oksimo.com wechseln, für den man dann einen eigenen Benutzer-Account benötigt.

• Menu (ab V1.0 23.08.2021)
  • New Vision
  • Manage Visions
  • Vision Collections
  • New State
  • Manage States
  • State Collections
  • New Rule
  • Manage Rules
  • New Simulation
  • Manage Simulations
  • Load Simulation
  • Combine Simulations
  • Share
  • Exit Simulator

Erwartungsgemäß können die drei wesentlichen Bestandteile für eine Simulation (das Ziel oder die Vision, der Status und die Veränderungsregeln) angelegt und verändert werden.

Eine neue Simulation kann angelegt und durchgeführt werden.

Spannend sind die drei folgenden Funktionalitäten (Load, Combine, share simulations). Hier kann man das Ergebnis einer Simulation an andere weitergeben oder auch von anderen übernehmen, damit mehrere Simulationen gemeinsam ein übergeordnetes Projekt bedienen.

Ablauf einer Simulation

Ausgangsbasis:

Der erste Zustand, an dem dann mögliche Veränderungen einwirken könnten, wird nicht vom System ermittelt, sondern wurde beobachtet und muss beschrieben werden.

Wenn z.B. die Bevölkerungs-Entwicklung in einer Kommune in den Jahren 2022 – 2032 simuliert werden soll, muss das System das Startjahr (hier 2022) und die Bevölkerungsanzahl zum Startzeitpunkt (hier z.B. 25.000) kennen.

Veränderungen basieren auf Regeln und Ereignisses oder Zuständen, bei denen diese Regeln dann greifen.

Diese Regeln basieren auf dem Wissen der Menschen, die sich an dem jeweiligen OksimoR-Projekt beteiligen.

Es gibt daher meistens sehr viele Regeln – sonst würde man ja auch keinen Computer benötigen – die in der Reihenfolge der Eingabe im System stehen. Jeder, der eine Eingabe macht, kann sehen, was bereits alles im System steht aber kaum einer kann dies bei komplexen Zusammenhängen überblicken.

Daher bilden die Regeln nur per Zufall die ideale Reihenfolge ab, in der sie zu prüfen und anzuwenden wären. Jede dieser zufälligen Reihenfolgen ist daher genauso richtig oder falsch, wie eine andere Reihenfolge (hier sehe ich aber noch Optimierungs-Potential). Bevor die erste Regel angewendet wird, hat das Programm alle Regeln in eine zufällige Reihenfolge gebracht. Wenn man ohne Veränderung der Ausgangslage die Simulation mehrfach durchlaufen lässt und dabei zu signifikant unterschiedlichen Ergebnissen kommt, ist klar, dass die Reihenfolge der Regeln eine Bedeutung hätte.

Simulationen:

Je Simulationsrunde (z.B. Jahreswechsel, nächste ausgespielte Karte beim Skat, neu eingetroffene Meldung einer Hochwasserstation etc…) werden alle Regeln auf ihre Anwendbarkeit geprüft. Diese Anwendbarkeit ist an Zustände oder Ereignisse gebunden, die gemeinsam mit der jeweiligen Regel definiert wurden.

Wenn z.B. ein Gesetz, welches den Zuzug von Bürgern ab dem Jahr 2030 auf 4% der Einwohnerzahl begrenzt, könnte eine entsprechende Regel im Jahr 2029 noch gültig sein, ab 2030 dann aber nicht mehr.

Wenn eine Veränderungsregel greift, führt sie zu Veränderungen. Diese Veränderungen könnten Zustände sein (z.B. geänderte Einwohnerzahl in jedem Jahr) oder Ereignisse (z.B. Kommunalwahlen alle fünf Jahre).

Wenn es mehrere mögliche Regeln gibt, die alternativ angewendet werden, kann man Wahrscheinlichkeiten für jede der Optionen mitgeben. Bei 50:50 würde in einem Simulation die eine Regel greifen und im nächsten Durchlauf dann die andere Regel.

Nach jedem Durchlauf könnte man auf Basis der Ergebnisse, die protokolliert und schriftlich ausgewiesen werden, die neue Ausgangssituation eingeben und wieder einen einzelnen Durchlauf starten oder dies übernimmt das Programm.

Abschluss:

Eines der Ereignisse/Zustände sollte die Bedingung für das Ende darstellen (z.B. Jahreswechsel 2032). Es wird auch dann enden, wenn keine einzige Veränderungsregel mehr greift, weil dann ja alles identisch bleibt.

Somit sollte klar sein, dass der Wechsel der Jahreszahl ebenfalls eine Veränderungsregel darstellen muss.

Zielerreichung:

Bei OksimoR handelt es sich um eine universelle Prozessplanung, mit der Intention, eine Lösung auf eine Frage zu finden. Dies könnte die erwartete Bevölkerungszahl im Jahre 2032 sein oder auch z.B. Methoden, um den Wasserverbrauch um 20% zu reduzieren.

Wie wir unter <Abschluss> gesehen haben, könnte eine der Veränderungsregeln auch sein „Vision erfüllt?“ oder „Antwort auf Frage gegeben?“. Wenn dies mit JA beantwortet werden kann, endet die Simulation.

Als Ergebnis sieht man dann nicht nur, ob etwas erreicht werden konnte, sondern auch wann.

nächste Versionen der Software:

dynamische Ziele:

Wie wir oben gesehen haben, gibt es Ziele oder Visionen und nach jedem Simulations-Durchlauf wird geprüft, ob das Ziel schon erreicht wurde oder wieviel noch fehlt.

Im praktischen privaten oder auch politischen Leben „kommt der Hunger beim Essen“. Sollte ein Minimalziel (z.B. ausgeglichener Haushalt) in Reichweite gerückt worden sein, entspricht dies der allgemeinen Lebenserfahrung, dass sich die Ziel ändern. Ggf. gönnt man sich jetzt zusätzlich ein ökologisch wirksames zusätzliches Ziel, wie die Erhöhung des Anteils an erneuerbaren Energie.

In der Ausgangslage (siehe oben) wurde ein Zustand beschrieben und das Ziel. Über die Veränderungsregeln wurde der Zustand dann verändert.

Mit derselben Logik können Veränderungsregeln demnächst auch die definierten Ziele verändern.

dynamischer Regelset:

Von einem Simulationsdurchlauf zum nächsten könnte sich ändern, welche Regeln geprüft werden sollen. Es könnten daher Regeln hinzukommen und auch Regeln entfernt werden.