Hallo,
unser sommer geht langsam zu ende und die grosse hitze in Perth ist langsam vorbei. Wir sind immer noch in unserem sommerdomizil, fahren aber naechste woche wieder nach hause. Ich dachte ich schreibe mal wieder einen update, ueber das was ich in der letzten zeit mit dem MBS gemacht habe.

Ich habe ein pause von der codierung fuer meine gleissteuerung eingelegt, um die verhaeltnisse mit strassenfahrzeugen besser kennenzulernen und moegliche parallelen zu erkennen. Ich habe mir drei scenarien ueberlegt, eine RoLa, eine grosse spedition und einen grossen bahnhofsparkplatz, die ich automatisieren moechte mit weitestgehend wiederverwendbaren scripten.

Das bauen von umfangreichen, virtuellen strecken mit vielen verzweigung kann muehsam sein, aber nach einer weile bekommt man uebung. Ich habe viele einzelne funktionen implementiert und stueck fuer stueck gelernt, wie ich abstrahierte funktionen mit Lua implementieren kann. 

Die verallgemeinerung ist aber noch nicht vollstaendig abgeschlossen, jetz folgt eine "Ordnungsphase" die einzelnen funktionen in leicht wiederverwendbare einheiten zu verpacken.

Dazu habe ich angefangen eine dokumentation zu schreiben mit der RoLa als beispiel, die den entwurfsprozess mehr top down formalisiert und nun eine klare richtlinie wird, wie ich die scripte gruppiere und parametrisiere um die moeglichst beste wiederverwendbarkeit zu erreichen. 

Anbei ist das dokument, welches erweitert wird und schliessendlich die gesamte beschreibung der verwendung der scripte enthaelt.  Das dokument ist in English aber es gibt ja uebersetzer. Ich schreibe lieber in English. Ich bin nicht versiert in deutscher IT sprache.

Gruss
Gmd

 

Lua_Rola_Dokumentation.pdf

Bearbeitet 30. März30. Mär von gmd

Hallo,

heute eine weitere version der dokumentation mit einem grossen teil der scripte fuer die erste komponente der RoLa "Vehicle Origin".
Noch nicht ganz vollstaendig, ohne die tatsaechliche anbindung an ein MBS modul, das kommt noch mit einer demo anlage, wenn ich
dann tatsaechlich die scripte teste.

Ich habe die dokumentation inclusive der scripte in word geschrieben. Nachdem ich die tests mit RoLa gemacht habe, bin ich einigermassen fliessend in Lua und kann die scripte schreiben ohne syntax check. Teilweise copy/paste, teilweise neue strukturierung, jedenfalls eine etwas bessere ordnung als in meinen testscripts.
Jede der abstrahierten komponenten wird dann separat getestet und zum schluss werden die einzelteile zur RoLa zusammegefuegt.

Die scripte dienen dazu die teilweise cryptischen zugriffe auf tabellen in leichter lesbare, "sprechende" begriffe zu verpacken und einfacher ablaeufe zusammenzustellen. Zugriffe auf 3 oder 4 dimensionale listen, koennen leicht unuebersichtlich werden, wenn man keine spezifischen zugriffsmethoden baut.

Bitte beachten: Die scripte sind noch nicht getestet. Wenn der entwurf vollstaendig ist, dann kann ich die scripte so wie sie sind vom word text in VS Code kopieren und syntax pruefen, und dann nach MBS in ein globales script uebernehmen und das anwendungsbeispiel zusammenbauen.

Gruss
Gmd


Edit:
Updated the pdf with a revison, added scripts and a depot return definition, scripts not completely tested, but partially syntax checked !
It has proven useful to rethink the functions and start fresh top down, including documentation. Some generic scripts will be added as an appendix.
Next step is to create the event module and event handlers in the studio for a demo.

 

Lua_Rola_Dokumentation.pdf

Bearbeitet 1. April1. Apr von gmd

Hallo,
habe die definitionsphase fuer das module "Vehicle Origin" soweit abgeschlossen.
Anbei der derzeitige stand der dokumentation und scripte.
Jetzt kommt das design der demo anlage und die verwwendung (test) der scripte.
Werde zwei module einrichten, dann sieht man gleich wie die scripte mehrfach verwendbar sind.
Diese demo ist dann auch fuer mich die basis fuer das design nachfolgender module. Bei meinem gedaechtnis brauche is so etwas inzwischen.
Die RoLa ist das beispiel der kombination mehrerer teilmodule zu einer groesseren anwendung.
Wenn das abgeschlossen ist gehe ich wieder an die gleise und baue aehnliche generische module fuer gleise.

Gruss
Gmd


 

 

Lua_Rola_Dokumentation.pdf

