Using Java for Next-Generation Telematics Systems

Telematics, the use of computers in vehicles in concert with telecommunication systems to transfer information to and from the vehicle, is increasingly a part of safe and secure transportation systems as well as in-vehicle management, entertainment, and communications. Telematics systems include hardware and software running on the mobile platform, and potentially the corresponding software running on server systems that organizes and disseminates data from the vehicle.

Creating fleet management systems that are reliable with technology that is portable, scaleable, robust, easy to use, quick and relatively inexpensive to deploy is critical to the success of such systems. Java, once considered suitable only for graphic applications, is today mature enough to meet the requirements of next-generation commercial telematics systems.  Combining the power and simplicity of embedded Java with a framework for creating telematics systems offers the industry reduced development costs and a more reliable and versatile end product.

Two applications that serve as extreme examples are a fleet trucking company that uses a telematics system to monitor speed and other parameters of each of its trucks, and a video-on-demand system that could be used in passenger cars.  In the first example, most of the data is sent from the mobile platform back to a central server where it is analyzed, while in the second example most of the data (video) is sent from a server to the vehicle.  These two examples not only demonstrate the extreme mix of possible data in telematics systems, but also illustrate the segmentation of the market:  commercial telematics and consumer telematics.

Some of the challenges and requirements for next-generation commercial telematics systems include:

1.     Reduced downtime attributed to software revisions.  Systems that require in-vehicle upgrades or a visit by a technician will not be acceptable.

2.     The entire system must be extremely robust, well designed, documented and tested. Software failures can be extremely expensive. For example, if a defect prevents the onboard device from performing basic tasks such as periodically uploading vehicle statistics required by government agencies, it is virtually impossible for the fleet operator to regenerate this data.

3.     A fleet with hundreds and even thousands of vehicles typically purchased over a span of many years creates a situation in which trucks are not running the same hardware platform.  To maintain a centralized application management and distribution point, it is essential to have a distribution and execution mechanism that supports a heterogeneous environment.

4.     The convergence of ever-increasing processing power and the growing use of telematics systems are leading to an explosion of the number of applications.  A flexible and extensible system is required because no company is able to anticipate all of the needs of a fleet management system in advance.

5.     Use of standardized software development tools and processes. Most legacy systems have been developed in variants of the C programming language using proprietary tools, libraries and operating systems. This makes the task of migrating a product to a new operating system or CPU difficult, time consuming and expensive.  New products require a cost-effective, standardized, network-friendly tool suite that maximizes code (platform) portability, software reuse, and programmer productivity.

The necessity of these requirements has been amply demonstrated by the field experience of Aonix and other companies. An example of high reliability requirements is the Intelligent Vehicle Initiative (IVI). As demands to deliver people and goods using the transportation industry grow, increasing emphasis is placed on automation to monitor the safety of the industry.  The IVI program is a program of the United States Department of Transportation to test these types of devices in the commercial trucking industry.  One of the devices tested monitors the location of the truck within lane boundaries and determines if the truck is outside of the lane inappropriately.  (The system checks if the turn signal is active during a lane excursion.)  Too many lane excursions over a period of time indicate that the driver is either driving too fast or is tired.  The system then alerts the driver and initiates other actions such as sending a message to headquarters documenting the behavior.  In the figure below, we see an actual test of the system.  The system detects a lane excursion when the vehicle is 30 or more inches past the lane marker.  In this test case, the complete data set including lateral velocity and other parameters for a 60 second period centered on the event is sent over a wireless network for collection into a database.  The figure below shows actual data collected in a test case for the lateral offset in the lane.

  Lane Excursion Data

While the specific example here tests for lane excursions, many such safety applications are possible. With the right telematics platform, these applications are easy to build and deploy.

