CONCEPTS IN REAL-TIME OPERATING SYSTEMS BAGIAN III

 

1.             Time Services

Clocks dan time services adalah beberapa fasilitas dasar yang disediakan untuk programmer oleh setiap sistem operasi real-time . Waktu layanan yang diberikan oleh sistem operasi didasarkan pada software clock yang disebut systems clock yang dikelola oleh sistem operasi, dikelola oleh kernel berdasarkan interupsi yang diterima dari hardware clock. Karena hard real-time systems biasanya memiliki kendala waktu (timing constraints) dalam kisaran mikro detik, system clock harus memiliki resolusi untuk mendukung layanan waktu yang diperlukan, sedangkan sangat sulit bagi perancang real-time operation systems untuk  mendukung hal tersebut dengan sangat baik.  Hardware clock secara periodik menciptakan interrupt (time service interrupts). Sebuah thread dapat mendapatkan current time readingdari system clock dengan memanggil system call yang didukung oleh sistem operasi. Semakin baik resolusi dari clock, semakin  sering kebutuhan untuk time service interrupts dan lebih besar jumlah processor time yang kernel habiskan dalam merespon interrupt tersebut.

1.1         Clock Interrupt Processing

Setiap kali jam interupsi terjadi , selain incrementing software clock, handler routine melakukan kegiatan sebagai berikut:

1.             Process Timer Events

Sistem operasi real-time menangani baik  per-process timer queues atau  single system-wide timer queue. Sebuah timer queu  berisi semua timer yang diatur berdasarkan urutan waktu masa berlakunya (expiration times) berakhir . Setiap waktu dikaitkan dengan handler routine. Handler routine adalah fungsi yang harus dipanggil saat timer berakhir . Pada setiap clock interrupt, kernel akan memeriksa struktur data timer dalam queue timer untuk melihat apakah ada timer event telah terjadi . Jika ditemukan bahwa timer event telah terjadi , maka antrian rutin handler yang sesuai dalam ready queue.

2.             Update ready list

Sejak clock event yang terakhir terjadi, beberapa tugas mungkin telah tiba atau berubah menjadi siap karena kondisi tertentu yang membuat task itu menunggu telah dipenuhi. Task dalam queue diperiksa, tasks yang ditemukan telah berubah dari posisi menunggu menjadi siap, masuk dalam ready queue. Jika ditemukan sebuah task yang memiliki prioritas lebih tinggi daripada tugas yang sedang berjalan telah menjadi siap, maka tugas yang sedang berjalan didahului dan scheduler dipanggil.

3.             Update Execution Budget

Pada setiap clock interrupt, scheduler mengurangi time slice (budget) yang tersisa untuk mengeksekusi task. Jika sisa budget menjadi nol dan task tidak selesai, maka task tersebut didahului, kemudian scheduler dipanggil untuk memilih tugas lain untuk dijalankan.

1.2         Providing High Clock Resolution

Terdapat dua kendala utama dalam menyediakan timer resolusi tinggi . Pertama, overhead yang terkait dengan pemrosesan clock interrupt menjadi berlebihan . Kedua, jitter yang berkaitan dengan time lookup system call (clock-gettime()) sering dari urutan beberapa milidetik . Oleh karena itu, tidak berguna untuk menyediakan clock dengan resolusi yang lebih baik dari ini. Namun, beberapa aplikasi real-time perlu berurusan dengan timing constrain dari urutan beberapa nanodetik.

Sebuah cara untuk memberikan clock resolution cukup baik adalah dengan pemetaan hardware clock ke ruang alamat aplikasi . Sebuah aplikasi kemudian dapat membaca jam hardware secara langsung ( melalui proses pembacaan  memori normal) tanpa harus melakukan system call. Tetapi membuat hardware clock terbaca oleh aplikasi secara signifikan mengurangi portabilitas dari aplikasi.

1.3         Timers

Timer service adalah layanan penting yang disediakan untuk aplikasi oleh semua sistem operasi real-time. Sistem operasi real-time biasanya mendukung dua jenis utama timer: timer periodik dan aperiodik (One Shot) timer.

1.             Periodic Timers

Digunakan terutama untuk pengambilan sampel event secara berkala atau melakukan beberapa kegiatan secara berkala. Setelah periodik timer diatur, setiap kali setelah masa berlakunya habis handler routine yang sesuai dipanggil, kemudian dimasukkan kembali ke dalam timer queue.

2.             Aperiodic (or One Shot) Timers

Timer ini ditetapkan untuk berakhir hanya sekali. Contohnya adalah watchdog timer seperti dibawah ini :

Watchdog timer digunakan secara ekstensif dalam real-time  programs untuk mendeteksi ketika task melewati tenggat waktu, dan menginisiasi exception handling procedures pada kejadian tersebut. Sebuah contoh penggunaan watchdog timer seperti gambar diatas, watchdog timer diatur pada awal dari sebuah critical function f() tertentu melalui sebuah call wd_start (t1). wd_start (t1) call mengatur watchdog timer berakhir sesuai deadline yang ditentukan (t1) dari awal tugas. Jika fungsi f() tidak menyelesaikan bahkan setelah t1 telah berlalu, maka watchdog timer berakhir, menunjukkan task deadline telah terlewati dan exception handling procedures dimulai. Bila task selesai sebelum waktu wathcdog timer selesai (sesuai deadlinenya) maka watchdog timer  di reset menggunakan  wd_tickle() call.

2.             Features of a Real-Time Operating System

Hasil identifikasi beberapa fitur penting yang diperlukan dari sistem operasi real-time , dan terutama mereka yang biasanya tidak ada dalam sistem operasi tradisional adalah sebagai berikut:

2.1         Clock and Timer Support