Hallo,
hier mal wieder ein update. Anbei eine erste version der demo fuer das "Vehicle Origin" modul.
Es passiert noch nicht viel, aber die struktur der scripte ist jetzt gut erkennbar und noch ueberschaubar.
Die einzige funktionalitaet, die derzeit implementiert ist, ist das setzen von release optionen fuer die fahrzeuge vom depot ueber schalter.
Der code ist generic und wird fuer alle VO module verwendet, egal wie viele. Die steuerung erfolgt ueber namen in den definitionstabellen.
In der demo vergebe ich die namen manuell, und auch die tabellen sind manuell erstellt. Spaeter wird mein programm solche tabellen generieren
und die objekte(hauptsaechlich kontakte)  entsprechend automatisch benennen.
Ich verwende Ereignismodule zur strukturierung der scripte. Fuer das VO modul gibt es ein Ereignismodul  VO, in dem nur die generischen scripte liegen.
Hier werden keine variablen abgelegt, jedenfalls keine die spezielle instanz daten enthalten.
Die anwendungen des VO moduls sind dann VO_1, VO_2 usw benannt, koennen aber auch anders heissen, ist nur eine tabelleneintrag. 
Nachfolgend werde ich jetzt die tatsechlichen funktionen einrichten mit 3 instanzen des VO Moduls. Und dann das naechste modul "Segmentierte Strecke" 
mit einbinden. Ich habe das dokumentationsdokument weiter ergaenzt. Ich bin mal gespannt wieviel tausend zeilen script das studio verkrafted.
Bisher ist noch keine kollisionskontrolle vorgesehen, wird interessant werden, wenn aus allen loechern die fahrzeuge ausgespuckt werden und wieder verschwinden .
 
Hier ist die content ID 5CE8FC5C-BD36-48C3-9B23-566BF925A002 , ist als entwurf geladen.

Gruss
Gmd

 

Hallo, mal wieder ein update.
Habe mein erstes "road modul" fertig.. Eine generische ampelsteuerung fuer beliebige anzahl von ampeln
ind definierbaren konfigurationen.
Viele features, inclusive gruene welle.

Beinhaltet noch keine fussgaegerampel. Das kommt spaeter wenn ich die grundlagen fertig habe.
Bisher erkunde ich moeglichkeiten und die integration mit meinem tool.
In diesem fall gibt es eine reihe von hilfsfunktionen, die auch plugins sein koennen um die definition der tabellen zu uebernehmen.

Das pdf  mit allen scripten ist zu gross, kann es nicht attachen, also habe ich die beschreibung ohne scripte geladen.

Falls jemand die demo und scripte moechte bitte PM.
gruss
Gmd
 

SC_Dokumentation_noscript.pdf

Hallo,
mal wieder ein update ... werde wegen neuer umstaende in zukunft etwas langsamer vorankommen. Erstens bin ich wieder in einem alten kommerziellen projekt engagiert (springe fuer einen notfall ein) und zweitens bin ich mal wieder fuer den kommenden winter (ab mitte juni) mit meinem motorrad im Norden unterwegs (etwas waermer ).

Die verschiedenen module repraesentieren anwendungsbereiche, die ich gedenke zu automatisieren. Tabellendefiniert mit generischen scripten. Tabellen koennen von hand erstellt werden, bzw. ich plane diese mit meinem programm zu generieren.
Derzeit ist das modul SignalCrossing (sollte eigentlich traffic light crossing heissen), laufbereit. VehicleOrigin und CrossingRoutes haben anfaenge, aber noch keine wirklich sinnvolle anwendung.

Die scripte sind sehr umfangreich dokumentiert und aufgeteilt in stufen der bedeutung, generisch, generalisiert und spezifisch.
Beispiel fuer generalisiert: Phasendefinitionen fuer kreuzungen sind wiederverwendbar und sind nicht spezifisch fuer bestimmte kreuzungen,
sondern fuer kreuzungstypen (hier SC)
Beispiel fuer spezifisch: Signaldefinitionen fuer eine bestimmte kreuzung auf der anlage gruppiert in modulen, hier z.b. SC_1
Generisch: Generell verwendet in the ampelsteuerung

Die rot/blauen kontakte sind nicht teil der ampelsteuerung, diese werden verwendet fuer den kreuzungsverkehr, auch ungesichert. Ist teilweise implementiert.

Fussgaengerampeln, linksabbieger mit blinklicht ist teil der definition.  Doppelspur mit separater linksabbiegerampel ist noch nicht teil der loesung, sowie andere
spezielle faelle. Die taster sind mehr oder weniger nur als test vorhanden. Kettenfunktion (gruene welle) zwischen ampeln ist auch definierbar.

