Pendekatan Thread Untuk Reduksi Delay Pada Perangkat Lunak Kendali Ventilator

Pendekatan Thread Untuk Reduksi Delay Pada Perangkat Lunak Kendali Ventilator

Sanga Lawalata¹, Bambang Lareno², Hendrik S. Sugiarto³

1,2,3Program Studi Teknologi Informasi, Institut Teknologi Calvin, Indonesia email: bambang.lareno@calvin.ac.id

Abstract

The ventilator must be able to supply oxygen according to the duration and amount required, not more or less. To produce the expected oxygen levels, air pressure and air flow, all these stages and processes are controlled electronically through software. However, in its development, the software to control ventilator often encounter delay problems. One of them is related to the work of the alarm. Therefore, futher investigation is needed to reduce the delay.

In this research, thread concept approach is proposed. In this approach, the synchronous process is pushed to an asynchronous thread with a non-blocking process, in which the main running process is not blocked. As a result, the delay time decreased significantly, by 98.24% on the average value.

Keywords: ventilator alarm, mechanic ventilation, software, control system Abstrak

Ventilator harus tepat menghembuskan oksigen sesuai durasi dan jumlah yang diperlukan, tidak boleh lebih atau kurang. Untuk menghasilkan kadar oksigen, tekanan udara dan aliran udara yang diharapkan, maka semua tahapan dan proses ini dikontrol secara elektronik melalui perangkat lunak. Namun dalam pengembangannya, perangkat lunak kontrol ventilator ini sering menghadapi masalah delay. Salah satunya terkait kerja alarm. Karena itu perlu diteliti lebih lanjut, bagaimana cara mereduksi delay tersebut. Dalam penelitian ini diusulkan pendekatan menggunakan thread. Pendekatan ini memindahkan proses synchronous ke dalam thread yang bersifat asynchronous dan proses non-blocking sehingga tidak memblok proses utama yang sedang berjalan. Hasilnya waktu delay menurun signifikan, sebesar 98,24%

pada nilai rata-rata.

Kata kunci: alarm ventilator, ventilasi mekanik, perangkat lunak, sistem kontrol

1. PENDAHULUAN

Keterbatasan jumlah ventilator, sebagai salah satu alat medis paling dibutuhkan dalam menangani COVID-19 dan gangguan pernafasan lainnya, tentu menjadi masalah. Sehingga beberapa perguruan tinggi terdorong membuat ventilator untuk membantu mengatasi masalah tersebut. Ventilator sendiri adalah suatu alat yang dapat menghembuskan oksigen ke dalam paru-paru pasien, mengeliminasi karbon dioksida dan membantu kerja otot pernafasan.

Jika hanya melihat fungsinya, ventilator tidak terlalu rumit. Namun, terapi ventilasi mekanik menggunakan ventilator cukup kompleks [1].

Sejatinya pembuatan ventilator harus reliabel (dapat diandalkan) karena

pengujian ekstensif [3]. Pengujian itu membutuhkan waktu paling sedikit dua tahun. Ini adalah periode paling panjang dalam proses pembuatan ventilator. Karena itu sebagian institusi termasuk perguruan tinggi akhirnya membuat ventilator dengan fungsi yang paling esensial yaitu membantu pernafasan dengan mode CPAP (Continuous Positive Air Pressure) [4].

Sebagiannya lagi, mengembangkan mode ventilasi yang berbeda.

Institut Teknologi Calvin ambil bagian dengan mengembangkan ventilator mode Volume Controlled-Continuous Mandatory Ventilation (VC- CMV) [5]. Perbedaan mode ini dengan CPAP adalah mode ventilasi CPAP dioperasikan ketika kondisi pasien masih sadar untuk membantu oksigenasi ke paru-paru pasien, sedangkan mode CMV umumnya digunakan ketika pasien tidak sadar atau mengalami kesulitan nafas [4][5].

Meski demikian, dalam mode ventilasi apapun, ventilator harus dapat diandalkan menyediakan udara dengan kadar oksigen, tekanan, aliran dan volume yang diharapkan sesuai kebutuhan pasien. Semua tahapan dan proses dikontrol secara elektronik menggunakan beberapa sensor dan valve yang diintegrasikan dengan sistem minikomputer [6]. Karena itu, diperlukan sebuah perangkat lunak sistem kendali ventilator. Institut Teknologi Calvin mengembangkan perangkat lunak yang diberi nama Vivent. Perangkat lunak dikembangkan menggunakan konsep service layer pattern. Vivent terbagi menjadi dua layer yaitu UI dan Service. Service merupakan inti yang mengatur semua fungsi dari ventilator seperti inhale exhale algorithm, alarm dan proses pengambilan nilai dari sensor, misalnya flow sensor.

Di sisi lain, alarm merupakan bagian penting dari sistem ventilator [7]

karena memberikan peringatan apabila ada nilai yang tidak sesuai misalnya tekanan udara, kecepatan udara yang disediakan ventilator sampai menunjukkan berapa persen kapasitas baterai yang masih tersisa sebelum diisi kembali. Sehingga Vivent VC-CMV membutuhkan minimal 4 alarm dan akan bertambah seiring dengan penambahan fungsi.

Pada pengembangan perangkat lunak tahap pertama, sistem berjalan normal. Namun, sewaktu alarm menyala, alarm akan menjalankan fungsi play_sound() yang akan berjalan dalam beberapa waktu. Hal ini akan menyebabkan tundaan (delay), dikarenakan play_sound() adalah synchronous process dimana proses akan dijalankan sampai selesai baru program akan berjalan ke process selanjutnya. Setiap alarm akan menjalankan play_sound() sampai alarm dimatikan. Sensitivitas kontrol putar (Control Knob) menjadi menurun. Terjadi lag antara pergerakan kontrol putar dan respon indikator pada control monitor (Gambar 1) dan aksi tertentu yang diharapkan, meskipun hanya dalam hitungan sepersekian detik.

Gambar 1. Tampilan Control Knob dan Control Monitor pada Vivent Dengan demikian perlu diteliti lebih lanjut, bagaimana cara mengurangi delay tersebut. Dalam hal ini diusulkan pendekatan menggunakan thread.

Jadi fokus penelitian ini adalah: “Apakah pendekatan thread dapat mereduksi delay akibat alarm pada perangkat lunak kontrol ventilator?”

2. METODOLOGI PENELITIAN

Penelitian ini memakai metode penelitian eksperimen, yaitu metode yang bertujuan untuk menguji pengaruh suatu variabel terhadap variabel lain atau menguji bagaimana hubungan sebab akibat antara variabel yang satu dengan variabel yang lainnya, digunakan untuk mencari pengaruh perlakuan tertentu terhadap yang lain dalam kondisi yang terawasi (supervised) [8]. Metode eksperimen yang digunakan terdiri: (1) Persiapan dan Pengumpulan data awal (precondition-tanpa thread), (2) Metode yang diusulkan, (3) Eksperimen (postcondition-dengan thread), (4) Hasil eksperimen dan Evaluasi hasil.

2.1 . Persiapan dan Pengumpulan Data Awal

Komponen terkait yang digunakan: (1) Rotary Knob KY-040. (2) Panel display 5 inch TFT Resistive touch screen display, Resolusi 800x480, HDMI input, LCD driver IC ILI9486L, Refresh rate 60HZ; (3) Rasberry Pi 4 model B.

Untuk kebutuhan pembandingan dan validasi hasil, perlu dilakukan pengambilan data awal. Data awal yang dihimpun adalah data delay yang terjadi akibat berfungsinya alarm. Besaran yang diukur adalah waktu antara perubahan pada kontrol putar (control knob) dengan tampilan parameter

Gambar 2. UML proses precondition

Pengukuran dilakukan dengan rekaman video dengan kepekaan frame mikrodetik(ms). Dalam perekaman dilakukan perubahan kontrol putar. Total didapatkan 110 data delay. Data hasil pengukuran precondition (kondisi tanpa thread) ditampilkan pada Tabel 1. Data delay yang diambil diluar 0.01 detik (10 ms) standar pengaturan knob [9].

Tabel 1. Data delay precondition Parameter Delay

Rata-rata 92,38 ms

Maks 243,00 ms

Min

Deviasi 26,00 ms

39,08 ms 2.2 . Metode Yang Diusulkan

Pendekatan yang diusulkan untuk mereduksi delay adalah thread.

Thread merupakan pendekatan perangkat lunak untuk meningkatkan kinerja sistem operasi dengan mengurangi overhead thread setara dengan proses klasik. Setiap thread dimiliki tepat satu proses dan tidak ada thread yang bisa ada di luar suatu proses. Thread mewakili bagian dari program yang dapat dijalankan secara independen [10]. Memiliki thread dengan cara ini, diperkirakan dapat meningkatkan kinerja aplikasi secara signifikan, yaitu dengan memindahkan proses synchronous ke dalam thread yang bersifat asynchronous dan non-blocking sehingga tidak menghalangi proses utama yang sedang berjalan.

2.3 . Eksperimen

Kode dikembangkan dengan pengaturan tertentu dalam menerapkan notasi UML sebagaimana terlihat pada Gambar 3. Fungsi alarm (pressure dan voltage) digambarkan dengan objek Alarm yang mempunyai properti Bell, yang akan memainkan suara lonceng pada saat method .play() dipanggil.