Clock dan timer services dengan resolusi yang memadai adalah salah satu isu yang paling penting dalam pemrograman  real-time . Pengembangan aplikasi hard real-time sering memerlukan dukungan layanan timer dengan resolusi urutan beberapa mikrodetik . Dan bahkan  resolusi yang lebih baik mungkin diperlukan dalam kasus aplikasi khusus tertentu . Clock dan timer adalah bagian penting dari setiap sistem operasi real-time . Di sisi lain , sistem operasi tradisional sering tidak menyediakan layanan waktu dengan resolusi yang cukup tinggi.

2.2         Real-Time Priority Levels

Sebuah sistem operasi real-time harus mendukung tingkat prioritas statis . Sebuah tingkat prioritas yang didukung oleh sistem operasi disebut statis, ketika programmer memberikan nilai prioritas untuk sebuah task, sistem operasi tidak mengubahnya sendiri. Tingkat prioritas statis juga disebut real-time priority levels. semua sistem operasi tradisional dinamis mengubah tingkat prioritas dari task dari values yang ditetapkan oleh programmer untuk memaksimalkan throughput sistem . Tingkat prioritas seperti yang diubah oleh sistem operasi dinamis jelas tidak prioritas statis.

2.3         Fast Task Preemption

Untuk keberhasilan operasi dari aplikasi real-time , setiap kali task dengan prioritas kritikal tinggi tiba , pengerjaan tugas prioritas rendah harus segera dikerjakan oleh CPU. Durasi waktu dari tugas prioritas yang lebih tinggi menunggu sebelum diperbolehkan untuk dijalankan secara kuantitatif dinyatakan sebagai corresponding task preemption time. Sistem operasi real-time kontemporer memiliki task preemption times dengan hitungan mikro detik saja. Namun, dalam sistem operasi tradisional , kasus terburuk dari task preemption times biasanya pada hitungan detik. Tak perlu dikatakan bahwa sistem operasi real-time harus memiliki kernel preemptive dan harus memiliki waktu tugas preemption dari urutan dari mikro detik saja.

2.4         Predictable and Fast Interrupt Latency

Interrupt latency didefinisikan sebagai time delay antara terjadinya interrupt dan menjalankan ISR yang sesuai (Interrupt Service Routine ) . Dalam sistem operasi real-time, upper bound pada latency interrupt harus dibatasi dan diharapkan akan kurang dari mikro detik saja. Cara interrupt latency rendah dicapai, adalah dengan melakukan sebagian besar kegiatan ISR dalam deferred procedure call (DPC). Sebuah DPC pada dasarnya adalah sebuah tugas yang melakukan sebagian besar aktivitas ISR. Sebuah DPC dieksekusi kemudian di nilai prioritas tertentu, dukungan untuk nested interrupts biasanya diinginkan. Artinya, sistem operasi real-time tidak hanya sekedar preemptive ketika menjalankan kernel routines, tetapi harus preemptive selama melayani interupsi juga.

2.5         Support for Resource Sharing Among Real-Time Tasks

Jika task real-time diizinkan untuk berbagi sumber daya kritis di antara mereka sendiri menggunakan teknik Resource Sharing tradisional, maka waktu respon tugas dapat menjadi tak terbatas yang berujung pada lewatnya deadline. Ini adalah salah satu alasan kuat mengapa setiap sistem operasi real-time komersial harus minimal menyediakan basic priority inheritance mechanism.

2.6         Requirements on Memory Management

Sistem operasi real-time embedded hampir tidak pernah mendukung virtual memory dan memory protection features. Hanya aplikasi besar dan kompleks saja yang mempunyainya. Sistem operasi real-time untuk aplikasi berukuran besar dan menengah diharapkan untuk memberikan dukungan memori virtual, tidak hanya untuk memenuhi tuntutan memori tugas yang berat dari aplikasi, tetapi juga memori untuk aplikasi-aplikasi non-real-time seperti teks editor, software e-mail, dll agar dapat berjalan pada platform yang sama. Virtual memory mengurangi rata-rata waktu akses memori, tetapi merendahkan worst-case dari akses memori. Hukuman menggunakan memori virtual adalah overhead yang terkait dengan menyimpan tabel terjemahan alamat dan melakukan virtual ke alamat fisik terjemahan. Selain itu, mengambil halaman dari memori sekunder pada permintaan menimbulkan latency yang signifikan. Oleh karena itu, sistem operasi yang mendukung memori virtual harus menyediakan aplikasi real-time dengan beberapa sarana untuk mengontrol paging, seperti penguncian memori. Penguncian memori mencegah halaman dari yang bertukar dari memori ke hard disk. Dengan tidak adanya fitur memori penguncian, waktu akses memori tugas real-time bahkan kritis dapat menunjukkan jitter besar, seperti waktu akses akan sangat tergantung pada apakah halaman yang dibutuhkan dalam memori fisik atau telah bertukar keluar .

Perlindungan memori merupakan masalah penting yang perlu dipertimbangkan dengan cermat. Kurangnya dukungan untuk perlindungan memori di antara tugas-tugas mengarah ke single address space untuk tasks. Untuk aplikasi embedded kecil , overhead beberapa Kilo Bytes memori per proses dapat diterima. Namun, bila tidak ada perlindungan memori yang disediakan oleh sistem operasi , biaya pengembangan dan pengujian program tanpa perlindungan memori menjadi sangat tinggi ketika kompleksitas meningkat aplikasi . Selain itu, kenaikan biaya pemeliharaan setiap perubahan dalam satu modul akan memerlukan pengujian ulang seluruh sistem.

Sistem operasi real-time embedded biasanya tidak mendukung memori virtual. Juga , perlindungan memori menjadi sulit untuk mendukung sistem manajemen memori non-virtual. Untuk alasan ini , dalam banyak embedded system, kernel dan proses pengguna mengeksekusi di ruang yang sama, yaitu tidak ada proteksi memori. Oleh karena itu , sistem panggilan dan fungsi panggilan dalam aplikasi tidak dapat dibedakan. Hal ini membuat aplikasi debugging sulit , karena run away pointer dapat merusak kode sistem operasi , membuat sistem " freeze ".

