Hidoors wil drijvende motor achter embedded Java worden

Steeds meer toepassingen van computers zijn 'embedded'; toepassingen waarin een systeem met een bepaald doel in een product is verwerkt. Een consortium van bedrijven probeert onder de naam Hidoors, dat staat voor High Integrity Distributed Object-Oriented Realtime Systems, Java geschikt te maken voor real-time en embedded toepassingen, zo lezen we bij IST Results. Het project probeert, met steun van de Europese Unie, een oplossing te vinden voor vier belangrijke problemen die het gebruik van Java van in embedded systemen in de weg staan. Om de veiligheid van de systemen te kunnen garanderen moeten bijvoorbeeld de manier van geheugen- en netwerkgebruik exact te voorspellen zijn. Ook moet Java bruikbaar zijn op systemen met beperkte rekenkracht.

Het onderzoek van Hidoors heeft voor één van de deelnemende bedrijven al tot een commercieel succes geleid. Aicas heeft sinds het begin van het project een omzetgroei van 30 procent weten te bewerkstelligen, omdat het tot op heden het enige bedrijf is dat de Real-time Specification voor Java ondersteunt. Vooral voor de toepassing in industriële robotten en auto's is Java geschikt. Dit vanwege de flexibiliteit die object-georiënteerd programmeren biedt en de kleinere kans op fouten. In bijvoorbeeld auto's kan dit gemak leiden tot meer mogelijkheden om de auto naar persoonlijke wensen in te stellen, zonder grote angst voor onveiligheden.

Reacties (30)

[Boudewijn]

hmm java realtime krijgen , dat lijkt me lastig. Om de volgende redenen:

- Java heeft die VM, dat is altijd overhead. zeker met mem+cpu en de realtime aspecten
- Het is geen OSS. Hoe willen ze nu dat netjes doen? Je wilt wss toch wel de zaak stevig aan gaan passen (jre is >10 meg... ken weinig embedded systemen die dat hebben)

Current approaches for the application of Java for realtime and safety-critical applications focus on subsetting the language to a more predictable set of operations. Instead, this project will develop and implement techniques to enable a deterministic implementation of the full Java language. The implementation will support the full bandwidth of modern object-oriented software development for this application domain.

Zo te zien doen ze het vanaf scratch, dat is best veel werk. Ik zou gewoone en GPL java-pakket nemen (blackdown???) en dat aanpassen.

Met aanpassen vooral dit:

This project will focus on improving the memory and runtime performance of the system through the use of new compiler optimization techniques, while maintaining the determinism required for realtime and safety-critical systems.

[Anoniem: 48679]

die >10meg die jij noemt is natuurlijk de java standard runtime die je op je desktop PC installeert met SWING en de hele hutsekluts.

