A biztonság szerepe a támogatott és autonóm vezetésű autókban

Még nem is oly rég elképzelhetetlennek tartottuk, hogy gép és program legyőzze a sakk vagy a „go” játék mestereit – ez ma már lehetséges. Ugyanilyen hihetetlenül hangzott, hogy egy automatikus vezetésű jármű baj nélkül közlekedhessen a való világ kiszámíthatatlan forgalmi viszonyai közt. Most már ez is lehetséges – bár számos biztonsági^[1] kérdésre kell még megnyugtató válaszokat kapnunk.

Megnövelt funkcionalitás

Az autók világában jelenleg komoly evolúció zajlik, amely során a hagyományos, ember vezette elektromechanikus szerkezet teljesen autonóm működésű, „önvezető” járművé alakul át. Ma már közel járunk az „átbillenési ponthoz” azáltal, hogy a legtöbb új autóban jelen van több-kevesebb korszerű vezetéstámogató képesség (Advanced Drives Assistance System – ADAS), köztük a sávkövetés, az autonóm vészfékezés, és néhány olyan alrendszer, amely a vezetőnek segít, hogy többet és jobban láthasson a jármű környezetéből. Eközben a teljesen autonóm járművek is több-millió kilométernyi tesztfutást teljesítettek.
Azok a rendszerek, amelyek ezeket a képességeket megvalósítják, szenzorokat, beavatkozókat, rádiófrekvenciás és fényradarokat tartalmaznak, mikroszámítógépek vezérlik őket, hálózatokon kommunikálnak – ami miatt egyesek „kerekeken guruló internetként” gondolnak rájuk. Az autók információt cserélnek más autókkal (ez a Vehicle to Vehicle – V to V vagy V2V), a közlekedési infrastruktúrával (forgalomirányító lámpákkal, intelligens útjelzőkkel, ez a Vehicle to Infrastructure – V to I vagy V2I), műholdakkal (tőlük szerzik a helyzetinformációt, de jelentést is adhatnak műholdbázisú rendszereknek).
Mindehhez természetesen a szoftver adja az intelligenciát – mindösszesen több mint 100 millió programsornyi kódra is tehető terjedelemben. Ebbe beletartozik a szorosan vett szoftveralkalmazás, de ennek működését az operációs rendszer, a hálózati kommunikációt a szenzorok, beavatkozók és a felhasználóval kommunikáló „ember–gép kapcsolat” (HMI) közbenső szintű (middleware) interfészei szolgálják ki.

Növekvő sebezhetőség

A rohamosan növekvő bonyolultsággal a (mindkét értelemben vett) biztonsági problémák fokozódása is együtt jár. A járművek „bármivel” folytatott kommunikációja (V to X) miatt az autók egyre nyitottabbak és védtelenebbek a külső informatikai támadások ellen – már megtörtént, hogy egy kívülálló vette át egy Jeep terepjáró irányítását, és tetszés szerint felül tudta bírálni a vezető beavatkozási kísérleteit. További sebezhetőségi tényező maga a jármű használója. Az autógyártók a jármű műszaki állapotának követésére „fedélzeti diagnosztikai rendszert” (On Board Diagnostics – OBD) építenek be a gyártmányaikba a hibakeresés és szervizelés megkönnyítése érdekében. Ennek interfészcsatlakozója, az OBD II szabadon elérhető a felhasználó által is. Ha „ráguglizunk” az OBD2 keresőszóra, tömegével találunk megoldásokat arra, hogy a vezető a járműmotor „egészségi állapotát” leíró információkhoz akár az okostelefonjával is hozzáférhessen a Bluetooth OBD2 interfészfelületen keresztül. Ez viszont egy kívülálló személy rosszindulatú beavatkozása előtt is „megnyitja az ajtót”. Az University of Michigan kutatói cikket publikáltak egy olyan kísérletről, amelyben közvetlen hozzáférést létesítettek egy laptop számítógépről egy nagy teherautó és egy iskolabusz ODB rendszerével.
Az ilyen roppant mennyiségű programkód esetén azonban nem csak a rosszindulatú beavatkozás lehetősége jelent kockázatot, de a fizikai biztonságot veszélyeztető programhiba lehetősége sem zárható ki. Egy bizonyos Toyota modellnél előfordult az az elhíresült eset, hogy a jármű a vezető akarata ellenére felgyorsult – a bírósági per figyelmeztetett arra, hogy sok meglevő, sokszorosan „újrahasznosított” programkód nem felel meg az igényes biztonsági elvárásoknak. Ezek helyett új kódokat kell kifejleszteni, amelyeknek ma már sokkal szigorúbb biztonsági szabványkövetelményeknek kell megfelelniük.

Szabványosítás