Method .play() bersifat synchronous yang berarti proses komputasi akan berhenti dan menunggu sampai method play() selesai atau suara alarm selesai dimainkan.

Gambar 3. UML proses postcondition

Dilakukan beberapa kali pengujian kode sampai didapatkan hasil yang cukup baik, yaitu delay secara rata-rata kurang dari 1/10 detik (10 ms).

3. HASIL DAN PEMBAHASAN 3.1. Hasil

Pengukuran hasil postcondition (kondisi dengan thread) dilakukan dengan rekaman video dengan kepekaan frame mikrodetik (ms). Perekaman meliputi 110 kali perubahan kontrol putar. Dengan demikian didapatkan 110 data delay. Data delay yang diambil juga diluar 0.01 detik (10 ms) standar pengaturan knob [9]. Data hasil pengukuran ditampilkan pada Tabel 2.

Tabel 2. Data delay postcondition Parameter Delay Rata-rata 1,62 ms

Max 15,00 ms

Min

Deviasi 0,00 ms

2,35 ms

Kode lolos uji dan dapat memberikan hasil yang baik sebagaimana Tabel 2, untuk Bell.py dan Alarm.py, adalah sebagai berikut:

Bell.py

def __init__(self):

self.__is_mute = False self.__is_play = False def run(self):

while True:

if (not self.__is_mute) and self.__is_play:

beepy.beep(sound=1) time.sleep(2)

self.log.error("ERROR %s: IT MUST NOT QUIT", "AlarmSound") def unmute(self):

…

def mute(self):

…

def stop(self):

… Alarm.py class Alarm ():

def __init__():

self.bell = Bell()

def on_bell_mute_timeout(self):

self.on_alarm_state_change.emit() def turn_on(self, error_message=None):

…

self.bell.play()

def turn_off(self, error_message):

…

self.bell.stop() def is_muted(self):

return self.bell.is_muted() def mute(self):

self.bell.mute() …

def unmute(self):

…

self.bell.unmute()

Jadi, dengan memindahkan Bell menjadi sebuah thread, proses play() berlangsung didalam sebuah proses baru yang berada diluar proses utama.

Threading akan membagi sumber daya komputer seperti memori dan akses I/O dan menentukan kapan sebuah proses berjalan dan berhenti supaya proses lain dapat berjalan.

Proses menjalankan suara alarm berjalan secara paralel dengan tidak memblok proses utama yaitu program ventilator sehingga fungsi GUI yang berhubungan dengan knob dapat berjalan hampir tanpa delay sewaktu proses beep() berlangsung.

3.2. Evaluasi

Secara umum, dengan membandingkan nilai agregasi dari kedua data hasil precondition dan postcondition (Lihat Tabel 3). Dapat terlihat bahwa penurunan (reduksi) waktu yang cukup signifikan. Untuk rata-rata delay, penurunan mencapai 98,24%, sedangkan penurunan untuk deviasi delay mencapai 93,99%.

Tabel 3. Reduksi delay

Parameter Delay

Pre Post Reduksi

Rata-rata 92,38 ms 1,62 ms 98,24%

Max 243,00 ms 15,00 ms -

Min

Deviasi 26,00 ms

39,08 ms 0,00 ms

2,35 ms -

93,99%

Pola penurunan delay akan dianalisis lebih dalam melalui perbandingan distribusi data delay response sebelum dan sesudah penerapan thread. Untuk mempermudah analisis, pada Gambar 4 di bawah ini, perbandingan distribusi antara delay precondition dan delay postcondition diperlihatkan dalam bentuk boxplot.

Dapat dilihat bahwa pada distribusi delay precondition, terjadi kasus delay yang mayoritas berada di antara 50-100 ms. Selain itu, terdapat beberapa kasus delay yang hampir menyentuh 250 ms. Di sisi lain, dapat dilihat bahwa distribusi delay postcondition hanya berada di kisaran mendekati nol. Ini adalah indikator bahwa setelah diterapkan pedekatan thread, kasus delay yang ditemukan sangatlah minim. Dengan demikian dapat disimpulkan bahwa mekanisme ini telah berhasil mereduksi delay yang ada secara signifikan.

Gambar 4. Perbandingan Boxplot Distribusi Delay

Selanjutnya, perbandingan distribusi dari kedua data akan dianalisis melalui bentuk histogram terhadap data delay. Distribusi tanpa thread, menunjukan tipe distribusi dua puncak atau multimodal distribution [11].

Dimana puncak pertama dalam rentang 59-70 ms dan puncak kedua dalam rentang 103-114 ms. Sedangkan dengan pendekatan thread dihasilkan distribusi satu puncak (Gambar 5).

