Using Java in Safety-Critical Applications White Paper

Wolf-Dieter Heker

Rainer Koellner

Verocel, GmbH

Copyright 2017 Verocel GmbH

 

TABLE OF CONTENTS

Using Java in Safety-Critical Applications …………………………………………………..1
1 Abstract …………………………………………………………………………………………………1
2 References …………………………………………………………………………………………….1
3 Introduction ………………………………………………………………………………………… 2
4 What is different with Real-time Java? …………………………………………………… 2
4.1 General aspects of OO…………………………………………………………………………. 2
4.1.1 Class Hierarchy ……………………………………………………………………………….. 3
4.1.2 Dynamic binding …………………………………………………………………………….. 3
4.2 Memory Management ………………………………………………………………………… 3
4.3 Multithreading ………………………………………………………………………………….. 5
4.4 Exception handling ……………………………………………………………………………. 6
4.5 Class initialization ……………………………………………………………………………… 7
4.6 Dynamic Loading ………………………………………………………………………………. 7
4.7 Interpretation versus Compilation ………………………………………………………. 7
5 Requirements for Real-time Java Implementations ………………………………… 8
6 Using Real-time Java with ISO 26262 and DO-332 ………………………………… 10
6.1 Comparison of ISO 26262-6:2011 to DO-178C …………………………………….. 11
6.2 Objectives and Activities for Object Oriented Software ………………………… 13
6.3 Class Hierarchy, Tracing and Type Consistency ………………………………….. 18
6.4 Strategy for memory management …………………………………………………….. 18
6.5 Overloading and type conversion vulnerabilities …………………………………. 20
6.6 Strategy for exception management …………………………………………………… 20
6.7 Reusing components ………………………………………………………………………… 21
7 Verification with JamaicaVM ………………………………………………………………. 23
7.1 Verifying JamaicaVM Applications…………………………………………………….. 23
7.1.1 Storage Requirements ……………………………………………………………………. 23
7.1.2 Execution Time Limits …………………………………………………………………… 23
7.1.3 Exception handling scheme ……………………………………………………………. 24
7.1.4 Guaranteed response times ……………………………………………………………. 24
7.1.5 Interoperability between application code and libraries…………………….. 25
7.1.6 Interoperability with Native Code …………………………………………………… 25
7.2 Verifying Third Party Libraries………………………………………………………….. 25
7.3 Verifying the JamaicaVM Libraries …………………………………………………… 26

7.3.1 Storage Requirements …………………………………………………………………… 26
7.3.2 Execution Time Limits ………………………………………………………………….. 26
7.3.3 Exception handling scheme …………………………………………………………… 27
7.4 Verifying the JamaicaVM Runtime Environment ……………………………….. 27
7.4.1 Verification of the Garbage Collector ………………………………………………. 28
7.5 Verification of Compiler Output ……………………………………………………….. 28
8 Potential Problems …………………………………………………………………………….. 30
9 Conclusion ………………………………………………………………………………………… 31
Appendix A Acronyms ………………………………………………………………………….. 32
Appendix B Example for OO paradigm implemented by switch ………………… 33

LIST OF FIGURES

Figure 6-1 V-model Verification Diagram …………………………………………………………………………………. 12
Figure 7-1 Synchronization points in interpreted versus compiled code ………………………………………. 25
Figure 7-2: Placing Synchronization Points into the compiled code …………………………………………….. 28
Figure 7-3: Certifying the Output of the Compiler………………………………………………………………………. 29
Figure B-1 Example Hierarchy ………………………………………………………………………………………………. 33
Figure B-9-2 Implementation by switch construct in C ………………………………………………………………. 33

1      Abstract

This document provides an analysis of the concerns with using Java, in particular real-time Java, in safety-critical applications. The focus is on hard real-time applications subject to certification based on ISO 26262.  Both safety and timeliness are considered.

As ISO 26262-6:2011 is not specific on activities regarding object-oriented (OO) languages, this document refers to guidance provided for real-time applications in avionics, which have similar certification requirements.  The avionics standard RTCA/DO-178C has an entire supplement on object-oriented technology and related techniques called RTCA/DO-332. DO-332 is used in this document to supplement the lack of detail for object-oriented technology in ISO 26262.

Furthermore, this document outlines a road map of necessary activities for using the aicas JamaicaVM implementation of real-time Java in a safety-critical environment.

2      References

  • ISO 26262-6:2011 (E)
    Road vehicles — Functional safety,
    Part 6: Product Development at the Software Level
  • RTCA/ DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A; RTCA, Inc., December 13, 2011
  • [HRTGC]
    Hard Real-time Garbage Collection in Modern Object-Oriented Languages: Fridtjof Siebert, aicas GmbH; 2002
  • Java
    The Java® Language Specification Java SE 8 Edition; Oracle America, Inc. and/or its affiliates; 2015
  • [RTSJ]
    Real-time and Embedded Specification for Java; Editor James J. Hunt, aicas GmbH
    Version 2.0, Draft 59, General Relativity Edition, March 20, 2017
  • [SCJ]
    Safety-Critical Java Technology Specification, JSR 302, Editor Doug Locke, Version 0.110, Draft, February 2, 2017

 

3      Introduction

Though conventional Java is fine for applications that do not have a time bound, i.e., do not have real-time requirements, it should not be used for control applications. Therefore, this study confines itself to real-time Java.  Real-time Java is defined as a Java implementation that conforms to the RTSJ specification and has a real-time garbage collector (GC).

Certification of real-time Java requires surmounting a number of challenges that procedural languages do not have.  These challenges are identified below, along with a means of overcoming them.  Since certification can only be done on a specific real-time Java implementation, the JamaicaVM has been chosen for this purpose.  This means the study must address issues that are specific to JamaicaVM.  This is rounded out with a proposal for verifying applications that run on JamaicaVM and its runtime environment, with special emphasis on memory management systems.

This study does not distinguish between safety levels; rather it assumes the highest assurance level: ASIL D.

Although there is ongoing work on specifying Safety-Critical Java, it was not considered here for three reasons.  First, the specification is not yet complete. Second, it would severely restrict the language, as only a small number of standard classes are available. Finally, it only supports scoped memory, as stack-like memory management technique, which also severely restricts what Java libraries can be used.  These restrictions drastically limit the compatibility with conventional Java, which is deemed unacceptable for the scope of this paper.  Instead, the semantic refinements and additional APIs of the Real-time and Embedded Specification for Java ([RTSJ]) are considered as providing the extensions necessary for real-time response.