2.7         Additional Requirements for Embedded Real-Time Operating Systems

Beberapa persyaratan tambahan yang biasanya dimiliki embedded applications biasanya adalah :

1.      Constraints atau batasan dalam hal biaya, ukuran, dan konsumsi daya.

2.      Sistem operasi real-time embedded harus mampu melakukan operasi disk less, karena sering kali disk yang terlalu besar untuk digunakan, atau meningkatkan biaya penyebaran. Selanjutnya, sistem operasi tertanam harus meminimalkan konsumsi daya total sistem.

3.      Sistem operasi embedded biasanya berada di ROM. Untuk aplikasi tertentu yang membutuhkan respon cepat, mungkin perlu untuk menjalankan sistem operasi real-time pada RAM . Karena waktu akses RAM adalah lebih rendah dari ROM , maka ekesekusinya lebih cepat. Untuk aplikasi embedded pada sistem operasi real-time diharapkan memiliki foot print (penggunaan memori ) yang sekecil mungkin.

3.             Unix as a Real-Time Operating System

UNIX adalah sistem operasi yang sangat populer, biasa digunakan sebagai komputer mainframe. Sekarang ini turunan UNIX banyak digunakan untuk komputer dekstop. Keberadaan UNIX sebagai sistem operasi yang ringan dan kebanyakan bersifat open source membuat banyak pengembang menggunakan sistem ini untuk dikembangakan lebih lanjut.

Pada bahasan ini akan dibahas tentang permasalahan UNIX sebagai Real-Time Operating System. Sebab ternyata sejak pertama di ciptakan UNIX bukan merupakan sistem operasi yang Real-Time. Ada 2 permasalahan yang membuat UNIX bukan sebagai Real-Time Operating System yaitu karena kernel UNIX bersifat non-preemptive dan juga karena terjadi perubahan prioritas pada task nya (Dinamic Priority of Task).

3.1. Features of UNIX System

- Clock and Timer Support

Pada sistem UNIX, clock dan dukungan timer sangat jauh jika ingin dikatakan sebagai real-time. Sebuah sistem dikatakan real-time jika memiliki waktu eksekusi kurang dari 1 milidetik, sedangkan waktu eksekusi pada UNIX sebesar 10 milidetik.

- Real-Time Priority Levels

Pada UNIX terjadi perubahan level  prioritas atau level prioritasnya bersifat dinamik. Hal tersebut sudah melanggar aturan dari real-time yang prioritas levelnya harus tetap atau statis.

- Fast Task Preemtive

UNIX memiliki penjadwalan task yang bersifat non-preemptive. Hal itu berarti sistem di UNIX tidak menunggu prioritas yang tinggi untuk dieksekusi terlebih dahulu. Namun jika ada task yang datang akan dieksekusi dahulu walaupun prioritasnya rendah, kemudian prioritas yang lain menunggu untuk di eksekusi walaupun prioritasnya tinggi sekalipun.

- Predictable and Fast Interrupt Latency

Suatu sistem dikatakan real time jika dapat di prediksi dan memiliki jeda waktu interupsi yang cepat. Namun pada UNIX waktu interupsi yang sangat lama. Jika pada sistem real-time dalam hitungan milidetik, pada UNIX bisa sampai detik

- Support For Resource Sharing among RT Task.

Pada UNIX tidak terjadi pembagian sumber daya secara bersama-sama. Sumber daya di akses satu persatu. Jika satu task mengakses sumber daya maka sistem akan mengunci (lock) aksesnya sehingga akses  yang lainya harus menunggu.

- Requirement on Memory Management

Managemen memori UNIX sudah mendukung untuk virtual memori. Jadi jika memori di disk sudah penuh maka akan membentuk virtual memori untuk menampung.

- Addional Requirement For Embedded RTOS

1. Time Constrain : Cost, Size, Power Consumption

Biaya yang diperlukan UNIX  untuk menjalankan aplikasi embedded cukup besar sebab UNIX bukan sistem operasi  Real-Time. Ukuran file yang dihasilkan UNIX juga besar. Kemudian komsumsi powernya juga tinggi karena UNIX sejadinya bukan real-time os jadi pemrosesnya membutuhkan komsumsi daya yang banyak.

3.      Disk Less Operation

UNIX mampu mengatur penggunaan disk jika ukuran file terlalu besar. Sebab UNIX bisa membuat virtual memori jika terdapat kelebihan muatan.

4.      Minimize Memory Requirement.

Sistem embedded di UNIX menyimpan menyimpan memori di ROM. Untuk proses yang memerlukan respon cepat juga dikerjakan di ROM, jadi UNIX untuk sistem embedded belum mampu untuk memenuhi pengurangan kebutuhan memori.

4.1.Other  Deficiencies of Unix

Kelemahan (Deficiencies) UNIX disini maksudnya adalah kekurangan yang ada pada UNIX sehingga tidak bisa menjadi Real-Time Operating System. Kelemahan-kelemahan itu antara lain :

Tidak adanya dukungan untuk driver perangkat tambahan : Di UNIX (Pada bahasan ini kita gunakan UNIX sistem V) driver perangkat berjalan pada mode kernel. Hal itu berarti akan sangat sulit jika kita ingin menambah perangkat baru yang membutuhkan driver.

