Tutorial: Guidelines for developing real-time and safety-critical embedded Java software - Part 4 - Embedded.com

Tutorial: Guidelines for developing real-time and safety-critical embedded Java software – Part 4

A good working definition of safety-critical Java code is that it issoftware that must be certified according to DO-178B or equivalentguidelines. Certification guidelines impose strict limits on softwarepractices, including peer review, traceability analysis, and softwaretesting.

More specifically safety-critical Java uses a subset of the fullhard real-time mission-critical capabilities, covered in the firstthree parts in this series. While it supports the notion of scopedmemory, it hides the RTSJ APIs that manipulate memory scopes. Instead,safety-critical Java programmers describe their intentions with respectto use of scoped memory by using annotations which can be staticallyanalyzed and enforced at compile time.

Following are 14 rules tofollow when doing Java development in safetycritical applications :

Rule 1. Except where indicated tothe contrary, use hard real-time programming guidelines
In general, all of the hard real-time guidelines are appropriate forsafety-critical development, except that certain practices acceptablefor hard real-time mission-critical development should be avoided withsafety-critical software (as indicated in the subsequent rules).

Rule 2. Use only 28 priority levelsfor NoHeapRealtimeThread
The official RTSJ specification states that a compliant implementationmust provide at least 28 priorities, but may support many more. Forsafety-critical development, application software should limit its useof priorities to the range from 1 though 28. Vendors can readilysupport this priority range as a standard safety-critical platform.

Rule 3. Use only instances ofCOMPLIANT-mode NoHeapRealtimeThread
In safety-critical systems, the sharing of data and control betweennative code and safety-critical Java code should be avoided ifpossible. This is because native code cannot be scrutinized by thesafety-critical byte-code verifier.

Rule 4. Prohibit use of@OmitSubscriptChecking annotation
In safety-critical code, turning off subscript checking is stronglydiscouraged, even though static analysis of the program presumably hasproven that the program will not attempt to access invalid arrayelements. In safety-critical systems, the key benefit of subscriptchecking is to prevent an error in one component from propagating toother components.

Rule 5. Prohibit use of @OmitScopeChecking annotation
In safety-critical code, turning off assignment scope checking inmethods that permit @AllowCheckedScopedLinks is strongly discouraged, even though careful inspection of the programmay have determined that the program will not attempt to makeassignments that would violate nested scoping rules.

Rule 6. Prohibit invocation ofmethods declared with the @AllowCheckedScopedLinks annotation
This annotation is designed to allow programmers to use practices thatcannot be certified safe by automatic static theorem provers. Thus,there is a risk that any software making use of this annotation willabort with a run-time exception. Allow this practice only insafety-critical systems for which developers are able to provideabsolute proof that run-time exceptions will not be thrown.

Rule 7. Require all code to be @StaticAnalyzable
In hard real-time mission-critical code, the use of the @StaticAnalyzable annotation isentirely optional. In safety-critical code, we require all componentsto have this annotation, and for all relevant modes of analysis to havea true value for the enforce_time_analysis,enforce_memory_analysis, and enforce_non_blocking attributes.

Rule 8. Require all classes withSynchronized virtual methods to inherit PCP or Atomic
The safety-critical profile does not allow the use of priorityinheritance locking.

Rule 9. Require all classes withSynchronized static methods to inherit StaticPCP or StaticAtomic
The safety-critical profile does not allow the use of priorityinheritance locking.

Rule 10. Prohibit dynamic classloading
While dynamic class loading may be supported in the hard real-timemission-critical domain, it should be strictly avoided insafety-critical software.

Rule 11. Prohibit use of blockinglibraries
Because of difficulties analyzing blocking interaction times whensoftware components contend for shared resources, all services thatmight block are forbidden in safety-critical code. Specifically, it isrecommended to avoid use of the following APIs in safety-criticalapplication software:

java.lang.Object.wait() java.lang.Object.wait(long) java.lang.Object.wait(long, int) javax.realtime.util.sc.NoHeapRealtimeThread.join() javax.realtime.util.sc.NoHeapRealtimeThread.join(long)
javax.realtime.util.sc.NoHeapRealtimeThread.join(long,int)
javax.realtime.util.sc.NoHeapRealtimeThread.sleep(long)
javax.realtime.util.sc.NoHeapRealtimeThread.sleep(long,int)
javax.realtime.util.mc.ThreadStack.join() javax.realtime.util.mc.CountingSemaphore.P()javax.realtime.util.mc.SignalingSemaphore.P() javax.realtime.util.mc.Mutex.enter()

Rule 12. Prohibit use of PriorityInheritance MonitorControl policy
Priority inheritance is more difficult to certify, more complicated toimplement, and less efficient than priority ceiling emulation. Also,the implementation of priority inheritance introduces synchronizationoverhead delays that are proportional to the complexity of theapplication, rather than a function only of the system configuration.Analyzing these delays is particularly difficult. For all of thesereasons, we prohibit its use in safety-critical software systems.

Rule 13. Do not sharesafety-critical objects with a traditional Java virtual machine
Combining safety-critical code with traditional Java code using the @TraditionalJavaMethod and @TraditionalJavaShared conventionscompromises the integrity of the safety-certification artifacts. Thispractice is therefore strictly forbidden.

Rule 14. Use development tools toenforce consistency with safety-critical guidelines
To enforce that programmers make proper use of the safety-criticalsubset and that all code is consistent with the intent of the hardreal-time programming annotations described in this section, usespecial byte-code verification tools that help assure reliable andefficient implementation of programmer intent.

KelvinNilsen, Ph.D. is chief technology officer at Aonix North America

To read Part 1 go to Alternatives to garbage collection
To read Part 2 go to Soft Real-TimeDevelopment Guidelines
To read Part 3 go to Hard Real-TimeDevelopment Guidelines

References:

[1] Guidelines for Scalable Java Development of Real-Time Systems,available at http://research.aonix.com/jsc/rtjava.guidelines.3-28-06.pdf

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.