fölszállás a CAN buszra

Hálózatok egyéb

Sziasztok,

a gépjárműfedélzeti adatbuszokhoz (CAN buszhoz) csatlakozással kapcsolatos tapasztalataitokat várom ebben a topikban.

Ki próbálkozott már ezzel, milyen HW/SW szükséges hozzá?
Mik a csatlakozási pontok?(Gondolom, ez erősen típusfüggő...)
Milyen adatokat sikerült kiolvasni?

Szép lenne pl. menet közben laptopon a technikai paramétereket megfigyelni, a CAN üzeneteket elkapni tudni...

  • 2826 megtekintés

( Hiena v | 2010. 01. 01., p – 17:24 )

A cégnél főállásban CANjük vágjuk a témát.
A CAN egy aszinkron, csavart érpáron menő, soros protokol. Sebességre az 500kb és 1Mb a leggyakoribb. Fizikailag egy két végén 120 Ohmmal lezárt csavart érpáros busz, erre csatlakoznak az eszközök. Az adatvezetékek elnevezése CAN high és CAN low, ami azt jelenti, hogy a can high vonalon 2.5V-os DC offszetre van ráültetve ponáltan a 2.5V-os digitális jel, a CANlownál, pedig 2.5V-os DC offszetre van ráültetve negáltan a 2.5V-os digitális jel.
Nincs dediált host és kliens, a kommunikáció irányát a üzenetcsomag fejlécében elhelyezett azonosítók határozzák meg.
Ilyen rendszerhez többféleképp lehet csatlakozni. Vannak gyári CAN interface eszközök (USB, PCMCIA) ezeknek elég borsos az ára. Vannak olcsóbb mikrokontrollerek (PIC), amiket viszonylag egyszerű kóddal rá lehet bírni, hogy fordítsák a CAN buszon lévő üzeneteket soros kommunikációra. Ez utóbbiak viszont lassabbak, tehát nem biztos, hogy fel tudod dolgozni a motorvezérlő által kiköpött teljes adattömeget.

A csatlakozási pont a kocsiban általában ODB csatlakozóval van kialakítva, viszont ez leggyakrabban csak a szevíz busz, tehát max. állapotjeleket tudsz lekérdezni. A dedikált buszokat szkóppal való méregetéssel lehet visszakeresni.
A CAN interfészeken szabványos DSUB csatlakozó kiosztása: 2. CAN low, 7. CAN high, 3. GND (opcionális)

Ami a kellemetlenebb dolog, hogy a hálózaton lévő eszközök azonosítói és protokoljai nem publikusak és gyártófüggőek.

A leggyakoribb adatok amikhez hozzá lehet férni:
- Sebességjel
- Kormányszög
- Pedál helyzet
- Motor állapot paraméterek (hőmérséklet, üzemanyagszint,olajszint, fordulatszám, gyújtás, motorfutás jel)
- Különféle segédberendezések állapotjelei (tükör, irányjelző, világítás, ülés, klíma, ablaktörlő)

Szoftveresen általában majd minden can interfacehez jár valamilyen tool. Az egyik legjobb a Vector CANape nevü progija, ahol egy layout file-al beállíthatod, hogy melyik eszközről, milyen adatokat, milyen formában jelenítsen meg. Így összerakhatsz akár egy kapcsolókkal, gomvbokkal, különféle virtuális műszerekkel teli panelt magadnak. Egyetlen hátránya, hogy a progi csak a Vector CAN kártyáival megy.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Azért használ minden gyártó egyedi (nem publikus) protokolt, hogy a csak a saját hulladék műszerével lehessen, a saját hulladék márkaszervizében diagnosztizálni a a saját hulladék motorvezérlővel ellátott saját hulladék autóját. Ugyanezen okból nincs olyan autódiagnosztikai műszer, ami minden típusú autót tudna kezelni. Ha el is adják a protokolokat más gyártónak, azt is több éves késésel teszik. Persze van amikor ráb@sznak erre a taktikára és a feltörik a protokoljukat. Van olyan műszergyártó, amelyik nem vergődik a liszenszdíjakkal...
Az egész CANBUS rendszer leginkább csak pénz lenyúlásáról szól.