Kurangnya layanan file Real-Time : Di UNIX, blok file di alokasikan ketikafile itu di panggil oleh aplikasi. Sebagai konsekuensi ketika task membaca file, maka mungkin akan terjadi error ketika blok yang tersedia pada disk sudah penuh. Jadi tidak ada jaminan akan adanya ruang yang tersedia di disk saat aplikasi membaca file. Kekurangan yang lain adalah bila ada file yang sama maka alokasi nya tidak diletakan pada lokasi yang berdekatan di disk.

Dukungan untuk Time Service tidak memadai : Time Service pada UNIX tidak memungkin untuk di katakan sebagai Hard Real-Time sebab clock resolution yang diberikan ke aplikasi adalah 10 milidetik.

5.             Unix-based Real-Time Operating Systems

Pada pembahasan sebelumnya kita sudah tahu bahawa UNIX tidak cocok digunakan pada aplikasi Hard Real-Time , dan di pembahasan kali ini akan diterangkan solusi untuk menjadikan UNIX sebagai Real-Time Operating System.

5.1.  Extensions To The Traditional UNIX Kernel

Salah satu solusi yang digunakan untuk menjadikan UNIX cocok di aplikasi Real-Time salah satunya adalah dengan menambahkan beberapa kemampuan-kemanpuan dari Real-Time seperti menambahkan dukungan timer Real-Time, Penjadwalan task Real-Time dibangun pada penjadwalan UNIX dll. Meskipun dengan penambahan kemampuan tersebut tidak mampu mengatasi masalah utama dari UNIX yaitu non-preemtive dan dinamic priority of task.  Namun setidaknya sudah memenuhi sedikit kebutuhan dari aplikasi hard real-time.

5.2. Host-Target Approach

Pendekatan ini sangat populer untuk mendeploy aplikasi embedded. Dalam pendekatan ini, pembuatan aplikasi dan mengeksekusian aplikasi berada pada tempat yang berbeda. Jadi untuk membuatan aplikasi Real-Time dilakukan di host kemudian dari host akan di unduh ke board target. Agar lebih jelasnya dapat dilihat pada gambar dibawah.

Sistem pada host harus memiliki lingkungan pengembangan program seperti compiler, editor, library, cross compires, debuggers, dll. Memori yang digunakan harus memiliki spesifikasi untuk mendukung virtual memori. Penghubung antara host dan board target adalah jaringan TCP/IP.  Cara implementasi dari pendekatan ini adalah pertama aplikasi di buat di host kemudian cross-compiler melakukan menghasilkan kode untuk prosesor target. Setelah itu modul yang telah dieksekusi di unduh oleh board target. Task di eksekusi di board target dan  eksekusi dikendalikan di sisi host menggunkan cross-debugger simbolik. Sewaktu program sukss bekerja, maka akan tersimpan di ROM atau Flash memori dan siap untuk dijalankan aplikasi. Contoh sistem operasi Real-Time kompersial adalah PSOS, VxWorks dan VRTX yang nantinya akan dibahas pada bab berikutnya.

5.3. Preemptive Point Approach

Sudah kita ketahui bahwa UNIX menerapkan penjadwalan non-preemptive untuk mengeksekusian task. Maka salah satu cara untuk membuatnya menjadi real-time salah satunya dengan meningkatkan performa real-time nya di sistem routine. Pada poin ini sistem akan dijadwalkan secara preemptive membuat sistem menunggu prioritas tertinggi dari task real-time tanpa adanya kesalahan struktur data kernel.

5.4. Self-Host System

Tidak seperti metode pendekatan Host-Target, pada sistem Self-Host pembuatan aplikai dan mengeksekusian dilakukan pada satu lokasi. Oleh karena itu metode ini sulit melakukan debugging program dan dukungan cross-compiler dan cross-debuger. Sistem self-host dibangun berdasar pada arsitektur micro-kernel. Menggunakan arsitektur micro-kernel untuk sistem operasi self-host memiliki beberapa keuntungan. Di arsitektur mikro-kernel hanya fungsionalitas core seperti penanganan intterupt dan managemen proses yang diimplementasikan sebagai routine kernel. Semua fungsionalitas lain seperti managemen memori, managemen file, managemen perangkat dan sebagainya di implementasikan sebagai modul add-ons yang beroperasi di mode user. Hasilnya akan membuat sistem operasi mudah untuk di konfigurasi. Selain itu micro-kernel juga ringan sehingga menjadi lebih efisien.

Seperti yang dibahas pada sub bab sebelumnya, bahwa permasalahan utama dari UNIX  untuk menjalankan aplikasi real-time adalah karena penjadwalannya berifat non-preemptive dan pritas tasknya bersifat dinamik (berubah-ubah). Oleh karena itu pembahasan kali ini kita akan membahas tentang Non-Preemptive dan jenis-jenis prioritas pada pada task.

Kernel No-Preemptive : Kernel UNIX bersifat no-preemptive yang artinya akan menunggu sampai satu proses selesai dieksekusi baru kemudian mengeksekusi proses lain. Agar membuat sistem menjadi preemptive, lock harus diletakan ditempat yang tepat. Sitem UNIX preemptive yang sebenarnya mempunyai 2 lock yaitu kernel-level lock dan spin lock. Pada kernel-level lock sistem menunggu sampai task berikutnya siap. Lock akan tertutup sampai ada proses yang ready.

Gambar 4. Operasi Spin Lock

Kemudian pada spin lock, task 2 tidak bisa mengakses resources (sumber) karena tertutup spin lock. Task 2 akan berputar-putar menunggu sampai task 1 selesai di kerjakan kemudian di realease oleh sistem

Prioritas-prioritas Real-Time : Sekarang akan di bahas mengenai permasalahan prioritas pengalamatan sistem self-host pada UNIX. Prioritas pada UNIX berubah-ubah sesuai keinginan sistem. Ada tiga prioritas perubahan pada sistem self-host ini yaitu

1.      Idle (Non-Migrating)

