Die Ideen für die Umsetzung von Multi-Agenten-Systemen in dWb+, die bereits in einem früheren Artikel beschrieben wurden, wurden umgesetzt und in einem ersten praktischen Szenario validiert:
Jeder Agent verfügt über einen Zustand den er selbst modifizieren kann und den andere Agenten und der Anwender einsehen können. Des weiteren verfügt jeder über eine individuelle Konfiguration. Diese kann der Agent nicht selbst modifizieren - sie wird ihm bei der Instantiierung durch den Schwarm zugeteilt. Weiterhin verfügt jeder Agent über eine Konfiguration, die die gesamte Population (den gesamten Schwarm) betrifft. Auch diese ist nicht durch den Agenten modifizierbar. Sie existiert nur einmal und wird allen Agenten per Referenz zugänglich gemacht.
Jeder Agent gehört zu einem Schwarm. Ein Schwarm kann aus unbegrenzt vielen Agenten bestehen. Der Schwarm sorgt dafür, dass die Agenten ihren inneren Zustand aktualisieren könnnen: Dazu gibt er jedem einzelnen Agenten Informationen über die Umgebung und die Zustände aller Agenten. Der Agent ermittelt anhand der Informationen aus der Umwelt und den Zuständen der anderen Agenten und seinem inheränten Verhalten etwaige Zustandsänderungen und aktuelisiert seinen Zustand.
Die Implementierung geschieht durch mehrere Module: Der Schwarm ist ein dediziertes Modul, das intern die Agenten verwaltet. Die Agenten treten selbst nicht als Module in Erscheinung. Dazu wurde für die bessere Veranschaulichung ein weiteres Modul geschaffen, das mittels Informationen aus dem Environment und den Zuständen der Agenten den Systemzustand visualisiert.
Die einzelnen Aspekte (Agent, Schwarm, Zustand, Environment) konnten dabei so generifiziert werden, dass Basisklassen entstanden, die die Erstellung weiterer Multi-Agenten-Systeme zur Benutzung in dWb+ wesentlich erleichtern.
Wie man aus den drei angehängten Screenshots sehen kann, entwickelt sich unter den einfachen Agenten mittels Selbstorganisation so etwas wie Ordnung.
Alarmierung über Skripte
16.09.2019
Nachdem ich mich in letzter Zeit wieder verstärkt mit den Themen Monitoring und Alarmierung auseinandersetze, habe ich überlegt, ob ich die dabei gewonnenen Erkenntnisse nicht auch dazu nutzen könnte, die bestehende Lösung flexibler zu machen
Weiterlesen...Android Basteln C und C++ Chaos Datenbanken Docker dWb+ ESP Wifi Garten Geo Git(lab|hub) Go GUI Gui Hardware Java Jupyter Komponenten Links Linux Markdown Markup Music Numerik PKI-X.509-CA Python QBrowser Rants Raspi Revisited Security Software-Test sQLshell TeleGrafana Verschiedenes Video Virtualisierung Windows Upcoming...
Das Konzept eines CircuitBreaker ist schon lange bekannt. Ich habe mir zu Studienzwecken einen selber gebaut - eigentlich zwei: Einer ist dafür da, das Logging von gleichartigen Exceptions zu drosseln, der andere für das Entzerren von Versuchen, Ressourcen von URLs nachzuladen. Diese spezielle Variante benötigte ich für EBMap4D: Falls einer der Tile-Server ausfällt, wird ansonsten ständig versucht, die Kacheln neu herunterzuladen. Das frisst nicht nur Rechenzeit, sondern ist auch unnütz.
Weiterlesen...Nachdem ich mich nun schon so lange mit Origami beschäftige habe ich endlich einmal das älteste dokumentierte Ornament versucht - aus gutem Grund...
Weiterlesen...Eine neue Musikreihe/Show auf Youtube gefunden...
Weiterlesen...Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.
Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.
Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...
PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.