Towards Programming Safety Critical Systems in Java

1. Towards Programming Safety Critical Systems in Java Bent Thomsen Aalborg University

2. Joint work with: • Martin Schoeberl • Institute of Computer Engineering Vienna University of Technology, Austria • Hans Søndergaard • Vitus Bering University College • Stephan Korsholm • Polycom (former KIRK telecom) and CISS • Anders P. Ravn, Thomas Bøgholm, Henrik Kragh-Hansen, Petur Olsen, Kim G. Larsen, Rene R. Hansen and Lone Leth Thomsen • CISS/Department of Computer Science Aalborg University

3. Computers today A computer is a grey box full of black smoke. When the black smoke escapes the computer does not work any more Anonymous CS student

4. Some have a broader view

5. But what about these?

6. Especially this one • JOP - Java Optimized Processor

7. Embedded Systems • Computer purchased as part of some other piece of equipment – Typically dedicated software (may be user customizable) – Often replaces previously electromechanical components – Often no “real” keyboard – Often limited display or no general purpose display

8. Real-time Systems Landscape • Interaction software • Psychology • Signal processing • Compute as much as possible within deadline • Media processing • QoS, graceful degradation • Control software • Catastrophic consequences of missed deadlines

9. High Integrity Embedded Real-Time Systems • Implemented in hardware • Customized components • Hardware specific software • Poor reusability • Specially trained programmers • Assembler and C (and C++) dominate embedded systems programming • Still at lot of Ada programming going on

10. What is the problem? • Sheer number of systems • Poor programmer productivity • Fewer and fewer C/C++ programmers

11. How to increase Programmer Productivity? 3 ways of increasing programmer productivity: • Process (software engineering) • Controlling programmers • Good process can yield up to 20% increase • Tools (verification, static analysis, program generation) • Good tools can yield up to 10% increase • Better designed Languages --- the center of the universe! • Core abstractions, mechanisms, services, guarantees • Affect how programmers approach a task (C vs. SML) • New languages can yield 700% increase

12. Why Java • Easy to learn • Early (first) programming language • Object oriented • Industrial strength • Platform independent • Concurrent • (Almost) Well-defined semantics

13. Java is all around us 1B installed base in 2006 2004 2005 2006 2007 2008

14. Even in space

15. Java Disadvantages wrt. Real-time • Unpredictable performance • Scheduling • Memory • Control and data flow • Automatic garbage collection • Dynamic class loading

16. Real-Time Specification for Java • RTSJ for short • First JSR request (JSR-001) • Still not completely finished • Implementations • Timesys RI • OVM (Purdue) • PERCS (AONIX), • JamaicaVM (AICAS) • McKinack (SUN) based on Hotspot • Websphere (IBM) based on J9

17. RTSJ Guiding Principles • Backward compatibility to standard Java • Write Once, Run Anywhere • Reflects current real-time practice • Predictable execution • No Syntactic extension • But subtle changes to semantics • Allow implementation flexibility

18. RTSJ Overview • Clear definition of scheduler • Priority inheritance protocol • NoHeapRealtimeThread • BoundAsyncEventHandler • Scoped memory to avoid GC • Low-level access through raw memory • High resolution time and timer • Targeted at larger systems • implementation from Sun requires a dual UltraSparc III or higher with 512 MB memory and the Solaris 10 operating system

19. RTSJ Subset • Ravenscar Java • Name from Ravenscar Ada • Based in Puschner & Wellings paper • Profile for high integrity applications • RTSJ compatible • No dynamic thread creation • Simplified scoped memory • Targeted at Java 2 Micro Edition • Implementations? • Partial on aJ-100 at CISS/AAU

20. Observation There is essentially only one way to get a more predictable language: • Namely to select a set of features which makes it controllable. • Which implies that a set of features can be deselected as well

21. The bottom up approach • take the Java language and its associated VM • provide low level access to physical memory (and interrupts), • add an interface to a scheduler which is some mechanism that gives predictability to thread execution, and which implements some policy that is specified through release and scheduling parameters, • add an interface to some memory areas controlled by mechanisms that may give more predictable allocation of objects, • add some mechanism to make synchronization more predictable, • add new classes of asynchronous events and their handlers, and internal event generators called timers related to clocks, • and try to come to terms with asynchronous transfer of control and termination.