Alig több mint öt éve, hogy egy „autóspecifikus” biztonsági szabvány lépett életbe. Az ISO26262 lényegében az IEC61508 jelű, a funkcionális biztonságra vonatkozó szabványnak egy adaptációja, amely azokra a követelményekre fókuszál, amelyeket a sorozatgyártású személyszállító járművek elektromos és elektronikus rendszereinek kell teljesíteniük. Ezek minden tevékenységre és történésre kiterjednek az érintett biztonságkritikus rendszerek teljes életciklusa alatt. Ez pedig a szoftverminőséggel kapcsolatos közvetlen következményekkel jár.
A szabvány úgynevezett „automotív biztonsági integritási szinteket” (Automotive Safety Integrity Level – ASIL) határoz meg annak érdekében, hogy kategóriákba sorolja az adott alrendszer kockázatainak mértékét. Ennek tartománya A-tól D-ig terjed, ahol „A” a legkevésbé biztonságkritikus elemekre vonatkozik, a „D” pedig a legmagasabb kockázati besorolású, ezért a legszigorúbb biztonsági követelményeket támasztja. Az ASIL szinteken kívül a QM (Quality Management) besorolás is létezik, (amelyre az ISO26262 nem vonatkozik), amely azt jelenti, hogy ez a fejlesztő szervezet saját minőségbiztosítási rendszerére van bízva. Az ASIL szintet viszont a kockázat mértékét meghatározó paraméterek, a hibának való „kitettség” és a hibaállapot kezelésének lehetőségei határozzák meg. A „hibaállapot kezelésének lehetősége” controllability paraméter különös figyelmet érdemel. Alapja az a feltételezés, hogy a vezető a vezetésre alkalmas állapotban van, megfelelően képzett (vezetői engedéllyel rendelkezik), és teljesít minden jogi követelményt, beleértve azt a gondossági elvárást is, amellyel képes a körülményekhez képest a forgalom más résztvevői által okozott kockázatok kezelésére és eleget tesz a közlekedési szabályoknak. A jogszabályokat úgy kell majd átalakítani, hogy ha az automatizált vezetőrendszer működik, a vezető nem fordít figyelmet a vezetés részleteire mindaddig, míg a rendszer fel nem szólítja beavatkozásra. Ennek a vezetőt értesítő rendszernek és a jármű irányításának az emberi vezető általi visszavétele kritikus fontosságú. Ha az értesítési rendszer meghibásodik, előfordulhat, hogy az emberi vezető nem figyel fel az elhárítandó veszélyhelyzetre, és nem képes azt elhárítani, amint ez egy nem régi esetben történt, amikor egy Tesla autó nem ismerte fel az útját keresztező kamiont. Ha viszont a vezetés visszavételi rendszere működik hibásan, a jármű az automatikus vezetőrendszer ellenőrzése alatt marad, és az emberi vezető nem képes közbeavatkozni a veszélyhelyzet elhárítása érdekében. Az ilyen szituációkat mindig a veszélyhelyzet kezelésének legmagasabb kockázati kategóriájába (C3) kell sorolni, amely azt jelenti, hogy az összes vezető és a közeledés más szereplőinek kevesebb mint 90%-a képes teljesen vagy részben elkerülni az ilyen baleseti helyzetek következményeit. Az ISO26262 szabvány 6. fejezete azokat a követelményeket fogalmazza meg, amelyeket a szoftverfejlesztési folyamatnak kell teljesítenie, hogy eléggé megbízható kódot legyen képes előállítani ahhoz, hogy az – ha a rendszerben fut – megfeleljen az elvárt ASIL szint elvárásainak.
Az autóipari mérnökök szakmai szervezete, a Society of Automotive Engineers (SAE) J3016 jelű szabványa a vezetés automatizálásának mértékére hat szintet állapít meg az automatizálás teljes hiányától a teljes automatizálásig. Az automatizált vezetőrendszerrel (amelyek a SAE besorolása szerinti harmadik vagy magasabb kategóriába sorolhatók), szenzorokból szereznek információt, amelyek adataiból modellt építenek fel a környezetükről. Ebből – az adott célnak megfelelően – eldöntik, milyen módon támogassák a vezető tevékenységét esetleg hogyan avatkozzanak be, ha a funkciók irányítását részben vagy egészen átvették a vezetőtől. Van még ezen kívül is biztonságkritikus feladatuk, mint például annak meghatározása, hogy a szenzorok megfelelően működnek-e, amikor figyelmeztetik a vezetőt, vagy visszaadják neki az irányítást.
Létfontosságú, hogy ez a szoftver megbízhatóan viselkedjen. Más szoftverfeladatok – például a szenzoradatok modellezése – kevésbé kritikusak, de még ezeknél is el kell végezni a kockázatelemzést.

