RTOS atau bukan RTOS adalah pertanyaannya

Saya diminta untuk menulis artikel ini dengan cabang komentar yang panjang (sayangnya saya tidak dapat menyebut ini sebagai diskusi) ke artikel saya yang terbaru “Dunia yang beragam dari sistem embedded dan tempat Embox di dalamnya” . Saya dicela di beberapa tempat karena membingungkan RTOS dan Embedded OS, yang saya sebut LynxOS, QNX dan VxWorks bukan RTOS, meskipun menurut saya, tentu saja, saya tidak melakukannya. Saya menyarankan penulis komentar ini beberapa kali untuk menulis artikel di mana ia akan menyatakan visinya tentang konsep "sistem operasi real-time", tetapi untuk beberapa alasan ia menolak. Baiklah, saya akan menyampaikan visi saya tentang istilah ini, dan mari kita bahas apa yang disebut RTOS dan apa yang tidak. Pada akhirnya, pertanyaan ini sering ditanyakan sehubungan dengan Embox .

Istilah OS RV (RTOS) mengacu pada bidang pemasaran!

Saya berpikir untuk memulai dengan cara ilmiah, dengan memperkenalkan istilah-istilah, tetapi memutuskan bahwa tesis provokatif ini akan disambut dengan sangat baik. Jadi, mengapa saya berpendapat bahwa istilah RTOS (sistem operasi real-time) mengacu pada pemasaran, lebih tepatnya, adalah slogan pemasaran (periklanan)? Semuanya sederhana. Ketika suatu produk diproduksi, itu perlu dijual. Tetapi jika Anda mencoba menjual hanya sistem operasinya, kesulitan akan muncul. Di sinilah posisi pasar datang untuk menyelamatkan. Misalnya, Anda bisa mengatakan "kami lebih cepat dari mereka."


Tapi Anda bisa ke pengadilan untuk itu! Dan di sana Anda perlu memberikan bukti. Tetapi bagaimana membuktikan bahwa Anda lebih cepat dalam semua kasus? Ini bukan kompetisi lari. Tetapi tentu saja, persaingan yang tidak sepenuhnya benar semacam itu sedikit keluar dari posisi pasar normal.

Pemosisian normal melibatkan pembentukan potret konsumen, mengidentifikasi sifat-sifat produk yang lebih diminati, dan berfokus pada sifat-sifat ini. Baik, atau Anda membentuk kebutuhan ini di pengguna. Misalnya, prosesor kami memiliki frekuensi seperti itu, smartphone memiliki prosesor N-core, dan sebagainya.

Karena klasik genre telah merumuskan bahwa sistem operasi diperlukan tidak hanya untuk sistem pengguna, tetapi juga untuk mengendalikan berbagai proses teknologi dalam mode otomatis, dan bahkan memperkenalkan konsep sistem operasi real-time, maka, Anda tahu, itu dosa untuk tidak menggunakannya. Memperkenalkan konsep sistem real-time, klasik berbicara tentang ambang waktu kritis tertentu. Artinya, ini berbeda dari sistem konvensional, di mana jika pengguna menunggu sesuatu, maka dia bisa menunggu, sistem real-time yang keras, misalnya, mengendalikan turbin, tidak bisa menunggu, kalau tidak Anda dapat beralih ke sesuatu yang buruk.

Dengan demikian, Anda dapat memberi tahu pengguna bahwa, tidak seperti sistem operasi konvensional, mereka akan diberikan sistem yang menjamin waktu respons sistem. Secara alami, semakin kecil, semakin banyak jumlah proses teknologi yang dapat dikontrol oleh sistem. Dan banyak tabel muncul di mana berbagai parameter kunci RTOS diberikan sebagai parameter kunci.

Bagaimana mereka diterima? Proses ini dijelaskan dengan jujur! Di sini kita mengambil masalah model ini dan itu, ini dan itu platform perangkat keras, dan menerapkan efeknya. Nah, pemasaran, tentu saja, dapat menyederhanakan dan memberi, waktu reaksi 1 μs. Tapi kami tidak memperhitungkan ini, kami percaya bahwa semuanya dijelaskan dengan jujur.

