CAN protokol – Aplikativni sloj

CAN protokol – Aplikativni sloj

U prethodnim tekstovima upoznali smo fizički i logički deo CAN komunikacije. Fizički sloj objašnjava kako se električni signal prenosi preko CAN-H i CAN-L vodova, dok CAN kontroler vodi računa o strukturi frejma, arbitraži, CRC proveri, ACK mehanizmu i detekciji grešaka.

Međutim, čak i kada savršeno razumemo kako izgleda CAN frejm, još uvek ne znamo šta podaci koji se nalaze u njemu zapravo znače.

CAN kontroler može da primi sledeći frejm:

ID:   0x280
DLC:  8
DATA: 82 45 01 00 00 00 00 00

On zna da je frejm ispravno primljen, zna njegov identifikator i osam bajtova podataka, ali ne zna da li broj 0x82 predstavlja temperaturu motora, broj obrtaja, položaj papučice, pritisak goriva ili nešto sasvim drugo.

Šta CAN sam po sebi definiše?

Osnovni CAN protokol definiše mehanizam razmene frejmova između čvorova na magistrali. Između ostalog, definiše:

• CAN identifikator
• arbitražu
• polje podataka
• kontrolna polja frejma
• CRC proveru
• ACK mehanizam
• detekciju i signalizaciju grešaka

Ali CAN ne kaže:

• da ID 0x280 pripada ECU-u motora
• da Byte 0 predstavlja temperaturu rashladne tečnosti
• da Byte 1 predstavlja opterećenje motora
• da se neka vrednost mora pomnožiti faktorom 0,1
• da se od neke vrednosti mora oduzeti 40
• da određeni bit znači „ventilator uključen“

Sve to mora biti definisano na višem nivou apstrakcije.

Od CAN frejma do stvarne informacije

Pretpostavimo da je proizvođač definisao sledeću poruku:

Ako se na magistrali pojavi:

ID:   0x280
DATA: 82 45 01 00 00 00 00 00

softver koji poznaje definiciju poruke može da protumači:

• 0x82 = 130 decimalno
• 130 - 40 = 90 °C
• Byte 1 predstavlja opterećenje motora
• Bit 0 u Byte 2 ima vrednost 1, pa je ventilator aktivan

Bez tih pravila isti frejm je samo niz brojeva.

Poruka i signal nisu isto

Kod analize CAN komunikacije veoma je važan pojam signal.

Jedan CAN frejm najčešće ne predstavlja samo jednu fizičku veličinu. Njegovo data polje može istovremeno sadržati više potpuno različitih podataka.

Na primer:

CAN ID: 0x280

Byte 0       → temperatura motora
Byte 1       → opterećenje motora
Byte 2 bit 0 → ventilator
Byte 2 bit 1 → klima uključena
Byte 2 bit 2 → zahtev za povećanje ler gasa
Byte 3-4     → broj obrtaja
...

Svaki od tih podataka možemo posmatrati kao poseban signal.

Signal može zauzimati:

• jedan bit
• nekoliko bitova
• jedan ceo bajt
• više uzastopnih bajtova

Zato pri dekodiranju CAN mreže nije dovoljno znati samo CAN ID. Potrebno je znati i tačnu poziciju svakog signala unutar data polja.

Raw vrednost, faktor i offset

Vrednost koja se prenosi CAN mrežom često nije direktno izražena u voltima, stepenima, obrtajima ili kilometrima na čas.

Najpre se prenosi takozvana raw vrednost, a zatim se ona preračunava.

Tipična formula izgleda:

Fizička vrednost = Raw × Factor + Offset

Na primer:

Raw    = 130
Factor = 1
Offset = -40

Temperatura = 130 × 1 - 40
Temperatura = 90 °C

Kod nekog drugog signala faktor može biti:

0.1
0.01
0.125
0.25

Na taj način se celobrojna vrednost preneta CAN frejmom pretvara u fizičku veličinu.

Redosled bajtova – Intel i Motorola

Ako signal zauzima više od jednog bajta, mora se znati i kojim redosledom se ti bajtovi tumače.

U CAN dokumentaciji i alatima često se sreću izrazi Intel i Motorola, odnosno little-endian i big-endian.

Nazivi Intel i Motorola potiču iz istorijskih razlika u načinu na koji su različite procesorske porodice organizovale višebajtne brojeve u memoriji. Intelovi procesori tradicionalno se vezuju za little-endian raspored, dok su mnogi Motorola procesori, poput porodice 68000, koristili big-endian raspored.

