Menu

Versenyfeladat középiskolai tanulók részére

150 150 Daniel Farago

(This page is intentionally written in Hungarian as targets Hungarian high school students.)

A feladat megoldásának határideje: 2018. július 15.

A megoldásokat dokumentációval együtt a contest@ip-camp.com címre várjuk.

A feladattal kapcsolatban kérdéseket a bejegyzés alatti fórumban, illetve a contest@ip-camp.com címen e-mailben tehettek fel.  Az egyenlő esélyek érdekében az e-mailben feltett kérdések az azokra adott válasszokkal együtt ki fognak kerülni a fórumra is.

A feladat specifikációjához olvass tovább!

Bevezetés

A napjaink modern gépjárműveivel szemben támasztott egyre magasabb szintű biztonsági és kényelmi követelmények csak a járművekbe épített egyre több elektronikai megoldással elégíthetők ki.  A megoldandó feladatok bonyolultságának növekedésével a korábban alkalmazott centralizált elektronikai rendszerek – amikben egy központi vezérlőegység felügyeli és irányítja az autó összes funkcióját – egyre inkább átalakultak decentralizált, úgynevezett elosztott rendszerekké.  Az egyes elemi funkciók megvalósítása egy-egy külön erre a célra dedikált vezérlőegység feladata, a magasszintű funkciók pedig az egyes vezérlőegységek együttműködéseként valósulnak meg.

Jó példa erre az ESP (elektronikus menetstabilizátor) működése, melyben a kerekek sebességét mérő érzékelőktől kezdve, a fék és szervokormány vezérlőegységein át a motorvezérlőig rengeteg szenzor és beavatkozó vesz részt.

Az ESP működésében résztvevő vezérlőegységek

A fenti trendnek köszönhetően ma már nem ritka, hogy egy-egy autóban akár százötvennél is több kis számítógép kap helyet, melyek feladatuk ellátásának érdekében folyamatos kommunikációs kapcsolatban állnak egymással.  Az adatokat szignáloknak nevezett, konkrét fizikai vagy logikai jelentéssel bíró adategységekben továbbítják egymás felé.  Egy-egy szignál lehet például a jármű sebessége, az egyes kerekek kerületi sebessége, vagy a kormányzott kerekek szöge, illetve a gyújtáskapcsoló állapota is.  Mivel a különböző szignálok értékkészlete eltérő, így azok bitben kifejezett mérete is különbözik egymástól.  Például a jármű sebességének kellő pontossággal történő ábrázolásához akár 16 bitre is szükség lehet, míg a gyújtáskapcsoló állapotának (ON/OFF) leírására egyetlen bit is elegendő.

A szignálok egy másik fontos jellemzője a periódusidejük, vagyis az az idő, ami az adott szignál két egymást követő értékének elküldése között eltelik.  A szignálok küldési periódusideje leginkább a szignál által reprezentált fizikai jellemző tulajdonságaitól függ.  Például a motor hőmérséklete nem tud egyik pillanatról a másikra jelentősen megváltozni, így az értékét hordozó szignált az esetek többségében elegendő lehet másodpercenként elküldeni a hálózaton.  Ezzel szemben a kerekek sebessége hirtelen is változhat (fékezésnél blokkolás, erős gyorsításnál kipörgés), a jármű kicsúszására való gyors reagálás pedig kritikus, így a keréksebességeket hordozó szignálok tipikus periódusideje 5-100 milliszekundumos nagyságrendbe esik.

Feladat

A járművek fejlesztése során tesztelési céllal, később a használat során pedig diagnosztikai céllal is szükséges lehet a kommunikációs szignálok megfigyelése, értékeinek naplózása, analizálása.  Ennek támogatására az autókban általában elhelyezésre kerül egy szignál-adatgyűjtő vezérlőegység is, mely a jármű kommunikációs hálózatára csatlakozva képes összegyűjteni a megfigyelendő jeleket, és vezetéknélküli hálózaton továbbítani például egy felhőalapú adatfeldolgozónak.

Jármű – felhő kommunikáció

A feladat egy olyan szoftveres eszköz kifejlesztése, mely a járművek kommunikációjának szimulálásával lehetővé teszi felhőalapú adatfeldolgozók tesztelését.

Követelmények

  • A szoftvert – ami lehet webalkalmazás, vagy egyszerű parancssorból futtatható alkalmazás is – Java vagy C# (.NET Core) nyelven kell elkészíteni.
  • Az eszköznek képesnek kell lennie HTTP és az IoT világban elterjedten alkalmazott MQTT protokollok használatával is kapcsolódnia a felhőben futó feldolgozóhoz.  Az éppen használni kívánt protokollt és a kapcsolat kiépítéséhez szükséges további paramétereket vagy a webes API-ján keresztül, vagy parancssori argumentumként kapja meg.
  • A megvalósítás egyaránt támaszkodhat a Java nyelv stream alapú IO, vagy buffer alapú NIO könyvtáraira. Az első esetben ügyelni kell a helyes szálkezelésre!
  • A szoftver által szimulálandó egy-egy járműtípushoz tartozó keretek (frame) paramétereit (azonosító, tartalmazott szignálok, azok mérete és kereten belüli elhelyezkedése stb.) JSON fájlok tartalmazzák, melyeket a program szintén vagy a webes API-ján keresztül, vagy parancssori argumentumként kap meg.
  • A szignálok értékeinek generálása a szimuláció során történhet véletlenszerűen, de lehetőleg a teljes értékkészlet kihasználásával.
  • A szignálgenerátor megvalósítása olyan kell legyen, hogy később a véletlenszám generátoron alapuló megoldás könnyen lecserélhető legyen például egy valódi járműben felvett napló alapján működő generátorra. Ez a gyakorlatban a generátor osztály egy célszerűen definiált interfészen keresztül történő elérését jelenti.
  • A program a működése során folyamatosan jelenítsen meg statisztikai adatokat a felhasználó számára – például az autónként kiküldött keretek számáról – webes megvalósítás esetén egy weboldalon, parancssori megvalósítás esetén pedig az alapértelmezett kimeneten.
  • A forráskód a – megértéshez szükséges mértékben – legyen ellátva kommentekkel, illetve készüljön egy rövid, a program használatát leíró felhasználói dokumentáció is.