Adalah prioritas terendah, prioritas ini akan di eksekusi bila sudah tidak ada task yang dijalankan. Prioritasi idle ini bersifat statis dan tidak dilakukan perhitungan secara periodik

2.      Dinamic

Adalah prioritas yang melakukan perhitungan secara periodik untuk meningkatkan waktu respon rata-rata. Pengerjaan prioritas ini dilakukan setelah prioritas Real-time di jalankan.

3.      Real-Time

Adalah prioritas tertinggi yang bersifat stati dan tidak ada penghitungan ulang. Task hard-real time bekerja pada level ini

                                                                                    

6.             Windows As A Real-Time Operating System

Sistem operasi Microsoft Windows sangat populer di komputer desktop . Sistem operasi Windows telah berevolusi selama bertahun-tahun terakhir dua puluh lima tahun dari naif DOS ( Disk Operating System ) . Microsoft mengembangkan DOS di awal tahun delapan puluhan . Microsoft terus mengumumkan versi baru dari DOS hampir setiap tahun dan terus menambahkan fitur baru untuk DOS dalam versi berturut-turut . DOS berkembang ke sistem operasi Windows , utamanya membedakan fitur adalah grafis front-end . Seperti beberapa versi baru dari Windows terus muncul dengan cara upgrade , maka code Windows benar-benar ditulis ulang pada tahun 1998 untuk mengembangkan sistem Windows NT . Karena kode benar-benar ditulis ulang , sistem Windows NT jauh lebih stabil ( tidak crash ) daripada sistem berbasis DOS sebelumnya . Versi terbaru dari sistem operasi Microsoft adalah keturunan dari Windows NT , sistem berbasis DOS yang ditolak . Gambar . 31,8 menunjukkan silsilah berbagai sistem operasi dari Microsoft stabil . Karena stabilitas merupakan syarat utama untuk aplikasi real-time keras, kita hanya mempertimbangkan Windows NT dan turunannya dalam penelitian kami dan tidak termasuk garis DOS produk.

Sebuah organisasi yang memiliki sistem Windows NT mungkin tertarik untuk menggunakannya untuk aplikasi real-time pada rekening baik penghematan biaya atau kenyamanan. Hal ini terutama berlaku dalam pengembangan aplikasi prototipe dan juga ketika hanya sejumlah penyebaran yang diperlukan. Berikut ini, kami menganalisis secara kritis kesesuaian Windows NT untuk pengembangan aplikasi real-time. Pertama, kami menyoroti beberapa fitur dari Windows NT yang sangat relevan dan berguna untuk pengembang aplikasi real-time. Dalam ayat berikutnya, kita menunjukkan beberapa kekosongan Windows NT bila digunakan dalam pengembangan aplikasi real-time.

6.1.       Features of Windows NT

Windows NT memiliki beberapa fitur yang sangat diinginkan untuk aplikasi real-time seperti dukungan untuk multithreading , tingkat prioritas real-time , dan timer . Selain itu , resolusi jam yang cukup baik untuk sebagian besar aplikasi real-time .

Windows NT mendukung 32 tingkat prioritas ( lihat Gambar . 31,9 ) . Setiap proses milik salah satu kelas prioritas berikut : menganggur , normal, tinggi , real-time . Secara default , kelas prioritas di mana aplikasi berjalan normal . Baik normal dan tinggi adalah tipe variabel mana prioritas adalah menghitung ulang secara berkala . NT menggunakan penjadwalan pre - emptive prioritas - driven dan benang prioritas real-time memiliki awalan dibanding semua benang lainnya termasuk benang kernel . Proses seperti penggunaan screen saver kelas prioritas idle. NT menurunkan prioritas tugas ( milik jenis variabel ) jika menggunakan semua waktu terakhir slice -nya . Ini menimbulkan prioritas tugas jika diblokir untuk I / O dan tidak bisa menggunakan waktu terakhir slice secara penuh . Namun, perubahan tugas dari prioritas dasarnya dibatasi untuk ± 2 .

6.2.            Shortcomings of Windows NT

Terlepas dari dukungan mengesankan bahwa Windows menyediakan untuk pengembangan program real-time seperti yang dibahas dalam Bagian 4.5.1, seorang programmer mencoba untuk menggunakan Windows dalam pengembangan sistem real-time harus mengatasi dengan beberapa masalah. dari jumlah tersebut, dua masalah utama berikut adalah yang paling merepotkan

.

1 .      Interrupt Pengolahan  

Tingkat Prioritas interupsi selalu lebih tinggi dari thread user-level , termasuk benang  kelas real-time . Ketika interupsi terjadi , rutin handler menghemat negara mesin dan membuat sistem mengeksekusi Rutin Interrupt Service ( ISR ) . Hanya pengolahan kritis dilakukan dalam ISR dan sebagian besar pengolahan dilakukan sebagai Procedure Call tangguhan ( DPC ) . DPC untuk berbagai interupsi yang antri dalam antrian DPC secara FIFO . Sementara pemisahan ini ISR dan DPC memiliki keuntungan dari memberikan respon cepat untuk interupsi lanjut , ia memiliki kelemahan menjaga semua DPC di prioritas yang sama . Sebuah DPC tidak bisa mendahului oleh DPC lain tapi oleh interupsi . DPC dijalankan dalam rangka FIFO pada prioritas yang lebih rendah daripada prioritas interupsi hardware tetapi lebih tinggi dari prioritas scheduler / operator . Selanjutnya , tidak mungkin untuk thread user-level untuk mengeksekusi pada prioritas yang lebih tinggi daripada ISRS atau DPC . Oleh karena itu , bahkan ISRS dan DPC sesuai dengan tugas prioritas yang sangat rendah dapat mendahului proses real-time . Oleh karena itu, pemblokiran potensi tugas real-time karena DPC bisa besar . Misalnya, menyela karena kesalahan halaman dihasilkan oleh tugas-tugas prioritas rendah akan diproses lebih cepat daripada proses real-time . Juga , ISRS dan DPC dihasilkan karena papan kunci dan interaksi mouse akan beroperasi pada tingkat prioritas yang lebih tinggi dibandingkan dengan tugas-tugas real-time . Jika ada proses yang melakukan jaringan atau disk I / O , efek seluruh sistem antrian FIFO dapat menyebabkan waktu respon yang tak terbatas bagi benang bahkan real-time.