Eine freundschaftliche warnung : Die scripte sind nicht geeignet fuer Lua anfaenger fals jemand sich fuer die implementierung selbst interessiert. Fuer die verwendung muss man diese aber nicht verstehen, es bedarf nur der sorgsamen definition der tabellen.

 Man kann variablen setzen in "Ereignisse" modul um debug ausgaben zu aktivieren. Ich habe nicht getestet die scripte zu kopieren in eine neue anlage. Ein timer mit 2s ist erforderlich fuer die ampelschaltung. In der demo ist alles enthalten, was man braucht um die scripte zu verwenden. 

Allerdings: Alle kommentare in English.    hier die entwurfsanalage   CA450BCA-57D8-4960-B0CA-4FA356B4C269
 

Falls jemand fragen hat, bitte nicht sofortige antwort erwarten.

Gruss
Gmd




 

 

Hallo,

habe mal wieder einen schritt weiter gemacht .. bugs aus der amplesteuerung enfernt und die crossing funktionen mit ampel fertiggestellt.
Dieses modul betreibt beliebige fahrzeuge and einer ampelkreuzung inclusive linksabbieger und blinker der fahrzeuge.
Warten auf fussgaenger ist noch noch nicht enthalten.
Das naechste modul is das depot .. hier werden fahrzeuge nach verschiedenen kriterien nach verschieden ausgesuchten zielen gestartet.
Die fahrzeuge haben ziele und koenen am ende in andere depots transportiert werden .. damit regele ich die virtuelle verbindung zwischen anlagen auf verschiedenen rechnern. Die ausfahrenden fahrzeuge werden an ein streckenmodul uebergeben dass die zielsetzung mit den MBS restriktionen uebernimmt und dafuer sorgt dass die fahrzeuge in die richtige richtung fahren. Kreuzungsmodule arbeiten unabhaengig und die fahrzeuge verhalten sich an kreuzungen gemaess den bedingungen des jeweiligen moduls behalten aber ihr ziel.
Ich habe noch ein paar weitere module zu erstellen bevor ich die meisten situationen abgedeckt habe.
Parkplatzverwaltung
Buskontenpunkt
Einfacher busbetrieb
und noch etliche speziellere module, die ich auch fuer fuessgaenger und radfahrer verwende.
Die tasten im bild sind zum test .. die verschiedenen modi koenen auch per script gesetzt werden und natuerlich auch von meinem programm.
Jedes der depots hat eine eigene definitionstabelle mit spezifischen zielen und rueckkehrkontakten. Die scripte sind allerdings generisch, wie alle anderen.

Das ganze ist dann ein netzwerk von eigenstaendigen modulen mit spezifischen eigenschaften, die die jeweiligen fahrzeuge kontrollieren gemaess den definierten bedingungen.
Spaeter werd ich dann auch animationen integrieren. Zunaechst mal nur die grundfunktionen, damit ich einen autonomen betrieb erreiche .
Hier noch ein bildchen der anlage, die ich derzeit als pilot projekt zusammenstelle.
Ist noch nicht ganz fertig .. Sie hate viele schnitstellen, portale und depots unter den bergen .. zu einem linken und rechten teil, der jeweils auf einem anderen rechner laeuft..

Gruss
gmd

Hello to Australia @gmd sorry, ist wohl noch etwas früh für dich jetzt, aber wird es auch wieder eine ID dazu geben oder ist das noch alles in Planung?

kind regards Atrus

6 hours ago, Atrus said:

Hello to Australia @gmd sorry, ist wohl noch etwas früh für dich jetzt, aber wird es auch wieder eine ID dazu geben oder ist das noch alles in Planung?

kind regards Atrus

Hallo Atrus,
Kein problem .. BDBF09FC-82AD-4535-B4D6-6EF60584E054 entwurf der demo mit dem code fuer das depot release, signal und signal crossing.. depot release ist etwas knapper dokumentiert als die anderen beiden module .. Ereignismodul ist "Vehicle Origin"
Naechstes modul ist routing .. uebernimmt ein fahrzeug vom depot und fuehrt es zum zugeordneten ziel ..
gruss
Gmd

Noch ein tip: wenn ihr den code an ChatGPT verfuettert, am besten nur jeweils ein modul, dann koennt ihr das auch in deutsch uebersetzen lassen oder erweiterungen machen, falls gewuenscht.
In meiner derzeitigen arbeit verwende ich 3 AI's, Juny und Sonnet von Jetbrains, und ChatGPT. ChatGPT liefert gute ergebisse mit LUA
ihr muesst nur aufpassen, denn MBS hat keine standard LUA implementierung, sondern weicht ab. In der source gibt es dazu eine beschreibung, die ihr auch dem AI fuettern koennt, dann kann er das beruecksichtigen.
Und fuer die skeptiker: In den letzen 4 monaten habe ich eine sehr umfangreiche "full stack", client server anwendung implementiert, wen es interessiert: NextJs, React mit Tailwing und Daisy, auf MySQL. Derzeit roughly 80K lines of code, no chance without an AI ..

Bearbeitet 5. November5. Nov von gmd

Hi gmd, danke für die ID. Werde ich ausprobieren. Bin gespannt!

LG Atrus

57 minutes ago, Atrus said:

Hi gmd, danke für die ID. Werde ich ausprobieren. Bin gespannt!

LG Atrus

Atrus,

beachte bitte folgendes: Direct hinter dem ausgang des depot's ist ein weiss/schwarzer kontakt der das fahrzeug direkt wieder zurueck in das depot schickt. Das ist zum test, da das routen modul noch nicht angeschlossen ist. Man kann die verschiednen modi ausprobieren .. the event is unter VO_1 Gleiskontakt wird ausgeloest.
Gruss
Gmd

Bearbeitet 5. November5. Nov von gmd

Hallo,
mal wieder ein update ..
BDBF09FC-82AD-4535-B4D6-6EF60584E054
Das modul "Vehicle Origin" ist in einer ersten version fertig, kombiniert mit dem strassenmodul. Nicht optimal da das MBS blockt wenn routen zugewiesen werden .. sieht man nach dem verlassen des depots. Das werde ich aendern und optimieren damit das ohne rucken geht.
Derzeit nur ein depot definiert und nur directe routen zu den zielen .. vor den zielen liegen kontakte die die fahrzeuge derzeit zum startdepot zurueckschicken .. das ist nur test .. derzeit sind keine geschwindigkeitsunterschiede per fahrzeugtyp oder streckenabschnitt realisiert, das kommt spaeter, wenn ich die anderen module in der grundversion fertig habe..
Naechstes modul ist die segmentierte strecke, womit sich verschiedene situationen kontrollieren lassen, unter anderem hat das ja mit der RoLa angefangen mit den wartepositionen der LKW, aber auch bus haltestellen usw, werden damit implementiert. Danach kommen kreuzungen ohne ampeln und fuer das strassenmodul auch indirecte fahrstrecken.
Gruss
Gmd

vor 2 Stunden schrieb gmd:

nach dem verlassen des depots ... rucken

Das ist immer so. Das Programm gefriert kurz ein wenn ein Fahrzeug ein Depot verlässt.

vor einer Stunde schrieb Phrontistes:

Das ist immer so. Das Programm gefriert kurz ein wenn ein Fahrzeug ein Depot verlässt.

Eine Zwangspause gibt es nur, wenn die zu berechnende Strecke sehr komplex ist (viele Abzweigungen) und das Studio mehrere hundert ms für die Berechnung benötigt.

10 hours ago, Phrontistes said:

Das ist immer so. Das Programm gefriert kurz ein wenn ein Fahrzeug ein Depot verlässt.

Neo hat die antwort .. der erste kontakt setzt das ziel fuer die fahrzeuge .. sind nur wenige kontakte aber einige moegliche alternativen, daher die kalkulationszeit, ist halt nicht wirklich multi threaded. Werde die zielzuweisung aufteilen und dem fahrzeug mitgeben, das ermoeglicht auch das dynamische aendern des ziels spaeter und sollte das rucken verhindern.
Gruss
Gmd

Hallo,
hier die naechste version
28AF80AB-856B-4921-81F1-6327301F48CE
Habe 2 weitere strategien ausprobiert, die letzte ist die aktive, wobei die kontakte fuer die route im fahrzeug liegen. Dabei ist zu beachten, dass die punkte nicht immer dicht liegen, das MBS muss immer noch kalkulieren und wenn man die erzeugte route fuer die gesamte strecke wieder ausliest, dann enthaelt sie zusaetzliche kontakte ... wenn man die kontakte dichter setz wird der kalkulationsaufwand veringert.
Auf meinem spielrechner merke ich immer noch ein kleines rucken, auf meinem arbeitsrechner ist das weg, der ist schneller.
Das depot muss noch optimiert werden .. es kann passieren dass fahrzeuge zu schnell ausgespuckt werden (settings) und auffahren . Das sind aber alles kleine dinge die dann stueck fuer stueck optimiert werden wenn ich die module tatsechlich einsetze .. Ich habe noch zwei weitere module definiert ... vordefinierte strecken fuer pkw, lkw, bus etc .. auf denen die fahrzeuge bestimmte eigenschaften bekommen und dann werden sie auf VO module (depots) verteilt .. random oder andere kriterien. Das naechste module ist der schattenparkplatz auf dem sets von fahrzeugen zwischengelagert werden umd verkehrsdichten je tageszeit zu simulieren. Dadurch koennen die anzahl der aktiven fahrzeuge gesteuert werden .. das sind dann die module mit denen ich meinen strassenverkehr implementiere.
Ahhh.. ich glaube ich habe noch nicht den parkplatz erwaehnt .. kleine und groessere parkplaetze mit gesteuerten zufahrten und abgahrten. Auch diese module kann fuer verschiedene situationen verwendet werden ..
Da ich jetzt erst mal die grundroutinen habe .. geht das schneller ..
Allerdings wird es bei 100+ fahrzeugen auf eine schnelle CPU ankommen wenn nicht einiges im MBS erweitert wird (true multi threading).
Ueber fahrstrassen ist das fuer die bahn beser zu loesen denke ich ..
Wenn mir jemand sagt, wie ich die dynamisch anlegen kann.. habe noch nicht gesucht, kenne nur den manuellen weg und der ist mir zu aufwendig.
Gruss
Gmd

