In Pursuit of Safety-Critical Java _ COTS Journal

Document Sample
In Pursuit of Safety-Critical Java _ COTS Journal Powered By Docstoc
					In Pursuit of Safety-Critical Java | COTS Journal                

     In Pursuit of Safety-Critical Java
     The world of safety-critical software and the world of Java are no longer estranged. Efforts are underway to craft
     specifications and platform solutions for safety-critical Java.
     By Kelvin Nilsen, Ph.D., Chief Technology Officer,Aonix

     Compared with other high-level programming languages like C and C++, Java offers productivity benefits from two-
     to ten-fold greater than those earlier languages. By carefully applying Java technologies to embedded real-time
     systems, software engineers have been able to deliver higher software quality, increased functionality and greater
     architectural flexibility in software systems.

     The domain of safety-critical systems spans the spectrum from software whose anomalous behavior might result in
     catastrophic failure of a commercial aircraft (requiring DO-178B Level A certification) to software that might cause
     or contribute only to a minor failure condition for an aircraft (requiring DO-178B Level D certification). Similar
     classification systems are in place for other industries, such as nuclear power generation, railway transportation and
     various medical devices. Table 1 compares which applications fall into which safety category.

     As systems increase in life-threatening safety criticality, the required development methodologies grow more
     specialized, and the certification audits become more rigorous. In general, safety certification audits require that
     developers enforce software processes that are much more conservative than the industry practice for development of
     mainstream software.

     Climbing Costs

     The required rigor for testing, inspection and traceability analysis add significantly to the costs of software
     development and force developers of safety-critical systems to forego many of the convenience features that yield
     significant developer productivity improvements in traditional software markets. In the past, this has required
     developers of the most critical safety systems to use highly specialized tools and technologies that have little
     relevance to the broader development community. Because the audience for their use is so small and specialized, tool
     licenses have been expensive and the tool functionality has been very limited in comparison to similar tools targeting
     broader markets.

     Though the Ada programming language continues to be the best technical solution for safety-critical development,
     some safety-critical developers are seeking to leverage more mainstream technologies in their safety-critical
     development. Some of their stated motivations are:

       Improved ability to recruit developers familiar with their selected programming languages and development

         Improved access to general-purpose development tools and off-the-shelf reusable software components

         Greater open-market competition between a larger number of competing technology providers

     To address this market need, the Open Group’s Real-Time and Embedded Forum has hosted a sequence of meetings
     that focus on creation of a safety-critical Java standard.

1 of 5                                                                                                                4/26/2005 2:45 PM
In Pursuit of Safety-Critical Java | COTS Journal              

     The Open Group

     The Open Group’s Real-Time and Embedded Forum has been exploring development of a safety-critical Java subset
     since April of 2002. In 2003, members of this forum began collaborating on a draft of a Java Specification Request
     (JSR). Unanimous approval for the wording of the JSR was achieved in May of 2003. Since then, the Real-Time and
     Embedded Forum has met regularly to advance the safety-critical Java specification.

     Within the Open Group, two approaches to satisfying the stringent requirements of safety-critical development with
     the Java language have been proposed. The “Ravenscar-Java” approach was initially proposed by graduate student
     Jagun Kwon in collaboration with Professor Andy Wellings and Lecturer Steve King of the University of York, with
     certain refinements proposed by James Hunt and Fridtjof Siebert of Aicas GmbH. The other approach, known as
     “Scalable-Java”, has been put forth by the author of this article.

     While there are subtle differences between the two candidate proposals, they share certain common objectives and
     approaches. In particular, both proposals:

       Encourage a hierarchy of real-time Java platforms, in which the safety-critical platform is the most restrictive.
     Software targeted to the safety-critical platform will also run on various mission-critical platforms, and development
     tools will be repurposed between safety- and mission-critical development.

       Encourage safety-critical developers to use an enhanced subset of the existing Real-Time Specification for Java
     (RTSJ) first published in 2001. RTSJ defines a framework for deployment of real-time Java software. However, the
     defined framework has many capabilities too complex for safety-critical development that must be eliminated from
     the safety-critical subset. As well, the official framework is missing certain capabilities required in typical
     safety-critical development projects that must be added.

       Prohibit the full generality of RTSJ’s ScopedMemory facilities, which replace automatic garbage collection. Within
     the safety-critical environment, automatic garbage collection will not be supported because this service is considered
     too complex to meet the reliability standards of FAA auditors. Because RTSJ’s ScopedMemory abstraction is also
     considered too complex for safety-certified systems, simplified versions of ScopedMemory have been proposed.

       Introduce standard Java 5.0 meta-data annotations to allow programmers to clarify their intentions with respect to
     composition of independently developed software components.

     The most recent meeting of the Real-Time and Embedded Forum was held in San Francisco late last month. At this
     meeting, it was decided that choices between features of the two proposals would be based on comparisons between
     how the two candidate approaches deal with certain common programming scenarios. The Kwon, Wellings, King,
     Hunt, Siebert team was given the month of February to resolve certain ambiguities in their current proposal, after
     which the author of this document has been assigned the task of developing the comparative case studies. The review
     of this work will take place at the next meeting of the Open Group, calendared for the last week of April in Dublin,

     For its part, Aonix has a hard real-time Java solution available now. The Aonix hard real-time JRTK programming
     environment (Figure 1) blends existing general-purpose C and Java development tools with special-purpose hard
     real-time Java development tools. All of the tools and reusable libraries are available as COTS components. The
     JRTK builder takes responsibility for orchestrating incremental builds of large software systems.

