The Cardiac Pacemaker – SystemJ versus Safety

Download Report

Transcript The Cardiac Pacemaker – SystemJ versus Safety

The cardiac pacemaker – SystemJ
versus Safety Critical Java
Heejong Park, Avinash Malik, Muhammad Nadeem,
and Zoran Salcic.
University of Auckland, NZ
Why is it interesting?

Study difference between classical (RTOS) model of
computation vs. the synchronous model of
computation

Improved state representation and formal
functional and non-functional (timing) verification of
programs designed in reactive languages

Different design decisions for implementing the
same safety critical application.
Approach taken for comparison

Implementing the cardiac pacemaker
control logic in SystemJ and comparing
with the SCJ implementation.

Features compared:
◦ Scheduling policies
◦ Real-time and response-time analysis
◦ Memory model (if you are interested, after
the presentation).
The cardiac pace-maker control
logic – DDDR operating mode
• The dips below the X-axis
are the pacing signals
• Scenario D: A normal
working heart.
• Scenario A: Atrial and
ventricle pace are
produced
• Scenario B: Only atrial
pace produced
• Scenario C: Only ventricle
pace produced
The general SystemJ model of
computation
Globally Asynchronous
Locally Synchronous
(GALS) MoC.
 Signals are used for
communication within
each synchronous island
(clock-domain).
 Channels and modifiedCSP style rendezvous
between reactions in
different clock-domains.

SystemJ syntax
What is each reaction really?
L1
S/O1
!S/O2
L2
input signal S;
L1: pause;
present (S) emit O1;
else emit O2;
L2: pause;
Synchronous composition
L1
A/B
L2
L1L
2
C/D
L1’
L2’
A&&C/
{B,D}
L1’
L2’
The cardiac pacemaker in SystemJ

Only synchronous
parallel composition

All communication via
signals

Input and Output to
the heart model also via
signals

No need for
asynchrony, because
only one mode runs at
any given time
SCJ vs. SystemJ – functional
correctness



States are explicitly demarcated at pause
Smaller state space compared to SCJ
Every FSM transition is atomic
◦ Easier to verify, since synchrony avoids interleaving
altogether.
◦ Further reduction in state space, because change in signals
(and update of data) is not visible until completion of
transition.

We verified for the pacemaker liveness properties
(via SPIN model-checker)
◦ If Ventricle/Atrial sense is not detected Ventricular/Atrial
pace will always be generated.
SCJ vs. SystemJ – tasks and scheduling model

Task priority
◦ SCJ needs unique priority for each task
◦ All SystemJ reactions have equal priority (or no priority)

Task ordering
◦ Priorities and schedule together determine task-ordering in SCJ
◦ Reactions in SystemJ can be run in any order – more optimization chances, outputs
are always deterministic.

Response time
◦ SCJ (RTOS) definition – time from release to completion of a task.
◦ Time from one or more inputs to generation of one or more outputs via one or more
tasks (reactions/CDs) interacting together.

Event handling
◦ SCJ supports Periodic and Aperiodic event handlers, no sporadic events (?) and what
happens with multiple incoming events?
◦ SystemJ can be considered to have only sporadic event handling with minimum
statically guaranteed inter-arrival time. Multiple events can always be captured.
SystemJ – timing model guaranteeing real-time
properties
A
A
𝑊𝐴𝐵
I/{}
𝑊𝐶𝑅𝑇
B
B
𝑊𝐵𝐶
T/{O}
𝑊𝐶𝑅𝑇
C
C
WCRT = max(𝑊𝐴𝐵 , 𝑊𝐵𝐶 )
 𝐼 → 𝑂 (response time from I to O) =
WCRT * 2
 Verifying real-time property: []𝐼 →⋄𝑀 𝑂

SCJ vs. SystemJ

Timers
◦ SCJ handles timing via one shot timer
handlers, triggered via external timers
◦ SystemJ converts wait statements to logical
time – bounded self-transitions.
 The resultant system is still real-time analyzable.
 The wait is exact.
𝑊𝐶𝑅𝑇
d<10
A
𝑊𝐶𝑅𝑇
d==10
B
Experimental results

We run the pacemaker on 3 different
platforms:
◦ Standard JOP – all SystemJ compiled to simple
Java
◦ TP-JOP, separated control and dataprocessing.
◦ JOP+, JOP with support for reactivity and
control processing.
Experimental results
Logic Element usage
Average Tick times (us)
Generated memory footprint (KB)
Conclusions

SystemJ is easier to verify (functional and nonfunctional):
◦ One is just programming an automaton
◦ Reduced state space representation, every change in
data/signal is not a new state, only pause makes a new
state





Time (real and logical) is a first class language
construct.
SystemJ allows handling multiple events, since it is
clock-driven.
No preemption of transitions, preemptions only
allowed once transition is finished.
Correct by construction achieved via SPIN and SMT.
Verified, pacemaker control-logic implemented in
SystemJ.
Questions?