Tapi permisi, bagaimana jika ada tugas lain? 10 tugas, 100 tugas? Dan jika kunci programmer mabuk mengganggu? Dan jika dalam sistem programmer tidak memprioritaskan tugas dengan benar?

Ada kasus ketika Embox lulus tes secara real time. Kami duduk dan berpikir bagaimana membuktikan bahwa ini adalah sistem operasi real-time. Ada laboratorium, ada pelanggan yang menginginkannya demikian. Kami mengetahui bahwa untuk pelanggan waktu-nyata berarti waktu respons sistem adalah 1 μs. Saya bertanya apakah percobaan berikut akan menjadi bukti:

• Kami mengambil platform perangkat keras tertentu
• Terapkan sinyal ke salah satu input GPIO
• Secara terprogram menangkap suatu peristiwa
• Pada keluaran GPIO, kami secara terprogram memberi sinyal
• Pengukuran dilakukan menggunakan osiloskop, waktu reaksi akan menjadi perbedaan antara input dan output front.

Pelanggan menegaskan bahwa inilah yang dibutuhkan. Saya mengajukan pertanyaan klarifikasi, dan kami sedang merancang sistem model dan mungkin tidak memulai (tidak memuat) dengan tugas lain. Artinya, normal bahwa sistem hanya akan melakukan tugas tes yang sederhana. Pelanggan mengatakan bahwa ini membutuhkan tugas pengujian. Mungkin Anda sendiri mengerti bahwa sistem telah lulus tes! Secara alami, dengan konfirmasi karakteristik, yaitu dampaknya berulang.

Bagian ini sama sekali tidak ditulis untuk meremehkan OS atau pengembang apa pun. Tetapi semata-mata untuk menunjukkan seluruh ketidaklengkapan gambar. Saya tidak mengklaim bahwa karakteristik beberapa sistem operasi tidak memungkinkan mereka untuk dikaitkan dengan RTOS, tetapi istilah ini hanya digunakan oleh pemasar. Saya melihat tes lain ketika saya memesan pilihan sistem operasi laboratorium independen berdasarkan persyaratan tugas. Ada serangkaian tugas model yang kompleks, dan interaksi jaringan dipertimbangkan, dan bagaimana parameter berubah jika sistem dimuat, dan perilaku dalam berbagai situasi darurat.

Definisi istilah "sistem operasi waktu-nyata"

Sekarang saya akan memperkenalkan istilah "sistem operasi Real-time". Tidak, saya tidak akan. Faktanya adalah bahwa ada banyak definisi dari istilah ini. Setidaknya ambil komentar di artikel asli:

Dalam sistem waktu nyata, seseorang pada umumnya berlebihan dan, karenanya, kecepatan sistem waktu nyata harus dibandingkan dengan proses yang dikontrolnya, apakah itu mobil otonom atau sistem kontrol proses di sebuah pabrik.

SRV / RTOS - ini semata-mata sebuah peringkat pada prediktabilitas respons terhadap peristiwa kritis.

RTOS adalah OS semacam itu di mana kebenaran suatu tugas tidak hanya dicirikan oleh kebenaran logis, tetapi pada saat yang dibutuhkan untuk menyelesaikan tugas ini.

Tetapkan kriteria untuk mengalihkan konteks tugas apa pun menjadi 1 μs per prosesor 100 MHz dengan floating-point coprocessor dengan penentuan 0,1 μs dan semuanya akan jatuh ke tempatnya.
Anda akan melihat dengan jelas di mana RTOS dan di mana tidak.

Yah, saya tidak bisa mengabaikan pendapat yang saya bicarakan dalam sebuah artikel yang disuarakan di salah satu konferensi OSDAY :

Suatu sistem dapat dianggap sebagai sistem waktu-nyata yang sulit jika tidak memiliki tempat di mana, dengan interupsi yang dikunci, ada siklus dengan jumlah iterasi yang tidak diketahui.

Tapi mungkin itu semua hanya khusus, dan seperti yang disarankan dalam komentar , Anda hanya perlu menggunakan klasik dan tidak membuat sepeda. Saya akan mengutip klasik yang ditentukan (Andrew Tanenbaum, jika seseorang tidak menebak):

