ARINC 653 ile Zamansal ve Mekansal Bölümlendirme

Zamansal ve Mekânsal Bölümlendirme Aynı Şey Değildir

ARINC 653 yaklaşımında zamansal bölümlendirme, bir partition'ın işlemciyi hangi pencerelerde kullanacağını; mekânsal bölümlendirme ise bir partition'ın başka bir partition'ın bellek alanına ve kaynaklarına izinsiz erişememesini hedefler. Birincisi zaman çizelgesi ve bütçe problemi, ikincisi koruma ve adres alanı problemidir.

Major time frame içinde partition window'larının deterministik olarak planlanması, yüksek öncelikli bir uygulamanın bütün işlemci zamanını tüketmesini engeller. Buna karşılık doğru zaman çizelgesi tek başına bellek izolasyonu sağlamaz. Güvenilir IMA tasarımında zaman, bellek ve partitionlar arası iletişim ayrı doğrulama sınırları olarak ele alınmalıdır.

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:

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 görev 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 zamanlayıcı 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: kuyruk dolarsa ne olur, eski veri ne zaman geçersiz sayılır, mesaj boyutu üst sınırı nedir ve üretici/tüketici farklı partition window'larında ise maksimum gecikme ne olur?

Bir mesajın network gecikmesi düşük olsa bile receiving partition bir sonraki window'a kadar çalışamıyorsa end-to-end gecikme büyür.

Health monitoring bir log sistemi değildir

Health monitoring'in amacı istisna 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 istisna oldu, logladık" yeterli değildir.

Failure mode önceden sınıflandırılmalı, recovery davranışı sınırlı olmalıdır.

Ben kritik üretim 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 dağıtım 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.

Işlem hacmi yerine worst-case davranış

Sunucu yazılımında çoğu zaman işlem hacmi artırmaya çalışırız. Safety-critical real-time dünyada önce worst-case davranış sorulur.

Önbellek 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 sınırlı çalışan 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

• SAE Industry Technologies Consortia / Airlines Electronic Engineering Committee. ARINC653P1-6: Avionics Application Software Standard Interface, Part 1, Required Services. 16 Aralık 2024.

• TÜBİTAK BİLGEM. BTE Publications. https://bilgem.tubitak.gov.tr/en/publications/bte-publications/

• TÜBİTAK BİLGEM. Real Time Operating System Adaptation Projects. https://bilgem.tubitak.gov.tr/en/real-time-operating-system-gis/

Kavram Katmanı

Bu yazıda kullanılan partition modeli için kısa tanım ve terim bağlantısı ARINC 653 maddesinde tutulur. Buradaki ayrıntılı anlatım ise zaman pencereleri, mekansal izolasyon, health monitoring ve gerçek zamanlı sistem davranışının birlikte nasıl değerlendirildiğine odaklanır.