vor 35 Minuten schrieb gmd:

fahrstrassen ... Wenn mir jemand sagt, wie ich die dynamisch anlegen kann..

Hallo gmd,
meines Wissens geht das Erstellen von Fahrstraßen nicht dynamisch (= über die EV), sondern nur manuell.

Viele Grüße
Götz

Bearbeitet 20. November20. Nov von Goetz
Schreibfehler korrigiert

1 hour ago, Goetz said:

meines Wissens geht das Erstellen von Fahrstraßen nicht dynamisch (= über die EV), sondern nur manuell.

ok danke ..
Habe die anlage aktualisiert.. sie enthaelt jetzt den beginn der "Vehicle Source", eine lademechanismus mit dem fahrzeuge mit bestimmten eigenschaften einfach in depots abgestellt werden .. das modul heisst VS .. spaeter kann mein programm damit fahrzeuge parken und dann laden mit verschiednen eigenschaften .. die taster sind als manueller test vorhanden .. ziel koennen verschiedene depots sein .. mit der zeit werden da wohl verschiedene kriterien anwendung finden.
Gruss
Gmd

Hallo, obiger katalog eintrag immer noch gueltig - ist aktualisiert
VS_Modul weitergebaut. Erste funktionen laufen. LOAD ONE (rot) started das jeweils erste fahrzeug auf der strecke und am kontakt werden fahreigenschaften zugewiesen und in das ausgewaehlte depot geschickt. Somit kann man typegesteuert mit spezifischen attributen fahrzeuge laden und auf depots verteilen .. zur zeit nur ein depot in der liste ..
Load ALL und Recall kommt als naechtes und depotzuweisung wird manuell, random, sequential erfolgen.
Recall holt die fahrzeuge zurueck... ist nur sinnvoll wenn jedes fahrzeug seinen platz hat.

Nochmals zur erklaerung warum ich das tue an diesem beispiel .. generell kann mein externes programm die definitionstabellen, die derzeit als test von hand definiert sind, erzeugen und ueber die schnittstelle laden, da ja alles in variablen abgelegt ist. Die grundfunktionalitaet ist mit generischen funktionen implementiert, die von den definitionen unabhaengig sind. Ausserdem kann ich ueber die schnittstelle dinge tun, die ich in Lua nicht kann. Selektieren von objekten, hinzufuegen usw. eindeutige namen vergeben, etc etc.
Mit dieser kombination kann ich dann komplexe steuerungen aufbauen, die ich dynamisch aendern kann ohne immer wieder zu programmieren und festgelegte starre strukturen wiederholt ablaufen zu lassen.

Allerdings koennen alle module natuerlich auch von hand verwendet werden und das VS oder auch VO ist dabei ganz nuetzlich..
Generell ist es viel einfacher mit tabellen zu arbeiten weil man den code nur einmal testen muss und es immer laeuft, wenn man die tabelle richtig definiert. Plazierung von kontakten muss man auch manuell machen.. mein programm kann das automatisch fuer die verschiedenen grundmuster basierend auf template objekten (vorlagen).

Das prinzip ist halt fuer typische scenarien abstraktionen zu schaffen, die man mit generischen funktionen implementiert. Der phantasie sind dabei keine grenzen gesetzt mehr und mehr verfeinerte konzepte zu schaffen. Es ist sind halt softwaremodule und keine landschaftsmodule.
Gruss
Gmd

Hallo nochmal,
anlage ist nochmals erneuert, habe load all und recall implementiert, allerdings funktioniert recall nur wenn das fahrzeug ausserhalb eines depots ist.. das werde ich noch erweitern.
Aber soweit ist die erste version VS fertig, habe noch nicht entschieden was als naechstes kommt. Mal sehen.
Gruss
Gmd

Hallo,