Masalah-masalah ini telah dihindari dengan sistem operasi Windows CE melalui mekanisme warisan prioritas.

2 .      Dukungan untuk Resource Sharing Protokol :

       Kami telah dibahas dalam Bab 3 bahwa kecuali protokol berbagi sumber daya yang tepat digunakan , tugas saat mengakses sumber daya bersama mungkin menderita inversi prioritas terbatas menyebabkan misses batas waktu dan bahkan kegagalan sistem . Windows NT tidak menyediakan dukungan apapun ( seperti warisan prioritas , dll ) untuk mendukung tugas-tugas real-time untuk berbagi sumber daya yang penting di antara mereka sendiri . Ini adalah kelemahan utama dari Windows NT bila digunakan dalam aplikasi real-time . Karena sebagian besar aplikasi real-time melakukan melibatkan berbagi sumber daya antara tugas kami uraikan cara yang mungkin di mana fungsi user-level dapat ditambahkan ke sistem Windows NT . Pendekatan paling sederhana untuk membiarkan tugas-tugas real-time berbagi sumber daya kritis tanpa inversi prioritas terbatas adalah sebagai berikut . Segera setelah suatu tugas berhasil mengunci sumber daya non - preemptable , prioritas dapat dinaikkan menjadi prioritas tertinggi ( 31 ) . Begitu tugas melepaskan sumber daya yang diperlukan , prioritas dipulihkan . Namun, kita tahu bahwa pengaturan ini akan menyebabkan inversi - warisan besar yang terkait . Kemungkinan lain adalah untuk melaksanakan prioritas plafon protocol ( PCP ) . Untuk mengimplementasikan protokol ini , kita perlu membatasi tugas-tugas real-time untuk memiliki bahkan prioritas (yaitu 16 , 18 , ... , 30 ) . Alasan pembatasan ini adalah bahwa NT tidak mendukung penjadwalan FIFO antara tugas-tugas prioritas yang sama . Jika prioritas tertinggi di antara semua tugas yang membutuhkan sumber daya adalah 2 * n , maka prioritas plafon sumber daya adalah 2 * n +1 . Dalam Unix , opsi FIFO antara tugas-tugas prioritas yang sama tersedia , maka mereka semua tingkat prioritas yang tersedia dapat digunakan .

7.             Windows vs Unix

 

Meskipun Windows NT memiliki banyak fitur yang diinginkan dari sistem real-time operasi, implementasi dari DPC bersama kurangnya dukungan protokol untuk berbagi sumber daya antara tugas-tugas prioritas yang sama membuatnya tidak cocok untuk digunakan dalam aplikasi real-time keamanan-kritis. Perbandingan sejauh mana beberapa fitur dasar yang dibutuhkan untuk pemrograman real-time yang disediakan oleh Windows NT dan Unix V ditunjukkan pada Tabel 1. With careful programming, Windows NT mungkin berguna untuk aplikasi yang dapat mentolerir merindukan tenggat waktu sesekali, dan memiliki batas waktu dari urutan ratusan milidetik dari mikrodetik. Tentu saja, untuk digunakan dalam aplikasi tersebut, utilisasi prosesor harus dijaga cukup rendah dan prioritas kontrol inversi harus disediakan pada tingkat pengguna.

7.1         Clock and Timer Support

Resolusi tinggi timer yang diinginkan dalam berbagai macam aplikasi yang berbeda. Sebagai contoh, penggunaan paling umum dari timer seperti pada Windows adalah dengan aplikasi multimedia yang menghasilkan suara atau audio yang memerlukan kontrol yang tepat. MIDI adalah contoh sempurna karena MIDI sequencer harus mempertahankan laju peristiwa MIDI dengan tingkat akurasi 1 milidetik. Artikel ini menjelaskan cara timer resolusi tinggi diimplementasikan dalam NT dan dokumen NtSetTimerResolution dan NtQuery Timer Resolution, fungsi kernel NT yang memanipulasi dan informasi tentang jam sistem kembali. Sayangnya, NtSetTimerResolution dan NtQueryTimerResolution tidak diekspor oleh kernel NT, sehingga mereka tidak tersedia untuk kernel-mode driver perangkat.Windows NT basis semua dukungan waktu off dari satu jam sistem mengganggu, yang secara default berjalan pada granularity 10 milidetik. Oleh karena itu, ini adalah resolusi timer standar Windows. Ketika sebuah aplikasi multimedia menggunakan timeBeginPeriod mutlimedia API, yang diekspor oleh Windows NT link dinamis perpustakaan Winmm.dll, panggilan diarahkan ke Windows NT fungsi kernel-mode NtSetTimerResolution, yang diekspor oleh asli Windows NT perpustakaan NTDLL.DLL .

·         MinimumResolution
Resolusi minimum timer. Pada sistem x86 standar ini adalah 0x2625A, yaitu sekitar 10 milidetik

·         MaximumResolution
Resolusi waktu maksimum. Pada sistem x86 standar ini adalah 0x2710, yaitu sekitar 1 milidetik.

·         ActualResolution
Ini adalah resolusi saat jam sistem.