“Jenis lain dari sistem operasi adalah sistem real-time. Sistem ini ditandai dengan memiliki waktu sebagai parameter kunci. Misalnya, dalam sistem kontrol proses industri, komputer waktu nyata harus mengumpulkan data tentang proses produksi dan menggunakannya untuk mengendalikan mesin di pabrik. Seringkali ada tenggat waktu yang sulit yang harus dipenuhi. Misalnya, jika mobil bergerak di jalur perakitan, tindakan tertentu harus dilakukan pada saat tertentu. Jika robot pengelasan dilas terlalu awal atau terlambat, mobil akan hancur. Jika tindakan mutlak harus terjadi pada saat tertentu (atau dalam rentang tertentu), kami memiliki sistem waktu-nyata yang sulit. Banyak dari ini ditemukan dalam kontrol proses industri, avionik, militer, dan area aplikasi serupa. Sistem ini harus memberikan jaminan mutlak bahwa tindakan tertentu akan terjadi pada waktu tertentu.

Jenis lain dari sistem waktu nyata adalah sistem waktu nyata lunak, di mana kehilangan batas waktu sesekali, meskipun tidak diinginkan, dapat diterima dan tidak menyebabkan kerusakan permanen. Sistem audio atau multimedia digital termasuk dalam kategori ini. Telepon digital juga merupakan sistem waktu nyata yang lunak.

Karena memenuhi tenggat waktu yang ketat sangat penting dalam sistem waktu-nyata, kadang-kadang sistem operasi hanyalah sebuah perpustakaan yang dihubungkan dengan program aplikasi, dengan segala sesuatu digabungkan secara erat dan tidak ada perlindungan antara bagian-bagian dari sistem. Contoh dari sistem real-time jenis ini adalah e-Cos.

Kategori perangkat genggam, sistem tertanam, dan sistem waktu nyata tumpang tindih secara signifikan. Hampir semuanya memiliki setidaknya beberapa aspek waktu nyata yang lunak. Sistem tertanam dan waktu nyata hanya menjalankan perangkat lunak yang dimasukkan oleh perancang sistem; pengguna tidak dapat menambahkan perangkat lunak mereka sendiri, yang membuat perlindungan lebih mudah. Handheld dan embedded system ditujukan untuk konsumen, sedangkan sistem real-time lebih untuk penggunaan industri. Meskipun demikian, mereka memiliki jumlah tertentu yang sama. ”

Tetapi dari uraian ini hanya mengikuti bahwa sistem dapat digunakan dalam sistem di mana tidak adanya reaksi dalam periode tertentu dapat menyebabkan konsekuensi bencana. Nah, untuk mencapai parameter kunci (tidak melebihi waktu reaksi), OS bisa menjadi perpustakaan, contoh dari eCos.

Cara mencapai karakteristik real-time

Saya tidak bisa memberikan definisi yang ketat (jika seseorang siap memberi, tulis di komentar). Tetapi dalam semua definisi di atas, beberapa properti terlihat (kali ini dan dapat diprediksi). Jika Anda menerjemahkan waktu ke dalam opsi prediktabilitas (bobot busur saat berpindah dari satu kondisi ke kondisi lain), maka hanya prediktabilitas yang tersisa!

Mari kita pikirkan bagaimana mencapai ini.

Jelas akan menghapus semua yang tidak perlu dari sistem kritis. Sistem universal sepertinya tidak akan stabil. Bahkan Kamerad Tanenbaum membicarakan hal ini, maksud saya, ketika dia berbicara tentang eCos.

Pendekatan lain yang meningkatkan prediktabilitas sistem, sekali lagi, diusulkan oleh Tanenbaum , adalah penggunaan algoritma khusus (sederhana) untuk perencanaan sumber daya, terutama waktu prosesor, yaitu, penjadwal tugas khusus. Dia menyarankan beberapa pendekatan untuk perencanaan, tetapi saya ingin fokus pada tabel yang digerakkan oleh tabel statis terlebih dahulu.