Ti nazivi su kasnije ostali u tehničkoj terminologiji i CAN alatima. Oni ne znače da je određeni ECU proizvela kompanija Intel ili Motorola, već opisuju redosled kojim treba tumačiti bajtove višebajtne vrednosti.

Kod little-endian rasporeda bajt manje težine dolazi prvi, dok kod big-endian rasporeda prvo dolazi bajt veće težine.

Ako u poruci imamo:

12 34

definicija signala određuje da li ta dva bajta treba protumačiti kao:

0x1234

ili kao:

0x3412

Kod složenijih CAN signala koji ne počinju tačno na granici bajta mora se voditi računa i o načinu numerisanja bitova, početnom bitu i dužini signala, pa endianess tada postaje nešto složeniji od prostog menjanja mesta dva bajta.

Kako ECU zna šta određeni CAN ID znači?

Važno je razumeti da se opis podataka ne šalje zajedno sa CAN frejmom.

Na magistrali se ne pojavljuje:

ID 0x280
Temperatura motora = 90 °C

nego samo nešto poput:

280  82 45 01 00 00 00 00 00

ECU koji prima ovu poruku već u svom programu ima zapisano da:

• treba da prati ID 0x280
• određeni signal počinje na određenom bitu
• signal ima određenu dužinu
• primljenu vrednost treba skalirati određenim faktorom

Drugim rečima, oba ECU-a unapred moraju govoriti istim jezikom.

To je slično razgovoru dve osobe. Fizički prenos zvuka može biti savršen, ali ako jedna osoba govori srpski, a druga ne poznaje srpski jezik, sadržaj poruke joj neće značiti ništa.

DBC – rečnik CAN mreže

Kod razvoja i analize CAN sistema često se koristi format baze podataka poznat kao DBC.

DBC nije protokol koji se prenosi CAN magistralom. On je opis CAN mreže koji softverskom alatu govori kako da protumači sirove frejmove.

DBC može sadržati informacije kao što su:

• CAN ID poruke
• naziv poruke
• ECU koji poruku šalje
• naziv signala
• početni bit signala
• dužina signala
• Intel ili Motorola raspored
• factor
• offset
• minimalna i maksimalna vrednost
• jedinica mere
• tekstualno značenje pojedinih statusnih vrednosti

Bez baze podataka CAN analizator može prikazati:

280  82 45 01 00 00 00 00 00

Ako učitamo odgovarajući DBC, isti alat može prikazati nešto mnogo razumljivije:

EngineCoolantTemperature = 90 °C
EngineLoad               = ...
CoolingFan               = ON

Radna komunikacija vozila i dijagnostika nisu isto

Kada govorimo o CAN mreži u automobilu, korisno je razlikovati dva veoma različita načina komunikacije.

Radna komunikacija između ECU jedinica

Tokom normalnog rada vozila ECU jedinice neprekidno razmenjuju informacije.

Na primer:

• ECU motora šalje broj obrtaja
• ABS šalje brzine točkova
• senzor ugla volana šalje položaj volana
• menjač šalje izabrani stepen prenosa
• BCM šalje stanja vrata, svetala i prekidača

Takve poruke su često ciklične. Jedan ECU ih šalje svakih 10 ms, 20 ms, 100 ms ili nekim drugim definisanim periodom, bez potrebe da ga drugi ECU prethodno nešto pita.

ECU motora
     |
     | ID 0x280 – RPM, temperatura, statusi
     v
================ CAN =================
     |
     +---- Instrument tabla
     +---- Menjač
     +---- ABS
     +---- Ostali ECU-i

Dijagnostička komunikacija

Dijagnostika najčešće koristi drugačiji princip: zahtev – odgovor.

Dijagnostički alat  ---- zahtev ----> ECU

Dijagnostički alat  <--- odgovor ---- ECU

Alat traži određenu informaciju ili funkciju, a ECU obrađuje zahtev i vraća odgovor.

Tu se pojavljuju protokoli kao što su OBD-II i UDS.

Zašto nam je potreban ISO-TP?

Ovde dolazimo do veoma važnog problema.

Kod klasičnog CAN-a data polje jednog frejma može sadržati najviše osam bajtova. Ali dijagnostička poruka može biti mnogo duža.

Na primer, odgovor koji sadrži:

• VIN broj
• duži identifikacioni zapis
• veliki blok memorije
• podatke za programiranje ECU-a