Nu moet je je enkele kleine vraagjes stellen om een antwoord op je eigen vraag te krijgen:
-> heeft een auto, robot, ... een intel processor met windows/linux/... + grafische omgeving?
-> moet de VM softwarematig werken? (er zijn dacht'k chips die bytecode uit kunnen voeren)
-> hebben ze dit hele porting proces dat je voorstelt ook gedaan om je Tetris te kunnen laten spelen op je GSM?


vergeet niet dat JAVA een standaard is met onderandere een (>10 meg) SUN implementatie voor het intel platform. Er is echter héél wat meer dan die implementatie en dat platform....en dus zie ik hier zeker graten in ja.

<ignore>
(leuk, mensen die JAVA amper kennen en direct alles in ASM willen maken...nofi, maar mij zul je nergens horen lullen over ASM/C++. En soms komen die opmerkingen nog doodleuk van een .NET fan ook....)
</ignore>

[Anoniem: 25991]

Dat is waar. Java vereist altijd meer overhead dan c of assembly. In deze talen kan je direct naar byte code compileren. Verder kan je in assembly speciale instructies gebruiken voor het type cpu die de doelgroep vormt, waardoor je dus alles uitermate kan benutten.

However, volgens mij is nu de tijd gekomen dat we helemaal niet meer hoeven te kijken op een megabyte of 10, en zeker niet op cpu power. java draait zelfs op je gsm Dus waarom ook niet in een auto ?

Wat ik mij wel afvraag is dat het nu écht zeker is dat het ook veiliger is. Ok, de code die je in java schrijft is zowizo al safer dan in c/assembly. Verder bestaan er voor java uitstekene test technieken die je code waterdicht kunnen maken.

Maar wat met de VM dan ? ...Die moet ook waterdicht gemaakt worden. Al is je code nog zo goed, als de VM crashed is het nog altijd gedaan....

[farlane]

....However, volgens mij is nu de tijd gekomen dat we helemaal niet meer hoeven te kijken op een megabyte of 10...

Volgens mij ben je niet helemaal thuis in deze markt ofniet? Wat denk je dat de prijs van een controller doet met ipv 4K geheugen 10M geheugen?

[Madcat]

Ik deel je mening, ik prefereer ook C/C++ voor embedded toepassingen.

echter is er wel een embedded java chip op de markt die gebruikt kan worden voor dit soort grapjes.hier is een linkje ( http://www.tweakers.net/nieuws/22271/ )

echter neem ik het net zoals jij niet zo serieus, als iets snel en realtime moet gebeuren dan prog je het zelf en ga je niet zitten debuggen waarom hij soms nu weer een paar miliseconden wacht en soms weer niet. en dan kom je er na een tijdje achter dat al die leuke libaries toch niet zo makkelijk zijn.

[wh1t3 sh4d0w]

kan aan mij liggen... maar volgens mij ben je toch die vm niet nodig op embedded

Maar embedded kan je idd het best in C/C++ doen of gewoon in ASM, dat is toch nog altijd het compactst en dat is toch wel vrij belangrijk op embedded systemen aangezien die meestal zeer beperkt geheugen hebben.

Denk niet dat Java nou erg succesvol zal zijn op dit vlak, al zijn debugging tools natuurlijk wel ongelooflijk handig. een taal kan nog zo goed zijn. Zonder goede debugging tools wordt het niets.

[Sjaaky]

Realtime java is al een tijdje in ontwikkeling. Ik heb op de tud een keer een demo gezien van een bedrijf (ff de naam kwijt) dat bezig was met realtime java. Ze hadden een goed werkende demo bij zich van een laser show.
De galvo's worden aangestuurd dmv realtime java. Bedenk wel dat realtime niet wil zeggen dat iets heel snel moet gebeuren. Realtime wil zeggen dat het moment waarop iets wordt uitgevoerd voorspelbaar is. De setpoints naar de galvo's moeten met constante tussenpozen worden ingesteld. Een garbage collector is dan dus iets wat je niet kunt gebruiken.
Ze hebben een aantal verbeteringen op standaard java:
1) De prioriteit van een realtime thread staat boven die van de garbage collector.
2) De garbage collector is preemptable. Anders zou realtime gedrag nog steeds niet gegarandeerd zijn.

Door deze veranderingen kan een gc geen garbage collecten in de realtime code. Daarom mag deze code geen dynamisch geheugen alloceren. Meestal is dat geen echte beperking. Een relatief kleine statische buffer voor de setpoints is in dit geval genoeg. De threads die niet realtime draaien hebben tijd genoeg om die buffer in de tussentijd aan te vullen.
Je hoeft bij een realtime applicatie meestal maar een klein gedeelte echt realtime te maken. De rest van de code is veel minder kritiek. De realtime code kent beperkingen qua geheugen allocatie etc. Maar de rest van de code kan je in het 'veilige' java programmeren, met alle voordelen van dien. Je hoeft je daar niet druk te maken over geheugenmanagement, je kan er een gui bij klussen, etc.

[constantino]

Niemand lijkt de picoJava te kennen en/of geschiedenis van java.
Java is speciaal ontwikkeld voor embedded toepassingen dus ik veronderstel dat dat wel goed zou moeten lopen.

hier een link:
http://www.webopedia.com/TERM/P/picoJava.html

[TheekAzzaBreek]

Waarom zou je Java nou uitgerekend in embedded systems willen gebruiken? In mijn optiek is de kracht van Java vooral portabiliteit, maar daar moet je wel wat nadelen voor accepteren. En uitgerekend die portabiliteit is geen issue in embedded systeme.

Kortom, ik snap er weer eens niks van. Kan iemand me dit uitleggen?

[Swinnio]

