UNIVERZA V LJUBLJANI

Fakulteta za elektrotehniko

Matija Cej

ORODJE ZA DIAGNOSTIKO SISTEMOV NA VODILU CAN V REALNEM ASU

DIPLOMSKO DELO VISOKOOLSKEGA STROKOVNEGA TUDIJA

Mentor: prof.dr. Ale Beli

Ljubljana, 2013

ZAHVALA
Zahvaljujem se mentorju prof. dr. Aleu Beliu, univ. dipl. in. el., za vso podporo, strpnost in
vodenje pri nastajanju diplomskega dela ter razvojni skupini za programsko opremo pri
podjetju Letrika, d. d., za idejo, strokovne nasvete in realizacijo orodja, opisanega v
diplomskemu delu. Prav tako se zahvaljujem starem, ki so mi omogoili tudij ter me
podpirali pri tudiju in diplomskem delu, teti za jezikovno pregledan izdelek ter vsem drugim,
ki so mi pri delu kakorkoli pomagali s koristnimi nasveti.

POVZETEK
Zmanjevanje fosilnih goriv in kodljivih izpustov ter uvajanje obnovljivih virov energije
avtomobilsko industrijo vedno bolj usmerjata v razvoj prevoznih sredstev, ki temeljijo na
zelenih tehnologijah, med katere spada tudi elektrika.
V dokaj kratki zgodovini razvoja modernih elektrinih prevoznih sredstev je eno izmed
glavnih vlog prevzel mikrokontroler. Mikrokontroler so mogani prevoznega sredstva, v
katerem se prepleta vrsta informacij. Pospeevanje, zaviranje in obraanje so nekatere izmed
teh, celota pa tvori kompleksen sistem za upravljanje avtonomnega sistema.
Pri razvoju kljuni pomen predstavlja spremljanje parametrov mikrokontrolerja, iz katerih se
oblikujejo zgoraj natete informacije za upravljanje vozila. Parametri omogoajo razvijalcu
vpogled v notranjost delovanja mikrokontrolerja in so kritini pri konnem uporabniku.
Cilj tega diplomskega dela je bila izdelava orodja za diagnostiko sistemov v realnem asu, ki
temelji na protokolu CAN z implementacijo protokola LDTP (Letrika debugging and testing
protocol) na vijem nivoju. To nam je uspelo s pomojo adapterja ifak isCAN USB, ki skrbi
za prenos informacij med raunalnikom in mikrokontrolerjem. Prednost programskega orodja
je v spremljanju 32-bitnih spremenljivk, periodinem spremljanju spremenljivk, preprostosti
ter prijaznosti do konnega uporabnika.
Izdelano programsko orodje bo uporabljeno za spremljanje parametrov pri razvoju elektrinih
avtomobilov v podjetju oziroma pri razvoju mikrokontrolerjev.

Kljune besede: Programsko orodje, protokol CAN, protokol LDTP, mikrokontroler, branje in
pisanje spremenljivk, periodino spremljanje spremenljivk, Ifak isCab USB.

ABSTRACT
Reduction of fossil fuel, harmful emissions and the introdustion of renewable energy sources
directs car industry on developing viachles based on so called green technologies such as
light, wind and also electricity.
In very short history if developing modern electrical viachles a part called microcontroller
took one if the main roles in terms of most important parts in electrical viachle as the brains
of any electrical viachle. There is a lot of information in microcontroller such as accelerating,
braking and starring, ect. All this information together form a complex autonomy system.
To monitor parameters of microcontroller is one of main meanings in developing this part of
the system. Parameters allow developer to look inside the box of microcontroller and their
settings are cricital for end user.
The goal of this work is to build a software development tool for monitornig parameters of
microcontroller which is based on CAN protocol with implementation of LDTP protocol on
higher level of CAN protocol. With help of Ifak IsCan USB adapter, which represent a
interface between computer and microcontroller, we managed to finish a task. The advantage
of this software tool is in monitoring not only 16 bit variables but also 32 bit variables,
periodical monitoring of variables with simplicity and user frendly interface.
This software will be used for monitoring parameters in developnig electrical cars or either
microcontrollers in company.
Key words: softaware development tool, CAN protocol, LDTP protocol, microcontroller,
writing and reading variables, periodical monitoring, Ifak IsCan USB.

KAZALO
1.

UVOD..................................................................................................................................1

2.

SPLONO O KOMUNIKACIJSKIH PROTOKOLIH.......................................................3

3.

2.1.

Osnovne zahteve za sestavo protokola.........................................................................3

2.2.

Oblike omreji ter naini povezovanja.........................................................................4

2.3.

Model ISO/OSI in TCP/IP...........................................................................................6

SPLONO O PROTOKOLIH CAN IN CANOPEN..........................................................8

3.1.

Glavne lastnosti protokola CAN..................................................................................8

3.2.

Struktura protokola CAN v modelu ISO....................................................................10

3.3.

Poiljanje sporoil prek protokola CAN....................................................................11

3.4.

Zakaj uporabljati CAN?.............................................................................................12

3.5.

CANOpen...................................................................................................................13

4.

OBJEKTNO PROGRAMIRANJE....................................................................................14

5.

ORODJE ZA DIAGNOSTIKO.........................................................................................16
4.1.

Zgradba orodja...........................................................................................................16

4.2.

Krmilnik Letrika aek 1350.........................................................................................17

4.3.

Opis protokola LDTP.................................................................................................19

4.3.1.

Opis funkcionalnosti protokola LDTP................................................................19

4.3.2.

Opis protokola.....................................................................................................20

4.4.

Opis modulov programa in pomembnejih funkcij....................................................26

4.4.1.

Modul Mod_Can.................................................................................................26

4.4.2.

Modul Mod_Ldtp................................................................................................29

4.4.3.

Modul Mod_TIdwarf..........................................................................................35

4.4.4.

Uporabniki vmesnik..........................................................................................37

4.4.6.

UML diagram programa.....................................................................................40

6.

SKLEP...............................................................................................................................42

7.

LITERATURA IN VIRI....................................................................................................43

KAZALO SLIK
Slika 1: povezava tokatoka in vetokovna povezava..........................................................4
Slika 2: Tri osnovne oblike omreji: obro, zvezda in vodilo....................................................5
Slika 3: Primerjava modelov ISO/OSI in TCP/IP.......................................................................6
Slika 4: Primer naslavljanja CAN...............................................................................................9
Slika 5: Primer dostopnosti do kanala........................................................................................9
Slika 6: Protokol CAN v modelu ISO/OSI...............................................................................10
Slika 7: Standardna oblika podatkovnega okvirja.....................................................................11
Slika 8: Razirjena oblika podatkovnega okvirja......................................................................11
Slika 9: Zgradba sistema...........................................................................................................16
Slika 10: Shema krmilnika Letrika aek 1350............................................................................17
Slika 11: Zgradba paketa za branje in pisanje posameznih spremenljivk.................................21
Slika 12: Zgradba paketa periodinega branja spremenljivk (CPU PC)...............................23
Slika 13: Zgradba nastavitvenega paketa za periodino spremljanje (PC CPU)..................24
Slika 14: Zgradba paketa uporabnikega vmesnika..................................................................25
Slika 15: Metoda f_CanRxInterpreter.......................................................................................26
Slika 16: Metoda f_CanRXUserHandler..................................................................................27
Slika 17: Funkcija f_MsgT.......................................................................................................28
Slika 18: Handler IFAK_MsgHandler..................................................................................28
Slika 19: Funkciji f_setLDTPServerAddress in f_setLDTPClientAddress..............................29
Slika 20: Funkcija f_Write32bitLDTP......................................................................................30
Slika 21: Funkcija f_CanRxInterpreter.....................................................................................32
Slika 22: Funkcija f_AddVariable.............................................................................................33
Slika 23: Funkcija f_ReceiveVar..............................................................................................34

Slika 24: Primer xml drevesne strukture in vozli..................................................................36

Slika 25: Primer dela datoteke xml z zapisom dwarf...............................................................37
Slika 26: Uporabniki vmesnik.................................................................................................38
Slika 27: Meritve periodino spremljanih spremenljivk v tekstovni datoteki..........................39
Slika 28: UML diagram programa............................................................................................41

KAZALO TABEL
Tabela 1 : Opis bitov podatkovnih okvirjev..............................................................................12
Tabela 2: Podatkovna polja paketa za branje in pisanje posameznih spremenljivk..................21
Tabela 3: Podatkovna polja periodinega paketa......................................................................23
Tabela 4: Podatkovna polja nastavitvenega paketa...................................................................24
Tabela 5: Podatkovna polja uporabnikega vmesnika..............................................................25

UVOD