Jogi szabályozás

A közlekedési jogszabályrendszert is meg kell változtatni annak érdekében, hogy az automatizált vezetőrendszerek támasztotta új körülményeket is szabályozni tudja, különösen a felelősség és a magánszféra tekintetében. Minden országnak megvannak a maga sajátos közlekedési törvényei és kötelező jogi megoldásai számos joghelyzet megítélésében.
Az USA szövetségi hatósága, a National Highway Traffic Safety Administration formális osztályozási rendszert javasolt, amely öt szintet különböztet meg attól kezdve, hogy az emberi vezető mindent a saját teljes ellenőrzése alatt tart, egészen addig, hogy a jármű az utazás teljes hossza alatt, még biztonságkritikus helyzetekben is az automatikus rendszer irányítása alatt marad, és a vezetőtől nem várja, hogy bármikor, bármilyen mértékben a vezetésbe avatkozzék.
Az USA egyes tagállamai különbözőképpen közelítik meg ezt a kérdést. Nevada volt az első állam, amely engedélyezte (2011-ben) az autonóm járművek működtetését, az autonóm vezetési technológiák tesztelését közutakon, ezt követte Kalifornia, Florida, Michigan, Észak-Dakota, Tennessee és Washington DC.
Európában kutatási program kezdődött 2014 januárjában, „Automated Driving Applications & Technologies for Intelligent Vehicles” (Automatizált vezetési alkalmazások és technológiák intelligens járművekben), amelynek keretében automatizált vezetési funkciókat dolgoznak ki a normál napi forgalomban való alkalmazásra. Céljuk olyan rendszer kialakítása, amely dinamikusan alkalmazkodik a közlekedési szituációkhoz. A projekt ugyancsak foglalkozik azokkal a jogi vonatkozásokkal is, amelyek a sikeres piacbevezetésre befolyással lehetnek.
A Vehicle & Road Automation (VRA – Jármű- és útautomatizálás) egy, az Európai Unió által kezdeményezett támogatási rendszer, amely együttműködési hálózatot kíván életre hívni azon szakértők és finanszírozók közreműködésével, akik az automatizált járművek használatbavételén és a kapcsolódó infrastruktúra kialakításán munkálkodnak. A VRA partnerkapcsolatra lépett néhány eredeti berendezés gyártóval (OEM) és beszállítóval is, de a legtöbb partner kutatóintézet vagy egyetemi kutatóhely. A VRA is elkészített egy listát az EU által szabályozásra javasolt jogi és hatósági kérdésekről.
A Volkswagent is bevonták a közös európai jogalkotási munkába, beleértve az ECE 79 jogszabály (amely egyben egy ENSz által is elfogadott jogi norma) módosítását is, amelynek tárgya a kormányzó berendezésekre vonatkozó követelményrendszer. Ez elvárja, hogy a vezetőnek bármikor képesnek kell lennie arra, hogy átvegye az automatikus kormányzás funkcióit és teljes ellenőrzést gyakoroljon az utazás egész tartama alatt történtekre.
A japán kormány azt tervezi, hogy törvényt alkot az önvezető járművekről. A kormányzat előállított egy négyfokozatú osztályozást is a vezetés automatizációjának különböző szintjeiről, amelynek egyike a teljesen autonóm, emberi beavatkozás nélküli vezetés is.
Kínában a Baidu (amelyet sokan a „kínai Google” kifejezéssel illetnek) ugyancsak egy önvezető autó kidolgozásán dolgozik a BMW-vel együttműködve. A kínai jogrendszer rendkívül rugalmas, így a kormányzatnak nagyobb a hatalma arra, hogy az autonóm járművek használatához szükséges változtatásokat megvalósítsa. Ugyanakkor nekik is meg kell találniuk a választ mindazokra a bonyolult problémákra, amelyekkel más országok jogrendszere is foglalkozik.
India is foglalkozik az autonóm vezetésű járművek kérdéseivel, de nagy problémákkal kell megbirkózniuk, egyebek közt a lassan mozgó járművekre vonatkozó sajátos jogi szabályozással, és a rendkívül vegyes infrastruktúra által támasztott nehézségekkel^[2].

Fejlesztési megközelítések

Ebben a problémakörben akkor most hogyan is tervezzünk olyan programkódot, amely a szó mindkét féle értelmében egyszerre biztonságos? A már említett ISO26262 olyan szoftverfejlesztési folyamatot részesít előnyben, amely kódolási szabványok és kódellenőrző szoftvereszközök alkalmazásával fokozza a biztonságot.
A rendszer informatikai biztonsága olyan funkciók tervezésével kezdődik, amelyek hozzájárulnak a rosszindulatú beavatkozások elleni védettséghez. Ilyenek
az alkalmazások szétválasztása, az „átjárás” tűzfalas védelme, a biztonságkritikus alkalmazások (mint a kormányzás és fékezés) elválasztása a kevésbé kritikusaktól, amelyek a külvilággal