Pengembang harus memastikan bahwa semua tugas berhasil menyelesaikan irisan waktu mereka. Untuk melakukan ini, diusulkan untuk menganalisis secara statis tugas kritis dan menentukan nilai ambangnya. Pendekatan ini ditetapkan dalam standar ARINC-653. Standar untuk sistem on-board, dan Anda sendiri mengerti, jika sesuatu tiba-tiba tidak punya waktu untuk bekerja di pesawat, maka malapetaka bisa terjadi.

Pendekatan selanjutnya adalah jadwal statis, tetapi didasarkan pada prioritas. Artinya, pengembang harus menganalisis kembali semua situasi dan, setelah menetapkan semua tugas dalam prioritas sistem, memastikan bahwa tugas-tugas penting diselesaikan pada waktu tertentu.

Saya tidak ingin melanjutkan, karena ada yang asli! Itu ditulis, tentu saja, lebih baik daripada yang bisa saya lakukan, dan di samping itu, mereka dapat dituduh mengubah fakta. Saya mengutip dengan tepat pendekatan ini untuk menunjukkan bahwa dalam hal apa pun, pengembang sistem akhir memiliki tanggung jawab untuk memastikan karakteristik sistem. Dan sistem operasi seharusnya hanya menyediakan kemampuan yang sesuai.

Melanjutkan diskusi tentang metode untuk meningkatkan prediktabilitas, saya ingin memberikan komentar lain

"Anda dapat mencapai waktu nyata dengan raspberry, tetapi tidak dengan RTOS, tetapi dengan mesin negara kecil yang membobol cache-nya."

Di sini saya ingin memperhatikan beberapa hal berikut:

• peningkatan prediktabilitas (properti waktu nyata) karena pengecualian RTOS dari sistem
• representasi program oleh mesin negara
• Yah, ketergantungan sistem waktu-nyata tidak hanya pada sifat-sifat perangkat lunak, tetapi juga pada perangkat keras.

Dengan penurunan jumlah ketidakpastian dalam kasus penurunan jumlah baris kode, saya pikir semua orang setuju. Meskipun, seperti biasa, saya tidak setuju, tetapi lebih pada nanti.

Apa pengaruh perangkat keras juga kemungkinan besar tidak diragukan. Secara khusus, ketika dikatakan bahwa tidak ada loop dengan jumlah iterasi sewenang-wenang dalam keadaan interupsi terkunci, terdengar bahwa pada beberapa korteks-m dalam RTOS yang dijelaskan tidak ada pemutusan interupsi sama sekali. Ini sedikit licik, karena di sana pengendali interupsi menonaktifkan interupsi dengan prioritas yang sama atau lebih rendah, secara independen, tetapi fakta pengaruh jelas. Dan tentu saja, keberadaan cache, terjemahan alamat (atau lebih tepatnya ketinggalan pada halaman), berkontribusi pada ketidakpastian. Terutama, saya ingin menarik perhatian pada kenyataan bahwa, pada kenyataannya, tidak ada yang bisa menjamin seratus persen pengoperasian peralatan yang benar. Nah, postingan jatuh dari Anda, bagaimana kehadiran RTOS akan membantu untuk menghindari hasil bencana?

Representasi program sebagai mesin negara, saya ingin mengusulkan untuk mempertimbangkannya dari sisi yang tidak jelas. Yaitu, bahwa program prediktabilitas dapat dianalisis. Dan karena kita berbicara tentang semua kondisi, maka itu harus dianalisis, dan secara statis, untuk semua situasi yang mungkin terjadi. Yah, karena bahasa pemrograman fungsional jauh lebih cocok untuk analisis statis, adalah mungkin untuk mengembangkan suatu program dalam beberapa bahasa khusus, atau menambahkan penggunaan bahasa pemrograman khusus. Pendekatan pertama digunakan, misalnya, di kernel seL4 terverifikasi. Contoh dari pendekatan kedua adalah standar ARINC-653 yang sama, dengan pembentukan persyaratan wajib dalam XML.

