• No results found

Uhlopˇr´ıˇ´ cka Provozn´ı teplota Rozhran´ı Sv´ıtivost [cd/m2] Cena 4” -40C aˇz 85C

COM, Ethernet

USB, — 100 USD

Obr´azek 1.17: STM32H747I-DISCO [12]

Displej pro STM32H747I-DISCO

Jako vhodn´y displej, kter´y by mohl slouˇzit po pˇripojen´ı k tomu kitu jako fin´aln´ı varianta se jevil displej od spoleˇcnosti Winstar. Tento displej disponuje sv´ıtivost´ı 1100 cd/m2. D´ale v´yrobce uv´ad´ı, ˇze displej je ˇciteln´y z kaˇzd´eho ´uhlu. Teplotn´ı odol-nost displeje -30–80 C. Displej je vybaven vstupem LVDS. Jelikoˇz v´yvoj´aˇrsk´y kit poskytuje MIPI R DSI bude zapotˇreb´ı vyuˇzit´ı pˇrevodn´ık mezi tˇemito rozhran´ımi.[32]

Tabulka 1.13: Winstar WF70A8SYAHLNN0

Uhlopˇr´ıˇ´ cka Provozn´ı teplota Rozhran´ı Sv´ıtivost [cd/m2] Cena

7” -30C aˇz 80C LVDS 1100 25 USD

Obr´azek 1.18: Winstar WF70A8SYAHLNN0 [32]

1.6 Tipy pro v´ yvoj grafiky HMI displej˚ u

Udrˇzovat jednoduchost

Pro vytv´aˇren´ı vysoce v´ykonn´e HMI aplikace je d˚uleˇzit´e udrˇzovat jednoduchost.

To zahrnuje zobrazen´ı pouze toho, co je pro uˇzivatele d˚uleˇzit´e. Neoˇcek´avat, ˇze uˇzivatel bude vˇedˇet, co jednotliv´e hodnoty v r´amci procesu znamenaj´ı, na m´ısto toho vhodnˇe tyto hodnoty zobrazit do spr´avnˇe zvolen´eho rozmez´ı.[13]

Dodrˇzet jednoduchost bude ˇz´adouc´ı i v r´amci t´eto pr´ace. Nejdˇr´ıve si zvolit nejd˚uleˇzitˇejˇs´ı z prvk˚u, kter´e bude potˇreba zobrazit pro uˇzivatele. Pot´e prov´est zhod-nocen´ı pˇrehlednosti.

Konzistentnost

Pokud jsou jiˇz napˇr´ıklad v tov´arnˇe k dispozici jin´a HMI, tak bude vhodn´e, aby novˇe vytv´aˇren´y syst´em byl co nejv´ıce podobn´y tˇem st´avaj´ıc´ım. At’ uˇz se jedn´a o um´ıstˇen´ı ovl´adac´ıch prvk˚u, pouˇzit´e barevn´e sch´ema, a dalˇs´ı. Pokud se jedn´a

pˇr´ıpadˇe je potˇreba dodrˇzovat nˇejakou formu konzistence alespoˇn mezi jednotliv´ymi obrazovkami.[13]

V pˇr´ıpadˇe t´eto pr´ace bude moˇzn´e povaˇzovat za jistou formu inspirace zvyklosti z jin´ych automobil˚u a to, at’ elektrick´ych, tak klasick´ych se spalovac´ım motorem.

Nebylo by totiˇz rozumn´e vn´aˇset nˇejakou vlastn´ı formu rozloˇzen´ı, kter´a se nebude ale-spoˇn ˇc´asteˇcnˇe podobat zaˇzit´emu standardu. Nebo napˇr´ıklad vym´yˇslet ´uplnˇe vlastn´ı reprezentaci r˚uzn´ych prvk˚u.

Pouˇzit´ı pˇrimˇeˇren´eho poˇctu barev

Zvolit vhodn´y poˇcet barev, aby bylo umoˇznˇeno efektivnˇe zachytit pozornost uˇzivatele. Napˇr´ıklad barvy urˇcen´e pro upozornˇen´ı by mˇely b´yt pouˇz´ıv´any pouze za t´ımto ´uˇcelem.[13]