1. UVOD
S tem ko so elektronska vezja in elementi v avtomobilski industriji izpodrinili mehanske
elemente, je eno izmed glavnih vlog prevzel mikrokontroler, kjer potekajo ukazi za delovanje
in upravljanje avtonomnega sistema.
Z razvojem mikrokontrolerjev se je razvila tudi povezljivost. Dandanes je v svetu veliko
protokolov, ki nudijo razvijalcem povezovanje sistema in mikrokontrolerja. Trenutno je na
tem podroju najbolj uinkovit protokol CAN, ki omogoa predvsem preprosto povezljivost,
robustnost, prilagodljivost, spremljanje v realnem asu in neodvisnost od tipa procesorja v
mikrokontrolerju. Protokol CAN je dominanten komunikacijski sistem za vgrajene sisteme v
avtomobilih [2].
Robustnost protokola CAN je izraena skozi nadgradnjo protokola na vijem nivoju po
standardu ISO/OSI, in sicer z implementacijo protokola CANOpen, ki omogoa robustneje
nastavite. Velike hitrosti in dobra povezljivost pa omogoajo prenos podatkov v realnem asu.
Cilj diplomske naloge je izdelava orodja CAN za diagnostiko sistemov v realnem asu, ki je
preprosto za uporabo in je popolnoma kompatibilno s protokolom CAN oziroma nadgrajenim
protokolom CANOpen. Za povezavo osebnega raunalnika in mikrokontrolerja skrbi adapter
IsCan USB proizvajalca Ifak. Zasnova sistema zaradi svoje univerzalnosti in zgradbe
omogoa preprosto dodajanje novih modulov k programu in prilagajanje uporabnikega
vmesnika.
Univerzalnost protokola CAN smo izkoristili za implementacijo novega protokola LDTP
(Letrika debugging and testing protokol), ki je nadgradnja protokola CANOpen in omogoa
branje posameznih globalnih spremenljivk mikrokontrolerja ter periodino branje globalnih
spremenljivk. Poleg zgoraj natetih lastnosti orodje odlikuje tudi hitro in uinkovito branje
datotek xml, iz katerih so razvidni tip procesorja ter vse spremenljivke, njihovi naslovi,
dolina spremenljivk itd.

13

14

15

SPLONO O PROTOKOLIH CAN IN CANOPEN

2. SPLONO O KOMUNIKACIJSKIH PROTOKOLIH

Protokol je formalen opis pravil za izmenjavo sporoil med oddajnikom in sprejemnikom, ki
jih je treba spotovati, da se raunalniki sistemi v omreju lahko med seboj sporazumevajo
[3].
Komunikacijski sistemi uporabljajo za izmenjavo sporoil dobro definirane formate: vsako
sporoilo ima svoj unikatni pomen, kar omogoa pravilen odziv na strani sprejemnika. e
hoemo, da mehanizem poiljanja deluje pravilno, mora protokol obsegati sintakso (zapis),
semantiko (pomen zapisa) in komunikacijsko sinhronizacijo. Protokol je neodvisen od
implementacije, tako da je lahko vkljuen kot strojna ali kot programska oprema. Velja tudi
tesna analogija med protokoli in programskimi jeziki: protokoli so v komunikacijah tako
pomembni, kot so izrauni pomembni za programske jezike ali algoritme [4, stran 177].
2.1. Osnovne zahteve za sestavo protokola
-

Podatkovne oblike za izmenjevanje podatkov.

Naslovne oblike za izmenjevanje podatkov.
Shranjevanje naslovov potrebno za prehajanje med sloji v omreju.
Povezljivost.
Detekcija napak.
Potrditvena sporoila.
Ponovitvena in potrditvena sporoila nastopijo ob izgubi ali zakljuku prenosa

podatkov.
Smer poteka informacij pomembno pri enosmerni komunikaciji (polovini dupleks).
Mehanizem za kontrolo sekvenc sporoila z velikim obsegom podatkov se delijo na

sporoila (sekvence) z manjim obsegom.

Nadzor pretoka informacij skrbi za uravnavanje hitrosti oddaje in sprejema med
sprejemnikom in oddajnikom (sprejemnik v nekaterih primerih sporoil ne more tako
hitro sprejemati, kot jih lahko oddaja oddajnik).

2.2. Oblike omreji ter naini povezovanja

16

SPLONO O PROTOKOLIH CAN IN CANOPEN

Ker eno samo vozlie ne zadoa za komunikacijo (potrebni sta vsaj dve), sta pri njej
znailna dva naina povezovanja vozli (naprava, ki v omreju opravlja komunikacijske
naloge) (Slika 1) :
-

Povezava tokatoka, ki si jo v telekomunikacijah lahko predstavljamo kot telefonski

klic med dvema osebama: sprejemnik lahko slii samo tisto, kar oddajnik odda.
Vetokovna povezava, pri kateri lahko oddano sporoilo prejme ve vozli. Primer
takne povezave sta radio in televizija.

Slika 1: povezava tokatoka (zgoraj) in vetokovna povezava (spodaj)

Z velikim tevilom vozli se zaradi kompleksnosti in pravilnega delovanja pojavijo omreja,
v katera so vozlia povezana. Poznamo tri osnovne oblike omreij, in sicer vodilo, zvezdo in
obro (Slika 2). Vsa ta omreja so med seboj deloma povezana, bistveno pa se razlikujejo po
dostopu do prenosnega sredstva:
-

Pozivanje ali izbiranje (zvezda in vodilo): deluje tako, da se izbere ali pozove vozlie,

ki bo oddajalo.
eton (obro in vodilo): dostop deluje po principu podajanja etona. Tisto vozlie, ki

ima eton, je doloeno kot oddajnik.

Nakljuni dostop (vodilo): vozlie, ki bo oddajalo, je izbrano nakljuno.

17

SPLONO O PROTOKOLIH CAN IN CANOPEN

Slika 2: Tri osnovne oblike omreij: obro, zvezda in vodilo.

18

SPLONO O PROTOKOLIH CAN IN CANOPEN

2.3. Model ISO/OSI in TCP/IP

Zaradi velikega tevila razlinih protokolov in prepletanja protokolov med programsko in
strojno opremo sta se pojavila referenna modela ISO/OSI ter protokola TCP/IP (Slika 3), ki
predstavljata modulirano zgradbo protokolov, kjer vsak sloj oziroma plast v modelu opravlja
svoje naloge, skupek slojev oziroma plasti pa deluje kot celota.
Referenni model ISO/OSI, ki je bil razvit leta 1984, velja za osnovni arhitekturni model za
komunikacijo med raunalniki in je sestavljen iz sedmih plasti, medtem ko je protokol TCP/IP
sestavljen iz tirih plasti. Na vsaki so doloene posamezne omrene funkcije.

Slika 3: Primerjava modela ISO/OSI in protokola TCP/IP. Protokol TCP/IP veliko bolj
poudarja pomen mrenih funkcij, medtem ko manj poudarja pomen podomrenega sloja.
Aplikacijske funkcije so v modelu OSI precej bolj razslojene.

19

SPLONO O PROTOKOLIH CAN IN CANOPEN

Opis slojev modela ISO/OSI:

-

Fizini sloj:
Skrbi za prenos digitalnih signalov po prenosnih sredstvih, kot so bakreni
vodniki ali optina vlakna. Osnovna podatkovna enota je bit. V tem sloju se

definira nivo signala, hitrost prenosa ter nain zapisa podatkov.

Linijski sloj:
Skrbi za zanesljiv prenos okvirjev (osnovna podatkovna enota zaporedje
bitov) med sosednjimi vozlii. Ta sloj doloa enote sporoila, nain
ugotavljanja napak (CRC, LRC), kontrolo pretoka, potrjevanje okvirjev (ABP,

GBN).
Omreni sloj:
Skrbi za delovanje omreja kot celote in zagotavlja pot prenosa od izvornega
do ponornega vozlia, kar pomeni, da vzpostavlja, prekinja in vzdruje

povezavo med uporabniki. Osnovna podatkovna enota sloja je paket.

Prenosni sloj:
Skrbi za prenos podatkovnih enot skozi omreje od izvornega do ponornega
vozlia. Sloj definira nain prenosa ter dolga sporoila razbije na manje dele

(sekvence). Osnovna podatkovna enota je paket ali segment.

Pogovorni sloj:
Skrbi za prenos podatkovnih enot skozi omreje od izvornega do ponornega
vozlia znotraj vozlia, kar pomeni, da nadzira komunikacijo med
raunalniki, vzpostavlja in prekinja komunikacijo ter doloa vrsto komunikacij.

Osnovna podatkovna enota je PDU (protokolovna podatkovna enota).

Predstavitveni sloj:
Skrbi za ustrezno kodiranje in prekodiranje podatkov, zgoevanje podatkov,

ifriranje ter vsebuje sisteme pretvorb za aplikacijski sloj.

Uporabniki sloj:
Skrbi za zagotavljanje storitev konnemu uporabniku (vmesnik med
uporabnikom in modelom).

20

SPLONO O PROTOKOLIH CAN IN CANOPEN

3. SPLONO O PROTOKOLIH CAN IN CANOPEN

Protokol CAN (Controller area network) je sistem, katerega podatki se prenaajo prek
omreja v topologiji serijskega vodila in temelji na delovanju v realnem asu z visoko stopnjo
varnosti.
Hitrosti prenosa podatkov prek protokola CAN dosegajo hitrosti do 1MBit/s in padajo z
dolino kabla. Prav visoka hitrost glede na preprostost oienja je najpomembneja lastnost
protokola CAN.
Na mreo CAN (kot imenujemo ve naprav, povezanih med seboj) se preprosto prikljuimo z
adapterjem, ki je razvijalcu lahko dostopen, in tako lahko dostopamo do vseh naprav v mrei.
3.1. Glavne lastnosti protokola CAN
-