• kommunikálnak, mint a fedélzeti tájékoztató és szórakoztatórendszer (infotainment),

• a kommunikáció legszükségesebb mértékre korlátozása,

• a kommunikáció keretében bekerült adatok ellenőrzése, validitásvizsgálata és mások.

Mivel ezen a területen a szoftverek javarészét C nyelven írják, jó kiindulópont a fizikai és informatikai biztonság szempontjainak érvényesítésére a MISRA C:2012 (MISRA 3) programozási módszertan. Ez egy sor útmutatást tartalmaz a C programok megírásához, a definiálatlan viselkedés elkerüléséhez, a forráskód karbantarthatóságának javításához, tesztelhetőségéhez, hordoz-
hatóságához és olvashatóságához. Mivel jelentős átfedések vannak a MISRA irányelvek és az ISO26262-6 megfelelőségi táblázatai között, a MISRA használata szinte elkerülhetetlen az ISO26262 megfelelőségű programkód írásához.
Nemrég publikálta a MISRA szervezet az irányelveinek 1. változatából a 3. változatba való továbblépés dokumentumait. Ez 14 új szabályt tartalmaz annak érdekében, hogy a MISRA még szélesebb körű „lefedettséget” garantáljon a biztonságos szoftverrendszerek fejlesztéséhez.
A szoftvereszközök az ISO26262 szellemében történő szoftverfejlesztés fontos feltételei. A statikus kódelemző eszközöknek lényeges szerepe van a kód minőségbiztosításában, mivel egyszerre adnak tájékoztatást a kódolás minőségéről és a kódolási szabványok – például a MISRA – követelményeinek való megfelelésről. A vizsgálóeszközök további biztonsággal is felruházzák a szoftvereket, míg a programverifikációs eszközök azt mérik, milyen mértékben valósítja meg a szoftver a tervező által célul kitűzött funkcionalitásokat.

Összegzés

Van tehát lehetőség arra, hogy mindkét értelmében biztonságos rendszereket állítsunk elő a járművekben való felhasználásra. Azok a szervezetek is, amelyek „újramodellezték” a fejlesztési folyamataikat annak érdekében, hogy megfelelhessenek az ISO26262 követelményrendszerének, azt tapasztalták, hogy a kezdeti bevezetési és betanulási fázison túljutva eredményeket könyvelhettek el a termelékenységükben is.

Dr. Frank van den Beuken – PRQA

^[1] A fordító zavarban van, ha az angol „safety” és „security” kifejezéseket kell magyarra átültetnie. Rendszerint mindegyiket a „biztonság” szóval fordítjuk, de míg a „safety” azt a fajta biztonságot jelenti, amely valaki vagy valami fizikai integritásának megőrzését garantálja valamilyen véletlen körülmény ellenére, a „security” inkább a szándékos, rosszindulatú befolyások elleni védettséget jelenti – legalább is a fordító „saját használatra” szánt, minden bizonnyal vitatható értelmezése szerint. Az angol nyelvű eredetiben a szerző a „safety” és a „security” szavakkal egyértelművé tudja tenni, melyik értelmezésre gondol az adott kontextusban, a fordításban megkíséreljük a helyzetnek megfelelően, körülírással egyértelműsíteni, ha szükséges. – A ford. megj.

^[2] Gyanítom, az „önvezető” járműveknek a normál forgalomba illesztésének legnagyobb kihívásaival azokban az országokban kell szembesülni, ahol hagyományosan nem tartják be a közlekedési szabályokat, ahol az erősebbnek, agresszívebbnek van elsőbbsége, ahol a vezetés inkább élet-halál harcra emlékeztet, mint a társadalom rendezett működésének egy megnyilvánulására. Bizonyára az olvasó is meg tudna nevezni néhány ilyen országot. Ha egy hagyományos autót megvásárolnak, a vezetővel együtt az a közlekedési kultúra (vagy kulturálatlanság) is beleül az autóba, amellyel az adott országban létezni lehet. Érdekes probléma lehet egy olyan autó megtervezése, amely „környezetfüggően” alkalmazkodik a szabály-követésnek vagy a szabályok szelektív figyelmen kívül hagyásának helyi hagyományaihoz. – A szerk. megj.

Hivatkozások

www.iso.org • www.iec.ch/functionalsafety • www.adaptive-ip.eu • www.sae.org • www.nhtsa.gov • http://vra-net.eu • www.unece.org • www.misra.org.uk

További információ:

www.programmingresearch.com