Ada metode lain yang meningkatkan prediktabilitas atau, jika Anda suka, faktor yang mempengaruhi prediktabilitas sistem. Saya membuat laporan tentang topik ini di salah satu konferensi OSDay . Secara khusus, selain yang sudah terdaftar, saya telah menyoroti pendekatan arsitektur. Lagi pula, sudah diketahui bahwa, misalnya, arsitektur microkernel dapat meningkatkan prediktabilitas sistem. Tetapi bahkan dalam laporan yang sama, pendekatan organisasi yang agak tidak jelas ditekankan. Ini hanya tentang titik di mana saya tidak setuju bahwa kurangnya RTOS menyebabkan peningkatan kemampuan prediksi. Jika Anda memikirkannya, maka secara umum konsep sistem operasi telah secara signifikan mengurangi jumlah kesalahan karena penggunaan kembali kode. Artinya, jika Anda tidak memiliki kode yang benar-benar cocok menjadi satu saklar / kasing, maka lebih baik menggunakan modul yang sudah jadi. Setelah semua, parameter "jumlah kesalahan per 1000 baris kode" belum dibatalkan, dan tidak peduli seberapa debug kode baru Anda, ada kesalahan.

Apakah RTOS ada?

Setelah menyelesaikan pernyataan di bagian sebelumnya bahwa ada kesalahan dalam kode apa pun, saya ingin membuat satu tesis yang lebih provokatif. Apakah RTOS ada?

Mari kita cari tahu. Membahas dengan seorang teman tentang sistem waktu nyata, kami sepakat sejauh bahwa sistem operasi waktu nyata (kita berbicara tentang sistem waktu nyata yang sulit) hampir tidak ada. Dia mengusulkan untuk mewakili seluruh sistem sebagai mesin negara atau grafik dengan deskripsi waktu transisi maksimum dari satu negara ke yang lain. Selain itu, sistem dapat dianggap stabil jika terbukti bahwa untuk semua input dan keadaan internal, ada busur yang mengarah ke keadaan tertentu dengan batas waktu. Anda tahu, ini hanya mungkin untuk sistem yang sangat kecil, hanya mesin negara yang disebutkan dalam komentar, tetapi di dunia modern hanya sedikit orang yang membutuhkan sistem seperti itu.

Tetapi kami tidak ragu bahwa sistem waktu nyata ada. Dan tentu saja, RTOS juga. Jika tidak demikian, maka pelatuk terbang pertama akan menghancurkan peradaban, maka tidak akan ada avionik, astronotika, robot, ACS-TP dan banyak lagi.

Bagaimana keluar dari situasi tersebut. Ini sangat sederhana, meskipun secara umum masalahnya kemungkinan besar tidak dapat diselesaikan, tetapi untuk masalah tertentu, dimungkinkan untuk menerapkan batasan yang membuatnya dapat dipecahkan, dengan beberapa jenis kemungkinan kesalahan yang berarti.

Sebagai contoh, standar diperkenalkan: POSIX realtime , ARINC-653 , ITRON . Standar-standar ini, pada kenyataannya, membedakan kelas tugas yang dapat diselesaikan jika Anda mematuhi standar ini. Atau studi dilakukan oleh laboratorium independen yang mempelajari apakah sifat-sifat OS tertentu cocok untuk memecahkan masalah target.

Jadi Embox RTOS atau bukan RTOS?

Menurut pendapat saya, untuk menjawab pertanyaan serupa, baik untuk Embox dan untuk OS lainnya, Anda hanya dapat bertanya: "Apa maksud Anda?". Lebih tepatnya: "Apa yang Anda maksudkan dengan konsep waktu nyata?". Yaitu, jika waktu pemrosesan interupsi menarik, dan apakah mungkin untuk memanggil penangan interupsi secara langsung, ini adalah satu hal, jika Anda perlu meningkatkan keandalan kerja, meskipun lambat, tetapi tentu saja jauh lebih kecil kemungkinannya gagal, ini adalah hal lain, kepatuhan dengan standar apa pun adalah yang ketiga, Verifikasi adalah yang keempat. Bukan kebetulan bahwa klasik besar Andrei Tanenbaum, meskipun ia mengusulkan metode untuk meningkatkan prediktabilitas, menggunakan konsep sistem real-time, tetapi menahan diri dari definisi yang ketat.

PS Pada saat penulisan ini, tidak ada satu RTOS yang terpengaruh.