Naslavljanje CAN

Za protokol CAN je znailno, da vozlia v mrei nimajo naslovov, kar pomeni, da lahko vsa
vozlia poiljajo ali sprejemajo sporoila. Vsako oddano sporoilo je poslano vsem
vozliem v mrei. Za ta namen ima vsako oddano sporoilo svojo identifikacijsko tevilko,
vozlia pa so konfigurirana za oddajanje in sprejemanje sporoil samo z danimi naslovi
(identifikacijskimi tevilkami). Shema delovanja naslavljanja je prikazana na Sliki 4.

21

SPLONO O PROTOKOLIH CAN IN CANOPEN

Slika 4: Primer naslavljanja CAN. Vozlie V4 odda sporoilo z unikatno identifikacijsko

tevilko. Sporoilo je poslano vsem vozliem, vendar samo vozlii V1 in V6 zaradi svoje
konfiguracije poslano sporoilo tudi sprejmeta. Pri drugih vozliih se sporoilo preprosto
zavre.
-

Dostopnost do kanala

Vodilo se obnaa kot krajevno porazdeljena logina vrata IN. V primeru soasne oddaje dveh
postaj (vozli) nila (dominantna) prevlada nad enico (recesivna). Na tej logiki temelji
celoten sistem, ki daje prednost sporoilom z nijo identifikacijsko tevilko (Slika 5).

Slika 5: Primer dostopnosti do kanala. Vozlie 2 odda sporoilo z najvijo prioriteto. Vsa
vozlia med oddajo tudi sprejemajo. e se sprejem in oddaja razlikujeta, prekinejo
oddajo in samo sprejemajo.

22

SPLONO O PROTOKOLIH CAN IN CANOPEN

23

SPLONO O PROTOKOLIH CAN IN CANOPEN

3.2. Struktura protokola CAN v modelu ISO

Slika 6: Protokol CAN v modelu ISO/OSI.

24

SPLONO O PROTOKOLIH CAN IN CANOPEN

3.3. Poiljanje sporoil prek protokola CAN

Protokol CAN vsebuje dve razlini obliki okvirjev, in sicer standardne z 11-bitnim
identifikatorjem in razirjene z 29-bitnim identifikatorjem.
Tipi okvirjev, s katerimi se prenaajo sporoila v protokolu CAN:
-

Podatkovni okvir skrbi za prenos podatkov med oddajnikom in sprejemnikom (Slika 7 in 8).
Prenosni okvir skrbi za poiljanje zahtev za zaetek prenosa podatkovnega okvirja z enakim

identifikatorjem.
Okvir za napake skrbi za javljanje napak.
Okvir prekoraitve skrbi za dodatno zakasnitev prenosa med akajoimi in konanimi
podatkovnimi ali prenosnimi okvirji, e je potrebno.

Slika 7: Standardna oblika podatkovnega okvirja

Slika 8: Razirjena oblika podatkovnega okvirja

Tabela 1 : Opis bitov podatkovnih okvirjev.
Ime

Opis

25

SPLONO O PROTOKOLIH CAN IN CANOPEN

bit RTR

bit SRR

bit IDE

biti DLC

Bit nam pove, ali gre za podatkovni ali

prenosni tip okvirja.
Podatkovni okvir 0
Prenosni okvir 1
Nadomea vlogo bita RTR za prvim
osnovnim 11-bitnim identifikatorjem
razirjenega paketa.
Skrbi za pravilno interpretacijo, ali gre za
standardni ali razirjeni format okvirja.
Standardni format 0
Razirjen format 1
Polje sestavljajo 4 biti, ki dajejo informacijo,
koliko bajtov podatkov okvir prenaa: e npr.
prenaa 0 bajtov, bo polje DLC enako 0000

3.4. Razlogi za uporabo protokola CAN

-

Delovanje v realnem asu pri izdelkih, kjer lovek nadzoruje delovanje (avtomobili,
viliarji, razna dvigala, ladje ) je najpomembneji hiter odziv. CAN zagotavlja
delovanje v realnem asu, kar pomeni, da je ukaz izvren v trenutku lovekovega

ukaza.
Dostopnost prikljuitev na mreo CAN mora biti razvijalcu hitro, takoj in lahko
dostopna. CAN omogoa takno prikljuitev, saj ima razvijalec s prikljuitvijo

adapterja pod nadzorom vse naprave v tej mrei.

Fleksibilnost razvoja programskih orodij CAN je univerzalni standard, ki ga lahko

uporabimo v vsakem programskem jeziku.

Neodvisnost procesorja protokol CAN je neodvisen tudi od tipa procesorja.

Delovanje poteka enako ne glede na to, v katerem procesorju poteka proces.

Robustnost CAN omogoa prilagajanje glede na to, kaj zahteva konni uporabnik in
kdo je konni uporabnik (kupec, serviser, tehnik ).

3.5. Sistem protokolov CANOpen

CANOpen je protokol, ki se nanaa na vije leei sloj protokola CAN. Razvit je bil kot
standardizirano vgrajeno omreje zaradi potrebe bo robustneji konfiguraciji (ve monosti

26

SPLONO O PROTOKOLIH CAN IN CANOPEN

nastavljanja). CANOpen razbremenjuje razvijalca na taken nain, da lahko specifine detajle,

kot je npr. bitna hitrost, zaradi robustneje zasnove preprosto zanemari. CANOpen omogoa
komunikacijsko kompatibilnost, operabilnost in integrabilnost z napravami. Omogoa, da
razvijalci s svojimi produkti razvijejo svoj uporabniki vmesnik s pripadajoimi funkcijami in
zahtevami.
Protokoli CANOpen
CANOpen razpolaga z ve komunikacijskim objekti, ki omogoajo razvijalcu prenos ukazov,
odziv na napake itd. na krmilniku. Naprava CANOpen je zgrajena iz treh delov:
aplikacijskega dela (nadzor vhodov in izhodov), objektnega slovarja (skupek parametrov, ki
omogoa dostop do konfiguracije) ter protokola CANOpen.
-

Protokol SDO

Storitveni podatkovni objekti (SDO Service data object) omogoajo dostop do vseh
objektnih slovarjev CANOpen (OD Object dictionary). Protokol SDO vzpostavi
komunikacijski kanal peer-to-peer med dvema napravama, med katerima prenaa podatke v
segmentirani obliki. Uporablja se za komunikacijo nastavitvenih podatkov (nastavljanje in
branje vrednosti iz objektnega slovarja naprave).
Naprava CANOpen lahko podpira do 128 kanalov SDO za strenik in do 128 kanalov za
odjemalce. Vsak podprti kanal SDO je lahko nastavljen s pravilnim komunikacijskoobjektnim prepoznavalnikom (COB ID communication object identifier), ki je vezan na tono
doloen set parametrov SDO.
-

Protokol PDO

Procesni podatkovni objekti (PDO Process data object) so kratka visoko prioritetna
sporoila protokola CAN, ki so prenesena med oddajo. Uporabljajo se za komunikacijo,
medtem ko delujemo na napravi v realnem asu. Sporoila PDO so poslana na nepotrjen
nain, kar pomeni, da potrditveni paket, poslan na povratni poti, ne obstaja.

27

OBJEKTNO PROGRAMIRANJE

4. OBJEKTNO PROGRAMIRANJE
Objektno programiranje je nain programiranja, ki izhaja iz podatkovnih struktur. Osnovni
gradnik pri objektnem programiranju je objekt, ki ga opredeljujejo lastnosti (spremenljivke
objekta) in metode (funkcije, ki delajo s podatki objekta). Objekti med seboj komunicirajo in
so navadno zdrueni v razredih (skupek funkcij, ki delujejo kot celota za dokonanje neke
naloge), ki oznaujejo objekte sorodnega tipa. Za lajo predstavo: Na nivoju spremenljivk tip
spremenljivke (celotevilska, znakovna, s plavajoo vejico) igra enako vlogo kot razred,
medtem ko je sama vrednost spremenljivke enaka objektu. Tako bi za primer lahko ustvarili
razred z imenom Osebe, v katerem so objekti imena oseb.
Pomembneja principa objektnega programiranja:
-

Dedovanje
Dedovanje omogoa ustvarjanje razredov, ki so izpeljani iz drugih razredov.
Tako izpeljan razred vsebuje nekatere dele starevskega razreda (tako
imenujemo razred, iz katerega dedujemo) kot svoje. Za primer si lahko
zamislimo razred Oblike, v katerem so definirana objekta viina in irina. Iz
tega razreda lahko dedujemo razreda Trikotnik in Kvadrat, ki bosta uporabljala
objekta starevskega razreda s to razliko, da bo v razredu Trikotnik npr.
ploina ((viina*irina)/2) drugae zapisana kot v razredu Kvadrat

(viina*irina), vrednosti pa bodo nastavljene glede na starevski razred.