ne može stati u jedan klasični CAN frejm.

Zbog toga se kod dijagnostike preko CAN-a veoma često koristi ISO-TP, definisan standardom ISO 15765-2.

ISO-TP koristi nekoliko tipova frejmova:

• Single Frame – cela poruka staje u jedan frejm
• First Frame – početak duže poruke
• Consecutive Frame – nastavci poruke
• Flow Control – kontrola toka podataka

Tako dobijamo približnu hijerarhiju:

UDS / OBD dijagnostička poruka
            |
            v
          ISO-TP
            |
            v
           CAN
            |
            v
       CAN-H / CAN-L

CAN prenosi pojedinačne frejmove. ISO-TP od više CAN frejmova pravi jednu dužu poruku. UDS ili OBD određuju šta sadržaj te poruke znači.

OBD-II – standardizovana dijagnostika

Jedan od najpoznatijih primera standardizovane automobilske dijagnostike je OBD-II, odnosno evropska varijanta EOBD.

Veoma je važno da CAN i OBD-II ne poistovećujemo.

CAN predstavlja jedan od mogućih sistema preko kojeg se dijagnostički podaci prenose, dok OBD definiše šta dijagnostički zahtev znači i kako treba protumačiti odgovor.

Kod OBD komunikacije preko CAN-a koristi se familija standarda ISO 15765.

PID – Parameter ID

Kod očitavanja trenutnih parametara vozila koriste se standardizovani identifikatori poznati kao PID – Parameter ID.

Na primer:

Standard ne znači da svaki automobil mora podržavati svaki postojeći PID. On definiše kako se određeni PID tumači ako ga vozilo podržava.

Postoje čak i posebni PID zahtevi kojima dijagnostički uređaj pita ECU koje PID-ove podržava.

Primer – očitavanje broja obrtaja

Dijagnostički alat može poslati:

01 0C

što znači:

• 01 – zahtev za trenutne podatke
• 0C – PID za broj obrtaja motora

ECU može odgovoriti:

41 0C 1A F8

Bajtovi 1A i F8 predstavljaju A i B.

A = 0x1A = 26
B = 0xF8 = 248

OBD standard za ovaj PID definiše formulu:

RPM = ((A × 256) + B) / 4

pa dobijamo:

RPM = ((26 × 256) + 248) / 4
RPM = 6904 / 4
RPM = 1726 o/min

UDS – Unified Diagnostic Services

OBD je prvenstveno standardizovan za zakonski propisanu dijagnostiku i određeni skup univerzalnih podataka, dok savremeni ECU-i nude mnogo šire dijagnostičke mogućnosti.

Jedan od najvažnijih protokola za takvu komunikaciju je UDS – Unified Diagnostic Services, definisan familijom standarda ISO 14229.

UDS omogućava funkcije kao što su:

• čitanje identifikacionih podataka ECU-a
• čitanje dijagnostičkih grešaka
• brisanje grešaka
• čitanje i upisivanje podataka
• pokretanje testova i rutina
• promena dijagnostičke sesije
• reset ECU-a
• bezbednosni pristup
• programiranje ECU-a

UDS servisni identifikatori

Primer UDS zahteva

Jedan od najpoznatijih primera je:

22 F1 90

Servis:

22 – Read Data By Identifier

dok je:

F1 90

DID – Data Identifier koji se vrlo često koristi za VIN vozila.

Pozitivan odgovor počinje sa:

62 F1 90 ...

Za mnoge UDS servise pozitivan odgovor dobija se dodavanjem vrednosti 0x40 na servisni identifikator zahteva:

0x22 + 0x40 = 0x62

Posle toga slede podaci koje je ECU vratio.

Negativan UDS odgovor

ECU ne mora prihvatiti svaki zahtev.

Ako ga odbije, često ćemo videti odgovor koji počinje:

7F

Na primer:

7F 22 xx

gde poslednji bajt predstavlja razlog odbijanja – takozvani NRC, Negative Response Code.

Razlog može biti, na primer, da zahtev nije podržan, da nisu ispunjeni uslovi, da se ECU nalazi u pogrešnoj dijagnostičkoj sesiji ili da nije izvršena potrebna autorizacija.

Dijagnostičke sesije

Kod UDS-a nije svaka funkcija dostupna u svakom trenutku.