boudewijnTux==bevooroordeeld?
Blijkbaar heb je iets tegen die mensen die je bobo's noemt, maar om daar nu op in te gaan zou te veel off-topic zijn.
Het gaat er in dit project niet om een implementatie te ontwikkelen die C of ASM in de toekomst overbodig gaat maken. Het is een onderzoeksproject dat tot doel heeft te onderzoeken in hoeverre het mogelijk is met behulp van de huidige technieken Java embedded te krijgen. Dat wil niet per definitie zeggen dat dat 1. gaat lukken 2. een direct toepasbaar resultaat oplevert.
Maar dat wil niet zeggen dat het project niet zinvol zou kunnen zijn...

[jesse282]

De toekomst zal leren dat asembly en C ook in de embedded wereld geheel zullen verdwijnen. Het zal domweg te duur worden om te ontwikkeling. Ten twede is het niet mogelijk om secure applicaties te maken in asembly of C. (Tenminste ik heb nog geen techniek gezien die 100% garantie geeft dat je geen buffer fouten in je code hebt zitten).

[GrimaceODespair]

Java is oorspronkelijk net bedoeld voor dit soort doeleinden. Zoek maar eens op Java en Oak (originele naam).

[martijnvanegdom]

Object Georienteerde Talen, met name Java en C# , zijn zeker de toekomst.

Op de Tu-Delft word op in het eerste jaar van de studie Technische Informatica alleen maar Java gegevens. Alles gebeurd in java. In het tweede jaar komen daar nog wel prolog, haskell en C bij maar Java blijft de hoofdmoot.

Waarom, java word steeds sneller, croosplatform, en schoonehid van code, de leesbaarheid van de code, en vooral de makkelijke manier om te debuggen

[Anoniem: 18254]

Op de Tu-Delft word op in het eerste jaar van de studie Technische Informatica alleen maar Java gegevens. Alles gebeurd in java. In het tweede jaar komen daar nog wel prolog, haskell en C bij maar Java blijft de hoofdmoot.

Ja, en dan in het derde jaar krijg je het practicum Embedded Systems (voorheen alleen voor Elektrotechniek maar tegenwoordig ook voor Informatica-studenten), en dan blijkt dat zowel bij ET als bij IN er fundamentele kennis ontbreekt doordat men vrijwel alleen Java heeft gehad. Een medestudent omschrijft deze mensen treffend als de "Java generatie". Degenen die het zichzelf niet hebben aangeleerd (oftewel ruim 95%) weten vrijwel niks van programmeren in C of van efficiënt programmeren, met als gevolg dat er door de meeste mensen tijden worden neer gezet van ver boven de seconde (het gaat hier overigens om een 256-punts FFT, uitgevoerd op een 80C552 microcontroller van Philips met een externe klok van 15 MHz), terwijl het record (in assembly) op 198 ms staat. Daarnaast wordt bij alles dat in C niet kan of niet kan zoals men vindt dat het hoort te kunnen het trieste excuus "Java kan het wel" gebruikt, ook als het niet waar is - zo zijn er bijvoorbeeld opvallend veel mensen die glashard beweren dat je in Java kunt machtsverheffen met de ^ operator.

Nog even je andere argumenten onderuithalen:

Java sneller? Hooguit minder langzaam.

Schoonheid van code? HAHAHAHAHAHAHAHAHA! Hier hoef ik verder niet op in te gaan lijkt me.

Leesbaarheid van de code? Bepaald niet, aangezien Java voor veel dingen veel meer code nodig heeft dan C, en bovendien pseudo-low level is - waar slaat het op dat ik om een FileReader een BufferedReader heen moet plaatsen? Het bufferen van I/O is een taak van het OS, niet van de programmeertaal. Wanneer je applicaties schrijft in C (wat van oorsprong toch een systeemprogrammeertaal is) hoef je je hier helemaal niet druk over te maken, en terecht. Verder maakt de geforceerde objectgeoriënteerdheid van Java de code ook een stuk minder leesbaar. Het slaat nergens op dat ik m'n main in een class moet zetten, en het slaat ook nergens op dat je System.out.println moet gebruiken in plaats van puts. Maar ja, Java heeft geen functies, dus gaan ze maar een of ander debiel System object uit hun duim zuigen waar vervolgens weer een out aan vast zit, en daar hangen ze dan de eigenlijke functie (in OO-kretologie een methode, geloof ik) aan. Het is compleet onlogisch en arbitrair, zowel voor de beginnende als voor de gevorderde programmeur.

