Alapok: -------- - a vörös távirányító: a vonatokat és a váltókat állítja. A nagy fekete dobozzal van összekötve, a parancsokat közvetlenül a sínre küldi. Független rendszer a BBB-ktől és a Raspberry Pi-től. - BBB: mikrovezérlők, amiken fut(ott) az állapotgép alapú elosztott biztonsági logika. Minden váltóhoz tartozik 1 BBB (kivéve talán az ikerváltót; ott nem emlékszmem, hogy 1 vagy 2 BBB van-e). Mindegyik BBB-re rá van csatlakoztatva annyi kis mikro vezérlő az oldalára, amennyi szakasz kapcsolódik ahhoz a váltóhoz. Jellemzően 3, max. 4. - illusztráció: https://github.com/ftsrg/BME-MODES3/wiki/HW-BeagleBone-expander-assignments - szakaszfoglaltság-érzékelők: dedikált eszközök, amiket vásároltunk a DigiToolstól. Egy érzékelő lapra 8 szakaszt lehet bekötni. Az érzékelő lapokból van 3-4, amiket sorban kötöttünk össze egy telefonkábellel. Az összekötött szakaszfoglaltság-érzékelők egy nagy vektort alkot, amiben minden egyes pozíción lévő bit az adott "indexű" szakasz foglaltságát jelző. A láncba összekötött szakaszfoglaltságok végül a Raspberry Pi-be futnak be, amin van egy kis szoftver, ami broadcastolja az állásokat a hálózaton (illetve igény esetén le is kérdezhető). - váltóállás: ha jól emlékszem, akkor a BBB-k szolgáltatják ezt az információt, valamilyen spéci módon. Változás esetén (egyenes / kitérő) elbroadcastolják a hálózaton az állást, de lehet, hogy lekérdezhető is az aktuális váltó állása. - USB adapter: van egy kis kütyü, amivel a "vörös távirányító" parancsait lehet a pályára kiadni, a távirányító nélkül. Ez arra jó, hogy a váltóállásokat állítsuk, illetve a vonatok sebességét és irányát tudjuk állítani programozottan a Pi-ről. - Raspberry Pi: az asztal felső oldalán van egy érintőkijelző, amihez a hátoldalon egy Pi tartozik. A Pi az egész rendszernek az egyik legfontosabb eleme, ugyanis hozzá van bekötve a szakaszfoglaltság-érzékelő lánc (ő tárolja el az aktuális foglaltásgokat és teszi lekérdezhetővé a hálózaton keresztül). A Pi-n fut ezenkívül az MQTT broker, ami a hálózati kommunikációban elengedhetetlen. Ezen a brokeren futnak különböző topikok hierarchikusan: szakaszfoglaltság, váltóállás, a biztonsági logika lezár/enged parancsai. A hierarchia első szintje a szakasznak / váltónak a száma, a második szintje, hogy milyen topik (ld előző lista). Ezenkívül a Pi-n fut még egy Java FX-es GUI-s alkalmazás, ami a pálya térképét vetíti ki és jeleníti meg rajta a vonatok pozícióját, a váltók állását és a szakaszok lezártságát (engedélyezett / lezárt-e az adott szakasz). Ezenkívül az érintőkijelző segítségével tudjuk engedélyezni a szakaszokat, állítani a váltókat és a vonatok sebességét is. (A szakaszok engedélyezése és letiltása biztos, a váltók és a vonatok állítása annyira nem biztos, hogy tényleg működik.) 1. DNS is king! - root.modes3.intra: Raspberry Pi-nek a DNS címe - mindegyik BBB-nek volt egy címe, ami azt hiszem a váltó számának felel meg és utána jön a modes3.intra suffix (t1-t6.modes3.intra) - DNS nélkül nem tudnak a BBB-k a Pi-vel kommunikálni, mert a rajtuk futó szoftverbe ez van belefordítva (ha jól emlékszem, akkor maga a DNS cím paraméterezhető, de akkor újra deployolni a kódokat a BBB-kre) - a BBB-k nem érik el a Pi-t, akkor nem tudjuk a váltók állását kiolvasni / lehallgatni a hálózaton, mert a BBB-k nem tudják elküldeni a megfelelő MQTT topikra az üzenetet, a Pi-n futó brokernek - jó eséllyel a Pi-n elindul a broker ettől függetlenül; tehát a szakaszfoglaltásgokat ki lehet olvasni, ha rácsatlakozunk az asztal ethernet hálózatára, kitaláljuk a Pi IP címét és hogy melyik porton fut a broker (elvileg 1883, ld. https://github.com/ftsrg/BME-MODES3/wiki/Starting-the-demonstrator) 2. Dokumentáció a repóhoz mellékelve: - https://github.com/ftsrg/BME-MODES3/wiki/Getting-Started - https://github.com/ftsrg/BME-MODES3/wiki/Starting-the-demonstrator 3. legegyszerűbb módja a "hálózati hallgatózásnak": - MQTT broker: a Pi-n fut elvileg a 1883-as porton (ld. https://github.com/ftsrg/BME-MODES3/wiki/Starting-the-demonstrator) - szakaszfoglaltság leolvasó: szintén a Pi-n fut és a szakasz esetén a "/modes3/segment/occupancy/{id}" témára küld egy SegmentOccupancyMessage-t. Váltó esetén a váltónak is van egy "segment" száma (ld. az asztalra gravírozott "sense" prefix a váltók mellett). - protobuf üzeneteket használunk: - üzenetek szöveges leírása: https://github.com/FTSRG/BME-MODES3/wiki/Network-messages - üzenetek protobuf definíciója: https://github.com/ftsrg/BME-MODES3/tree/master/src/java/messaging/proto.messages/src/main/proto - a protobuf definíciókat egy protobuf compilerrel az adott célnyelvre lehet fordítani. - java célnyelv esetén a repót leklónozva, gradle 4.2 (muzeális darab, remélhetőleg megy újabb gradlevel is)-t telepítve és a src/java könyvtáron belül a "./gradlew :messaging:hu.bme.mit.inf.modes3.messaging.proto.messages:generateProto" parancsot kiadva legenerálhatóak a messaging/messages projektben az src/java mappába (ha jól emlékszem), a .java forrásfájlok: https://github.com/ftsrg/BME-MODES3/tree/master/src/java/messaging/messages - alternatívaként keresni kell egy java protobuf fordítót és legenerálni a java osztályokat a .proto definíciókból - topikok a hozzájuk tartozó üzenettípusok nevével: https://github.com/FTSRG/BME-MODES3/blob/master/src/java/messaging/messages/src/main/resources/topicMapping.json - ezután írni kell egy MQTT hello world típusú alkalmazást, amivel rácsatlakozunk az adott topikokra (szakaszfoglaltság esetén többre is, mert az {id} placeholdert az összes szakaszértékre + "sense" értékre be kell helyettesíteni) és hallgatózunk, hogy jön-e rajtuk az adott üzenet. Ha jön, akkor azt ki tudjuk olvasni a .protoból fordított javas protobuf üzenetobjektumokkal (hiszen ilyen formátumban fog megérkezni az üzenet). 4. bonoylultabb módja a "hálózati hallgatózásnak" (ha valki tudja az xtended fordítani): - előzetes feltételek: a teljes repót le kell fordítani a projektek közötti függőségek miatt (a keletkező jarokat nem publikáltuk sehol) - ld https://github.com/ftsrg/BME-MODES3/wiki/Getting-Started#getting-started-as-a-developer - a components/sample projektben van egy példa alkalmazás, amely hallgatózik a szakaszok foglaltságára és ha egy szakasz legalább kétszer lett foglalt, akkor lekapcsolja (nem engedi a vonatot áthaladni) - projekt: https://github.com/ftsrg/BME-MODES3/tree/master/src/java/components/sample - lekapcsoló "logika": https://github.com/ftsrg/BME-MODES3/blob/master/src/java/components/sample/src/main/java/hu/bme/mit/inf/modes3/components/sample/SampleComponent.xtend - az alkalmazás belépési pontja: https://github.com/ftsrg/BME-MODES3/blob/master/src/java/components/sample/src/main/java/hu/bme/mit/inf/modes3/components/sample/app/Main.xtend - szükséges command-line paraméterek: --address --port - ha ez a kód működik, akkor a foglaltság-változásokat már ki lehet olvasni automatikusan és ezen elindulva lehet saját kódot írni a hálózati API doksi mentén (ld lentebb) - (érdeklődőknek) bővebb leírás arról, hogy a SampleComponentBridge osztály és a függőségei mit csinálnak, lásd hálózati API doksi: https://github.com/FTSRG/BME-MODES3/wiki/On-the-communication-component-of-the-API 5. bonyolultabb módja a hallgatózásnak: - ezt a hálózati API doksit elolvasni: https://github.com/FTSRG/BME-MODES3/wiki/On-the-communication-component-of-the-API - és a hozzá tartozó projekteket megkeresni a repóban, lefordítani és összelegózni a repóban lévő projektekből: https://github.com/ftsrg/BME-MODES3/tree/master/src/java - ha jól emlékszem, akkor a src/components alkönyvtárban már magasabb szintű alkalmazások is vannak, amiket újra fel lehet használni: https://github.com/ftsrg/BME-MODES3/tree/master/src/java/components - occupancyquery: a Pi-n futó szakaszfoglaltság-leolvasó és továbbító kód https://github.com/ftsrg/BME-MODES3/tree/master/src/java/components/occupancyquery - touchboard: a Pi-n futó és az érintőkijelzőn megjelenített alkalmazás kódja https://github.com/ftsrg/BME-MODES3/tree/master/src/java/components/touchboard - trackelemtcontroller: BBB-ken futó kód, amivel a váltók állását lehet beállítani és kiolvasni, illetve a szakaszokat lehet engedélyezni és letiltani: https://github.com/ftsrg/BME-MODES3/tree/master/src/java/components/trackelementcontroller/src/main/java/hu/bme/mit/inf/modes3/components/trackelementcontroller safetylogic: a biztonsági logika. az állpotgép-alapú a "componentlevel", a Viatra Query alapú a "systemlevel", lásd: https://github.com/ftsrg/BME-MODES3/tree/master/src/java/components/safetylogic