Gerçek Zamanlı Sistemler (Real-Time Systems) -1.2
Bölüm 1.2: RTOS ve Çeşitleri
Bu bölümde Gerçek Zamanlı İşletim Sistemi kavramına giriş yapacağız ve RTOS kavramını tanımlayacağız. Ek olarak RTOS’u farklı alt kavramlarda ele alacağız.
Bir adım geriden: Bir önceki bölümde ilk olarak, RTOS'un ne olduğuna dair genel bir bakış sunduk ve gerçek zamanlı gereksinimleri olabilecek sistemlere ufak bir göz attık. Bir önceki bölüme buradan ulaşabilirsiniz.
Bu bölüme başlamadan önce düşüncenizi merak ettiğim bir husus var. Şöyle ki bu seriye ek olarak “Gömülü Linux (Embedded Linux)” dünyasına girip bir seriye başlamak istiyorum. Sizin bu konuda düşünceleriniz ne olur? Yorumlarda belirtebilir misiniz? Ekstra olarak bana buradan ulaşabilirsiniz.
Şimdiden teşekkürler. Kaldığımız yerden devam edelim.
Gerçek Zamanlı ‘İşletim Sistemi’ - RTOS
Günümüzde kullandığımız işletim sistemleri (OS'ler), Windows, Linux ve macOS gibi örneklerle bilgisayar programlarını yazmayı ve bakımını daha kolay hale getirmek için tasarlanmıştır. Bu sistemler, donanımın karmaşıklığını gizleyerek programcıya tutarlı bir programlama ortamı sunar. Böylece programcı, donanımın ayrıntılarına fazla takılmadan çalışabilir. İşletim sistemleri, daha karmaşık davranışlar yaratmak için kullanılabilecek bazı temel yapıları sağlar. Örneğin, iş parçacıkları (threads) ve mutex'ler bu yapılar arasındadır. Bu araçlarla, çok iş parçacıklı bir program oluşturmak ve paylaşılan verilere korumalı erişim sağlamak mümkündür.
Not: Thread (iş parçacığı), bir programın aynı anda birden fazla işlem yapabilmesini sağlar. Mutex ise, paylaşılan veriye aynı anda yalnızca bir iş parçacığının erişmesine izin vererek veri tutarlılığını koruyan bir kilit mekanizmasıdır.
Bir uygulama geliştirirken işletim sisteminin sağladığı bu thread ve mutex gibi yapıları kullanmak, yazılımı daha az karmaşık hale getirir. Aynı zamanda farklı programcılar tarafından geliştirilen kodları anlamak daha kolay olur çünkü herkes aynı temel yapıları kullanır. Ayrıca, uygun önlemler alındığında bu kodlar, işletim sistemi tarafından desteklenen herhangi bir donanımda değişiklik yapmadan çalıştırılabilir. Bu sayede donanım taşınabilirliği arttırılmış olur.
Bir önceki örnekte (bkz. Şekil 1), bir mutex kullanılarak, paylaşılan verilere yalnızca bir iş parçacığının aynı anda erişebilmesi sağlanır. Genel amaçlı bir işletim sisteminde (örneğin Windows veya Linux), bir iş parçacığı, mutex'in serbest kalmasını sonsuza kadar bekleyebilir. Yani, Thread 1 paylaşılan veriye erişmek için Mutex'i beklerken, bu bekleme süresi sınırsız olabilir. Burada Gerçek Zamanlı İşletim Sistemleri (RTOS) devreye girer ve genel amaçlı işletim sistemlerinden ayrılır. RTOS'ta, tüm bekleme durumları zamanla sınırlıdır. Örneğin, Thread 1, bir Mutex'i edinmeye çalıştığında ve bunu 100 ms içinde elde edemezse, sonsuza kadar beklemek yerine belirli bir süre sonra işlemine devam eder. Bu bekleme süresi, RTOS'ta belirli bir üst sınır olarak tanımlanır ve bu sayede sistemde bir deterministik yapı sağlanır.
Not: Deterministik sistem, işlemlerin belirli bir düzen ve öngörülebilir sürelerle gerçekleştiği sistem anlamına gelir. RTOS'larda bu yapı, sistemin kritik görevleri zamanında yerine getirmesini sağlar.
Bu fark ile birlikte RTOS'un zaman açısından hassas olan sistemlerde kullanılması sağlanır. Örneğin, endüstriyel otomasyon veya otomotiv gibi alanlarda, bir işlemin ne kadar süre içinde tamamlanacağını bilmek oldukça önemlidir. Bu nedenle, RTOS sistemlerinde, Mutex gibi kaynaklar için bekleme süresi sınırlıdır ve belirli bir süre aşıldığında iş parçacığı bilgilendirilir. Bu sayede sistemde istenmeyen gecikmelerin önüne geçilir.
Herhangi bir işletim sistemi (OS), belirli bir kod parçasını öngörülebilir bir süre içerisinde çalıştırabiliyorsa, bu işletim sistemi bir Gerçek Zamanlı İşletim Sistemi (RTOS) olarak kabul edilebilir. Bu geniş tanım, oldukça fazla sayıda sistemi kapsar. Ancak, bir RTOS uygulamasını diğerinden ayıran bazı temel özellikler vardır.
Düşünülesi: Gerçek zamanlı bir görevin zaman sınırını karşılayamama durumu ne sıklıkla kabul edilebilir ve bu sınırın karşılanamaması ne kadar kritik bir durum yaratır?
RTOS uygulamaları genellikle üç kategoriye ayrılır:
Sıkı Gerçek Zamanlı Sistemler (Hard Real-Time Systems)
Kesin Gerçek Zamanlı Sistemler (Firm Real-Time Systems)
Yumuşak Gerçek Zamanlı Sistemler (Soft Real-Time Systems)
Not: Firm ve Soft gerçek zamanlı sistemler arasındaki fark konusunda endüstride tam bir uzlaşı yoktur. Bu yüzden, sistem gereksinimlerinizi iyi anlamanız ve çözümünüzü bu gereksinimlere göre tasarlamanız önemlidir.
Ekstra: Bir sistemde, bir hatanın ciddiyeti güvenlik açısından tehlike oluşturuyorsa, bu tür hatalar güvenlik-kritik olarak kabul edilir. Örneğin, bir hata sonucunda hayat kaybı veya büyük bir mülk kaybı riski varsa, bu durum güvenlik-kritik olarak değerlendirilir. Ancak, tüm sıkı gerçek zamanlı sistemler güvenlikle ilgili değildir. Örneğin, bazı endüstriyel otomasyon sistemlerinde de sıkı zaman gereksinimleri olabilir, fakat bu durumlar güvenlik riski oluşturmaz.
Gerçek Zamanlı Sistem Türleri: Hard, Firm ve Soft
Gerçek zamanlı sistemler üç ana kategoriye ayrılır: sıkı (hard), kesin (firm) ve yumuşak (soft). Bu sınıflandırma, sistemin bir görevi belirlenen zaman sınırında yerine getirmediğinde ne tür sonuçlarla karşılaşılacağını anlamamıza yardımcı olur.
Sıkı Gerçek Zamanlı Sistemler (Hard Real-Time Systems)
Sıkı gerçek zamanlı (Hard Real-Time System) bir sistem, her zaman belirlenen süreyi tam olarak karşılamalıdır; yani zaman sınırını %100 oranında karşılamak zorundadır. Bu tür sistemlerde, tek bir zaman sınırının kaçırılması bile sistemin başarısızlığı anlamına gelir. Bu, her zaman bir güvenlik riski oluşturmasa da, sistemin işlevini yerine getiremediğini gösterir.
Örnek: Medikal cihazlar ve kontrol sistemleri. Örneğin, bir kalp pili (pacemaker) tam zamanında bir elektrik darbesi vermesi gereken bir cihazdır. Eğer kalp pili, doğru anda bu darbeyi veremezse, hastanın hayatı tehlikeye girebilir. Bu yüzden, kalp pilleri gibi cihazlar güvenlik-kritik olarak kabul edilir.
Başka bir örnek olarak, Bilgisayarlı Sayısal Kontrol (CNC) tezgahları verilebilir. CNC tezgahında, hareket kontrol sistemi belirlenen bir komuta zamanında tepki vermezse, takım yanlış yere dalabilir ve işlenen parçaya zarar verebilir. Burada hayat riski olmamakla birlikte, tek bir zaman sınırının kaçırılması, iş parçasının hurdaya dönüşmesine neden olabilir. Yani, her iki durumda da tek bir zaman sınırının kaçırılması önemli sonuçlar doğurur.
Kesin Gerçek Zamanlı Sistemler (Firm Real-Time Systems)
Kesin gerçek zamanlı sistemler, zaman sınırlarını çoğu zaman karşılamak zorundadır; ancak, arada sırada bu sınırların aşılması ciddi bir sistem hatası olarak kabul edilmez. Bu tür sistemlerde, zaman zaman ufak gecikmeler yaşanabilir ancak bu durum genelde kullanıcının rahatsız olması dışında büyük bir sorun yaratmaz.
Örnek: Video ve ses senkronizasyonu. Video ve ses bir anlığına senkronizasyon dışına çıkarsa, bu kullanıcıyı rahatsız edebilir ancak sistemin genel işlevini kaybettiği anlamına gelmez. Başka bir örnek olarak, bir sıcaklık kontrol sistemi düşünülebilir. Bu tür bir sistemde, birkaç veri örneği (sample) zamanında okunmasa bile, sistemin tamamının bozulmasına yol açmaz. Ancak, bu durum çok sık tekrarlanırsa sıcaklık dengesi bozulabilir ve sistemin çalışma standartlarına uygun çalışması zorlaşır.
Yumuşak Gerçek Zamanlı Sistemler (Soft Real-Time Systems)
Yumuşak gerçek zamanlı sistemler, zaman sınırlarını karşılama konusunda en esnek olan sistemlerdir. Bu tür sistemlerde, belirli bir süre içinde işlem yapılması hedeflenir, ancak bu her zaman mümkün olmayabilir. Sistem, bu sınırları karşılamak için "elinden geleni yapma" garantisi verir, ancak her zaman başarı garantisi sunmaz.
Örnek: Arabalarda hız sabitleyici (cruise control). Hız sabitleyici sisteminde, aracın hızı +/- belirli bir oranda hedef hıza yakın olacak şekilde ayarlanır. Ancak, sistemin her zaman bu hıza ulaşması gerekmez. Örneğin, büyük bir yokuş çıkarken sistem hızını tam olarak koruyamayabilir. Yine de, çoğu durumda sürücüye hedef hıza yakın bir hız sunar. Bu tür sistemlerde belirli bir tolerans vardır ve tam zamanında tepki vermeme, sistemin başarısızlığı olarak kabul edilmez.
RTOS Çeşitleri ve Alanları
Gerçek Zamanlı İşletim Sistemleri (RTOS), işlevsellik açısından oldukça geniş bir yelpazeye sahiptir ve bu sistemler, en iyi performansı sağlamak için farklı mimarilere ve işlemci boyutlarına uyacak şekilde tasarlanmıştır. Küçük sistemler için 8–32 bitlik mikrodenetleyici (MCU) odaklı RTOS'lar örnek verilebilir; bunlara FreeRTOS, Keil RTX, Micrium µC ve ThreadX gibi sistemler dahildir. Bu tür RTOS'lar, mikrodenetleyicilerde kullanılmak üzere kompakt bir gerçek zamanlı çekirdek sunar.
Daha büyük işlemciler, yani 32 ve 64 bitlik uygulama işlemcilerine geçildiğinde, Wind River VxWorks, Wind River Linux, Green Hills Integrity OS, Blackberry QNX ve PREEMPT_RT çekirdek uzantılarına sahip Linux gibi daha kapsamlı RTOS'lar karşımıza çıkar. Bu işletim sistemleri, hem gerçek zamanlı zamanlama gereksinimlerini hem de genel hesaplama görevlerini destekleyen geniş bir yazılım seçeneği sunar.
Düşünülesi: Bu kadar çok seçenek varken, bazı RTOS'ların ücretli olması dikkat çekici. Peki, ücretsiz seçenekler varken neden ücretli bir RTOS tercih edelim? Bu tercih, sistemin ihtiyaçlarına ve beklentilerine bağlı olarak değişir.
Ücretli ve Ücretsiz RTOS Çözümleri Arasındaki Farklar
Ücretli RTOS çözümlerini ücretsiz çözümlerden ayıran üç temel unsur vardır: güvenlik onayları, ara katman yazılım (middleware) ve müşteri desteği.
Güvenlik Onayları: RTOS'lar, yüksek deterministik bir çalışma ortamı sunduğu için güvenlik-kritik uygulamalarda sıklıkla kullanılır. Güvenlik-kritik sistemler, hata yapması durumunda insanlara zarar verebilecek veya büyük maddi kayıplara yol açabilecek sistemlerdir. Bu tür sistemlerde, yazılımın her zaman öngörülebilir bir şekilde çalışması gerekir. Bir olay karşısında belirli bir süre içinde yanıt verme garantisi, güvenli ve tutarlı bir davranışı sağlamak için önemlidir. Bu güvenlik-kritik uygulamalar, belirli düzenleyici standartlara uymak zorundadır. Örneğin, DO-178B ve DO-178C havacılık alanında, IEC 61508 SIL 3 ve ISO 26262 ASILD ise endüstriyel ve otomotiv uygulamalarında sıkça kullanılan standartlardır. Güvenlik sertifikalarını daha uygun maliyetle sağlamak için, tasarımcılar ya bu sistemlerde kullanılan kodu oldukça basit tutarak hatasız bir şekilde çalışacaklarını matematiksel olarak kanıtlar ya da sertifikalı bir ticari RTOS çözümü kullanırlar. Örneğin, WITTENSTEIN SafeRTOS, endüstriyel, tıbbi ve otomotiv kullanımı için onaylara sahip olan FreeRTOS'un bir türevidir.
Ara Katman Yazılım (Middleware): Karmaşık sistemlerde ara katman yazılım, çok önemli bir bileşen olabilir. Middleware, kullanıcı kodu (yani geliştiricinin yazdığı uygulama kodu) ile RTOS ya da doğrudan donanım (bare metal) arasında çalışır. Ücretli çözümler, önceden entegre edilmiş yüksek kaliteli middleware bileşenleri sunar; örneğin dosya sistemleri, ağ yığınları, kullanıcı arayüzü çerçeveleri ve endüstriyel protokoller gibi. Bu middleware, geliştirme süresini azaltır ve proje risklerini minimize eder. Kendi middleware'inizi yazmak yerine hazır çözümleri kullanmak, hem riskleri hem de geliştirme süresini azaltarak, özellikle büyük ve karmaşık projelerde iyi bir yatırım olabilir.
Örneğin FreeRTOS, ücretli destek ve eğitim seçenekleri sunar. Ayrıca, ücretli olarak eklenebilen middleware çözümleri de vardır. Bununla birlikte, açık kaynaklı veya ücretsiz middleware bileşenleri de bulunmaktadır ve bu bileşenler, proje ihtiyaçlarına göre entegrasyon sağlanarak kullanılabilir.
Bu Seride Hangi RTOS Kullanılacak?
RTOS dünyasında birçok seçenek varken, bu serimizde tek bir RTOS ve tek bir MCU modeli üzerine odaklanacağız. Bu tercihin birkaç sebebi var. Öncelikle, serimizde ele alınacak çoğu kavram, neredeyse her RTOS üzerinde uygulanabilir niteliktedir. Nasıl ki iyi programlama alışkanlıkları programlama dilinden bağımsız bir değere sahipse, RTOS üzerinde anlatılacak temel bilgiler de herhangi bir RTOS’e uyarlanabilir. Tek bir RTOS ve tek bir MCU modeli üzerinde yoğunlaşarak, alternatifleri de ele almaya çalıştığımız bir senaryoya göre konuları daha derinlemesine inceleyebileceğiz.
Bu serimizde kullanılan RTOS, mikrodenetleyiciler için en popüler RTOS uygulamalarından biri olan FreeRTOS. FreeRTOS, 15 yılı aşkın bir süredir piyasada olup, onlarca farklı platforma taşınmış durumdadır. RTOS programlama konusunda deneyimli bir gömülü sistemler mühendisiyle konuşursanız, FreeRTOS'u duyduklarından veya en az bir kez kullandıklarından emin olabilirsiniz. Bu nedenle, FreeRTOS'a odaklanarak, bu RTOS üzerinde edindiğiniz bilgileri hızlı bir şekilde başka donanımlara veya farklı bir RTOS'e geçirebilmeniz mümkün hale gelecektir.
Not: Bir diğer sebep de FreeRTOS’un ücretsiz olmasıdır! FreeRTOS, MIT lisansı altında dağıtılmaktadır ve bu da onu açık kaynaklı bir seçenek haline getirir. Daha fazla bilgi için FreeRTOS lisans sayfasına göz atabilirsiniz. Ayrıca, FreeRTOS'un türevleri olan SafeRTOS ve OpenRTOS gibi seçenekler de mevcuttur.
Yukarıdaki görsel, bir ARM tabanlı sistemde FreeRTOS’un hangi katmanda yer aldığını gösteren bir yığın yapısını (firmware stack) temsil ediyor. Bu yığın, sistemi oluşturan farklı katmanlardan oluşur ve her bir bileşen üst üste yerleşir. Burada "user" terimi, gömülü sistemin son kullanıcısından ziyade FreeRTOS’u kullanan programcıyı ifade etmektedir. Burada user kodu, altta hangi donanım portu kullanılıyor olursa olsun, aynı FreeRTOS API’sine erişebilir. Bu durum, kodun farklı donanımlar arasında kolayca taşınabilmesini sağlar. FreeRTOS, kullanıcı kodunun satıcı tarafından sağlanan sürücüleri (vendor drivers), CMSIS (Cortex Microcontroller Software Interface Standard) ya da doğrudan donanım kayıtlarını (hardware registers) kullanmasına engel olmaz.
Bu yapıyı ve FreeRTOS'un sunduğu esnekliği anladıktan sonra, bir RTOS'un hangi durumlarda kullanılması gerektiğine daha yakından bakabiliriz.
Hangi Durumlarda RTOS Gerekli?
Gerçek zamanlı işletim sistemi (RTOS) kavramını ilk duyanlar, RTOS’un gömülü sistemlerde gerçek zamanlı davranış elde etmenin tek yolu olduğunu düşünebilirler. Ancak, bu düşünce yanlış bir kanıya yol açabilir. RTOS, her durum için çözüm olmaktan ziyade, belirli problemlerde tercih edilebilecek bir çözüm olarak değerlendirilmelidir. Özellikle mikrodenetleyici (MCU) tabanlı bir RTOS’un ideal çözüm olabilmesi için, problemin karmaşıklık seviyesi uygun olmalıdır: ne çok basit ne de çok karmaşık.
Örneğin, yalnızca iki durumun izlenmesi ve bu durumlar aynı anda mevcut olduğunda bir alarm tetiklenmesi gibi basit bir sorun varsa, bunu çözmek için RTOS’a ihtiyaç duyulmayabilir. Bu tür bir durumda, bir AND kapısı gibi basit bir donanım çözümü yeterli olabilir.
Daha karmaşık bir örneği ele alalım: Bir motorun hızını kontrol etmek ve bir enkoder aracılığıyla gidilen mesafeyi izlemek. Bu görevler, analog veya dijital donanımlarla yapılabilir, ancak mesafeyi ayarlamak ve kontrol döngüsünü ayarlamak gibi gereksinimler donanım çözümlerinde zorluk yaratabilir. Bu noktada, CPLD veya FPGA gibi programlanabilir mantık cihazları kullanılabilir. Ancak, FPGA’nin maliyeti bazı durumlarda kabul edilemeyebilir. Aynı zamanda, mevcut ekipte donanım dillerine veya araçlarına aşina olan kişiler yoksa, bare-metal MCU yazılımı daha iyi bir çözüm olabilir.
Şimdi daha karmaşık bir senaryoyu düşünelim: Bir cihaz, farklı aktüatörleri kontrol ediyor, çeşitli sensörlerden veri topluyor, bu verileri yerel hafızaya kaydediyor ve bir ağa (Ethernet, Wi-Fi, CAN vb.) bağlanması gerekiyor. Bu tür bir durumda RTOS oldukça kullanışlı olabilir. Birden fazla görevin birbirinden bağımsız şekilde tamamlanması gerektiğinde, RTOS’un getirdiği ek karmaşıklıklar, sağladığı avantajlarla dengelenebilir. RTOS, daha düşük öncelikli ve karmaşık görevlerin (örneğin ağ ve dosya sistemi işlemleri) daha kritik zaman gerektiren görevlerle (aktüatör kontrolü ve sensör okuma gibi) çakışmasını engeller. Ayrıca, kontrol sistemleri belirli zaman aralıklarında çalıştığında daha verimli hale gelir ki bu da RTOS’un güçlü olduğu bir alandır.
Daha da karmaşık bir sistem örneğini ele alalım: Bu cihaz, web sayfası sunma, kullanıcı kimlik doğrulaması yapma ve farklı dosya protokolleri kullanarak çeşitli dizinlere dosya aktarma gibi birden fazla ağ gereksinimine sahip. Bu tür bir karmaşıklık RTOS ile de yönetilebilir, ancak mevcut kaynaklara göre, bazı durumlarda tam donanımlı bir OS (RTOS veya genel amaçlı OS) daha uygun olabilir. Gerekli karmaşık yazılım yığınları (örneğin ağ yığınları, dosya protokolleri) genellikle hazır olduğundan, bu tür karmaşık bir sistem için çok çekirdekli bir yapı da kullanılabilir. Bir çekirdek RTOS’u çalıştırırken, diğer çekirdek genel amaçlı bir OS çalıştırabilir.
Tabiki de bunlar birer fikirdir ve gerçek dünyada bu seçimler proje gereksinimine bağlıdır. Bu sebeple Her durumda RTOS veya başka bir gerçek zamanlı çözümün en doğru seçenek olup olmadığına dair kesin bir kural yoktur.
İlk bölümün 2 ayağında gerçek zamanlı gereksinimlerin nasıl tanımlanacağını ve gerçek zamanlı sistemlerin uygulanabileceği farklı platformları ele aldık. Artık, geniş bir yelpazeye yayılan gerçek zamanlı gereksinimlere sahip sistemleri ve bu gereksinimleri karşılamak için kullanılabilecek çeşitli yöntemleri anlama becerisine sahibiz. Bu bölümü tamamlarken, öğrendimiz bilgileri test edebilmek için şu soruyu düşünebiliriz:
"Bir sistem tasarlayacak olsaydınız, bu sistemin güvenilirlik, gerçek zamanlılık ve performans gereksinimlerine bağlı olarak hangi yaklaşımı (RTOS, GPOS, Bare-Metal) tercih ederdiniz? Tercih ettiğiniz yaklaşımı hangi avantajları ve sınırlamaları göz önünde bulundurarak gerekçelendirirdiniz?"
Bir sonraki bölümde, mikrodenetleyici (MCU) tabanlı gerçek zamanlı sistemlere daha yakından bakacağız. Bu kapsamda, iki farklı programlama modelini - süper döngüler (super loops) ve RTOS görevleri (RTOS Tasks) - incelemeye başlayacağız.
Dilerseniz Patreon Sayfam üzerinden bu çabamı maddi katkılarınızla destekleyebilirsiniz.
Muhteşem