ECU se može nalaziti u različitim dijagnostičkim sesijama. U osnovnoj sesiji dozvoljene su standardne funkcije, dok za programiranje, kalibracije ili napredne procedure može biti potrebno prebacivanje ECU-a u drugu sesiju.

Zato napredna dijagnostička operacija često nije samo jedna komanda, već čitava sekvenca:

1. Uspostavi komunikaciju
2. Promeni dijagnostičku sesiju
3. Izvrši bezbednosnu autorizaciju
4. Pošalji zahtev
5. Proveri odgovor
6. Izvrši proceduru
7. Vrati ECU u normalno stanje

Security Access – Seed/Key

Jedan od tradicionalnih UDS mehanizama zaštite je Security Access.

Tipična procedura izgleda ovako:

Dijagnostički alat  ---- traži seed ----> ECU

Dijagnostički alat  <------ seed -------- ECU

Dijagnostički alat:
izračunava key pomoću odgovarajućeg algoritma

Dijagnostički alat  ------- key --------> ECU

Ako je ključ ispravan, ECU otključava određeni nivo pristupa.

Tek tada mogu postati dostupne funkcije poput:

• kodiranja
• promene određenih konfiguracija
• izvršavanja zaštićenih rutina
• programiranja memorije

UDS nije vezan isključivo za CAN

Još jedna važna stvar je da UDS ne treba poistovećivati sa CAN-om.

UDS definiše značenje dijagnostičkih servisa. Sam UDS može koristiti različite komunikacione tehnologije.

Kod klasične CAN dijagnostike često imamo:

UDS
 |
ISO-TP
 |
CAN

Ali u savremenim vozilima UDS se može prenositi i preko drugih mreža, na primer kroz Ethernet korišćenjem DoIP-a.

To dodatno pokazuje da su CAN i UDS različiti nivoi komunikacije.

J1939 – standardizovani jezik teških vozila

Još jedan odličan primer protokola izgrađenog iznad CAN-a je SAE J1939.

J1939 se veoma često koristi u:

• kamionima
• autobusima
• poljoprivrednim mašinama
• građevinskim mašinama
• industrijskim motorima
• agregatima

Za razliku od mnogih proizvođačkih CAN mreža putničkih vozila, J1939 standardizuje veliki deo značenja poruka.

Zbog toga motor jednog proizvođača, menjač drugog i instrument tabla trećeg mogu razmenjivati standardizovane informacije.

29-bitni CAN identifikator

J1939 koristi prošireni, 29-bitni CAN identifikator.

U njemu se, između ostalog, nalaze informacije povezane sa:

• prioritetom poruke
• tipom poruke
• određenim adresnim informacijama
• adresom izvornog uređaja

Zato CAN ID u J1939 sistemu ima mnogo strukturisanije značenje nego kod mreže u kojoj proizvođač jednostavno proizvoljno dodeljuje identifikatore.

PGN – Parameter Group Number

Jedan od najvažnijih pojmova J1939 protokola je PGN – Parameter Group Number.

PGN označava određenu grupu podataka.

Jedna grupa može sadržati informacije kao što su:

• broj obrtaja motora
• opterećenje
• temperature
• pritisci
• status transmisije
• dijagnostički podaci

SPN – Suspect Parameter Number

Unutar tih grupa nalaze se pojedinačni parametri poznati kao SPN – Suspect Parameter Number.

Pojednostavljeno:

PGN → grupa podataka
SPN → konkretan parametar unutar sistema

J1939 dijagnostika

J1939 ima i sopstvena pravila za dijagnostičke informacije.

Često ćemo sresti:

• DM1 – aktivne dijagnostičke greške
• DM2 – prethodno zabeležene greške
• SPN – parametar na koji se problem odnosi
• FMI – karakter ili način otkazivanja

Zato se na dijagnostici teških vozila mogu pojaviti zapisi poput:

SPN 100 FMI 1

SPN govori koji je parametar u pitanju, dok FMI bliže opisuje vrstu problema.

Proizvođački CAN protokoli

Kod putničkih vozila situacija je često mnogo zatvorenija.

Proizvođač može sam definisati:

• koji CAN ID se koristi
• koji signal se nalazi na kom bitu
• faktor i offset
• periode slanja
• brojače poruka
• kontrolne sume
• dijagnostičke identifikatore
• kodiranja i adaptacije
• sigurnosne procedure

Zbog toga ista CAN poruka može imati potpuno različito značenje na dva različita modela automobila.

ID:

0x280