2 of 5                                                                                                              4/26/2005 2:45 PM
In Pursuit of Safety-Critical Java | COTS Journal             

     The JRTK verifier enforces compliance with safety-critical and hard real-time mission-critical programming
     guidelines. These guidelines are much more rigorous than what is enforced by the traditional Java byte-code verifier.
     The JRTK translator converts portable Java byte-code files into stylized portable C-language intermediate files,
     providing easy access to powerful optimizing compilers, profilers and code coverage analyzers for a broad assortment
     of different architectures. The standard JRTK debugger, provided as an Eclipse plug-in, is built by customizing
     Eclipse’s pre-existing C debugger plug-in.

3 of 5                                                                                                             4/26/2005 2:45 PM
In Pursuit of Safety-Critical Java | COTS Journal               

     Why Java is Superior to C and C++

     Reuse and integration of independently developed C/C++ components is difficult for a variety of reasons. First, the
     C/C++ standards make specific provisions for implementation-dependent and implementation-defined language
     features where an integer might be 32 bits on one processor and 64 bits on another. Second, the C/C++ standards do
     not fully specify the behavior of the standard template libraries (STL) or underlying operating system I/O libraries;
     nor does it standardize the collections of services needed from the operating system.

     All that is especially true for low-level device I/O, interrupt handling and multithreading capabilities, which depend
     heavily on the underlying real-time operating system, C++ compiler and optimization choices specified when the
     compiler was invoked. Third, both the C++ language and the STL libraries are large, complex and quite difficult to
     understand. Programmers commonly misunderstand the semantics of macro expansions, operator overloading,
     multiple inheritance and other esoteric features, requiring every member of a C++ team to be a C++ compiler expert.

     A typical C or C++ component has buried within it hundreds of implicit dependencies on the target processor, the
     compiler, host operating system and standard template libraries. Assumptions are rarely documented, and most C and
     C++ programmers do not realize that the validity of their code depends on assumptions not necessarily valid in all
     execution environments. All of this means that tremendous additional effort is required to move code to a new
     execution environment, including careful review of source code and thorough retesting of all boundary cases in the
     new execution environment. This almost always results in various revisions to the source code. In the final analysis,
     the C/C++ approach to software reuse is cost-prohibitive.

         Proposed Scalable-Java Approach for Safety-Critical Development:

         A Review of Key Features

         Work continues toward defining a safety-critical subset of Java that would match the deployment efficiency of C
         and C++ with the developer productivity benefits of Java. Detailed descriptions of the draft specification are
         available at Listed here are the highlights of the Scalable-Java proposal.

         In particular, the Scalable-Java platform is designed to:

               Satisfy the stringent requirements of DO-178B Level A certification
               Support performance, memory footprint, and predictable real-time latencies that are comparable to C and
               Support portability and scalability benefits similar to traditional Java
               Standardize the implementations of low-level services such as device input and output, and interrupt
               Allow efficient and safe stack-memory allocation of Java objects, with static compile-time enforcement that
               referential integrity rules are not violated
               Enable upward compatibility with a hard real-time mission-critical Java subset (DO-178B Level C) that uses
               the same compiling, debugging, and profiling tools as are used for safety-critical development
               Make possible secure and efficient integration of hard real-time mission-critical Java components with
               traditional Java components in larger, more dynamic (DO-178B Level C) application

     In contrast, users consistently report favorably of their moves to embedded Java development. Using Java, one

4 of 5                                                                                                               4/26/2005 2:45 PM
In Pursuit of Safety-Critical Java | COTS Journal                          

     developer built a fault-tolerant distributed demonstration in only three days, even though they had previously
     budgeted a “solid three months” to implement the same capabilities using C/C++ targeted to a popular RTOS.
     Another described the final months of a multiple-year project involving hundreds of developers, some working
     exclusively in C and others entirely in Java.

     In the final three months of the project, the team reported that the Java programmers were nowhere to be seen while
     the C programmers were putting in overtime trying to find and correct lingering bugs. A third explained that after a
     failed attempt to develop a complex multi-service telecommunications framework in C, they abandoned the project
     and rewrote the entire system in Java. The result was more functional, maintainable, and reliable. They completed the
     project with one fifth the lines of source code and in half the time, even though they had to retrain their engineers in
     the use of Java.

     Proven Superiority

     The Java programming language has already demonstrated itself superior to C and C++ for development of large and
     complex non-real-time systems. Efforts are under way to define a safety-critical subset of Java that would match the
     deployment efficiency of C and C++ with the developer productivity benefits of Java. This new platform promises
     significant benefits to the safety-critical development community. For a list of the key elements of the proposed
     safety-critical Java scheme, see the sidebar: “Key Features of the Proposed Scalable-Java Approach for
     Safety-Critical Development.”

     Aonix North America
     San Diego, CA.
     (858) 457-2700.

     © 2005 RTC Group, Inc., 905 Calle Amanecer, Suite 250, San Clemente, CA 92673

5 of 5                                                                                                                          4/26/2005 2:45 PM