KESO is an embedded multi JVM for embedded devices and networks of micro controllers. KESO relies on an traditional OSEK/VDX operating system that provides scheduling and synchronization mechanisms to support multiple tasks on one micro controller. It furthermore provides notification mechanisms and a timer concept that allows the handling of timed or cyclic events.

KESO is designed for static embedded systems. The static nature of the system enables the use of analyzing techniques that allow the creation of a system that is highly adapted to the Java applications. Because complicated mechanisms such as a dynamic loader for Java classes are not required in such a system, we can achieve code sizes that allow to run KESO on smallest embedded devices. To avoid the interpretation of bytecode on the target controllers, the Java bytecode is compiled to a native code binary image ahead of time.

KESO applications are developed in Java using a uniform programming model. There is a single configuration for the system as a whole. Subsequent configurations such as the configuration for the OSEK/VDX operating system are created automatically by jino, the KESO building tool.

KESO provides a concept similar to the process concept found in modern operating systems for personal computers. These units are called domains in KESO and allow the safe co-existence of multiple tasks on the same micro controller. These domains can communicate through a uniform portal mechanism that works similar to Java Remote Method Invocation (RMI) or Remote Procedure Calls (RPC). The conceptual design of KESO was inspired by the Java operating system for personal computers JX.

KESO is unique in several aspects:

• It is the first Multi-JVM for deeply embedded systems.
• It provides OSEK/VDX API calls and system primitives to the (Java) application developer.
• It provides hardware drivers written in pure Java. (under development)
• It provides a per JVM configurable garbage collector.

We are currently working on Distributed KESO, which will allow domains to be spread across a controller network. These domains will be able to communicate via the portal mechanism just as domains that are colocated on a micro controller. Since the location of a domain is transparent to the application, a relocation or integration of tasks within the controller network will boil down to a reconfiguration that does not require a change to the applications.