Toto doporuˇcen´ı by se dalo pˇrevz´ıt i pro pˇr´ıpad t´eto pr´ace. V´ysledn´a grafick´a podoba by tak mˇela vyuˇz´ıt pˇrimˇeˇren´eho poˇctu barev. D´ıky tomuto pak p˚ujdu jasnˇe a zˇretelnˇe upozornit uˇzivatele, v tomto pˇr´ıpadˇe ˇridiˇce, napˇr´ıklad na nutnost nabit´ı akumul´atoru, ˇci jin´eho technick´eho probl´emu.

1.7 Osvˇ edˇ cen´ e postupy pˇ r´ı v´ yvoji grafiky ˇ r´ıd´ıc´ıho syst´ emu HMI

Pˇresnost

Pˇri vytv´aˇren´ı grafiky je d˚uleˇzit´e zaˇc´ıt s aktualizovan´ymi poˇzadavky a pˇresn´ymi informaci ohlednˇe vytv´aˇren´e aplikace. Vytv´aˇren´ı neaktu´aln´ı ˇci nepˇresn´e grafiky bude m´ıt za n´asledek nutnost pˇrepracov´an´ı a m˚uˇze v´est i ke zmatku.[14]

Toto doporuˇcen´ı by mˇelo b´yt snad nezbytnost´ı, plat´ıc´ı obecnˇe pro vˇetˇsinu pro-jekt˚u. V t´eto pr´aci bude vhodn´e zaˇc´ıt nejdˇr´ıve jen s n´aˇcrtem na pap´ır, kter´y by se n´aslednˇe mohl pˇren´est do samotn´e grafiky displeje. Zde by se nejdˇr´ıve vyˇreˇsilo, zda lze vˇsechny poˇzadovan´e prvky um´ıstit na obrazovku v rozumn´e velikosti. Pokud by se nepodaˇrilo ´uspˇeˇsnˇe um´ıstit vˇsechny poˇzadovan´e prvky, pˇriˇslo by na ˇradu nejdˇr´ıve zmenˇsen´ı v nˇejak´em pomˇeru, pˇr´ıpadnˇe by pak muselo doj´ıt k odebr´an´ı urˇcit´ych prvk˚u a jejich pˇresunut´ı na dalˇs´ı obrazovku.

Vizu´aln´ı logika

Jako dalˇs´ı je potˇreba promyslet nejlepˇs´ı logick´e rozvrˇzen´ı proces˚u do grafiky. Zde se typicky pouˇz´ıv´a rozdˇelen´ı jednotliv´eho procesu do v´ıce oblast´ı. Tyto oblasti pak reprezentuj´ı jednotliv´e ˇc´asti tohoto procesu. Grafika v celkov´em n´ahledu by mˇela zobrazovat vˇsechny interakce mezi vˇsemi zaˇr´ızen´ımi a k tˇemto interakc´ım zobrazit pouze nejd˚uleˇzitˇejˇs´ı informace. Z toho celkov´eho zobrazen´ı by mˇel b´yt umoˇznˇen pˇr´ıstup k detailnˇejˇs´ım informac´ım ohlednˇe kaˇzd´e z interakc´ı.[14]

Pouˇzit´ı animac´ı

Animace obecnˇe v grafice vˇzdy zaujmou. V pˇr´ıpadˇe grafiky HMI by nemˇelo b´yt dovoleno, aby tyto animace zp˚usobovaly jak´ekoliv rozpt´ylen´ı uˇzivatele. Tak´e by mˇely b´yt zobrazeny pouze nezbytn´e informace. Uˇzivatel se totiˇz potˇrebuje v prv´e ˇradˇe zamˇeˇrit na sledov´an´ı stavu procesu.[14]

Doporuˇcen´ı bude urˇcitˇe vhodn´e dodrˇzet i v r´amci n´avrhu grafiky potˇrebn´eho pro tuto pr´aci. Jelikoˇz uˇzivatel, v tomto pˇr´ıpadˇe ˇridiˇc, ocen´ı v´ıce zobrazen´ı stavu baterie a upozornˇen´ı na nutnost dobyt´ı, m´ısto animace, zda je automobil v pohybu. Tato informace by byla na displeji na ´ukor viditelnost ostatn´ıch a pro ˇridiˇce d˚uleˇzitˇejˇs´ıch prvk˚u.