Polimorfizem
Polimorfizem omogoa, da je kazalec (eden izmed osnovnih podatkovnih tipov
programskega jezika C++, ki nam omogoa pogled na fizino pomnilniko
lokacijo), ki kae na dedovani razred, popolnoma zdruljiv s kazalcem, ki kae
na osnovni razred, iz katerega je dedovani razred. Posebna veja polimorfizma
so tudi virtualne metode. e npr. funkcijo osnovnega razreda v dedovanem
razredu spremenimo, to imenujemo virtualna metoda.

28

OBJEKTNO PROGRAMIRANJE

Prednosti in pridobitve objektnega programiranja v primerjavi s konvencionalnimi metodami

programiranja :
-

Kraji as razvoja: Kadar je razred objekta ustvarjen, je lahko uporabljen vekrat,

lahko ga po potrebi dodatno razirimo in je modularen.

Laje razhroevanje: Razredi so lahko testirani neodvisno drug od drugega. S tem
si zmanjujemo obmoje iskanja napake. Poleg tega so objekti, ki smo jih ponovno

uporabili, e testirani.
Bolje testiranje ter posledino bolja kvaliteta.
Neodvisnost aplikacije z uporabnikim vmesnikom.
Preprost prenos realnega problema v programsko kodo.
Niji stroki razvoja ter kraji as razvoja posledino omogoajo kvalitetnejo
programsko opremo.

Toda:
-

Uenje, ki temelji na objektnem programiranju, lahko vzame veliko asa.

Velikost programa neprimerno za mikrokrmilnike z manjim pomnilnikom.
Poasneji programi, zahtevneja obdelava ve potrebnih korakov za izvritev

ukaza.
Neprimerno za reevanje nekaterih problemov.

29

ORODJE ZA DIAGNOSTIKO

5. ORODJE ZA DIAGNOSTIKO
4.1. Zgradba orodja

Slika 9: Zgradba sistema

Celotni sistem orodja za diagnostiko (Slika 9) je sestavljen iz:
-

napajalnika, ki skrbi za napajanje krmilnika (48 V).

krmilnika Letrika aek 1350, ki predstavlja strojno opremo sistema. Deluje na
podlagi digitalnega signalnega procesorja ter vsebuje protokol CANOpen.

Programiranje poteka prek osebnega raunalnika.

adapterja IsCan usb Ifak, ki skrbi za povezavo med osebnim raunalnikom in
krmilnikom. Deluje na podlagi protokola CAN, tako da omogoa hitrosti do

1Mbit/s ter hitro povezljivost na omreje.

osebnega raunalnika, ki predstavlja drugi del oziroma programsko opremo
krmilnika in na katerem poteka program, predstavljen v nadaljevanju. Program je
napisan v programskem jeziku C++ s pomojo programa C++ builder. V program
je implementiran protokol LDTP, ki predstavlja nadgradnjo protokola CANOpen.
Sestavljajo ga trije moduli in grafini vmesnik za najboljo interakcijo s konnim
uporabnikom. Celotna zgradba programa je prikazana v diagramu UML na Sliki
28.

30

ORODJE ZA DIAGNOSTIKO

4.2. Krmilnik Letrika aek 1350

Slika 10: Shema krmilnika Letrika aek 1350. Krmilnik vsebuje est digitalnih vhodov, est
digitalnih izhodov, dva analogna vhoda, en analogni izhod, prikljuke za komunikacijo CAN,
5 V- in 12 V-napajanje, prikljuke za enkoder, ozemljitev ter key in.

31

ORODJE ZA DIAGNOSTIKO

Glavne lastnosti krmilnika :

-

Pretvornik enosmerne napetosti na trifazno izmenino napetost.

Deluje na podlagi procesorja DSP (Digitalno signalni procesor), ki omogoa

kontrolo magnetnega pretoka izmeninega motorja v realnem asu.

Vsebuje protokol CANOpen ter razline prikljuke, ki omogoajo raznovrstne

vgradnje.
Programiranje poteka prek osebnega raunalnika.
Komunikacija poteka prek RS232 ali protokola CAN.
Uporablja se v avtomobilski industriji za avtomobile za golf, letalike avtomobile
za prevoz prtljage itd.

Komunikacija med krmilnikom (Slika 10) in osebnim raunalnikom je potekala na podlagi

protokola CAN, in sicer s pomojo vmesnika IsCan USB proizvajalca Ifak. Lastnosti
vmesnika so kompatibilne z lastnostmi protokola CAN (hitrost prenosa, podatkovni okvirji,
hitra povezljivost).

32

ORODJE ZA DIAGNOSTIKO

4.3. Opis protokola LDTP

4.3.1. Opis funkcionalnosti protokola LDTP
1. Branje posameznih globalnih spremenljivk
Ena izmed glavnih in tudi osnovnih funkcij protokola LDTP je branje posameznih globalnih
spremenljivk mikrokontrolerja. Beremo lahko poljubno lokacijo iz pomnilnika RAM
mikrokontrolerja preprosto tako, da podamo naslov in velikost naslova. Lahko beremo tudi
poljubno lokacijo iz pomnilnika NVRAM (non volatile memory) oziroma FRAM, ki ga v
sistemu uporabljamo kot zaasen pomnilnik ob izpadu elektrinega napajanja.
2. Periodino branje globalnih spremenljivk
Druga glavna funkcija protokola je periodino branje globalnih spremenljivk oziroma
periodino spremljanje spremenljivk iz poljubne lokacije pomnilnika RAM. Periodino
spremljanje aktiviramo s posebnim ukazom, perioda poiljanja pa se nastavlja z globalno
spremenljivko v programu. Tipina perioda je dolga 10 ms, vendar se lahko spreminja glede
na obremenjenost mree CAN in bitne hitrosti prenosa podatkov. Omogoeno je spremljanje
poljubnega tevila 16- in 32-bitnih spremenljivk, vendar z naraanjem tevila spremenljivk
naraa tudi perioda poiljanja, ker se podatki delijo v ve paketov. Ta del protokola ja
zasnovan tako, da veino dela opravi osebni raunalnik, mikrokontroler pa s tem ostane
neobremenjen.
3. Uporabnika forma
Ta del protokola je namenjen hitremu testiranju krmilnika. Programer oziroma razvijalec
lahko ta del protokola prilagaja svojim potrebam. Tu najdemo funkcije, ki omogoajo vrtenje
motorja z vektorsko regulacijo navora, aktiviranje in deaktiviranje periodinega branja,
regulacijo hitrosti, tokovni sinus
Ta del protokola se uporablja kot dvosmerna komunikacija med krmilnikom in uporabniko
formo v aplikaciji PC. V smeri krmilnika proti osebnemu raunalniku se prenaajo biti stanja
krmilnika in trenutne vrednosti najpomembnejih veliin, medtem ko se v nasprotni smeri
prenaajo referenne vrednosti, nastavitve in ukazi.

33

ORODJE ZA DIAGNOSTIKO

4.3.2. Opis protokola

Protokol je zasnovan kot nadgradnja protokola CANOpen. Knjiica CANOpen (objektni
slovar) poskrbi, da pridejo podatki do elenega naslovnika brez napak. Kot nosilni paket
protokola je uporabljen paket PDO, ki je enosmerna povezava med dvema vozliema mree
brez povratnega potrditvenega sporoila (nepotrjen nain). LDTP paket se vstavi v 64 bitov
dolg paket PDO.
1. Princip delovanja pisanja in branja posameznih spremenljivk
Branje oziroma pisanje poteka tako, da se prek objekta PDO polje napravi ustrezen paket
(Slika 11). Paketu sledi ustrezen povratni paket, ki ima enak format. Pri branju spremenljivke
povratni paket nosi informacijo o vrednosti spremenljivke, medtem ko je pri pisanju povratna
informacija potrditev vpisa vsa polja so pri odgovoru enaka, le v polju Value je vrednost, ki
jo preberemo iz elene lokacije po vpisu. Na ta nain na strani PC preverimo pravilnost vpisa.
Povratni paket nam slui tudi kot preverjanje, ali je naprava vkljuena, saj je v tem primeru
paket obdelala in poslala.
Polje Address omogoa zapis do irine 24 bitov, kar nam zadoa za branje vseh monih
naslovov iz mikroprocesorjev druine C2000.
Polje Value omogoa zapis vrednosti do irine 32 bitov.

34

ORODJE ZA DIAGNOSTIKO

Slika 11: Zgradba paketa za branje in pisanje posameznih spremenljivk. Vrednosti v tabeli so
zapisane tako, da je na prvem mestu LSB (Least significant byte), najniji bajt podatka, na
zadnjem mestu pa MSB (Most significant byte), najviji bajt podatka. Takemu nainu
razporejanja bitov se imenuje big endian. Biti znotraj posameznih bajtov pa so razporejeni
klasino po nainu little endian.
Tabela 2: Podatkovna polja paketa za branje in pisanje posameznih spremenljivk.
Bit
63 - 60
59

Ime
/
MT

Vrednost
0xF

Opis
Identifikacija tipa paketa
Memory type bit
Dostop do pomnilnika RAM
Dostop do pomnilnika NVRAM
Tip dostopa bralni ali pisalni
Bralni
Pisalni
irina podatka
8 bitov (byte)
16 bitov (Word)
32 bitov (DWord)
rezervirano
LSB, 2. bajt in MSB naslova
LSB, 2. bajt, 3. bajt in MSB podatka

