1 / 17

Comparative Analysis of Cardiac Pacemaker Control Systems in SystemJ and Safety-Critical Java

This study examines the differences between classical and synchronous models of computation in designing safety-critical applications like cardiac pacemakers. It compares the SystemJ and Safety-Critical Java implementations in terms of scheduling policies, real-time analysis, memory models, and more, highlighting the benefits of each approach.

unity-pope
Télécharger la présentation

Comparative Analysis of Cardiac Pacemaker Control Systems in SystemJ and Safety-Critical Java

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The cardiac pacemaker – SystemJ versus Safety Critical Java Heejong Park, Avinash Malik, Muhammad Nadeem, and Zoran Salcic. University of Auckland, NZ

  2. 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.

  3. 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).

  4. 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

  5. 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 modified-CSP style rendezvous between reactions in different clock-domains.

  6. SystemJ syntax

  7. What is each reaction really? input signal S; L1: pause; present (S) emit O1; else emit O2; L2: pause; L1 S/O1 !S/O2 L2

  8. Synchronous composition L2 L1 L1L2 A/B C/D A&&C/{B,D} L2’ L1’ L1’L2’

  9. 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

  10. 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.

  11. 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.

  12. SystemJ – timing model guaranteeing real-time properties A B C • WCRT = • (response time from I to O) = WCRT * 2 • Verifying real-time property: I/{} A B T/{O} C

  13. 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 B d==10

  14. Experimental results • We run the pacemaker on 3 different platforms: • Standard JOP – all SystemJ compiled to simple Java • TP-JOP, separated control and data-processing. • JOP+, JOP with support for reactivity and control processing.

  15. Experimental results Logic Element usage Average Tick times (us) Generated memory footprint (KB)

  16. Conclusions • SystemJ is easier to verify (functional and non-functional): • 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.

  17. Questions?

More Related