# ARINC 653 ile Zamansal ve Mekansal Bölümlendirme > ARINC 653, aynı aviyonik bilgisayarda çalışan farklı kritik uygulamaları partition sınırlarıyla ayırır. İzolasyon yalnız process seviyesinde değil, zaman bütçesi ve kaynak erişimi seviyesinde de kurulmalıdır. - Author: Muhammet Ali Köker - Language: tr - Canonical: https://alikoker.com.tr/arinc-653-zamansal-ve-mekansal-bolumlendirme - Published: 2022-06-15T12:00:00+03:00 - Modified: 2026-08-19T16:59:00+03:00 - Verified: 2026-08-19T16:59:00+03:00 - Type: article Safety-critical bir bilgisayarda iki uygulamanın birbirinin belleğini bozmaması yeterli değildir. Düşük kritik seviyeli bir partition CPU'yu zamanında bırakmıyorsa daha kritik fonksiyonun deadline'ı kaçabilir. Bu nedenle izolasyonun iki boyutu vardır: alan ve zaman. Aviyonik veri iletişimiyle ilk temas ettiğim dönemden beri gerçek zamanlı sistemlerde en önemli farkın "hızlı çalışmak" ile "ne zaman çalışacağını bilmek" arasındaki ayrım olduğunu düşünüyorum. ARINC 653 bu ayrımı sistem mimarisinin merkezine koyar. ## Integrated Modular Avionics neden partition ister? Klasik federated mimaride her avionics fonksiyonu ayrı donanıma sahip olabilir. Integrated Modular Avionics (IMA) yaklaşımı ise aynı computing platform üzerinde birden fazla uygulamanın kaynak paylaşmasına izin verir. Donanım azalır, fakat failure containment zorlaşır. Aynı CPU ve belleği kullanan yazılımlardan birindeki hata diğerini etkilememelidir. Partitioning burada yalnız virtualization benzeri bir kolaylık değil, safety argümanının parçasıdır. ARINC 653, APEX servisleri ve partition modelini bu bağlamda tanımlar. ## Space partitioning Mekansal bölümlendirme, bir partition'ın başka partition'a ait bellek veya kaynağa izinsiz erişmesini engellemeyi amaçlar. MMU/MPU mekanizmaları bu işin donanımsal temelini oluşturabilir. Ancak yalnız address-space izolasyonu yetmez. Shared memory, I/O device, DMA ve inter-partition communication kanalları da kontrollü olmalıdır. Bir partition'daki pointer hatasının başka partition'ın state'ini değiştirememesi beklenir. Bu, klasik process isolation ile benzer görünür; fark, safety-critical sistemde davranışın doğrulanabilir ve konfigürasyonla sınırlandırılmış olmasıdır. ## Time partitioning Zamansal bölümlendirme daha ilginçtir. ARINC 653 yaklaşımında partition'lar belirli zaman pencerelerinde çalıştırılır. Major time frame içinde her partition'a ayrılmış window'lar bulunabilir. Schedule döngüsel ve önceden belirlenmiş olabilir. Örneğin: ```text Major frame: 100 ms 0-20 ms Partition A 20-35 ms Partition B 35-65 ms Partition A 65-100 ms Partition C ``` Partition B kendi içindeki task scheduling yüzünden 15 ms bütçesini aşmaya çalışsa bile Partition C'nin başlangıç zamanını keyfi biçimde öteleyememelidir. Bu özellik average CPU utilization hesabından farklıdır. CPU yüzde 40 boş olsa bile partition window dışındaysa uygulamanın çalışması istenmeyebilir. Determinism'in bedeli budur. ## Partition içinde ikinci bir scheduler vardır ARINC 653 partition scheduling ile process scheduling'i birbirinden ayırır. İlk katman hangi partition'ın CPU kullanabileceğini belirler. Aktif partition içinde ise process'ler priority ve zamanlama politikalarına göre yönetilebilir. Bu iki seviyeyi karıştırmak capacity hesabında hata üretir. Bir process'in worst-case execution time'ı partition window'una sığsa bile aynı partition'daki diğer process'lerle birlikte deadline analizi yapılmalıdır. Dolayısıyla gerçek zamanlı planlama `partition budget -> process budget -> operation budget` şeklinde aşağı doğru parçalanır. ## Communication kontrollü olmalıdır Partition izolasyonu tamamen iletişimsizlik değildir. Uygulamalar veri paylaşmak zorundadır. ARINC 653 sampling port ve queuing port gibi iletişim semantikleri tanımlar. Sampling yaklaşımında son değer okunur; queuing yaklaşımında mesaj sırası ve kapasite önem kazanır. Burada alışıldık dağıtık sistem problemlerinin daha deterministik bir versiyonu karşımıza çıkar: queue dolarsa ne olur, eski veri ne zaman geçersiz sayılır, mesaj boyutu üst sınırı nedir ve producer/consumer farklı partition window'larında ise maksimum gecikme ne olur? Bir mesajın network latency'si düşük olsa bile receiving partition bir sonraki window'a kadar çalışamıyorsa end-to-end latency büyür. ## Health monitoring bir log sistemi değildir Health monitoring'in amacı exception stack trace toplamak değildir. Hatanın kapsamına göre process restart, partition restart, module seviyesinde recovery veya sistem durum değişikliği gibi önceden tanımlı aksiyonlar gerekir. Safety-critical sistemde "beklenmeyen exception oldu, logladık" yeterli değildir. Failure mode önceden sınıflandırılmalı, recovery davranışı bounded olmalıdır. Ben kritik production servislerinde de bu düşünce biçimini değerli buluyorum. Her sistemi ARINC 653 gibi tasarlamak gerekmez; fakat hangi hata hangi sınırda tutulacak ve recovery hangi state'i kaybedecek soruları aynı derecede önemlidir. ## Configuration kod kadar kritiktir Partition window'ları, port'lar, bellek alanları ve yetkiler configuration ile tanımlanıyorsa yanlış configuration uygulama kodu kadar tehlikelidir. Bu yüzden schema doğrulama, static consistency check ve deployment artifact'ının bütünlüğü önem kazanır. TÜBİTAK BİLGEM'in ARINC 653 odaklı gerçek zamanlı işletim sistemi çalışmalarında da conformance ve time partitioning doğrulamasının ayrı araştırma konusu olması tesadüf değildir. ## Throughput yerine worst-case davranış Sunucu yazılımında çoğu zaman throughput artırmaya çalışırız. Safety-critical real-time dünyada önce worst-case davranış sorulur. Cache miss, interrupt, context switch ve I/O jitter hesap dışında bırakılamaz. Ortalama 2 ms çalışan fonksiyonun nadiren 18 ms sürmesi, 10 ms budget'lı partition için kabul edilemez. Bu bakış açısı gerçek zamanlı ses, kontrol ve veri toplama sistemlerinde de işe yarar. P50 değerinin iyi olması deadline garantisi değildir. ## ARINC 653'ten alınacak genel ders ARINC 653'ü yalnız havacılık standardı olarak okumak eksik olur. Daha genel mühendislik dersi, isolation'ın resource ownership ile birlikte zaman ownership gerektirebilmesidir. Microservice'lerde CPU quota, container isolation veya bounded worker pool kullanırken aynı problem daha gevşek biçimde karşımıza çıkar. Kritik sistemde kaynak paylaşımı varsa "kim ne kadar kullanabilir?" sorusunun yanında "ne zaman kullanabilir?" sorusu da tasarımın parçasıdır. ## Kaynakça - [TÜBİTAK BİLGEM - Real Time Operating System Adaptation Projects](https://bilgem.tubitak.gov.tr/en/real-time-operating-system-gis/) - [TÜBİTAK BİLGEM - BTE Publications](https://bilgem.tubitak.gov.tr/en/publications/bte-publications/) ## Bu Çalışmaya Atıf Köker, M. A. (2022). ARINC 653 ile Zamansal ve Mekansal Bölümlendirme. alikoker.com.tr. https://alikoker.com.tr/arinc-653-zamansal-ve-mekansal-bolumlendirme - BibTeX: https://alikoker.com.tr/arinc-653-zamansal-ve-mekansal-bolumlendirme.bib - RIS: https://alikoker.com.tr/arinc-653-zamansal-ve-mekansal-bolumlendirme.ris - CSL-JSON: https://alikoker.com.tr/arinc-653-zamansal-ve-mekansal-bolumlendirme.csl.json