kod jednog proizvođača može pripadati motoru, kod drugog instrument tabli, a kod trećeg možda uopšte ne postoji.

Zašto univerzalna dijagnostika ne vidi sve?

Ovo sada možemo mnogo lakše razumeti.

Dva dijagnostička uređaja mogu koristiti isti OBD konektor, istu CAN magistralu i isti fizički interfejs, a ipak imati veoma različite mogućnosti.

Razlika nije nužno u sposobnosti uređaja da električno komunicira sa CAN mrežom.

Razlika je često u količini znanja koje alat poseduje o višim slojevima apstrakcije i protokolima konkretnog vozila.

Univerzalni uređaj može znati:

• standardne OBD funkcije
• standardne UDS servise
• veliki broj poznatih proizvođačkih funkcija

ali ne mora imati kompletnu proizvođačku bazu.

Fabrički alat može dodatno posedovati:

• kompletne DID definicije
• procedure kodiranja
• parametre adaptacije
• vođene servisne procedure
• bezbednosne autorizacije
• flash fajlove
• konfiguracione baze

Fabrički dijagnostički alati

Primeri fabričkih sistema su:

• Renault CLIP
• Volkswagen ODIS
• BMW ISTA
• Mercedes-Benz Xentry
• Toyota Techstream
• Ford IDS / FDRS

Oni ne koriste neki „bolji CAN“.

U velikom broju slučajeva komuniciraju preko iste mreže preko koje komunicira i univerzalni alat. Razlika je u tome što fabrički sistem raspolaže detaljnim informacijama o tome koju poruku treba poslati, kada je poslati i kako protumačiti odgovor.

Jedan fizički CAN – više mogućih „jezika“

Na istoj osnovnoj CAN tehnologiji mogu postojati veoma različiti sistemi.

Ova slika možda najbolje objašnjava zašto je CAN istovremeno jednostavan i komplikovan.

Na električnom nivou možemo imati samo dva voda. Na nivou CAN kontrolera možemo imati potpuno ispravan frejm. Ali pravo značenje podataka počinje tek kada poznajemo pravila viših slojeva apstrakcije, odnosno protokola i aplikacionih definicija.

Šta zapravo vidi CAN analizator?

Ako se priključimo na mrežu običnim CAN analizatorom, možemo videti hiljade poruka:

120  01 00 7F 22 18 00 00 00
1A0  3B 08 12 45 FF 00 00 01
280  82 45 01 00 00 00 00 00
3C0  10 27 48 33 19 01 00 00
...

To znači da smo uspešno pristupili CAN mreži.

Ali još uvek ne znači da smo je razumeli.

Da bismo od tih brojeva došli do informacija kao što su:

Temperatura motora: 90 °C
Broj obrtaja:       1726 o/min
Brzina vozila:      64 km/h
Ventilator:         uključen

potrebno je poznavati način na koji su podaci definisani na višem nivou apstrakcije.

Upravo tu počinje reverse engineering CAN mreže.

Zaključak

CAN protokol rešava veoma težak problem – omogućava velikom broju elektronskih uređaja da pouzdano dele istu komunikacionu magistralu.

Ali CAN sam po sebi ne zna ništa o automobilu.

Ne zna šta je motor. Ne zna šta je ABS. Ne zna šta je brzina vozila. Ne zna šta je temperatura. Ne zna šta znači dijagnostička greška.

Za CAN su sve to samo identifikatori, bitovi i bajtovi.

Pravo značenje nastaje tek kroz više slojeve apstrakcije i pravila koja oni definišu:

• DBC opisuje poruke i signale
• ISO-TP omogućava prenos dužih poruka preko CAN-a
• OBD-II standardizuje deo dijagnostičkih podataka
• UDS definiše napredne dijagnostičke servise
• J1939 standardizuje komunikaciju velikog broja sistema teških vozila
• proizvođački protokoli definišu specifične funkcije konkretnog vozila

Zato poznavanje električnog CAN signala i strukture frejma predstavlja tek prvi deo priče.

Onog trenutka kada pokušamo da odgovorimo na pitanje:

„Šta ovaj CAN frejm zapravo znači?“

ušli smo u svet viših slojeva apstrakcije.

A kada poželimo da računar ne samo posmatra CAN mrežu, već da kroz standardizovan interfejs aktivno komunicira sa različitim vozilima i dijagnostičkim protokolima, dolazimo do veoma zanimljive teme:

SAE J2534 PassThru.