Univerza v Ljubljani
Fakulteta za elektrotehniko
MATEJ LOVRI ´ C
KRMILNA ENOTA ZA ELEKTRI ˇ CNO VOZILO
Magistrsko delo
Magistrski ˇstudijski program druge stopnje Elektrotehnika
Mentor: prof. dr. Tadej Tuma
Ljubljana, 2022
Zahvala
Zahvaljujem se mentorju prof. dr. Tadeju Tumi za vso pomoˇc pri izdelavi magi- strskega dela.
Zahvaljujem se vsem ˇclanom ekipe Superior Engineering, ki ste mi zaupali in pomagali izpeljati ta projekt, ter vsem voznikom, ki ste z vsako voˇznjo pogumno sprejemali vsa morebitna tveganja. Delati z vami je bil izjemen privilegij in neprecenljiva izkuˇsnja.
Zahvaljujem se vsem sponzorjem ekipe Superior Engineering, ki ste s finanˇcno in tehniˇcno podporo omogoˇcili obstoj tega projekta.
Zahvala tudi vsem mojim bliˇznjim prijateljem ter sestri za vaˇso dobro druˇzbo in podporo.
Nazadnje pa se zahvaljujem svojima starˇsema. Vajin trud, podpora in poˇzrtvovalnost so bili in bodo glavni navdih za vse moje dosedanje in bodoˇce doseˇzke.
iii
iv
Povzetek
Formula Student (FS) je mednarodno inˇzenirsko tekmovanje, na katerem se ekipe ˇstudentov tehniˇcnih univerz med seboj pomerijo v naˇcrtovanju, izdelavi ter dirka- nju formula dirkalnika. Tekmovanja potekajo vsako leto na dirkaliˇsˇcih po Evropi in ostalih kontinentih, organizirajo pa jih glavni akterji avtomobilske industrije, ki tekmovanja izkoristijo za promocijo, predvsem pa za iskanje bodoˇcega kadra, saj si ˇstudenti med izdelavo dirkalnika naberejo izkuˇsnje, ki jim dobro sluˇzijo pri nadaljnjem delu v industriji.
V zaˇcetnih letih tekmovanja so vse dirkalnike poganjali motorji z notranjim iz- gorevanjem. Z leti pa je razvoj na podroˇcju baterij ter motorjev z visoko specifiˇcno moˇcjo prepriˇcal posamezne ekipe na prehod na elektriˇcni pogon. S premikom in- dustrije v smeri elektriˇcnih vozil se vsako leto vse veˇc ekip odloˇci za izdelavo elektriˇcnih dirkalnikov, ki ˇze nekaj let presegajo zmogljivosti klasiˇcnega pogona.
Ena izmed sodelujoˇcih ekip je bila tudi ekipa Univerze v Ljubljani – Superior Engineering, ki je v letu 2018 tekmovala s svojim prvim elektriˇcnim dirkalnikom.
Pri vseh sodobnih vozilih, bodisi bencinskih ali pa elektriˇcnih, je potrebna uporaba krmilnega raˇcunalnika, ki nadzoruje pogon vozila. Pri vozilih z notranjim izgorevanjem se je za ta krmilni raˇcunalnik v industriji uveljavil angleˇski izraz engine control unit ali ECU. Enakovredno temu pa se pri elektriˇcnih vozilih v zadnjih letih uporablja izraz vehicle control unit ali VCU. V magistrskem delu je predstavljena izdelava krmilnega raˇcunalnika ali VCU-ja za nadzor elektriˇcnega dirkalnika, ki je tekmoval na FS tekmovanjih v letu 2021.
Problematika izdelave krmilnika je razdeljena na veˇc poglavij. V uvodu zaˇcnemo z doloˇcanjem tehniˇcnih zahtev, saj za elektriˇcne dirkalnike niso ˇse tako uveljavljene sploˇsne zahteve ter principi delovanja, kot je to pri vozilih s klasiˇcnim v
vi Povzetek
pogonom. Temu sledi naˇcrtovanje in izdelava vezja, ki mora upoˇstevati okoliˇsˇcine znotraj elektriˇcnega dirkalnika. Nato se seznanimo s programsko opremo, ki mora najprej zagotoviti varno delovanje vozila, nato pa mora izkoristiti ˇse vse prednosti elektriˇcnega pogona za energijsko uˇcinkovitejˇse delovanje in hitrejˇse ˇcase na stezi.
Na koncu predstavimo ˇse konˇcne rezultate testiranj in tekmovanj. Dirkalnik je z dokonˇcno izdelanim VCU-jem tekmoval na ˇstirih dirkah po Evropi, kjer se je v veˇcih panogah uspel uvrstiti na stopniˇcke.
Kljuˇcne besede: Formula Student, nadzorna enota vozila, elektriˇcno vozilo, vgrajeni sistemi
Abstract
Formula Student (FS) is an international engineering design competition where teams of university students compete against each other in design, construction and racing of formula style race cars. The competitions are held every year on racetracks across Europe and other continents, and are organized by major com- panies from the automotive industry. The companies organize these competitions for promotion purposes, but also for finding and recruiting new engineering stu- dents who gained valuable experience during their development of the vehicle.
In the beginning years of the competition all competing race cars were powered by internal combustion engines. As yeas passed and progress has been made in higher energy density batteries and high specific power electrical motors, some teams decided to switch to an electric powertrain. As the automotive industry started shifting into production of electric vehicles more and more teams started switching to electrical propulsion, which was already starting to outclass cars with internal combustion engines. One of these teams was the team of students from University of Ljubljana – Superior Engineering, which successfully made the switch to electric in the year 2018 and has been competing with electric cars ever since.
All modern vehicles, either electric or combustion, use computers to control the vehicle and its powertrain. In the world of combustion vehicles a widely adopted term for this computer is called the engine control unit or ECU. But in the world of electric vehicles, a more common term for this device is called the vehicle control unit or VCU. This master’s thesis presents the design and con- struction of one such VCU that has been used on an FS race car which competed in the year 2021. The work is separated into multiple stages of its design. In the introduction we establish a set of requirements that were determined before the vii
viii Abstract
construction phase. After that we present the design of the electrical board itself.
Followed by that is the presentation of the software package that was developed for the VCU, which has to ensure the safe operation of the vehicle as well as make the most use of the electric powertrain for the purposes of energy efficiency and better lap times on the track.
At the end we present the results of the testing period and the competitions.
The 2021 car equipped with the VCU has entered in four competitions across Europe, where it achieved podiums in multiple categories.
Key words:Formula Student, vehicle control unit, electrical control unit, electric vehicle, embedded systems
Vsebina
1 Uvod 1
1.1 Avtorjev prispevek in porazdelitev opravljenega dela . . . 2
2 Opis vezja 5 2.1 Specifikacije . . . 5
2.2 Blokovni diagram . . . 5
2.3 Mikrokrmilnik . . . 6
2.4 Distribucija napajanja . . . 7
2.4.1 Merjenje toka . . . 9
2.4.2 Izhodne stopnje . . . 11
2.5 VCU napajanje . . . 13
2.6 Analogni del . . . 15
2.7 Komunikacija . . . 17
2.7.1 CAN . . . 17
2.7.2 RS-232 . . . 18
2.8 Zajemanje podatkov . . . 19 ix
x Vsebina
2.8.1 SD kartica . . . 21
2.8.2 USB . . . 22
2.8.3 Brezˇziˇcna telemetrija . . . 22
2.8.4 Rezervno napajanje . . . 23
2.9 Varnostni sistemi . . . 24
2.9.1 Izklopno vezje . . . 24
2.9.2 Indikator aktivnosti pogonskega sistema . . . 25
3 Programska oprema 27 3.1 SEOS . . . 28
3.1.1 CAN komunikacija . . . 29
3.1.1.1 CAN konfiguracija . . . 29
3.1.1.2 Potek CAN komunikacije . . . 30
3.1.1.3 CAN dogodki . . . 31
3.1.2 Monitor . . . 33
3.1.2.1 Parametri . . . 34
3.1.2.2 Podatki . . . 36
3.2 Stroj stanj . . . 39
3.3 Predpolnjenje pogonskega sistema . . . 40
3.4 Nadzor pogona . . . 42
3.4.0.1 Nadzor zdrsa . . . 45
Vsebina xi
4 Razvoj, testiranje in rezultati 49
5 Zakljuˇcek 53
Literatura 55
xii Vsebina
Seznam slik
2.1 Blokovni diagram vseh podsistemov na VCU-ju . . . 6
2.2 Postavitev kristalnega oscilatorja ter oblika otoˇcka na drugem sloju 7 2.3 Shema vezave tokovnih meritev . . . 9
2.4 Merjenje padca napetosti na merilnem uporu . . . 10
2.5 Vezava tokovne meritve . . . 11
2.6 Upori za tokovne meritve med varovalkami . . . 12
2.7 Stikalo za ventilatorje . . . 13
2.8 Pametno NMOS stikalo . . . 13
2.9 Vhodna stopnja napajalnika . . . 14
2.10 Postavitev in povezava napajalnika . . . 15
2.11 Vmesna in izhodna stopnja napajalnika . . . 16
2.12 Shema vhodne analogne stopnje s sledilniki . . . 17
2.13 Referenˇcna napetost in napajanje A/D pretvornika . . . 17
2.14 Vhodna analogna stopnja s sledilniki . . . 18
2.15 CAN vmesnik s terminacijo . . . 19 xiii
xiv Seznam slik
2.16 Shema vezave SD kartice ter EMI filtra (levo) ter implementacija
na vezju (desno) . . . 21
2.17 Shema USB vodila . . . 23
3.1 Arhitektura projekta . . . 28
3.2 Konfiguracija krmilnika znotraj okolja STM32CubeIDE . . . 29
3.3 Diagram CAN omreˇzij na vozilu . . . 30
3.4 Pot CAN sporoˇcila od sprejema do obdelave . . . 31
3.5 Princip delovanja . . . 35
3.6 Pregled delovanja zajemanja podatkov . . . 37
3.7 Stroj stanj vozila . . . 39
3.8 Predpolnenje pogonskega sistema . . . 41
3.9 Predpolnenje pogonskega sistema . . . 41
3.10 Nadzor pogona . . . 42
3.11 Funkcija izkoristka v odvisnosti od navora ter hitrosti za Emrax 188 motor . . . 45
3.12 Karakteristika gume . . . 47
3.13 Poenostavljen diagram regulatorja zdrsa . . . 47
3.14 Primerjava hitrosti vseh ˇstirih koles pri ugasnjenem nadzoru zdrsa (zgoraj) in aktiviranem nadzoru zdrsa (spodaj) . . . 48
4.1 Vezje prvega VCU prototipa . . . 49
4.2 Izsek podatkovnega zajema z vzdrˇzljivostne dirke na tekmovanju FS Alpe Adria, prikazan v programu Monitor . . . 51
Seznam slik xv
4.3 Dirkalnik Svarog med dirko na tekmovanju FS Alpe Adria . . . . 51 4.4 Zadnja revizija VCU-ja ter postavitev v vozilu . . . 52
xvi Seznam slik
Seznam tabel
2.1 Maksimalne tokovne porabe vseh naprav na formuli . . . 8
xvii
xviii Seznam tabel
Seznam uporabljenih simbolov
V priˇcujoˇcem zakljuˇcnem delu so uporabljene naslednje kratice:
Kratica Pomen
VCU Vehicle Control Unit
FS Formula Student
AMS Accumulator management system IMD Insulation Monitoring device BSPD Brake system plausibility device TSAL Tractive system active light
SOC State of charge
TS Tractive system
CAN Controller area network SPI Serial Peripheral Interface EMI Electromagnetic interference TVS Transient voltage supression
xix
xx Seznam uporabljenih simbolov
1 Uvod
Inˇzenirsko druˇstvo Superior Engineeing je v letu 2016 priˇcelo z dirkanjem na Formula Student tekmovanjih. Od takrat naprej je ekipa vsako sezono izdelala popolnoma nov dirkalnik. Prva dva dirkalnika sta bila bencinska, ki se zaradi preprostosti in zanesljivosti nista zanaˇsala na veliko koliˇcino elektronike. Potre- bovala sta le raˇcunalnik za nadzor motorja. Za nadzor motorja so na trgu ˇze vrsto let uveljavljeni nadzorni raˇcunalniki oz. ECU-ji, kot so npr. Haltech Elite ECU-ji, ki imajo naloˇzeno vso potrebno programsko opremo in so idealna reˇsitev za dirkalne projekte, ki morajo biti konˇcani v kratkem ˇcasu. Z letom 2018 pa se je zgodil preskok na elektriˇcni pogon. Naenkrat se je minimalno ˇstevilo potrebne elektronike bistveno poveˇcalo. Potrebni elektronski sistemi, ki so na voljo na trgu, so manj uveljavljeni ter manj medsebojno zdruˇzljivi, kar ˇse posebej velja za po- droˇcje elektriˇcnih dirkalnikov. Dodatna oteˇzitev je priˇsla z odloˇcitvijo, da bo avto za pogon uporabljal dva neodvisna motorja namesto enega, kar je pomenilo, da mora imeti ekipa veˇc svobode pri spremembah krmilnih programov. Na trgu sicer ˇ
ze obstajajo generiˇcni ECU-ji, ki ponujajo ta zadosten nivo konfiguracije. Med vodilnimi ponudniki raˇcunalnikov na tem podroˇcju sta proizvajalca dSPACE in Speedgoat. Oprema teh proizvajalcev je zelo popularna v profesionalni industriji in je zato tudi temu primerno cenjena, za upravljanje pa je potrebno posebno usposabljanje. Potreben je bil direktnejˇsi pristop do reˇsevanja tega problema.
Potreben je bil zmogljiv mikrokrmilnik, ki bi ga ekipa lahko sama programirala.
Zaradi neizkuˇsenosti na podroˇcju konstruiranja elektronskih naprav je razvoj la- stnega krmilnika prvo sezono odpadel. Druˇstvo je takrat zaˇcelo sodelovati s slo- venskim podjetjem Elaphe, ki je imelo ˇze izdelano krmilno enoto, primerno za elektriˇcna vozila, programerski ekipi pa je bila omogoˇcena prosta modifikacija kode. Elaphejevi krmilni enoti se je reklo PCU ali propulsion control unit.
1
2 Uvod
PCU je opravljal funkcijo nadzora moˇci ter poˇsiljanja navornih komand na oba krmilnika motorjev ali inverterja. Samo po sebi bi bilo to dovolj, vendar pa morajo biti Formula Student dirkalniki po pravilniku opremljeni ˇse z dodatnimi varnostnimi sistemi. Ti sistemi so manj kompleksni in v celoti analogni, zato jih je ekipa razvila sama. Na prvi elektriˇcnem dirkalniku so bili ti sistemi narejeni na prototipnih ploˇsˇcah in so bili zelo nezanesljivi. Naslednje leto jih je ekipa izdelala na namenski tiskanini, ki se jo je generiˇcno klicalo ECU. ECU je bil opremljen s poˇcasnejˇsim mikrokrmilnikom in je, poleg omenjenih varnostnih funkcij, izvajal ˇse nadzor hlajenja na vozilu ter sluˇzil tudi kot skupno mesto za varovalke vseh sistemov na vozilu.
V tej fazi smo imeli na drugem elektriˇcnem dirkalniku PCU, ki je opravljal nadzor nad motorji in stanjem vozila, ter ECU, ki je izvajal nadzor nad ostalimi sistemi. Tako organiziran sistem je sicer deloval zanesljivo, vendar smo hitro do- segli omejitve PCU-ja z vidika podpore funkcionalnosti, ki bi jih potrebovali za metodiˇcnejˇsi pristop razvoja dirkalnika na stezi. Zahteve za veˇcje hitrosti zaje- manja podatkov in veˇcje velikosti datotek ter potreba po brezˇziˇcni telemetriji z direktnim dostopom do mikrokrmilnika so nas pripeljale do odloˇcitve, da razvi- jemo nov nadzorni raˇcunalnik, ki bo zdruˇzil funkcionalnosti PCU-ja ter ECU-ja.
Ta nadzorni raˇcunalnik smo odslej imenovali VCU ali vehicle control unit, njegova izdelava in delovanje pa sta tematiki tega zakljuˇcnega dela.
1.1 Avtorjev prispevek in porazdelitev opravljenega dela
Visoki cilji in razseˇznost projekta pomenijo, da je na poti do trenutne imple- mentacije VCU-ja sodelovalo veˇc ljudi, ki so na svoj naˇcin prispevali k uspehu projekta. To je znotraj ekipe edini priˇcakovan pristop do dela, kjer se bo vedno uporabilo vse prednosti, ki jih ima ekipa na voljo. Kot glavni programer predho- dnega PCU-ja sem po sezoni 2019 znotraj ekipe dal pobudo, da se izdela VCU ter prevzel odgovornost za pravoˇcasno izpeljavo projekta. Na podlagi izkuˇsenj iz prejˇsnjih let sem skupaj s preostalimi ˇclani elektriˇcnega slopa postavil visoko ni- vojske zahteve projekta (poglavje 2.1). Pri doloˇcanju podrobnejˇsih funkcionalnih zahtev projekta mi je pomagal ekipni ˇclan Tadej Peˇcar. Na podlagi teh zahtev sva lahko izbrala primeren mikrokrmilnik (poglavje 2.3), ki bi jih izpolnil. Nadaljnje
1.1 Avtorjev prispevek in porazdelitev opravljenega dela 3
faze izbire preostalih komponent in naˇcrtovanja vezja sem opravljal sam. Sem pa iz predhodnega ECU-ja (z manjˇsimi popravki) prenesel vse ˇze dobro delujoˇce sisteme, za katere je bil takrat odgovoren Matevˇz Zupin (poglavja 2.4, 2.8.3 in 2.9). Na enem delu izklopnega vezja (poglavje 2.9.1) je tudi modifikacija, ki jo je naˇcrtoval Domen Kriˇzmanc. Fazo konstruiranja tiskanine sem v veˇcini opravil sam, v manjˇso pomoˇc sta mi bila Aljaˇz Kontestabile in Domen Kriˇzmanc, ki sta v zakljuˇcnih dneh pred rokom oddaje v proizvodnjo pomagala pri hitrejˇsem risanju vezja. V fazi programiranja sem imel zopet pomoˇc s strani Tadeja Peˇcarja, s ka- terim sva skupaj delala na tematikah v poglavjih 3.1, 3.1.1 in 3.1.2. Tadej Peˇcar je razvil tudi aplikacijo za osebni raˇcunalnik, s katero spreminjamo parametre na VCU-ju ali pa dostopamo do zajetih podatkov. Podroben opis delovanja sistema za telemetrijo in njenih protokolov je predstavljen v Peˇcarjevem diplomskem delu, ki ob ˇcasu pisanja tega dokumenta ˇse ni objavljen [1]. Znotraj poglavja 3.4 ome- njam algoritem za oceno stanja baterije, ki je produkt magistrske naloge, ki jo je napisal Kriˇstof Aliˇc [2]. Na koncu naj omenim ˇse, da se VCU uporablja za izvajanje algoritma za vektoriranje navora, na katerem je delal Luka Brglez v sklopu svojega magistrskega dela [3].
4 Uvod
2 Opis vezja
2.1 Specifikacije
32-bitni Arm® Cortex®-M7 procesor s frekvenco 480 MHz
distribucija 12 V napajanja za do 27 naprav in meritvami toka
nadzor vklopa ventilatorjev ter ˇcrpalk
6 analognih vhodov s 16-bitno resolucijo in merilnim obmoˇcjem do 5 V
4 digitalni vhodi z moˇznostjo branja pulzno-ˇsirinsko moduliranih signalov
veˇcnapetostni napajalni ˇcip z nadzorom posameznih izhodov ter javljanjem napak
komunikacija:
– 2x CAN FD do 8 Mbit/s – 2x UART do 2 Mbit/s
– USB Full speed do 12 Mbit/s
– LoRa oddajnik/sprejemnik za brezˇziˇcno telemetrijo
varnostni sistemi, skladni s Formula Student pravilnikom
2.2 Blokovni diagram
Blokovni diagram vseh sistemov ter njihovih povezav je prikazan na sliki 2.1 5
6 Opis vezja
MCU
2
CAN USB
LoRa
6
Analog input TSAL logic
Shutdown circuit 27
Power distribution
Connector 2
SD card
2
UART
Connector 1
VMCU
VCOM
VAn
Power supply
Slika 2.1: Blokovni diagram vseh podsistemov na VCU-ju
2.3 Mikrokrmilnik
VCU uporablja STM32H743ZI [4] mikrokrmilnik proizvajalca STMicroelectro- nics (krajˇse STM). Krmilnik je na voljo v LQFP ali BGA paketih. Za projekt je bil primernejˇsi LQFP-144 paket, saj ima na voljo dovolj sponk, da pokrije vse potrebne funkcionalnosti iz specifikacij (poglavje 2.1), hkrati pa ga je laˇzje servi- sirati, saj ima vse sponke dostopne. Krmilnik ima jedro iz druˇzine ARM Cortex-7 procesorjev, ki obratuje z maksimalno frekvenco 480 MHz. Izbira procesorja je bila narejena na podlagi odloˇcitve, da bo uporabljen najhitrejˇsi eno-jedrni STM- ov procesor, ki je trenutno na trgu. Eno-jedrni zato, ker se je na podlagi izkuˇsenj iz prejˇsnjih sezon doloˇcilo, da ni potrebno veˇc kot eno jedro in ker bi bila efektivna uporaba veˇcih jeder prezahtevna s programerskega vidika. Najhitreˇse jedro pa nam pridobi najveˇc rezerve pri implementaciji algoritmov, ki so lahko manj op- timizirani. Dodatna prednost mikrokrmilnika je v tem, da STM ponuja komplet razvojnih orodij STM32Cube [5]. Orodje se je obseˇzno uporabljalo med kon-
2.4 Distribucija napajanja 7
struiranjem, saj avtomatsko preverja, ali so uporabnikove nastavitve sponk ter perifernih enot pravilne. V fazi pisanja programske opreme je orodje koristno, saj lahko na podlagi naˇse nastavitve generira osnovo za projekt.
Na mikrokrmilnik sta povezana dva kristalna oscilatorja. Prvi kristal ima frekvenco 24 MHz in sluˇzi kot glavna ura za vse periferne enote znotraj mikrokr- milnika. Na tiskanini je kristal postavljen na izoliran otoˇcek zato, da se motnje, ki jih povzroˇca, ne ˇsirijo drugje po vezju. Otoˇcek je narejen na prvem in drugem sloju. Na tretjem in ˇcetrtem sloju otoˇcka ni. Postavitev kristala je prikazana na sliki 2.2. Drugi kristal ima frekvenco 32,768 kHz in je uporabljen za realnoˇcasno uro (Real Time Clock – RTC). Ta kristal ostaja aktiven tudi, ko je glavno napa- janje odklopljeno. Realnoˇcasna ura nam omogoˇca beleˇzenje ure in datuma.
Slika 2.2: Postavitev kristalnega oscilatorja ter oblika otoˇcka na drugem sloju
2.4 Distribucija napajanja
VCU opravlja distribucijo napajanja za vse 12 V sisteme na vozilu. Napetost iz 12 V baterije je speljana do VCU-ja, nato pa je porazdeljena na veˇc izhodov, vsak s svojo varovalko. V principu sluˇzi kot ˇskatla z varovalkami v osebnih vozilih in omogoˇca pregled nad vsemi varovalkami na enem mestu. Na VCU je postavljena zato, da lahko z mikrokrmilnikom direktno izvajamo pregled nad porabo naprav in hkrati vklapljamo ali izklapljamo posamezne naprave. Pregled nad stanjem varovalk je narejen vizualno. Pod vsako varovalko je postavljena svetleˇca dioda, ki se ugasne takrat, ko varovalka pregori. Merjenje porabe je opisano v poglavju
8 Opis vezja
2.4.1.
Odsek vezja za distribucijo napajanja je bil primerno dimenzioniran glede na najveˇcjo predvideno tokovno porabo. V tabeli 2.1 so navedeni vsi porabniki na vozilu ter njihova najveˇcja poraba.
Tabela 2.1: Maksimalne tokovne porabe vseh naprav na formuli
Naprava IM ax (A)
Crpalkeˇ 9,2
Glavni ventilatorj 12 Baterijski ventilatorji 10,5
Inverterji 2,84
TSAL 1
Pedalna ˇskatla 1
Armaturna ploˇsˇca 1
VCU 1
Ostalo <1
Skupaj 40
Kabel iz 12 V baterije je pred vstopom na VCU razdeljen na 4 vodnike, saj so sponke na konektorju, skozi katere vstopamo na vezje, omejene na 12 A. Ker je skupni tok razdeljen na veˇc sponk, potrebuje vsaka od njih svojo varovalko, saj bi lahko v primeru, da se en vodnik prekine, presegli tokovno omejitev na ostalih treh sponkah konektorja.
Zaradi velikih tokov, ki teˇcejo skozi VCU, in zaradi tankega sloja bakra (35 µm) je bilo potrebno za najveˇcje porabnike naˇcrtovati ˇcim krajˇse poti s ˇcim veˇcjo povrˇsino zato, da so imeli ˇcim manjˇso upornost in s tem manjˇse termiˇcne izgube. V odsekih, kjer so priˇcakovani najveˇcji tokovi, so dodani tudi termiˇcni skozniki (angl. thermal via), vidni poleg merilnih uporov na sliki 2.6.
Na vezju sta uporabljena dva razliˇcna tipa varovalk. Prvi tip je MINI® [6]
serija avtomobilskih varovalk. So ˇsiroko dostopne varovalke, ki skupaj z drˇzalom ne zasedejo veliko prostora na vezju. Njihov problem je v tem, da niso na voljo za tokove, ki so manjˇsi od 1 A. Drugi tip so cilindriˇcne varovalke. Te so uporabljene
2.4 Distribucija napajanja 9
za nizkotokovne naprave, saj so na voljo za ˇsirok nabor tokov pod 1 A. Njihova glavna teˇzava je v tem, da so dvakrat ˇsirˇse v primerjavi z MINI serijo varovalk.
Izbira samo enega tipa varovalk je bila zaradi njihovih slabosti izloˇcena. Samo avtomobilske varovalke ne bi bile na voljo za vse potrebne tokove, cilindriˇcne pa bi poveˇcale vezje do nesprejemljive velikosti. Na koncu se je naredil kompromis med obema, kjer se je za vse veˇcje porabnike uporabilo avtomobilske MINI varovalke in cilindriˇcne varovalke za vse preostale naprave.
2.4.1 Merjenje toka
Tokovne meritve se izvaja z merjenjem padca napetosti na merilnih uporih, skozi katere teˇce tok naprej v porabnike. Zaradi prostorskih omejitev se tok ne meri na vseh porabnikih, temveˇc samo po skupinah porabnikov. Vizualna predstavitev vezave je na sliki 2.3. Merilni upori so postavljeni na odcepih napajanj posa- meznih naprav. Z upori merimo tok pred in po skupini porabnikov. Izmerjeni vrednosti lahko nato odˇstejemo v programu in na ta naˇcin dobimo porabo po- samezne skupine porabnikov. Na ta naˇcin merimo tokove glavnih ventilatorjev, vodnih ˇcrpalk ter baterijskih ventilatorjev, za vse ostale porabnike pa imamo zgolj njihovo skupno porabo, ki je izmerjena na zadnjem uporu v vrsti.
12V
Itotal I1 I2
If an=Itotal−I1 Ipump =I1−I2
Slika 2.3: Shema vezave tokovnih meritev
Za meritev so bili izbrani tokovni merilni upori, kar pomeni, da imajo zelo nizko upornost (<1mΩ), nizko toleranco in nizki temperaturni koeficient. Mer- jenje padca napetosti na uporu je narejeno s Kelvinovo vezavo, kar pomeni, da je merilna povezava narejena na najbolj notranji strani upora in je loˇcena od
10 Opis vezja
glavne poti toka [7, toˇcka 4]. Na ta naˇcin je napetostna meritev izvedena zgolj na merilnem elementu in ne vsebuje napake zaradi padca napetosti na kontaktih (slika 2.5).
Slika 2.4: Merjenje padca napetosti na merilnem uporu
Tok skozi merilne upore se meri z uporabo ojaˇcevalnika tokovnih senzorjev (angl. current sense amplifier) NCS199A2 [8]. To je ˇcip, ki vsebuje operacijski ojaˇcevalnik z integriranimi upori (ˇcip U10 na sliki 2.4) v vezavi diferencialnega ojaˇcevalnika. Prednost uporabe takˇsnega ˇcipa je manjˇsa poraba prostora na vezju, saj so vsi potrebni upori za vezavo diferencialnega ojaˇcevalnika ˇze vgra- jeni. Prednost vgrajenih uporov je tudi v tem, da imajo zaradi izdelave na is- tem substratu visoko raven medsebojnega ujemanja. Ker se nahajajo na majhni povrˇsini znotraj istega ohiˇsja, se jim enakomerno spreminja temperatura in s tem tudi njihova upornost, kar nam zmanjˇsa koliˇcino lezenja na izhodu. Toleranca teh uporov moˇcno vpliva na rezultat meritve, natanˇcneje na vrednost sofaznega ojaˇcanja. Izhod ojaˇcevalnika lahko izraˇcunamo po enaˇcbi 2.1.
Vout =AD∗(V+−V−) +ACM ∗V+ (2.1) Enaˇcba je sestavljena iz diferencialne in sofazne komponente. Doseˇci ˇzelimo ˇ
cim veˇcje diferencialno ojaˇcanjeAD, ki nam bo ojaˇcalo majhen padec napetosti na merilnem uporu, hkrati pa ˇzelimo imeti ˇcim manjˇse sofazno ojaˇcanjeACM, ki nam
2.4 Distribucija napajanja 11
Slika 2.5: Vezava tokovne meritve
vnaˇsa napako preko enosmerne napetosti na ne-invertirajoˇci sponki ojaˇcevalnika.
Razmerje teh dveh ojaˇcanj uporabimo pri izraˇcunu CMRR.
CM RR= 20 log10 AD ACM
(2.2) Z uporabo zunanjih uporov, ki imajo toleranco 0.1 %, je moˇzno doseˇci CMRR
= 84 dB. Vrednost CMRR, ki jo ponuja uporabljeni namenski ojaˇcevalnik, znaˇsa 115 dB. Ker so ojaˇcevalniki tokovnih senzorjev na voljo samo s fiksnimi vre- dnostmi ojaˇcanja, jih je potrebno izbrati v kombinaciji z merilnim uporom, tako da bodo pri najveˇcjem priˇcakovanem toku izkoristili najveˇcji razpon vrednosti, ki jih lahko izmeri analogni vhod na mikrokrmilniku.
2.4.2 Izhodne stopnje
VCU ima funkcijo preklapljanja ventilatorjev ter ˇcrpalk na vozilu. Sam preklop teh naprav je izveden s PMOS tranzistorji, ki jih mikrokrmilnik poganja preko vmesne NMOS stopnje (angl. gate driver). Shema vezave je na sliki 2.7. Vsa
12 Opis vezja
Slika 2.6: Upori za tokovne meritve med varovalkami
stikala so postavljena tik ob konektorju, njihove povezave pa so ˇcim krajˇse in podvojene na veˇcih slojih zato, da imajo ˇcim manjˇso upornost.
Crpalke in ventilatorji so velika induktivna bremena, kar pomeni, da pri ne-ˇ nadnem odklopu napajanja ustvarjajo visoke negativne napetostne konice, ki bi lahko uniˇcile izhodne stikalne tranzistorje na VCU-ju. Ker na vezju, zaradi pro- storskih omejitev, ni implementirana zaˇsˇcita proti temu, je potrebno na oˇziˇcenju ˇ
crpalk in ventilatorjev obratno vzporedno povezati “freewheel” diode, ki pri od- klopu napajanja ohranijo tokokrog, preko katerega se lahko shranjena energija varno izprazni [9, stran 2].
Na vezju sta dve dodatni NMOS pametni stikali BTS3118D [10]. Stikali sta namenjeni upravljanju dodatnih naprav, ki niso bile planirane v zaˇcetnem naˇcrtu.
Stikali imata ˇsirok nabor koristnih funkcij:
ESD zaˇsˇcita
termiˇcna zaˇsˇcita z zapahom
zaˇsˇcita pred preobremenitvijo
zaˇsˇcita pred kratkim stikom
2.5 VCU napajanje 13
Sidepod fan 1
FAN_CTRL
1
2 3
Q29
SI2393DS-T1-GE3
3
1
2
Q25 BSS306N
GND R122
49.9kR
R114 60.4R R115
5.1kR
GND
Sidepod fan 1 out
Slika 2.7: Stikalo za ventilatorje
zaˇsˇcita pred prenapetostjo
limitiranje toka
Pri BTS3118D stikalu je za doseganje nizke upornostiRDS potrebno napajati vhod z vsaj 5 V. GPIO izhodi na mikrokrmilniku so sposobni samo 3,3 V, zato je potrebna uporaba MCP1402 gate driver ˇcipa [11], ki dvigne ta nivo na 12 V in zagotovi, da ima stikalo najmanjˇso moˇzno upornost (slika 2.8).
1 IN
SOURCE 3 DRAIN 2 LS1
BTS3118D R132
10kR
LS1_CTRL 3 5
U22A
MCP1402T-E/OT
CGND LS1
GND
Slika 2.8: Pametno NMOS stikalo
2.5 VCU napajanje
VCU je naˇcrtovan za napajanje iz 12 V baterije. Ker lahko med sestavljanjem ali servisiranjem vozila pride do napaˇcnega priklopa baterije, je na vhodni stopnji napajalnika vezje za aktivno zaˇsˇcito pred obratnim priklopom (slika 2.9 levo).
Ob pravilnem priklopu bo Vgs negativna in PMOS bo do konca odprt. Ob
14 Opis vezja
napaˇcnem priklopu pa boVgs pozitivna in bo PMOS zaprt [12, poglavje 3.3]. Za tem sledi filter za odstranjevanje sofaznih motenj na napajanju, ki vodi v vhodni elektrolitski kondenzator in nato v napajalni ˇcip. Negativna stran napajalnika (CGND) je na vhodu loˇcena od glavne zemlje, ki se uporablja na vezju. Shema vhodne stopnje je prikazana na sliki 2.9, naˇcrt vezja pa na sliki 2.10.
SUPPLY RESET
1 RSL 2 BSG 7 ENA 8 WAK
22 ROT 59 VS2 60 VS1 63 DRG 64 RSH 12V
4 3 2
1LCM1 SRF0905-100Y CF1
0.1u/50V
CF2 0.1u/50V
CVS3 0.1u/50V 3
1
2
QRP1
IPD85P04P4L-06
12
DRP1 MM3Z10VST1G
RRP1 49.9kR
PGND C62 470uF
CGND
GND
Slika 2.9: Vhodna stopnja napajalnika
Za regulacijo napetosti je uporabljen napajalnik Infineon TLF35584 [13], [14].
Napajalnik ima integrirane vhodne (vmesne) ter izhodne regulatorje in potrebuje minimalno ˇstevilo zunanjih komponent. Na vhodu je uporabljen integrirani step- down regulator (slika 2.11 zgoraj), ki obratuje pri 2,2 MHz in spusti vhodno napetost [6 V–40 V] na vmesno napetostVP REREG = 5,8 V. Ta vmesna napetost je nato interno povezana na integrirane namenske linearne LDO izhodne regulatorje, ki imajo razliˇcne napetosti (slika 2.11 spodaj).
Napajalnik med obratovanjem neprestano spremlja izhodne napetosti, tempe- rature in obremenitev internih regulatorjev. V primeru hujˇse napake bo informa- cije poslal po SPI liniji do mikrokrmilnika in se nato ponovno zagnal. Napajalnik ima tudi svoj watchdog ˇstevec, ki ga mora mikrokrmilnik redno ponastavljati. ˇCe se ta ˇstevec izteˇce, pomeni, da se je program na mikrokrmilniku verjetno ujel v neskonˇcno zanko, zato napajalnik sproˇzi ponovni zagon.
Napajalnik ponuja tudi natanˇcno 5 V referenco in dva linearna napetostna sle- dilnika (voltage tracker), ki sledita tej referenci in sta zato primerna za napajanje senzorjev.
2.6 Analogni del 15
Slika 2.10: Postavitev in povezava napajalnika
2.6 Analogni del
VCU opravlja 11 neodvisnih analognih meritev. Eno napetostno in ˇstiri tokovne meritve, ki se merijo na odseku za distribucijo napajanja (poglavja 2.4 in 2.4.1), preostalih ˇsest pa je speljanih na konektor in so namenjene za prikljuˇcitev zuna- njih senzorjev, kot so npr. linearni senzorji pomika, ki se uporabljajo za merjenje gibanja vzmeti na podvozju vozila. Vsi zunanji senzorji so napajani iz napeto- stnih sledilnikov (slika 2.11: VTR1, VTR2), ki uporabljajo natanˇcno 5 V refe- renco (VREF5).
Med naˇcrtovanjem vezja se je pojavil problem v tem, da je izhodna napetost sledilnikov na napajalniku 5 V, maksimalna napetost na analognih vhodih mi- krokrmilnika pa je 3,6 V. Za zniˇzanje nivoja napetosti bi lahko izhode senzorjev povezal na napetostni delilnik, vendar bi potem upornost delilnika preobremenila izhod senzorjev in vplivala na pravilnost meritve. Zato je vsak analogni vhod na VCU povezan na operacijski ojaˇcevalnik, ki je v konfiguraciji napetostnega
16 Opis vezja
HM72E-064R7LF LBU1 4.7uH
CPR1 22uF
VPREREG
PGND
VuC33
VCOM5 VTR1
VTR2
VREF5 SYN 24
EVC 26
MPS 27 SEC 28 FRE STU 30
VCI 31
GST
QVR 38 QUC 39 SQUC 40 QCO 41
QT2 42 SQT2 43 SQT1QT1 4445 FB1 46 FB2 47 FB3 48 FB4 49
AG4 50 PG2PG1 5152 SW2SW1 5556
VREF5
1 2
J-MPSH
CPR2 10uF
CFB1 100nF
CUC1 4.7uF CCO1 4.7uF CT2
4.7uF CT1
4.7uF CVR1 4.7uF
GND AGND
GND GND
VCOM5
VREF5 VTR1
VTR2
VuC33 i SupplyLine
Slika 2.11: Vmesna in izhodna stopnja napajalnika
sledilnika in ˇsele nato deljen na uporovnem delilniku (sliki 2.12 in 2.14), ki skalira obmoˇcje na 3,3 V. Identiˇcen uporovni delilnik je povezan tudi med 5 V refe- renco na napajalniku in 3,3 V referenco za A/D pretvornik na krmilniku. A/D pretvornik ima na napajalni liniji ˇse feritno jedro za duˇsenje nihanj (slika 2.13).
Za zmanjˇsanje merilnih napak so uporabljeni upori z 0.1 % toleranco in nizkim temperaturnim koeficientom, celotno vezje pa je postavljeno nad loˇceno analogno zemljo. Na vhodu pred sledilnikom je postavljen RC filter z mejno frekvenco 130 Hz (slika 2.12).
2.7 Komunikacija 17
Slika 2.12: Shema vhodne analogne stopnje s sledilniki
Slika 2.13: Referenˇcna napetost in napajanje A/D pretvornika
2.7 Komunikacija
2.7.1 CAN
Veˇcina komunikacije med napravami na vozilu poteka po CAN (Controller Area Network) vodilu. CAN vodilo omogoˇca hitro in robustno komunikacijo z uporabo diferencialnih signalov. V kombinaciji z zaˇsˇciteno sukano parico je CAN vodilo idealno za uporabo v elektriˇcnem vozilu, kjer motorji in inverterji ustvarjajo veliko koliˇcino elektromagnetnih motenj.
Za komunikacijo po CAN vodilu je potrebno uporabiti CAN transceiver (oddajnik–sprejemnik). Za vezje je bil izbran Microchip MCP2562FD [15], ki omogoˇca komunikacijo po hitrejˇsem CAN FD (Flexible Data rate) protokolu.
Cip podpira napajanje z dvema razliˇˇ cnima napetostma, kar je potrebno zato, ker so nivoji signalov na strani CAN vodila 5 V, na strani mikrokrmilnika pa 3,3 V.
18 Opis vezja
Slika 2.14: Vhodna analogna stopnja s sledilniki
Na vezje je dodana tudi terminacija, ki jo lahko po potrebi onemogoˇcimo tako, da odstranimo upora R17 in R19, kar je prikazano na sliki 2.15. Namesto klasiˇcne terminacije z enim 120 Ω uporom je uporabljena “biased split” terminacija, ki izboljˇsa EMC lastnosti vezja [16, poglavje 3.2]. Glavni razlog za to je v tem, da se diferencialni signali pravilno terminirajo preko upora, sofazni signali oz.
motnje pa vidijo enojni upor kot odprte sponke, zato pride na obeh koncih linije do odbojev in poslediˇcno do zvonjenja na liniji. Z dvema 60 Ω uporoma in kondenzatorjem (C28) je moˇzno ustvariti nizko impedanˇcno pot do zemlje za sofazne motnje. Z uporoma R18 in R20 pa vsiljujemo konstanten 2.5 V recesivni nivo na obeh linijah, kar ˇse dodatno izboljˇsa EMC lastnosti vezja.
2.7.2 RS-232
Za potrebe naprav, ki ne podpirajo CAN protokola, je bil na VCU dodan RS- 232 vmesnik. Za razliko od CAN, RS-232 ne uporablja diferencialnih signalov, kar zmanjˇsa maksimalno zanesljivo hitrost prenosa. Za doseganje zadostnega
2.8 Zajemanje podatkov 19
Slika 2.15: CAN vmesnik s terminacijo
razmerja med signalom in ˇsumom (Signal to Noise Ratio – SNR) je potrebna veˇcja razlika med logiˇcnima nivojema (± 5 V), kar pa povzroˇca daljˇse prehode (slew rate) in omeji hitrost prenosa. Za RS-232 komunikacijo je bil uporabljen Maxim MAX13235E ˇcip [17], ki ima vgrajena dva vmesnika in podpira hitrosti prenosa do 3 Mb/s, kar je relativno visoka hitrost za RS-232. V aplikaciji na vozilu je en vmesnik uporabljen za komunikacijo z IMU-jem (angl. Inertia Measurment Unit), ki poˇsilja informacije o pospeˇskih vozila in GPS lokacijo. Drug vmesnik je uporabljen za nalaganje programske opreme na mikrokrmilnik.
2.8 Zajemanje podatkov
Zajemanje podatkov je bistvenega pomena pri razvoju dirkalnika. V zaˇcetnih fazah razvoja pomaga pri razreˇsevanju tehniˇcnih teˇzav in iskanju napak v sis- temu. Ko pa je dirkalnik enkrat tehniˇcno brezhiben, se lahko osredotoˇcimo na zajemanje podatkov o njegovi zmogljivosti. Ti podatki omogoˇcajo vozniku in dirkalnemu inˇzenirju vpogled v obnaˇsanje dirkalnika na stezi. Hitrost vozila, sile ter pomiki v vzmetenju in boˇcni pospeˇski so le eni izmed mnogih podatkov, s katerimi lahko ovrednotimo voznikove obˇcutke na stezi in zniˇzamo ˇse kakˇsno de- setinko ˇcasa na krog. Uporabljajo se tudi za potrditev naˇcrtovanih zmogljivosti iz zaˇcetnih faz razvoja. Inˇzenirji na podroˇcju podvozja, ˇsasije in aerodinamike se pri razvoju svojih sklopov moˇcno opirajo na simulacije. Rezultate, ki jih dobijo iz teh simulacij, primerjajo z izmerjenimi podatki na vozilu s procesom, ki mu pravimo validacija. Pri validaciji doloˇcimo raven ujemanja simuliranega modela
20 Opis vezja
z dogajanjem v resniˇcnem svetu. Modelu, ki ima visoko raven ujemanja, reˇcemo, da je reprezentativen. Model, ki ni reprezentativen, nakazuje povrˇsno razumeva- nje fizikalnih zakonov, ki definirajo njegovo obnaˇsanje. Z novimi meritvami dobi inˇzenir dodaten vpogled v dogajanje in poglobi to razumevanje zato, da lahko popravi model tako, da bo uporabnejˇsi za naslednjo iteracijo izdelka.
Sedaj smo spoznali vlogo meritev in lahko postavimo nekaj zaˇcetnih zahtev za sistem, ki jih bo izvajal. Sistem mora biti hiter, da lahko dovolj visoko vzorˇci najhitrejˇse prehode, ki nas zanimajo, nuditi mora dovolj vhodov za meritve, pod- pirati veˇc razliˇcnih protokolov komunikacije ter imeti dovolj trajnega pomnilnika, da lahko shrani par ur izmerjenih podatkov. Za ugoditev teh zahtev bi bila pri- merna ˇze veˇcina merilnih sistemov, ki so trenutno na trgu. Ti sistemi ponujajo veliko ˇstevilo vhodov, imajo dovrˇsen uporabniˇski vmesnik ter jamˇcijo zanesljivo delovanje. Je pa njihova slabost v tem, da so dragi. Takˇsni inˇstrumenti so izde- lani tako, da pokrivajo ˇsirok spekter moˇznih aplikacij in protokolov, zato je teˇzje najti take, ki so dovolj majhni in imajo hkrati vse potrebne vmesnike. Tudi ˇce bi naˇsli primerno merilno napravo, bi jo morali umestiti vzporedno z VCU-jem, ki je kontrolna enota vozila in je ˇze povezan z vsemi senzorji in sistemi na vozilu, kar bi pomenilo, da bi se nam poveˇcala skupna koliˇcina ˇzic in konektorjev, s tem pa masa ter kompleksnost sistema. Navedene toˇcke oˇcitno kaˇzejo na to, da je najboljˇsa reˇsitev ta, da VCU opravlja nalogo merilnega sistema. Poleg tega, da imamo tako preprost dostop do vseh naprav in senzorjev, ki so povezane na VCU, imamo tudi direkten dostop do vseh internih spremenljivk iz raznih algoritmov, ki se izvajajo na njem.
Implementacija sistema za zajemanje podatkov na VCU bo predstavljena v naslednjih toˇckah.
1. SD kartica 2. USB
3. brezˇziˇcna telemetrija 4. rezervni pomnilnik
2.8 Zajemanje podatkov 21
2.8.1 SD kartica
SD kartica sluˇzi kot trajni pomnilnik za podatke, ki jih zajema VCU. Za to nalogo smo jo izbrali, saj ima dovolj visoko hitrost in dovolj spomina. Ti dve zahtevi smo postavili glede na tipiˇcno hitrost in dolˇzino posnetkov, ki smo jih izvajali v prejˇsnjih sezonah. Na tipiˇcnem posnetku ˇzelimo beleˇziti 128 spremenljivk tipa float s frekvenco 100 Hz, ˇcas trajanja pa bi bil najveˇc 30 minut. To skupaj nanese na hitrost 51 kB/s in velikost enega posnetka 92 MB, kar sta zelo nizki zahtevi za sodobne SD kartice. STM32H7 procesor, ki ga uporabljamo na VCU-ju, ima ˇze vgrajen vmesnik za SD kartico, ki podpira delovanje v HS (High Speed) naˇcinu in lahko doseˇze hitrosti do 25 MB/s [18, poglavje 55.4] ter podpira velikosti do 32 GB. V HS naˇcinu vmesnik komunicira s kartico s 3,3 V signali. Po standardu je potrebno imeti na linijah za SD kartico pull-up upore ter terminacijske upore. To zahtevo reˇsimo s CM1624 ˇcipom [19], ki ima, poleg zahtevanih uporov, integriran ˇse EMI filter in TVS diode, ki ˇsˇcitijo procesor pred razelektritvami, ki se lahko zgodijo med menjavo SD kartice. Pri konstruiranju vezja se je upoˇstevalo vsa pri- poroˇcena naˇcela za hitre signale. SD kartica je postavljena ˇcim bliˇzje procesorju, vse linije pa imajo pod seboj neprekinjeo zemljo. Kjer je potrebno zamenjati sloj, naredi signalna linija prehod iz prvega sloja (rdeˇca) na ˇcetrti sloj (modra), poleg pa je postavljena ozemljitvena izvrtina.
Slika 2.16: Shema vezave SD kartice ter EMI filtra (levo) ter implementacija na vezju (desno)
22 Opis vezja
2.8.2 USB
USB vmesnik se uporablja za povezavo VCU-ja na osebni raˇcunalnik. Preko USB-ja je moˇzno v ˇzivo prenaˇsati trenutne podatke, prenesti stare posnetke, ki so shranjeni na SD kartici, ali pa spreminjati parametre vozila. STM32H7 procesor ima ˇze vgrajen USB vmesnik, ki brez dodatne zunanje opreme podpira USB v FS (Full Speed) naˇcinu in deluje s hitrostjo 12 Mbit/s. Za high speed naˇcin, ki omogoˇca hitrosti do 480 Mbit/s, bi bil potreben ULPI ˇcip, za katerega se ni odloˇcilo, saj bi zavzel preveˇc prostora in poveˇcal kompleksnost vezja. Hitrost v FS naˇcinu je dovolj visoka za tipiˇcen prenos, ki pri 30-minutnem posnetku traja pribliˇzno eno minuto.
Pri konstruiranju vezja so se upoˇstevale USB specifikacije ter vsa priporoˇcena naˇcela za hitre diferencialne signale. Po standardu je na D+ linji potreben 1,5 kΩ pull-up upor, ki pa je pri H7 procesorju ˇze integriran na ˇcipu. VCU deluje kot
“USB device” oz. USB naprava, osebni raˇcunalnik pa kot “host” oz. gostitelj, kar pomeni, da mora VCU spremljati nivo na VBUS liniji, da ugotovi prisotnost osebnega raˇcunalnika. VBUS linija iz raˇcunalnika deluje na petih voltih, sponka za detekcijo pa ima absolutno toleranco VDD + 4 V. Ker je VCU napajan iz baterije na avtu in ne iz VBUS linije, bi pri odklopu napajanja (VDD = 0 V) napetost na tej liniji presegla 4 V in uniˇcila ˇcip. Da prepreˇcimo to moˇznost, je na VBUS liniji vstavljen uporovni delilnik, ki spusti nivo na 3 V, kar je ˇse zmeraj dovolj visoko za detekcijo (kriterij: 0,7∗VDD). Vse povezave na USB so zaˇsˇcitene proti elektrostatiˇcni razelektritvi z USBLC6-4SC6 [20] ˇcipom, ki je postavljen takoj ob konektorju. Diferencialni liniji D+ in D- sta speljani druga ob drugi s pribliˇzno isto dolˇzino in neprekinjeno zemljo.
2.8.3 Brezˇziˇcna telemetrija
Brezˇziˇcna telemetrija se uporablja za dvosmerno komunikacijo med VCU-jem in prenosnim raˇcunalnikom. Omogoˇca nam spremljanje podatkov v realnem ˇcasu, medtem ko je dirkalnik na stezi. Omogoˇca nam spreminjanje parametrov vozila med obratovanjem, kar je koristno pri nastavljanju algoritmov za vozno dina- miko, saj lahko voznik neprekinjeno ponavlja en vozni manever, medtem pa lahko
2.8 Zajemanje podatkov 23
Slika 2.17: Shema USB vodila
inˇzenir v ˇzivo spreminja parametre in spremlja vpliv teh sprememb.
Telemetrija je na VCU-ju implementirana z LoRa SX1278 modulom. LoRa protokol je bil izbran, ker, za razliko od mobilnega omreˇzja, ne potrebuje dostopa do centrale in nima plaˇcljive naroˇcnine. Doseg LoRa modula je primeren za razdalje na tipiˇcnem dirkaliˇsˇcu. Edina bistvena omejitev LoRa omreˇzja je nizka hitrost prenosa.
LoRa SX1278 moduli so na voljo v piggyback izvedbi, zato je namestitev na vezje preprosta. Na VCU je povezan s SPI vodilom in 6 GPIO signali. Podatkovne SPI linije so speljane na ˇcim krajˇsi razdalji z neprekinjeno zemljo. Povezava za anteno, ki izstopa iz LoRa modula, je tik ob modulu speljana na koaksialni konektor, ki je nato preko kabla povezan na zunanjo anteno.
2.8.4 Rezervno napajanje
STM32H7 krmilnik vsebuje interno periferno enoto za nadzor napajanja. Napaja- nje znotraj krmilnika je razdeljeno na veˇc domen (domena jedra, analogna domena itd.). Ena izmed njih je rezervna ali zasilna domena (angl. backup). Krmilnik nudi moˇznost napajanja te rezervne domene tudi ko je krmilnik izklopljen. Za to
24 Opis vezja
funkcijo je potrebno na Vbat sponko priklopiti 3 V baterijo. Napajalna periferija bo napajanje rezervne domene avtomatsko preklopila iz glavnega na rezervno na- pajanje takrat, ko ugasnemo primarno napajanje. Pod rezervno domeno spadata del SRAM pomnilnika ter realnoˇcasna ura s koledarjem. Uporaba rezervnega po- mnilnika za shranjevanje konfiguracije VCU-ja je podrobneje opisana v poglavju 3.1.2. Realnoˇcasna ura oz. RTC (angl. real time clock) je ura s koledarjem, ki po izklopu napajanja teˇce naprej, zato se pri beleˇzenju podatkov uporablja za pridobivanje trenutne ure in datuma na zaˇcetku vsakega podatkovnega zajema.
2.9 Varnostni sistemi
Formula Student pravilnik specificira posebne varnostno-kritiˇcne sisteme, ki jih mora implementirati vsaka ekipa, ˇce ˇzeli priti skozi tehniˇcni prehod. V sklopu tega poglavja bomo spoznali tri takˇsne sisteme. V preteklih sezonah so ti sistemi obstajali na ECU-ju, po novem pa se nahajajo na VCU-ju, vendar brez bistvenih sprememb v naˇcinu delovanja.
2.9.1 Izklopno vezje
Izklopno vezje, po angl. shutdown circuit (od zdaj naprej SDC), je sistem, skozi katerega mora teˇci celotni napajalni tok za izolacijske kontaktorje v bateriji (AIR).
SDC mora po pravilniku vsebovati specificirano serijo zaporedno vezanih stikal in zapahov. Zaradi obvezne zaporedne vezave bo odprtje katerega koli ˇclena SDC verige povzroˇcilo takojˇsni odklop vseh treh izolacijskih kontaktorjev v bateriji.
Med stikala, ki sodijo pod SDC, spadajo zasilna stikala v kabini in na obeh straneh vozila, inercijsko stikalo za zaznavanje trkov in ˇse par drugih. Zapahi pa se uporabljajo pri kritiˇcnih sistemih, kot so AMS, IMD ter BSPD, ki morajo ostati v razklenjenem stanju tudi po tem, ko se napaka odpravi. Teh zapahov voznik ne more ponastaviti iz kabine, ker jih je moˇzno ponastaviti le z zunanjim posegom.
2.9 Varnostni sistemi 25
2.9.2 Indikator aktivnosti pogonskega sistema
Indikator aktivnosti pogonskega sistema, po angl. tractive system active light (od zdaj naprej TSAL), je sistem, ki da vsem prisotnim osebam okoli dirkalnika podatke o trenutnem stanju aktivacije pogonskega sistema. Sitem je sestavljen iz dveh delov. En del je sama luˇc, ki se mora nahajati na vrhu varnostne kletke, drug del pa je logiˇcno vezje, ki spremlja stanja izolacijskih kontaktorjev ter napetosti na pogonskem sklopu, da ugotovi, ali je ta aktiviran oz. ali naj se ga zaradi zaznane okvare obravnava kot aktiviranega.
26 Opis vezja
3 Programska oprema
Programska oprema na VCU-ju zajema komplet programov in storitev, ki izvajajo nadzor nad voˇznjo vozila ter pravilnim delovanjem njegovih sistemov. Cilj razvoja je bil narediti hitro, zanesljivo, fleksibilno programsko platformo, ki bo omogoˇcala enostavno namestitev na trenutni dirkalnik ter na vse bodoˇce dirkalnike. Koda za vsako posamezno funkcionalnost je loˇcena po modulih. Konfiguracije posame- znih modulov so shranjene loˇceno od njihovih implementacij. Takˇsna struktura omogoˇca, da so moduli ter storitve zajeti v repozitoriju za verzioniranje, ki se lahko vzporedno razvija na veˇcih dirkalnikih. Z uporabo programa Git ter sple- tno storitvijo kot je Gitlab, imamo pregled nad vsemi verzijami kode, hkrati pa tam dokumentiramo vse odkrite teˇzave ter njihove reˇsitve.
Slika 3.1 prikazuje arhitekturo sistema programske opreme. Spodnji blok pred- stavlja nivo strojne opreme STM32H7 mikrokrmilnika. Do strojne opreme v krmilniku dostopamo preko gonilnikov iz HAL knjiˇznice. HAL – hardware ab- straction layer oz. sloj za abstrakcijo strojne opreme – je knjiˇznica za STM32 pro- cesorje, ki jo generiramo znotraj razvijalnega okolja STM32CubeIDE 3.2. Orodje ponuja vmesnik za generacijo kode za gonilnike ter konfiguracijo vseh perifer- nih enot na krmilniku. V konfiguraciji lahko nastavljamo, na katere sponke so speljane posamezne periferne enote, kolikˇsne so hitrost prenosa komunikacijskih vmesnikov, prekinitve, DMA in ˇse mnogo veˇc. Obstojeˇco konfiguracijo je moˇzno spreminjati in generairati novo kodo, brez potrebe po ustvarjanju novega pro- jekta. Ker je programski vmesnik ali API (application program interface) za HAL knjiˇznico generiˇcen, je moˇzno celoten projekt z minimalnim ˇstevilom modi- fikacij preseliti na drug STM mikrokrmilnik.
Programsko okolje STM32CubeIDE se uporablja tudi za generacijo vmesne
27
28 Programska oprema
STM32H7 Mikrokrmilnik SEOS
STM HAL gonilniki
FDCAN SDMMC SPI UART USB ...
Applikacije
CAN handler
Vmesna programska oprema
FreeRTOS USB
Monitor RTOS resource ...
Driving Vehicle state Cooling Communication ...
Slika 3.1: Arhitektura projekta
programske opreme ali angl. middleware. Ta sloj abstrakcije vsebuje kodo za realnoˇcasni operacijiski sistem FreeRTOS ter kodo za USB protokol, kjer specifi- ciramo VCU kot USB napravo (USB device [21, poglavje 4]).
FreeRTOS je realnoˇcasni operacijski sistem oz. bolj specifiˇcno jedro, na ka- terem lahko gradimo sisteme v realnem ˇcasu. Ponuja nam komplet funkcij in storitev, s katerimi lahko razvrstimo zaˇzeljene funkcionalnosti krmilnika na opra- vila, ki jih FreeRTOS nato pametno razvrˇsˇca in izvaja ob toˇcno doloˇcenih ˇcasih.
FreeRTOS je bil uporabljen kot osnova za SEOS (3.1).
3.1 SEOS
SEOS ali Superior Engineering operating system je zbirka orodij, narejenih na osnovi HAL gonilnikov in FreeRTOS jedra. Narejen je bil v sklopu razvoja pro- gramske opreme za Formula Student dirkalnik. Namen je bil narediti orodje, s
3.1 SEOS 29
Slika 3.2: Konfiguracija krmilnika znotraj okolja STM32CubeIDE
katerim je moˇzno hitro ustvariti generiˇcen krmilnik za poljuben sistem na dirkal- niku, ki uporablja CAN komunikacijo in mora delovati v realnem ˇcasu. Zmoglji- vost SEOS-a se je kasneje ˇse nadgradila s sistemom za shranjevanje in oddajanje zajetih podatkov po razliˇcnih vmesnikih, kot sta USB in SD kartica.
3.1.1 CAN komunikacija
CAN vodilo predstavlja glavni naˇcin prenosa podatkov in ukazov med napravami na vozilu (slika 3.3). V veˇcini primerov priˇcakujemo takojˇsnji odziv prejemnika, hkrati pa na prejemniku ne ˇzelimo troˇsiti procesorskega ˇcasa z izvajanjem pro- gramov, dokler ti ne dobijo nove informacije o sistemu. V ta namen so se SEOS-u dodale storitve, ki nam omogoˇcajo enostavno postavitev CAN komunikacije in pa naˇcin, da proˇzimo specifiˇcna realnoˇcasna opravila ob prejemu novih sporoˇcil.
3.1.1.1 CAN konfiguracija
Konfiguracija CAN sporoˇcil se izvaja z uporabo struktur, ki jih HAL knjiˇznica uporablja pri izvajanju komunikacije. Znotraj projekta urejamo dve tabeli teh
30 Programska oprema
INVERTER 1 INVERTER 2 PEDALBOX VCU
DASHBOARD
BATTERY MANAGEMENT
SYSTEM
ENERGY METER STEERING
WHEEL
Slika 3.3: Diagram CAN omreˇzij na vozilu
struktur, ki vsebujeta podatke o sporoˇcilih, ki jih nameravamo uporabljati. Ena tabela je za sporoˇcila, ki jih poˇsiljamo, in druga za sporoˇcila, ki jih sprejemamo.
Za indeksiranje sporoˇcil znotraj obeh tabel uporabljamo enumeracije. Tem enu- meracijam pravimo tudi oprijemalo sporoˇcila ali angl. message handle. Z opri- jemali lahko kjerkoli na projektu dostopamo do informacije o posameznem CAN sporoˇcilu. V tabeli za poˇsiljanje imamo shranjeno informacijo o tem, na katero CAN omreˇzje spada posamezno sporoˇcilo in informacije o samem sporoˇcilu, kot so identifikacijska ˇstevilka, dolˇzina sporoˇcila ipd. V tabeli za sprejemanje sporoˇcil imamo definirane sprejemne filtre, ki bodo naprej spuˇsˇcali samo sporoˇcila, ki so definirana v tabeli, ostala pa ignorirala, tako da ne zavzemajo procesorskega ˇcasa.
V sprejemni tabeli je potrebno za vsako sporoˇcilo podati tudi naslov do funkcije, ki prevede vsebino sporoˇcila. Program za sprejemanje je tako nastavljen in lahko preko naslova sporoˇcila sam kliˇce primerno prevajalno funkcijo za vsako sporoˇcilo.
3.1.1.2 Potek CAN komunikacije
Poˇsiljanje sporoˇcila izvedemo tako, da zapakiramo ˇzeljene podatke v paket in ga nato skupaj z oprijemalom sporoˇcila podamo funkciji za poˇsiljanje. Funkcija iz HAL knjiˇznice pripravi ustrezen CAN paket ter ga poˇslje na ciljni CAN vmesnik.
Sprejemanje sporoˇcil se zanaˇsa na kompleksnejˇsi sistem od poˇsiljanja. Vizu- alni diagram sprejema CAN sporoˇcil je prikazan na sliki 3.4. Prva faza sprejema
3.1 SEOS 31
se zgodi, ko CAN periferija sproˇzi prekinitveno rutino po uspeˇsno sprejetem pa- ketu. Sedaj je potrebno spraviti paket iz prekinitve do opravila za procesiranje CAN paketov. Ker paketi lahko prihajajo iz veˇcih virov, konˇcati pa morajo v enem opravilu, je potrebna uporaba FreeRTOS kolone ali vrste (angl. queue). Iz prekinitvenih rutin kopiramo podatke v vrsto, pri ˇcemer uporabimo temu name- njeno funkcijo. Podatki, ki prihajajo v vrsto, bodo postavljeni na najniˇzje prosto mesto v koloni. Opravilo za procesiranje sporoˇcil (slika 3.4 desno) ˇcaka v bloki- ranem stanju, dokler se na prvem mestu v koloni (indeks 0) ne pojavi sporoˇcilo.
Ko se na prvem mestu pojavi sporoˇcilo, ga opravilo pobere iz kolone in obdela njegovo vsebino. V tem ˇcasu so se lahko v vrsto postavila nova sporoˇcila in se premaknila na najniˇzje prosto mesto. Opravilo bo iz vrste neprestano pobiralo sporoˇcila, dokler se ta ne izprazni, za tem pa se bo vrnilo nazaj v blokirano stanje.
Task Queue
0 1 2 N ...
xQueueSendT oBackFromISR xQueueSendT
oBackFromISR Interrupt
FD CAN 0 Rx Interrupt handler
Interrupt
FD CAN 1 Rx Interrupt handler
Message processing Wake up
Slika 3.4: Pot CAN sporoˇcila od sprejema do obdelave
3.1.1.3 CAN dogodki
CAN dogodki so posebna aplikacija FreeRTOS-ove storitve za skupine dogodkov (event group). FreeRTOS dogodki se uporabljajo za zbujanje opravil, ki ˇcakajo na specifiˇcen dogodek oz. kombinacijo dogodkov. V ta namen sluˇzijo kot idealno orodje za VCU, kjer ˇzelimo soˇcasno izvajati veliko ˇstevilo opravil, katerih odziv je odvisen od nove informacije, ki v veˇcini primerov pride po CAN vodilu. V prvem koraku je potrebno definirati zastavice ali angl. event flags, ki bodo pred- stavljale posamezne dogodke. To naredimo z enumeracijami, njihove vrednosti pa definiramo z zamiki bitov, saj je skupina dogodkov bitno polje, kjer vsak bit predstavlja posamezen dogodek.
1 e n u m E v e n t F l a g s {
32 Programska oprema
2 B O O T _ I N V 1 = 1 < < 0 ,
3 B O O T _ I N V 2 = 1 < < 1 ,
4 B U T T O N S = 1 < < 2 ,
5 B M S _ C E L L = 1 < < 3 ,
6 };
V drugem koraku je potrebno definirati strukturo, kjer shranimo oprijemalo do skupine dogodkov in mapiramo definirane dogodke na oprijemala sporoˇcil, ki smo jih omenili v poglavju 3.1.1.1. Za tem v FreeRTOS-u ustvarimo statiˇcno skupino dogodkov, naˇso strukturo pa registriramo v SEOS sistemu za prejemanje sporoˇcil.
1 s t r u c t E G E n t r y T r a n s i t i o n E v e n t s = {
2 . h a n d l e P t r = & Evn ,
3 . f l a g s = {
4 [ C A N _ R X _ I N V 1 _ B O O T U P ] = B O O T _ I N V 1 ,
5 [ C A N _ R X _ I N V 2 _ B O O T U P ] = B O O T _ I N V 2 ,
6 [ C A N _ R X _ D A S H B O A R D ] = BUTTONS ,
7 [ C A N _ R X _ B M S _ C E L L S ] = B M S _ C E L L ,
8 }
9 };
10
11 v o i d i n i t (v o i d) {
12 Evn = x E v e n t G r o u p C r e a t e S t a t i c (& E v n B u f f ) ;
13 S E O S _ C A N _ M s g R X _ H a n d l e r _ R e g i s t e r (& T r a n s i t i o n E v e n t s ) ;
14 }
Sedaj imamo vse pripravljeno, da v opravilih ˇcakamo na CAN sporoˇcila. V opravilih si lahko definiramo masko zastavic dogodkov in nato kliˇcemo FreeR- TOS funkcijo za ˇcakanje na dogodke. Podrobno delovanje funkcije je opisano v FreeRTOS dokumentaciji [22, poglavje 6]. Ko v opravilu kliˇcemo funkcijo xE- ventGroupWaitBits, ga bo FreeRTOS blokiral. Opravilo bo nato ˇcakalo na izpol- njene pogoje, da se spet zbudi. Pogoji so v naˇsem primeru zastavice dogodkov.
Cakamo lahko, da se zgodi katerikoli dogodek iz maske ali pa da se zgodijo vsiˇ dogodki. Definiramo lahko tudi maksimalni ˇcas ˇcakanja na dogodke. V spodnjem primeru je funkcija xEventGroupWaitBits klicana tako, da bo zbudila opravilo, ko se bodo zgodili vsi trije dogodki iz maske ali pa ko bo poteklo 1000 milisekund.
1 v o i d V e h i c l e S t a t e F u n c (v o i d * Arg ) {
2 w h i l e (1) {
3.1 SEOS 33
3 E v e n t B i t s _ t m a s k = B O O T _ I N V 1 | B O O T _ I N V 2 | B M S _ C E L L ;
4 E v e n t B i t s _ t e v e n t s = x E v e n t G r o u p W a i t B i t s ( Evn , mask , pdTRUE , p d M S _ T O _ T I C K S ( 1 0 0 0 ) ) ;
5
6 if (( e v e n t s & m a s k ) == m a s k ) {
7 // Vsa tri s p o r o c i l a s p r e j e t a . I z v a j a j o p r a v i l o
8 } e l s e {
9 // Cas p o t e k e l p r e d e n so p r i s l a s p o r o c i l a . P r i m e r n o u k r e p a j
10 }
11 }
12 }
Storitev za javljanje CAN dogodkov nam omogoˇca, da se v poljubnem ˇstevilu opravil naroˇcimo na poljubno kombinacijo sporoˇcil. Storitev si ob inicializaciji shrani tabelo vseh naroˇcnikov na sporoˇcila in njihove zastavice dogodkov. Ko po CAN-u sprejmemo novo sporoˇcilo, bo storitev vsem naroˇcnikom postavila zasta- vico dogodka v njihovi skupini dogodkov, FreeRTOS jedro pa bo nato poskrbelo, da se razvrstijo vsa opravila, ki so doˇcakala ˇcakane dogodke. Storitev bil lahko v prihodnosti tako posodobili, da bi generiˇcno ravnala s komunikacijskimi vmesniki in tako javljala dogodke ob sprejemu sporoˇcil iz UART, SPI in ostalih vmesnikov.
3.1.2 Monitor
Monitor je storitev v sklopu SEOS-a, ki izvaja nadzor nad parametri, beleˇzenjem podatkov ter komunikacijo z zunanjim raˇcunalnikom. Razvit je bil zaradi spe- cifiˇcnih zahtev, ki izhajajo iz dinamiˇcnega procesa hkratnega razvoja in testiranja dirkalnega prototipa.
Za delovanje se zanaˇsa na uporabo zasilnega ali rezervnega SRAM pomnil- nika (angl. backup static random access memory). Tipiˇcno, SRAM ni trajen, kar pomeni, da se bodo podatki na njem izgubili, ˇce mu odstranimo napajanje.
STM32H7 arhitektura pa ima moˇznost uporabe rezervne baterije, ki po izklopu glavnega napajanja ˇse naprej napaja doloˇcen odsek SRAM-a. Ta rezervni odsek, ki je velik 4 kB, se uporablja za shranjevanje parametrov ter ostalih metapodat- kov, potrebnih za delovanje sistema, ki bi jih sicer morali shranjevati na zunanji EEPROM ali pa na SD kartico, pri ˇcemer je prednost ˇse v tem, da ta odsek
34 Programska oprema
SRAM-a spada pod naslovljiv pomnilnik, tako da lahko na njem direktno ustvar- jamo C spremenljivke in do njih dostopamo brez komunikacijskih vmesnikov, kot sta SPI ali I2C.
3.1.2.1 Parametri
Pregled funkcionalnosti sistema za parametre:
Parametri so nastavljivi med ˇcasom obratovanja (angl. runtime). Parame- tre je moˇzno spreminjati preko osebnega raˇcunalnika ter s stikali na volanu.
Ob spremembi parametra preko osebnega raˇcunalnika se nova vrednost zapiˇse na trajni pomnilnik.
Ob vnoviˇcnem zagonu se uporabi zadnja zapisana vrednost.
Nekatere parametre se lahko zaradi varnostnih pomislekov spreminja samo s ponovnim zagonom. Ostale je moˇzno posodabljati ob poljubnih intervalih.
Parametre je moˇzno opremiti z enoto ter s kratkim opisom.
Seznam parametrov ter njihove vrednosti je moˇzno prenesti na osebni raˇcunalnik. Ta seznam je moˇzno kasneje naloˇziti nazaj na VCU.
Definiranje novih parametrov med razvojem vkljuˇcuje minimalno ˇstevilo korakov.
Princip delovanja sistema bomo opisali s postopkom definiranja novega pa- rametra. S klicem predprocesorske direktive v vrstici 4 ustvarimo tri entitete naˇsega parametra. Ustvarimo:
1. spremenljivko, ki jo uporabljamo v naˇsi aplikaciji (“Variable” na sliki 3.5);
2. nabiralnik, ki hrani novo vrednost parametra (“Mailbox” na sliki 3.5) ter 3. spremenljivko v backup SRAM-u, ki hrani vrednost parametra, ko je VCU
izklopljen.
3.1 SEOS 35
Variable Backup SRAM
Mailbox
PC USB
USB_Cmd_Task
init() param_sync(ParamName)
Slika 3.5: Princip delovanja
Naslednji korak je, da parameter registriramo v Monitorju (vrstica 13). Monitor si ob vsakem zagonu sestavi seznam vseh registriranih parametrov ter njihovih lokacij na pomnilniku (vrstica 15). Iz slike 3.5 vidimo, da bo Monitor med svojo inicializacijo kopiral vrednost, ki je shranjena na backup SRAM-u, v spremen- ljivko, ki jo uporablja naˇsa aplikacija. Vrednost te spremenljivke lahko prosto spreminjamo znotraj aplikacije brez vpliva na vrednost, ki je shranjena v backup SRAM-u. ˇCe ˇzelimo vrednost parametra spreminjati z zunanjim raˇcunalnikom, se lahko kadarkoli poveˇzemo na VCU z USB ali LoRa vodilom. Monitor bo, ob vzpostavljeni povezavi, poslal seznam vseh parametrov ter njihovih vrednosti. Ko z raˇcunalnikom zahtevamo spremembo enega parametra, se nova vrednost zapiˇse direktno na backup SRAM in v nabiralnik (mailbox). Nabiralnik je v bistvu FreeRTOS kolona (queue) z enim elementom. Sluˇzi kot zaˇcasna shramba nove vrednosti parametra. Da prepiˇsemo parameter, ki ga trenutno uporablja apli- kacija, z vrednostjo v nabiralniku, je potrebno znotraj aplikacije klicati funkcijo za sinhronizacijo ˇzeljenega parametra (param sync(ParamName)). Na ta naˇcin lahko med programiranjem aplikacije definiramo, kdaj se sme posodobiti vrednost parametra in se na ta naˇcin izognemo morebitnemu nezaˇzelenemu obnaˇsanju sis- tema.
36 Programska oprema
1 # i n c l u d e " M o n i t o r . h "
2
3 // a l o k a c i j a p a r a m e t r a
4 S E O S _ M o n i t o r _ P A R A M _ A L L O C A T E (
5 float, // P o d a t k o v n i tip
6 P o w e r L i m i t , // Ime p a r a m e t r a
7 d e s c (" M a x i m u m ␣ DC ␣ p o w e r ") , // O p i s
8 u n i t (" kW ") // E n o t a
9 ) = 8 0 . 0 ; // P r i v z e t a v r e d n o s t
10
11 v o i d m a i n (v o i d) {
12 // r e g i s t r a c i j a p a r a m e t r a
13 S E O S _ M o n i t o r _ R e g i s t e r P a r a m ( P o w e r L i m i t ) ;
14 // M o n i t o r i n i c i a l i z a c i j a po r e g i s t r a c i j i v s e h p a r a m e t r o v
15 S E O S _ M o n i t o r _ P o s t I n i t () ;
16 // F r e e R T O S z a g o n
17 v T a s k S t a r t S c h e d u l e r () ;
18 }
3.1.2.2 Podatki
Pregled funkcionalnosti sistema za zajemanje podatkov:
Podatke je moˇzno hkrati poˇsiljati:
– na SD kartico,
– na raˇcunalnik preko USB,
– brezˇziˇcno, na raˇcunalnik preko LoRa oddajnika.
Vsaka od naˇstetih metod poˇsiljanja uporablja svoj seznam podatkov, ki naj jih poˇsilja. Te sezname je moˇzno spreminjati z osebnim raˇcunalnikom, brez potrebe po ponovnem programiranju.
Podatke, zajete na SD kartici, je moˇzno prenesti na raˇcunalnik preko USB povezave.
Podatki se lahko zajemajo s poljubno frekvenco (najveˇc 1000 Hz).
Frekvenca zajemanja je definirana v aplikaciji in ni spremenljiva od zunaj.
3.1 SEOS 37
Podatke je moˇzno opremiti z enoto ter s kratkim opisom.
Definiranje novih podatkov med razvojem vkljuˇcuje minimalno ˇstevilo ko- rakov.
Variable
Mailbox Backup SRAM
data_sync(DataName)
USB
USB_taskMailbox Mailbox
SD card
SD_taskLoRa
LoRa_task
PC USB
USB_Cmd_Task
Datalogging configuration init()
Slika 3.6: Pregled delovanja zajemanja podatkov
Princip delovanja sistema bomo opisali s postopkom definiranja novega po- datka. S klicem predprocesorske direktive v vrstici 4 ustvarimo tri entitete naˇsega podatka. Ustvarimo:
1. spremenljivko, ki jo uporabljamo v naˇsi aplikaciji (“Variable” na sliki 3.6);
2. nabiralnike za vsako metodo prenosa, ki hranijo nove vrednost podatka (“Mailbox” na sliki 3.6), ter
3. konfiguracijo v backup SRAM-u, ki hrani nastavitve podatkov, ko je VCU izklopljen.
Naslednji korak je, da podatek registriramo v Monitorju (vrstica 13). Monitor si ob vsakem zagonu sestavi seznam vseh registriranih podatkov ter lokacije nji- hovih konfiguracij na backup SRAM-u (vrstica 15). Vsak registriran podatek je opremljen s svojo konfiguracijo o tem, na katere vse vmesnike naj se njegova vrednost poˇsilja. To konfiguracijo lahko spreminjamo z osebnim raˇcunalnikom.