Medical Electronics Manufacturing Spring 1999
EMBEDDED SOFTWARE
Exploring Java Programming for Medical Electronics
The Java programming environment is flexible and easy to use. In some situations it can be a sensible option for devices that use embedded systems.
Curtis Schwaderer
Write once, run anywhere is a motto commonly used by Java advocates. But with its origins in the desktop world, can Java be applicable to embedded devices, especially mission-critical ones such as medical electronics? This article provides an introduction to Java, describes its benefits and drawbacks, and offers an implementation model for Java in embedded environments. The model illustrates how medical device manufacturers can take advantage of Java's benefits and still keep the high-reliability, mission-critical nature of a device intact.
Depending on the complexity of the application, Java can provide a viable option for software development.
What Is Java?
|
|
ADVERTISEMENT |
Not without drawbacks. Java has desktop origins. Most software developers have faced the dreaded blue-screen effect or Windows exception error. Obviously embedded devices cannot afford to be unstable or unreliable, particularly when the safety of a patient is an issue. Although Java is an interpreted language, Java byte code is actually smaller than C byte code. However, the JVM's large overhead requires more memory and a higher-performance cpu than C. Java garbage collection provides automatic memory and resource recovery, but this function also produces delays during these recovery periods so real-time response is compromised. In short, if the reliability, speed and size, and real-time response concerns can be overcome, choosing Java as a design option becomes much more viable.
Best of Both Worlds
This example will explore how the problems with Java can be overcome for an embedded device. Analyzing use of the Java environment in an OS-9 real-time operating system (RTOS) reveals its strengths and weaknesses. OS-9 is a multitasking, process model RTOS used extensively in mission-critical applications. OS-9 is ideal for such real-time applications because of its secure process model architecture and module cyclic redundancy check (CRC) validation facilities that can detect attempts to corrupt—accidentally or maliciously—the system. A general architecture of the OS-9 Java environment and virtual machine is shown in Figure 1.
Figure 1. The OS-9 Java environment.
Java applets run in a threaded environment. The JVM, which runs in the context of a single process, therefore, implements a threaded environment within which each Java applet can run. Threads imply that universal access is available to all resources within the context. By defining the context as a single process, the Java environment is viewed by the system's native real-time environment as nothing more than another process.
Reliability. Enabling end-users to load a unique or custom Java application onto a medical device can make the device more flexible, but it also presents certain risks. Providing such a customization option greatly increases the risk of a failed application, compromising the reliability of the system. Figure 2 shows the result of an application fault in the Java environment. From the system perspective, a fault occurred in the JVM process context. OS-9 isolated this fault within the context of the JVM process. Anything within the JVM environment is subject to potential system failure, but other processes in the system are not at risk.
Figure 2. Application fault in the Java environment.
This safeguard allows custom applications to be added to the environment without compromising the core reliability of the system. It is also possible to use a multiple JVM environment to take advantage of the development time and effort savings of Java. Figure 3 shows a multiple JVM environment in which core system Java applications can run in a trusted JVM environment, and dynamically loaded add-on applications can run in a nontrusted environment. With this setup, application faults in the nontrusted environment do not affect other critical-function applets in the trusted environment.
Figure 3. Multiple JVMs providing trusted and nontrusted environments.
Real-time response. Figures 2 and 3 also apply from a real-time response perspective. Java garbage collection refers to the inherent facility within the Java environment that inspects the environment and frees any resources no longer being used by any execution thread within the JVM. The benefit of this facility is that applications don't need to be judicious about returning memory or resources allocated to them. The drawback is that this facility can be time-consuming and can compromise the real-time nature within its context. In the OS-9 environment, designers should implement tasks that must be deterministic as separate processes. It is important to specify a scheduling and priority scheme that ensures these processes will be deterministic by preempting the JVM processes even if garbage collection is occurring. In other words, the system guarantees that the process will be scheduled within a set time frame. For instance, the operating system must guarantee that the time it takes to stop execution of process A and begin execution of process B in a multitasking environment will be X microseconds.
Size. Java is large. Enterprise Java, which requires 8 Mbyte of random access memory (RAM), is the version used on desktop PCs. Personal Java, a subset of Enterprise Java, cuts out some of the functionality, but is still appropriate to use in smaller embeddable devices. Embedded Java, which requires 1 Mbyte of RAM, is a very small subset of Java targeted at smaller embedded systems. Implementing Personal Java, including the application, requires roughly 4 Mbyte of RAM and 4 Mbyte of read-only memory (ROM). Embedded Java requires roughly 1–3 Mbyte of ROM and 1 Mbyte of RAM. If Java graphics classes are not used, ROM and RAM requirements can be decreased by as much as half. From a size perspective, using Java doesn't always make sense. Figure 4 shows application complexity versus size requirements for Java and C/C++.
Figure 4. Application complexity versus code size for Java and C/C++.
Figure 4 also summarizes a case study involving size requirements of an Internet appliance using a Java environment and native application environments. The case study concluded that for applications involving network connectivity and moderate-to-complex graphics capability, the overall size requirements for the product break even. As more graphics complexity and multimedia capability are introduced, Java becomes a smaller solution.
Application Note
ABX Hematologie, a French medical electronics company, uses OS-9 in its Vega Retic hematology analyzers. Although the ABX product line does not currently use Java technology, the following analysis examines whether Java could make sense.
The first step is to identify the functionality of the equipment. The hematology analyzer has an input panel, a display, and printout capability for report generation. The equipment also has a function to conduct the blood analysis. For this hypothetical situation, a touch screen and a network interface for remote access were also included.
Figure 5. Hypothetical Java environment for a blood analyzer.
Figure 5 shows a general diagram of the software functions for the hypothetical device and where each function might reside within each environment. To meet the real-time system requirements, only a small portion of the environment may need to be written for the native environment. The other functions can then reside within the Java environment for ease of development and reusability. An optional JVM could also be provided to customize the device to run additional analysis applications. The baseline environment for this kind of application is between 4 and 5 Mbyte of ROM and between 2 and 3 Mbyte of RAM.
Conclusion
As the complexity of medical equipment increases, Java represents an increasingly attractive option for software development. Speeding up the development process, reusing already finished code, and providing an industry-standard environment for customization are just a few reasons that Java can make sense as a programming option. Reliability, size, and real-time response concerns represent the roadblocks that must be overcome to make Java a viable option for a particular medical device. If implemented properly, however, Java can make sense for medical products.
Reference
1. John K Ousterhout, "Scripting: Higher-Level Programming for the 21st Century" IEEE, May 1998.
Curtis Schwaderer is the director of network technologies for Microware Systems Corporation (Des Moines, IA). He can be reached at curts@microware.com.