Makkelijke manier om te debuggen? Het tegendeel lijkt me waar. C programma's zijn met kennis van x86 assembly nog enigszins op machinecode-niveau te debuggen, bij Java niet (ervanuit gaande dat je het voor een JVM gecompileerd hebt), omdat je dan op het niveau van die rottige Java bytecode werkt en daar wil niemand zich toe verlagen...

[Anoniem: 77437]

Het is perfect mogelijk om embedden en Java te combineren:

- Niemand zegt dat je java code niet kunt compilen naar byte code, en daarna linken naar native machine instructies. De linker kan dan ineens ook platform afhankelijke optimalisaties doorvoeren. Zulke binaries zijn even snel en soms sneller als de C++ tegenhangers, het voordel is dat je met managed objecten zit, en dat je niet zelf moet alloceren en dealloceren in je heap. Een stuk veiliger dus.

- Sommige systemen (lees:het onze) hebben zulk een linker in een chip on-board. Deze linker zet bij het laden van classes de byte code om naar bv. ARM IV Thumb instructies, creëert code segmenten in de heap, en verifiëert alle dependencies en calls naar andere classes.

- Een volledig OS en 'VM' kan in ongeveer 5 MB (komt overeen met de 1.1.8 JDK of met het J2ME Personal Java profile)

- Java is perfect voor embedded systemen in wagens en trucs ed., omdat je gemakkelijk remote updates kunt installeren. Je moet gewoon nieuwe classes uploaden. In combinatie met een OSGi platform (zgn. bundles) heb je dan een zeer krachtig EN gemakkelijk onderhoudbaar systeem. Aangezien zulke remote updates op wagens e.d. dikwijls via gsm-data of gprs binnenlopen (nogal traag dus) kan de linker al beginnen linken tijdens de download van de update. Op het moment dat de laatste bytes van de update binnen zijn, is ook de linker klaar, en kan de software meteen gestart worden in native code.

[martijnvanegdom]

Er zijn echt veel voordelen aan java,
heb je ooit assembler geprogd? Heb je dat ooit gedebugt??

heb je ooit java geprogd? heb je dat ooit gedebugt?

probeer maar eens, en je zult zien dat java (en in het algemeen hoger talen) makkelijker te coden zijn dan assembler

[Anoniem: 48923]

Toch wel jammer dat er zo veel mensen in het verleden leven.

Hiermaar even een lijstje met feiten (en meningen)

1) JRE (voor embeded systemen) is klein genoeg
2) Java is niet (meer) traag
3) Java kan erg veel en (bijna) net zoveel als C of ASM
4) De Java VM heeft veel goede controles en regels veel voor je (het programma) zoals geheugen management.
5) Ik ben geen man in pak en sta 100% achter Java.
6) Ik haat geen andere talen (zoals vele mensen denken dat Java liefhebbers al het andere haten)

[Wim-Bart]

Het volgende is totaal off-topic, maar omdat er toch over C wordt gesproken en J++ toch op C lijkt het volgende. Bron is onbekend maar had het nog in mijn archief ergens staan. Inmiddels al weer enkele jaren oud, maar blijft leuk.

Creators Admit UNIX, C Hoax

In an announcement that has stunned the computer industry, Ken Thompson, Dennis Ritchie and Brian Kernighan admitted that the Unix operating system and C programming language created by them is an elaborate prank kept alive for over 20 years. Speaking at the recent UnixWorld Software Development Forum,Thompson revealed the following:

"In 1969, AT&T had just terminated their work with the GE/Honeywell/AT&T Multics project. Brian and I had started work with an early release of Pascal from Professor Niklaus Wirth's ETH labs in Switzerland and we were impressed with its elegant simplicity and power. Dennis had just finished reading 'Bored of the Rings', a National Lampoon parody of the Tolkien's 'Lord of the Rings' trilogy. As a lark, we decided to do parodies of the Multics environment and Pascal. Dennis and I were responsible for the operating environment. We looked at Multics and designed the new OS to be as complex and cryptic as possible to maximize casual users' frustration levels, calling it Unix as a parody of Multics, as well as other more risque allusions. We sold the terse command language to novitiates by telling them that it saved them typing.


Then Dennis and Brian worked on a warped version of Pascal, called 'A'. 'A' looked a lot like Pascal, but elevated the notion of the direct memory address (which Wirth had
banished) to the central concept of the language. This was Dennis's contribution, and he in fact coined the term "pointer" as an innocuous sounding name for a truly malevolent construct.

