Yes, its time

Sorry, but I haven't had a chance to update this blog in a while. Seems its crunch time, and our small team is getting buried in its own success.

The good news is: We've been running production on our Java based control system (for semiconductor manufacturing equipment) for more than a year now, at three major customer plants! For the regular 'bread maker', the uptime has been almost astronomical compared to the (similar) beta release of the last control system do-over that I remember back-when in 1995. I know, thats along time ago, but things move slow in the semiconductor machine control world. I believe my distinguished colleague Doug Locke at some point called embedded developers 'as conservative as cats', my addition to this only would be that our trade also only 'moves like humans dinosaurs', which makes for rather slow progress altogether.

In the end, the move was timely, and so far (from the technical aspect), it has been a fun ride. The 'shock and awe' thunder one sometimes gets from management doesn't go away with any technology, I suppose. But at least with the new software framework, we typically can now respond in a way that doesn't kill the entire weekend. Speaking of which, we just got orders/requirements to get a tool ready for Semicon West, so the Java control system we've been working on will be there live running a actual semiconductor machine!

James Gosling: on the Java Road

James Gosling: on the Java Road

Does Java make sense in the embedded world?

One of he main advantages of Java is that "Java is very accessible in terms of its flexibility and ease of programming." says Roger Mite, a senior research director at Sun Labs. "There are a lot of people who are Java programmers who are not embedded systems programmers". "Sun pushes Java for sensor networks".

Something we applied and expanded on in the project I'm involved with at my place of work.
The (fairly large-scale) project is a control framework for large tools with lots of robotics, digital and analog devices and controllers. The goal for us was not just to make it easy to integrate sensors and other hardware into this framework -- that too. We also had to consider how to scale for future developments. Outside of hardware, some of the major factors that affect success and cost of your project are...

1. Access to people that share your vision and are willing to create the product
   
2. Access to knowledge in domains that you need but where you don't want to compete with
3. Access to standard, off-the-shelf components that are typically commodities
   

For 1. there is two ways to go about it: Either you create things accept the fact that The main goal was really to lower the threshold for someone to be able to contribute to such a system. An easy and consistent language is a large part of that, and Java has decent tradeoff's (I could list all the features I sorely miss in Java, but that would take up the rest of the web space at blogger, and it would take the rest of my life to explain them to my team...).
The concept of the Java VM is a similar enabling feature, since that now brings the condensed realtime knowledge of the vendor of your realtime VM into the team. This has the potential to take care of the lower level stuff; the stuff that noone really wants to bother with and that keeps some old bearded, gruffy individual in employment, typically only person that can fix the foundation.
Of course another reason for Java is the easy acessibility of external high quality components. Just the ability to integrate the Apache XML parser (instead of being held ransom by you RTOS vendor or some 3rd party company in the caribean) means accessibility to new technology as the embedded and controls world has never seen before.

When does outsourcing make sense?

Here is my $.02:
Understanding how a certain embedded systems/realtime systems work is a domain knowledge thats rather hard to come by. Knowing how to use a programming language (thus using a programming language to translate a problem into a solution) is a service that may be temporarily difficult, but in the grant scheme of things its something thats rather easy. If a problem can be described without meeting, telephone conferences, or flying to far away places, its a simple service (just like renting a car, or getting a plane ticket, or placing a telephone call). If a problem requires more elaborate means of communication, most likely you're talking about a product, which requires domain knowledge to build (such as a plane, a car or something as simple as a telephone).

Outsourcing a procedure is easy, outsourcing a product is not.
Outsourcing a service is easy, outsourcing domain knowledge is not.

Making device programming accessible

One of the advantages of Java is that "Java is very accessible in terms of its flexibility and ease of programming." says Roger Mite, a senior research director at Sun Labs. "There are a lot of people who are Java programmers who are not embedded systems programmers" (See "Sun pushes Java for sensor networks").

This is one of the major reasons for using Java in the project I'm involved with at my place of work. This (fairly large-scale) project is a control framework for large tools with lots of robotics, digital and analog devices and controllers. The goal for us was not just to make it possible to integrate any number of sensors and other hardware into this framework. That too, but we also had to consider how to scale for future developments -- and making things accessible for new folks is a good way to do that.

The Sun SPOT stuff is aimed to spark interest in realtime/control application development with the typical bussiness application developer community. The Sun SPOT team is about to release a evaluation kit for their technology, which includes three Sun SPOTs devices: two stand-alone sensor/actuator devices and one base station. All three Sun SPOTs include a processor board with 32-bit ARM9 CPU, 512 KB RAM and 4MB Flash memory, 2.4 GHz radio and USB interface. Each stand-alone Sun SPOT also includes a 3D accelerometer, temperature and light sensors, 8 tri-color light emitting diodes (LEDs), six analog inputs and 8 general purpose I/O ports for controlling relays and servos. It is said to cost $499.00 and to be available in May 2006.

The only gripe I have with it is the price: even though the components are probably worth it, I think it's a hard sell for someone who'd start to do some casual control hacking.

SWT, Swing or AWT: Which is right for you?

SWT, Swing or AWT: Which is right for you?
SWT : buy
Swing: hold
AWT : sell

Aonix PERC gets SWT

It seems that Aonix was busy and added SWT to PERC. This could make for snappy GUI's in embedded and realtime Java devices, since SWT isn't as bloated as Swing. For my part, I just wish Swing would get buried (fat chance thats gonna happen). Now if all other embedded VM suppliers -- especially the OEM's that supply VM's for cellphones -- could just do the same thing.

JamaicaVM gets Swing support

Seems the aicas JamaicaVM now also supports Swing as per this press release, which would make it possible to use the same JVM throughout a distributed system, from the RT/embedded subsystem up to the GUI.

Java breaks out

Java breaks out
Brewing enhancements, OEMs target security, speed and ease of programming
By DAVID LAMMERS
EE Times (02/06/06, 10:00:00 AM EST)

An Embedded.com article with some details on ARM using Jazelle as hardware JVM, and on PERC Pico and its (intended) limitations. This sounds familiar, I recall the standard PERC VM having the same limitations a few years back (evidently for different reasons).
Speaking of Jazelle: Fritjof has a page with all sorts of embedded/RT-Java devices.

IBM's 2 msec latency GC j9

IBM sets real-time tempo for Java code with Metronome
By David Lammers
EE Times (09/12/05, 09:00:00 AM EDT)

Seems IBM is back in the Java-RT game. Three years ago at the Embedded Systems Conference in San Jose, I got a response from one of their main RTSJ-Java j9 developers that was pretty discouraging, but now they seem to be back. Here is an article about their 2 millisec worst case garbage collector called Metronome.
During our initial tests for our framework (in 2002), the then IBM j9 was overall a good performer, the only reason why we couldn't select it then was the unknown future of this VM in the realtime domain. I think even QNX wound up replacing the VM in their Neutrino/QNX6 RTOS (after a promising RT-Java start in 2001), since the direction of IBM wasn't clear.
Welcome back, IBM!

Also, the article contains interesting little side-kicks from Greg Bolella (distinguished engineer at Sun Microsystems Software and director of the real-time Java program):

"Both real-time garbage collection and scoped memory are necessary for these applications. Anyone, or any company, who intimates anything different just isn't clued in."

and

...The real-time-collection vs. scoped memory argument these IBM guys like to make is completely spurious..."

Greg was at IBM in charge of RT-Java when IBM kickstarted the RTSJ effort. He was the lead for the RTSJ 'JSR0001' for quite some time. He moved on to Sun right around the time when IBM appeared to loose interest in RT-Java.
Looks like he ain't afraid to say what he thinks...
In the end, he's right, it should not be a "either/or" choice for the consumer.

Java preps dive into real-time role

Java preps dive into real-time role
Through tweaks and modifications, Java is finding a home in critical applications ranging from the military to telecommunications
By David Lammers
EE Times (08/01/05, 10:00:00 AM EDT)

Embedded.com article

Java with real time constraints

Building Java-based embedded designs with real time constraints
By Kelvin Nilsen
Embedded.com (08/15/05, 09:15:00 AM EDT)

Kelvin Nilsen in an article elaborating on "soft" vs. "hard" real-time.

PERC Pico

Articles about Aonix PERC Pico release in Bussiness Wire and Electronicstalk

Real Java for Real Time – Gain and Pain

Real Java for Real Time – Gain and Pain
Anders Nilsson, Torbjörn Ekman, Klas Nilsson
Department of Computer Science, Lund University, Sweden

A presentation about problems and potential solutions using RT-Java. The new IBM garbage collector mentioned in this article is developed at this university at the same time.

Reliability quest fuels RT Java projects

REAL-TIME JAVA: Reliability quest fuels RT Java projects
David Lammers
EE Times (03/28/2005 9:00 AM EST)

Article

Real-Time Java Moving Into the Mainstream

Doug Locke's article 'Real-Time Java Moving Into the Mainstream from the December 2004 issue of RTC Magazine. In the same issue, Kelvin Nilsen talks about Java and mission-critical systems in the article titled 'Definition and Standardization Move Java into Mission-Critical Applications'

The Experts

Some of the people I keep running into and keep reading about on the subject of real-time java:

• Douglas E. Jensen, he operates the real-time.org website, which sadly hasn't seen a update in almost 2 years. Nonetheless, the material presented on his site is still valid in its fundamentals that I consider required reading.
• Doug Locke was over a long time in charge of the reference implementation of the RTSJ at Timesys. I had the honor of meeting him, a very bright and knowledgeable man.


• Peter Dibble is the author of 'Real-Time JAVA Platform Programming', a very well written book that explains software control problems and their solutions -- not necessarily just for Java.
• Kelvin Nilsen is the CTO of Aonix (formerly NewMonics) and sometimes holds classes and seminars on the subject. He holds numerous patents on real-time programming and garbage collection.


• Fridtjof Siebert, and the company he founded aicas located in Germany approaches memory garbage collection from a new perspective (sorta revolutionary as to what Newmonics did a few years ago). This company deserves to be on the 'watch list' for anyone doing embedded development.
  

There are quite a few more to mention, this list will be updated as needed.

The History

(Just to clarify: When 'Java' is mentioned in any of my comentary, I mean 'Java - the Platform', consisting of JVM, Language and Libraries. I'll try to use 'Java - the language' when I'm talking about any language features, but I think this will be pretty rare. 'JVM' and 'J2ME'/'J2SE' will be used for the VM and library respectively. All Java related terms and abbrevation are trademarks of Sun MicroSystems.)

Over the years since I've been following the developments in the Java embedded/real-time space (ca. since 1999) things have been constantly changing, and it certainly was a trying experience in the 'user space' of RT-Java. I was charged with architecting a control framework for semiconductor manufacturing equipment based on Java technology in 2000, and due to the constant change, it wasn't always easy to make management-digestable suggestions were to go next.

Initialy a NIST project delivered the requirements for a Java realtime specification. Around this time, the community got split into two camps

• The (now defunct) J-Consortium lead by HP used an approach to tighten the existing Java specification without adding any extra interfaces and libraries. The argument was that if the specification (JVM and libraries) is implemented to real-time principles (i.e. determinitstic GC, interuptable I/O), there is no need for any extra modifications.
  
• The RTJS experts group lead by IBM under the newly formed Sun comunity process (rumor has it that the IBM/RTSJ group caused to Sun to accelerate the creation of the JCP process: the 'Real-Time Specification for Java' is numbered 'JSR00001'), the approach here was a much more elaborate API and JVM modifications true to the core of real-time computing principles and theory.
  

Although the first group didn't enjoy the support of Sun, they had one distinguishing advantage: There was already an existing implementation in the form of the Newmonics (now Aonix) PERC VM. This was a clean room implementation of the Java specification with a deterministic garbage collector based on research of the Newmonics founder and chief architect Kelvin Nielsen.

In contrast, the RTSJ group had to create the specification (which was finished in 2002), the first reference implementation (which wasn't really useable, sorry) came out in 2003, and second release in 2004. The full suite wasn't released until 2005, but with severe requirements and restrictions.
Having said this, it is not meant to diminish the work of the experts group: They were basically tasked to bring light into a dark spot of computing, then full with legends and woodoo.

As it turns out, the two specs are not exclusive to each other. The German company aicas released a implementation in 2003 which fulfills the RTSJ specification and has a highly deterministic garbage collector. More and more JVM's start implementing the RTSJ *and* have RT capable GC.

Starting in 2004, the mainstream software and control publications noticed that there was something new coming into the embedded/control market, and more and more publications touted it 'the thing to come in 2005', including December, 2004 issue of the RTC Magazine and analyst Chris Lanfear.
Its not (quite) here yet. Probably because control applications take longer to implement due to their typical higher shelf-live and larger requirements set than their desktop or gaming counterparts. And probably because real-time developers tend to be as conservative as cats. But it is definitely out there...

Good Evening...

... and Welcome!

I've created this blog primarily to post shortcuts to news and developments in the Java embedded / realtime control world, and perhaps summarize and comment on some of the articles.

My background is that I'm a senior developer at a company in the Semiconductor Equipment industry and the principal architect of their next generation machine control system. It is pretty much entirely developed using Java, utilizing different Java VM's for different framework areas. My resume can be found here.

I would like use this blog to network with people in similar (or even not so similar) positions to exchange ideas and find generic solutions to common problems.

I will prime this blog with some articles that I had book-marked over the years, sometime I may even have some commentary. I'll try to do the best to get the initial set of articles into some resemblance of a chronical order, but that may not be too easy, so some stuff may be out of order.

Thanks, and have fun,

-Thomas