1.8 CAN Bus

CAN (Controler Area Network) je robustn´ı standard sbˇernice pouˇz´ıvan´y ve vo-zidlech. Zjednoduˇsenˇe by se dalo CAN sbˇernici pˇrirovnat k nervov´emu syst´emu automobilu, kter´y umoˇzˇnuje komunikaci mezi vˇsemi jeho ˇc´astmi. V pˇr´ıpadˇe au-tomobilu jsou tˇemito ˇc´astmi jednotliv´a ECU (Electronic Control Unic). ECU je zabudovan´y syst´em v automobilov´e elektronice, kter´y ˇr´ıd´ı jeden ˇci v´ıce elektrick´ych syst´emu nebo subsyst´emu ve vozidle. Napˇr´ıklad airbagy, audiosyst´em nebo manage-ment baterie. Modern´ı vozidla mohou m´ıt aˇz 80 takov´ychto ECU. Protokol sbˇernice CAN pak umoˇzˇnuje komunikaci navz´ajem mezi jednotliv´ymi syst´emy. Odpad´a tak potˇreba realizace vyhrazen´ych linek mezi kaˇzd´ym z tˇechto syst´em˚u. Z´aroveˇn je d´ıky propojen´ı pomoc´ı t´eto sbˇernice umoˇznˇeno, aby jednotliv´a ECU pouˇz´ıvala infor-mace z ostatn´ıch, coˇz eliminuje potˇreby instalace senzor˚u stejn´eho zamˇeˇren´ı do v´ıce zaˇr´ızen´ı. Zde budou uvedeny hlavn´ıch v´yhody a d˚uvody, proˇc je tento standard vyuˇz´ıv´an. [15]

N´ızk´a cena

ECU komunikuj´ı pomoc´ı jedin´eho rozhran´ı CAN. D´ıky ˇcemuˇz je zredukov´ana v´ysledn´a cena, hmotnost i chybovosti.

Centralizace

Syst´em sbˇernice CAN umoˇzˇnuje centr´aln´ı diagnostiku chyb a konfiguraci vˇsech ECU.

Robustnost

Takov´yto syst´em je odoln´y v˚uˇci elektrick´ych poruch´am a elektromagnetick´emu ruˇsen´ı, coˇz ho ˇcin´ı pro prostˇred´ı automobil˚u ide´aln´ım.

Efektivn´ı

Priorita vys´ılan´ych CAN zpr´avy je rozliˇsena pomoc´ı ID. Zpr´avy s nejvyˇsˇs´ı prio-ritou z´ıskaj´ı pˇr´ıstup ke sbˇernici pˇrednostnˇe.

Flexibilita

Kaˇzd´a jednotka ECU pˇripojen´a k CAN sbˇernici m˚uˇze pˇrij´ımat vˇsechny zpr´avy pˇren´aˇsen´e touto sbˇernic´ı. Pak se rozhoduje o relativnosti jednotliv´ych zpr´av pro dan´e ECU a podle toto jsou data akceptov´ana ˇci ignorov´ana.

1.9 Popis demo-boardu