A tisztánlátás kedvéért. A CAN egy szabványos kommunikációs interface amit a BOSH és társai fejlesztettek ki anno. Mivel automatizálás és autógyártás területén kvázi szabvánnyá vált ezért a BOSH a CAN specifikációt és a hozzá kapcsolódó részeket szabadon hozzáférhetővé tette. (Lásd:www.semiconductors.bosch.de/pdf/can2spec.pdf)
Ami eltér a gépkocsigyártóknál az nem a CANbusz, hanem a rajta folyó adatok. Ahogy lejjebb is írták, az applikációs réteg. Ennek az eltérésnek viszont kemény anyagi és üzleti okai vannak. Az autógyártók, a nyomtatógyártókhoz hasonlóan nagyon kicsi haszonkulccsal árulják a termékeiket. Sok új autó tulajdonos nemcsak a kocsi megvételekor fizet, hanem a kötelező szervizeknél, egyes alkatrészcseréknél. Az autógyártóknál működik egyfajta "mi adtunk neked egy drága játékszert, te elrontottad, most akkor fizess érte" szemlélet.
A modern motorvezérlőkben sok olyan információ és adat van, amiből következtetéseket lehet levonni a motor működéséről. Viszont ezek az adatok kijutása üzleti szempontból nem biztos, hogy egészségesek lennének. Nem tesz jót az üzletnek, ha kiderülne, hogy a cingárka kis motorba egy kigyorsításkor nem 14 liter/100km üzemanyag megy be, hanem 30 liter körül. A valóságon nem sokat változtatna a dolog, mert az átlagfogyasztás ugyanannyi lenne, de egy környezettudatos vásárló simán átsétál ilyentől egy másik kereskedőhöz, mert nem szereti a nagy számokat. Ugyanígy nem lenne jó, ha aranytácán adnák át azt, hogy milyen előgyújtási, befecskendezési paraméterekkel faragnak le fél litereket az átlagfogyasztásból. De az sem mutat jól, ha a user látja, hányszor indul újra a motorvezérlő egy röpke 80 km-es út alatt.

Ugyanígy az egységes interface lehetőséget biztosítana a trükközésekre:
Típusidegen alkatrészek beszerelésére. (Józsikám, a lamdaszonda 50k lenne, de van helyette Buzuki 20 ért, csak kisebb az átmérője. Körbetekerem szigszallaggal és jó lesz.)
Mű részegységek beszerelésére. (Itt a fasza ECU szimulátor, betesszük, és mindig jó lesz a CO)

Kishazánkban nem csak az órát tekerik át előszeretettel, de vannak szervizek akik biztosítanak "virtuális olajcserét", és időszakos "ott középen világító, idegesítő, sárga lámpa kikapcsolást" is. Nem lenne jó ezeknek az embereknek az életét megkönnyíteni.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Apósom l200-asában folyamatosan villog a differenciálzár visszajelzője, aminek csak akkor kéne, ha 4WD-ben megy 60(?) felett.
Szervizben aszondták, hogy 80kHUF, mert difiművel kapcs javítás. Semmit nem cserélnek, csak lehúzzák a vezetéket. Úgyhogy maradt villogón.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

"Az egész CANBUS rendszer leginkább csak pénz lenyúlásáról szól."

Nem, a CAN egy robusztus, aszinkron kommunikációs protokollról szól :P

Egyébként, ahogy már előttem is leírták, a CAN protokoll szabványos. A rajta menő jelek nem. Amihez még annyit tennék hozzá, hogy mivel minden gyártó mást és máshogyan épít az autójába mint a többiek, ráadásul az újabb autóknál a jellemzően túlterhelt CAN-kommunikációba már így is nehezen tudják behajtogatni az összes jelet, ezért akkor sem tudnának teljesen megegyező rendszert építeni, ha holnaptól kitörne a világbéke, meg ilyenek. Egyszerűen az autók fizikai különbözősége miatt nem.

Egyébként vannak egységesítési törekvések, pl. az IBK-elv, vagy az ICM, meg jönnek már az újabb kommunikációs protokollok is, de olyanok, hogy visszasírjuk majd a CAN-t, mint egy egyszerű, átlátható, robusztus rendszert :)

Hmm. Nem kimondottan gépjárművekkel foglalkozunk, de ha jól rémlik, szabvány szerint azoknak sem "sima" CAN layer-3-ban kellene működni, hanem a megfelelő CAN-Open deviceprofile-ban. Ezek megtalálhatók pl. itt: http://www.can-cia.org/index.php?id=85

Mondjuk ez már egy felsőbb, CAN-en működő protokoll, itt van master meg slave meg guarding, heartbeat, meg mindenféle nyalánkságok, de amennyiben nem tévedés a fentebbi feltételezésem, akkor a szabványt betartó gyártók eszközeit simán tudod olvasni. Amennyiben tévedtem, bocsi, csak egy ötlet volt. Jó pár éve kellett csinálnom egy analóg 4-10mA kimenetű kamionokban használt dőlésszögmérőhöz CANOpen slave-t. Ezért is gondolom, hogy csak van valami reménysudár. :)

+1, néhány kiegészítéssel:

A CAN-es PIC-ek nem tudom mit tudnak, de szerintem van köztük olyan, ami elég gyors, meg esetleg lehet bufferelni is.