One of the most important factors to consider in supporting complex requirements is programming language and platform. An example drawn from real commercial systems is the XataNet fleet management system deployed by Xata.  The system utilizes a Java framework combined with .NET web services customized to help meet the unique aspects of Xata’s business.  The Java framework is utilized on both the onboard computing platform and the server-side computing platforms to create a seamless interface between these platforms.  The information collected on the vehicle is transmitted to the server-side computers using wireless networks and other technologies, depending on the urgency of the data transmission and the relative costs of the network bandwidth.  In addition, the system uses Java dynamic loading capability to add features and update in-vehicle software without requiring a system restart.  These updates and enhancements are delivered over the same networks that transport data from the trucks.

Onboard Intelligent Systems

Each Xata onboard intelligent system is composed of an embedded processor running the PERC Ultra virtual machine, which is programmed to perform as much local processing on the vehicle as possible.  By providing significant intelligence on the mobile platform, Xata minimizes network bandwidth requirements, thus saving fleet owners money by not making heavy use of wireless data networks.  The added intelligence also enhances reliability, enhances degraded mode processing, automates vehicle diagnostics, betters vehicle security, and creates more accurate reports. 

These advantages come with a price.  Software with the features described here can require many man-years to write and debug from scratch.  A properly designed application framework and its components can significantly reduce the effort required to develop on-board computer systems, and will provide a stable foundation upon which to easily extend the system in the future.

There are many advantages of the Java programming language for designing a reliable system, and in important ways Java is better suited than C or C++ for most aspects of creating a telematics system.  However, conventional Java by itself cannot accomplish the entire task, including programming of hardware interrupt routines and drivers. Solutions to this problem are addressed further below. First, some of the reasons for using Java for telematics systems are reviewed.

Simpler programming language

It is well documented that Java is easier to learn and to use to create complex programs.  Combined with its extensive, standard, and well-documented libraries, Java developers consistently achieve their goal with at least 30 to 50 percent greater productivity than their C or C++ counterparts, and according to some studies as much as 200 to 300 percent improvement.  This has been documented in IDC reports (IDC, Java Pays – Positively, May 1998) and has been the experience of many development teams.  Because of this simplicity and library commonality, Java programs are usually more reliable and more accurate to their specification.  A more detailed analysis of the advantages of the Java programming language can be found in many papers. [Calix], [Phipps], [Wells], [Zedasoft]

From the point of view of the telematics application programmer, this simplicity directly translates to increased programmer productivity, faster development times, and fewer bugs found both at development time and in deployment.  For example, compared to C++, Java does not allow for multiple inheritance in objects.  This does not in any way inhibit the expressive power of the programmer as most constructs created with multiple inheritances can be created with Java single object inheritance and Java interfaces.  In the cases where Java cannot be used, the semantics of the construct are likely ambiguous and may act differently for different C++ compilers.  Java’s single inheritance and interface definitions are simpler and allow other programmers reading the code to quickly understand the object relationships.

Code portability

Java code is compiled to byte codes, a set of machine operands designed to execute on a Java virtual machine.  Since Java code is first transformed to byte codes and the operation of these byte codes on a Java virtual machine is well defined and platform independent, any platform that can execute a Java virtual machine can execute the Java program.  This allows software development teams to move applications and programs to additional platforms with much less effort than would be required in C, C++, or other programming languages.

For a telematics platform development manager facing requirements for multiple target platforms, code portability between platforms is sometimes crucial to the success of the project.  The Java programming problem can solve compatibility issues between platforms and also help create a simulation platform on a standard personal computer.  For example, The Xatanet system Aonix developed for Xata uses the same binary (compiled) Java installed on the target platform and in the simulator.  Differentiation is limited to only those code areas where actual data is retrieved, requiring a data simulator stub.  By using Java, a simulator that uses the same binary code installed on the platform can be designed and running within a few short weeks.

Dynamic program loading

A key feature of the Java programming language is the ability to load new code into the Java virtual machine even while the virtual machine is executing other programs.  This allows developers to create applications that can easily add components without restarting the system.  This is particularly useful in telematics where a new or updated application can be downloaded to the vehicle over a wireless network, allowing the telematics platform on the vehicle to be updated in the field.