Gambar 5. Perbandingan Histogram Distribusi Delay

Bentuk distribusi yang membentuk dua puncak mengindikasikan ada beberapa komponen penggerak yang saling bertumpuk sehingga terkadang menghasilkan delay yang lebih lama. Sedangkan pada kondisi hardware sama, mekanisme thread telah berhasil mereduksi distribusi dua puncak ini menjadi satu puncak saja. Dengan demikian, pendekatan thread tidak hanya berhasil mengurangi delay secara signifikan tetapi juga telah berhasil menormalisasi kondisi sistem alarm.

Selain itu, terlihat pada Gambar 5, bahwa distribusi delay postcondition terletak pada posisi yang melampaui 99% persentil dari distribusi delay precondition. Fakta ini menunjukan bahwa kedua distribusi tersebut telah terpisahkan secara signifikan dimana delay postcondition memiliki distribusi yang terpisah dan jauh lebih rapat jika dibandingkan dengan delay precondition.

Untuk memperkuat dukungan klaim ini, maka validasi statistik akan digunakan. Jika diamati dari Tabel 3 terdapat rata-rata perbedaan 90,76 ms antara delay precondition dan delay postcondition. Pertama, akan menggunakan statistik t-test [11] untuk menentukan apakah selisih ini signifikan dengan menggunakan nilai yang relatif ketat ( ). Dari hasil perhitungan, maka didapatkan t-value = 24,196 dan p-value di kisaran 10^-63. Nilai p-value yang sangat kecil ini menunjukan bahwa selisih delay ini tervalidasi secara signifikan.

Selanjutnya, karena kedua distribusi tersebut memiliki bentuk yang unik (multi-modal dan skew), maka dipilih statistik non-parametrik two- sample Kolmogorov-Smirnov test [11] untuk membandingkan perubahan bentuk distribusinya. Melalui analisa statistik tersebut, maka didapatkan p- value di kisaran 10^-65. Nilai p-value yang sangat kecil ini menunjukan bahwa perubahan distribusi antara delay precondition dan delay postcondition tervalidasi secara signifikan.

4. SIMPULAN

Dari eksperimen yang dilakukan dan hasil yang diperoleh, dapat disimpulkan bahwa memindahkan playing sounds yang bersifat sync dan blocking ke dalam sebuah thread membuat proses tersebut menjadi async dan non-blocking. Hal ini membuat aplikasi dapat melakukan proses-proses sharing dengan menghentikan sesaat proses yang sedang berjalan untuk melakukan proses lain sehingga menghasilkan user experience yang baik.

Dugaan bahwa mekanisme thread akan mereduksi delay, terbukti dan tervalidasi secara statistik

DAFTAR PUSTAKA

[1] Yuan, L., “Chapter 13: Troubleshooting and Error Reporting”, Medical Ventilator System Basics: A clinical guide, Oxford University Press, Oxford, 2017.

[2] Beloncle, F., Piquilloud L., Olivier, P.Y., Vuillermoz, A., Yvin, E. and Richard, A. M. &. J.-C., “Accuracy of P0.1 measurement performed by ICU ventilators: a bench study”, Annals of Intensive Care, vol. 9, no. 104, pp.

135-143, 2019.

[3] Savary, D., Lesimple, A., Beloncle, F., Morin F., Templier, F., Broc, A.,

[4] BRIN, “Siaran Pers No. 117SP/HM/BKKP/VIII/2020”, Badan Riset dan Inovasi nasional, Jakarta, 2020.

[5] Kreit, J.W., “Chapter 5: Ventilator Modes and Breath Types”, in Mechanical Ventilation: Physiology and Practice, 2nd ed., Oxford University Press, Oxford, 2017.

[6] Yuan, L., “Chapter 9: Ventilator Control Parameters”, Medical Ventilator System Basics: A clinical guide, Oxford University Press, Oxford, 2017.

[7] Walsh, B.K. and Waugh, J.B., “Alarm Strategies and Surveillance for Mechanical Ventilation”, Respiratory Care, vol. 65, no. 6, pp. 820-831, 2020.

[8] Sugiyono, “Metode penelitian: Kuantitatif, Kualitatif dan R&D”, Penerbit Alfabeta, Bandung, 2018.

[9] Joy-IT, “KY-040 Rotary encoder”, Neukirchen-Vluyn, Joy-IT Published under CC BY-NC-SA 3.0, German, 2017.

[10] Silberschatz, A., Galvin, P.B., and G. Gagne, G., “Operating System Concepts”, 10th Ed., John Wiley & Sons, 2018.

[11] Selvamuthu, D. and Das, D., “Introduction to Statistical Methods, Design of Experiments and Statistical Quality Control”, Springer Nature Singapore, 2018.