• Nem Talált Eredményt

A hálózatba kötött autó

In document AZ OKOS VÁROS (Pldal 135-138)

Nemeslaki András

B) Városok általános állapota

7.5. A hálózatba kötött autó

A hálózatba kötött autó, vagy angolul a connected car kifejezés egyre inkább elterjedt az utóbbi években. De mit is jelent ez, és mi az elgondolás előnye? A hálózatba kötött autó lényege az, hogy a jármű képes különböző, jellemzően vezeték nélküli interfészeken ke-resztül egyfelől az internetre kapcsolódni, másfelől különböző más járművekkel, illetve infrastrukturális elemekkel közvetlenül is kommunikálni mint a tárgyak internetének (IoT, Internet of Things) egy eleme.

Kezdetben jellemzően infotainment (azaz információ és szórakoztatás, angolul infor-mation + entertainment) jellegű szolgáltatások miatt volt szükség az internetes kapcsolatra.

Másfelől viszont érdemes azt is figyelembe venni, hogy a mai autók rengeteg szenzorral vannak felszerelve: radarok, ABS, esőérzékelő, hőmérők, GPS, légnyomásmérő, gyorsulás-mérő stb. A mai járművek árának nagyjából 30-35%-át már az elektronika, a különböző szenzorok és aktuátorok, illetve a járműveken belül elhelyezett kommunikációs eszközök adják. Korábban a szenzorok csak a jármű vezetőjének jelezték a különböző mérési ada-tokat és az ezekből adódó esetleges gondokat. Felmerült viszont az igény, hogy az autók egymásnak is jelezhetnék ezeket a problémákat, egymással is kommunikálhatnának. Ha egy autó megcsúszik a jeges úton, arról értesíthetné az utána jövő többi járművet is, illetve azok vezetőit, de hasonlóan érdemes egy vészfékezésről riasztásokat küldeni, hiszen nem mindenki érzékeli feltétlenül vizuálisan, hogy az előtte haladó jármű, ha részben takarásban van, vészfékezett. A járművek közötti kommunikáció speciális követelményeire szabott technológiai megoldásokat a következő szakaszban ismertetjük.

Életszerű elképzelés az is, hogy az autók a biztosítótársaságokkal is kapcsolatban le-gyenek. Ma a biztosítások megkötésénél a biztosítótársaságok általános járművezetői pro-filokat használnak. Figyelembe veszik, hogy az adott járművezető hány éves, férfi-e vagy nő, vidéken vagy nagyvárosban lakik-e, és persze azt is, hogy hány éve van jogosítványa és milyen baleseti statisztikákkal rendelkezik. Ennek ellenére ez egy meglehetősen lebutított profil, amely nem igazán tud különbséget tenni az ügyfelek között. Ha viszont a biztosító-társaság folyamatosan kapná az adatokat az ügyfelei járműveiből, akkor láthatná azt, hogy ki mennyire vezet gyorsan, sportosan, balesetveszélyesen, ezek alapján pedig egy sokkal precízebb profilt és személyre szabott árképzést tudna biztosítani.

KORREKTÚRAPÉLDÁNY PB

Végezetül pedig szintén hasznos lenne, ha a hálózatba kötött autók a megfelelő márka-szervizeknek is folyamatosan küldenének adatokat, a szerviz pedig előre látná azt, hogy mikor lesz szükség egy féktárcsa vagy egy kuplung cseréjére például. Ezek alapján pedig előre be tudná szerezni az alkatrészeket, és szükség esetén berendelhetné a járművet, ha karbantartást lát szükségesnek.

7.5.1. Járműkommunikációs megoldások

Ami a kommunikációs interfészeket illeti, a járműveken belül számos vezetékes és vezeték nélküli kommunikációs interfész megtalálható. A járművön belül a szenzorok általában vezetékes megoldásokkal kommunikálnak, a legelterjedtebb rendszer a CAN, de egyre in-kább elterjednek más megoldások is, mint a Lin vagy a Flexray. A járművek szenzorjaiból a járművezető közvetlenül is kinyerheti az adatokat, ha egy Bluetooth-kapcsolat és egy megfelelő mobilapplikáció segítségével rácsatlakozik a jármű OBD-II (On-Board Diag-nostics) interfészére.

A járművek azonban egyre inkább képesek kell hogy legyenek arra, hogy egymással is kommunikáljanak, mint ahogy azt már kifejtettük. Ezt a kommunikációs megoldást hívjuk C2C (Car-to-Car) vagy V2V (Vehicle-to-Vehicle) kommunikációnak. A járművek közötti kommunikáció kiemelt fontosságú például az önvezető járművek fejlesztésében is, hiszen a közelben mozgó többi járműtől számos olyan adatot tud begyűjteni az önvezető autó, amelyek segítik majd a tájékozódásban és a döntések meghozatalában.