7.2         Real-Time Priority Levels

 Penjadwalan prosesor Windows NT mengacu pada proses dimana Windows NT menentukan pekerjaan (tugas) harus dijalankan pada prosesor komputer pada saat. Tanpa penjadwalan, prosesor akan memberikan perhatian kepada pekerjaan berdasarkan ketika mereka tiba dalam antrian, yang biasanya tidak optimal. Sebagai bagian dari penjadwalan, prosesor memberikan tingkat prioritas untuk proses yang berbeda berjalan pada mesin. Ketika dua proses yang meminta layanan pada saat yang sama, prosesor melakukan pekerjaan untuk satu dengan prioritas yang lebih tinggi.

Ada enam tingkat prioritas yang bernama:

·         Realtime

·         Tinggi

·         di atas normal

·         normal

·         Di bawah normal

·         rendah

Tingkat ini telah dikaitkan nomor dengan mereka. Aplikasi mulai dari tingkat prioritas dasar delapan. Sistem ini secara dinamis menyesuaikan tingkat prioritas untuk memberikan semua aplikasi akses ke prosesor. Tingkat prioritas 0-15 digunakan oleh aplikasi yang dinamis. Tingkat prioritas 16-31 dicadangkan untuk aplikasi real-time.

7.3         Fast Task Preemption

Dalam komputasi , preemption adalah tindakan sementara mengganggu tugas yang dilakukan oleh sistem komputer , tanpa memerlukan kerjasama , dan dengan maksud melanjutkan tugas di lain waktu . Perubahan tersebut dikenal sebagai context switch . Hal ini biasanya dilakukan oleh tugas istimewa atau bagian dari sistem yang dikenal sebagai scheduler preemptive , yang memiliki kekuatan untuk mendahului , atau mengganggu , dan kemudian melanjutkan , tugas-tugas lain dalam sistem .

Dalam setiap desain sistem yang diberikan , beberapa operasi yang dilakukan oleh sistem mungkin tidak Preemptible . Hal ini biasanya berlaku untuk kernel fungsi dan interupsi layanan yang , jika tidak diizinkan untuk berjalan sampai selesai , akan cenderung menghasilkan kondisi ras mengakibatkan kebuntuan . Pembatasan scheduler dari preempting tugas sementara mereka memproses fungsi kernel menyederhanakan desain kernel dengan mengorbankan respon sistem . Perbedaan antara mode pengguna dan kernel mode , yang menentukan tingkat hak istimewa dalam sistem , juga dapat digunakan untuk membedakan apakah tugas saat ini Preemptible .

Sebagian besar sistem modern memiliki kernel preemptive , yang dirancang untuk mengizinkan tugas yang harus mendahului bahkan ketika dalam mode kernel . Contoh sistem tersebut Solaris 2.0/SunOS 5.0, [ 1 ] Windows NT , Linux kernel 2.6 dan 3.x , AIX dan beberapa sistem BSD ( NetBSD , sejak versi 5 ) .

7.4         Predictable and Fast Interrupt Latency

Perdebatan tentang kesesuaian Windows NT untuk aplikasi real-time yang sedang berlangsung di komunitas pemrograman . Sayangnya , data keras mengenai real-time respon NT tidak tersedia . Dokumentasi menunjukkan bahwa interupsi hardware memiliki hirarki prioritas tetap . Pengujian empiris pada platform tertentu menunjukkan hal yang sebaliknya . Sementara NT rata-rata latency interrupt cukup baik ( di urutan beberapa mikrodetik pada Pentium cepat) , terburuknya latency tidak mudah diprediksi dan bisa berada di urutan beberapa milidetik , tergantung pada platform NT ( 80x86 , Alpha , prosesor tunggal , multiprosesor , dan sebagainya) dan sistem yang driver yang Anda gunakan . Jika perangkat membutuhkan konsisten , respons yang cepat untuk interupsi , maka latency panjang , bahkan jika mereka terjadi hanya sesekali, akan menyebabkan masalah besar.

Untuk membantu menjernihkan kebingungan interrupt kemampuan penanganan NT , saya mengembangkan DOIRQ , sebuah perangkat lunak yang melakukan analisis kotak hitam sistem interupsi NT dan menerangi masalah dan keterbatasan , serta potensi yang besar . Alat ( tersedia secara elektronik , lihat " Resource Center , " halaman 3 ) dapat digunakan untuk menunjukkan dua bug di single- processor NT , 80x86 Hardware Abstraction Layer ( HAL ) yang , dalam kondisi tertentu , menyebabkan interupsi ditunda atau ditangani dari order. Hal ini penting karena bug dapat menyebabkan prioritas tinggi menyela ditunda oleh interupsi prioritas rendah dan , oleh karena itu , mengurangi kegunaan NT untuk driver yang membutuhkan cepat , penanganan interupsi deterministik.

7.5         Support for Resource Sharing Among Real-Time Tasks

