A Pro le for Safety Critical Java - Aalborg Universitetpeople.cs.aau.dk/~bt/DAT5E07/henrik3.pdf · Figure 1. Class structure of the pro le with application threads 3.2 Schedulable

A Profile for Safety Critical Java

Martin Schoeberl Hans Søndergaard Bent ThomsenAnders P. Ravn

Præsenteret af: Henrik Kragh-Hansen

November 8, 2007

Introduktion Valg af features/begrænsninger Safety Critical Java Implementation Eksempel Konklusion

Forfatterne

Martin Schoeberl

Udvikler af JOP processoren

Hans Søndergaard

Lektor ved Vitus Bering Denmark

Bent Thomsen

Lektor ved Aalborg Universitet

Database og programmerings teknologier

Lokale: 3.2.38

Anders P. Ravn

Professor ved Aalborg Universitet

2/20


Artiklen

Udgivet ved

Proceedings of the 10th IEEE International Symposium onObject and Component-Oriented Real-Time DistributedComputing

Bidrag

Profil til Hard Real-Time systems

Er ikke et RTSJ subset

Profil til aJile og JOP

3/20


Hvorfor en ny profil?

RTSJ

Er for generel

Mange dynamiske features

Ravenscar-Java

Subset af RTSJ

Fjerner usikre features

Stadig for kompleks

4/20


Safety Critical Java

Baseret pa:

JSR-302 specification request

DO-178B standard

Design mal

Nemt framework

Simpel program analyse

Nemt at implementere pa indlejrede systemer

Minimal implementations detaljer

Skal kunne læres pa under en dag

5/20


Oversigt

1 Valg af features/begrænsninger

2 Safety Critical Java

3 Implementation

4 Eksempel

5 Konklusion

6/20


Thread ændringer i forhold til RTSJ

Parametre i constructoren til RealtimeThread

Scheduling

Processing group

Hukommelse parametre og omrader

Initializer thread

Skal laves eksplicit i RTSJ

Laves i stedet i main metoden i SCJ

waitForNextPeriod

Er fjernet

Handteres af scheduleren

7/20


Release parametre

Prioritet ikke nødvendigt

Bruger release og deadline tid

Bliver prioriteret af scheduleren

Schedulability kan verificeres

Cost

Ikke en del af profilen

Skal checkes af et tool offline.

8/20


Et overblik over SC Java profilen

Indeholder følgende

Periodic threads (PeriodicThread)

Sporadic threads (SporadicThread)

Runtime systemet (RealtimeSystem)

Tidsbegreb (RelativeTime)

Hukommelses tilgang

9/20


Klasse struktur af threads

#run() : boolean#cleanup() : boolean

RealtimeThread <<abstract>>

PeriodicThread <<abstract>>

+fire()

SporadicThread <<abstract>>

MyPeriodicThread MySporadicThread

Figure 1. Class structure of the profile withapplication threads

3.2 Schedulable Entities

All schedulable entities (periodic and sporadic) are rep-resented by threads. The structure of real-time threads isshown in Figure 1. The abstract class RealtimeThread hastwo methods:

• run() the run logic to be executed every time the threadis activated

• cleanup() a clean-up method to be executed if the sys-tem should be shut down or stopped

We have considered two different design patterns forspecializing it: through subclassing or through delegationto a Runnable via a parameter in the constructor. If sub-classing is used, the run method with the run logic is im-plemented in a subclass of PeriodicThread or Sporadic-Thread classes. This supports the static architectural pat-terns that we envisage for applications. In contrast, delega-tion through a parameter gives an illusion that the run logicmight be changed dynamically during execution. As a resultof the arguments in Section 2.2, we have in this profile cho-sen to introduce the run logic through subclassing. This alsomeans that the PeriodicThread and SporadicThread classesare declared abstract, see Figure 1.