A járművek közötti kommunikációnak azonban speciális követelményei vannak, hiszen egyrészt a járművek nagyon nagy sebességgel mozoghatnak, főleg, ha a relatív sebessé-geket nézzük, két ellenkező irányba mozgó jármű esetén. A késleltetésnek viszont nagyon alacsonynak kell lennie: egy vészfékezés esetén például az erről szóló riasztásnak néhány tizedmásodpercen belül meg kell érkeznie ahhoz, hogy érdemben reagálni lehessen rá.

Egy másik kommunikációs forgatókönyv az, amikor a jármű a környezetében levő inf-rastruktúrával, annak okos elemeivel kommunikál. Ezt hívjuk C2I (Car-to-Infrastructure) vagy V2I (Vehicle-to-Infrastructure) kommunikációnak. A kommunikáció itt rendszerint egy úgynevezett OBU (On-Board Unit) és egy RSU (Road-Side Unit) között történik.

Az infrastruktúra-elem lehet például egy okos közlekedési lámpa, amelyik kommunikál a kereszteződésbe érkező járművekkel, és adaptívan változtatja a jelzését annak függvé-nyében, hogy milyen forgalmi viszonyokat érzékel a különböző sávokban.

Egy kiemelten releváns példa az okos infrastrukturális elemekre a közlekedési táblák esete is. Mint azt mindannyian tudjuk, számos olyan közlekedési táblánk van, amely bi-zonyos veszélyhelyzetekre figyelmeztet, legyen az csúszós út, kőomlás, az úton átszaladó gyermekek, vagy egy kiugró szarvas az út menti erdőből. Ezek a táblák azonban statikusak, és nem mondanak sokat az aktuális közlekedési viszonyokról. A csúszós útra figyelmez-tető tábla ott látható az út szélén akkor is, ha meleg, száraz idő van, az áthaladó gyerme-kekre figyelmeztető tábla pedig éjjel is látható, amikor egy gyermek sincs az utcán. Ma már azonban rendelkezésre áll az a technológia, amellyel ezeket a táblákat dinamikussá, adaptívvá tehetjük. Ha például egy autó szenzorjai érzékelik, hogy az autó megcsúszott az úton, akkor egy erre vonatkozó riasztást elküldenek az útszéli közlekedési táblának, amelyik aktívvá válik, és figyelmezteti a később arra haladó autókat a veszélyre. Másfelől,

PB KORREKTÚRAPÉLDÁNY

ha a gyalogátkelő mellett kihelyezett mozgásérzékelő szenzorok érzékelik, hogy valaki kö-zeledik a zebra felé, akkor figyelmeztethetik az arra közlekedő autókat, akár közvetlenül, akár egy dinamikus közlekedési tábla segítségével.

A) IEEE 802.11p

A C2C és a C2I kommunikációs forgatókönyvek kiszolgálására, azok speciális követelmé-nyeinek a figyelembevételével több dedikált technológiai megoldás is létezik. Az egyik ezek közül az IEEE 802.11p szabvány, amely gyakorlatilag egy speciális wifimegoldás, a jár-műhálózatok igényeire optimalizálva [Jiang–Delgrossi 2008]. A 802.11p az 5,9 GHz-es frekvenciatartományban, azon belül pedig az Egyesült Államokban egy 75 MHz széles, Európában egy 30 MHz széles sávban működik. Ennek a frekvenciatartománynak a hasz-nálata ingyenes, tehát a mobilhálózati frekvenciákkal ellentétben nem kell licencdíjat fizetni érte. Másfelől viszont a hagyományos ISM (Industry, Science, Medical) ingyenes csator-nákhoz képest, amelyeket megtalálhatunk a 866 MHz, 900 MHz, 2,4 GHz vagy 5,8 GHz környékén (ezeken működik a wifi, a Bluetooth, vagy olyan szenzorhálózati kommuniká-ciós megoldások, mint a LoRa vagy a Zigbee) az 5,9 GHz-es frekvencia használata erősen szabályozott, minden itt működő rádiós egységnek be kell tartania bizonyos előírásokat.

Ez nyilvánvalóan a közlekedésbiztonsági követelmények garantálásának köszönhető.

A járműkommunikáció számára dedikált frekvenciatartományt 10 MHz szélességű csatornákra osztják. A csatornák között létezik egy dedikált kontrollcsatorna, ahol a kü-lönböző jelzésforgalom, illetve a járművek által periodikusan küldött úgynevezett beacon-csomagok haladnak. Ezekben a beaconbeacon-csomagokban a járművek általában 10 Hz-es frek-venciával, azaz másodpercenként tízszer hirdetik a saját aktuális sebességüket, pozíciójukat, gyorsulásukat, haladási irányukat. Ezt az információt számos úgynevezett cooperative awareness alkalmazás használja, azaz olyan alkalmazások, amelyek arra épülnek, hogy a járművek minél pontosabban ismerjék a környezetükben haladó többi jármű helyzetét, mozgását. Ilyen lehet például egy sávváltást vagy előzést segítő alkalmazás.