Pro pˇr´ıpad t´eto pr´ace byl vyuˇzit demo-board. Na obr´azku 1.19 je vidˇet blokov´e sch´ema tohoto demo-boardu. V r´amci t´eto pr´ace byla ˇreˇsena funkcionalita ˇci komuni-kace pro n´asleduj´ıc´ı ˇc´asti. Displeje (palubn´ı desky), ˇr´ıdic´ı jednotky, ovl´adac´ıch prvk˚u podvolantov´e jednotky (p´aˇcky smˇerovek, p´aˇcky stˇeraˇc˚u a ostˇrikovaˇc˚u a ovl´ad´an´ı me-chanismu z´amk˚u.

Obr´azek 1.19: Blokov´e sch´ema demo-boardu

1.9.1 Vstupy a v´ ystupy

Mezi jeden druhu sign´al˚u, kter´e bylo potˇreba v tomto pˇr´ıpadˇe zpracov´avat, patˇrily CAN zpr´avy. Tyto zpr´avy jsou pos´ıl´any po sbˇernici mezi ˇr´ıdic´ı jednotkou a displejem. Dalˇs´ım druhem zpracov´avan´ych sign´al˚u byly sign´aly silov´e. Tyto sign´aly slouˇzily napˇr´ıklad pro obsluhu svˇetel pro denn´ı sv´ıcen´ı. V´ystupy na tomto demo-boardu tvoˇrily koncov´e prvky. Mezi tyto prvky patˇrila: svˇetla smˇerovek, svˇetla pro denn´ı sv´ıcen´ı, motorek stˇeraˇc˚u, motorek ostˇrikovaˇc˚u a z´amky. Tyto v´ystupy byly ovl´ad´any za pomoc´ı rel´e, pˇr´ıpadnˇe

”solid state rel´e“.

Obr´azek 1.20: Demo-board

2 Realizace grafiky a firmwaru

2.1 V´ ybˇ er a testov´ an´ı displej˚ u

Mikroe HMI 7”

Po proveden´ı poˇc´ateˇcn´ı reˇserˇse displej˚u byl vybr´an displej od spoleˇcnosti Mikro-elektronika. U tohoto displeje byla podle parametr˚u jedin´ym moˇzn´ym probl´emem pomˇernˇe mal´a sv´ıtivost jeho panelu. Pro ´uˇcel programov´an´ı tohoto displeje byl k dis-pozici kompil´ator

”microC for FT90x“. Souˇc´ast´ı tohoto kompil´atoru bylo i prostˇred´ı pro vytv´aˇren´ı grafick´eho rozhran´ı. Prostˇred´ı jako celek se jevilo pˇrehlednˇe a pˇrivˇetivˇe.

Jako moˇzn´y probl´em se zde uk´azala jeho dokumentace. V dokumentaci knihovny s funkcemi potˇrebn´ymi pro komunikaci pomoc´ı CAN protokolu nebyl totiˇz u vˇetˇsiny z nich uveden konkr´etn´ı pˇr´ıklad jejich vyuˇzit´ı. Naˇstˇest´ı zde bylo k dispozici nˇekolik pˇr´ıklad˚u od v´yrobce, kter´e slouˇzily jako inspirace.

Nejdˇr´ıve byla do displeje nahr´ana aplikace pro otestov´an´ı. Toto probˇehlo bez komplikac´ı. Pro nahr´av´an´ı zkompilovan´eho k´odu zde slouˇzila aplikace USB HID Bootloader. Dalˇs´ı ˇc´ast´ı bylo otestov´an´ı komunikace po sbˇernice CAN. V r´amci sezn´amen´ı se s displejem byla jako prvn´ı otestov´ana komunikace po s´eriov´em portu.

Toto testov´an´ı probˇehlo bez komplikac´ı. N´aslednˇe pˇriˇslo na ˇradu samotn´e otestov´an´ı komunikace po sbˇernici CAN, kter´e ovˇsem dopadlo ne´uspˇechem. St´ale totiˇz nebylo moˇzn´e v displeji pˇreˇc´ıst pˇrijat´e CAN zpr´avy. Pro vys´ıl´an´ı CAN zpr´av bylo pouˇzito v´yvojov´e desky Arduino Due vybaven´e pˇr´ısluˇsn´ym vys´ılaˇcem. Zde bylo vyuˇzito i podpory ze strany v´yrobce, ale ani s touto pomoc´ı se CAN zpr´avy st´ale nedaˇrilo zpracovat nebo i jen ˇc´ıst jejich jednotliv´e ˇc´asti. Ohlednˇe grafick´ych moˇznost´ı byl tento displej prozkoum´am jen zbˇeˇznˇe. A uk´azalo se, ˇze pro poˇzadovan´y grafick´y de-sign by bylo potˇreba vytvoˇren´ı ˇci ˇc´asteˇcn´e upraven´ı jiˇz dostupn´ych widget˚u. D´ale testov´an´ı tohoto displeje jiˇz neprob´ıhalo.

Weintek eMT3070B

HMI displej od spoleˇcnosti Weintek byl dalˇs´ım testovan´ym. Zde byla vcelku snadno vyzkouˇsena komunikace po sbˇernici CAN, kter´a na rozd´ıl od modelu uve-den´eho v´yˇse, fungovala bez probl´emu. Vˇse ohlednˇe nastaven´ı a n´asledn´eho zobra-zen´ı dat z CAN zpr´avy, bylo velice intuitivn´ı. V pˇr´ıpadˇe tohoto displeje tak staˇcilo prov´est jeho propojen´ı s CAN vys´ılaˇcem a ve v´yvojov´em prostˇred´ı pˇridat nov´e lok´aln´ı zaˇr´ızen´ı, kter´e komunikuje po sbˇernici CAN. N´aslednˇe pak bylo moˇzn´e, jednoduˇse ˇc´ıst poˇzadovanou ˇc´ast CAN zpr´avy. Za zm´ınku d´ale stoj´ı v´yvojov´e prostˇred´ı, kter´e

je uˇzivatelsky pˇr´ıvˇetiv´e a tak´e obsahuje jiˇz spoustu pˇreddefinovan´ych prvk˚u. Tyto prvky d´ale nab´ızej´ı velkou variabilitu v moˇznostech jejich pˇrizp˚usoben´ı. V´yhodou tohoto displeje byla robustn´ı konstrukce, jelikoˇz displej byl um´ıstˇen v kovov´em ˇsasi. Jako nev´yhoda se u tohoto displeje jeho pomˇernˇe vysok´a cena, kter´a by zne-snadˇnovala jeho pouˇzit´ı ve v´ysledn´em elektromobilu, a tak´e jeho n´ızk´a sv´ıtivost.

4D systems GEN4-ULCD-50D-SB-AR

Jako dalˇs´ı byl testov´an displej od spoleˇcnosti 4D Systems. Tento displej nab´ız´ı pouze komunikaci pomoc´ı s´eriov´e linky. V´yrobce uv´ad´ı u tohoto displeje, ˇze dis-ponuje vysokou sv´ıtivost´ı, coˇz by bylo pro pˇr´ıpad t´eto pr´ace ide´aln´ı. Bohuˇzel se nepodaˇrilo uv´est do provozu ani jeden ze dvou kus˚u tohoto displeje, kter´e byly k dis-pozici a tak nebylo moˇzn´e ho nˇejak´ym zp˚usobem d´ale otestovat. Displej po pˇripojen´ı nap´ajen´ı pouze problik´aval a tak byl hned ze zaˇc´atku oznaˇcen za nevhodn´y a byl zam´ıtnut.

Riverdi RiTFT-50-IOT-CAP

Dalˇs´ım z testovan´ych byl displej od spoleˇcnosti Riverdi. Tento displej umoˇzˇnoval v´yvoj pomoc´ı r˚uzn´ych v´yvojov´ych prostˇred´ı. Zde bylo vyzkouˇseno nahr´an´ı apli-kace z v´yvojov´ych prostˇred´ı Arduino IDE a tak´e Zerynth Studio. V obou pˇr´ıpadech probˇehlo vˇse bez komplikac´ı. Tento displej vypadal jako pˇrijateln´a varianta pro reali-zaci v´ysledn´eho ˇreˇsen´ı. Nedostatek tohoto displeje spoˇc´ıval v nepˇr´ıtomnosti rozhran´ı CAN a tak´e v jeho nepˇr´ıliˇs vysok´e sv´ıtivosti. Kombinace tˇechto dvou nedostatk˚u vedla k hled´an´ı dalˇs´ıch variant.

STM32H747I-DISCO

Po zkuˇsenostech z pˇredchoz´ıch HMI displej˚u pˇriˇsla na ˇradu tato varianta. V tomto pˇr´ıpadˇe se nejedn´a pˇr´ımo o HMI displej, ale o v´yvoj´aˇrsk´y kit, kter´y umoˇzˇnuje pˇripojen´ı panelu. Jelikoˇz tento kit disponuje rozhran´ım MIPI R DSI, bylo moˇzn´e prov´est snadnou v´ymˇenu panelu na tomto kitu. D´ıky tomu bylo rozˇs´ıˇreno mnoˇzstv´ı panel˚u, ze kter´ych bylo moˇzn´e vyb´ırat. Tento kit byl tak´e nakonec vybr´an jako va-rianta pro fin´aln´ı ˇreˇsen´ı s t´ım, ˇze pro nˇej bude vybr´an panel s dostateˇcnou sv´ıtivost´ı a pozorovac´ımi ´uhly. Dalˇs´ım d˚uvodem proˇc byl tento kit nakonec vybr´an, byla pˇr´ıtomnost CAN sbˇernice.

Pro v´yvoj grafiky tohoto displeje bylo k dispozici hned nˇekolik v´yvojov´ych prostˇre-d´ı. Jedna z variant, kter´a byla k dispozici, bylo Embeded Wizzard studio. Toto v´yvojov´e prostˇred´ı se z poˇc´atku jevilo jako dobr´a varianta, i kdyˇz zp˚usob vytv´aˇren´ı aplikac´ı zde byl m´ırnˇe odliˇsn´y od vˇetˇsiny ostatn´ıch v´yvojov´ych prostˇred´ı. Bylo zde ale k dispozici mnoˇzstv´ı pˇr´ıklad˚u a uk´azek. Jako dalˇs´ı moˇznost pro v´yvoj grafiky byl n´astroj TouchGFX Designer. Toto prostˇred´ı nab´ızelo klasick´y zp˚usob v´yvoje, kde byla k dispozici ˇc´ast pro grafick´y n´avrh zp˚usobem

”drag and drop“a k n´ı n´aleˇzej´ıc´ı zdrojov´y k´od. Pro vytvoˇren´ı uˇzivatelsk´eho rozhran´ı bylo nakonec zvoleno druh´e jme-novan´e prostˇred´ı TouchGFX Designer.

2.2 N´ avrh grafiky

Dalˇs´ı ˇc´ast´ı t´eto bakal´aˇrsk´e pr´ace bylo navrˇzen´ı grafick´eho rozhran´ı pro vybran´y displej. Uˇz pˇri p˚uvodn´ım seznamov´an´ı se s displeji bylo jasn´e, ˇze budou u vˇetˇsiny z nich moˇznosti pˇredpˇripraven´ych widget˚u nedostaˇcuj´ıc´ı. Zejm´ena pak z pohledu jejich grafick´e str´anky. Vˇetˇsina z nich totiˇz obsahovala pouze widgety jednoduch´eho vzhledu. Pro vytv´aˇre podoby wigdet˚u, kter´a odpov´ıdala poˇzadavk˚um bylo vyuˇzito aplikace GNU Image Manipulation Program, zkr´acenˇe GIMP.

Pˇri vytv´aˇren´ı grafick´eho rozhran´ı bylo nejprve potˇreba si ujasnit, co uˇzivateli (ˇridiˇci) bude nutn´e zobrazovat. Jednalo se o aktu´aln´ı rychlost vozidla, dojezd, pr˚umˇ er-nou spotˇrebu, procenta zb´yvaj´ıc´ı baterie, aktu´aln´ı vyuˇzit´ı motoru a pak r˚uzn´e signa-lizaˇcn´ı kontrolky jako jsou smˇerovky, signalizace poruchy motoru ˇci svˇetel a dalˇs´ı. Po ujasnˇen´ı tˇechto poˇzadavk˚u bylo moˇzn´e pˇristoupit k samotn´eho vytv´aˇren´ı grafick´eho rozhran´ı.

N´avrh ukazatel˚u

Jako prvn´ı z vyjmenovan´ych pˇriˇsla na ˇradu realizace vizualizace vyuˇz´ıvan´eho v´ykonu a dojezdu. Zde bylo jiˇz od zaˇc´atku uvaˇzov´ano o vizualizaci ve formˇe, ja-kou je v automobilech reprezentov´an rychlomˇer a ot´aˇckomˇer. Prvn´ım zhotoven´ym n´avrhem, byl tento kruhov´y analogov´y ukazatel na obr´azku2.1.

Obr´azek 2.1: N´avrh kruhov´eho ukazatele

Dalˇs´ım z vytvoˇren´ych n´avrh˚u byl ukazatel p˚ulkruhov´y. Ten na rozd´ıl od kru-hov´e varianty poskytoval moˇznost vyuˇz´ıti i ˇc´asti prostoru uvnitˇr tohoto ukazatele.

Na obr´azku2.2 se nach´az´ı jeho prvn´ı n´avrh.

Obr´azek 2.2: N´avrh p˚ulkruhov´eho ukazatele

N´aslednˇe bylo vhodn´e vybrat jeden z tˇechto dvou n´avrh˚u a touto cestou pak pokraˇcovat. Jako varianta, kter´a bude pouˇzita pro ˇreˇsen´ı a z´aroveˇn tak i pro dalˇs´ı v´yvoj, byla zvolena varianta p˚ulkruhov´eho ukazatele. Na dalˇs´ıch obr´azc´ıch bude zobrazen postupn´y v´yvoj a ´upravy tohoto ukazatele.

V dalˇs´ım n´avrhu, kter´y je zobrazen na obr´azku 2.3, bylo provedeno drobn´e zmenˇsen´ı cel´eho ukazatele a zvˇetˇsen´ı ˇc´ıslic. Tento ukazatel vypadal uˇz o pozn´an´ı l´epe, jak varianta pˇredchoz´ı. Bohuˇzel zde zvˇetˇsen´ı ˇc´ıslic zlepˇsilo viditelnost ovˇsem na ´ukor pˇrehlednosti. Ukazatel pak p˚usobil aˇz moc pˇreplnˇen´ym dojmem.

Obr´azek 2.3: Vytv´aˇren´ı p˚ulkruhov´eho ukazatele

Jako ˇreˇsen´ı tohoto nedostatku se nab´ızelo ponech´an´ı jen nˇekter´ych ˇc´ısel. Po t´eto

´

upravˇe vypadal ukazatel n´asledovnˇe2.4. V tomto stavu jiˇz vypad´a ukazatel o pozn´an´ı pˇrehlednˇeji, neˇz v pˇredchoz´ım pˇr´ıpadˇe. Tato varianta byla pak jistou dobu uvaˇzov´ana jako fin´aln´ı.

Obr´azek 2.4: Vytv´aˇren´ı p˚ulkruhov´eho ukazatele II

N´aslednˇe byla provedena posledn´ı zmˇena v tomto ukazatele. Jelikoˇz byl tento ukazatel uvaˇzov´an pro vizualizaci dojezdov´e vzd´alenosti automobilu, bylo potˇreba prov´est drobn´e ´upravy. Tyto ´upravy byly provedeny zejm´ena pro usnadnˇen´ıˇcitelnosti a vylepˇsen´ı pˇrehlednosti tohoto ukazatele. V´ysledn´a verze, kter´a byla tak´e nakonec pouˇzita pro fin´aln´ı realizaci je zobrazena na obr´azku 2.5

Obr´azek 2.5: Vytv´aˇren´ı p˚ulkruhov´eho ukazatele III

V tomto stavu vypadal tento ukazatel ˇcitelnˇe a pˇrehlednˇe, ale z´aroveˇn nep˚usobil pˇreplnˇen´ym dojmem. Do ukazatele byly jeˇstˇe pˇrid´any popisky, aby bylo jasn´e, jak´a data ukazatel zobrazuje. Vnitˇrn´ı ˇc´ast ukazatele bylo vyuˇzita pro zobrazen´ı procent zb´yvaj´ıc´ı baterie a vnˇejˇs´ı ˇc´ast, kter´a byla vyplˇnov´ana zelenˇe, slouˇzila pro zobrazen´ı zb´yvaj´ıc´ıho dojezdu automobilu v kilometrech.

Tento n´avrh ukazatele poslouˇzil i pro vytvoˇren´ı dalˇs´ı ˇc´asti grafiky displeje. Jed-nalo se o druh´y ukazatel, kter´y byl urˇcen pro zobrazen´ı aktu´aln´ıho vyuˇzit´ı motoru a jeho druh´a polovina byla urˇcena pro zobrazen´ı, jak se v dobˇe, kdy nen´ı vyuˇz´ıv´an motor, dobij´ı akumul´ator. Napˇr´ıklad v dobˇe brzdˇen´ı ˇc´ı j´ızdˇe z kopce. Tento ukaza-tel zobrazen´y na obr´azku 2.6, byl aˇz na jeho znaˇcen´ı totoˇzn´y s ukazatelem, kter´y

zobrazoval dojezd automobilu.

Obr´azek 2.6: Vytv´aˇren´ı p˚ulkruhov´eho ukazatele IV

V pr˚ubˇehu vytv´aˇren´ı bylo uvaˇzov´ano o zobrazen´ı stavu baterie v podobˇe at’ uˇz horizont´aln´ı, ˇci vertik´aln´ıho baru. Jedn´ım z moˇzn´ych uvaˇzovan´ych zobrazen´ı stavu akumul´atoru byl napˇr´ıklad form´at zobrazen´y na obr´azku2.7

Obr´azek 2.7: Uvaˇzovan´e zobrazen´ı stavu akumul´atoru

Nakonec bylo ovˇsem zvoleno zobrazen´ı ve formˇe dvou stejnˇe stylizovan´ych ukaza-tel˚u. D´ıky tomuto form´atu bylo dosaˇzeno stejnorod´eho vzhledu cel´e grafiky displeje, nam´ısto v´ıce rozliˇcnˇe stylizovan´ych ˇc´ast´ı.

Kontrolky

U vytv´aˇren´ı kontrolek nebyl pˇr´ıliˇsn´y prostor na kreativitu, jelikoˇz jsou v tomto znaˇcen´ı jiˇz zaveden´e nˇejak´e standardy v oblasti automobil˚u a tak by bylo neˇz´adouc´ı a nesmysln´e prov´adˇet n´avrh jejich vlastn´ıho stylu. Jedin´e kontrolky, u kter´ych ˇslo pouˇzit alespoˇn z ˇc´asti vlastn´ıho n´avrhu, byly kontrolky smˇerovek.

Kompletn´ı grafika displeje

Po vytvoˇren´ı vˇsech potˇrebn´ych komponent, popsan´ych v pˇredchoz´ıch bodech, mohlo pˇrij´ıt na ˇradu jejich spojen´ı a realizace kompletn´ı grafiky. Vˇsechny kompo-nenty spojen´e dohromady vypadaly pak n´asledovnˇe viz obr. 2.8

Obr´azek 2.8: Fin´aln´ı n´avrh grafiky displeje

Zde bude n´asledovat popis jednotliv´ych ˇc´ast´ı jiˇz fin´aln´ı verze grafiky displeje.

Displej na obr´azku je zobrazen ve stavu, kdy jsou vˇsechny kontrolky rozsv´ıcen´e.

1. Zde jsou kontrolky prav´e a lev´e smˇerovky

2. Zobrazen´ı aktu´alnˇe zaˇrazen´e rychlosti. Jelikoˇz se jedn´a o displej do elektromobilu nejsou zde klasick´e rychlosti, ale pouze p´ısmena D, R, P, N.

3. Kontrolky svˇetel. Prvn´ı je kontrolka spuˇstˇen´eho denn´ıho sv´ıcen´ı, druh´a pak kon-trolka svˇetel d´alkov´ych a posledn´ı je kontrolka mlhov´ych svˇetel.

4. Zde se zobrazuje aktu´aln´ı rychlost vozidla.

5. ˇCerven´e a ˇzlut´e v´ystraˇzn´e kontrolky. Mezi nˇe patˇr´ı kontrolka zataˇzen´e ruˇcn´ı brzy, nezapnut´ych bezpeˇcnostn´ıch p´as˚u, poruchy motoru, svˇetel ˇci nedostatku kapaliny

5. ˇCerven´e a ˇzlut´e v´ystraˇzn´e kontrolky. Mezi nˇe patˇr´ı kontrolka zataˇzen´e ruˇcn´ı brzy, nezapnut´ych bezpeˇcnostn´ıch p´as˚u, poruchy motoru, svˇetel ˇci nedostatku kapaliny

Related documents