For sporadic events we bind each event to a single thread.The event/thread relation is a 1:1 relation (same as in theoriginal Ravenscar-Java, different to the RTSJ). Therefore,periodic threads and sporadic event threads are very similar.Both contain program logic that gets released by an event.For a periodic thread this event is generated by the elapsingtime, for a sporadic thread either by an hardware event (in-terrupt) or an software event (invocation of fire()). Figure 1shows the simple class hierarchy.

package javax.safetycritical;

public abstract class RealtimeThread {

protected RealtimeThread(RelativeTime period,RelativeTime deadline,RelativeTime offset, int memSize)

protected RealtimeThread(String event,RelativeTime minInterval,RelativeTime deadline, int memSize)

abstract protected boolean run();

protected boolean cleanup() {return true;

}}

Figure 2. The base class for all schedulableentities

We use a single class (RealtimeThread) to expressall schedulable entities (periodic time-triggered, softwareevent-triggered, and hardware event-triggered). Figure 2shows the definition of RealtimeThread.

The run() method has to be overwritten for the appli-cation logic – that is the same abstraction as in standardjava.lang.Thread. The difference to j.l.Thread is that themethod is abstract and it has to return a boolean result.Declaring it abstract forces the programmer to implementrun(). The return value is used for the shutdown as describedin Section 3.3.1. The method cleanup() is invoked duringthe shutdown phase.

For a periodic real-time entity the run() method is peri-odically invoked, for a sporadic entity when the software orhardware event happens. We are not using the loop con-struct with waitForNextPeriod() as in the RTSJ.

The class is abstract and extended by PeriodicThreadand SporadicThread. Figure 3 shows the two class def-initions. PeriodicThread is just a wrapper for a periodicRealtimeThread. SporadicThread has an additional methodfire() to implement software events. After invoking fire() ona SporadicThread, the thread gets released by the scheduler.

3.2.1 Release Parameters

All time values are specified by the class RelativeTimewhich is similar to the same class in the RTSJ. However, weremove all methods that can change the time value. The re-sulting objects are immutable. Immutable time values guar-antee that the release parameters cannot be changed duringthe mission phase.

10/20


Sammenlignet med RJ

Figure 7. Thread and Handler classes: RJ(left), our SCJ proposal (right)

mentation on top of the RTSJ [4]. We use the Sun version(Mackinac [3]) on top of Solaris for a standard PC. So farwe have not found any issues that make it impossible to im-plement the proposed specification on top of the RTSJ.

4.1 Structuring the API

To obtain compatibility with the RTSJ a safety criticalAPI can be structured in at least three ways:

• as a subset of RTSJ at the method level

• as a new API with an RTSJ-compliant binding

• mirroring the RTSJ class structure

Ravenscar-Java has chosen the first approach. We havechosen the second approach in our profile.

The two different approaches mirror two of the mostcommon techniques for reusing functionality in object-oriented systems [9]: class inheritance, also called white-box reuse and object composition, also called black-boxreuse.

At the definition of real-time threads in RTSJ (and con-sequently in Ravenscar-Java) the class inheritance patternhas been used. This approach has shown to be a problem-atic design choice, resulting in inheritance of all the pub-lic methods from the java.lang.Thread class. In contrast tothis, using the object composition pattern results in smalland clean thread classes with precisely those methods youwant to specify.

Asynchronous events and their handlers were in RTSJintroduced almost totally separated from the real-timethreads. However, over time a better classification of eventsin periodic events (time-triggered) and sporadic events(event-triggered) has evolved. Yet, structuring a profile as asubset of RTSJ using the class inheritance pattern compli-cates the design of a new profile, see Figure 7. Also herethe object composition pattern gives a cleaner solution.

4.2 Verification and Tools

A real-time application has to be verified, at minimumthe WCET and a schedulability analysis. For usage of dy-namic memory we propose automatic/compiler generationof scoped memory. The worst-case memory consumption(WCMC) has to be analyzed.

For the implementation on JOP we can use the availableWCET analyzer [18]. However, a tighter integration withthe profile (e.g., automatic selection of the run() method tobe analyzed) and a schedulability analyzer is still missing.

4.3 Standard Library

The RTSJ assumes the standard JDK or at minimum aJ2ME verison of the JDK (CLDC or CDC). However, thespecification is very silent about how and if those libraryfunctions can be used within a real-time application. Weneed following information for the library:

1. Dynamic memory allocation

2. Worst-case execution time

3. Blocking time

There is not much work available how to solve those issues.The Javolution project [8] provides substitutes for the col-lection classes where elements are recycled. In that case wedo not need a garbage collector for collections.

In [10] the Java Modeling Language (JML) is used todescribe pre- and post-conditions for methods to describeloop bounds. The descriptions are than proven by KeY, asemi-automated prover. Data flow analysis propagates thebound information to all call sites and the results can beintegrated into an ILP based WCET analyzer (e.g., [18]).

Exceptions need dynamic memory and are an issue e.g.,for the implementation of an RTSJ compliant JVM. A prag-matic, but not correct, approach is to pre-allocate the datastructures for all possible exceptions in immortal memoryand reuse them. Besides need for dynamic memory excep-tions are also problematic with respect to WCET. A bet-ter approach is to avoid exceptions by a defensive program-ming style. The absence of runtime exceptions can then beproved formally [19].

5 Conclusion

In this paper we have presented a simple real-time Javaprofile for safety critical systems. Instead of building ontop of RTSJ using the class inheritance pattern, we have de-signed our profile by using the object composition pattern.

Simultaneously, we have gone through RTSJ, Ravenscar-Java, and the SC Java proposal to find the points where these

11/20


RealtimeThread

public abstract class RealtimeThread {protected RealtimeThread(RelativeTime period, RelativeTime deadline,

RelativeTime offset, int memSize)

protected RealtimeThread(String event, RelativeTime minInterval,RelativeTime deadline, int memSize)

abstract protected boolean run();

protected boolean cleanup() {return true;

}}

12/20


Eksekveringsforløb i SCJ

Figure 5. Application states

Those three states are inspired by the states in a MIDlet,but they are also based on industrial experiences from real-time systems which need to shut down in a controlled way.

3.3.1 Shutdown

In contrast to RJ we provide an additional phase for the real-time application: Shutdown. This phase is intended to pro-vide a safe termination of the real-time system; e. g. threadshave a chance to bring actuators into a safe position. Theshutdown phase is initiated similar to the start of the mis-sion phase, by invoking stop() from RealtimeSystem.

However, we can not simply stop all threads, but need aform of cooperation. All real-time threads return a booleanvalue from the run() method. This value indicates: I’mready for a shutdown. When a thread is in a critical op-eration, where a shutdown is not allowed, the thread justreturn false to delay the shutdown process. In the first sub-phase the runtime system waits for all threads to be readyfor shutdown before actually switching to cleanup.

In the second sub-phase, all tasks are notified throughcalls to the cleanup() method that clean up is in progress.During the shutdown the cleanup() method is invoked peri-odically2 instead of the run() method. The cleanup methodreturns true to signal that its task has safely completedits shutdown responsibilities. If the return value is false,cleanup() will be called again; if the return value is true,the thread is terminated. The possibility of several cleanupinvocations allow threads to resolve mutual dependenciesduring shutdown and spread the cleanup work so that alltasks can still meet their deadlines. Shutdown terminateswhen all threads are terminated.

3.4 An Example

Figure 6 shows a short example how to write a real-timeapplication with the proposed profile. One periodic threadprints a message each second and fires the software eventon every second iteration. The sporadic thread handles thesoftware event and prints a message. After 10 iterationsthe periodic thread requests a shutdown from the runtimesystems. On behalf of this shutdown the method cleanup()gets invoked once.

2at the same period as the former run() method