habe die anlage aktualisiert mit der letzten software version. Etwas aufgeraeumt, kleine inkonsistenzen beseitigt und ein depot display zugefuegt damit ich sehen kann was im depot passiert.
Jetz kann man oedentlich verkehr erzeugen, wenn man die module dupliziert oder erweitert und mehr als ein VO betreibt ..
Als naechstes habe ich entschieden das SR modul zu erweitern und indirekte routen fuer ziele zu ermodeglichen, damit der ablauf mehr variation bekommt und die kreuzungen auch wirklich benutzt werden .
Gruss
gmd

Hallo,
mal wieder ein update 904C5AD0-127E-4B96-943A-5596AEE8E457
etwas mehr fehlertoleranz eingebaut und das VO Vehicle Origin kann jetzt auch direct oder indirect setzen fuer die nachfolgende routenauswahl.
Das SR Street Route modul kann jetzt indirekte routen ausfuehren, habe eine definiert..
Werde jetzt erst mal meine specs fuer die module erneuern und ueberdenken, nach den ersten erfahrungen.
Was wirklich nervt ist der Lua editor, ist halt viel zu basic fuer das was ich tue, also verwende ich VS Code aber das bedeuted immer kopieren.. Ich habe all meine script module in VS Code und aendere auch dort und nur zum test kopiere ich die jeweiligen teile erneut in das MBS.
Ein besserer editor oder direkter anschluss eines externen hilft auch nur bedingt, da die scripte ja verteilt sind. Waere nur nuetzlich mit globalen suchfunktionen und besseren strukturierungsmoeglichkeiten.
Naja, vielleicht kommt ja mal ein library konzept mit einer IDE (Integrated Development Environment), aber ich denke solange nur wenige benutzer Lua verwenden und noch weniger wirklich intensiv, passiert da nichts auf der front.

Gruss
Gmd

Hallo,
hier die uebersicht ueber die derzeit geplanten / implementierten module. Das ist ausschliesslich verkehr, also keine kraene, baustellen, schiffsverladung usw.
Vehicle Traffic - Generic Software Modules

Module List

VEHICLE RELATED

VS - Vehicle Source
VO - Vehicle Origin
VP - Vehicle Parking
VW – Vehicle Wait

CROSSINGS

SC – Signal Crossing
UC – Unsecured Crossing
RC – Rail Crossing
RO - Roundabout

ROUTE RELATED

SR – Street Routes
SS – Segmented Street Routes
FD – Forked Drive Through
FE – Forked Dead End

MISCELANEOUS

RO – RoLa
VL – Vehicle Load / Unload

Module Purpose / Application

VEHICLE RELATED

VS
“Vehicle Source” is responsible for loading vehicles from categorised vehicle groups—typically located on park tracks—into selectable depots. The park track defines the vehicle type, and during loading, type-specific vehicle parameters are automatically applied.

VO
“Vehicle Origin” defines a vehicle storage system based on depots. Vehicles can be released using different criteria and route-determination modes. The module determines destination, forward target, and return target, and stores these values on the vehicle for use by connected modules.

VP
“Vehicle Parking” manages complex parking areas implemented with virtual tracks and contacts. It supports large-scale parking logic with criteria for entry control, release ordering, park duration, and other advanced features. It can also be used for transport logistics and other parking-related applications.

VW
“Vehicle Wait” provides queue management for temporary vehicle stoppage. It is ideal for bus lanes, taxi queues, drop-off points, and similar scenarios, and can be combined with “Forked Drivethrough” (FD) for more advanced flow control.

CROSSINGS

SC
“Signal Crossing” manages signal-controlled road intersections. It supports complex multi-arm layouts, pedestrian phases, turn-specific signals, and coordinated phase timing for consistent traffic flow.

UC
“Unsecured Crossing” handles non-signalised junctions using right-of-way rules, priority logic, and yield behaviour. Ideal for simple or low-traffic intersections.

RC
“Rail Crossing” controls road–rail intersections, managing barriers, warning lights, approach triggers, and safety logic to prevent road traffic from entering when trains are present.

RO
“Roundabout” provides traffic flow management for circular junctions, including priority handling, entry gap detection, and smooth merging for continuous movement.

ROUTE RELATED

SR
“Street Routes” determines full vehicle paths using sequential contacts. Supports direct and indirect routing, speed control, animations, and integration with vehicle origin and depot systems.

SS
“Segmented Street Routes” define single stretches of road where vehicles wait in specific positions before progressing. Segments can operate as single-lane or multi-lane sections and allow controlled, ordered movement through defined waiting points. Signal controlled or not.

FD
“Forked Drivethrough” provides a siding or lay-by for vehicles such as buses or taxis to queue for loading and unloading. It represents a separate lane parallel to the main road, with defined entry and exit points, and can be configured with or without a passing lane so through traffic can remain unaffected.

FE
“Forked Dead End” supports branching street layouts where one or more paths terminate, enabling turning loops, reversing logic, and service operations for taxis, delivery vehicles, and shuttles.

MISCELANEOUS

RO
“RoLa” (Rollende Landstrasse) handles loading lorries onto rail wagons, coordinating rail departure, unloading, and transfer between road and rail for intermodal transport systems.

VL
“Vehicle Load / Unload” manages areas where vehicles exchange cargo or passengers, including stall assignment, queuing, timed loading operations, and integration with logistics workflows.

---

und in Deutsch:
Vehicle Traffic – Generische Softwaremodule

Modulliste

FAHRZEUGBEZOGEN

VS – Vehicle Source
VO – Vehicle Origin
VP – Vehicle Parking
VW – Vehicle Wait

KREUZUNGEN

SC – Signal Crossing
UC – Unsecured Crossing
RC – Rail Crossing
RO – Roundabout

ROUTENBEZOGEN

SR – Street Routes
SS – Segmented Street Routes
FD – Forked Drive Through
FE – Forked Dead End

SONSTIGES

RO – RoLa
VL – Vehicle Load / Unload

Modulzweck / Anwendung

FAHRZEUGBEZOGEN

VS
„Vehicle Source“ ist verantwortlich für das Laden von Fahrzeugen aus kategorisierten Fahrzeuggruppen – typischerweise auf Abstellgleisen – in auswählbare Depots. Das Abstellgleis definiert den Fahrzeugtyp, und beim Laden werden automatisch typspezifische Fahrzeugparameter gesetzt.

VO
„Vehicle Origin“ definiert ein fahrzeugbasiertes Lagersystem auf Grundlage von Depots. Fahrzeuge können nach verschiedenen Kriterien und Routenermittlungsmodi freigegeben werden. Das Modul bestimmt Ziel, Vorwärtsziel und Rückgabeziel und speichert diese Werte am Fahrzeug zur Nutzung in angeschlossenen Modulen.

VP
„Vehicle Parking“ verwaltet komplexe Parkbereiche, die mit virtuellen Gleisen und Kontakten umgesetzt sind. Es unterstützt großflächige Parklogik mit Kriterien für Einfahrtskontrolle, Ausfahrtreihenfolge, Parkdauer und weiteren Funktionen. Es kann auch für Transportlogistik und andere parkbezogene Szenarien genutzt werden.

VW
„Vehicle Wait“ stellt Warteschlangenmanagement für temporäre Fahrzeugstopps bereit. Ideal für Busspuren, Taxiwarteschlangen, Kurzhaltebereiche und ähnliche Szenarien. Kann mit „Forked Drivethrough“ (FD) kombiniert werden, um erweiterten Fluss zu steuern.

KREUZUNGEN

SC
„Signal Crossing“ steuert signalgesteuerte Straßenkreuzungen. Unterstützt komplexe mehrarmige Layouts, Fußgängerphasen, Abbiegesignale und koordinierte Phasenabläufe für einen gleichmäßigen Verkehrsfluss.

UC
„Unsecured Crossing“ behandelt ungesicherte Kreuzungen ohne Signale mittels Vorfahrtsregeln, Prioritätslogik und Vorsichtshalten. Geeignet für einfache oder wenig befahrene Kreuzungen.

RC
„Rail Crossing“ kontrolliert Bahnübergänge im Straßenverkehr, inklusive Schranken, Warnlichtern, Annäherungstriggern und Sicherheitslogik, um Straßenfahrzeuge bei Zugverkehr zu stoppen.

RO
„Roundabout“ steuert Verkehrsflüsse auf Kreisverkehren, inklusive Vorfahrtregelung, Einfahrtslückenerkennung und kontinuierlichem Kreisbetrieb.

ROUTENBEZOGEN

SR
„Street Routes“ bestimmt vollständige Fahrzeugrouten anhand sequenzieller Kontakte. Unterstützt direkte und indirekte Routen, Geschwindigkeitssteuerung, Animationen und die Integration mit Fahrzeugdepots und Ursprungssystemen.

SS
„Segmented Street Routes“ definieren einzelne Straßenabschnitte, in denen Fahrzeuge an festgelegten Positionen warten, bevor sie weiterfahren. Die Segmente können ein- oder mehrspurig betrieben werden und ermöglichen kontrollierte, geordnete Bewegungen durch definierte Wartepunkte – signalgesteuert oder ungesteuert.