The ability to update code in the field while the system is active is a great benefit over other languages such as C++.  The equivalent notion in C++ or C is the Dynamic Link Library, or DLL.  These libraries can be loaded (linked) on the fly with a program that is running, but they have the disadvantage that two or more versions with the same method names cannot be loaded at the same time.  This is easily accomplished in Java using new instances of a classloader and has one particularly useful application in telematics.  Consider a telematics system in the field with certified code for computing tax data.  However, new laws require that this code be updated.  With Java, it is very easy to update the old code and run the old and the new together.  Since the new code can be downloaded in the field without interrupting the execution of the existing code, the new code can execute side by side with the old code and the data collected compared for correctness before the new law takes effect.  When the time comes to switch over to the new code, the old code can easily be stopped and unloaded from the system, all dynamically without restarting the platform or the Java virtual machine.

Improved reliability through automatic garbage collection

Automatic garbage collection refers to the type of memory allocation used on a Java platform.  This one feature of Java alone can account for a forty percent or more increase in programmer productivity and substantially increased system reliability.  The reason for this is best illustrated by an example.  In C or C++, memory allocation during runtime is accomplished through a specific library call such as malloc.  In addition, the programmer must release this memory back to the system with another library call such as free when it is no longer required.  These dynamically allocated memory objects are programmatically referred to by “pointers” that identify the memory address where the memory is located.

Three common programming errors can occur in this type of system.  First the programmer may forget to release or free the memory, which gives the classic memory leak that eventually will lead to an out-of-memory situation.  Second the programmer may use a pointer from a memory location that has already been freed.  This can lead to notoriously difficult debugging situations with bugs that are very hard to reproduce or to pinpoint.  Lastly, the programmer may use a pointer that has not been initialized at all.  All three of these situations can easily lead to a catastrophic failure of the system.

Languages such as Java use automatic garbage collecting schemes to relieve the programmer from dealing with pointers and remembering to release allocated memory.  In these systems, the “garbage collector” is a separate process that examines memory to determine when memory allocated in the program is no longer required and is automatically returned to the system.  The advantages in terms of programming and reliability are clear: engineers are able to spend more time focusing on architecture and less time chasing insidious bugs. The result is higher reliability, faster time to market, easier maintenance, and lower lifetime costs.

Extensive and consistent libraries

While most languages and more specifically compilers for the language have libraries for commonly performed functions, these libraries may not be the same from compiler to compiler.  Java defines a common set of libraries that have a specific behavior independent of the compiler.  Since byte codes are independent of the Java virtual machine, compatibility issues are greatly reduced.

The extensive set of libraries is also a great boon to developers of telematics platforms.  With numerous third-party tools available in Java that can be executed on any platform with a Java virtual machine, enormous time-savings are possible.  Even though the standard template library for C++ contains many of these same functions, these libraries must be available, usually in compiled form, for the specific platform.  With the ambiguities that often arise in C++, many of these function may operate differently on the various platforms.  This again can cause bugs that are very difficult to track down.

Because the Java programming language offers these advantages, it is important to select the proper Java virtual machine for the task.  For example, a Java virtual machine that is appropriate for Web services is not suitable for execution on an embedded or real-time embedded platform.  With the cost of memory and microprocessors rapidly decreasing, embedded manufactures are utilizing larger memory and more powerful CPUs to add value by adding new features to products.  This in turn drives up the complexity of the software and the simplicity and safety inherent in Java becomes more desirable for development.  However, this does not reduce the need for a reliable Java virtual machine in these embedded systems, especially in situations that are safety critical.  The design of a Java Virtual Machine’s automated memory management feature is key to the virtual machine’s success in reliable systems. Below we outline a number of attributes that are not commonly found in garbage collectors that are not designed to be reliable. 

·         Preemptive garbage collection - The garbage collection thread may be interrupted so that high-priority tasks may run deterministically.