public class PeriodicSporadic {

public static void main(String[] args) {

final SporadicThread rte =new SporadicThread("SWEVENT",

new RelativeTime(2000, 0)) {

protected boolean run() {System.out.println("SW event fired");return true;

}};

new PeriodicThread(new RelativeTime(1000, 0)) {int counter = 0;protected boolean run() {

System.out.println("P1");++counter;if (counter%2==1)

rte.fire();if (counter==10)

RealtimeSystem.stop();return true;

}

protected boolean cleanup() {System.out.println("cleanup!");return true;

}};

RealtimeSystem.start();}

}

Figure 6. An example of a real-time applica-tion

4 Implementation

It is mandatory to provide a reference implementation forthe specification and evaluate it with some application testcases. An implementation of a first draft of the proposedspecification is available on the Java processor JOP [17], aswell as on the aJ100. The implementations are light-weightand use the already available real-time thread implemen-tations [16, 20]. In [16] it has been shown that the JOPscheduler performs quite will. Tasks with periods down to100 μs can be scheduled on a 100 MHz version of JOP. Thescheduling code base is industry proven as it is in produc-tion in three applications.

Furthermore, we are currently also working on an imple-

Tilstande

Initialized

Alle objekter oprettesLaves i main metoden

Mission

Alle trade startes

Stop

Run returnerer booleanCleaup kaldt i stedet for run

13/20


Implementation af SCJ

Implementeret til JOP og aJile

Simpel implementation

Bruger eksisterende thread implementation

API

Et nyt API i stedet for subset af RTSJ

Bruger object composition

Sma rene klasser

14/20


Standard libraries

Problemer med eksisterende libraries

Dynamisk hukommelse allokering

Darlig WCET, fokusere pa average

Javolution

Genbruger hukommelse

Fokuserer pa WCET, men garanterer ingen WCET

Fokuserer pa predictability frem for plads forbrug

15/20


Standard libraries

Problemer med eksisterende libraries

Dynamisk hukommelse allokering

Darlig WCET, fokusere pa average

Javolution

Genbruger hukommelse

Fokuserer pa WCET, men garanterer ingen WCET

Fokuserer pa predictability frem for plads forbrug

15/20


Standard libraries

Canteen

Tilbyder List, Set og Map

Tilbyder statisk analyse af WCET

Kaster ikke exceptions i mission phase

Ingen hukommelses allokering i mission phase

Understøtter generics

Kompatibel med standard Java interface

16/20


public class PeriodicSporadic {public static void main(String[] args) {

final SporadicThread rte = new SporadicThread("SWEVENT",new RelativeTime(2000, 0)) {

protected boolean run() { return true; }};new PeriodicThread(new RelativeTime(1000, 0)) {

int counter = 0;protected boolean run() {++counter;if (counter%2==1) rte.fire();if (counter==10) RealtimeSystem.stop();return true;

}protected boolean cleanup() { return true; }

};RealtimeSystem.start();

}

}

17/20





int counter = 0;protected boolean run() {

++counter;if (counter%2==1) rte.fire();if (counter==10) RealtimeSystem.stop();return true;



}

}

17/20









}

}

17/20









}

}

17/20


Hvorfor bruge profilen?

Fordele

Simpel profil

Henvendt til sikkerheds kritiske systemer

Object composition pattern

Kun applikations specifikke krav

Kræver tools til analyse af

WCET

Scheduling

Worst-case memory consumption

18/20


Min mening om artiklen

Fordele

Nem at læse

God struktur

Simpel og elegant løsning

Ulemper

Mangler lidt detaljer om tools

JOP og aJile implementation er ikke ens

19/20

Spørgsmal?

Documents

A Pro le for Safety Critical Java - Aalborg Universitetpeople.cs.aau.dk/~bt/DAT5E07/henrik3.pdf · Figure 1. Class structure of the pro le with application threads 3.2 Schedulable