FD
„Forked Drivethrough“ stellt eine Ausweichspur oder Haltebucht für Fahrzeuge wie Busse oder Taxis bereit, um zu laden oder zu entladen. Es handelt sich um eine parallel zur Hauptstraße verlaufende Spur mit definierten Ein- und Ausfahrten, optional mit Überholspur, sodass der Durchgangsverkehr ungestört bleibt.

FE
„Forked Dead End“ unterstützt verzweigte Straßenlayouts, bei denen ein oder mehrere Pfade enden. Ermöglicht Wendeschleifen, Rückfahrlogik und Serviceabläufe für Taxis, Lieferfahrzeuge oder Shuttlefahrzeuge.

SONSTIGES

RO
„RoLa“ (Rollende Landstrasse) steuert das Aufladen von LKWs auf Bahnwagen, koordiniert Abfahrten, Entladevorgänge und den Übergang zwischen Straßen- und Schienenbetrieb in intermodalen Transportsystemen.

VL
„Vehicle Load / Unload“ verwaltet Bereiche, in denen Fahrzeuge Güter oder Passagiere aufnehmen oder abgeben. Beinhaltet Stellplatzzuweisung, Warteschlangen, zeitgesteuerte Ladeprozesse und Einbindung in logistische Abläufe.

Gruss
Gmd

Hallo,
habe weiter an den specs gearbeitet und mal ein data sheet mit gebrauchsanleitung fuer das VS modul gemacht.
Anbei das PDF, die mbp datei fuer das beispiel element und als zip die lua datei fuer VS-Code wie im PDF beschrieben.
I habe, bzw. mache data sheets fuer alle module fuer meine entwicklung. Benutzeranleitungen aber nur wenn wirkliches
interesse besteht, da fuer die anderen module mehr beschreibung fuer die konfiguration noetig waere.
Die vorgehensweise bei der installation ist fuer alle gleich und ide lua files fuer VS-Code habe ich ohnehin. Also wer moechte,
sagt bescheid.

VS hat noch nicht alle funktionen die in der spec erwaehnt sind und falls es ein problem gibt, oder ich etwas vergessen oder uebersehen habe, dann meldet euch. Vielleicht kann ich ja den ein oder anderen motivieren mehr Lua zu benutzen.
Jedes modul laesst sich ja anpassen und erweitern allein durch definition, ohne viel programmierung. Von hand ist die namenspflege natuerlich etwas muehsamer als wenn man das automatisiert.

Gruss
Gmd

VS_module.zip VS_Element.mbp

MBS_datasheet_VS.pdf

Bearbeitet 23. November23. Nov von gmd
pdf typos updated

Hallo,
hatte gestern und heute noch ein paar stunden und habe weitere specs, elemente und software gebaut.
1) Autobahn mit ueberholverkehr (dynamisch und geschwindigkeitsabhaengig)

2) Bus depot mit routenangabe und fahrplanvergabe

3) Parkbuchten mit dynamischer zuweisund und vielen features fuer verschiedene fahrzeugtypen mit verschiednen kriterien.

Die Parkbuchten sind fast fertig .. mit bypass oder drivethrough wenn voll, oder fahrzeugtyp nicht passt, mit kontrollierter parkzeit, und vieles mehr. Auch voellig generisch mit beliebig vielen buchten, einfache oder mehrfache zu- und abfahrt.

Beispieldefinition fuer 4 parkbuchten
local slotTemplates = { {
index = "1-4",
entryTarget = {"PB_1_Entry" },
bypass = {"PB_1_Bypass" },
driveThrough = {"PB_1_Exit_Alternative" },
allowedTypes = {"PKW"},

-- Contacts used to drive INTO the slot (sequence of contacts)

routeToSlot = {"PB_1_TSlot_*" }, -- slot target

-- Track that represents the actual parking location

slotTrack = "PB_1_SSlot_*",

-- Contacts used to create target for reversing OUT of the slot

routeToReverse = { "PB_1_Exit_2", "PB_1_Exit_3", },

-- Track used to detect “backed out far enough”

reverseTrack = "PB_1_RSlot_*",

-- Forward Exit

finalExitTarget = {"PB_1_Exit"},

alternateExitTarget = {"PB_1_Exit_Alternative"},

},

Wildcard * wird fuer namesexpansion verwendet, dann braucht man nicht soviel zu tippen.
Verwende dieses modul auch fuer LKW parken in speditionen usw.
Die anbindung and die anderen module ist vorhanden, dh. ein fahrzeug kann auf einer route zwischendurch an verschiedenen punkten parken ohne dass das gesamtziel verlorengeht. Alle module koennen daten aus den fahrzeugen auswerten, die den fahrzeugen vom VS modul mitgegeben werden koennen oder auch dynamisch von der schnittstelle gesetzt werden. Das hier nur mal als grober ueberblick.
Viele kombinationen denkbar.
Gruss
Gmd