A beaconüzenetekre a küldő fél nem vár visszajelzést, azok megerősítésére nincs szükség, hiszen ha az egyik üzenet elveszett, egy tizedmásodpercen belül úgyis küldi a következőt. Küldés előtt a küldő fél belehallgat a rádiós csatornába, és ha azt szabadnak találja, akkor elküldi a beaconcsomagot. Ha a csatorna foglalt, vár egy rövid ideig, majd újra próbálkozik.

A többi csatornát ezzel szemben a hagyományos értelemben vett adatküldésre hasz-nálhatják különböző alkalmazások, ezeket hívjuk szervizcsatornáknak. Az itt elküldött csomagokra a küldő fél vár egy megerősítést, hogy a csomag ténylegesen megérkezett.

Külön szervizcsatorna áll rendelkezésre a biztonságkritikus alkalmazások számára (mint például egy ráfutásos baleset elkerülése), és külön csatorna az összes többi alkalmazásnak.

Bár eredetileg csak olyan alkalmazásokra szerették volna használni ezt a frekvencia-tartományt, amelyek nem kereskedelmi jellegűek, és főleg a közlekedés biztonságát, illetve annak hatékonyságát segítik, később engedélyezték olyan alkalmazások számára is, amelyek magáncégek kereskedelmi jellegű szolgáltatásaihoz tartoztak. Egy ilyen jel-legű alkalmazás például a fizetős kapuknak a használata (autópályáknál, hidaknál vagy alagutaknál), amelyeken a járművek megállás nélkül áthaladhatnak, ha előtte a rádiós

KORREKTÚRAPÉLDÁNY PB

interfészen megtörtént a jármű azonosítása és a megfelelő használati díj levonása a tulaj-donos bankkártyájáról.

B) LTE–V2x

Egy másik lehetőség a járműhálózatok kommunikációjának biztosítására a hagyományos cellás mobilhálózatok adaptálása a speciális igényekhez. Itt leginkább a negyedik gene-rációs LTE-hálózatokra gondolhatunk. Ez az egyik leginkább elterjedt kommunikációs technológia, az előrejelzések szerint 2021-re több mint 4 milliárd LTE-előfizető lesz a vi-lágon. A hagyományos LTE-hálózatokat azonban nem a járművek igényeire optimalizálták, ezért azok csak korlátozott számú járműkommunikációs forgatókönyvet képesek támo-gatni. Például a nagy sebességgel mozgó járművek, illetve a nagyon alacsony, csak néhány század másodperces késleltetést megengedő alkalmazások támogatása nem oldható meg a hagyományos LTE-hálózaton keresztül.

Nem egyértelmű az sem, hogyan lehet kezelni a cellaváltásokat a különböző mobil-szolgáltatók hálózatai között. A biztonságos járműkommunikációhoz szükséges, hogy teljes mobilhálózati lefedettség álljon rendelkezésre, ma azonban ez még nem feltétlenül adott. Bár bizonyos esetekben a különböző mobilhálózatok lefedettségi térképe jól kiegészítheti egy-mást, a hagyományos előfizetők esetében ezt nem lehet kiaknázni: az előfizető – lefedettség hiányában – leszakad a hálózatról, még akkor is, ha egy másik szolgáltatónak van lefedett-sége az adott helyen. Egy önvezető jármű esetén ez nyilvánvalóan nem lesz elfogadható.

Az alacsony késleltetésre vonatkozó elvárásokat ki lehetne elégíteni, ha megoldható lenne az egymás közelében levő LTE-eszközök közvetlen kommunikációja úgy, hogy az ne haladjon keresztül a bázisállomáson. Erre a megoldást a 2016-ban megjelent LTE–D2D (Device-to-Device) kommunikációs modell jelentheti. Az LTE–D2D azonban csak az adat-küldést biztosítja közvetlenül az eszközök, esetünkben a járművek között. Mindemellett azonban a jelzésforgalom továbbra is a bázisállomáson halad keresztül, és a bázisállomás lesz az, amely az időszeletek, illetve a frekvenciák kiosztását végzi, elkerülve az interfe-renciát a cellában tartózkodó többi eszközzel.

A fenti nehézségeket felismerve az LTE-technológiát kidolgozó szabványosításszer-vezet, a 3GPP 2015-ben létrehozott egy V2x munkacsoportot, ahol az x betű helyettesítése V-vel (Vehicle/jármű) vagy I-vel (Infrastructure), úgy a járművek közötti, mint a járművek és az infrastruktúra közötti kommunikáció lefedését is jelenti. Ami már a mai hálózatokon is biztosítható, az a V2I – I2V jellegű, nem biztonságkritikus alkalmazások támogatása.

In document AZ OKOS VÁROS (Pldal 135-138)