Peran utama dari sistem operasi adalah bahwa pengelolaan sumber daya . Tugasnya adalah untuk menyajikan satu set layanan yang sesuai dengan aplikasi dan pengguna mendukung . Secara tradisional , sistem operasi tujuan umum , termasuk Windows NT , federasi berbagi sumber daya secara adil , dengan tujuan utama dari pemanfaatan sumber daya yang efisien . Akibatnya algoritma penjadwalan yang dipilih tidak cocok untuk aplikasi yang memiliki ketat Quality- of - Service ( QoS ) dan persyaratan manajemen sumber daya , seperti aplikasi media streaming terus menerus . Beberapa pendekatan untuk pengelolaan sumber daya yang mampu memenuhi persyaratan ini , termasuk penggunaan penjadwal deterministik , mapan . Sistem operasi sudah ada yang menyediakan layanan untuk partisi sumber daya halus dan QoS alokasi berbasis . Namun demikian , muncul pertanyaan : dapat kita memperkenalkan mekanisme manajemen yang sesuai ke dalam sistem operasi tujuan umum yang akan memberikan dukungan yang memadai untuk sebagian besar aplikasi sensitif sumber daya , khususnya multimedia ? Atau ada masalah yang melekat dalam tujuan umum arsitektur sistem operasi yang menuntut signifikan re - engineering ? Kami mencoba untuk menjawab pertanyaan ini dengan mengajukan Protected Virtual Machine ( PVM ) arsitektur . Hal ini memperkenalkan mekanisme ke Windows NT yang memungkinkan partisi sumber daya dan perlindungan dari gangguan sumber daya . Fungsi arsitektur PVM adalah dua kali lipat . Pertama memperkenalkan mekanisme penjadwalan yang diperlukan dan sumber daya abstraksi atom ke dalam sistem operasi , dan kedua menyediakan reservasi tingkat yang lebih tinggi dan layanan masuk langsung ke aplikasi . Sistem yang dihasilkan mampu memberikan kedua layanan - usaha terbaik untuk aplikasi dengan kebutuhan kurang ketat dan dijamin layanan untuk multimedia dan pengolahan sumber daya penting lainnya di lingkungan bersama , Dengan meningkatkan sistem operasi yang ada , aplikasi warisan masih dapat didukung , sehingga menghindari rintangan terkemuka di real-time dan multimedia sistem operasi yang ada .

7.6         Additional Requirements for Embedded Real-Time Operating Systems

Microsoft ® Windows ® platform dengan cepat mendapatkan popularitas dengan
tertanam pengembang sistem karena memberikan pembangunan rendah biaya dan memungkinkan perusahaan untuk cepat membawa fungsionalitas meningkat untuk pasar. Selain menjadi kuat, sistem operasi 32-bit yang modern Platform, Windows menyediakan sejumlah keuntungan unik yang tidak ditemukan di lain tertanam sistem operasi:

·         Windows terkenal Win32 ® API, dengan berbagai terkait dari alat pengembangan dan basis pengetahuan, menyediakan dasar yang luas pengembangan bakat, peralatan, dan keahlian.

·         Windows memungkinkan penggunaan jangkauan terluas komponen perangkat lunak pihak ketiga, dari perangkat driver dan ekstensi sistem database dan aplikasi dari semua jenis.

·         windows juga menawarkan dukungan jaringan komprehensif dan konektivitas ke
non-tertanam dan sistem informasi perusahaan.

·         Untuk sistem dengan antarmuka operator yang canggih, ada juga akrab Jendela Graphical User Interface (GUI)

Keuntungan utama dari sistem operasi Windows dalam aplikasi embedded adalah kemampuan untuk memanfaatkan komponen software off-the-rak yang ada, baik yang di Windows itu sendiri atau komponen dari berbagai pengembang pihak ketiga.

Sistem tertanam desainer yang membuat aplikasi yang memaksimalkan
penggunaan komponen yang ada, dan meminimalkan jumlah komponen software yang harus ditulis, akan mewujudkan biaya pengembangan terendah dan waktu tercepat ke pasar. Persembahan terbaru dari Microsoft untuk meningkatkan fungsi sistem tertanam adalah Windows NT ® Tertanam 4.0. Ini anggota terbaru dari keluarga produk sistem operasi Windows NT secara khusus ditawarkan untuk digunakan dalam produk tertanam dan perangkat. Microsoft Windows NT Tertanam 4.0 adalah cara yang cepat dan ekonomis untuk membangun fungsionalitas yang kaya menjadi embedded system dan aplikasi. Produk ini terdiri dari beberapa daerah untuk membantu pengembang dengan cepat implementasi dan memberikan kemampuan untuk memperluas fungsionalitas dari sistem operasi dasar. Windows NT Tertanam terdiri dari tiga bidang utama.

1.      Windows NT Sumber File - file ini adalah dasar dari akhirnya tertanam sistem operasi Anda .Mereka termasuk fitur Windows NT 4.0 termasuk Service Pack 5 . Ini berarti solusi Anda dapat mencakup semua fungsi kaya Windows NT , seperti dukungan multi- adaptor , kemampuan jaringan , Win32 API , dan banyak lagi.

2.      Target Designer - Target Designer adalah alat pengembangan untuk mengkonfigurasi dan membangun Windows NT Embedded sistem . Ini adalah alat authoring utama dalam Microsoft Windows NT Tertanam . Menggunakan Sasaran Designer , Anda dapat membuat sistem operasi Windows NT , mengintegrasikan komponen kustom dan aplikasi , dan membangun sistem embedded bootable . Sasaran Designer menampilkan Windows Konfigurasi NT pada tingkat komponen dalam cara grafis standar . Setiap daerah fitur sistem operasi dengan mudah diwakili oleh komponen agraphical di Target Designer . Bila menggunakan Target Designer , Anda dapat menghemat waktu dan bekerja di lingkungan Windows akrab untuk membuat disesuaikan Windows NT sistem operasi tertanam.

3.      Komponen Designer - Komponen Designer digunakan dalam hubungannya dengan Sasaran Designer dan memungkinkan Anda untuk membuat komponen kustom yang dapat ditambahkan ke Target Designer con-figurasi. Menggunakan Komponen Designer Anda dapat dengan mudah membuat file definisi komponen yang meningkatkan lebih lanjut dan mengkustomisasi fungsi resultan sistem embedded. Dalam file definisi komponen, Anda dapat menentukan komponen yang ingin Anda termasuk ke dalam Target Designer. Anda juga dapat mengkonfigurasi kemampuan dan komponen-komponen dengan menggunakan informasi dalam pengembangan sistem Anda, seperti registry setempat atau Database Sasaran Designer Sistem. Setelah Anda membuat file definisi komponen Anda, Anda dapat mengimpor ke Target Designer. Setelah mereka diimpor Anda dapat menambahkan komponen baru untuk konfigurasi Anda tertanam.