|
![](images/biljka.jpg)
OPIS PROJEKTA
UVOD U UGRADBENE MREŽNE POSLUŽITELJE
JAVA U UGRADBENIM MREŽNIM POSLUŽITELJIMA
TINI - Tiny InterNet Interface
FESB-ovi UGRADBENI WEB REGULATORI
(EWC - Embeded Web Controllers)
FESB - EWC M&C
FESB - EWC M
|
Java u ugradbenim mrežnim poslužiteljima
Zbog svoje brzine, sažetosti koda i detaljnog upravljanja hardverom C i asembler su bili najbolji izbor za programiranje klasičnih ugradbenih sistema. Razvojem i većom upotrebljivošću Interneta i općenito mrežne komunikacije između uređaja širi se i pojam ugradbenih sistema. Za ugradbene sisteme koji koriste mrežnu komunikaciju Java se sve više nameće kao izbor višeg programskog jezika, bilo u suradnji s tradicionalnim kodom ili kao jedini korišteni programski jezik.
Java je nastala razvojem iz programskih jezika C i C++ kao želja programera da uklone uočene nedostatke tih jezika, naročito u pogledu sigurnosti, prenosivosti softvera i jednostavnije mogućnosti istovremenog izvršavanja više programskih niti.
Za razliku od ostalih viših jezika kod kojih je prenosiv izvorni kod programa kojeg je zatim bilo potrebno kompilirati za određenu platformu na kojoj će se izvršavati, kod Jave je prenosiva izvršna verzija programa, tj. izvorni se kod prevodi u izvršni “virtualni” kod koji se zatim interpretira jednako na svim platformama. Jedini uvjet koji takav izvršni kod postavlja je da na ciljanoj platformi postoji interpreter za Javu i operativni sustav daje podršku za višenitnost, organizaciju podataka, prikaz i slično. Ovakav pristup omogućava i jednostavno slanje programa preko mreže bez obzira na krajnji uređaj. Ovakva distribucija i prenosivost je moguća i kod ostalih viših jezika, ali u tom slučaju bi krajnji uređaji morali biti sposobni pokretati složene prevoditelje što komplicira i poskupljuje same uređaje.
Java ima ugradbenu podršku za istovremeno izvođenje više programskih niti bilo dijeljenjem vremena jednog procesora ili paralelnim računanjem na više procesora. Prenošenjem rješavanja tog problema sa operativnog sustava na izvorni kod programa izbjegavaju se različitosti operativnih sustava koje bi mogle ometati rad programa i osigurava se neovisnost programa o operativnom sustavu. Operativni sustav je i dalje potreban, ali su postupci standardizirani na nivou izvornog koda programa.
Arhitektura Java platforme
Arhitektura Java platforme se dijeli na pet osnovnih dijelova, kao na slici 3:
Kod: JAR datoteka koja sadržava programski kod.
Java klase: Java API paket klasa dobivenih sa JVM. Pri pisanju Java programa pozivaju se API iz ovog paketa. Većina funkcija iz ovog paketa je pisana u samoj Javi, ali se neki dijelovi oslanjaju na biblioteke pisane u strojnom kodu .
Strojni kod: Biblioteke pisane u strojnom kodu koje se pozivaju iz Java koda u klasama, ovaj sloj postoji paralelno sa JVM i RTOS (Real Time Operating System).
Platforma: JVM koji učitava i izvršava Java klase iz memorije. JVM koristi podršku RTOS za upravljanje operacijama iz Java programa.
Hardver: Kompletan hardver, upravljan RTOS-om. RTOS rješava potrebe JVM i upravlja rasporedom izvršavanja.
Slika 3. Arhitektura Java platforme
JVM ovisi o operativnom sustavu (RTOS) koji pruža hardverski specifičnu podršku za izvršavanje Java programa. To uključuje višenitnost, upravljanje memorijom i izvršenje strojnog koda.
Da bi se odredilo kakvu platformu koristiti, potrebno je zbrojiti zahtjeve JVM, Java API paketa, Java programa i pripadajućih biblioteka u strojnom kodu.
Java API
Kako su Java API paketi prilično veliki, razvijena su četiri odvojena paketa API-ja za različite dijelove tržišta:
Java Development Kit namijenjen je osobnim računalima i sadrži čitavu Java korisničku okolinu;
Personal Java (Java Applet Environment) namijenjen je uređajima kojima je potreban GUI i sposobnost izvršavanja apleta;
Embedded Java namijenjena je donjem dijelu tržišta Java uređaja, naročito onima koji nemaju univerzalni uređaj za prikaz (odnosi se na java.awt). Korisnici mogu prilagoditi Java platformu prema svojim potrebama;
Java Card se koristi kod uređaja vrlo ograničenih sposobnosti kao što su npr. pametne kartice. Najčešće je dovoljna podrška samo za java.lang paket i pakete za kodiranje (enkripciju).
Ovi API predstavljaju manje skupove dovoljne za rad u nekom području, a nastali su eliminiranjem suvišnih API-ja za pojedino područje interesa. Razvijeni su tako da budu kompatibilni prema gore, tj. Embedded Java programi se mogu izvršavati na Personal Javi, ali ne i obratno. U tablici 1. prikazani su hardverski zahtjevi pojedinih API-ja bez ostalih zahtjeva sistema (kako ih definira JavaSoft).
Tablica 1. Hardverski zahtjevi pojedinih API-ja bez ostalih zahtjeva sistema
(kako ih definira JavaSoft).
![](images/sl4.gif)
Vrlo malo ugradbenih sistema koristi sve API-je, dovoljan je samo manji, prilagođeni skup. U tablici 2. prikazana je analiza JDK 1.1.4. paketa klasa i prikaz zahtjeva Personal Jave i Embedded Jave za pojedinim paketom.
Tablica 2. Analiza JDK 1.1.4. paketa klasa i prikaz zahtjeva Personal Jave i Embedded Jave za pojedinim paketom.
![](images/sl5.gif)
Potrebno je naglasiti da su vrijednosti dane za JDK 1.1.4. i da sa daljnjim poboljšanjima paketa treba očekivati i njihov rast.
Postoje dva načina smanjivanja paketa klasa. Statička metoda analizira kod programa i na osnovu toga kompilira pozvane klase i pakete. Na temelju liste kompiliranih može se ukloniti nekorištene klase i pakete. Ova metoda je brza, ali podložna greškama u slučaju klasa koje se ne pozivaju direktno iz izvornog koda. Dinamička metoda zahtijeva pokretanje programa i stvaranje popisa klasa koje program poziva. Na ovaj način se dobije točniji popis pozvanih klasa jer su zabilježene i klase koje se pozivaju iz drugih izvora npr. mreže. Kombiniranjem statičke i dinamičke metode može se napraviti sažeti popis zahtjeva za pojedini program.
Java u primjeni
Praktična primjena Jave kod ugradbenih mrežnih servera uveliko ovisi o razumijevanju i pažljivom odabiru kompromisa između memorijskog otiska, performansi i prilagodljivosti.
Relativno veliki utrošak memorije na Java Virtual Machine, podršku u strojnom kodu i biblioteke klasa se isplaćuje kroz sažetost koda Java aplikacije. Broj aplikacija, njihova složenost, kao i to da li se učitavaju s brzog (npr. disk jedinica) ili sporog uređaja (npr. modem) ili su rezidentne u ROM-u glavni su faktori pri odluci da li koristiti Javu. Prednosti Jave naročito dolaze do izražaja kod sistema s većim brojem aplikacija zbog dinamičkog vezivanja na standardne biblioteke i kod složenih aplikacija zbog veće gustoće koda.
Tri su osnovna učinka Jave na memorijski otisak:
zahtjevi Jave za RAM-om su obično veći od zahtjeva jednake aplikacije pisane u strojnom kodu,
Java štedi ROM u sistemima s više srednje velikih aplikacija i u sistemima sa složenim aplikacijama,
Java aplikacije su manje od aplikacija u strojnom kodu, pa su pogodnije kad se učitavaju kroz spori kanal kao što je bežična ili dial-up veza.
Performanse se mogu podijeliti u dvije osnovne kategorije: prosječna brzina i determinizam. Neovisnost Jave o platformi se postiže kombinacijom Java klasa i JVM-a. Klase nastaju prevođenjem izvornog koda Jave u bajt-kod koji se zatim može izvršavati na bilo kojoj Java platformi. Na uređaju se Java bajt-kod izvršava pomoću interpreterske petlje JVM-a. Interpreterska petlja prevodi Java bajt-kod u odgovarajuće funkcije strojnog koda za vrijeme izvršavanja programa. Java bajt-kod se izvršava sporije od aplikacija u strojnom kodu jer se optimizacija koda ne može provoditi u realnom vremenu, a i prevođenje je zahtjevan proces. Ovo usporenje u odnosu na strojni kod je zanemarivo kod manjih aplikacija dok kod složenijih može predstavljati značajan problem, pa se često vremenski kritični dijelovi aplikacije pišu u strojnom kodu kako bi se ubrzalo izvođenje programa.
Determinizam kao sposobnost obavljanja zadatka unutar određenog vremena predstavlja problem programerima ugradbenih sustava kod kojih je to vrijeme reda veličine desetak milisekundi. Naime, mehanizam oslobađanja neiskorištene memorije Java Garbage Collector nije deterministički proces i može prouzročiti zastoje u radu programa koji ovisno o procesoru, količini memorije i algoritmu mogu potrajati i do 100-tinjak milisekundi. Proces oslobađanja neiskorištene memorije se može ubrzati korištenjem bržeg procesora, boljeg algoritma ili pažljivim programiranjem aplikacije, ali uglavnom se radi što veće brzine ne piše u Javi nego u strojnom kodu.
Projektant sustava pri pronalaženju pravog kompromisa između brzine i veličine treba voditi računa i o trećem činitelju: prilagodljivosti. Mogućnost izvršavanja istog koda na različitim platformama na prvi pogled nije toliko bitna kad se radi o ugradbenim sustavima jer je platforma najčešće unaprijed točno određena. Java dolazi do izražaja tamo gdje platforma nije točno zadana ili je podložna promjenama. Najbolji primjer za to su mrežno orijentirani i distribuirani sustavi kada je važno da i dijelovi sustava rađeni na različitim osnovama mogu koristiti iste programe. Osim toga, prilikom unapređenja sustava značajno je da se nadogradnja softvera može ostvariti koristeći istu osnovu bez obzira na to kakva je promjena napravljena u hardveru, a time je pojednostavljeno i održavanje softvera.
Ubrzavanje Jave
Java se može ubrzati na sljedeće načine:
Java kompileri - ovaj način je sličan standardnim kompilerskim tehnikama koje se koriste i kod drugih jezika. Prednosti su podizanje performansi kompiliranjem u strojni kod i smanjenje zauzeća memorije od strane JVM-a koji ipak nije u potpunosti izbačen jer Java i dalje ovisi o procesu uklanjanja suvišnih podataka iz memorije (Garbage Collector) i višenitnosti. Također je omogućeno zajedničko korištenje koda pisanog u Javi, C-u, i C++-u. S druge strane, prevođenjem u strojni kod gube se prednosti Jave kao dinamičke platforme;
JIT (Just In Time) kompiler - kompilira Java bajt-kod u strojni kod pri učitavanju i sprema rezultate kompiliranja u RAM. Pri ponovljenom pozivu neke metode bit će izvršen strojni kod. To znači da je pri prvom pozivu neke metode izvršavanje nešto sporije nego kod klasičnog bajt-kod interpretera, a nakon toga je 5 do 10 puta brže. Moglo bi se postići i još veće ubrzanje ali JIT mora balansirati između stvaranja brzog koda i brzog stvaranja koda. Dakle, JIT je nešto poput interpretera koji snima rezultate svoga rada. JIT troši oko 100 Kb ROM-a i zahtijeva RAM međuspremnik za spremanje kompiliranog koda čija veličina ovisi o veličini aplikacije;
Java optimizirani procesori - budući da se Java zasniva na stogu (stack-based), procesori koji imaju bolje optimizirane operacije sa stogom će izvršavati Java programe brže od drugih. Razvijen je niz procesora optimiziranih upravo za Javu, s ciljem izrade procesora koji će davati dovoljno poboljšanje performansi da bi se opravdala njihova upotreba. Set naredbi strojnog jezika ovih procesora jednak je onome što ga generira Java bajt-kod kompiler i time zamjenjuje JVM interpreter petlju. Budući su ovi čipovi razvijani isključivo za ubrzavanje Java bajt-koda, dijelovi aplikacije pisani u C-u ili C++-u moraju biti prevedeni u Java bajt-kod;
ROMizeri - JVM koristi RAM za dvije namjene: spremanje Java objekata (Java Heap) i izvršenje Java bajt-koda (Java Memory Pool). Pri izvršavanju Java aplikacije JVM kopira bajt-kod iz ROM-a (ili nekog drugog spremišta) u RAM, a zatim u RAM pohranjuje i izvršnu verziju klase. Ovakav način korištenja memorije može vrlo brzo potrošiti memoriju ugradbenog sistema što dovodi do smanjenja performansi. Ovakva ovisnost o RAM-u predstavlja problem za ugradbene sustave koji su okrenuti korištenju ROM-a zbog nižih troškova. U svrhu rješavanja tog problema su razvijeni ROMizeri. Oni prekompiliraju Java klase i omogućuju izvršenje tih klasa direktno iz ROM-a, te uklanjaju potrebu za kopiranjem klase u RAM čime se postiže ubrzanje sistema i značajna ušteda memorije.
|
TINI - Tiny InterNet Interface
| |