0
1
58

RW
0
1

57 - 56

LEN
0
1
2
3

55-32
31-0

Address
Value

35

ORODJE ZA DIAGNOSTIKO

2. Princip delovanja periodinega branja spremenljivk

Mikrokrmilnik mora imeti implementiran medpomnilnik z elementi doline 32 bitov, ki
vsebujejo naslove posameznih spremenljivk, ki jih hoemo periodino spremljati. Dolina
medpomnilnika se lahko doloi poljubno, vendar je maksimalno tevilo elementov (in s tem
tudi spremljanih spremenljivk) enako 222 (indeksi od 0 do 221).
Komunikacija poteka tako, da prek podatkovnega paketa za nastavljanje spremljanih
spremenljivk (Slika 13) na zaporedna mesta vpiemo njihove naslove. Vsak element
medpomnilnika slui branju enega 16-bitnega podatka. Pri spremljanju 32-bitnih spremenljivk
mora program na osebnem raunalniku poskrbeti, da v medpomnilniku naslove nastavi tako,
da dobi obe 16-bitni polovici in jih zdrui v 32-bitno celoto.
Mikroprocesor vsakokorat odgovori s paketom, ki ima enak format (Slika 12). e je sprejeti
paket enak poslanemu, je nastavitev uspeno izvedena. Ko je na vrsti naslednja perioda
poiljanja spremenljivk, mikroprocesor polje toliko paketov, da na osebni raunalnik prenese
vse elene spremenljivke (po vrsti bere iz medpomnilnika, dokler ne naleti na indeks 0). V en
paket lahko zapiemo tri 16-bitne spremenljivke, medtem pa vsak paket dobi tudi svoj indeks
N, ki nosi tevilko od 0 do 73 (Maksimalno tevilo spremljanih spremenljivk je 222. V vsak
paket lahko zapiemo tri spremenljivke: 222/3 = 74.).
Program na osebnem raunalniku mora poskrbeti, da se naslovi v medpomnilniku polnijo po
vrsti brez vmesnih vrzeli. Prav tako mora poskrbeti, da ob dodajanju nove spremenljivke
naloi e enkrat celoten medpomnilnik. Bajti so v paketu razporejeni enako kot pri branju ali
pisanju posameznih spremenljivk.

36

ORODJE ZA DIAGNOSTIKO

Slika 12: Zgradba paketa periodinega branja spremenljivk (CPU PC).

Tabela 3: Podatkovna polja periodinega paketa.

Bit
63 - 56

Ime
N

Vrednost
0 - 73

Opis
Zaporedna tevilka paketa

55-48

Reserved

Se ne uporablja

47-40

Value (3*N + 0)

LSB bajt podatka iz medpomnilnika

39-32

Value (3*N + 0)

MSB bajt podatka iz medpomnilnika

31-24

Value (3*N + 1)

LSB bajt podatka iz medpomnilnika

23-16

Value (3*N + 1)

MSB bajt podatka iz medpomnilnika

15-7

Value (3*N + 2)

LSB bajt podatka iz medpomnilnika

7-0

Value (3*N + 2)

MSB bajt podatka iz medpomnilnika

37

ORODJE ZA DIAGNOSTIKO

Slika 13: Zgradba nastavitvenega paketa za periodino spremljanje (PC CPU).

Tabela 4: Podatkovna polja nastavitvenega paketa.

Bit
63 - 56

Ime
0x56

Vrednost
0x56

Opis
Identifikacija tipa paketa

55-48

Buffer index

0 - 221

Zaporedna t. vpisa v medpomnilnik

47-40

Reserved

Se ne uporablja

39-32

Reserved

Se ne uporablja

31-24

Address [7-0]

23-16

Address [15-8]

LSB bajt spremenljivke, ki jo hoemo

spremljati
2. bajt spremenljivke, ki jo hoemo spremljati

15-7

Address [23-16]

3. bajt spremenljivke, ki jo hoemo spremljati

7-0

Address [31-24]

MSB bajt spremenljivke, ki jo hoemo

spremljati

38

ORODJE ZA DIAGNOSTIKO

3. Princip delovanja uporabnikega vmesnika

Uporabniki vmesnik je implementiran kot dvosmerna komunikacija brez potrditvenih
paketov (Slika 14). Komunikacijska pot CPU PC je implementirana kot sinhrona
komunikacija s fiksno periodo, saj prenaa izmerjene koliine in stanja krmilnika. Nasprotna
pot PC CPU je lahko sinhrona ali asinhrona. Vsak paket v tej smeri je ukaz zase in nanj se
krmilnik odzove, rezultat pa je viden v paketih CPU PC.

Slika 14: Zgradba paketa uporabnikega vmesnika. Paketi za vsako smer komunikacije imajo
4-bitno identifikacijsko polje N, zato lahko vzpostavimo komunikacijo s 16 paketi v vsako
smer. V vsakem paketu imamo prostora za prenos sedmih ukazov (skupno 16 x 7 bajtov).
Tabela 5: Podatkovna polja uporabnikega vmesnika.
Bit

Ime

Vrednost

Opis

63 60
59-56
55-48
47-40
39-32
31-24
23-16
15-8
7-0

0xE
N
User byte 0
User byte 1
User byte 2
User byte 3
User byte 4
User byte 5
User byte 6

0xE
0-15

Indetifikacija tipa paketa

Identifikacija do 16 podpaketov
Uporabnikovi podatki
Uporabnikovi podatki
Uporabnikovi podatki
Uporabnikovi podatki
Uporabnikovi podatki
Uporabnikovi podatki
Uporabnikovi podatki

39

ORODJE ZA DIAGNOSTIKO

4.4. Opis modulov programa in pomembnejih funkcij

4.4.1. Modul Mod_Can
Modul Mod_Can vsebuje vse potrebne metode za inicializacijo gonilnika vmesnika IsCan
USB Ifak, poiljanje sporoil in njihovo sprejemanje.
Ta modul je v programu uporabljen tako, da iz njega dedujemo neki drug modul (modul
Mod_Ldtp), v katerem je implementiran neki drug protokol (protokol LDTP) nad osnovnim
protokolom CAN. Med obema moduloma poteka oddajanje paketov CAN prek klica ustrezne
metode, sprejem pa poteka tako, da modul Mod_Can klie virtualno metodo dedovanega
razreda s parametrom, ki predstavlja strukturo prejetega paketa.
Dodajmo e to, da komunikacija med modulom in dedovanimi razredi poteka z univerzalno
strukturo sporoila ne glede na to, ali gre za 29-bitno ali 11-bitno naslavljanje. To omogoa
preprosto spremembo konne aplikacije za nov adapter CAN.
4.4.1.1.

Opis funkcij modula Mod_Can

void Tmod_CAN::f_CanRxInterpreter(structCanMsgTypeUser str_MsgRx)

{
}

Slika 15: Metoda f_CanRxInterpreter.

To je virtualna metoda (Slika 15), ki je v modulu Mod_Can prazna. Uporabljajo jo dedovani
razredi, in sicer zato, da prek nje sprejemajo osnovna sporoila razreda Tmod_CAN.
Parameter virtualne metode je univerzalna struktura CAN za sprejemanje sporoil.

40

ORODJE ZA DIAGNOSTIKO