·         Incremental garbage collection - Garbage collection is comprised of many small increments of work so that garbage collection resumes where it left off following each preemption.

·         Defragmenting - Live objects are relocated to consecutive memory locations and contiguous free segments are coalesced together into larger free segments in order to improve reliability of the memory allocator.

·         Fully accurate - The garbage collector accurately differentiates between pointers and non-pointers when performing the scan of the heap.

·         Paced - The garbage collection process is configured to make progress at a pace consistent with the application’s allocation rate.

Low-Level Code

It has not always been possible to write 100% of a telematics application in Java. Ordinary Java lacks the features necessary to allow programmers to write device drivers, handle interrupts, respond to sensors within microseconds, exhibit fully deterministic behavior, and other capabilities typically required of complex telematics applications. While 80%-90% of telematics application code can be written in Java for execution on a Java Standard Edition virtual machine, the remaining low level control code must be written in a different way. In the past, the most typical approach would be to write low level code in C, and connect it to Java through the Java Native Interface (JNI), a standardized mechanism for Java communication with other languages.

Some of the problems with a C and JNI approach include:

·         The JNI interface is inefficient.

·         Communication via JNI can violate safe features of Java.

·         Developers are required to learn and maintain two different language platforms.

·         The C code is subject to all the usual problems discussed previously, such as dangling pointers.

Obviously it would be ideal if the C code could be eliminated entirely, and all telematics software could be written in Java. Fortunately, emerging technologies have now made this possible. Under the auspices of the Java Community Process and in cooperation with the Open Group, Java community members have been developing standards (Java Specification Request  #302) for a special profile of the Real-Time Specification for Java that is suitable for control components of complex applications, even those with hard real-time or safety certifiable requirements.

The first technology to reach market from the JSR-302 effort is PERC Pico from Aonix. PERC Pico defines a strict subset of conventional Java and augments Java to make it possible to develop device drivers and handle interrupts. All memory is handled automatically, efficiently, and deterministically through stack-based allocations. The result is control code that is written in Java source code, yet exhibits fully deterministic behavior with speed and size comparable to components written in C. PERC Pico is appropriate not only for device communication, but for any instances of computation-intensive logic where a full garbage-collection virtual machine will not provide satisfactory performance.

We have introduced the software engineer to the general requirements of the telematics system.  Key to achieving the goals of these requirements is the Java virtual machine. In particular, we have shown that requirements are best met with a combination of a high level virtual machine with reliable and predictable garbage collection, along with a low level virtual machine capable of supporting fast and deterministic code and communicating directly with hardware devices.  By understanding the advantages that the Java language and libraries bring to telematics platforms, we also understand that not all Java virtual machines can meet the challenges required in this market.  We have described several features of Java virtual machines that are important to telematics platforms, and these features mostly centered on the memory management (garbage collection) schemes used in the virtual machine.  We have referenced problems that can occur in embedded and real-time embedded systems when certain strategies for garbage collection are followed.  The combination of Aonix PERC Ultra and PERC Pico resolves the identified problems, making it an ideal choice for embedded and real-time embedded systems in telematics and other vertical markets with similar requirements.

References

Link to IVI program: www.its.dot.gov/ivi/ivi.htm

[Calix] Centralized Network Element Platform – Case Study, Calix Networks, http://www.javelocity.com/

[Phipps] Comparing Observe Bug and Productivity Rates for Java and C++. Geoffrey Phipps, ACM Software - Practice & Experience, Volume 29 ,  Issue 4  (April 1999)

[Wells] Java Offers Increased Productivity, Robert Wells, http://wellscs.com/robert/java/productivity.htm

[ZedaSoft] Using Java for Soft Real-Time Simulation, Rob Hatcherson, Keith Holt, Stephen Tarterm, ZedaSoft, Inc., http://www.zedasoft.com

Dr. Nilsen can be reached at kelvin.nilsen@aonix.com.