Java i inbyggda system gör applikationsutveckling
billigare
Jonas Jonsson utvecklare Data Respons AB
Vad har hänt med Java? För några år sedan, före IT-bubblans kulmen, talade många
varmt om Java och plattformsoberoende. Trots att intresset svalnat något har en del
hänt till dags dato. Det finns flera implementeringar och leverantörer av Virtuella
Javamaskiner JVM (Java Virtual Machine) som även anpassats för inbyggda system.
Målet och visionen med Java är, och har varit, att skapa plattformsoberoende. Genom
att låta en programvara arbeta som en virtuell processor på hårdvaruprocessorn kan
plattformar, med olika arkitektur, köra samma applikation, förutsatt att en JVM finns
för plattformen.
Målet och visionen med Java har gjort att många lärt sig språket. Väl spridda
kunskaper av programmering i ett språk bidrar till att öka efterfrågan av möjligheten
att programmera även inbyggda system i det aktuella språket. Idag byggs dessutom
allt större och mer komplexa system där olika hårdvaruarkitekturer ansluts.
Utveckling av nya produkter har länge krävt
bakåtkompabilitet. När större system med
hårdvaruarkitekturer från olika leverantörer och av
olika arkitektur sätts samman, växer behovet av att
underlätta bakåtkompabilitet i framtiden. De system
som ligger på ritbordet konstrueras för att ha
möjlighet att inkludera andra hårdvaruarkitekturer i
framtiden och därigenom uppfylla framtida behov.
Application
Java VM (JVM)
Native Interface (NI)
Application Programming
Interface API
Problem som uppstår när systemen blir större och
Realtids OS RTOS
olika komponenter integreras är att antalet
mjukvaror och mjukvaruversioner riskerar att växa
Emb. Hardware
till ett svårhanterbart antal.Även små förändringar i
välskriven C-kod som använder maskinspecifika
definitioner konsekvent orsakar mycket arbete när
Figur 1 Den virtuella maskinen
placeras mellan API och
ändringar måste göras på flera ställen i olika
applikation för att göra
källkoder.
applikationen mindre beroende
Därefter följs ändringarna av kompileringar och
av hårdvaran.
uppdatering av applikationer för varje enskilld
hårdvaruarkitektur. Om samtliga embedded system
istället använder samma Java källkod för de uppgifter som är gemensamma, t.ex
kommunikation, protokollhantering och textbehandling/parsning, underlättas
förfarandet eftersom applikationen är generell och endast finns i en version som ej
behöver kompileras gentemot varje system. Med en JVM och ett NI (Native Interface)
görs hårdvaran åtkomlig på ett generellt sätt. Genom ett generellt beteende för all
hårdvara kan samtliga komponenter exekvera samma applikationer. När endast en
generell applikation behöver underhållas förenklas administrationen av komplexa
system. Därtill minskas beroendet av enskilda leverantörer genom att mjukvaran blir
fristående från hårdvaran.
Ytterligare fördelar med att implementera JVM är att de nackdelar som följer när en
kund skall motiveras att köpa utvecklingsmiljöer för specifika RTOS (Real-Time
Operating System) undviks. I vissa fall är kostnaden för dessa hög i förhållande till
den produkt som skall säljas. Det krävs varken ekonomi- eller psykologiexamen för
att förstå svårigheten att motivera en produkt för en kund som själv vill utveckla
applikationer när konstnaden för utvecklingsverktygen är betydande. Framförallt vid
små volymer och produkter med lågt pris förskjuts prisbilden, utslaget per enhet,
kraftigt. Till denna direkta kostnad kommer i många fall en utbildnings- och
uppstartsperiod av nya utvecklingsmiljöer innan applikationsutvecklingen kan ta fart.
För utveckling i Java finns en ett större antal alternativa utvecklingsverktyg som
utvecklas snabbare i förhållande till de specifika verktygen för enskillda RTOS.
Vilka frågeställningar är det som väcks vid implementation av en JVM? Två centrala
aspekterna vid implementation av en JVM i inbyggda
Javainstruktion
system är, exekveringshastigheten kontra realtidskrav och
begränsningar i minneskapacitet. I standarden för Java
Bytekoder
kompileras källkoden till bytekoder. Bytekoderna tolkas
och länkning (dvs klassladdning) sker under körning, av
C instruktioner
den virtuella maskinen som i sig är ett program som
agerar som en processor. Härigenom kommer exekvering
Operationskoder
av en enskild Javainstruktion att kräva exekvering av en
mängd operationskoder.
Figur 2 Effektivitet vi exekvering
J2M
E
AP
PD
JGP
...
J2E
E
J2SE
CDC
DC
CL
Sun har lett arbetet vid framtagningen av Java. Med
tiden har Sun delat in Java teknologin i flera delar för
att passa olika typer av plattformar med olika resurser.
Den första delningen utgörs av
• J2EE - Java2 Enterprise Edition avsedd för
server och finansiella applikationer.
• J2SE - Java2 Standard Edition primärt avsedd
för webutveckling
• J2ME - Java2 Micro Edition avsedd för
inbyggda system.
Micro Edition är i sin tur indelad i CLDC - Connected
Limited Device Configuration och CDC - Connected
Limited Device Configuration. För anpassning mot de
minsta systemen har CLDC indelats i ytterligare
profiler bl.a. mot mobila informationsenheter och
handdatorer.
M
ID
P
av Javaapplikationer.
Det andra problemet som uppkommer med begränsningar
i minneskapacitet består i ambitionen att göra Java
flexibelt ”-Write Once Run Anywhere, WORA”. Konceptet WORA kräver minne
eftersom klasser, även om att de aldrig används, finns permanent i minnet för att, vid
behov kunna, anropas under exekvering. För att lösa dessa problem finns framförallt
två ansatser och dessa tillämpas av olika leverantörer.
Figur 3 Indelning av Java teknologi
från Sun
För att öka exekveringshastigheten kan Java koden kompileras till exekverbar
maskinkod. Denna kompilerade lösning erbjuds bl.a. med CEE-J från USA baserade
Skelmir. Genom att bygga applikationen före nedladdning går det att undvika att icke
använda klasser laddas ner och förbrukar minneskapacitet. Detta kan vara att föredra
om minneskrav är en central aspekt bl.a. finns SimpleRTJ från den Australiensiske
leverantören RTJ Computing. Utöver detta erbjuds även kombinationer av de två
åtgärderna för att höja prestandan från bl.a. Schweiziska Esmertec i form av Jbed och
Fast-J från WindRiver.
Memory usage:
Linking
Compile
Interpret
Run-time
Execution speed:
Tyvärr innebär, som oftast, fördelar ur en synvinkel
nackdelar i en annan. När implementation av JVM
görs på system med väsentligt begränsade resurser
och specifik I/O i jämförelse med en desktop PC
kan detta innebära behov, eller krav, att frångå en
komplett implementation. Priset för att öka
exekveringshastigheten eller minska minnesbehovet
medför ofta avsteg från Java standard. Om länkning
sker före nerladdning blir det ej möjligt att ladda
generella Java klasser. Det blir inte heller möjligt att
exekvera generella bytekoder om kompilering sker
till operationskod för att öka
exekveringshastigheten.
Sun
Build-time
SimpleRTJ
Skelmir
Skelmir
Esmertec
Fast-J
Figur 4 Leverantörers anpassningar
mot inbyggda system
I vissa sammanhang kan det även vara acceptabelt att förbättra den ena av
minnesbehov och exekveringshastighet på bekostnad av den andra men med fullt Java
stöd. En metod som används för detta är JIT kompilering (Just In Time). JIT innebär
att klasserna kompileras till maskinkod, på målsystemet, när de laddas. Detta ökar
exekveringshastigheten och närmar sig i detta hänseende Java kod som kompilerats
till maskinkod. Det krävs dock en kompilator som exekverar på målsystemet vilket
ökar behovet av minne och minskar exekveringshastigheten vid första exekveringen
av en klass, å andra sidan bibehålles möjlighet till dynamisk klassladdning.
Data Respons har med relativt små ansträngningar genomfört en portning av
SimpleRTJ från RTJ Computing, som ett examensarbete vid KTH-Syd. SimpleRTJ är
förmodligen den lösning som kan köras med minst krav på hårdvaran i fråga om
processor och minne. Alternativet är relativt billigt med licensavgift från US$3000 +
royalty, vilket kan jämföras med andra alternativ från 500 000 SEK och uppåt. Låga
avgifter beror till stor del på att leverantören själv inte har som ambition att
genomföra portningen. Av detta följer endast generellt Javastöd och ej stöd som
kräver anpassning gentemot specifik hårdvara. I inbyggda sammanhang finns ej, i alla
tillämpningar, behov för stöd av t.ex. GUI (Graphic User Interface). Ett exempel på
detta är Data Respons produkt RIO*
(Remote Input Output), mot vilken
portningen gjorts, där avsaknad av GUI inte
utgör någon begränsning eftersom grafiska
enheter saknas. Möjlighet finns dock att
själv skapa detta om behov uppkommer i
framtiden.
Data Respons har även hållit
aftonseminarium med titeln ”Java och
inbyggda system” vid det nyöppnade
kontoret i Göteborg. Detta seminarium
planeras även att hållas i Stockholm under
september.
Källförteckning
http://java.sun.com
http://www.esmertec.com
http://www.skelmir.com
http://www.rtjcom.com
*
RIO GSM är en produkt för M2M
applikationer. Den har flera
kommunikaitonsmöjligheter t.ex.
analog input, digital I/O, RS232/485
Därtil finns tillval såsom GSM modul
och bluetooth. Bredden av
kommunikationsmöjligheter gör RIO
användbar vid fjärrövervakning och
fjärrstyrning