Extra követelmények

Az alábbi követelmények teljesítése nem része az alapfeladatnak, de megvalósításuk az elbírálás során plusz pontokat jelent:

  • A Java NIO könyvtáron alapuló megoldás – annak kisebb erőforrásigénye miatt – preferált.
  • A szignálok értékeinek ugrásmentes változtatásának érdekében a generátor szimuláljon egy tetszőlegesen választott folytonos (korlátos) sztochasztikus folyamatot.
  • Elosztott működés támogatása master-slave architektúrában: Komolyabb terhelések szimulálásának érdekében a programot legyen lehetőség több végponton is futtatni. Ebben az esetben a végpontokon futó slave példányok működését egy kijelölt master példány felügyelje.  A felhasználó a master példánynak adhatja ki az utasításait, ami ezek alapján a terhelés egyenletes elosztását figyelembe véve elindítja, és felkonfigurálja a rendelkezésre álló slave végpontokat.

Példa

A következő JSON részlet példa a program egy lehetséges bemenetére:

{
  "vehicleType":"MyFavouriteVehicleType",
  "frames": [
    {
      "name":"VehicleStatus",
      "frameID":1,
      "period":1000,
      "signals": [
        {
          "name":"EngineRPM",
          "position":0,
          "length":16
        },
        {
          "name":"EngineTemperature",
          "position":16,
          "length":8
        },
        {
          "name":"VehicleSpeed",
          "position":24,
          "length":12
        },
        {
          "name":"IgnitionStatus",
          "position":36,
          "length":1
        },
        {
          "name":"Gear",
          "position":37,
          "length":3
        }        
      ]
    },
    {
      "name":"ESPStatus",
      "frameID":20,
      "period":10,
      "signals": [
        {
          "name":"BrakeForceRR",
          "position":0,
          "length":12
        },
        {
          "name":"BrakeForceRL",
          "position":12,
          "length":12
        },
        {
          "name":"BrakeForceFR",
          "position":24,
          "length":12
        },
        {
          "name":"BrakeForceFL",
          "position":36,
          "length":12
        }        
      ]
    }
  ]
}

A leíró a MyFavouriteVehicleType által küldött üzenetek felépítését és időzítéseit tartalmazza.  Ez alapján a MyFavouriteVehicleType típusú járművek két üzenetet küldenek a felhőben futó feldolgozónak: VehicleStatus (1000 milliszekundumonként) és ESPStatus (10 milliszekundumonként).  A szignálok keretben elfoglalt pozíciója és mérete bitben van megadva.  A szimulátornak a fenti JSON részlet alapján a következő két üzenetet (gyakorlatilag bájt tömböt) kell összeállítania és megfelelő időzítésekkel folyamatosan küldenie a felhőbe:

VehicleStatus (1000 milliszekundumonként)

ESPStatus (10 milliszekundumonként)

VehicleID

Minden üzenet egy 4 bájtos (uint32) VehicleID mezővel kezdődik.  Ennek a mezőnek a funkciója a járművek egyedi azonosítása.  Tehát, ha például a szimulátornak 500 db MyFavouriteVehicleType típusú járművet kell szimulálnia, akkor minden 1000 milliszekundumban kiküld 500 db VehicleStatus üzenetet és minden 10 milliszekundumban 500 db ESPStatus üzenetet páronként különböző VehicleID-val.

A VehicleID értékek kiosztása nullától kezdődően és folytonosan történjen, annak érdekében, hogy az üzenetek feldolgozásánál könnyen meg lehessen állapítani a járművek típusát.  Ha a program a bemenetén két jármű leíróját is megkapja – sorrendben: MyFavouriteVehicleType és MyHatedVehicleType -, és a feladat az, hogy 500 db MyFavouriteVehicleType típusú és 1200 db MyHatedVehicleType típusú jármű kommunikációját szimulálja, akkor az első 500 VehicleID (0 – 499) MyFavouriteVehicleType típusú autókhoz, míg a következő 1200 VehicleID érték (500 – 1699) MyHatedVehicleType típusú autókhoz tartozzon.

FrameID

A FrameID (1 bájtos) mező a keretek azonosítására szolgál.  Értéke a JSON-ben megadott frameID értékével kell, hogy megegyezzen.

Szignálok

Az azonosító mezők után következik a keret által tartalmazott szignálok elhelyezése.  Mivel az azonosítók összesen 40 bitet foglalnak el a keretek elején, a JSON-ben megadott bit-pozíciókat a bájt tömbben való pozíció meghatározásához 40-el módosítani kell (lsd. ábra).  A keretekben esetlegesen előforduló nem kihasznált területeket nullával kell inicializálni.

Leave a Reply

Your email address will not be published.

%d bloggers like this: