Real Time Java implementations for embedded systems

[duragezic]

The senior design project of which I am unfortunately the project leader of is basically a study on the feasibility of using Real Time Java (RTJ) on embedded systems that is able to meet hard real time constraints.

When I mentioned this to one of the profs I had last semester, he basically shook his head and seemed to say it's not going to work. From what I've read, some papers straight up say it's not going to work. There's not much industry use of RTJ for embedded systems and all that kind of adds up and is disappointing for us, but still we have to do this either way. So that aside...

The problem I've been finding is that there are not many RTJ implementations that are suitable for embedded systems. A lot of them that are based on the Real Time Specification for Java (RTSJ) seem to be much too big, like they are designed for larger systems like running on a server. Sun's RTS is one of these; it's not suitable for us.

The concerns are cost (we'd like to avoid buying anything, since it is for evaluation and academic use, we could use a demo version as long as it's not limited or stripped), that it will run on a PowerPC-based target, and that hopefully it does not require an underlying Real Time OS (RTOS).

That seems to really limit our choices. So far, we've found simpleRTJ and some Scorpion RTJ. The problem with so many is that they just are too big for an embedded system and/or they require an underlying OS. Something like simpleRTJ is supposedly built to be a small implementation that does not require a RTOS, basically just what we need.

However, simpleRTJ is a commercial product (does have an evaluation version) that I'm not sure will work on a PowerPC and has a number of limitations itself. Plus we need to find several possible products, evaluate them, and choose which one to use for our project.

Another thing is that we are also to investigate creating Java programs that will interact with C code like a device driver. The most common way seems to be with JNI, except that products like simpleRTJ do not support JNI and instead have their own interface. I'm thinking that JNI is the most used and thus most documented and supported, but we probably won't be able to use it, so the capabilities a RTJ product has for doing this task is also important.

So what I'm asking is any thoughts on this in general from someone who has some knowledge or experience, and if anyone is aware of a RTJ implementation that would meet our needs. Thanks.

 

[smack Down]

Why Java, trying to meet hard real time in an interrupted language seems like a bad idea. Also if you don't plan on using a real time OS then you need to provide all the functions of a real time OS yourself. That in and of itself is no easy task and besides the scheduler it all has to be done in C/assembler.

Why are you using a PowerPC in an embedded application? Unless you have one hell of a budget and have an FPGA with a PowerPC core. Embedded real time systems get data from the real world and send data to the world I can't imagine any such project that could be completed in less then a year that requires more power then a HC12.

 

[duragezic]

Well some of these things are sort of set already and we don't have a choice. Here we don't get to create our own senior design projects. Companies pay a sum of money to have a team of 4-5 EE and/or CpE students do the project in two semesters that the company sponsors/requests. The Problem Statement given to us says they are having various problems associated with the C language (weak type checking, unable to enforce real time constraints, poor portability, difficulty in maintenance, etc) that would be mostly solved with Real Time Java so we are to investigate if it is realistic or feasible to do.

So although Java is slower partially due to things like more runtime checks, it is the runtime checks that are supposed to hopefully address the issues they are having with C. I'm also not too familiar with this, but I suspect things like the JIT compiler or something like that would be used by these RTJ for embedded systems products in order to gain some speed.

What I mean by not requiring a RTOS is that the RTJ implementation (like simpleRTJ for example) provides those functions itself. If it required a RTOS separately, the company would have to spend major time/money porting it and we are not sure how they would all interact. Like if we are supposed to interface Java with C code, I think having an underlying RTOS that isn't part of the RTJ implementation would add an extra layer of unknown interaction. But again, I'm not too familiar with it all yet and we are in the initial stages so I might have something wrong. But I understood it as basically a specialized version of RTJ would provide all the RTOS functionality too.

As for the PowerPC, again that is the sponsor's choice since they are supplying the target as an evaluation kit. Appearantly what we are getting for the board is a next-gen version of something they currently use. It has Freescale's e200z6 core.

 

[smack Down]

The Problem Statement given to us says they are having various problems associated with the C language (weak type checking, unable to enforce real time constraints, poor portability, difficulty in maintenance, etc)

Their problems are not related to the C language. Other then auto casting int to double I don't know what they are talking about when they say weak type checking. They are unable to enforce real time constraints because they are to cheap to buy a real time OS. If they followed the C standard and used a RTOS they should only need to port their costume drivers.

It sound like their problems are related to their RTOS choose rather then language choose. The language you use isn't going to make much difference in real time systems because the more features you use the more unpredictable the run time is. Undeterministic behavior is the enemy of all real time systems.

Before you put to much effort into the OS side of things make sure you do a load analyst. Assume all task are periodic, if they are not then take the worst case of how often it can occur. Estimate the how much system time each task needs per period. Using that calculate the utilization if the total utilization is less then .5 you great, higher then .7 walk away. Of course if you have very few task you can have a higher utilization. If your task have interaction you need lower utilization. You said they have been missing deadlines so they may be at or above the utilization limits already.

 

[EagleKeeper]

Java itself is not designed to be an OS.

Therefore you will have to have an underlying OS.

Currently, the majority of embedded RTOSes are a derivative of *nx, VxWorks, PSOS or Windows.

There are other embedded OSes out there, but they are dropping in popularity.

 

[Fox5]

Why can't you just add a couple extra memory chips on to fit the larger RTOS Java systems? As long as you're not trying to fit inside a cell phone form factor, I'd imagine it would be doable.

 

[duragezic]

smack Down: Well one example that I understand showed several functions, where each function was a layer so to speak (it's a very large company with outsourcing around the world so they are dealing with multiple layers of C like a device driver is the lower layer). So at the lowest level there are two functions f, one took two ints as arguments, one took an unsigned int and an int. The problem was that on layers above that one, someone did not know about this (say the two int function was older than the function with one unsigned int and one int). So for whatever reason, the person writing at that layer wasn't aware of this the newer one that specified as unsigned int as the first argument, so they write two functions:

func1()
{
...
a = f(4, 5);
}

func2()
{
...
b = f(-3, -2);
}

Now as I understand it, C would let func2() call the newer function that requires an unsigned int for the first argument, and the programmer would not know anything is wrong. I believe a language like Java would give some sort of exception at runtime (or even error during compile?) that basically said the method was not found.

Then again, I don't even remember using 'unsigned' in Java. But either way that is one example I was given on problems with C.

As far as the RTOS issue... hmm I don't know. I thought a product like simpleRTJ would be what we need. But I will look into the RTOS issue and bring it up with my sponsor. The board we are receiving will have 1.5MB of flash memory and 64KB of SRAM (with an additional 8KB cache that can be used as RAM). So that seems like a fairly decent amount of memory... but my understanding is that even if it fit, larger RTJ systems, especially ones based off the RTSJ are just too much and would run too slowly.

And about the load analysis... well it's tough to do since we are merely demonstrating a RTJ program meeting hard real time constraints. I actually asked for clarification on that and got an in-depth example of what they currently do, but we aren't doing any engine controls or whatever. We are just developing some demo that will push the target to the edge as much as they currently do with their real applications. But I will have specifications on some of the timing, and there's maybe three layers of tasks that need to get done, with the first layer or two that probably absolutely have to meet a deadline, while the lowest priority layer has tasks that aren't as critical.


Thanks all for the thoughts and keep them coming. I have no knowledge or experience with real time systems so this is all knew for me, and I thought I had a handle on it until this RTOS issue you guys talk about.. :|

 

[ScottMac]

THere are a couple microcontrollers that will program directly in Java ... Parallax has a Stamp, and I know I've seen others that I don't recall.

Check out a copy of Circuit Cellar magazine, they all pretty much advertise in there.

Good Luck

Scott

 

[IHateMyJob2004]

You can do real time Java. A professor might think otherwise because he is stuck in the world of theory, not reality.

While the Navy would not allow RTJ for anything they do, they do allow us to use Java (not real time) for front ends. Typically, those GUIs talk to a controller (usually Ada or C/C++) that is in fact real time.

 

[degibson]

Originally posted by: IHateMyJob2004
You can do real time Java. A professor might think otherwise because he is stuck in the world of theory, not reality.

I have to disagree with this. True real time requires guarantees. I think it is going to be very difficult to make any hard guarantees about runtime in a language that has Java's features -- GC, for instance. It might be doable on an RTOS -- on an embedded platform without an underlying real-time base, it will be challenging indeed.

 

[Markbnj]

Now as I understand it, C would let func2() call the newer function that requires an unsigned int for the first argument, and the programmer would not know anything is wrong.

I'm not aware that any version of C has function overloading, so that problem is not one of type checking. The last definition of f() in the namespace would hide any previous. Within that definition if the compiler has a defined type conversion that will allow the call, then it will compile. But I doubt seriously it would convert a literal signed integer into an unsigned without a warning.