void Tmod_CAN::f_CanRXUserHandler()
{
if( b_LibraryOpen && b_DeviceOpen && b_MsgHandlerOpen)
{
BYTE i_Result;
if(b_ExtendedMsg == false)
{
i_Result = isCAN_ReceiveMessageNorm(i_DeviceNum,
&str_MsgRxNorm);
if(i_Result == 0)
{
str_MsgRx.MessageID = str_MsgRxNorm.MessageID;
str_MsgRx.Extended = 0;
str_MsgRx.RemoteReq = str_MsgRxNorm.RemoteReq;
str_MsgRx.DataLen = str_MsgRxNorm.DataLen;
for(int i = 0; i < str_MsgRxNorm.DataLen; i++)
{
str_MsgRx.Data[i] = str_MsgRxNorm.Data[i];
}
f_CanRxInterpreter(str_MsgRx);
}

}
else
{

i_Result = isCAN_ReceiveMessageExt(i_DeviceNum, &str_MsgRxExt);

if(i_Result == 0)
{
str_MsgRx.MessageID = str_MsgRxExt.MessageID;
str_MsgRx.Extended = 1;
str_MsgRx.RemoteReq = str_MsgRxExt.RemoteReq;
str_MsgRx.DataLen = str_MsgRxExt.DataLen;
for(int i = 0; i < str_MsgRxExt.DataLen; i++)
{
str_MsgRx.Data[i] = str_MsgRxExt.Data[i];
}
}
}

f_CanRxInterpreter(str_MsgRx);

Slika 16: Metoda f_CanRXUserHandler.

Metoda (Slika 16) prevzame sprejeto sporoilo CAN iz Ifak API-ja (vmesnik za
programiranje aplikacij) in ga prepie v univerzalno uporabniko strukturo ne glede na to, ali
gre za razirjeni ali standardni paket. Paziti pa moramo na to, da ko paket prepiemo v

41

ORODJE ZA DIAGNOSTIKO

univerzalno strukturo, uberemo dve razlini poti glede na to, kakna vrsta paketa je na vrsti za
obdelavo (standardni ali razirjeni).
void Tmod_CAN::f_MsgTx(structCanMsgTypeUser msg)
{
if( b_LibraryOpen && b_DeviceOpen && b_MsgHandlerOpen)
{
if(b_ExtendedMsg == false)
{
str_MsgTxNorm.MessageID = msg.MessageID;
str_MsgTxNorm.RemoteReq = msg.RemoteReq;
str_MsgTxNorm.DataLen = msg.DataLen;
for(int i = 0; i < msg.DataLen; i++)
{
str_MsgTxNorm.Data[i] = msg.Data[i];
}
isCAN_TransmitMessageNorm(i_DeviceNum, &str_MsgTxNorm);
}
else
{

str_MsgTxExt.MessageID = msg.MessageID;
str_MsgTxExt.RemoteReq = msg.RemoteReq;
str_MsgTxExt.DataLen = msg.DataLen;
str_MsgTxExt.bExtended=true;
for(int i = 0; i < msg.DataLen; i++)
{
str_MsgTxExt.Data[i] = msg.Data[i];
}
isCAN_TransmitMessageExt(i_DeviceNum, &str_MsgTxExt);

Slika 17: Funkcija f_MsgT.

Podobno obliko ima funkcija za poiljanje sporoila CAN (Slika 17), ki zna iz univerzalne
strukture generirati strukturo API glede na tip paketa in jo predati API-ju. Za parameter
uporablja paket msg, ki ga hoemo poslati (v univerzalnem formatu).
void __cdecl IFAK_MsgHandler(BYTE deviceNr, void *pContext)
{
Tmod_CAN *owner;
owner = static_cast<Tmod_CAN*>(pContext);
owner->f_CanRXUserHandler();
}

Slika 18: Handler IFAK_MsgHandler.

42

ORODJE ZA DIAGNOSTIKO

Handler za sprejeta sporoila adapterja Ifak (Slika 18). To je osnovni handler, ki ga

poklie

API

gonilnika

Ifak.

Od

tod

dalje

se

kliejo

naslednje

funkcije

(f_CanRXUserHandler()), ki jih sproi sprejem novega paketa. Za parametre vsebuje

deviceNr, ki nam pove tevilko adapterja, kjer je bilo sporoilo prejeto in *pContext kot
pomoni kazalec iz API-ja, ki ga nastavimo pri inicializaciji handlerja. Ta parameter nosi
kazalec na objekt tipa Tmod_CAN, prek katerega kliemo metodo istega objekta. Tako lahko
iz handlerja C prenesemo klic v objekt C++, kar sicer ne bi bilo mono.
4.4.2. Modul Mod_Ldtp
Predstavlja modul komunikacije LDTP prek protokola CAN LDTP. Vsebuje vse potrebne
metode za sprejemanje in poiljanje 16- in 32-bitnih sporoil ter funkcije, potrebne za
periodino spremljanje.
Ta modul se uporablja tako, da ga izpeljemo iz razreda adapterja CAN. Nato se metode
modula za poiljanje LDTP kliejo iz aplikacije, pri sprejemu sporoila pa modul sam ustvari
Windows message, ki ga moramo v aplikaciji prestrei ter prebrati podatke paketa LDTP.
4.4.2.1.

Opis funkcij modula Mod_Ldtp

void Tmod_ldtp::f_setLDTPServerAddress (int ldtp_id, int node_id )

{
LDTP_serverAdd = ldtp_id | node_id;
}
void Tmod_ldtp::f_setLDTPClientAddress (int ldtp_id, int node_id )
{
LDTP_clientAdd = ldtp_id | node_id;
}

Slika 19: Funkciji f_setLDTPServerAddress in f_setLDTPClientAddress.

Funkciji (Slika 19) se uporabljata za nastavljanje naslova odjemalca (branje ali pisanje v
slovar CAN) in strenika (poiljanje zahtev za branje ali pisanje) LDTP.

43

ORODJE ZA DIAGNOSTIKO
void Tmod_ldtp::f_Write32bitLDTP (int value,int Address, EvarMemory
memoryType)
{
structCanMsgTypeUser msg;
msg.MessageID
msg.RemoteReq
msg.DataLen =
msg.Data[0] =
msg.Data[1] =
msg.Data[2] =
msg.Data[3] =
msg.Data[4] =
msg.Data[5] =
msg.Data[6] =
msg.Data[7] =

= LDTP_serverAdd;
= false;
8;
0xF6 | memoryType;
(unsigned char)Address;
(unsigned char)(Address>>8);
(unsigned char)(Address>>16);
(unsigned char)value;
(unsigned char)(value>>8);
(unsigned char)(value>>16);
(unsigned char)(value>>24);

f_MsgTx(msg);
}

Slika 20: Funkcija f_Write32bitLDTP.

Funkcija po CAN-u polje 32-bitni ukaz za vpis podatka v slovar CAN (Slika 20). Prav tako
imajo funkcije f_Write16bitLDTP, f_Read16bitLDTP in f_Read16bitLDTP enako zgradbo, le
da funkcije za branje podatka iz slovarja CAN za parameter ne sprejmejo parametra value
(zato, ker gre samo za branje iz neke lokacije RAM) ter tudi ne vsebujejo polj (polja
msg.Data[4] msg.Data[7]) za zapis vrednosti. Vse tiri funkcije se med seboj loijo po
vrednosti polja msg.Data[0]. Tam se nahaja skupna vrednost vseh bitov, ki so potrebni za
loevanje branja in pisanja ter 16- in 32-bitnih spremenljivk. Zgornji primer ima vrednost
0xF6 | memoryType zaradi tega, ker so privzeto zgornji tirje biti enaki 0xF, na spodnjih tirih
bitih pa so postavljene zastavice za zapis 32-bitne besede DWORD (2^2) ter za pisanje (2^1),
uporabljamo pa lahko obe vrsti pomnilnika RAM ali NVRAM, tako da je tam lahko vrednost
0 ali 1 (2^1) (glej stran 13). Funkcija vsebuje parametre za zapis vrednosti na poljubni
lokaciji, naslov, na kateri se nahaja, ter ali gre za pomnilnik RAM ali NVRAM.
Prejeti podatek se nato najprej vpie v uporabniko strukturo, ki vsebuje vse informacije
prejetega sporoila.

44

ORODJE ZA DIAGNOSTIKO
void Tmod_ldtp::f_CanRxInterpreter(structCanMsgTypeUser str_MsgRx)
{
//preverjanje ali je sporocilo namenjeno nam (klientu)
if((str_MsgRx.MessageID == LDTP_clientAdd) && (str_MsgRx.DataLen == 8))
{
BYTE identification, tmp;
tmp = str_MsgRx.Data[0];
identification = (tmp>>4) & 0x0F;
uniDWord value;
//preverjanje ali gre za normalno ali za periodicno branje
if(str_MsgRx.Data[0]<73) //<periodicno branje
{
//interpretacija LDTP sporocila za peridoicno spremljanje
structCanMsgTypeUser message;
f_ReceiveVar(message);
periodic_LDTP_msg.values[0] =(int)str_MsgRx.Data[2] +
((int)str_MsgRx.Data[3]*256);
periodic_LDTP_msg.values[1] =(int)str_MsgRx.Data[4] +
((int)str_MsgRx.Data[5]*256);
periodic_LDTP_msg.values[2] =(int)str_MsgRx.Data[6] +
((int)str_MsgRx.Data[7]*256);
TMessage msg;
msg.Msg = WM_LDTP_PERIODIC_READ;
msg.WParam = 0;
msg.LParam = 0;
Owner->Dispatch (&msg);

else if((str_MsgRx.Data[0]>>4)==0x0F) //< normalno branje

{
uniDWord value, address;
BYTE tmp, id, memory_type, rw_flag, length ;
//interpretacija LDTP sporocila
tmp = str_MsgRx.Data[0];
id = (tmp>>4) & 0x0F;
memory_type = (tmp>>3) & 0x01;
rw_flag = (tmp>>2) & 0x01;
length = tmp & 0x03;
address.byte[0] = str_MsgRx.Data[1];
address.byte[1] = str_MsgRx.Data[2];
address.byte[2] = str_MsgRx.Data[3];
value.byte[0]
value.byte[1]
value.byte[2]
value.byte[3]

=
=
=
=

str_MsgRx.Data[4];
str_MsgRx.Data[5];
str_MsgRx.Data[6];
str_MsgRx.Data[7];

//ali gre za

LDTP read sporocilo?

45

ORODJE ZA DIAGNOSTIKO
if(str_MsgRx.Data[0] == 0xF1)
{
// ce gre za LDTP read, sem prihajajo paketi s prebranimi elementi iz
//OD serverja z 16 biti.
// interpretiramo ...
RX_LDTP_msg.ldtp_id = str_MsgRx.MessageID;
RX_LDTP_msg.Value = value.dword;
RX_LDTP_msg.Address = address.byte[2];
RX_LDTP_msg.length = VarWord;
RX_LDTP_msg.read_write = VarRead;
RX_LDTP_msg.memory_type = VarRam;
TMessage msg;
//...ter posljemo Windows message
msg.Msg = WM_LDTP_READ;
msg.WParam = 0;
msg.LParam = 0;
Owner->Dispatch(&msg);
}
if (str_MsgRx.Data[0] == 0xF2)
{
// ce gre za LDTP read, sem prihajajo paketi s prebranimi elementi
// iz OD serverja z 32 biti.
//interpretiramo...
RX_LDTP_msg.ldtp_id = str_MsgRx.MessageID;
RX_LDTP_msg.Value = value.dword;
RX_LDTP_msg.Address = address.dword;
RX_LDTP_msg.length = VarDword;
RX_LDTP_msg.read_write = VarRead;
RX_LDTP_msg.memory_type = VarRam;
TMessage msg;
//...ter posljemo Windows message
msg.Msg = WM_LDTP_READ;
msg.WParam = 0;
msg.LParam = 0;
Owner->Dispatch(&msg);
}
if(str_MsgRx.Data[0] == 0xF5)
{
//sem prihajajo 16 bitni potrditveni paketi(write) za vpisovanje v OD
serverja
}
if (str_MsgRx.Data[0]== 0xF6)
{
//sem prihajajo 32 bitni potrditveni paketi(write) za vpisovanje v OD
serverja
}
}

Slika 21: Funkcija f_CanRxInterpreter.

46

ORODJE ZA DIAGNOSTIKO

To je virtualna funkcija, ki se klie iz starevskega razreda TMod_Can (Slika 21). Sporoilo

najprej filtrira, preveri, ali gre za sporoilo LDTP in ali gre za normalno branje in pisanje ali
periodino spremljanje, ga interpretira in rezultat vpie v uporabniko strukturo ter nato polje
windows message glede na to, ali gre za periodino branje ali za normalno branje in
pisanje.
4.4.2.2.

Opis funkcij modula Mod_Ldtp za periodino spremljanje.

void Tmod_ldtp::f_AddVariable(int address, int type)

{
if ((type == 2) && ((num_addresses + 1) < MAX_ADDRESSES) ) {
var_buffer[num_addresses] = address + 1;
var_types[num_addresses] = 1;
var_diary[num_addresses] = num_vars;
num_addresses++;
var_buffer[num_addresses] = address;
var_types[num_addresses] = 2;
var_diary[num_addresses] = num_vars;
num_vars++;
num_addresses++;
}
else if ((type == 1) && (num_addresses < MAX_ADDRESSES) ) {
var_buffer[num_addresses] = address;
var_types[num_addresses] = 0;
var_diary[num_addresses] = num_vars;
num_vars++;
num_addresses++;
}

Slika 22: Funkcija f_AddVariable

Funkcija skrbi za pravilen vrstni red vpisa spremenljivk glede na to, ali gre za 16-bitno ali 32bitno spremenljivko (Slika 22). Funkcija sprejme dva parametra:
-

Naslov spremenljivke, ki jo hoemo spremljati (e gre za 32-bitno spremenljivko, se

najprej vpie naslov nijih 16 bitov).

Tip spremenljivke (ali gre za 16-bitno ali 32-bitno spremenljivko).

47

ORODJE ZA DIAGNOSTIKO
void Tmod_ldtp::f_ReceiveVar(structCanMsgTypeUser message)
{
int values[3];
int buffer_index;
int Nindex;
values[0] =(int)message.Data[2] + ((int)message.Data[3]*256);
values[1] =(int)message.Data[4] + ((int)message.Data[5]*256);
values[2] =(int)message.Data[6] + ((int)message.Data[7]*256);
Nindex = message.Data[0];
for (int i = 0; i < 3; i++) {
buffer_index = (Nindex * 3) + i;
if(buffer_index >= num_addresses)
{
break;
}
if (var_types[buffer_index]==0)
{
var_read_vars[var_diary[buffer_index]] = values[i];
var_iscomplete[var_diary[buffer_index]] = 1; //! ce je enaka
ena je spremenljivka prebrana do konca
}
else if(var_types[buffer_index]==1)
{
var_read_vars[var_diary[buffer_index]] =values[i];
var_iscomplete[var_diary[buffer_index]] = 0; //! ce je enaka
nic spremenljivka ni prebrana do konca (sledi se naslednjih 16 bitov
spremenljivke)
}
else if (var_types[buffer_index]==2)
{
var_read_vars[var_diary[buffer_index]] =
(var_read_vars[var_diary[buffer_index]] * 65536) | values[i];
var_iscomplete[var_diary[buffer_index]] =1;
}
}
}

Slika 23: Funkcija f_ReceiveVar.

Funkcija je povezava na relaciji CPU PC (periodini paket, ki se polje s CPU na PC)
(Slika 23). Paket vsebuje tri indekse: N, N + 1 in N + 2. Ker je najveje tevilo spremljanih
spremenljivk enako 222 in vsak paket vsebuje tri od njih (kot je znano, je v enem paketu
prostora za tri 16-bitne spremenljivke), je najvije mono tevilo paketa 73. Ta in prejnja
funkcija morata skrbeti tudi za to, da spremenljivko pri lomljenju (npr. da se 32-bitna
spremenljivka pojavi v dveh paketih spodnjih 16 bitov v prvem paketu, zgornjih 16 bitov v
drugem paketu) zdruita v celoto.
48

ORODJE ZA DIAGNOSTIKO

4.4.3. Modul Mod_TIdwarf

Modul Mod_TIdwarf predstavlja modul branja datotek ti dwarf xml (Slika 25), ki so
generirane z orodjem ofd2000.exe.
Glavna, sredina toka modula so trije vektorji oziroma strukture (vloga vektorja v
programskem jeziku C++ je podobna vlogi tabele, le da se vektorju dolina dinamino
spreminja glede na tevilo zapolnjenih mest v vektorju) t_DIE, t_base_type_DIE in t_symbol:
-

t_DIE je struktura, ki predstavlja en objekt DIE (Debug definition entry), ki je

definiran po standardu DWARF in je prebran iz sekcije DWARF datoteke xml. Vendar
to je interna struktura to pomeni, da je treba objekte DIE e interpretirati v seznam

simbolov.
t_base_type _DIE je struktura, ki predstavlja objekt DIE osnovnega podatkovnega
tipa. Med osnovne podatkovne tipe programskega jezika spadajo integer, character,

string
t_symbol je struktura, ki predstavlja en dokonno interpretiran simbol. Je uporabnika
struktura, ki sestavlja uporabniku razreda dostopno tabelo simbolov (uporabljeno v
uporabnikemu vmesniku za branje pravilnih vrednosti iz naslovov).
4.4.3.1

Delovanje modula

Iz datoteke xml naloimo vse simbole.

Z zunanjim parserjem (uporabljen je parser z imenom RapidXml) preberemo
datoteko xml, jo naloimo v pomnilnik in razkodiramo (orodje je sposobno pravilno

interpretirati oznake datoteke xml ter s tem pravilno razporediti elemente).

Poiemo prvo vozlie v datoteki ter po tem vozliu poiemo informacijo o tipu

procesorja. Primer drevesne strukture in vozli je na Sliki 24.

Ko dobimo informacijo o tipu procesorja, informacijo spravimo v target_id, da v

nadaljnjem postopku vemo, za kateri procesor gre.

Preverimo, ali datoteka xml vsebuje zapis podatkov DWARF, ter se sprehodimo
skozi vse sekcije, dokler ne poiemo debug_info, ki vsebuje simbole za obdelavo

objektov DIE.
Z zanko for se spet sprehodimo, tokrat po vseh objektih DIE, ki so podrejeni
parent_DIE, ter preberemo atribut id, ki nam podaja vrednost naslova.

49

ORODJE ZA DIAGNOSTIKO

Pri vsakem objektu DIE se sprehodimo skozi sekcije z atributi in shranimo v t_DIE
tiste vrednosti, ki so za nas pomembne (razlini t. i. tagi nosijo razline informacije):
DW_TAG_VARIABLE zapisi spremenljivke
DW_TAG_BASE_TYPE zapis osnovnega podatkovnega tipa

(najniji nivo)
DW_TAG_STRUCTURE_TYPE zapis tipa strukture
DW_TAG_MEMBER zapis podrejenega elementa strukture
DW_TAG_DEF zapis typedef podatkovnega tipa
DW_TAG_UNION_TYPE zapis tipa unije
DW_TAG_ARRAY_TYPE zapis tipa tabele
DW_TAG_SUBRANGE_TYPE zapis dimenzij polja
Naslovi spremenljivk so razdeljeni na ve nivojev. e program vidi, da element ni
najnijega, osnovnega tipa, gre o spremenljivki poizvedovat za nivo nie. e
spremenljivka nima nijega nivoja, jo vpie. Podrejene elemente rekurzivno obdelamo
z enako funkcijo (rekurzivnost funkcija se klie znotraj sebe). Druga metoda preie
serializirane objekte DIE, da dopolni e druge informacije posameznega simbola. Ko

pride do konca, popolno informacijo vpie v uporabniko strukturo sym_table.

Dobljene objekte pomona metoda DIE razporedi po abecednem redu.

Slika 24: Primer drevesne strukture in vozli xml.

50

ORODJE ZA DIAGNOSTIKO

Slika 25: Primer dela datoteke xml z zapisom dwarf. Oznake v oglatih oklepajih lahko zunanji
parser pravilno interpretira ter nam s tem privaruje veliko asa pri branju simbolov iz
datoteke.

4.4.4. Uporabniki vmesnik

Uporabniki vmesnik (Slika 26) slui kot najblija interakcija s lovekom. Vsebuje vse zgoraj
opisane funkcije in logiko delovanja celotnega sistema. Poleg tega omogoa e shranjevanje
podatkov v tekstovno datoteko za kasnejo obdelavo. Vmesnik je nastajal s pomojo objektov,
ki so na voljo v programu, ter z osnovnim in kompleksnejim programiranjem C++.

51

ORODJE ZA DIAGNOSTIKO

Slika 26: Uporabniki vmesnik.

1. Polje ukaz za aktivacijo vmesnika Ifak IsCan Usb.

2. Polje ukaz mikrokontrolerju, ki omogoi samo delovanje mikrokontrolerja (pred tem
se mikrokontroler odziva samo vsako sekundo s posebnim bitom, ki nas obvesti, da je
mikrokontroler prikljuen in dela).
3. Polje ukaz mikrokontrolerju za zaetek ali zaustavitev monosti periodinega
spremljanja.
4. Odpiranje datoteke xml ali out ter izpis imen in naslovov v tabelo.
5. Tabela z imeni spremenljivk in pripadajoimi naslovi:
- S pritiskom na celico tabele v stolpcu value preberemo vrednost
spremenljivke z mikrokontrolerja.

52

ORODJE ZA DIAGNOSTIKO

S pritiskom na celico tabele v stolpcu write value vpiemo vrednost, ki jo

elimo na mesto izbranega naslova v mikrokontrolerju.

S pritiskom na celico v stolpcu periodic prestavimo spremenljivko v desno

tabelo ter spremenljivko zanemo periodino spremljati.

6. Vrednost, ki jo vpiemo v eno od polj write value v tabeli.
7. Kotiek, namenjen shranjevanju v datoteko. Vsebuje gumb za izbiro datoteke (po
izbiri datoteke se meritve shranjujejo v enako datoteko tudi z zaetkom novega
shranjevanja od prejnjih meritev dalje), komentar ter gumb za shranjevanje. Primer:

Slika 27: Meritve periodino spremljanih spremenljivk v tekstovni datoteki.

53

ORODJE ZA DIAGNOSTIKO

4.4.6. Diagram programa UML

UML (Unified Modelling Language) je raunalniki standard, namenjen modeliranju
raunalnikih sistemov in procesov. Vsebuje zbirko grafinih zapisov, s katerimi lahko
ustvarimo modele, ki izvirajo iz objektno usmerjenih programov (npr. C++ Builder).
UML vsebuje tehnike podatkovnega modeliranja, podjetnega modeliranja, objektnega
modeliranja in modeliranja po komponentah.
UML sestavljajo diagrami, med katerimi so najpomembneji trije:
-

Odloitveni diagram
Prikazuje relacije med t. i. igralci in uporablja razline poti odloitve znotraj

sistema.
Sekvenni diagram
Predstavlja stanja sistema in prehode med njimi. Obiajno se uporablja v

povezavi z drugimi programskimi jeziki.

Diagram razreda
Je statien diagram, ki opisuje strukturo sistema s predstavitvijo razredov,
atributov, metod in operacij ter z relacijami med njimi. Uporablja se za bolji
pregled in raziskovanje zgradbe celotnega sistema ter za analizo zahtev,
potrebnih za nadaljnji razvoj modela. Na sliki 28 so vidni razredi, definicije,
enumeratorji in strukture, ki so zajete v programu, in relacije med njimi. Glavni
del predstavljajo trije zgoraj opisani moduli in uporabnika forma, na kateri so
zdrueni vsi trije moduli.

54

ORODJE ZA DIAGNOSTIKO

Slika 28: UML diagram celotnega programa.

55

SKLEP

6. SKLEP
Cilj diplomske naloge je bila izdelava orodja za diagnostiko sistemov na vodilu CAN v
realnem asu, ki bi nudil razvijalcu vpogled v notranjost delovanja mikrokrmilnika. Ena od
pomembnejih zahtev je bila uspena implementacija novega protokola LDTP, ki s svojo
prirejeno logiko dopolnjuje protokol CAN na vijem nivoju in omogoa preprosto zamenjavo
vmesnika povezave CAN. Velika prednost tega protokola je predvsem v dobrem in pravilnem
razporejanju paketkov, ki se izmenjujejo na poti od osebnega raunalnika do
mikrokontrolerja. Ta del velja posebej za periodino branje spremenljivk.
Programsko orodje se bo uporabljalo pri merjenju karakteristik elektrinih vozil v realnem
asu. Shranjevanje v datoteko omogoa poznejo obdelavo podatkov in s tem uinkovito
reevanje problemov, ki se pojavijo med delovanjem nekega sistema.
Uporabniki vmesnik in moduli so zasnovani tako, da so neodvisni drug od drugega, kar
omogoa spreminjanje uporabnikega vmesnika kot tudi dodajanje novih modulov k orodju.
Skupaj s prednostmi protokola CAN (preprosta povezljivost, robustnost, delovanje v realnem
asu ) tvori program uinkovito orodje za diagnostiko, ki je preprosto in prijazno do
uporabnika.
Razvoj programa lahko v prihodnosti poteka v smeri interakcije s konnim uporabnikom.
Zaslon za izpis vejih spremenljivk, ki bi omogoale konnemu uporabniku lepi pregled, in
implementacija grafa za izris spremenljivk so le nekatere izmed naprednejih funkcionalnosti
programa.

56

LITERATURA IN VIRI

57

LITERATURA IN VIRI

7. LITERATURA IN VIRI
[1.] Spletna stran Can Cia, protokol CAN (15.3.2013), http://can-cia.org
[2.]
Spletna
stran
Can
Cia,
protokol
CAN
osnovno

(15.3.2013)

www.can-cia/index.php?id?can
[3.] Spletna stran Wikipedia, Protokol (28.6.2013) http://sl.wikipedia.org/wiki/Protokol_(ra
%C4%8Dunalni%C5%A1tvo)

[4.] Douglas E. Comer, Internetworking with TCP/IP Vol.1, 2000

[5.] Stanislav Kovai, Komunikacije v avtomatiki, prosojnice pri predmetu
komunikacije v avtomatiki 2011/2012
[6.] Spletna stran Wikipedia Can-bus (15.3.2013) http://en.wikipedia.org/wiki/CAN_bus
[7.]
Spletna
stran
gradiva.txt,
objektno
programiranje
(1.7.2013)
http://gradiva.txt.si/index.php/objektno-programiranje-2/
[8.]
Spletna
stran
Wikipedia,
Object-oriented
programming

(1.7.2013)

https://en.wikipedia.org/wiki/Object-oriented_programming
[9.] Spletna stran Tehnoloke univerze Malezije, Object oriented programming (15.8.2013)
http://ocw.utm.my/file.php/42/01PPvsOOP-edit15Feb13.pdf
[10.] Spletna stran saylor, Advantages and Disadvantages
Programming

(15.8.2013),

of

Object-Oriented

http://www.saylor.org/site/wp-

content/uploads/2013/02/CS101-2.1.2-AdvantagesDisadvantagesOfOOP-FINAL.pdf
[11.] Spletna stran Direct industry, krmilnik letrika aek 1350 (10.3.2013)
http://pdf.directindustry.com/pdf/letrika/ac-controllers/26759-53849.html
[12.] Spletna stan Ifak systems, Ifak IsCan usb (15.3.2013) http://www.ifaksystem.com/en/communication-automation/mobile-parametration/products/iscan-usb/
[13.] Bob Swart, Mark Cashman, Paul Gustavson, Jarrod Hollingworth, Borland C++
builder 6 developers guide, Sams publishing, 2003
[14.] Spletna stran cplusplus, c++ vodi (6.3.2013) http://www.cplusplus.com/doc/tutorial/
[15.] Spletna stran tutorials point, c++ vodi (6.3.2013)
http://www.tutorialspoint.com/cplusplus
[16.] Spletna stran Sourceforge, RapidXML (8.4.2013) http://rapidxml.sourceforge.net/
[17.] Spletna stran Wikipedia, UML (15.8.2013)
http://en.wikipedia.org/wiki/Unified_Modeling_Language
[18.] Spletna stran Agiledata, Introduction UML (15.8.2103)
http://www.agiledata.org/essays/objectOrientation101.html

58

IZJAVA
Izjavljam, da sem diplomsko delo izdelal samostojno pod vodstvom mentorja prof. dr.
Alea Belia, univ. dipl. in.el. Izkazano pomo drugih sodelavcev sem v celoti navedel v
zahvali.
Matija Cej