Brian must be credited with the idea of having absolutely no standard I/O specification:
this ensured that at least 50% of the typical commercial program would have to be re-coded when changing hardware platforms. Brian was also responsible for pitching this lack of I/O as a feature: it allowed us to describe the language as "truly portable".


When we found others were actually creating real programs with A, we removed compulsory type-checking on function arguments. Later, we added a notion we called
"casting": this allowed the programmer to treat an integer as though it were a 50kb user-defined structure. When we found that some programmers were simply not using pointers, we eliminated the ability to pass structures to functions, enforcing their use in even the simplest applications. We sold this, and many other features, as enhancements to the efficiency of the language. In this way, our prank evolved into B, BCPL, and finally C. We stopped when we got a clean compile on the following syntax:


for(;P("\n"),R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("|
"+(*u/4)%2);

At one time, we joked about selling this to the Soviets to set their computer science progress back 20 or more years.

Unfortunately, AT&T and other US corporations actually began using Unix and C. We decided we'd better keep mum, assuming it was just a passing phase.

In fact, it's taken US companies over 20 years to develop enough expertise to generate useful applications using this 1960's technological parody. We are impressed with the tenacity of the general Unix and C programmer. In fact, Brian, Dennis and I have never ourselves attempted to write a commercial application in this environment.


We feel really guilty about the chaos, confusion and truly awesome programming projects that have resulted from our silly prank so long ago."

Dennis Ritchie said: "What really tore it (just when AIDA was catching on), was that Bjarne Stroustrup caught onto our joke. He extended it to further parody, Smalltalk.
Like us, he was caught by surprise when nobody laughed. So he added multiple inheritance, virtual base classes, and later ... templates. All to no avail. So we now have compilers that can compile 100,000 lines per second, but need to process header files for 25 minutes before they get to the meat of "Hello, World".


Major Unix and C vendors and customers, including AT&T, Microsoft, Hewlett-Packard, GTE, NCR, and DEC have refused comment at this time.

Borland International, a leading vendor of object-oriented tools, including the popular Turbo Pascal and Borland C++, stated they had suspected this for a couple of years.
In fact, the notoriously late Quattro Pro for Windows was originally written in C++.
Philippe Kahn said: "After two and a half years programming, and massive programmer burn-outs, we re-coded the whole thing in Turbo Pascal in three months. I think it's fair to say that Turbo Pascal saved our bacon". Another Borland spokesman said that they would continue to enhance their Pascal products and halt further efforts to develop C/C++.


Professor Wirth of the ETH institute and father of the Pascal, Modula 2 and Oberon structured languages, cryptically said "P.T. Barnum was right." He had no further comments.

[jesse282]

Java en c# zijn de toekomst. Java biedt tenminste echte security, als ik een java adsl modem kan vinden die puur java is, zou ik hem graag kopen. Dat ben ik weer een stuk veiliger . Nog een md5 flash checksum erbij en ik ben tevreden.

Java heeft geen last van buffer overruns en andere heap exploits. Dit soort fouten zijn toch voor 80% verantwoordelijk voor de gevaarlijke exploits.

[Boudewijn]

ik zie niet in hoe je dat allemaal compact en realtime wil maken met die VM ertussen.
Die VM is idd de toegevoegde veiligheid ...

Maar heb je ooit een alternatieve (linux based) firmware op een linksys gezien.... ook zo stabiel als wat, maar toch echt C(++)

[riddles]

Realtime wordt zeker een probleem aangezien je je dan zaken als gc niet kunt veroorloven.

Maar de vraag is of compact nog een issue is. Kijk maar eens hoe snel een ARM processor nu is en hoe klein 32/64 MB is. Je hoeft in een embedded systeem al lang niet meer binnen 256kB te blijven.

[Anoniem: 109954]

Java is *op dit moment* langzaam. Ik ben vrij pro Java, maar zal dat (veelgebruikte) argument niet ontkennen. Maar laten we niet vergeten dat daar waarschijnlijk verandering in gaat komen. Processoren worden steeds sneller en waarschijnlijk wordt Java steeds meer geoptimaliseerd. Vroeger was C++ waarschijnlijk ook te langzaam geweest voor een 386. Nu maakt het verschil tussen C en C++ meestal niet zo veel meer uit. Als er over een aantal jaar processoren komen die Java zo snel uit kunnen voeren als C++ nu, dan heeft het wel veel voordelen. Onder andere minder exploits en kortere ontwikkeltijd.