22. Life is complicated enough • apart from 1 and 2, the remaining ”enhancements” complicate life for a programmer • source program for an application becomes a mixture of • application specific requirements • (deadlines, periods, binding of external events, and program logic), • parameters for controlling policies of the underlying middleware mechanisms • (cost, priority, importance, event queue sizes, memory area sizes), • parameters for tuning or sidestepping the mechanisms • (miss handlers, timers).

23. SC Java Our Target Community Real-Time Computing Control Engineering Control in Real-Time Computing Real-Time Programming Techniques in Control System Implementation

24. A typical embedded program Cruise control: Loop Read the sensors; Compute speed; if speed too high Compute pressure for brake pedal; if speed too low Compute pressure for accelerator; Transmit the outputs to actuators;

25. FTIR instrument Interfero-gram enclosed in a Thermobox FOSS WineScan Case Study • FTIR technology: Fourier Transform Infrared Spectroscopy

26. Interferometer functional requirements The instrument • Temperature reading and regulation • thermobox, cuvette, interferometer, IR-source • reading: 5 times/sec • regulation: 1 time/sec • Interferometer measurement • move the mirror and read IR-detector • every 333 µs • up to 3200 times in a scan • an interferometer measurement • 32 scans Thermobox

27. Our approach • the Java language and machine supported by existing RT mechanisms and policies • low level access to hardware, since hardware abstraction layers are yet in the future • plus periodic and sporadic threads with application specific parameters, including program logic

28. The Aim • An easy to use framework • Simplified program analysis • Easy to implement on embedded systems • Minimum implementation details • J2ME programmers should be able to learn to use SC Java in a day

29. SC Java Programming Model Initialized: An RT application is in the Initialized state until the initialization code of the RealTimeSystem has run to completion and its start method has not been invoked. Application threads and passive objects are created and initialized here. Threads are not started. Mission: An RT application is in the Mission state when it has returned from its start method which starts all threads. Stop: An RT application is in the Stop state when it has returned from the stop method which waits for threads to perform their optional cleanup.

30. Difference to RTSJ • No Initializer Thread • Done as part of main method • No WaitForNextperiod • Scheduler does this • No priorities • Programmer Specify deadline and periods • Scheduler calculates priorities

31. Only few concepts • Periodic Threads • Sporadic Threads • RunTimeSystem • Relative Time • Immortal and Raw Memory

32. Schedulable Entities All schedulable entities (periodic and sporadic) are represented by threads. The abstract class RealtimeThread has two methods: • run() • the run logic to be executed every time the thread is activated • cleanup() • a clean-up method to be executed if the system should be shut down or stopped Initialize is done in main()

33. The Class Diagram

34. The RealtimeThread Class

35. PeriodicThread

36. SporadicThread

37. The Runtime System

38. An example

39. Implementations of SC Java • On Ajile aJ-100 and JOP • Use existing schedulers and threads • On Mechatronic Brick and Polycom (Kirk) • Currently experimenting with JamVM • Implementation on RTSJ underway

40. What about Program Analysis? • Traditional approaches to analysis of RT systems are hard and conservative • Alternatives via: • Java PathFinder • SARTS • WCET and Schedulability on JOP

41. Utilisation-Based Analysis • A simple sufficient but not necessary schedulability test exists Where C is WCET and T is period

42. Solve by forming a recurrence relationship: The set of values is monotonically non decreasing When the solution to the equation has been found, must not be greater that (e.g. 0 or ) Response Time Equation Where hp(i) is the set of tasks with priority higher than task i

43. Java Code Bytecode void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; } JAVAC JVM 0: iconst_0 1: istore_2 2: goto #39 5: getstatic 8: aload_0 9: iload_2 10: aaload Model Checker Special JVM Java PathFinder

44. SARTS • WCET and Schedulability analyzer for Java programs written in the SCJ profile (PRTJ) • Assumes correct Loop bounds annotations • Generated code to be executed on JOP • Generates Timed Automata • Control flow graph with timing information • Uppaal Model-checker checks for deadlock

45. SARTS Overview

46. Java to UPPAAL

47. Translation of Basic Blocks into states and transitions Patterns for: Loops Monitor statements If statements Method invoke Sporadic task release Timed Automata templates

48. Predefined models Scheduler Periodic Task Sporadic Task Simple models of RM scheduler

49. Periodic Task/Sporadic Task

50. Example One periodic task Two sporadic tasks Mutually exclusive SARTS can do better than utilisation test