OBD-ben csak dedikált szervízbusz lenne? Nem tudom, én inkább úgy gondolnám, hogy a szervízüzenetek (nincs olyan sok, mint a jármű összes többi üzenete egyébként) csak simán rajta vannak a "fő" buszon, nem látom sok tetejét, hogy fizikailag is el legyenek különítve. Az viszont valószínű, hogy az OBD-eszközök csak a szervízüzeneteket tudják olvasni, függetlenül attól, hogy látják-e a többit.

Amennyire észrevettem, a hálózati eszközöknek többnyire már nincs a CAN-en felül saját hálózati protokollja (bár, előfordulhat, pl. ilyen a VectorXCP is, ha már említetted a Vector-t), inkább csak a többé-kevésbé szabványos "alap" CAN-protokollt használják. Persze, ez még nem sok könnyítés, ha olvasni akarunk valamit, az ID-ken túl tudni kell az egyes üzenetek belső felépítését (ilyen értelemben mondhatjuk, hogy ez mégegy "protokoll") és a jelek skálázását is (mivel a "nyers" jelen önmagában csak egészértékeket lehet értelmezni)

A segédberendezések (ülés, klíma, VPS, stb.) jellemzően nem CAN-en vannak, hanem LIN-en, vagy ha mégis CAN-en, akkor dedikált alacsonysebességű CAN-en. A "fő" CAN-ről legfeljebb csak olvasnak ezek az eszközök.

A toolokból meg elég sok van. Egyszer láttam már ezeket a Vectoros cuccokat, de szerintem ágyúval verébre, ha csak olvasni akarok a CAN-ről. Igazából nem erre lettek kitalálva, hanem egy plusz réteghez CAN-re, amivel még további okosságokat lehet csinálni. Ez már túlmutat önmagában a CAN-en, ami abból is látszik, hogy a Vectoros cuccok több különböző hálózati protokollon is működnek, nem csak CAN-en. Szerintem a legtöbb CAN-el kapcsolatos feladtahoz egy ilyesmi bőven elég: http://www.canfestival.org/

Egyébként azért nem teljesen reménytelen a CAN-el bütykölni. Ha teljes visszafejtést nem is lehet megcsinálni, azért egy-két fontosabb jelet el lehet kapni, főleg, ha egy elterjedt, ismert rendszerről van szó, akkor a Google segíthet. Meg az is működhet, hogy egy adott gyártó hasonló üzeneteket használ az autóiban, legalábbis a fontosabb jelek hasonlóak, pl. a motorfordulatszám valószínűleg ugyanolyan ID alatt ugyanolyan formában fog megjelennei egy adott gyártó összes típusánál, tehát jó eséllyel elég az egyiknél megfejteni. Ha ezek mind nem működnek, akkor még mindig jöhet a szkóp+okoskodás+türelem+még több türelem, aztán vagy sikerül elkapni valamit, vagy nem.

Jahm. A loggolás és lehuzogatás sokat segít. Ezzel meg lehet találni az eszköz azonosítókat, és onnan tovább lehet indulni.
Hogy mi, merre van gányolva a CAN buszon arra elég legyen annyi, hogy a BMW-ben CAN-es firmware töltés közben rendszeresen elindul az ablaktörlő. Mondjuk fel lehet fogni egyfajta állapotjelzésnek...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( zeller | 2010. 01. 01., p – 21:23 )

Most láttam egy Microchip PIC32 reklámot egy magazin B4 oldalán, az MX5 családnak van CAN interfésze, eszközileg erre pl. el lehet indulni.

18F szériából használtam többet is. Azoknak a sebessége elegendő monitorozáshoz, egy-egy adatcsomag elkapásához. Amúgy a Microchip EUART modulja elég jó, mert alapból konfigurálható szűrésre, így nem a kontrollernek kell magoznia az embert érdeklő infókat.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( fdavid | 2010. 01. 02., szo – 08:47 )

Hiena nagyon jol leirta a lenyeget, csak annyit tennek hozza, hogy nem a fizikai eszkozhatter a kerdes onmagagaban, hanem a applikacios reteg. Ez bizony gyarto specifikus, es persze leteznek kesz protokoll implementaciok, de ezeket sem vasarolhaod meg altalaban szabadon. Ja es azert ha meg is vehetsz kesz megoldasokat, akkor is alaposan a zsebedbe kell nyulni. Ertsd: 10e Euros nagysagrendrol van szo, de ha tenyleg be akarsz vasarolni, akkor a Vector es a Softing cegeknel erdemes korulnezni.

Azert meg azt is erdemes megfontolni, hogy OBD-n eleg keves informacio fog jonni ahhoz kepest, amit a controllerek egymas kozott kuldozhenek, es ami a fejlesztoi buszon kiolvashato. Ezekhez fizikai beavatkozas nelkul nem fogsz hozzaferni.

( csearo | 2010. 01. 06., sze – 22:15 )

Köszönök minden eddigi hozzászólást, időközben már sikerült is találnom egy fehér-zöld csavart érpárt, az lesz az. :)

:wq