Avtor: Janez Pirc
Ko je bila strojna oprema (HW) relativno draga, smo bili primorani optimizirati stroške. To je pomenilo, da smo funkcionalnost naprave in grafični uporabniški vmesnik (GUI) v celoti poganjali na istem mikrokontrolerju.
HW arhitektura naprave
Pri manj zahtevnih napravah je ta pristop deloval, vendar se je s kompleksnejšimi napravami in večjimi zahtevami po zmogljivejšem GUI kmalu pokazalo, da je takšna arhitektura omejujoča. Razvojniki so ugotovili, da hkratno poganjanje GUI in naprave na istem mikrokontrolerju prinaša kompromise. Izbira med manj zmogljivim grafičnim vmesnikom ali manj zmogljivim krmilnikom naprave ni bila sprejemljiva. Zato so sodobne in kompleksne naprave danes običajno opremljene z enim ali več mikrokontrolerji, medtem ko GUI poganja računalnik. Spremembo prikazuje slika 1 v prvem članku v Svet elektronike št. 336.
V tem članku se bomo osredotočili na arhitekturo naprave z enim mikrokontrolerjem, ki nadzoruje delovanje naprave, medtem ko GUI poganja računalnik.
Časovna optimizacija razvojnega procesa
Optimizacija razvojnega procesa je ključnega pomena za učinkovito rabo virov. Ker je usposabljanje specialistov za različne tehnologije časovno zahteven proces, se razvijalci običajno specializirajo, nekateri se osredotočajo na razvoj programske opreme za mikrokontroler, medtem ko drugi razvijajo GUI na računalniku.
Klasičen razvojni cikel, ki obsega zapis zahtev, izdelavo naprave in temeljito testiranje, se pri kompleksnih sistemih razbije na več pod ciklov. Posamezne sklope razvijamo ločeno v začetni fazi projekta, nato pa jih integriramo v celoto. Ta proces se lahko ponavlja večkrat.
Ta vsebina je samo za naročnike
Podjetja pogosto posodabljajo in razvijajo več naprav istočasno, pri čemer so projekti v različnih fazah razvoja. Razvijalci se osredotočajo na svoje segmente in optimizirajo čas ter učinkovitost dela, pri čemer se izogibajo preklapljanju med projekti.
Neizkušeni vodje razvojnih projektov, ki imajo omejeno razumevanje tehnologij, se pogosto zanašajo na komunikacijo med specialisti. Pod časovnim pritiskom dajejo prednost projektom v zaključni fazi, kar lahko vodi v poenostavitve in zanemarjanje pomembnih analiz v zgodnjih fazah. Rezultat je sledeča časovna optimizacija projekta:
Najprej razvojna ekipa razvije napravo, ugnezdenem programer se fokusira na funkcionalnosti.
Kasneje GUI specialist oblikuje grafični vmesnik, ter ga integrira v napravo.
Še bistveno kasneje se doda oddaljeni dostop za upravljanje in vzdrževanje.
Slabosti časovnega zamika izdelave GUI
Optimizacija procesa razvoja naprave tako, da se izdelava GUI načrtuje kasneje, ko osnovne funkcionalnosti naprave že delujejo, ima slabosti. Komunikacija med specialisti je običajno slaba. Večji ko je časovni zamik med izdelavo naprave in izdelavo GUI, več pomembnih informacij se izgubi. Tako izdelan GUI je pomanjkljiv. Skriti problem se odkrijejo na koncu projekta, reševanje teh problemov je težko, potreben je nov razvojni cikel na GUI in na ugnezdenem mikrokontrolerju. Podrobna analiza skritih napak razkrije pomanjkljivo razumevanje delovanja naprave s strani GUI specialista. GUI specialist lahko celo prepriča marketinško ekipo in vodstvo glede funkcionalnosti naprave, ki pa jo sama naprava ne more izvesti. Posledično dobimo izdelek, ki je estetsko dovršen, vendar je grafični uporabniški vmesnik bolj prilagojen trženju kot dejanski funkcionalnosti naprave.
SW arhitektura naprave
Zgoraj sem kratko opisal optimizacije virov.
HW arhitektura naprave: ugnezdeni mikrokontroler za napravo in ločen PC za GUI.
Specializacija razvijalcev: prvi dela na mikrokontrolerju, drugi na PC.
Časovni proces: najprej se programira funkcionalnosti naprave, kasneje se izdela GUI.
Spodaj bom pa opisal različne programske arhitekture.
PC nadzoruje celotno napravo
Ko arhitekt celotne naprave uporabi vgrajen PC za krmiljenje naprave, običajno ne pride do večjih težav. Razvijalec oblikuje programsko arhitekturo za posamezne funkcionalnosti naprave in vzporedno ustvarja uporabniški vmesnik (GUI). Programer se v zgodnji fazi razvoja pri postavljanju elementov (WIDGETS) ne obremenjuje z grafično podobo ali uporabniško izkušnjo (user experience). Prvi GUI ima predvsem funkcionalni namen in bo deloval pravilno v vseh podrobnostih. Kasneje se pri dodelavi GUI vključijo tudi grafični oblikovalci in testni uporabniki. Tako GUI in funkcionalnost nastajata istočasno, pri čemer za oboje v vseh ciklih razvoja skrbi isti specialist, kar je ključnega pomena za uspeh projekta. Neizkušenost vodje projekta nikoli ne povzroči problematične optimizacije projekta na način, da se najprej razvije funkcionalnost naprave ter kasneje GUI. Tudi časovni pritiski za hitro zaključevanje zastavljenih ciljev ne vplivajo na kakovost ter ne povzročajo nepotrebnih dodatnih razvojnih ciklov za reševanje problemov.
Takšna SW arhitektura izgleda odlična, a ima svoje slabosti. Embedded PC je običajno zelo zmogljiv, vendar ni zasnovan za krmiljenje kompleksnih naprav v realnem času. Mikrokontrolerji ter RTOS operacijski sistemi na mikrokontrolerjih so zasnovani za hitro obdelavo procesov na spodnjem HW nivoju in s tem primernejši za krmiljenje kompleksnih naprav.
Ugnezdeni PC zmore odzivne čase reda 100 ms, kar je nekje tudi meja človekove zaznave na primer na GUI. Če želimo z ugnezdenem PC krmiliti procese z zanesljivim odzivnim časom reda 10mS, se moramo že pošteno potruditi ter poseči po sistemskih delih programske opreme. Za doseganje odzivnih časov pod 10mS pa je potreben večji poseg v operacijski sistem ali pa kombinacija mikrokontrolerja in računalnika.
Na začetku sem omenil, da se kompleksne naloge razgradijo na več manj kompleksnih podprocesov. Če je na napravi mogoče posamezne funkcionalnosti razdeliti na zaključene in neodvisne celote, lahko te zaključene dele dalje delimo na procese, kjer se ne zahteva hiter odzivni čas ter procese, kjer je odzivni čas ključnega pomena. Tako lahko PC krmili vse počasne procese, mikrokontroler pa izvede posamezne zaključene procese v realnem času. Programski sklopi na ugnezdenem mikrokontrolerju in komunikacijski protokol proti PC delujejo kot HW driver-ji. Mikrokontroler prevzame funkcionalnost HW aktuatorjev. Tak način dela ohranja zgoraj omenjeno kakovost, ter omejuje tveganja za probleme le na ločeno obravnavane hitre procese ter pripadajoč komunikacijski protokol.
Mikrokontroler nadzoruje napravo, PC pa GUI
Enostavnejše naprave predvsem pa starejše naprave so bile brez GUI. Za upravljanje naprav preko stikal, tipk in potenciometrov ter prikaz na preproste svetlobne prikazovalnike je primernejši in cenejši mikrokontroler. Mikrokontrolerji so se razvijali in so lahko krmilili tudi kompleksnejše naprave. Te naprave so se kasneje posodabljale. Mehanske gumbe ter preproste svetlobne prikazovalnike je zamenjal sodoben GUI na PC.
Posodobitev starejše naprave z dodajanjem sodobnega GUI ni preprosta. Poseg v jedro programske arhitekture je zahteven in s tem dolgotrajen ter tvegan.Enostavneje je, če pustimo polen nadzor nad napravo staremu mikrokontrolerju in ugnezdenem programerju ter dodamo ugnezdenem PC v funkciji GUI.Uspešno nadgrajena HW arhitektura pa še ne pomeni, da bo programska arhitektura ter novonastala organizacija razvoja brez problemov.
Programer mikrokontrolerja na napravi je preobremenjen, da bi se poleg svojega dela lotil spoznavanja programskih okolij na ugnezdenem PC ter naredil GUI. Pri načrtovanju se vodje razvoja, zaradi slabega poznavanja tehnologij, omejujejo na samo funkcionalnost naprave in funkcionalnost GUI. Zelo pomemben načrt komunikacijskega protokola se odlaga in kasneje protokol nastane ob delu.
Razvojni ekipi se pridruži mlajši PC specialist, ki nima izkušenj na funkcionalnostih naprave, nima dovolj podatkov in nima načrta komunikacijskega protokola. Okoliščine so primerne za odlaganje integracije GUI in mikrokontrolerja v celoto. GUI specialist bo optimiziral svoj čas na način, da se bo posvetil grafični podobi ter komunikaciji z vodjem in ključnimi kupci.
Kasnejši razvoj GUI, neizkušenost programerja in pomanjkljive informacije so vzrok za napake v SW arhitekturi ter posledično prepozno odkrite probleme, več ciklov razvoja in s tem velike kasnitve na projektu. Programerju GUI je enostavneje kreirati svoj kontrolni proces, kot pa prevzeti reševanje problemov celotne SW arhitekture na napravi.
Enotna MVC arhitektura
MVC (Model-View-Controller) arhitektura je pristop pri oblikovanju programske opreme za izdelavo GUI. Pri tem pristopu se aplikacija deli na tri glavne komponente. Model opisuje podatkovno sliko naprave, View opisuje prikaz stanja naprave uporabniku, Krmilnik pa obdeluje zahtevane spremembe. Na PC nivoju je teorija znana in lepo razdelana. Kako pa bi MVC uporabili na naši arhitekturi naprave, pa je malo zapisanega.
Programer, ki na PC krmili celotno napravo (GUI in HW) to teorijo običajno pozna. Enako velja tudi za programerja, ki mora izdelati na napravi samo GUI. Embedded programer pa je do nadgradnje naprave z modernim GUI uspešno programiral ter intuitivno rešil vse težave ter na ta način zadovoljivo upošteval MVC teorijo.
V zgoraj opisanih okoliščinah, ko ugnezden mikrokontroler nadzoruje napravo, GUI pa se naredi na PC, ter pomanjkanju celostnega pristopa k načrtovanju SW arhitekture, običajno na napravi nastaneta dve ločeni MVC, kar pomeni dva običajno nekoliko različna kontrolna procesa, dva nekoliko različna podatkovna modela, in dva različna prikaza stanj uporabniku. Na ugnezdenem mikrokontrolerju je običajno prikaz (View) narejen z UART konzolo.
Pristop izgradnje dveh ločenih MVC arhitektur na napravi v sam SW vnaša nepotrebno kompleksnost. Način usklajevanja različnih kontrolnih procesov in ločenih podatkovnih modelov na izdelanih projektih lepo pokaže zapleten komunikacijski protokol. Protokol definira način povezovanja dveh MVC. Če bi se ta protokol skrbno načrtovali v zgodnih fazah razvoja naprave, bi bilo kasneje problemov manj, ker bi opis tega protokola že vseboval ključne informacije za razvoj obeh MVC. Slika zgoraj (enotna MVC arhitektura) lepo pokaže, da ima kontrolni proces nadzor nad uporabniškim vmesnikom in nad podatki. Če GUI in podatke v ločeni arhitekturi upravlja PC, glavni kontrolni proces pa mikrokontroler, se protokol med mikrokontrolerjem in PC podvoji. Kompleksen protokol vabi PC programerja k poenostavljanju na napačen način: delovanje mimo mikrokontrolerja.
Analiza problemov podvojene MVC ter na drugi strani skrbna optimizacija celotnega razvojnega procesa pokažeta, da za podvajanje MVC arhitekture ni razloga. Pomembno je, da ima naprava enoten kontrolni algoritem. Za prikaz (View) ni dvomov, kdo ga naredi. Tudi za podatke velja, če jih hranimo na enem mestu, s tem poenostavimo komunikacijski protokol in kontrolni proces. En MVC za celotno napravo je primernejša rešitev. Naj povzamem:
Če PC poganja celotno napravo, to je GUI in posamezne HW aktuatorje v napravi, bo razvoj tekel z enotno MVC arhitekturo brez večjih težav.
Pri napravah, kjer mikrokontroler hrani podatke in kontrolira celotno funkcionalnost je običajna praksa podvajanje MVC arhitekture, kar zahteva veliko virov. Tveganje za probleme je večje.
Zgodnje načrtovanje komunikacijskega protokola je pomemben segment in odraža celotno SW arhitekturo naprave.
Priporočljiva je enotna MVC arhitektura za celotno napravo.
GUI-O in enotna MVC arhitektura
Kompleksnost naprave in seveda uspešen razvoj predhodnih verzij naprave na mikrokontrolerjih ima za posledico ohranjanje kontrolne funkcije na mikrokontrolerju. Zgoraj sem že omenil, da SW arhitekturo naprave odraža načrt komunikacijskega protokola. Omenil sem tudi, da je specialistu, ki programira GUI, enostavnejši fokus v design in uporabniško prijaznost kot detajlno poznavanje funkcionalnosti naprave. S postopnim reševanjem problemov ter optimizacijo razvojnega procesa na koncu dosežemo enotno MVC arhitekturo. GUI izvaja samo View funkcionalnost. Spremembe v procesu so opisane spodaj:
GUI specialist s programom ter izvedbo (View) dosledno izvaja ukaze ugnezdenega mikrokontrolerja.
Ob razvoju posameznih funkcionalnosti GUI specialist dobi podatke o kreiranju ekranov: katere elemente uporabiti, kam jih postavi, kakšno je začetno stanje, kakšen je obseg vrednosti. Seveda se načrtuje ustrezen ukaz za kreiranje ekrana v komunikacijski protokol.
Kasneje se izkaže, da se na istem ekranu začetna stanja in ostali parametri spremenijo. Logično je, da se tudi ti parametri proti GUI pošiljajo skupaj z ukazom za kreiranje ekrana in tudi ob vsaki spremembi posameznega parametra.
Optimizacija dela GUI specialista gre v smer: Če embedded programer preko protokola proti GUI pošlje več podatkov, ter jih GUI specialist interpretira ter izvede z istimi programskimi sklopi, deluje GUI pravilno. Na ta način se GUI specialist razbremeni. Ne potrebuje več podrobnega poznavanja celotne funkcionalnosti naprave. GUI specialist se lahko posveti grafični podobi elementov ter specialnim efektom, ki niso povezani z kontrolo same naprave.
Ko se na ta način izvaja drugi in tretji projekt, je logična optimizacija dalje: sistematično in relativno enostavno GUI-O specialist v komunikacijski protokol doda parametre za vse projektne specifike. Tako je na strani GUI en program za več projektov. GUI specialist pridobi čas, da tehnološko ne zaostaja. Zamenja tehnologijo na najučinkovitejšo ter ob tem močno dvigne kakovost. Glede na klasičen GUI program je tu nekoliko obširnejši interpreter ukazov za nekoliko obširnejši komunikacijski protokol. S skrbnim načrtovanjem interpreter porabi manjši del procesorskega časa.
Tako je nastal GUI-O, ki pokaže sledeče prednosti:
Učinkoviteje je, če isti razvijalec, programer mikrokontrolerja, razvija funkcionalnost naprave in krmili GUI. Napak je manj, če se istočasno in z istimi procesi krmili naprava in GUI.
GUI-O ASCII protokol ima vgrajeno dosledno uporabo arhitekture Model-View-Controller (MVC). Tako ni več potrebe po kompleksnem načrtovanju komunikacijskega protokola, ker je ta narejen.
Razvoj GUI na klasičen način ter s tem povezan vložek specialista ni več potreben. Vzamemo najboljši GUI program ,iz police‘ in ga uporabimo. Kreiranje inicializacijskih stringov na posameznem projektu z lahkoto (sproti ob delu – mimogrede) naredi ugnezdenem programer.
Programer ugnezdenem mikrokontrolerja porabi manj časa, da se seznani z GUI-O protokolom ter naredi osnovni GUI in kasneje doda vse grafične predloge, kot pa da za GUI specialista definira in zapiše komunikacijski protokol za konkreten projekt.
Sodelovanje z grafičnim oblikovalcem ter sodelovanje z marketingom oziroma ključnimi kupci se prenese iz GUI specialista na ugnezdenem programerja. Grafične predloge so potrebne tudi pri GUI-O rešitvi. Vloga omenjenih sodelujočih se ne spreminja.