Taleb bu üçüncü hâl için yeni bir sözcük kullanır: antifragile, antikırılgan. Kavramın asıl değeri, belirsizlik karşısındaki alışkanlığımızı tersine çevirmesindedir: amaç bir sonraki şoku tahmin etmek değil, şoktan hangi yönde etkileneceğimizi baştan tasarlamaktır. Aşağıda önce kavramı ve altındaki asimetriyi tanımlıyor, ardından yazılımdan ürüne ve topluluğa kadar farklı sistemlere uygulanışını ele alıyoruz.

Antikırılganlık Nedir? Üçlü Yelpaze

Taleb bu noktayı bir kargo örneğiyle somutlaştırır. Bir kutunun üstünde KIRILIR yazar; karşıtı çoğu kişiye göre “dayanıklı”dır. Oysa dayanıklı kutunun üstünde hiçbir şey yazmaz, çünkü nasıl savrulduğu onu ilgilendirmez. Asıl karşıt uç, üstünde “lütfen hırpalayın” yazabilecek, sarsıldıkça içindeki daha iyi duruma gelen kutudur. Dilde böyle bir kelime yoktu; Taleb bu boşluğu “antikırılgan” ile doldurdu.

Buradan üçlü bir yelpaze çıkar. Her şeyi volatiliteye — yani belirsizliğe, strese, rastgeleliğe, şoka — verdiği tepkiye göre üçe ayırabiliriz:

Burada sık yapılan bir karışıklık var: antikırılganlık ile dayanıklılık aynı şey değildir. Dayanıklı sistem şoktan sonra aynı kalır, antikırılgan sistem gelişir. Kas ağırlık kaldırdıkça güçlenir, kemik yük altında yoğunlaşır, bağışıklık denetimli maruziyetle öğrenir. Bu sistemlerin ortak yanı, aşırı korumanın onları güçlendirmek yerine zayıflatmasıdır; belirli bir stresin yokluğu başlı başına bir kırılganlık kaynağıdır.

Konveksite: Antikırılganlığın Matematiği

Bir şeyi antikırılgan yapan nitelik asimetridir. Antikırılgan bir yapının volatilite karşısındaki kazancı kaybından büyüktür: iyi giderse çok kazanır, kötü giderse az kaybeder. Taleb bunu konveksite (dışbükeylik) olarak adlandırır. Tersi bir cam bardakta görülebilir: bardağı bir metreden bir kez düşürmek, bir santimden yüz kez düşürmekten çok daha zararlıdır. Küçük sarsıntılar etkisiz kalır, tek büyük darbe parçalar. Kayıp stresle orantısız büyüdüğünde ortaya çıkan içbükey eğri, kırılganlığın imzasıdır.

Antikırılgan yapıda işaret tersine döner. Bir denemenin başarısızlık maliyeti sınırlıyken (örneğin sınırlı bir zaman ve bütçe) başarısının getirisi açık uçluysa, dağılımın aşağı yönü kapalı, yukarı yönü açıktır. Taleb’in vurgusu da buradadır: geleceği tahmin etmeye değil, maruziyeti dışbükey kılmaya odaklanmak. Onun çerçevesinde volatilite, rastgelelik, stres, hata ve zaman aynı ailenin üyeleridir; düzensizliğin farklı görünümleridir ve antikırılgan yapılar bu düzensizlikten beslenir.

Antikırılganlığın Araç Çantası

Konveksite tesadüfe bırakılmak zorunda değildir; tasarlanabilir. Aşağıdaki pratikler, ilerleyen bölümlerdeki farklı alanların hepsinde tekrar eder:

• Barbell (halter) stratejisi: Riski iki uçta toplamak; ağırlığı aşırı güvenli tarafa koyup küçük bir payı çok sayıda yüksek riskli, açık uçlu girişime ayırmak. Belirsizliği yanlış ölçülen “orta risk” bölgesinden kaçınmak.
• Opsiyonellik: Yükümlülük değil seçenek biriktirmek; kötü senaryoda kullanılması zorunlu olmayan, iyi senaryoda getirisi açık seçenekler.
• Via negativa: Sağlamlığı bir şey ekleyerek değil, kırılganlık kaynaklarını çıkararak artırmak.
• Hormesis: Küçük, sık ve iyileşmeye fırsat tanıyan stresörlerle sistemi büyük şoka hazırlamak; aşırı koruma yerine denetimli maruziyet.
• Skin in the game: Kararı verenin sonucun riskini de taşıması; aksi hâlde kayıplar sisteme, kazançlar bireye kalır ve gizli kırılganlık birikir.
• Artıklık ve ademimerkeziyet: Yedeklilik kısa vadede verimsizlik gibi görünse de belirsizliğe karşı bir tampondur; dağıtık karar tek bir kırılma noktasını ortadan kaldırır.

Uygulama: Altı Alanda Antikırılganlık

Yazılıma

Yazılım, kavramın en doğrudan uygulandığı alanlardan biridir; sektör buna Chaos Engineering adını bile vermiştir. Netflix’in Chaos Monkey aracı, üretim ortamında rastgele sunucuları bilerek devre dışı bırakır. Mantık hormesistir: sistemi her gün küçük ve denetimli arızalara maruz bırakan ekip, büyük arıza geldiğinde ona dayanacak biçimde olgunlaşmış bir mimariye sahip olur. Aynı asimetriyi error budget, feature flag ile birlikte otomatik geri alma (hatanın etkisini saniyeler içinde sınırlar), fuzzing ve hatayı suç değil veri olarak ele alan suçlamasız postmortem kurar. Buradaki örtük kırılganlık genellikle aşırı optimizasyondur: her şeyi sıkıca birbirine bağlayıp son damla verimi sıkan bir sistem, beklenmedik tek bir girdide bütünüyle çöker. Coupling’i Dengelemek yazısında ele alındığı gibi, amaç bağımlılığı yok etmek değil dengede tutmak ve bir bileşen çökerken sistemin bütününün denetimli biçimde geri çekilmesine (graceful degradation) izin vermektir.

Bir Proje Ekibine

Bir ekip de strese maruz kalan bir sistemdir ve antikırılganlığı, kriz sonrasında dağılıp dağılmadığıyla ölçülür. Belirleyici etken psikolojik güvenliktir: hatayı açıkça dile getirebilen bir ekipte her hata ortak hafızaya yazılır, hatanın gizlendiği ekipte ise hatalar birikip aynı anda açığa çıkar. Bunu mümkün kılan pratikler tanıdıktır; bilgi tek kişiye bağlı kalmasın diye çapraz eğitim, belirsizliğe pay bırakan plan boşluğu (slack), ucuza denenip ucuza vazgeçilebilen küçük denemeler ve olaylardan sonuç çıkaran düzenli değerlendirmeler. Ekibi her çatışmadan ve başarısızlıktan yalıtmak, çoğu zaman onu güçlendirmek yerine kırılganlaştırır.

Bir Şirkete

Şirket ölçeğinde antikırılganlık çoğu zaman bir barbell yapısına benzer: gelirin büyük kısmı kanıtlanmış, nakit üreten çekirdekte dururken küçük bir pay çok sayıda ucuz ve açık uçlu girişime ayrılır. Bu girişimlerin çoğu sonuç vermez, ancak tutan birkaçı tüm portföyü taşıyabilir. Kırılgan şirketin işaretleri ise bellidir: tek bir müşteriye veya tedarikçiye bağımlılık, yüksek borç ve kaldıraç, her şeyi verimlilik adına en sınıra kadar yontmak, kararı tek merkezde toplamak. Antikırılgan şirket daha ademimerkezidir, elinde seçenek tutar, durgunlukta rakipleri elenirken pay kazanır ve kararı verenle sonucun riskini taşıyanı aynı tarafta tutar.

Bir Ürüne

Bir ürünün antikırılganlığı, gerçek kullanımla temas ettikçe bozulacak mı yoksa öğrenecek mi biçimde tasarlandığına bağlıdır. MVP ve hızlı yineleme, baştan doğru ürünü tahmin etme iddiasından vazgeçip ürünü kullanım geri bildirimiyle biçimlendirme yaklaşımıdır; tahminin yerini denetimli maruziyet alır. A/B testleri her özelliği küçük ve geri alınabilir bir denemeye dönüştürür, böylece zayıf seçenek düşük maliyetle elenir. Kademeli dağıtım (canary), beta kanalları, ekibin kendi ürününü kullanması (dogfooding) ve kullanıcı hata bildirimlerini birincil veri olarak ele alan döngüler, ürünü sürekli küçük stresörlere maruz bırakarak olgunlaştırır.

Bir Topluluğa

Açık kaynak toplulukları bu özelliği belirgin biçimde taşır. Bir bakımcı ayrıldığında proje çatallanabilir (fork) ve tek bir kişiye ya da sunucuya bağlı kalmaz. Katkıcı çeşitliliği fikirleri sürekli sınamaya tabi tutar; zayıf öneriler tartışmada elenir, işe yarayanlar kalır. Bu yapıda eleştiri bir tehdit değil bir bağışıklık mekanizmasıdır: kod incelemeleri, açık anlaşmazlıklar ve kamuya açık tartışma topluluğu güçlendirir. Buna karşılık tek kişiye bağlı, merkezîleşmiş ve eleştiriye kapalı bir topluluk, dışarıdan uyumlu görünse de tek bir ayrılışa veya itiraza karşı kırılgandır.

Bir Sisteme

Daha genel olarak, birbiriyle etkileşen parçalardan oluşan her sistemde ilkeler benzerdir. Dağıtık sistemlerde N+1 artıklık, devre kesici (circuit breaker) ve bölme perdesi (bulkhead) desenleri, tek bir arızanın zincirleme bütün sistemi durdurmasını engeller; su alan bölmesi yalıtılırken geminin yüzmeye devam etmesi gibi. Aynı düşünce emniyet-kritik aviyonikte yedekli (redundant) kanallar ve hata sınırlandırma (fault containment) olarak kurumsallaşmıştır. Doğadaki karşılığı evrimdir: çok sayıda küçük başarısızlık üzerinden türü güçlendiren bir süreç işler; birey kırılgan kalırken tür bütününde antikırılgan davranır. Buradaki yaygın hata verimlilik takıntısıdır, çünkü tek bir senaryoya kusursuz biçimde optimize edilen sistem, o senaryonun dışındaki koşullara karşı kırılganlaşır. Bu nitelikler de Sistem Mühendisliği Nedir? yazısındaki beliren özellikler gibi sistem düzeyinde ortaya çıkar ve tek bir parçaya indirgenemez.

Altı alandaki örüntüyü tek bir tabloda karşılaştırmak mümkün:

Tuzaklar: Her Şey Antikırılgan Olmalı mı?

Burada önemli bir sınır var. “Antikırılganlık iyiyse, o hâlde her şeyi üretimde kırarak öğrenelim” çıkarımı tehlikeli bir yanlış okumadır. Her sistem antikırılgan olmak zorunda değildir; bazıları yalnızca dayanıklı olmalıdır. Bir uçağın uçuş kontrol yazılımında, üretim ortamında bilerek arıza üretmek söz konusu olamaz. DO‑178C ve özellikle en yüksek güvence seviyesi olan DAL A’nın bütün varlık nedeni, sistemin sahada deneme yanılmayla değil, daha uçmadan önce kanıtlanmış biçimde doğru çalıştığını göstermektir. Hatanın sonucunun geri döndürülemez olduğu alanlarda hedef dışbükeylik değil, öngörülebilir ve kanıtlanmış güvenilirliktir.

Bunun altında daha temel bir kural yatar: antikırılganlık ancak hayatta kalındığı sürece bir anlam taşır. Sistem bir kez tamamen çökerse, sonraki denemelerin beklenen getirisi ne olursa olsun konu dışıdır; Taleb bunu yıkım (ruin) ve ergodisite kavramlarıyla anlatır. Barbell stratejisinin önce aşağı yönü koruması da bu yüzdendir. Doğru sıra, önce sistemi tümüyle oyun dışı bırakacak şokları olanaksız kılmak, ardından kalan alanı volatiliteden faydalanmaya açmaktır. Bu sıranın tersine çevrilmesi, yani koruma sağlamadan risk almak, antikırılganlık değil yalnızca kumardır.

Sonuç

Antikırılganlık, geleceği daha iyi tahmin etme çabası değil, tahmine bağımlı kalmadan belirsizlik karşısında doğru konumlanma yaklaşımıdır. Kırılgan bir yapı dünyanın tam olarak beklendiği gibi ilerlemesine bel bağlar; dayanıklı yapı sapmalara kayıtsız kalır; antikırılgan yapı ise sapmalardan yararlanacak biçimde kurulmuştur. Pratikte sorulması gereken soru “bu şoktan nasıl kaçınırım” değildir, çünkü bir sonraki şok çoğu zaman öngörülemez; daha verimli soru, hangi yapıların şoktan zarar yerine fayda görecek biçimde tasarlanabileceğidir. Taleb’in via negativa ilkesi gereği bu çoğu zaman yeni bir şey eklemekle değil, sistemi yıkıma açan kırılganlık kaynaklarını (tek bağımlılık noktası, aşırı kaldıraç, hatayı cezalandıran kültür, sınıra kadar yontulmuş optimizasyon) tek tek ortadan kaldırmakla başlar.

Kaynaklar

• Nassim Nicholas Taleb — Antifragile: Things That Gain from Disorder, Random House, 2012. (Türkçesi: Antikırılgan: Belirsizlikten Nasıl Faydalanılır)
• Nassim Nicholas Taleb — The Black Swan: The Impact of the Highly Improbable, Random House, 2007.
• Nassim Nicholas Taleb — Skin in the Game: Hidden Asymmetries in Daily Life, Random House, 2018.
• Nassim Nicholas Taleb — Fooled by Randomness, Texere, 2001.
• Principles of Chaos Engineering — https://principlesofchaos.org/
• A. Basiri vd. — “Chaos Engineering”, IEEE Software, 2016 (Netflix Chaos Monkey / Simian Army).
• B. Beyer, C. Jones, J. Petoff, N. R. Murphy (ed.) — Site Reliability Engineering, O’Reilly, 2016 (error budget, blameless postmortem).
• Coupling’i Dengelemek: Yazılım Tasarımında Bağımlılığı Yönetmek
• Sistem Mühendisliği Nedir?

Çoğumuz bu acıya bir isim veririz: coupling (bağlaşım). Ve hemen ardından bir reçete yazarız: “Demek ki daha az coupling lazım, her şeyi birbirinden ayıralım (decouple edelim).” Ekip bu uğurda kodu mikroservislere böler — ve birkaç ay sonra, ağ üzerinden birbirine eskisinden de sıkı bağlı, ama bu kez hata ayıklaması çok daha zor bir sisteme uyanır.

Sorun coupling’in kötü olması değil; sorun onu yanlış anlamamız. Vlad Khononov’un 2024 tarihli kitabı Balancing Coupling in Software Design tam da bunu söylüyor: coupling, yok edilecek bir kusur değil, dengelenecek bir tasarım niteliğidir. Bu yazıda önce coupling’in ne olduğunu ve neden ondan tamamen kurtulamayacağımızı göreceğiz; sonra Khononov’un onu ölçmek için sunduğu üç boyutlu modeli inceleyeceğiz; ve son olarak bu fikrin en uca taşındığı yere, aviyonik yazılımın DO‑178C standardına bakacağız — orada coupling’i analiz etmek bir tercih değil, bir sertifikasyon şartıdır.

Coupling Nedir? (Ve Neden Ondan Tamamen Kurtulamayız?)

En yalın tanımıyla coupling, iki bileşen arasındaki bağımlılıktır: birindeki değişikliğin diğerinde de değişiklik gerektirme ihtimali. İki modül birbirine ne kadar sıkı bağlıysa, birlikte değişme olasılıkları da o kadar yüksektir.

Khononov bu bağımlılığın özünde iki şeyin yattığını söyler: paylaşılan bilgi (shared knowledge) ve paylaşılan yaşam döngüsü (shared lifecycle). Bir bileşen, diğeri hakkında ne kadar çok şey “bilmek” zorundaysa — onun veri yapısını, kurallarını, iç işleyişini — o kadar bağlıdır. Ve o bilgi değiştiğinde, ona bağlı her yerin de değişmesi gerekir.

Burada kritik bir nokta var: coupling yalnızca yazılıma özgü değildir. Aynı ilişki bir organizasyonda (bir departmanın kararı diğerini etkiler), bir makinede (bir dişlinin dönüşü diğerini sürer), hatta bir takımda da vardır. Coupling, birbiriyle etkileşen parçalardan oluşan her sistemin doğal bir özelliğidir.

Peki neden ondan tamamen kurtulamayız? Çünkü sıfır coupling’e sahip bir sistem, aslında bir sistem değildir. Birbiriyle hiç konuşmayan, hiçbir bilgi paylaşmayan bileşenler bir bütün oluşturmaz; yalnızca yan yana duran, birbirinden habersiz parçalar yığını olur. Bir sistemin değeri — uçağın uçması, uygulamanın iş görmesi — tam da parçaların birlikte çalışmasından, yani onları birbirine bağlayan ilişkilerden doğar. Daha önce Sistem Mühendisliği Nedir? yazısında değindiğimiz beliren özellikler (emergent properties) işte bu bağlardan ortaya çıkar.

Coupling, sistemi bir arada tutan tutkaldır. Tutkalsız sistem dağılır; ama her yeri tutkala bulanmış sistem de kıpırdayamaz. O yüzden doğru soru “coupling’den nasıl kurtulurum?” değildir. Doğru soru şudur: Ne tür, ne kadar ve nerede?

“Decoupling Her Zaman İyidir” Efsanesi

Yazılım kültüründe neredeyse bir slogan vardır: “sıkı bağ değil, gevşek bağ” (loose coupling). Bu öğüt iyi niyetlidir ama yarım kalmıştır; çünkü madalyonun iki yüzü vardır.

Bir uçta aşırı coupling bulunur: her şeyin her şeye bağlı olduğu, tek bir değişikliğin sistemin yarısını tetiklediği, kimsenin elini sürmeye cesaret edemediği “büyük çamur topu” (big ball of mud). Bunu hepimiz biliriz.

Diğer uçta ise daha sinsi bir tehlike vardır: aşırı decoupling. Bağımlılıktan kaçmak uğruna araya gereksiz katmanlar, soyutlamalar ve dolaylılıklar (indirection) koyarsınız. Tek bir akışı anlamak için yedi dosya ile üç arayüz arasında zıplamak gerekir. En meşhur örneği, gerçekte birbirine sıkı sıkıya bağlı bileşenleri ayrı servislere bölüp aralarına bir de ağ koyan dağıtık çamur topu (distributed big ball of mud) — yani yanlış kurgulanmış mikroservislerdir. Bağımlılık ortadan kalkmamıştır; yalnızca görünmez olmuş, üstüne bir de ağ gecikmesi ve dağıtık hata ayıklama derdi eklenmiştir.

Khononov bunu arızi karmaşıklık (accidental complexity) ile açıklar: problemin kendisinden değil, onu çözmek için yaptığımız kötü tasarım tercihlerinden doğan karmaşıklık. Hem aşırı coupling hem de aşırı decoupling arızi karmaşıklık üretir. Demek ki iyi tasarım bir uçta değil, dengededir. Geriye tek soru kalıyor: Bu dengeyi nasıl bulacağız? İşte Khononov’un asıl katkısı burada başlıyor.

Coupling’i Ölçmek: Khononov’un Üç Boyutu

Khononov’un en güçlü fikri, coupling’i tek bir “az/çok” ölçeğine sıkıştırmayı bırakıp onu üç ayrı boyutta ele almaktır. Bir bağlantının iyi mi kötü mü olduğunu bu üç boyut birlikte belirler:

1. Entegrasyon gücü — ne kadar bilgi paylaşılıyor?
2. Mesafe — bileşenler birbirine ne kadar uzak?
3. Oynaklık — ne sıklıkta değişiyor?

Bunları tek tek görelim.

1. Entegrasyon Gücü (Integration Strength)

Entegrasyon gücü, iki bileşenin birbiriyle ne tür ve ne kadar bilgi paylaştığını anlatır. Khononov bunu, en güçlüden (en çok bilgi paylaşan, en kırılgan) en zayıfa (en az bilgi paylaşan, en sağlam) doğru dört seviyeye ayırır:

Soldan sağa gidildikçe paylaşılan bilgi azalır, sağlamlık artar. En tepedeki içe nüfuz eden bağlaşım, bir bileşenin başka bir bileşenin kapağını açıp içine elini sokmasıdır — örneğin onun veritabanı tablosunu doğrudan okumak. En alttaki sözleşme bağlaşımı ise kapıdaki posta kutusundan konuşmaktır: arkada ne olduğunu bilmezsiniz, yalnızca sözleşmeye güvenirsiniz.

Aradaki farkı küçük bir örnekle görelim:

# KIRILGAN — içe nüfuz eden bağlaşım (intrusive)
# Sipariş modülü, Kullanıcı modülünün VERİTABANI TABLOSUNU doğrudan okuyor.
# "users" tablosunun yapısı değişirse sipariş modülü de kırılır.
def siparis_indirimi(kullanici_id):
    row = db.query("SELECT loyalty_tier FROM users WHERE id = ?", kullanici_id)
    return 0.20 if row.loyalty_tier == "GOLD" else 0.0

# SAĞLAM — sözleşme bağlaşımı (contract)
# Sipariş modülü, Kullanıcı modülünün YAYIMLADIĞI arayüzü çağırıyor.
# Kullanıcı modülü içeride ne yaparsa yapsın, sözleşme sabit kaldıkça sağlam kalır.
def siparis_indirimi(kullanici_id):
    seviye = kullanici_servisi.sadakat_seviyesi(kullanici_id)   # sözleşme
    return INDIRIM_TABLOSU[seviye]

İki kod da aynı işi yapıyor. Ama ilki, Kullanıcı modülünün veritabanı şemasına gizlice bağımlı; ikincisi yalnızca yayımlanmış bir sözleşmeye. Birincisinde users tablosuna eklenen masum bir değişiklik sipariş modülünü çökertebilir; ikincisinde Kullanıcı modülü içini baştan yazsa bile, sadakat_seviyesi sözleşmesi durduğu sürece sipariş modülü habersizdir.

Bu dört seviyelik fikir gökten zembille inmedi. Khononov burada, yazılım tasarımının köklerindeki iki klasik fikri — Larry Constantine’in 1970’lerdeki coupling türlerini ve Meilir Page‑Jones’un connascence kavramını — tek bir ölçekte birleştirir. (Birazdan bu soy ağacına döneceğiz.)

2. Mesafe (Distance)

İkinci boyut, coupling’in mekânsal ölçüsüdür: birbirine bağlı iki bileşen fiziksel ve örgütsel olarak ne kadar uzakta? Yakından uzağa doğru bir yelpaze düşünün:

aynı metot içi → aynı sınıf → aynı modül → aynı namespace → ayrı servis → ayrı sistem → ayrı ekip/şirket

Mesafe neden önemli? Çünkü zincirleme bir değişiklik gerektiğinde, o değişikliği hayata geçirmenin maliyeti mesafeyle birlikte artar. Aynı sınıftaki iki metodu birlikte değiştirmek dakikalar sürer. Ama iki bağımlı bileşen, ayrı ekiplerin sahip olduğu ayrı servislerdeyse, aynı değişiklik artık toplantılar, sürüm planları, API versiyonlama ve ekipler arası koordinasyon demektir. Khononov buna sahiplik mesafesi (ownership distance) der: bilgi ne kadar uzun yol kat ederse, onu değiştirmenin koordinasyon yükü o kadar büyür.

3. Oynaklık (Volatility)

Üçüncü boyut zamansaldır: bu bileşen ne sıklıkta değişiyor? Çünkü coupling’in bedeli ancak değişiklik olduğunda ödenir. Hiç değişmeyen bir bileşene sımsıkı bağlı olmak neredeyse bedavadır — bağ asla “tetiklenmez”. Ama sürekli evrilen, oynak bir bileşene aynı sıkılıkta bağlı olmak, her değişiklikte zincirleme acı demektir.

Bir kodun ne kadar oynak olduğunu kestirmek için Khononov, Alan Güdümlü Tasarım’ın (Domain-Driven Design) alt‑alan (subdomain) sınıflamasından yararlanır: işin kalbindeki, rekabet avantajı yaratan çekirdek (core) alanlar en sık değişir; destekleyici (supporting) ve hazır çözülebilen genel (generic) alanlar daha durağandır. Khononov’un çarpıcı sözüyle: oynaklık, modülerliği opsiyonel kılar. Kararlı koda sıkıca bağlanmak başlı başına bir sorun değildir; çünkü o bağ pratikte hiç sınanmaz.

Üçünü Birleştirmek: Denge Formülü

Asıl güzellik, bu üç boyut bir araya geldiğinde ortaya çıkar. Khononov tüm kitabın özünü tek bir mantıksal ifadeye sığdırır:

denge = (güç XOR mesafe) VEYA DEĞİL(oynaklık)

Korkutucu görünebilir ama söylediği şey son derece sezgiseldir. XOR (özel veya), “ikisinden yalnızca biri” demektir. Yani sağlıklı bir tasarımda güç ile mesafe birbirine zıt olmalıdır:

Köşeleri okuyalım:

• Güçlü + yakın = iyi. Çok bilgi paylaşan iki şey aynı yerde durursa, onları birlikte değiştirmek kolaydır. Sıkı bağ burada sorun değil.
• Zayıf + uzak = iyi. Az bilgi paylaşan şeyleri ayrı servislere/modüllere dağıtmak modülerliktir; her biri kendi başına yaşar.
• Güçlü + uzak = felaket. Çok şey paylaşan ama birbirinden uzak bileşenler küresel karmaşıklık üretir; bir bilgi parçası sistemin bir ucundan diğerine yolculuk eder. Buna bir de oynaklık eklenince ortaya o meşhur dağıtık çamur topu çıkar.
• Zayıf + yakın = israf. Birbiriyle alakasız şeyleri aynı sınıfa tıkıştırmak gereksiz yerel karmaşıklık yaratır.

Peki VEYA DEĞİL(oynaklık) kısmı? O da şunu söyler: bir bileşen kararlıysa (oynak değilse), yukarıdaki dengesizliğe katlanabilirsiniz — çünkü o bağ zaten hiç sınanmayacaktır. Modülerlik bedava değildir; ödediğiniz “modülerlik vergisini” yalnızca sık değişen yerlerde ödemeye değer.

Bu modeli pratiğe dökmek üç basit sezgisel kurala iner:

• Çok bilgi paylaşıyorlarsa, yakın tut. (Güçlü bağı kısa mesafeyle dengele.)
• Uzaktalarsa, paylaşılan bilgiyi azalt. (Mikroservis sınırını ancak gerçek bir sözleşmeyle geç.)
• Kararlıysa, modülerlik zahmetine girme. (Oynak olmayan yere mühendislik gücü harcama.)

Dikkat edin: bu, “küçük ve dağıtık her zaman daha basittir” diyen popüler mikroservis söylemine doğrudan bir itirazdır. Bileşenleri küçültüp uzaklaştırmak, aralarındaki bilgi paylaşımı (güç) hâlâ yüksekse, sistemi basitleştirmez; tam tersine küresel karmaşıklığı artırır.

Kısa Bir Tarih: Constantine’den Connascence’a

Coupling, yazılım mühendisliğinin en eski kavramlarından biridir; Khononov’un modeli de bu birikimin üzerine kuruludur.

• Larry Constantine (1970’ler). Yapısal Tasarım (Structured Design) çalışmasında coupling’i ilk kez sistematik biçimde sınıflandırdı. En güçlüden (en kötü) en zayıfa (en iyi) doğru türleri şöyleydi: içerik (content), ortak (common), dış (external), kontrol (control), damga (stamp) ve veri (data) bağlaşımı. Bu sınıflama on yıllar boyunca — ve birazdan göreceğimiz gibi DO‑178C dâhil — sahada referans oldu.
• Meilir Page‑Jones (1990’lar). Connascence kavramıyla coupling’i ölçülebilir hâle getirdi. İki bileşen, biri değişince diğeri de değişmek zorundaysa “connascent”tir. Page‑Jones bağı üç eksende değerlendirdi: güç (değiştirmek ne kadar zor), yerellik (bileşenler ne kadar yakın) ve derece (kaç bileşeni etkiliyor) — Khononov’un güç ve mesafe boyutlarının doğrudan atası.
• David Parnas. Bilgi gizleme (information hiding) ilkesiyle modüllerin birbirinden iç kararları değil yalnızca sözleşmeyi bilmesi gerektiğini savundu — yani “sözleşme bağlaşımı”nın felsefi temelini attı.

Khononov’un katkısı, bu dağınık mirası tek bir tutarlı çerçevede — entegrasyon gücü, mesafe, oynaklık — toplamasıdır. Ve buradan güvenlik‑kritik dünyaya zarif bir köprü uzanır: DO‑178C’nin coupling diline doğrudan Constantine’in terimleriyle, veri bağlaşımı ve kontrol bağlaşımı ile gireriz.

Güvenlik‑Kritik Dünyada Coupling: DO‑178C

Şimdiye kadar coupling’i bir tasarım tercihi olarak konuştuk: iyi mühendis dengeyi gözetir, kötüsü gözetmez. Peki ya yanlış dengenin bedeli bir insanın canıysa?

Uçak yazılımının geliştirildiği dünyada coupling artık bir üslup meselesi değildir; kanıtlanması zorunlu bir sertifikasyon şartıdır. Sivil havacılıkta uçuş yazılımı, RTCA ve EUROCAE’nin ortaklaşa hazırladığı DO‑178C standardına (Avrupa’daki adıyla ED‑12C) göre geliştirilir ve denetlenir. Bu, daha önce MISRA C yazısında değindiğimiz türden emniyet‑kritik bir disiplindir — ama bir adım öteye geçip doğrudan bileşenler arasındaki bağları hedef alır.

DO‑178C, Constantine’den miras aldığı iki terimi resmî olarak tanımlar:

Veri bağlaşımı (data coupling): Bir bileşenin, münhasıran kendi kontrolünde olmayan veriye bağımlılığı.

Kontrol bağlaşımı (control coupling): Bir bileşenin, başka bir bileşenin yürütülmesini (ne zaman, hangi koşulda çalışacağını) etkileme biçimi veya derecesi.

Standart, bu bağların yalnızca var olduğunu kabul etmekle yetinmez; doğrulama sürecinin bir objektifi olarak (DO‑178C’nin meşhur Tablo A‑7‘sinde) şunu talep eder: Gereksinim temelli testlerin, bileşenler arasındaki veri ve kontrol bağımlılıklarını gerçekten çalıştırdığını kanıtlayın. Burada DO‑178C, selefi DO‑178B’den ayrılır: eskiden bağları yalnızca tanımlamak yeterken, DO‑178C onların testlerle uygulandığını göstermeyi ister.

Bu gereklilik her yazılım için aynı değildir. DO‑178C, olası bir arızanın yol açacağı sonucun ağırlığına göre beş tasarım güvence seviyesi (Design Assurance Level, DAL) tanımlar:

En kritik A ve B seviyelerinde, coupling analizinin geliştiriciden bağımsız bir gözle doğrulanması şarttır. (Daha önce Fonksiyonel Olmayan Yazılım Gereksinimleri yazısında bir aviyonik projenin DAL A gereksinimlerine kısaca değinmiştik.)

Peki bu analiz tam olarak ne yapar? Burada güzel bir tamamlayıcılık vardır. Klasik yapısal kapsama ölçütleri — deyim (statement), karar (decision) ve modern uçakların A seviyesinde istediği MC/DC (Modified Condition/Decision Coverage) — bir bileşenin içindeki tüm kod yollarının test edildiğini gösterir. Ama bir bileşen tek başına kusursuz olabilir ve yine de başka bir bileşenle birleştiğinde patlayabilir. Veri ve kontrol bağlaşım analizi tam bu boşluğu kapatır: bileşenlerin arasındaki etkileşimleri hedefler — yani yazılım sistem mühendisliğinde V modelinin sağ kolundaki entegrasyon ve doğrulama adımlarının ta kendisidir.

Yapısal kapsama kutuların içini test eder; veri ve kontrol bağlaşım analizi ise kutular arasındaki okları test eder. Pratikte ölçüm iki ayrı şekilde yapılır: kontrol bağlaşımı için çağrı‑çiftleri (call‑pair) ve dönüşlerin kapsanması — yani bileşenler arası her çağrının en az bir testte gerçekten yürütülmüş olması; veri bağlaşımı için ise “yaz‑oku” (set‑use / define‑use) çiftlerinin kapsanması — yani bir bileşenin yazdığı her verinin, onu okuyan bileşen tarafından bir testte gerçekten kullanılmış olması.

Bütün bu titizliğin sebebi tek bir kavramdır: birleşim tehlikesi (composition hazard). Havacılık tarihi, tek tek doğru çalışan bileşenlerin birleştiğinde — beklenmedik bir veri paylaşımı, dokümante edilmemiş bir yan etki ya da yanlış sırada tetiklenen bir çağrı yüzünden — başarısız olabildiğini acı tecrübelerle öğrendi. Hatalar çoğu zaman bileşenlerin içinde değil, aralarındaki arayüzlerde yaşar. DO‑178C, bu arayüzlerin görünür kılınmasını ve test edilmesini zorunlu tutarak riski kökünden hedefler.

İki Dünya, Tek Ders

İlk bakışta bir tasarım kitabıyla bir havacılık standardı uzak akrabalar gibi görünür. Oysa ikisi aynı gerçeğin iki yüzüdür.

Khononov bize bir akıl yürütme çerçevesi verir: coupling’i üç boyutta düşün, dengeyi bilinçli kur, nereye ne kadar bağ koyacağına karar ver. DO‑178C ise bir doğrulama disiplini dayatır: bağları belgele, görünür kıl ve testlerle çalıştığını kanıtla. Biri “nasıl tasarlamalı”, diğeri “nasıl ispatlamalı” sorusunu yanıtlar.

Ama ikisinin de altında yatan içgörü aynıdır: risk, bileşenlerin içinde değil, aralarındaki bağlarda ve paylaşılan bilgide yoğunlaşır. İster Khononov’un entegrasyon gücü merdiveni olsun, ister DO‑178C’nin veri/kontrol bağlaşımı ayrımı — ikisi de aynı şeyi söyler: coupling’i örtük bırakma; onu açık, bilinçli ve mümkünse test edilebilir kıl.

Aradaki tek fark bahsin büyüklüğüdür. Bir CRUD uygulamasında yanlış kurulmuş bir bağ, en kötü ihtimalle bir gece yarısı acil yamasıdır. Bir uçuş kontrol bilgisayarında aynı hata, can demektir. Bu yüzden havacılık, iyi mühendisin her yerde gönüllü yapması gerekeni zorunlu kılar. Disiplin aynıdır; yalnızca hata payı farklıdır.

Khononov’un üç boyutuyla DO‑178C’nin iki bağlaşım türü arasında hoş bir yankı da vardır: kontrol bağlaşımı, “bir bileşen diğerinin ne zaman çalışacağını etkiliyor” demektir; veri bağlaşımı ise “bir bileşen diğerinin neyi gördüğünü etkiliyor”. Paylaşılan kontrol akışı ve paylaşılan veri — coupling dediğimiz şeyin en temel iki biçimi, ister bir mikroservis mimarisinde ister bir uçuş bilgisayarında olsun.

Sonuç

Coupling’i yıllarca yanlış sevdik: ondan kaçmaya, onu yok etmeye çalıştık. Oysa coupling, sistemi sistem yapan şeydir; mesele onu yok etmek değil, dengelemektir.

Khononov’un bıraktığı pratik miras birkaç cümleye sığar:

• Coupling kaçınılmaz ve gereklidir; hedef sıfır bağ değil, doğru bağdır.
• Her bağı üç boyutta tart: güç (ne kadar bilgi paylaşılıyor), mesafe (ne kadar uzak), oynaklık (ne sıklıkta değişiyor).
• Dengeyi kur: güçlü bağları yakın tut, uzaktakileri sözleşmeyle gevşet, kararlı yerlere modülerlik vergisi ödeme.
• Ve en önemlisi: coupling’i örtük bırakma. Onu görünür, bilinçli ve — bahis büyükse — test edilebilir kıl.

Havacılık bu son ilkeyi bir standarda yazıp imza zorunluluğu getirdi. Geri kalanımız için ise bu, henüz yazılmamış ama her iyi tasarımın içinde yaşayan bir sözleşmedir. İster bir mobil uygulama yazın, ister bir uçuş kontrol sistemi: er ya da geç, sistemin kaderini bileşenlerin tek tek kalitesi değil, aralarındaki bağların dengesi belirleyecektir.

Kaynaklar:

• Vlad Khononov — Balancing Coupling in Software Design (Addison‑Wesley, 2024).
• coupling.dev — kitabın kavramlarını derleyen tamamlayıcı kaynak.
• Meilir Page‑Jones — What Every Programmer Should Know About Object-Oriented Design (1995). Ayrıca Connascence (Wikipedia).
• Edward Yourdon, Larry Constantine — Structured Design (Prentice Hall, 1979).
• RTCA/EUROCAE — DO‑178C / ED‑12C, Software Considerations in Airborne Systems and Equipment Certification (2011). Genel bakış: DO‑178C (Wikipedia).
• Rapita Systems — Data Coupling & Control Coupling for DO‑178C.
• LDRA — Data Coupling and Control Coupling (DCCC) analysis.
• FAA — AC 20‑115D, Airborne Software Development Assurance.

Kalman filtresi, 1960’ta Rudolf Kálmán’ın ortaya koyduğundan beri uzay araçlarından telefonunuza, robotlardan finansal modellere kadar her yerde çalışan, gürültülü ölçümler ile kusurlu bir hareket modelini optimal şekilde harmanlayan özyinelemeli bir kestirimcidir. Bu yazıda filtreyi sıfırdan kuracağız: önce Gauss dağılımlarını birleştirme sezgisiyle, sonra doğrusal durum-uzay modeliyle, ardından doğrusal-olmayan dünyaya geçişi sağlayan Genişletilmiş Kalman Filtresi (EKF) ile. Yol boyunca hem NumPy ile tam çalışan Python kodları hem de tarayıcınızda canlı oynayabileceğiniz iki etkileşimli simülatör olacak.

Problem: Gizli Durumu Gürültünün Altından Çıkarmak

Bir sistemin gerçekten bilmek istediğimiz büyüklüklerine durum (state) diyelim ve x ile gösterelim — bir cismin konumu ve hızı, bir uydunun yörünge parametreleri, bir bataryanın şarj seviyesi. Sorun şu ki durumu doğrudan göremeyiz. Elimizde sadece iki kusurlu bilgi kaynağı vardır:

1. Bir hareket modeli. Fizik bize “bir sonraki adımda durum kabaca şu olur” der. Ama model idealdir; rüzgâr, sürtünme, modellenmemiş ivmeler yüzünden gerçekten sapar ve bu sapma adım adım birikir.
2. Gürültülü ölçümler. Sensör bize durumla ilgili bir şey söyler (z), ama her okumanın üzerinde rastgele gürültü vardır. Üstelik sensör çoğu zaman durumun tamamını değil, bir fonksiyonunu ölçer (örneğin yalnızca konumu, hızı değil).

Kalman filtresinin yaptığı tam olarak şudur: her adımda modelin tahminiyle yeni ölçümü, her birinin ne kadar güvenilir olduğunu hesaba katarak birleştirir. Kritik nokta, filtrenin yalnızca en iyi tahmini (x̂) değil, o tahmine ne kadar güvendiğini de (kovaryans matrisi P) taşımasıdır. Tüm zekâ bu ikinci büyüklükte saklıdır.

Bir de güzel özelliği var: filtre özyinelemelidir (recursive). Tüm geçmiş ölçümleri saklamaz; her an yalnızca güncel x̂ ve P değerlerini tutar, yeni ölçüm gelince bunları günceller. Bu yüzden gömülü bir mikrodenetleyicide, sabit hafızayla, gerçek zamanlı çalışabilir.

Gauss Dağılımı ve İki Bilgiyi Birleştirmek

Kalman filtresinin kalbinde tek bir varsayım yatar: belirsizliği Gauss (normal) dağılımıyla temsil ederiz. Bir Gauss iki sayıyla tanımlanır: ortalama μ (“en iyi tahminim”) ve varyans σ² (“ne kadar eminim” — küçük varyans = sivri, emin; büyük varyans = yayvan, belirsiz).

Şimdi sihirli kısım. Elimizde aynı büyüklük hakkında iki bağımsız Gauss bilgi olsun: biri modelin tahmini, diğeri ölçüm. Bu ikisini çarptığımızda ortaya çıkan şey yine bir Gauss’tur — ve bu yeni Gauss, her ikisinden de daha dardır, ortalaması da ikisinin “kesinliklerine göre ağırlıklı” ortasındadır:

$$ \mu = \mu_1 + \frac{\sigma_1^2}{\sigma_1^2 + \sigma_2^2}\,(\mu_2 - \mu_1), \qquad \sigma^2 = \sigma_1^2 - \frac{\sigma_1^4}{\sigma_1^2 + \sigma_2^2} $$

İki şeye dikkat edin. Birincisi, ortalamanın kaydığı miktar σ₁²/(σ₁²+σ₂²) ağırlığıyla belirlenir — bu ifade tam olarak skaler Kalman kazancıdır (K). İkincisi, sonuçtaki varyans her iki girdiden de küçüktür: iki bağımsız bilgiyi birleştirmek belirsizliği azaltır, asla artırmaz. Güncelleme denklemini şöyle de yazabiliriz:

$$ \mu = \mu_1 + K\,(\mu_2 - \mu_1), \qquad K = \frac{\sigma_1^2}{\sigma_1^2 + \sigma_2^2} $$

Bu, birazdan göreceğimiz tam Kalman güncellemesinin (x̂ = x̂⁻ + K(z − x̂⁻)) bire bir skaler hâlidir. Geriye kalan tek iş, bunu tek boyuttan matrislere taşımak.

Doğrusal Durum-Uzay Modeli

Çok boyutlu durumda μ yerine durum vektörü x, σ² yerine kovaryans matrisi P geçer. Sistemi şu iki denklemle modelleriz:

$$ x_k = F\,x_{k-1} + B\,u_{k-1} + w_{k-1}, \qquad w_{k-1} \sim \mathcal{N}(0, Q) $$

$$ z_k = H\,x_k + v_k, \qquad v_k \sim \mathcal{N}(0, R) $$

Terimleri tek tek tanıyalım:

• F — durum geçiş matrisi: bir adımda durumun fizikçe nasıl evrildiği.
• B, u — kontrol matrisi ve kontrol girdisi: dışarıdan uyguladığımız, bildiğimiz etkiler (örneğin gaz/fren). Kontrol yoksa bu terim düşer.
• H — ölçüm matrisi: durumun hangi bileşeninin, nasıl ölçüldüğü.
• Q — süreç gürültüsü kovaryansı: modele ne kadar güvenmediğimiz. Büyük Q = “modelim kaba, gerçek bundan sapabilir”.
• R — ölçüm gürültüsü kovaryansı: sensöre ne kadar güvenmediğimiz. Genelde sensörün datasheet’inden ya da kalibrasyondan bilinir.
• P — kestirim kovaryansı: filtrenin o anki tahminine olan güveni. Filtre bunu kendisi üretir ve günceller.

Somut bir örnek kuralım: bir doğru üzerinde, yaklaşık sabit hızla giden bir cisim. Durumu konum ve hızdan oluşsun, Δt adım süresi olsun. Yalnızca konumu ölçebildiğimizi varsayalım. O zaman:

$$ x_k = \begin{bmatrix} p_k \\ \dot{p}_k \end{bmatrix}, \quad F = \begin{bmatrix} 1 & \Delta t \\ 0 & 1 \end{bmatrix}, \quad H = \begin{bmatrix} 1 & 0 \end{bmatrix} $$

F‘in anlamı net: yeni konum = eski konum + hız·Δt; yeni hız = eski hız (sabit hız varsayımı). H = [1, 0] ise “ölçüm sadece konumu görür, hızı görmez” der. Hızı hiç ölçmediğimiz hâlde filtre onu konum ölçümlerinin zaman içindeki değişiminden çıkarsayacak — Kalman filtresinin en şık tarafı budur.

Süreç gürültüsünü, modellenmemiş bir ivmeden gelir gibi düşünürüz (beyaz-gürültü ivme modeli):

$$ Q = q\begin{bmatrix} \tfrac{\Delta t^4}{4} & \tfrac{\Delta t^3}{2} \[4pt] \tfrac{\Delta t^3}{2} & \Delta t^2 \end{bmatrix}, \qquad R = \begin{bmatrix} \sigma_{\text{ölç}}^2 \end{bmatrix} $$

Buradaki q skaler bir “süreç gürültüsü yoğunluğu”dur ve birazdan en kritik ayar düğmemiz olacak.

Tahmin Adımı (Predict)

Filtre iki adımlı bir danstır. İlk adım tahmin: mevcut durumu ve belirsizliği, modeli kullanarak bir adım ileri taşırız.

$$ \hat{x}_k^- = F\,\hat{x}_{k-1} + B\,u_{k-1} $$

$$ P_k^- = F\,P_{k-1}\,F^{\mathsf{T}} + Q $$

Üstteki − işareti “henüz ölçümü görmeden, sadece modele dayalı a-priori tahmin” demektir. Birinci denklem sezgisel: durumu fizik kurallarıyla ileri sür. İkinci denklem daha derin: belirsizliği de ileri taşırız, ama F P Fᵀ ile dönüştürüp üzerine + Q ekleriz. Bu + Q çok önemli — tahmin adımı belirsizliği daima büyütür. Mantıklı: modele güvenerek geleceğe baktıkça emin olduğumuz şey azalır. Konum-hız örneğinde belirsizlik elipsi, hız yönünde uzar; çünkü hızdaki ufak bir hata, zamanla konumda büyük bir belirsizliğe dönüşür.

Güncelleme Adımı (Update)

İkinci adım güncelleme: yeni ölçüm gelince tahmini düzeltiriz. Burası Gauss çarpımının matris hâlidir.

$$ y_k = z_k - H\,\hat{x}_k^- $$

$$ S_k = H\,P_k^-\,H^{\mathsf{T}} + R $$

$$ K_k = P_k^-\,H^{\mathsf{T}}\,S_k^{-1} $$

$$ \hat{x}_k = \hat{x}_k^- + K_k\,y_k $$

$$ P_k = (I - K_k H)\,P_k^- $$

Sırayla:

• y — yenilik (innovation): ölçüm bizi ne kadar şaşırttı? Beklediğimiz ölçüm (H x̂⁻) ile gerçek ölçüm (z) arasındaki fark. Yenilik küçükse model isabetli, büyükse ölçümde yeni bilgi var.
• S — yeniliğin kovaryansı: bu şaşkınlığın ne kadarı beklenen (gürültü + model belirsizliği).
• K — Kalman kazancı: filtrenin kalbi. Yeniliğin ne kadarına güveneceğimizi belirleyen, hassasiyete göre ağırlıklı harman oranı. K → 1 ise “sensöre güven, ölçümü kabul et”; K → 0 ise “modele güven, ölçümü neredeyse yok say”.
• Durum güncellemesi: a-priori tahmine, yeniliğin K katını ekle.
• Kovaryans güncellemesi: tahmin belirsizliği azalır (yeni bilgi geldi).

Pratikte son denklem yerine sayısal olarak daha kararlı olan Joseph formu tercih edilir; her durumda simetrik ve pozitif yarı-tanımlı bir P üretir:

$$ P_k = (I - K_k H)\,P_k^-\,(I - K_k H)^{\mathsf{T}} + K_k R\,K_k^{\mathsf{T}} $$

Buna birazdan “Mühendislik Notları”nda döneceğiz.

Tam Algoritma: İki Adımın Dansı

Tüm filtre, bu iki adımın sonsuza dek tekrarından ibarettir:

Başlangıçta x̂₀ için bir tahmin (bilmiyorsak sıfır) ve P₀ için büyük bir değer veririz — “başta hiçbir şey bilmiyorum” demenin yolu budur. İlk birkaç ölçümde filtre hızla kendine gelir; kötü bir başlangıcı çabucak unutur. Bu, Kalman filtresinin pratikteki en sevimli huylarından biridir.

Elde Çalışan 1B Örnek

Soyut kalmasın; ilk iterasyonu elle yapalım. Konum-hız modelimizde Δt = 1, σ_ölç = 2 (yani R = 4), q = 0.01 olsun. Başlangıç: x̂₀ = [0, 0], P₀ = 500·I (çok belirsiz).

Tahmin: x̂⁻ = F·[0,0]ᵀ = [0, 0]. Kovaryans için P⁻ = F P₀ Fᵀ + Q. Hesabı yapınca P⁻[0,0] ≈ 1000 çıkar (belirsizlik tahminle daha da büyüdü).

İlk ölçüm geldi: diyelim z₁ = 2.64. O zaman:

• Yenilik: y = z₁ − x̂⁻[0] = 2.64 − 0 = 2.64
• Yenilik kovaryansı: S = P⁻[0,0] + R = 1000 + 4 = 1004
• Kalman kazancı: K = [P⁻[0,0], P⁻[0,1]]ᵀ / S = [0.996, 0.498]ᵀ
• Durum: x̂ = x̂⁻ + K·y = [0.996·2.64, 0.498·2.64] = [2.63, 1.31]
• Kovaryans: P[0,0] = (1 − 0.996)·1000 ≈ 4.0

İlk adımda K ≈ 1 çıkması tesadüf değil: P₀ kocaman olduğu için filtre “modelime hiç güvenmiyorum, ölçüm neredeyse aynen doğrudur” diyor ve ilk ölçümü olduğu gibi kabul ediyor. Konum varyansı 1000’den 4’e düştü; bir ölçümle ne kadar çok şey öğrendiğimize bakın. Adımlar ilerledikçe K küçülerek kararlı bir değere oturacak — filtre artık modeline de güvenmeye başlayacak.

NumPy ile Sıfırdan Lineer KF

Teori güzel ama her zaman dediğim gibi, gözünüzle görmediğiniz hiçbir şeye güvenmeyin. Aşağıdaki kod modeli kurar, gerçek bir yörünge ile gürültülü ölçümler üretir ve filtreyi çalıştırır. Toplam 20 satırlık bir döngü.

import numpy as np
import matplotlib.pyplot as plt

dt = 1.0
F = np.array([[1, dt],
              [0, 1.0]])          # sabit-hız geçiş matrisi
H = np.array([[1.0, 0.0]])        # yalnızca konumu ölçüyoruz
q = 0.01                          # süreç gürültüsü yoğunluğu
Q = q * np.array([[dt**4/4, dt**3/2],
                  [dt**3/2, dt**2]])
R = np.array([[4.0]])             # ölçüm gürültüsü (σ=2 → R=σ²=4)

# 1) Gerçek yörünge + gürültülü ölçümler üret
rng = np.random.default_rng(1)
N = 60
x = np.array([0.0, 1.0])          # [konum, hız]
truth, meas = [], []
for _ in range(N):
    x = F @ x + np.array([0.0, rng.normal(0, np.sqrt(q))])
    truth.append(x.copy())
    meas.append((H @ x)[0] + rng.normal(0, 2.0))
truth, meas = np.array(truth), np.array(meas)

# 2) Kalman filtresini çalıştır
xhat = np.array([0.0, 0.0])
P = np.eye(2) * 500.0             # başlangıçta çok belirsiziz
I = np.eye(2)
est, var_p, gain = [], [], []
for k in range(N):
    # --- TAHMİN ---
    xhat = F @ xhat
    P = F @ P @ F.T + Q
    # --- GÜNCELLEME ---
    y = meas[k] - H @ xhat                  # yenilik
    S = H @ P @ H.T + R
    K = P @ H.T @ np.linalg.inv(S)          # Kalman kazancı
    xhat = xhat + (K @ y)
    P = (I - K @ H) @ P
    est.append(xhat.copy()); var_p.append(P[0, 0]); gain.append(K[0, 0])
est = np.array(est)

rmse_kf  = np.sqrt(np.mean((est[:, 0] - truth[:, 0])**2))
rmse_raw = np.sqrt(np.mean((meas - truth[:, 0])**2))
print(f"KF RMSE={rmse_kf:.2f}   ham ölçüm RMSE={rmse_raw:.2f}")
# -> KF RMSE=0.73   ham ölçüm RMSE=1.64

Sonuç çarpıcı: ham ölçümlerin gerçek konuma göre RMSE’si 1.64 iken, Kalman kestiriminin RMSE’si 0.73 — kabaca 2.25 kat daha iyi. Hem de tek bir ekstra sensör eklemeden, yalnızca bir hareket modelini akıllıca kullanarak.

Bir de filtrenin “kendine güveni” olan P ve kazanç K‘nin zaman içindeki davranışına bakalım:

R ve q değerleriyle oynayıp kodu yeniden çalıştırın: R‘yi büyütürseniz filtre ölçümlere daha az güvenir, kestirim pürüzsüzleşir ama yavaşlar. q‘yu büyütürseniz modele daha az güvenir, kestirim ölçümlerin peşinden koşar. Bu dengeyi en iyi, doğrudan elinizle hissederek anlarsınız — buyrun.

Etkileşimli Simülatör: Lineer Kalman Filtresi

Aşağıdaki simülatör gerçek zamanlı çalışır. Üç düğme var: ölçüm gürültüsü σ, filtrenin varsaydığı süreç gürültüsü q ve cismin gerçek hızı. Gerçek dünya sabit (ama hafif manevra yapan) bir hızla ilerler; siz filtreyi nasıl ayarladığınıza göre sonucu izleyin.

Birkaç deney önerisi: q‘yu en küçük değere çekin ve birkaç saniye izleyin — güven bandı kâğıt inceliğine düşerken gerçek (yeşil) çizginin bandın dışına kaçtığını göreceksiniz. Filtre kendine olduğundan fazla güveniyor; bu, gerçek sistemlerde ıraksamanın (divergence) klasik reçetesidir. Sonra q‘yu sonuna kadar açın: bu sefer kestirim her gürültülü noktanın peşine takılır, filtrenin tüm pürüzsüzleştirme faydası kaybolur. İyi ayar ikisinin arasındadır.

Doğrusal Olmama Problemi: Sensör Düz Konuşmaz

Şimdiye kadar her şey doğrusaldı: x = F x ve z = H x. Gerçek dünyaysa nadiren bu kadar kibardır. Çoğu sensör, durumun doğrusal-olmayan bir fonksiyonunu ölçer.

Klasik örnek: orijine yerleştirilmiş bir sensör, hareketli bir cisme olan uzaklığı (menzil, r) ve açıyı (θ) ölçsün. Cismin konumu Kartezyen (p_x, p_y) ise, ölçüm şudur:

$$ h(x) = \begin{bmatrix} r \\ \theta \end{bmatrix} = \begin{bmatrix} \sqrt{p_x^2 + p_y^2} \[4pt] \operatorname{atan2}(p_y, p_x) \end{bmatrix} $$

İçindeki karekök ve atan2 yüzünden bu fonksiyon durumda doğrusal değildir. İşte sorun: Kalman filtresinin tüm matematiği “Gauss içeri girer, Gauss dışarı çıkar” varsayımına dayanır. Ama bir Gauss dağılımını doğrusal-olmayan bir fonksiyondan geçirirseniz, çıkan şey artık Gauss değildir — çarpık, eğri büğrü bir dağılımdır. H matrisi diye bir şey de yoktur; h(x) bir matrisle yazılamaz. Klasik KF burada çalışmaz.

(Aynı sorun ölçümde değil süreçte de olabilir: x = f(x, u) doğrusal-olmayan bir hareket modeli olabilir — dönen bir cisim, sürtünmeli bir sarkaç. Çözüm her iki durumda da aynıdır.)

EKF’in Fikri: Lineerizasyon ve Jacobian’lar

Genişletilmiş Kalman Filtresi’nin (EKF) çözümü zarif ve pragmatiktir: doğrusal-olmayan fonksiyonu, içinde bulunduğumuz çalışma noktasının yakınında bir doğruyla (teğetle) değiştir. Yani her adımda, güncel tahmin x̂ etrafında birinci-dereceden Taylor açılımı yaparız. Bu teğetin eğimi, fonksiyonun Jacobian matrisidir:

$$ F_k = \left.\frac{\partial f}{\partial x}\right|_{\hat{x}_{k-1},\,u_{k-1}}, \qquad H_k = \left.\frac{\partial h}{\partial x}\right|_{\hat{x}_k^-} $$

Fikir basit ama güçlü: kovaryansı taşırken ve Kalman kazancını hesaplarken, sabit F ve H matrislerinin yerine bu her adımda yeniden hesaplanan Jacobian’ları kullanırız. Durumun kendisini taşırken ise gerçek doğrusal-olmayan f ve h fonksiyonlarını kullanmaya devam ederiz (teğeti değil, eğrinin kendisini).

Bu yaklaşımın bedeli de aynı resimde: EKF artık optimal değildir ve doğrusallık varsayımı yalnızca çalışma noktasının yakınında geçerlidir. Tahmin gerçekten uzaksa veya fonksiyon çok bükülmüşse, teğet kötü bir yaklaşım olur ve filtre ıraksayabilir. Yine de pratikte EKF, on yıllardır navigasyon ve takip sistemlerinin bel kemiğidir; çünkü çoğu sistem, adım adım bakıldığında “yeterince doğrusal”dır.

Range-Bearing Jacobian’ını Elle Türetmek

EKF’i uygulamak demek, Jacobian’ı doğru türetmek demektir; gerisi neredeyse klasik KF’tir. Menzil-açı ölçümümüz için H_k = ∂h/∂x türevini eleman eleman alalım. Durumumuz [p_x, p_y, v_x, v_y] ve r = √(p_x² + p_y²).

Menzil satırı için:

• ∂r/∂p_x = p_x / r, ∂r/∂p_y = p_y / r

Açı satırı için (θ = atan2(p_y, p_x) türevinin standart sonucu):

• ∂θ/∂p_x = −p_y / r², ∂θ/∂p_y = p_x / r²

Hız bileşenlerine göre türevler sıfırdır, çünkü ölçüm hıza doğrudan bağlı değil. Hepsini bir matriste toplayınca:

$$ H_k = \frac{\partial h}{\partial x} = \begin{bmatrix} \dfrac{p_x}{r} & \dfrac{p_y}{r} & 0 & 0 \[8pt] -\dfrac{p_y}{r^2} & \dfrac{p_x}{r^2} & 0 & 0 \end{bmatrix} $$

El ile türetilen bir Jacobian, hata yapmaya en açık yerdir; bu yüzden onu daima sayısal türevle doğrulayın. (h(x+ε) − h(x−ε)) / 2ε merkezî farkı, analitik Jacobian’a çok yakın çıkmalıdır:

import numpy as np
def h(x): return np.array([np.hypot(x[0], x[1]), np.arctan2(x[1], x[0])])
def H_jac(x):
    px, py = x[0], x[1]; r2 = px*px + py*py; r = np.sqrt(r2)
    return np.array([[ px/r,   py/r,  0, 0],
                     [-py/r2,  px/r2, 0, 0]])

x = np.array([3.0, 4.0, 1.0, -2.0])          # r = 5
eps = 1e-6; J_num = np.zeros((2, 4))
for i in range(4):
    e = np.zeros(4); e[i] = eps
    J_num[:, i] = (h(x+e) - h(x-e)) / (2*eps)

print(np.max(np.abs(H_jac(x) - J_num)))      # -> ~7e-9  (analitik = sayısal)
print(H_jac(x))   # [[ 0.6 ,  0.8 , 0, 0], [-0.16,  0.12, 0, 0]]

Maksimum fark ~10⁻⁹ mertebesinde; Jacobian’ımız doğru. (p_x=3, p_y=4 için r=5; 3/5=0.6, 4/5=0.8, −4/25=−0.16, 3/25=0.12 — elle de doğrulayabilirsiniz.)

EKF Algoritması

EKF döngüsü, klasik KF’ten yalnızca iki yerde ayrılır. Önce ölçüm modelimizin sabit F matrisini (bu örnekte hareket doğrusal: 2B sabit hız) ve Q‘yu kuralım:

$$ F = \begin{bmatrix} 1&0&\Delta t&0 \\ 0&1&0&\Delta t \\ 0&0&1&0 \\ 0&0&0&1 \end{bmatrix}, \qquad Q = G\,\sigma_a^2\,G^{\mathsf{T}},\quad G = \begin{bmatrix} \tfrac{\Delta t^2}{2}&0 \[2pt] 0&\tfrac{\Delta t^2}{2} \[2pt] \Delta t&0 \[2pt] 0&\Delta t \end{bmatrix} $$

EKF adımları:

$$ \hat{x}_k^- = f(\hat{x}_{k-1}, u_{k-1}), \qquad P_k^- = F_k\,P_{k-1}\,F_k^{\mathsf{T}} + Q $$

$$ y_k = z_k - h(\hat{x}_k^-), \qquad S_k = H_k\,P_k^-\,H_k^{\mathsf{T}} + R $$

$$ K_k = P_k^-\,H_k^{\mathsf{T}}\,S_k^{-1}, \quad \hat{x}_k = \hat{x}_k^- + K_k\,y_k, \quad P_k = (I - K_k H_k)\,P_k^- $$

İki kritik fark:

1. Ortalama gerçek fonksiyonla, kovaryans Jacobian’la taşınır. Yeniliği z − H x̂⁻ değil, z − h(x̂⁻) ile hesaplarız; ama S, K, P denklemlerinde H yerine H_k Jacobian’ı kullanırız.
2. Açı farkını sarmak (wrapping). atan2 değerleri [−π, π] aralığındadır. 179° beklerken −179° ölçerseniz, ham fark −358° çıkar; oysa gerçek fark sadece +2°‘dir. Bu yüzden açı yeniliğini daima [−π, π] aralığına sararız:

$$ y_\theta \leftarrow \big((y_\theta + \pi)\bmod 2\pi\big) - \pi $$

Bu küçük detayı atlamak, takip sistemlerinin açı sıçramalarında neden aniden çıldırdığının bir numaralı sebebidir. Aşağıdaki diyagram iki filtrenin yapısal farkını özetliyor:

NumPy ile Sıfırdan EKF: Range-Bearing Takibi

Hepsini bir araya getirelim. Aşağıdaki kod, sabit hızla giden (ama yavaşça dönen) bir hedefi, orijindeki menzil-açı sensörüyle takip eder. Klasik KF kodumuzdan tek farkı, h fonksiyonu, H_jac Jacobian’ı ve açı sarması.

import numpy as np

dt = 1.0
F = np.array([[1,0,dt,0],[0,1,0,dt],[0,0,1,0],[0,0,0,1.0]])   # 2B sabit hız
G = np.array([[dt**2/2,0],[0,dt**2/2],[dt,0],[0,dt]])
Q = G @ (0.02*np.eye(2)) @ G.T
sr, sth = 0.5, np.deg2rad(1.0)               # menzil (m) ve açı (rad) gürültüsü
R = np.diag([sr**2, sth**2])

def h(x):                                     # doğrusal-olmayan ölçüm
    return np.array([np.hypot(x[0], x[1]), np.arctan2(x[1], x[0])])

def H_jac(x):                                 # ölçüm Jacobian'ı (2x4)
    px, py = x[0], x[1]
    r2 = px*px + py*py; r = np.sqrt(r2)
    return np.array([[ px/r,   py/r,  0, 0],
                     [-py/r2,  px/r2, 0, 0]])

def wrap(a):                                  # açıyı [-π, π] aralığına sar
    return (a + np.pi) % (2*np.pi) - np.pi

# Gerçek hedef: sabit hız + yavaş dönüş; sensör orijinde
rng = np.random.default_rng(4)
N = 55
xt = np.array([-26.0, 9.0, 1.4, 0.25])
c, s = np.cos(np.deg2rad(2.2)), np.sin(np.deg2rad(2.2))
truth, meas = [], []
for _ in range(N):
    truth.append(xt.copy())
    meas.append(h(xt) + np.array([rng.normal(0, sr), rng.normal(0, sth)]))
    xt = F @ xt
    xt[2:] = np.array([[c, -s], [s, c]]) @ xt[2:]      # hız vektörünü döndür
truth, meas = np.array(truth), np.array(meas)

# EKF döngüsü
xhat = np.array([-24.0, 12.0, 0.0, 0.0])
P = np.diag([16., 16., 9., 9.])
I = np.eye(4); est = []
for k in range(N):
    # --- TAHMİN (f doğrusal → F sabit) ---
    xhat = F @ xhat
    P = F @ P @ F.T + Q
    # --- GÜNCELLEME (h doğrusal-olmayan → Jacobian) ---
    Hk = H_jac(xhat)
    y = meas[k] - h(xhat); y[1] = wrap(y[1])    # açı farkını sar!
    S = Hk @ P @ Hk.T + R
    K = P @ Hk.T @ np.linalg.inv(S)
    xhat = xhat + K @ y
    P = (I - K @ Hk) @ P
    est.append(xhat.copy())
est = np.array(est)

rmse = np.sqrt(np.mean(np.sum((est[:, :2] - truth[:, :2])**2, axis=1)))
print(f"EKF konum RMSE = {rmse:.2f} m")         # -> 0.56 m

Burada hareketin doğrusal olduğuna (f = sabit F) ama ölçümün doğrusal-olmadığına dikkat edin: tüm doğrusal-olmama h ve H_k‘de yaşıyor. Her adımda yeniden hesaplanan tek şey Hk Jacobian’ı. Sonuç: 1°’lik açı ve 0.5 m’lik menzil gürültüsüne rağmen konum RMSE’si 0.56 m — sensörün ham gürültüsünün epey altında.

Etkileşimli Simülatör: Genişletilmiş Kalman Filtresi

Şimdi EKF’i canlı izleyelim. Bu sefer üstten bakışlı 2B bir görünüm var: orijinde sensör, dönen bir hedef ve EKF’in kovaryans elipsi. Menzil ve açı gürültüsünü, filtrenin süreç gürültüsünü ve hedefin dönüş hızını ayarlayabilirsiniz.

En öğretici deney: açı gürültüsünü (σ_θ) büyütün ve kovaryans elipsinin nasıl bir muz şeklini aldığını izleyin. Elips, sensöre olan doğrultuya dik (teğetsel) yönde uzar; çünkü uzak bir hedefte 1°’lik açı hatası, metrelerce yanal konum hatası demektir — oysa menzil yönündeki belirsizlik küçük kalır. Dönüş hızını artırırsanız, sabit-hız varsayan filtrenin manevra anlarında gerçek yörüngenin dışına savrularak geciktiğini görürsünüz; bu, model uyumsuzluğunun (model mismatch) doğrudan görsel kanıtıdır.

Mühendislik Notları: Q, R Ayarı, Iraksama ve Sayısal Kararlılık

Filtreyi çalıştırmak kolay; doğru çalıştırmak ustalık ister. Sahaya çıkmadan önce kontrol listesi:

1. Asıl mesele Q/R oranıdır. R çoğu zaman sensörün veri sayfasından ya da statik kalibrasyondan bilinir; gerçek ayar düğmesi Q‘dur. Mutlak değerlerden çok, Q ile R arasındaki oran filtrenin karakterini belirler: büyük Q/R → çevik ama gürültülü; küçük Q/R → pürüzsüz ama tembel ve manevrada geciken. Simülatörlerde bunu elinizle hissettiniz.

2. Filtrenin tutarlılığını ölçün (NIS/NEES). Filtre yalnızca doğru tahmin etmemeli, belirsizliği hakkında da dürüst olmalı. Yenilik y ile kovaryansı S kullanılarak hesaplanan normalize yenilik karesi (NIS), istatistiksel olarak bir χ² dağılımına uymalıdır. Yenilikler S‘in öngördüğünden sürekli büyükse filtre fazla iyimserdir (Q veya R küçük); sürekli küçükse fazla karamsardır. NIS, “filtrem yalan söylüyor mu?” sorusunun nicel cevabıdır.

3. Iraksamaya (divergence) karşı uyanık olun. En sinsi hata, P‘nin gerçek hatadan çok daha küçük olması — filtre kendine güvenir, gelen ölçümleri “aykırı” sanıp reddeder, gerçekten gitgide kopar. Sebepleri: çok küçük Q, modellenmemiş bir dinamik, ya da sayısal yuvarlama. Lineer simülatörde q‘yu dibe çekerek bunu birebir görebilirsiniz.

4. Sayısal kararlılık için Joseph formunu kullanın. P = (I − KH)P⁻ denklemi, kayan-nokta yuvarlamasıyla P‘yi asimetrik veya negatif-tanımlı yapabilir; bu da filtreyi çökertir. Joseph formu P = (I−KH)P⁻(I−KH)ᵀ + KRKᵀ her zaman simetrik ve pozitif yarı-tanımlı sonuç verir. Ek maliyet birkaç matris çarpımıdır; gömülü sistemlerde ucuz bir sigortadır. Her adımda P‘yi (P + Pᵀ)/2 ile simetrikleştirmek de yaygın, ucuz bir önlemdir. (Kayan-nokta tuzakları üzerine ayrı bir yazı yazmıştım; Kalman filtresi bu tuzakların en çok ısırdığı yerlerden biridir.)

5. Gözlemlenebilirliği (observability) sorgulayın. Yalnızca menzil ölçen bir sensör, hedefin açısal konumunu tek başına belirleyemez; takip ancak hedef hareket ettikçe ve geometri değiştikçe oturur. EKF simülatöründe elipsin yöne bağlı şişmesi tam da bunun resmidir. Durumunuzun ölçümlerinizden gerçekten çıkarılabilir olduğundan emin olun.

6. EKF’e özgü tehlike: lineerizasyon hatası. Başlangıç tahmini gerçekten uzaksa ya da fonksiyon çok bükülmüşse, teğet kötü bir yaklaşım olur ve EKF ıraksar. Çok keskin doğrusal-olmamalıkta, türev almayan Unscented Kalman Filtresi (UKF) — dağılımı seçili “sigma noktalarıyla” temsil eder — genellikle daha sağlamdır ve Jacobian türetme derdini ortadan kaldırır. Dağılım çok-modlu (multimodal) veya gürültü Gauss’tan çok uzaksa, sıra parçacık filtresine (particle filter) gelir: dağılımı binlerce örnekle temsil eden, hesapça pahalı ama çok genel bir yöntem.

Sonuç

Kalman filtresi, ilk bakışta matris denklemlerinden oluşan korkutucu bir reçete gibi görünür. Oysa altında yatan fikir tek bir cümleyle özetlenir: iki Gauss bilgiyi — modelin tahmini ile sensörün ölçümünü — her birinin belirsizliğine göre tartarak birleştir, sonra tekrarla. Tahmin adımı belirsizliği büyütür, güncelleme adımı küçültür; bu nefes alıp verme sonsuza dek sürer.

EKF ise aynı makinenin doğrusal-olmayan dünyaya uzanmış hâlidir: her adımda fonksiyonları çalışma noktasında bir teğetle değiştirir, gerisini değiştirmez. Bu küçük numara, onu yarım asırdır navigasyondan robotiğe kadar her yerde çalışan bir iş atı yapmıştır — kusursuz değil, ama şaşırtıcı derecede dayanıklı.

Tasarımınızın kaderini üç şey belirler: modelin (F, H ya da f, h) gerçeğe sadakati, Q‘nun ve R‘nin doğru ayarı. Bu üçünü yerine oturtursanız, gürültünün altından şaşırtıcı netlikte bir gerçek çıkarırsınız. Yanlış ayarlarsanız, filtre ya tembelce gerçeğin peşinden sürüklenir ya da kendine aşırı güvenip sessizce ıraksar. Her iki sonu da sahada görmek mümkün — ve artık ikisini de tanıyorsunuz.

Devamı için iyi konular: durum boyutu büyüdüğünde kare-kök (square-root) filtreleri sayısal kararlılığı nasıl kurtarır; UKF sigma noktalarıyla Jacobian’a neden hiç ihtiyaç duymaz; ve birden çok hareket modelini paralel koşturan IMM (Interacting Multiple Model) manevra yapan hedeflerde neden EKF’i döver. Bunlar defterimde duruyor.

Kaynaklar:

• R. E. Kálmán — “A New Approach to Linear Filtering and Prediction Problems”, Journal of Basic Engineering, Vol. 82, No. 1, 1960, pp. 35–45. (Her şeyin başladığı makale.)
• Greg Welch, Gary Bishop — An Introduction to the Kalman Filter, UNC-Chapel Hill, TR 95-041. (Klasik, sade giriş.)
• Sebastian Thrun, Wolfram Burgard, Dieter Fox — Probabilistic Robotics (MIT Press, 2005), Bölüm 3: “Gaussian Filters”. (KF ve EKF’in olasılıksal türetimi.)
• Dan Simon — Optimal State Estimation: Kalman, H∞, and Nonlinear Approaches (Wiley, 2006). (Joseph formu, kare-kök filtreleri ve sayısal konular için referans.)
• Yaakov Bar-Shalom, X.-Rong Li, Thiagalingam Kirubarajan — Estimation with Applications to Tracking and Navigation (Wiley, 2001). (Menzil-açı takibi, NIS/NEES tutarlılık testleri.)
• S. J. Julier, J. K. Uhlmann — “Unscented Filtering and Nonlinear Estimation”, Proceedings of the IEEE, Vol. 92, No. 3, 2004. (EKF’in ötesi: UKF.)
• Roger Labbe — Kalman and Bayesian Filters in Python. (Etkileşimli, kod-ağırlıklı ücretsiz kitap.)

İşte bu sorunun cevabı sistem mühendisliğidir. Sistem mühendisi, tek tek parçaları tasarlayan kişi değil; parçaların oluşturduğu bütünün doğru çalışmasından sorumlu olan kişidir.

Daha önce Yazılım Sistem Mühendisliği yazısında bu disiplinin yazılıma özel halini ele almıştık. Bu yazıda ise konuya bir adım geri çekilip sistem mühendisliğinin genel resmine bakacağız: ne olduğuna, neden gerekli olduğuna, yaşam döngüsünün nasıl yönetildiğine ve hangi standartların bu işi disipline ettiğine.

Önce “Sistem” Nedir?

Sistem mühendisliğini anlamak için önce sistem kelimesinin mühendislikteki anlamını netleştirmek gerekir. Sistem; ortak bir amaca hizmet etmek üzere bir araya gelmiş, birbiriyle etkileşen parçaların oluşturduğu bütündür. Bu parçalar yalnızca donanım değildir; donanım, yazılım, insanlar, prosedürler, veri ve tesisler birlikte bir sistemi oluşturabilir.

Sistemin en kritik özelliği, parçaların toplamından fazlası olmasıdır. Bir sistemin sergilediği ama hiçbir bileşeninde tek başına bulunmayan özelliklere beliren özellikler (emergent properties) denir:

• Bir uçağın “uçabilmesi” hiçbir tek parçasının özelliği değildir; parçaların doğru birleşiminden doğar.
• Bir sistemin “emniyetli” veya “güvenli” olması, bütünsel bir niteliktir; tek bir vidaya bakarak ölçülemez.
• Tam tersi de geçerlidir: Her bileşeni ayrı ayrı kusursuz çalışan bir sistem, arayüzlerdeki uyumsuzluk yüzünden bütün olarak başarısız olabilir.

İşte sistem mühendisliği tam da bu bütünsel ve beliren özelliklerle ilgilenir. Tek tek bileşenlerin mükemmelliği değil, onların birlikte çalıştığında ortaya çıkardığı davranış esas konudur.

Sistem Mühendisliğinin Tanımı

Alanın en yetkili kurumu olan INCOSE (International Council on Systems Engineering) sistem mühendisliğini şöyle tanımlar:

Sistem mühendisliği; mühendislik ürünü sistemlerin başarılı bir şekilde gerçekleştirilmesini, kullanılmasını ve hizmetten çıkarılmasını sağlamak amacıyla sistem ilke ve kavramlarını, bilimsel, teknolojik ve yönetimsel yöntemlerle birleştiren disiplinler ötesi ve bütünleştirici bir yaklaşımdır.

Bu tanımın iki anahtar kelimesi vardır:

• Disiplinler ötesi (transdisciplinary): Sistem mühendisi tek bir uzmanlık alanına gömülmez; mekanik, elektronik, yazılım, güvenilirlik, maliyet ve insan faktörleri gibi alanların kesişiminde çalışır.
• Bütünleştirici (integrative): Asıl görev, farklı uzmanların ürettiği parçaları tutarlı bir bütün hâlinde birleştirmek ve aralarındaki arayüzleri yönetmektir.

Buna sıkça eşlik eden bir benzetme vardır: Uzmanlık mühendisleri (yazılımcı, elektronikçi, makineci) bir orkestranın enstrüman sanatçılarıysa, sistem mühendisi orkestra şefidir. Şef hiçbir enstrümanı en iyi çalan kişi değildir; ama bütünün uyum içinde, doğru tempoda ve doğru notalarla çalmasından sorumludur.

Neden Sistem Mühendisliğine İhtiyaç Var?

Küçük ve basit bir ürün için ayrı bir sistem mühendisliği faaliyetine ihtiyaç olmayabilir. Sistemler büyüdükçe, karmaşıklaştıkça ve disiplin sayısı arttıkça üç temel problem ortaya çıkar:

1. Karmaşıklık: Bileşen sayısı arttıkça aralarındaki olası etkileşim sayısı karesel olarak büyür. On bileşenli bir sistemde 45 olası ikili arayüz vardır; yüz bileşende bu sayı 4950’ye çıkar. Kimse bu karmaşıklığı kafasında tutamaz; yönetilmesi gerekir.
2. Disiplinler arası çatışma: Yazılımcının “kolay” dediği şey elektronikçi için imkânsız, ağırlık mühendisi için kabul edilemez olabilir. Bu çelişen kısıtların dengelenmesi (trade-off) gerekir.
3. Hataların geç fark edilmesinin maliyeti: Bir hatayı gereksinim aşamasında yakalamakla sahada yakalamak arasında binlerce kat maliyet farkı vardır.

Bu son madde, sistem mühendisliğinin varlık sebebini en çarpıcı biçimde özetler. Barry Boehm’in klasik çalışmaları ve NASA verileriyle desteklenen meşhur hata maliyeti tırmanması aşağıdaki grafikte gösterilmektedir:

Buradaki ders nettir: Sistem mühendisliği maliyetin büyük kısmının henüz harcanmadığı, fakat o maliyetin büyük kısmının taahhüt edildiği erken aşamalara yoğunlaşır. Yaşam döngüsünün ilk %15’inde verilen kararlar, toplam maliyetin yaklaşık %80’ini kilitler. Doğru yatırım yeri burasıdır.

Sistem Mühendisliği Yaşam Döngüsü: V Modeli

Sistem mühendisliği sürecini anlatmak için en yaygın kullanılan görsel, V modelidir. V’nin sol kolu yukarıdan aşağıya ayrıştırma ve tanımlama sürecini, sağ kolu ise aşağıdan yukarıya entegrasyon ve doğrulama sürecini temsil eder. V’nin tabanında ise gerçekleştirme (kodlama/üretim) yer alır.

Bu modelin en güçlü fikri, sol koldaki her seviyenin sağ kolda kendisine eşlenen bir doğrulama seviyesi olmasıdır:

• Sistem gereksinimleri ↔ Sistem doğrulama testleri
• Mimari tasarım ↔ Entegrasyon testleri
• Birim tasarımı ↔ Birim testleri

Yani bir gereksinim yazılırken daha o anda “bu gereksinimi nasıl doğrulayacağım?” sorusu sorulur. Doğrulanamayan bir gereksinim, kötü bir gereksinimdir. V modelinin yatay okları bu izlenebilirlik (traceability) ilişkisini gösterir.

Temel Süreçler

Modern sistem mühendisliği, ISO/IEC/IEEE 15288 standardıyla resmî bir çerçeveye oturtulmuştur. Bu standart, sistem yaşam döngüsü süreçlerini dört grupta toplar: anlaşma süreçleri, organizasyonel proje destek süreçleri, teknik yönetim süreçleri ve teknik süreçler. Pratikte sistem mühendisinin günlük işini oluşturan teknik süreçler şunlardır:

Gereksinim Mühendisliği

Her şey paydaşların ihtiyaçlarıyla başlar. Sistem mühendisi bu ihtiyaçları toplar, çelişkilerini çözer ve onları ölçülebilir, test edilebilir sistem gereksinimlerine dönüştürür. Gereksinimler genellikle bir hiyerarşi oluşturur:

İyi bir gereksinim; tek anlamlı, doğrulanabilir, ulaşılabilir ve izlenebilir olmalıdır. Gereksinimler genellikle iki kümeye ayrılır:

• Fonksiyonel gereksinimler: Sistemin ne yapacağını tanımlar (“Sistem, hedefe X saniye içinde kilitlenmelidir”).
• Fonksiyonel olmayan gereksinimler (-ilities): Sistemin nasıl olacağını tanımlar — güvenilirlik (reliability), kullanılabilirlik (availability), bakım yapılabilirlik (maintainability), emniyet (safety), güvenlik (security), performans, taşınabilirlik. Sistemlerin başarısı çoğu zaman bu niteliklerde gizlidir.

Mimari ve Tasarım Tanımı

Gereksinimler belirlendikten sonra sistem mühendisi sistemin mimarisini kurar: hangi fonksiyon hangi bileşene atanacak, bileşenler hangi arayüzlerle konuşacak, veri nasıl akacak. Bu aşamada en kritik ürün arayüz kontrol belgeleridir (interface control documents, ICD). Sistemlerin çoğu, bileşenlerin içinde değil, bileşenler arasındaki arayüzlerde patlar.

Sistem Analizi ve Trade Study

Hiçbir tasarım kararı tek başına doğru ya da yanlış değildir; bir denge içerir. Daha hafif mi yoksa daha ucuz mu? Daha hızlı mı yoksa daha güç-verimli mi? Sistem mühendisi bu alternatifleri trade study (denge analizi) ile sistematik biçimde değerlendirir: kriterleri belirler, ağırlıklandırır, seçenekleri puanlar ve kararı gerekçesiyle kayıt altına alır.

Entegrasyon, Doğrulama ve Onaylama

Bileşenler üretildikten sonra sıra V’nin sağ kolundaki birleştirme ve sınama sürecine gelir. Burada sistem mühendisliğinin belki de en sık karıştırılan iki kavramı devreye girer:

• Doğrulama (Verification) — “Sistemi doğru mu yaptık?” Ürünün belirlenmiş gereksinimlere uyup uymadığının kontrolüdür. Referans, yazılı gereksinim ve tasarım belgeleridir.
• Onaylama (Validation) — “Doğru sistemi mi yaptık?” Ürünün, gerçek kullanım ortamında paydaşın asıl ihtiyacını karşılayıp karşılamadığının gösterilmesidir.

Bir sistem her gereksinimini eksiksiz karşılayıp (doğrulamayı geçip) yine de yanlış sistem olabilir — çünkü gereksinimlerin kendisi baştan yanlış yazılmış olabilir. İyi sistem mühendisliği her ikisini de güvenceye alır.

Süreç Boyunca Yatay Faaliyetler

Bu teknik süreçlere ek olarak, projenin tamamına yayılan yönetimsel faaliyetler vardır: risk yönetimi, konfigürasyon yönetimi (hangi versiyon, hangi değişiklik), izlenebilirlik yönetimi ve teknik gözden geçirmeler (SRR, PDR, CDR gibi kapı niteliğindeki tasarım gözden geçirmeleri).

Standartlar ve Çerçeveler

Sistem mühendisliği, sektöre göre farklılaşan zengin bir standart ekosistemine sahiptir. Başlıcaları:

Tarihsel olarak alanın kökleri 1950–60’lı yıllarda ABD savunma ve uzay programlarına (örneğin MIL-STD-499) ve Bell Labs’in karmaşık telekomünikasyon projelerine dayanır. Apollo programı, sistem mühendisliğini bir disiplin olarak olgunlaştıran kilometre taşı kabul edilir.

Belge Merkezliden Model Merkezliye: MBSE

Geleneksel sistem mühendisliği büyük ölçüde belge merkezlidir: yüzlerce sayfalık gereksinim dokümanları, Word ve Excel tablolarında yönetilen izlenebilirlik matrisleri. Bu yaklaşımın sorunu, belgelerin kolayca tutarsız hâle gelmesi ve büyük sistemlerde senkronizasyonun imkânsızlaşmasıdır.

Model Tabanlı Sistem Mühendisliği (Model-Based Systems Engineering, MBSE) bu soruna yanıttır. INCOSE’un tanımıyla MBSE; gereksinim, tasarım, analiz, doğrulama ve onaylama faaliyetlerini desteklemek için modellemenin, kavramsal tasarım aşamasından itibaren resmî olarak kullanılmasıdır.

MBSE’de “tek doğru kaynak” artık belgeler değil, tutarlı bir sistem modelidir. Bu modelden gereksinim raporları, arayüz tanımları ve diyagramlar otomatik türetilir. Modelin standart dili çoğunlukla SysML‘dir (Systems Modeling Language); son yıllarda olgunlaşan SysML v2, dilin ifade gücünü ve araç birlikte çalışabilirliğini önemli ölçüde artırmıştır.

Bu dönüşüm, dijital iplik (digital thread) ve dijital ikiz (digital twin) gibi kavramların da temelini oluşturur: Sistemin kavramdan operasyona kadar tüm yaşam döngüsünün dijital, izlenebilir ve simüle edilebilir bir kopyasının tutulması.

Sistem Mühendisinin Rolü

Yaygın bir yanılgı, sistem mühendisinin “her şeyi en iyi bilen süper mühendis” olduğudur. Gerçekte iyi bir sistem mühendisi genellikle T biçimli bir profile sahiptir: Bir alanda derin uzmanlık (T’nin dikey çizgisi) ile birlikte birçok alana yayılan geniş bir kavrayış (T’nin yatay çizgisi).

Sistem mühendisinin asıl katma değeri teknik değil, çoğu zaman bütünleştirici ve iletişimsel olmasıdır:

• Farklı disiplinlerin dilini anlar ve aralarında tercümanlık yapar.
• Bütünü görür; lokal optimizasyonun (bir bileşeni mükemmelleştirirken sistemi bozmanın) tuzağına düşmez.
• Kararların gerekçesini (rationale) kayıt altına alır; “neden böyle yapıldı?” sorusunun cevabını yıllar sonrasına taşır.
• Projenin teknik vicdanıdır: Takvim baskısı altında “bunu sonra hallederiz” denen riskleri görünür kılar.

Sonuç

Sistem mühendisliği, parlak bileşenler üretmekle ilgili değildir; o bileşenlerin birlikte, doğru ve güvenli biçimde çalışan bir bütün oluşturmasını sağlamakla ilgilidir. Karmaşıklık arttıkça, başarısızlığın asıl kaynağı tek tek parçaların kalitesi değil, parçalar arasındaki arayüzler, yanlış anlaşılan gereksinimler ve geç fark edilen tutarsızlıklar olur.

Bu yüzden sistem mühendisliği yatırımını yaşam döngüsünün başına — gereksinimlerin yazıldığı, mimarinin kurulduğu, doğrulama stratejisinin belirlendiği erken aşamalara — yoğunlaştırır. Hata maliyeti grafiğinin acımasız matematiği bunu zorunlu kılar.

İster bir uçak, ister bir otomobil, ister büyük ölçekli bir yazılım platformu geliştiriyor olun, soru hep aynıdır: Parçaların hepsi bir araya geldiğinde gerçekten işe yarayacak mı? Bu sorunun sorumluluğunu üstlenen kişi sistem mühendisidir.

Kaynaklar:

• INCOSE — Systems Engineering Handbook, 5th Edition (Wiley, 2023).
• ISO/IEC/IEEE 15288:2023 — Systems and software engineering — System life cycle processes.
• NASA — Systems Engineering Handbook, NASA/SP-2016-6105 Rev2.
• Barry W. Boehm — Software Engineering Economics (Prentice Hall, 1981).
• SAE International — ARP4754B: Guidelines for Development of Civil Aircraft and Systems (2023).
• Object Management Group — OMG Systems Modeling Language (SysML).
• R. H. Thayer — “Software system engineering: a tutorial,” IEEE Computer, vol. 35, no. 4, pp. 68-73, March 2002, DOI: 10.1109/MC.2002.993773.

Nyquist–Shannon teoremini hatırlayan herkes refleksle cevaplar: “En az 2.18 GSPS.” Mantıklı görünür: en yüksek frekansın iki katı. Cevap teknik olarak yanlış olmasa da, gerçek hayatta hiçbir ADS-B alıcısı 2 GSPS’lik bir ADC ile çalışmaz. Tipik bir donanım 1090 MHz’i önce bir mixer ile düşük bir IF’e indirir; yeterince temiz bir clock ve geniş analog bantlı bir ADC varsa bu adımı tamamen atlayıp 1090 MHz’in komşuluğundaki 2 MHz civarındaki dar bandı doğrudan 50 MSPS hatta daha yavaş clock ile örneklemek de mümkündür — ve hiçbir şey kaybolmaz.

Burada işin sırrı bandpass sampling (veya IF sampling, undersampling) denilen, klasik örnekleme teoreminin az bilinen kuzenidir. Bu yazıda teoremin geometrisine, izinli/yasak örnekleme oranlarının nasıl ortaya çıktığına, spektral ters çevrilme tuzağına ve modern ADC’lerin neden GHz mertebesinde analog bant genişliği ilan ettiğine inip somut bir Python örneğiyle her şeyi yerine oturtacağız.

Nyquist’in Saklı Varsayımı

Genel anlamıyla Nyquist–Shannon teoremi şunu söyler: bir sinyalin en yüksek frekans bileşeninin en az iki katı hızla örneklersen, bilgiyi kaybetmeden geri çevirebilirsin. Bu formülasyondaki gizli varsayım, sinyalin baseband (taban bant) olduğudur — yani spektrumun [0, f_max] aralığında yaşadığını kabul eder.

Oysa modern bir RF alıcısının önündeki sinyaller hiç de böyle değildir. Bir VHF havacılık telsizi [118, 137] MHz aralığında çalışır; ADS-B 1090 MHz civarında birkaç megahertz’lik bir bantta yaşar; GPS L1 1575.42 MHz taşıyıcısının etrafında C/A kodu için yaklaşık ±1 MHz, P(Y) kodu içinse ±10 MHz mertebesinde bir spektruma sahiptir. Bu sinyallerin ortak özelliği dar bantlı olmalarıdır: f_H − f_L değeri f_c değerine kıyasla çok küçüktür. Spektrumun büyük bölümü zaten boş.

Eğer boş alanı saymayı bırakırsak — ki kimse 0 ile f_L arasındaki sessizliği örneklemek için ADC çevirmiyor — gerçek bilgi yükümüz sadece B = f_H − f_L kadardır. Information-theoretic alt sınır da bu: f_s ≥ 2B yeterli olmalı. Tek soru, hangi 2B’nin (ya da 3B’nin, 5B’nin) işe yarayacağıdır.

Bandpass Sampling Teoremi

Resmi formülasyonu 1991’de Vaughan, Scott ve White, IEEE Transactions on Signal Processing’de yayınladığı “The Theory of Bandpass Sampling” makalesinde verdi (cilt 39, sayı 9, ss. 1973–1984). Teorem şunu söyler:

Spektrumu [f_L, f_H] aralığında yaşayan, B = f_H − f_L bant genişliğine sahip bir bandpass sinyali, aşağıdaki eşitsizliği sağlayan herhangi bir f_s ile birinci-derece tek-tip örnekleme (uniform first-order sampling) altında geri çevrilebilir biçimde sayısallaştırılabilir:

$$ \frac{2 f_H}{n} \le f_s \le \frac{2 f_L}{n - 1} $$

burada n, 1 ≤ n ≤ ⌊f_H / B⌋ aralığında bir tamsayıdır.

n = 1 aldığımızda eşitsizliğin sağ tarafı tanımsızdır (bölü sıfır); bu, klasik Nyquist durumudur: f_s ≥ 2·f_H. Daha büyük n değerleri, daha düşük örnekleme hızlarına izin verir — ama tüm aralıklar değil, sadece belirli aralıklar.

Burada n, sinyalin sonuçta yerleşeceği Nyquist bölgesinin indeksidir. Nyquist bölgesi n: [(n−1)·f_s/2, n·f_s/2] aralığını kapsar. Sinyalin tamamı tek bir Nyquist bölgesinin içine sığmak zorundadır — bir bölgenin sınırına denk gelirse iki komşu bölgeden alias’lar birbiriyle çakışır ve veri umutsuzca bozulur.

Sayısal Bir Örnek: 70 MHz IF, 10 MHz Bant

Klasik bir ara frekans (intermediate frequency, IF) seçimini düşünelim: f_c = 70 MHz, B = 10 MHz, dolayısıyla f_L = 65 MHz, f_H = 75 MHz.

Bu durumda izin verilen n değerleri 1 ≤ n ≤ ⌊75 / 10⌋ = 7 aralığındadır. Her n için izinli aralık şudur:

Üç şey hemen göze çarpıyor:

1. Yasak bölgeler vardır. Örneğin 43 MSPS ile 50 MSPS arasında hiçbir n çalışmaz. Bu aralıkta sinyal mutlaka iki komşu Nyquist bölgesi arasındaki sınırı keser ve alias’lar çakışır.
2. n büyüdükçe izinli aralık daralır. n = 7’de pencere yalnızca 240 kHz genişliktedir. Clock kaynağınızın drift’i, anti-alias filtresinin roll-off bölgesi, sıcaklık değişimi — hepsi bu dar yarığa sığmak zorundadır. Pratikte n = 7 ile bir tasarım yapmak intihardır.
3. Daha düşük hızlara inerken ciddi bir kazanım var. 75 MSPS yerine 31 MSPS’de çalışan bir ADC seçmek, hem güç tüketimini hem dijital arka uçtaki örnek hızını yarıdan fazla düşürür. Cortex-M tabanlı bir alıcıda bu ciddi bir mimari kazançtır.

İyi bir tasarımcı aralığın ortasında durur. n = 3 için 50–65 MSPS aralığının ortası ~57.5 MSPS’tir; clock’la 5 MSPS sapsa bile hâlâ izinli bölgenin içindedir.

Wedge Diyagramı: Geometriye Bakmak

Bu yasak ve izinli bölgeler bir grafiğe dökülünce ortaya wedge (kama) diyagramı çıkar. X ekseninde normalize merkez frekansı f_c / B, Y ekseninde normalize örnekleme hızı f_s / B vardır.

İzinli bölgeler, her biri bir n değerine karşılık gelen, üçgen şeklinde “kamalar”dır. Kamaların ortak özelliği:

• Üst kenarı f_s = 2·f_L / (n − 1) doğrusudur.
• Alt kenarı f_s = 2·f_H / n doğrusudur.
• Sol ucu noktada (kamanın tepesi) f_s = 2·B’dir — teorik alt sınır.

Yasak bölgeler, kamalar arasındaki üçgen “boşluklar”dır. Bir zone sınırının (m·f_s/2) bandın içine düştüğü her f_s yasaktır; bu da f_s ekseninde [2·f_L/m, 2·f_H/m] aralıklarına — yani kabaca 2·f_c/m noktalarının etrafına — denk gelir. f_s teorik alt sınır 2B’ye yaklaştıkça kamalar daralır ve yasak bölgeler sıklaşır. Bu yüzden “f_s’i 2B’ye çok yakın seçme” sezgisi vardır: tepe noktasının yakınında çalışan bir tasarım için clock drift’inin minik bir parçası dahi sistemi yasak bölgeye sürüklemeye yeter.

Yine de wedge diyagramı sadece bir gözlem aracıdır. Saha tasarımının değişmez kuralı şudur: bir kamanın iç noktasında dur, kenardan uzak kal. Vaughan’ın 1991 makalesi bu hassasiyet analizini ayrı bir bölümle ele alır.

Spectral Inversion: Çift n Hayatınızı Berbat Eder

Bandpass sampling’in en sinsi tuzağı spektral inversiyondur. Sinyalin Nyquist bölgesinin paritesine bağlı olarak baseband’e indiğinde ters çevrilmiş olabilir.

Lyons’un Understanding Digital Signal Processing kitabındaki konvansiyonu kullanırsak:

• n tek → spektrum yukarı doğru (“upright”), orijinaliyle aynı yönde.
• n çift → spektrum ters çevrilmiş (zone 1’de f_s/4 etrafında aynalanmış).

Şimdi gerçek sinyali 7.5 ila 8.5 Hz arasına koyalım — zone 2 (n = 2, çift). Alias: 8.5 → 1.5, 7.5 → 2.5. Üst kenar artık altta. Ters çevrilmiş.

Bu, simetrik modülasyonlarda (DSB, gerçek değerli BPSK gibi) görünmez bir hatadır — spektrum simetrik olduğu için ters de aynı görünür. Ama single sideband (SSB), asimetrik PSK, ya da Doppler işareti taşıyan FM sinyallerinde alıcının demodülatörü tam tersine çalışır. Bandpass sampling tasarımlarında klasik bir bug kaynağıdır ve genelde “neden konuşma anlaşılır ama yön bilgisi tersine” gibi anlamsız belirtilerle kendini gösterir.

Düzeltmesi basit: örnekleri (−1)^k ile çarpmak ya da downconversion sonrası I/Q kanallarından birinin işaretini çevirmek yeter. Önemli olan, hangi rejimde olduğunuzu bilmektir.

ADC’de Önemli Olan f_s Değil, Analog Bant Genişliğidir

Bandpass sampling’in pratik mühendisliği burada başlar. Bir ADC’yi 50 MSPS’de örnekleyip 1090 MHz’lik bir sinyal yakalamak istiyorsanız, ADC’nin analog girişi 1090 MHz’i geçirebilmek zorundadır.

İşte tam burası, Nyquist’i ezbere bilen mühendislerin tökezlediği yerdir. Çoğu kişi ADC datasheet’ine baktığında “100 MSPS” gibi sayısal hıza odaklanır ve analog input bandwidth (veya full-power input bandwidth) satırını kaçırır. Halbuki bandpass sampling’in fizibilitesi tamamen o satırla belirlenir.

Üç somut örnek üzerinden bakalım:

Bu cihazların ilan ettikleri “Nyquist hızlarının çok üstündeki analog bant genişliği” tesadüf değildir — bandpass sampling pazarı için kasıtlı olarak öyle tasarlanmışlardır. Sample-and-hold devresinin RC zaman sabiti, takip kapasitansı, switch açma süresi: hepsi yüzlerce megahertz hatta gigahertz ölçeğinde sinyalin “doğru” anda yakalanmasına izin verecek şekilde optimize edilmiştir.

Bir tasarım kuralı olarak: f_H < analog BW / 2 koşulu sağlanmadan o ADC bandpass sampling’e uygun değildir. Spec edge’inde çalışmak istemezsiniz.

Sınırı Belirleyen Aslında Jitter

ADC analog bant genişliği yeterli olsa bile, yüksek IF’te sinyali sınırlandıran başka bir parametre ortaya çıkar: clock jitter’ı, yani aperture jitter. Tipik formülü şudur:

$$ \mathrm{SNR_{jitter}} = -20 \log_{10}(2\pi \cdot f_{\text{in}} \cdot \sigma_t) $$

Burada f_in analog giriş frekansıdır (örnekleme hızı değil!) ve σ_t clock kaynağının RMS jitter değeridir. Formülde gizli olan korkutucu gerçek şudur: SNR, sinyal frekansıyla doğrudan azalır. Baseband’de problem olmayan jitter, 1 GHz IF’te uygulamayı imkânsız hale getirebilir.

Somut bir hesap: σ_t = 100 fs (modern bir VCXO için iyi bir değer), f_in = 1 GHz:

$$ \text{SNR} = -20 \log_{10}(2\pi \cdot 10^9 \cdot 10^{-13}) \approx 64 \text{ dB} $$

64 dB SNR, etkin bit sayısı (ENOB) cinsinden yaklaşık 10.3 bit’e karşılık gelir. Yani 78 dB SNR (≈12.6 ENOB) ilan eden LTC2208’i 1 GHz’de örneklerseniz, jitter tavanı yüzünden 2 etkin bitten fazlasını clock kaynağına kurban etmiş olursunuz — 16-bit’lik nominal çözünürlüğe göre kayıp 5 bit’i aşar. ADC’nin ilan ettiği 78 dB SNR’ı görmek için çok daha düşük IF’te kalmanız ya da çok daha temiz bir clock (örneğin 10 fs sınıfı bir SAW veya kristal osilatör) kullanmanız gerekir.

Bu yüzden bandpass sampling tasarımlarında clock kaynağı, alıcının LO’su kadar — bazen daha fazla — özen ister. Phase noise spektrumunun, sinyal yakınında −150 dBc/Hz’in altına inebilmesi tipik bir hedeftir.

Anti-Alias Filtresi Artık Bir Bandpass

Klasik baseband örneklemede anti-alias filtresi bir alçak geçirendir (lowpass): f_s/2 üzerindeki her şeyi keser. Bandpass sampling’de ise işin doğası değişir: hedeflediğiniz tek Nyquist bölgesinden başka her şey alias olur ve bandın içine düşer.

Yani filtre artık şunu yapmak zorundadır:

• [f_L, f_H] arasını geçirmek
• Diğer tüm Nyquist bölgelerine düşen sinyali ve gürültüyü bastırmak — özellikle DC’den f_L’e kadar olan geniş bant ve f_H’in üstündeki ADC analog BW’sine kadar olan bant.

Bunu sağlamak ciddi bir RF filtre tasarımı işidir. SAW (Surface Acoustic Wave) filtreleri, cavity filtreleri ya da seramik filtreler kullanılır. Pasif L-C ile yapmak istediğinizde, gereken yan-bant bastırma seviyesi (60–80 dB) ve gerçek RF uygulamalarındaki dar göreli bant (örneğin 1090 MHz’de 2 MHz, yani B/f_c ≈ %0.2; bu yazıdaki 70 MHz / 10 MHz örneği didaktik olarak geniş tutulmuştur) yüksek-Q kapasitörler ve hassas frekans cevabı ister.

İkinci ve daha önemli nokta: filtre sinyali geçirirken bantlardaki gürültüyü de geçirir. Bandpass sampling’de gürültü integration aralığı f_s/2 ile sınırlı değildir — ADC’nin analog BW’sine kadardır. Yani filtreyi geçen 600 MHz’lik geniş bir bant gürültüsü, sinyalle birlikte zone 1’e alias’lanır. Bu, Vaughan’ın 1991 makalesinin önemli bir sonucudur ve sıklıkla göz ardı edilir.

Python ile Sayısal Doğrulama

Teori güzel, ama her zaman dediğim gibi gözlerinizle görmediğiniz hiçbir şeye güvenmeyin. Aşağıdaki Python kodu 70 MHz IF’teki 10 MHz bant genişlikli bir sinyali üretir, n = 5 için izinli olan 31.25 MSPS’de örnekler ve sonucun zone 1’de doğru yere düştüğünü gösterir.

import numpy as np
import matplotlib.pyplot as plt

# Sinyal parametreleri
f_c    = 70e6        # taşıyıcı (IF merkezi)
B      = 10e6        # bant genişliği
T      = 100e-6      # toplam süre
f_high = 1.0e9       # "sürekli zaman" benzetimi için yüksek hızda örnekleme
t_high = np.arange(0, T, 1/f_high)

# Bandpass sinyali: basitlik için f_c ± B/4 konumunda iki ton
x_high = (np.cos(2*np.pi*(f_c - B/4)*t_high)
        + np.cos(2*np.pi*(f_c + B/4)*t_high))

# Bandpass sampling: f_s = 31.25 MSPS, n = 5 (izinli aralık [30, 32.5])
step = 32                       # 1.0e9 / 32 = 31.25 MSPS
f_s  = f_high / step
x_bp = x_high[::step]

# FFT
N    = len(x_bp)
X    = np.fft.fft(x_bp)
freq = np.fft.fftfreq(N, d=1/f_s)
mag  = 20*np.log10(np.abs(X) + 1e-12)

# n = 5 tek → upright; kayma miktarı (n-1)/2 · f_s = 2·f_s
shift = (5 - 1) / 2 * f_s
print("Beklenen alias tonları (MHz):",
      sorted([(f - shift) / 1e6 for f in (f_c - B/4, f_c + B/4)]))

pos = freq >= 0
peaks = freq[pos][np.argsort(mag[pos])[-2:]]
print("Ölçülen alias tonları (MHz):", sorted(peaks / 1e6))

plt.plot(freq[pos] / 1e6, mag[pos])
plt.xlabel("Frekans (MHz)"); plt.ylabel("Genlik (dB)")
plt.title(f"f_s = {f_s/1e6:.2f} MSPS, n = 5 — zone 1 alias'ı")
plt.grid(); plt.show()

Çalıştırınca pozitif yarıda 5 MHz ve 10 MHz civarında iki keskin tepe görmelisiniz. Hesap doğrudan modulodur: n = 5 için kayma miktarı (n−1)/2 · f_s = 2 · 31.25 = 62.5 MHz; alt ton 67.5 − 62.5 = 5 MHz’e, üst ton 72.5 − 62.5 = 10 MHz’e iner. n tek olduğu için spektrum upright kalır, yani alt-üst sıra korunur.

Şimdi denemeye değer bir alıştırma: step = 29 yapın — bu, f_s ≈ 34.48 MSPS demektir ve 65–75 MHz bandı için hiçbir n çalışmaz (n = 5’in tavanı 32.5, n = 4’ün tabanı 37.5 MSPS). Zone 4/5 sınırı (4·f_s/2 ≈ 68.97 MHz) iki tonun tam arasından geçer: 67.5 MHz tonu zone 4’ten (çift → ters), 72.5 MHz tonu zone 5’ten (tek → düz) alias’lanır. Tonlar 1.47 ve 3.53 MHz’e iner; aralarındaki 5 MHz’lik fark korunamaz ve f − shift formülü alt ton için yanlış sonuç verir. Yasak bölgenin gözlemlenebilir kanıtı budur.

İnce bir nokta: step = 30 (33.33 MSPS) da nominal 65–75 MHz bandı için yasak olmasına rağmen bu demoda spektrumu bozmaz — zone 4/5 sınırı 66.67 MHz, iki tonun da altında kaldığından ikisi de zone 5’te kalır ve tonlar temiz biçimde 0.83 ile 5.83 MHz’e iner. Yasak bölge tanımı sinyal bandının tamamına bakar; iki ayrık tondan oluşan demo sinyalimiz o bandı doldurmadığı için, zone sınırı tonların arasına denk gelmedikçe kaza olmaz. Gerçek bir modüle sinyal bandın tamamını doldurur ve aynı f_s’te geri dönülmez biçimde bozulurdu.

Etkileşimli Simülatör

Aşağıdaki araçla f_c, B ve f_s değerlerini değiştirerek alias konumunu ve izinli/yasak bölge sınırlarını anlık görebilirsiniz.

Mühendislik Notları ve Pratik Tuzaklar

Bandpass sampling’i sahaya çıkarmadan önce kontrol listesi:

1. Önce f_H’i, sonra f_s’i seç. Sinyal yüksek bandının ADC’nin analog input BW’sinin yarısını aşmaması ilk koşuldur. Bunu hesaplamadan datasheet’in MSPS satırına bakmak hatalıdır.
2. Wedge’in tepe noktasından kaç. Pratik bir kural: izinli aralığın ortasına denk gelen n’i seç. Eğer ortası çok dar bir kamaya düşüyorsa daha küçük n’e geç.
3. Clock’un phase noise’unu RF mühendisliği gibi düşün. σ_t = 1 ps’lik bir clock, baseband alıcısında lüks; 1 GHz IF’te facia.
4. Anti-alias filtresini erken seç. SAW filtresinin sipariş süresi haftalar olabilir. Sistem mimarisinde yeri belirlenmeden FPGA yazılımına geçmek riskli.
5. Spektral inversiyonu cebine yaz. n çift kullanıyorsan downstream demodülatörün önüne (-1)^k veya I/Q swap ekle. Test günü “neden tersine konuşuyor?” diye paniklemekten daha ucuza geliyor.
6. Gürültü figürünü unutma. Filtreyi geçen out-of-band gürültü doğrudan baseband’e iner. Aktif önyükselticinin gürültü figürü, geniş analog BW’de etkin gürültüye dönüşür.
7. Sıcaklık üzerinden clock drift’ini düşün. −40 °C’de farklı bir TCXO frekansı, izinli kamadan çıkmana neden olabilir. Tasarım marjı somut olarak hesaplanmalı.

Bandpass Sampling Nerede Kullanılır?

Modern alıcı mimarilerinin büyük kısmı hâlâ analog ön-karıştırıcı (mixer) ile bandı önce baseband’e ya da düşük IF’e indirir, sonra örnekler. Bunun nedeni hem analog BW yeterli ADC’lerin pahalı olması, hem de clock phase noise’unun maliyetli yönetimi.

Ama doğrudan-IF veya doğrudan-RF örnekleme yapan tasarımlar son 10 yılda hızla yayıldı:

• AMD/Xilinx Zynq UltraScale+ RFSoC (ZCU111, ZCU216 değerlendirme kartları) — yongaya entegre GSPS-sınıf doğrudan RF örnekleme ADC ve DAC blokları, FPGA fabric’i içinde sert IP olarak dijital downconverter/upconverter. Birkaç GHz’e ulaşan analog girişlerle, klasik mixer + IF + ADC zincirini tek yonga ile değiştirme amacı taşır.
• Ettus USRP X410 — Zynq RFSoC tabanlı, kanal başına 400 MHz anlık bant genişliği veren doğrudan RF örnekleme platformu.
• Yazılım tanımlı askeri telsizler ve doğrudan-IF örnekleme yapan üst-uç ölçüm cihazları (modern spektrum analizörleri, vektör sinyal analizörleri).

Buna karşılık PlutoSDR, RTL-SDR gibi popüler hobi/laboratuvar SDR’ler bandpass sampling kullanmaz — bunların hepsinde analog quadrature downconversion yapan tuner yongaları (AD9363, R820T2 vb.) vardır. ADC görece düşük IF’te (RTL-SDR için ~3.57 MHz) çalışır. Bandpass sampling görüldüğü kadar bedava değildir; ödediği bedel, clock ve filtre alt sisteminin yüksek karmaşıklığıdır.

Sonuç

Nyquist–Shannon teoremi temel bir doğrudur, ama “en yüksek frekansın iki katı” ezberi onu bir nevi karikatürleştirir. Sinyalin baseband değil dar-bantlı olduğu durumda, gerçek alt sınır bilgi yüküdür: f_s ≥ 2B. Bandpass sampling, bu alt sınıra hangi sayısal hilelerle nasıl yaklaşacağımızı söyler.

Pratikte bandpass sampling’i benimseyen tasarımlarda kritik karar üç sayıyla özetlenir: hangi n, hangi ADC analog BW, hangi clock jitter’ı. Bu üç sayıyı doğru yere koyarsanız, gerçekten 1 GHz’lik sinyali 50 MHz clockla örneklemek mümkündür — ve sahada her gün çalışır. Yanlış yere koyarsanız sistem ya hiç çalışmaz ya da bazen, anlayamadığınız zamanlarda kendi kendine gizemli biçimde bozulur. RF mühendisliğinde her iki son da görülmüştür.

Sonraki yazı için iyi bir devam konusu: bandpass sampling’in çıktısı zone 1’e indikten sonra dijital downconversion (DDC) ile I/Q ayrımı nasıl yapılır, ve neden “f_s/4 trick” denilen küçük sihir hem CIC filtresinden hem de NCO’dan tasarruf sağlar. Bu defterimde duruyor.

Kaynaklar:

• R. G. Vaughan, N. L. Scott, D. R. White — “The Theory of Bandpass Sampling”, IEEE Transactions on Signal Processing, Vol. 39, No. 9, Sept. 1991, pp. 1973–1984.
• Richard G. Lyons — Understanding Digital Signal Processing (3rd ed., Pearson, 2010), Bölüm 2: “Sampling Bandpass Signals” ve “Spectral Inversion in Bandpass Sampling”.
• Walt Kester (Analog Devices) — MT-007 Tutorial, “Aperture Time, Aperture Jitter, Aperture Delay Time — Removing the Confusion”.
• Walt Kester (ed.) — Analog-Digital Conversion, Analog Devices Education Library, 2004.
• Analog Devices — AD9265 datasheet (16-bit, 125 MSPS, 650 MHz analog BW).
• Texas Instruments — ADS5474 datasheet (14-bit, 400 MSPS, 1.4 GHz analog BW).
• Analog Devices — LTC2208 datasheet (16-bit, 130 MSPS, 700 MHz analog BW, 70 fs aperture jitter).
• AMD/Xilinx — Zynq UltraScale+ RFSoC ürün sayfası ve veri sayfaları.

İşte bu noktada Renode devreye giriyor. Bu yazıda, Xilinx (artık AMD) Zynq7000 SoC ailesinin Renode üzerinde nasıl simüle edildiğine, donanım çevre birimleri ile FPGA tarafının nasıl modellendiğine ve bu yaklaşımın hangi avantajları getirdiğine bakacağız.

Renode Nedir?

Renode, Antmicro tarafından geliştirilen ve MIT lisansı ile dağıtılan açık kaynak bir tam-SoC emülatörüdür. QEMU’nun aksine yalnızca CPU emülasyonuna odaklanmaz; çevre birimlerini, sensörleri, ağ arayüzlerini, kablosuz iletişim modüllerini ve hatta birden fazla cihazın aynı anda çalıştığı sistemleri tek bir simülasyon ortamında ele alır.

Renode’un öne çıkan özellikleri:

• Geniş platform desteği: 100’den fazla SoC ve geliştirme kartı (ARM Cortex-M/A, RISC-V, x86, PowerPC)
• Python ile genişletilebilirlik: Yeni bir çevre birimi, birkaç satırlık bir Python betiği ile eklenebilir
• Deterministik yürütme: Aynı senaryo her çalıştırıldığında tıpatıp aynı sonucu üretir
• Robot Framework entegrasyonu: Test otomasyonu doğrudan desteklenir
• Yerleşik GDB sunucusu: Hata ayıklama için ek araç gerekmez

Renode’un QEMU’dan en belirgin farkı, sistem entegrasyon testlerine odaklı tasarlanmış olmasıdır. UART çıktısını yakalamak, GPIO durumunu değiştirmek, sensörden değer “enjekte etmek” ya da ağ trafiğini iki sanal cihaz arasında köprülemek gibi işlemler Renode’da birinci sınıf vatandaş muamelesi görür.

Zynq7000 Mimarisine Kısa Bir Bakış

Zynq7000, tek bir silikon üzerinde iki dünyayı birleştirir:

• PS (Processing System): Çift çekirdekli ARM Cortex-A9 (1 GHz’e kadar, parça hızına göre), NEON SIMD birimi, donanımsal FPU, L1/L2 önbellek, DDR3 denetleyicisi ve sabit çevre birimleri (UART, SPI, I2C, GPIO, USB, Gigabit Ethernet, SD/MMC).
• PL (Programmable Logic): Artix-7 ya da Kintex-7 ailesinden bir FPGA dokusu; geliştiricinin kendi IP bloklarını, hızlandırıcılarını veya özel arayüzlerini sentezlediği alandır.
• AXI Interconnect: PS ile PL arasındaki yüksek bant genişlikli köprüdür. AXI3 / AXI4 protokolü üzerinden General-Purpose (GP), High-Performance (HP) ve Accelerator Coherency Port (ACP) bağlantılarını sunar.

PS tarafı, donanım üreticisi tarafından sabitlenmiş bir mikrodenetleyiciye benzer. PL tarafı ise tamamen sizin elinizdedir; bitstream ile yeniden programlayabilirsiniz. Renode’un bu iki dünyayı simüle ederken nasıl ele aldığı, yazının kalbini oluşturuyor.

Kurulum

Renode’u edinmenin birkaç yolu vardır. Linux üzerinde en hızlı yol resmi paket deposunu kullanmaktır:

# Ubuntu / Debian
wget https://github.com/renode/renode/releases/latest/download/renode_latest.deb
sudo apt install ./renode_latest.deb

# Çalıştır
renode

Docker tercih edenler için resmi imaj da mevcuttur:

docker run -it --rm antmicro/renode:latest

Kaynaktan derlemek isteyenler dotnet SDK 8.0 ile depoyu çekip build.sh betiğini çalıştırabilir. macOS ve Windows için de hazır paketler mevcuttur.

Kurulum doğrulaması basittir: renode komutu sizi (monitor) istemi ile karşılayacaktır.

İlk Simülasyon: .resc Senaryo Dosyası

Renode iki tür dosya kullanır:

• .repl (Renode Platform) — Platformun tanımı: hangi çevre birimleri hangi adreslerde, hangi IRQ’lara bağlı.
• .resc (Renode Script) — Senaryo: hangi platformu yükle, hangi firmware’i çalıştır, hangi pencereleri aç.

Renode kurulumu, Zynq tabanlı popüler kartlar için hazır platform dosyaları içerir. Örneğin ZedBoard için tipik bir senaryo şöyle görünür:

:name: ZedBoard ile Zynq7000 Simulasyonu
:description: Zynq7000 uzerinde bare-metal firmware

mach create "zedboard"
machine LoadPlatformDescription @platforms/boards/zedboard.repl

# UART cikti penceresini ac
showAnalyzer sysbus.uart1

# Firmware'i yukle
sysbus LoadELF @firmware.elf

# CPU0'i belirli bir adresten baslat
cpu0 PC 0x00100000

start

Bu senaryoyu renode boot.resc ile çalıştırdığınızda yeni bir pencere açılır ve UART çıktısı orada akmaya başlar. pause, step, start komutlarıyla zamanı tamamen kontrol edebilirsiniz: simülasyonu istediğiniz anda dondurabilir, talimatları tek tek ilerletebilir veya gerçek zamandan kat kat hızlı çalıştırabilirsiniz.

Platform Tanımı: .repl Dosyaları

Bir .repl dosyası, platformun adres haritasını, kesme bağlantılarını ve reset değerlerini tanımlar. ZedBoard platformunun küçük bir parçası:

gic: IRQControllers.ARM_GenericInterruptController @ {
        sysbus new Bus.BusMultiRegistration { address: 0xF8F01000; size: 0x1000; region: "distributor" };
        sysbus new Bus.BusMultiRegistration { address: 0xF8F00100; size: 0x100; region: "cpuInterface" }
    }
    [0-1] -> cpu0@[0-1]

uart1: UART.Cadence_UART @ sysbus 0xE0001000
    -> gic@50

gpio: GPIOPort.XilinxGPIOPS @ sysbus 0xE000A000
    IRQ -> gic@52

ttc0: Timers.Cadence_TTC @ sysbus 0xF8001000
    [0-2] -> gic@[10-12]

Burada Cadence_UART, XilinxGPIOPS gibi tip adları, Renode içinde hazır olarak gelen çevre birimi modellerine karşılık gelir. Adres alanı (0xE0001000), reset davranışı ve IRQ numarası, fiziksel Zynq7000 ile birebir eşleşir. Bu sayede aynı sürücü kodu, hem Renode’da hem de gerçek kartta değişiklik gerektirmeden çalışır.

İhtiyacınız olan bir çevre birimi platformda yoksa iki seçeneğiniz var: kendi .repl dosyanızı baştan yazmak, ya da mevcut olanı using ile dahil edip üzerine ekleme yapmak.

Donanım Çevre Birimlerinin Simülasyonu

Renode, çevre birimlerini kayıt davranış seviyesinde (register-transaction-level) modeller. Cycle-accurate değildir; yani saat döngüsü hassasiyetinde zamanlama yapmaz. Bunun yerine, yazılımın gördüğü her şeyin doğru olmasına odaklanır: aynı register adresleri, aynı bit alanları, aynı IRQ tetikleme davranışı, aynı protokol durum makineleri.

Zynq7000 için yerleşik olarak modellenen başlıca çevre birimler:

• UART (PS7_UART / Cadence_UART) — Tam fonksiyonel; FIFO seviyesi, baud rate, IRQ davranışı
• GIC (Generic Interrupt Controller) — ARM PrimeCell standart GIC modeli
• TTC (Triple Timer Counter) — Üç bağımsız 16-bit sayaç
• GPIO (XilinxGPIOPS) — 4 banka, MIO ve EMIO pinleri
• I2C, SPI — Cadence master/slave denetleyicileri
• DMA, Ethernet (GEM), SD/MMC — Temel düzeyde modellenmiştir

Eksik bir çevre birimi varsa, Python ile birkaç satırda basit bir model yazılabilir. Renode’un PythonPeripheral sınıfı, harici .py dosyalarını doğrudan çevre birimi olarak yükler. Önce platforma yeni cihazı ekleriz:

my_sensor: Python.PythonPeripheral @ sysbus 0x43C00000
    size: 0x100
    initable: true
    filename: "@scripts/my_sensor.py"

Sonra Python betiğini yazarız. Her bus erişiminde request nesnesi otomatik olarak sağlanır:

# my_sensor.py
if request.IsInit:
    sensor_value = 0

elif request.IsRead:
    if request.Offset == 0x00:
        request.Value = sensor_value      # sicaklik degeri
    elif request.Offset == 0x04:
        request.Value = 0x0001            # durum bayragi: hazir

elif request.IsWrite:
    if request.Offset == 0x08:
        sensor_value = request.Value      # firmware kalibrasyon yazabilir

Hepsi bu kadar — sınıf, kalıtım ya da derleme adımı yok. Renode konsolundan simülasyon sırasında sysbus.my_sensor WriteDoubleWord 0x08 42 yazarak sensör değerini değiştirebilirsiniz; firmware tam o anda farklı bir koda dallanır. Bu, fault injection testleri için son derece güçlü bir araçtır.

UART’ı TCP’ye Bağlamak

Renode’un en pratik özelliklerinden biri, sanal UART’ları TCP soketleri olarak dışa açabilmesidir. Bu sayede ekransız ortamlarda (CI sunucuları, Docker konteynerleri, uzak makineler) simülasyonu çalıştırıp telnet, netcat ya da kendi test betiğinizle bağlanabilirsiniz.

Renode tarafında iki komut yeter:

emulation CreateServerSocketTerminal 3456 "uart_term"
connector Connect sysbus.uart1 uart_term
start

İlk komut 3456 portunda bir TCP sunucusu açar, ikincisi sanal UART’ı bu sokete bağlar. Artık başka bir terminalden bağlanabilirsiniz:

$ telnet localhost 3456
Trying 127.0.0.1...
Connected to localhost.
Boot tamamlandi
Sensor degeri: 42
> help
Komutlar: status, reset, dump

Klavyeden yazdığınız her karakter firmware’in UART RX FIFO’suna düşer; firmware’in TX FIFO’suna yazdığı her karakter terminale akar. Tıpkı gerçek bir kart gibi.

Bu, otomatik testleri Python ile yazmanın en temiz yoludur. Pexpect ya da düz socket:

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("localhost", 3456))

# Boot tamamlanmasini bekle
buf = b""
while b"Boot tamamlandi" not in buf:
    buf += s.recv(4096)

# Komut gonder, cevabi yakala
s.sendall(b"sensor read\n")
buf = b""
while b"\n" not in buf:
    buf += s.recv(4096)

print("Firmware cevabi:", buf.decode().strip())
s.close()

Birden fazla UART’ı aynı anda farklı portlardan dışa açabilirsiniz — örneğin debug UART’ı 3456, telemetri UART’ı 3457 portundan. Aynı simülasyona iki ayrı Python istemcisi, iki ayrı porttan bağlanır.

Ek olarak UART’ı dosyaya yazdırmak da mümkündür:

sysbus.uart1 CreateFileBackend @uart.log true

CI’da test başarısız olduğunda bu log dosyası paha biçilmezdir.

FPGA / PL Tarafı Nasıl Simüle Edilir?

Renode’un en sık sorulan sorularından biri: “Peki ya FPGA?” Renode kendi başına Verilog ya da VHDL kodunu yorumlamaz. PL tarafını ele almak için iki yaygın yaklaşım vardır:

a) Python Peripheral (TLM Modeli)

FPGA’da yapılacak işin davranışsal modelini Python ile yazarsınız. Renode peripheral’ları register-transaction seviyesinde (TLM) modellendiği için AXI handshake’i, burst transfer’leri ve back-pressure gibi protokol detayları Renode tarafından soyutlanır; sizin kodunuz yalnızca register okuma/yazma çağrılarına yanıt verir. Bu yaklaşımda RTL test edilmez, ancak yazılım entegrasyonu sorunsuz ilerler.

Yukarıdaki my_sensor.py basit bir sensör modeliydi. PL tarafında daha tipik bir şey de — örneğin yazılan veriyi sayıp hazır bayrağı tutan minimal bir AXI slave — aynı yapıyla yazılır:

# axi_fifo.py - Yazilanlari sayan basit AXI slave
if request.IsInit:
    write_count = 0
    last_data = 0

elif request.IsRead:
    if request.Offset == 0x00:
        request.Value = 0xDEADBEEF       # IP ID register
    elif request.Offset == 0x04:
        request.Value = write_count      # kac kez yazildi
    elif request.Offset == 0x08:
        request.Value = last_data        # son yazilan veri

elif request.IsWrite:
    if request.Offset == 0x08:
        last_data = request.Value
        write_count += 1

Bu kadar küçük bir model bile sürücü geliştirmek ve yazılım entegrasyonunu test etmek için yeterlidir.

Ne zaman uygun? Henüz HDL yazılmamışken yazılımın ilerlemesi gerektiğinde, PoC ve erken aşama firmware geliştirmede ve fault injection senaryolarını hızla kurmak istediğinizde.

b) Verilator Co-simülasyon

Renode, Verilator ile sıkı entegrasyona sahiptir. HDL kaynak dosyaları Verilator ile C++’a derlenir; ortaya çıkan paylaşılan kütüphane Renode’a bağlanır. Renode’un AXI işlemleri (read/write transaction’lar) bu köprü üzerinden Verilator’a iletilir, Verilator yanıtı geri döner. PL bloğunuz gerçek RTL ile test edilmiş olur.

Önce .repl dosyasında co-simüle edilecek peripheral’ı tanımlarız:

my_axi_ip: CoSimulated.CoSimulatedPeripheral @ sysbus <0x43C00000, +0x1000>
    frequency: 100000000

Sonra .resc betiğinde Verilator çıktısı paylaşımlı kütüphaneyi bağlarız:

sysbus.my_axi_ip SimulationFilePath @libVtop.so

Bundan sonra firmware’in 0x43C00000 adresine yaptığı her AXI okuma/yazma, Verilator simülasyonuna iletilir; RTL’in yanıtı geri döner.

Ne zaman uygun? PL bloğunuzun RTL doğrulamasını da sistem testine dahil etmek istediğinizde. Saf RTL simülasyonuna kıyasla yavaş kalsa da, yazılım sürücüleriyle birlikte uçtan uca test imkânı sağlar.

İki Yaklaşımın Karşılaştırması

Pratikte ekipler bu iki yaklaşımı birlikte kullanır: yazılım ekibi Python peripheral ile hızlıca ilerler, RTL hazır olduğunda Verilator co-simülasyonuna geçilir.

Hata Ayıklama: GDB ile Bağlanmak

Renode, her sanal CPU için GDB Remote Serial Protocol sunucusu açabilir. Bu, fiziksel JTAG bağlantısının yerine geçer; üstelik çok daha hızlıdır ve sorun çıkarmaz. Kablosu kopmaz, hedef “wedge” olmaz, sürücü çakışması yaşanmaz.

Renode tarafında:

machine StartGdbServer 3333

Başka terminalde:

arm-none-eabi-gdb firmware.elf
(gdb) target remote :3333
(gdb) b main
Breakpoint 1 at 0x100040
(gdb) c
Continuing.
Breakpoint 1, main () at main.c:42

(gdb) info registers
r0   0x00000000
r1   0xe0001000
...
(gdb) x/16wx 0xE0001000   # UART register'larini incele

Tüm standart GDB özellikleri çalışır:

• Breakpoint, watchpoint, conditional break: Hardware watchpoint sayısı simülasyonda sınırsızdır
• Stack trace, frame inspection: Tam debug bilgisi varsa kaynak satırına kadar
• Memory read/write: Aktif simülasyonda istediğiniz adresi okuyup yazabilirsiniz
• Source-level stepping: step, next, finish

Bir watchpoint örneği — GPIO data register’ı her değiştiğinde dur:

(gdb) watch *(uint32_t*)0xE000A040
Hardware watchpoint 1: *(unsigned int*)0xE000A040
(gdb) c
Hardware watchpoint 1: *(unsigned int*)0xE000A040
Old value = 0
New value = 1

Time-travel hata ayıklama: Renode deterministik olduğu için, hatadan önce snapshot alıp koşumu tamamlayabilir, sonra snapshot’ı yeniden yükleyip farklı bir yol deneyebilirsiniz. Heisenbug avına alışkın olanlar için bu çok değerli bir yetenektir.

Reverse Debugging — Geri Adım Atmak

Renode’un belki de en az bilinen yeteneklerinden biri GDB reverse execution desteğidir. Yani simülasyonu sadece duraklatmakla kalmaz, geriye doğru da çalıştırabilirsiniz.

Açmak için, GDB bağlanmadan önce Renode tarafında tek satırlık bir ayar yeterlidir:

machine StartGdbServer 3333
reverseExecMode true

Sonra GDB’de standart “reverse” komutları çalışır:

(gdb) target remote :3333
(gdb) b main
(gdb) c
Breakpoint 1, main () at main.c:42

(gdb) n                # 5 satir ileri git
(gdb) n
(gdb) n
(gdb) n
(gdb) n

(gdb) reverse-step     # bir satir geri (rs kisaltmasi)
(gdb) reverse-stepi    # bir assembly instruction geri (rsi)
(gdb) reverse-continue # son breakpoint'e ya da ilk snapshot'a kadar geri
(gdb) rsi 50           # 50 instruction geri

Mekanizma snapshot tabanlıdır: Renode arka planda periyodik state snapshot’ları alır; reverse komutları, en yakın snapshot’a dönüp oradan tekrar ileri koşturarak istenen noktaya ulaşır. Bu yüzden:

• Reverse hız olarak forward’dan yavaş çalışır
• Snapshot sıklığı performans/granülerlik dengesini belirler
• Tek çekirdek (single-core) emülasyonlarda desteklenir; çift Cortex-A9’lu Zynq7000’de bu özelliği kullanmak isterseniz SMP yerine yalnızca tek CPU başlatan bir senaryo kurmanız gerekir

Pratik değer: Diyelim ki zor yeniden üretilen bir hata yakaladınız. Kritik anı geçtikten sonra, bir register’ın yanlış değer aldığını fark ettiniz. Forward debugging’de tüm koşumu sıfırdan başlatıp doğru noktada durmaya çalışırsınız. Reverse ile bulunduğunuz noktadan geriye doğru giderek ilk yanlış adımı bulursunuz — çoğu zaman dakikalar yerine saniyeler içinde.

VS Code, CLion, Eclipse’in GDB entegrasyonu doğrudan çalışır. Tipik bir launch.json:

{
    "type": "cppdbg",
    "request": "launch",
    "program": "${workspaceFolder}/build/firmware.elf",
    "miDebuggerServerAddress": "localhost:3333",
    "miDebuggerPath": "/usr/bin/arm-none-eabi-gdb"
}

Tek değişiklik şudur: gerçek board için kullanılan OpenOCD adresinin yerine Renode portu yazılır. Geri kalan tüm IDE deneyimi aynıdır.

Hook’lar: Renode’un Süper Gücü

Hook’lar, simülasyon sırasında belirli olaylara Python callback bağlamanın yoludur. Renode’u QEMU’dan ya da basit bir emülatörden ayıran en güçlü özellik budur. Hook’lar sayesinde, gerçek donanımda asla erişemeyeceğiniz iç durumlara müdahale edebilirsiniz.

Adres tabanlı (watchpoint) hook

Belirli bir adrese yapılan her yazmayı yakalayalım:

sysbus AddWatchpointHook 0xE000A040 DoubleWord Write "print('GPIO yazildi: ' + hex(value))"

Parametreler: adres, genişlik (Byte / Word / DoubleWord / QuadWord ya da numerik 1/2/4/8), erişim modu (Read / Write / ReadWrite), Python ifadesi. Firmware bu register’a her yazdığında ekrana satır basılır. Bu yöntemle protokol trace’i çıkarmak, fiziksel donanımda son derece zordur.

Fonksiyon başı hook

Bir sembole varıldığında çalışacak callback’i kurmak için AddSymbolHook kullanılır; komut sembolün adresini otomatik olarak çözer:

cpu0 AddSymbolHook "panic" "print('PANIC! PC=' + hex(pc))"

panic fonksiyonu çağrıldığında log basılır — ya da machine Pause ile simülasyonu durdurursunuz. Hata yakalama için idealdir.

Fault injection hook

Diyelim ki SPI flash okuma fonksiyonunun 17. çağrısında hata enjekte etmek istiyorsunuz. Fiziksel donanımda bunu yapmak çok zordur; Renode’da Python ile birkaç satır yeterlidir:

# fault_inject.py
call_count = 0

def on_spi_read_entry(cpu):
    global call_count
    call_count += 1
    if call_count == 17:
        # R0 (donus degeri) = 0xFFFFFFFF (hata)
        cpu.SetRegisterUnsafe(0, 0xFFFFFFFF)
        # Fonksiyonu erken sonlandir
        cpu.PC = cpu.GetRegisterUnsafe(14).RawValue  # LR

Bu betiği Renode’a yükleyip spi_read sembolüne bağlayın. Test, retry mantığını gerçekçi koşullar altında doğrular.

Coverage toplama

cpu0 EnableProfilerCollapsedStack @coverage.txt false

Her instruction’ı yakalar; hangi fonksiyonların ne kadar çalıştığını ortaya çıkarır. Çıktıyı inferno-flamegraph ile besleyerek bir gecede eksiksiz bir flame graph üretebilirsiniz. Donanımda coverage toplamak gcov ile dahi bu kadar temiz olmaz.

IRQ hook

Bir kesme tetiklendiğinde, CPU üzerinden hook bağlanır:

cpu0 AddHookAtInterruptBegin "print('IRQ basladi')"
cpu0 AddHookAtInterruptEnd   "print('IRQ bitti')"

IRQ akışını anlamak için altın değerindedir. Çoklu kesme yarış koşullarını çözmekte de yardımcı olur.

Önemli: Hook’lar simülasyon ömrü boyunca aktif kalır. Test izolasyonu için her test başlangıcında Reset Emulation ile makine durumunu tertemiz başlatın; aksi takdirde hook’lar sonraki testlere taşınır ve flakiness kaynağı olur.

Hook’lar, Renode’u sıradan bir emülatörden, gözlemlenebilir ve müdahale edilebilir bir sisteme dönüştürür.

Diğer İleri Düzey Özellikler

Renode’un günlük kullanımda ezberlenmesi gereken birkaç başka özelliği:

Logger seviyeleri ve filtreleri

sysbus.uart1 LogLevel 0    # NOISY - her byte'i logla
sysbus.gpio  LogLevel 3    # WARNING ve uzeri
logFile @sim.log true

Her çevre birimi bağımsız log seviyesi alır. Sorunlu modülü debug log’una yükseltip diğerlerini sessizleştirebilirsiniz; CI loglarınız böylece yönetilebilir kalır.

Snapshot / Restore

Save @before-test.snapshot
# ... test calistir, sistemde degisiklik yap
Load @before-test.snapshot
# ... tertemiz bastan basla

Tipik kullanım: Linux boot edildikten sonra snapshot alın, her test bu snapshot’tan başlasın. 30 saniyelik boot, 50 ms’lik restore’a düşer. Bu yaklaşım CI suite süresini dramatik şekilde kısaltır.

Multi-machine simülasyonu

mach create "node1"
machine LoadPlatformDescription @platforms/boards/zedboard.repl
mach create "node2"
machine LoadPlatformDescription @platforms/boards/zedboard.repl

emulation CreateSwitch "switch1"
connector Connect node1.eth0 switch1
connector Connect node2.eth0 switch1

İki Zynq7000 kartı arasında Ethernet trafiği simüle edilir. Dağıtık sistem firmware’i, master/slave protokoller ve redundans senaryoları için olmazsa olmazdır.

Time control

emulation SetGlobalQuantum '0.000010'   # 10 us quantum
machine Pause
machine Resume

Simülasyonu duraklatabilir, yavaşlatabilir veya hızlandırabilirsiniz. Gerçek zaman zorunluluğu olmayan testler, simülasyonu gerçek zamandan kat kat hızlı koşturarak saatlerce sürecek bir testi dakikalara indirebilir.

Wireless ve PCAP

Renode’un IEEE 802.15.4 (Zigbee) ve Bluetooth Low Energy için sanal “radio medium” desteği vardır. Birden fazla cihaz aynı medyumda paket alıp gönderir, Wireshark uyumlu PCAP dosyası kaydedilir (Ethernet, 802.15.4 ve BLE için). Mesh ağ firmware’i geliştirenler için biçilmiş kaftan.

Sembol bazlı cpu0 LogFunctionNames

cpu0 LogFunctionNames true

Her fonksiyon çağrısını log’a yazar. Boot sırasında nelerin çağrıldığını görmek ve çağrı grafiğini anlamak için son derece hızlı bir araçtır.

Test Otomasyonu

Renode, kutudan çıktığı haliyle Robot Framework desteği sunar. Bu özellik, simülasyonun CI/CD ortamlarına entegrasyonunu çok kolaylaştırır. Tipik bir test dosyası şuna benzer:

*** Settings ***
Suite Setup     Setup
Suite Teardown  Teardown
Test Setup      Reset Emulation
Resource        ${RENODEKEYWORDS}

*** Test Cases ***
Boot ZedBoard Firmware
    Execute Command          include @scripts/boot.resc
    Create Terminal Tester   sysbus.uart1
    Start Emulation
    Wait For Line On Uart    Boot tamamlandi
    Wait For Line On Uart    Sensor degeri: 42

GPIO Pini Yuksek Cikmali
    Execute Command          include @scripts/boot.resc
    Start Emulation
    Execute Command          sysbus.gpio WritePin 7 true
    # Firmware'in pini okuyup yanit vermesini bekle
    Wait For Line On Uart    Pin 7 yuksek

Çalıştırma komutu: renode-test test.robot. CI ortamında bu komut, fiziksel kart gerektirmeden bütün regresyon testlerini koşturur. Uzun boot sürelerini atlamak için snapshot / restore mekanizmasını kullanabilirsiniz: simülasyonu bir kez boot edip durumu snapshot olarak kaydedersiniz, sonraki testler o noktadan başlar.

Geliştirme, Debug ve Test için Avantajlar

Renode ile Zynq7000 simülasyonunun fiziksel kartla yüksek seviyeli karşılaştırması:

Bu tablo özet sunuyor; üç ayrı disiplin için somut faydalara bakalım.

Geliştirme tarafında

• Donanım gelmeden başlanır. Yeni bir Zynq7000 kartı tasarlandığı sırada yazılım ekibi simülasyon üzerinde sürücüleri yazmaya başlayabilir. PCB üretimi 6 hafta sürüyorsa, o 6 hafta boşa gitmez.
• Hızlı iterasyon. Bitstream sentezi 30 dakika sürüyorsa, Renode’da platform değişikliği 2 saniye sürer. Yazılım geliştiricilerin donanım ekibinin bir sonraki sentezini beklemesine gerek kalmaz.
• Yeni katılım eşiği düşer. Yeni gelen mühendise kart, JTAG, USB-UART ve lab erişimi ayarlamak yerine git clone && renode boot.resc yeterli olur.
• Aynı kod hem simülasyonda hem gerçek donanımda çalışır. Renode’un adresleri ve davranışı fiziksel SoC ile birebir eşleşir; sürücü kodu port etmeden iki tarafta da koşar.

Debug tarafında

• Determinizm. Aynı bug aynı şekilde tekrar üretilir; “bende çalışıyor” durumu yoktur. Reproducer’lar snapshot ya da .resc betiği olarak paylaşılır.
• Time-travel. Bug’dan önce snapshot alın, koşumu tamamlayın, sonra snapshot’ı yükleyip farklı bir yolda deneyin. Heisenbug’ları çözmek için fiziksel donanımda imkansıza yakın bir yetenektir.
• Görünürlük. Hook’lar ve logger sayesinde gerçek donanımda görünmez olan iç durumlar (register snapshot’ı, IRQ akışı, AXI handshake) izlenebilir hale gelir.
• GDB her zaman bağlı. JTAG kopmaz, hedef wedge olmaz. İstediğiniz anda durdurursunuz, durumu incelersiniz, devam ettirirsiniz.
• Coverage temiz toplanır. Renode tarafından üretilen instruction trace tamamen offline işlenebilir; gerçek donanımda bunu yapmak için ek donanım ya da kod enstrümantasyonu gerekir.

Test tarafında

• CI/CD entegrasyonu. Robot Framework + ekransız Renode + Docker = her commit’te tam sistem testi. Kart farmının operasyonel maliyeti yoktur.
• Paralel koşum. Tek bir makinede 16 simülasyon paralel çalışır; aynısını fiziksel kart farmında yapmak 16 ayrı kart gerektirir.
• Fault injection. “Şu IRQ kaybolsa ne olur? DMA timeout olursa? Sensör NaN dönerse?” Hepsi tek hook satırı ile test edilebilir; fiziksel donanımda kurulması haftalar sürecek senaryolar dakikalara iner.
• Regresyon süresi. Snapshot’lar sayesinde bir gecede onlarca kat fazla test koşturulur; günlük geri bildirim döngüsü çok daha sıkı hale gelir.
• Veri odaklı test. Sensör girdilerini dosyadan besleyen Python peripheral’lar, aynı testi yüzlerce farklı veri kümesiyle koşturmayı mümkün kılar.

Kullanım Alanları

Renode + Zynq7000 ikilisinin somut kullanım alanları:

1. Bootloader geliştirme. U-Boot, FSBL, SPL ve özel bootloader’lar Renode’da boot edilir. SD kart imajı yüklenir, JTAG ya da USB-UART kurmaya gerek kalmaz. Her commit’te boot tamamlanma süresi otomatik ölçülür ve regresyon olarak işaretlenebilir.

2. Linux kernel hata ayıklama. Custom kernel patch’leri Renode üzerinde test edilir. kgdb çalıştırmak fiziksel kartta yorucudur; Renode’un yerleşik GDB sunucusu doğrudan çekirdek sembollerine bağlanır.

3. Avionik ve fonksiyonel güvenlik. DO-178C, IEC 61508, EN 50128 gibi standartlar yüksek test kapsamı ve kanıtlanabilir tekrarlanabilirlik gerektirir. Renode’un deterministik yapısı bu beklentiyi doğal olarak karşılar; testi .resc betiği olarak sertifikasyon dosyasına eklemek mümkündür.

4. Drone, robot ve otonom sistemler. Mock peripheral’lar üzerinden GPS, IMU ve lidar girdileri dosyadan simüle edilerek uçuş kontrol algoritmaları test edilir. Saha uçuşu yapmadan algoritma doğrulanmış olur.

5. Eğitim laboratuvarları. Üniversite ya da kurum içi eğitimlerde, her öğrenci için kart sağlamak yerine herkesin laptop’ında Renode çalışır. Yanlış kod yazılsa bile kart yanmaz.

6. Güvenlik araştırması. Firmware fuzzing’i hızlandırır; AFL veya libFuzzer ile birlikte koşturulur. Side-channel analizi için instruction trace çıkarılabilir. CVE PoC’leri snapshot olarak paylaşılır, reproducer net olur.

7. Firmware OTA güncelleme testleri. OTA başarısız olursa fiziksel kart bricklenir; Renode’da bricklendiyse Reset komutu yeterlidir. Riskli bootloader değişikliklerini Renode’da yüzlerce kez test edip karta yalnızca kararlı sürümü atabilirsiniz.

8. Müşteri demo’ları ve eğitim. Sahaya kart götürmeden firmware’in çalıştığını gösterebilirsiniz. Müşteriye veya entegrasyon ortağına Docker imajı bırakırsanız, kart olmadan da deneyebilirler.

9. Hızlı PoC ve teklif aşaması. Müşteri “şu çevre birimi destekleniyor mu?” diye sorduğunda, fiziksel kart sipariş etmeden Renode’da basit bir prototip yapıp gösterebilirsiniz.

Best Practices

Renode’u proje sürecine sokarken biriken pratik dersler:

1. .resc ve .repl dosyalarını versiyon kontrolünde tutun. Bunlar projeye ait konfigürasyondur; firmware kaynak kodu kadar değerlidir. Repo’da sim/ klasörü açıp betikleri orada tutun ve kod incelemesine tabi kılın.

2. Renode versiyonunu pinleyin. renode --version çıktısını CI loglarına yazdırın; Dockerfile’da spesifik tag (örn. antmicro/renode:1.14.0) kullanın. Determinizm bunu gerektirir; aynı testin aynı sonucu üretmesi versiyon sabitliğiyle başlar.

3. Snapshot stratejisi kurun. Uzun boot’ları her test başında tekrarlamak israftır. “Linux boot tamamlandıktan sonra” ya da “init betiği çalıştıktan sonra” gibi tipik anlarda snapshot alıp test suite’lerini bu noktadan başlatın. Bu yaklaşım, karmaşık bir projede toplam CI süresini saatlerden dakikalara çekebilir.

4. Logger seviyesini ortama göre ayarlayın. CI’da LogLevel 3 (Warning); lokal debug’da LogLevel 0 (Noisy). Aksi takdirde CI logu fazlasıyla şişer, gerçek sorunlar gürültü altında kaybolur.

5. Test başlangıçlarını izole edin. Her test başında Reset Emulation çağırın; bu, kalan hook’lar dahil makine durumunu tertemiz sıfırlar. Hook sızıntısı, en sinsi flakiness kaynağıdır.

6. Custom peripheral’lar küçük olsun. Bir Python peripheral 50 satırı geçiyorsa ayrı bir .py dosyasına alın ve pytest ile birim testini yazın. Test edilmemiş bir peripheral, ana firmware’in hatalarını maskeleyebilir.

7. Robot Framework testlerini paralel koşturun. pabot ile paralel koşum mümkündür. Her test kendi makine örneğinde izole olsun; Reset Emulation, Test Setup adımında zorunlu olsun.

8. UART çıktısını dosyaya da yazdırın. sysbus.uart1 CreateFileBackend @uart.log true ile UART akışını dosyaya kaydedin. CI’da test başarısız olduğunda bu log paha biçilmezdir.

9. Ekransız modu kullanın. Renode GUI yerel hata ayıklama için iyidir; CI için ise --disable-xwt --console veya --hide-monitor bayraklarıyla başlatın. Hem hız kazanırsınız hem de ekran bağımlılığı kalmaz.

10. Real-time bağımlılıkları dikkatli ele alın. Renode RealTimeMode‘da fiziksel zamana hizalanmaya çalışır ama saat doğruluğu çekirdek kullanımına bağlıdır. Sıkı timing testleri için emulation SetGlobalQuantum ile deterministik time-step kullanın; gerçek zamana güvenmeyin.

11. Sensör akışlarını dosyadan besleyin. Sensör simülasyonunu kod içine gömmek yerine, JSON / CSV dosyasından okuyacak şekilde yazın. Aynı test senaryosu farklı veri kümeleriyle koşturulabilir — veri odaklı test (data-driven testing) kapısı böylece açılır.

12. Mevcut platformları kopyalayıp özelleştirin. @platforms/boards/zedboard.repl‘i kopyalayıp my_board.repl yapın, using ile orijinali dahil edip üzerine sadece farkları yazın. Renode güncellemelerinde temel platform iyileşirken sizin patch’iniz korunur.

13. Coverage’ı simülasyondan toplayın. cpu0 EnableProfilerCollapsedStack ile çıkan log + inferno-flamegraph = bir gecede test kapsamı raporu. Manuel kart üzerinde coverage almak çok daha pahalıdır.

14. PR’lara Renode test sonucu ekleyin. GitHub Actions’ta renode-test çıktısını PR yorumuna yapıştıran bir adım kurun. İnceleyiciler testin yeşil olduğunu görerek incelemeye başlar; bu, “deneyip baktım” kültürünü destekler.

15. Renode dokümantasyonunu sıkça açın. Renode hızla gelişiyor; renode.readthedocs.io yeni özellikler için en güncel kaynaktır. Antmicro blog’u Verilator entegrasyonu, yeni platformlar ve case study’ler için kıymetlidir.

Sınırlamalar

Renode’un her şeye çare olmadığını da unutmamak gerekir:

• Cycle-accurate değildir. Gerçek zamanlı performans profili ölçümü için uygun değildir. Cache miss oranları, DDR3 timing’i, pipeline davranışı gerçek donanımdaki sonuçlarla birebir örtüşmez.
• Tüm çevre birimleri tam modellenmemiştir. Zynq7000’in PCIe, USB OTG gibi bazı blokları yalnızca temel düzeyde simüle edilir.
• FPGA HDL doğrulaması için Verilator gibi ek bir araç gerekir. Renode tek başına RTL çalıştıramaz.
• Analog dünya kısıtlıdır. ADC/DAC kanalları yerleşik olarak gelmez; veri akışını siz “enjekte etmelisiniz”.

Bu sınırlamalara rağmen, sistem entegrasyon testlerinin %80’i Renode üzerinde yapılabilir. Geri kalan kısım fiziksel donanımda son doğrulamayla tamamlanır.

Sonuç

Zynq7000 gibi PS+PL hibrit bir SoC’yi geliştirmek, donanım kaynaklı bekleme süreleri ve test maliyetleri yüzünden çoğu zaman acı verici olur. Renode, açık kaynak doğası, geniş çevre birim kütüphanesi ve Verilator ile co-simülasyon yeteneği sayesinde bu sürecin önemli bir bölümünü masaüstüne ya da CI sunucusuna taşımanıza imkân tanır.

Yazılım, donanım gelmeden hazır olabilir; testler her commit’te otomatik koşabilir; “şu hatayı tekrarlat” denildiğinde simülasyon snapshot’ı paylaşmak yeterli olabilir. Üstelik bunların tümü için herhangi bir lisans ücreti ödemezsiniz.

Renode’un Zynq7000’i ile başlamak için yapmanız gereken yalnızca renode komutunu çalıştırıp start @scripts/single-node/zedboard.resc yazmaktır. Gerisi, zaten gömülü mühendisin bildiği iştir.

Kaynaklar:

• Renode resmi sitesi
• Renode GitHub deposu
• Renode dokümantasyonu
• Antmicro — Verilator ile Renode co-simülasyon
• AMD/Xilinx Zynq7000 SoC ailesi
• Renode Robot Framework rehberi

Akreditasyon denetimi sabahı. Denetçi elinde bir kalem, masanızdaki Keysight 34465A multimetreyi gösteriyor.

— “Bu cihazı neyle kalibre ediyorsunuz?” — “Yan rafta duran Fluke 5720A kalibratörle.” — “Peki Fluke 5720A neyle kalibre edildi?” — “Geçen yıl TÜBİTAK UME’ye gönderdik.” — “Peki UME neyle kalibre etti?”

Kısa bir sessizlik. Cevabı tahmin ediyorsunuz ama ifadeyi bulamıyorsunuz: daha iyi bir kalibratörle. Peki o kalibratör neyle? Daha iyisiyle. Sonra? Sonsuza mı gidiyor bu zincir?

Bir önceki yazıda bir cihazın belirsizliğinin nasıl hesaplandığını adım adım gördük. Belirsizlik bütçesinin son satırında “kalibrasyon belgesi (UME, k=2)” diye bir kaynak vardı; o satıra bir sayı yazıp geçtik. Bu yazıda o satırın arkasını açacağız. Kalibrasyon belgesindeki belirsizlik nereden geliyor? UME bu sayıyı nasıl üretiyor? Ve zincirin en tepesindeki cihazlar — ki onlar bu sektörün gerçekten en hassas ölçüm aletleri — nasıl doğrulanıyorlar?

Cevap, mühendislikten yavaş yavaş fiziğe doğru kayıyor. Zincirin tepesinde başka bir cihaz yok. Doğa yasaları var.

İzlenebilirlik Piramidi

Önceki yazıda izlenebilirlik zincirini lineer bir akış olarak çizmiştik: SI → UME → akredite lab → cihaz. Aslında bu akış bir piramidin yan kesiti. Tepede bir avuç birincil standart var; tabanda dünyadaki milyonlarca ölçüm cihazı.

Piramidi okumanın iki yolu var. Yukarıdan aşağı baktığınızda her seviyede belirsizlik artar, maliyet düşer, erişim genişler. Aşağıdan yukarı baktığınızda her cihaz “bir üstündeki seviyenin daha hassas örneğine” karşı kalibre edilir. Bu mantığın doğal sonucu, en üstte de bir cihaz olması gerektiği — ve onun da bir başkasına karşı kalibre edilmesi gerektiği. Ama bir yerde durması lazım. Yoksa kalibrasyon kavramının kendisi anlamsız.

Piramidin her seviyesinde belirsizlik yaklaşık bir mertebe (10×) artıyor. Bu rastlantı değil. Pratik bir kuraldır: referans cihazınız, kalibre edeceğiniz cihazdan en az dört kat daha iyi olmalı (TUR ≥ 4 kuralı, önceki yazıdaki Z540.3 sınırı). Üreticiler ve akredite laboratuvarlar piramidi bu kurala göre kurarlar; tipik aralık 4 ile 10 arasında değişir. Daha iyi olmak şart değil çünkü pahalı; ama 4’ün altına düşmek de pratik olarak kararı bozar.

“Kim Kalibre Eder?” Sorusunun Sonu

Şimdi denetçinin sorusuna geri dönelim. Piramitte hep yukarı çıkıyoruz: cihaz, kalibratör, transfer standardı, NMI’nin birincil standardı. Sonunda Seviye 1’e ulaşıyoruz. UME’deki sezyum fıskiyesi. Kibble terazisi. Josephson eklem dizisi. Bunları kim kalibre ediyor?

Yanıt iki kademede gelir.

İlk kademe pratiğin cevabıdır: kimse. Birincil standart başka bir cihaza karşı doğrulanmaz. Çünkü daha hassası yok. Eğer birinci sınıf bir Josephson voltaj standardından sapma görmek isterseniz, bunu görmenin tek yolu başka bir Josephson standardı ile karşılaştırmaktır. Bu da “kalibrasyon” değil, karşılaştırma olarak tanımlanır. (Bu konuya bölüm 6’da döneceğiz.)

İkinci kademe felsefenin cevabıdır: doğa yasaları. Modern birincil standartlar, başka bir cihazın değerlerine karşı değil, fiziğin sabit niceliklerine karşı tanımlanır. Sezyum fıskiyesinin doğru çalışıp çalışmadığını anlamanın yolu, ürettiği frekansın gerçekten sezyum-133 atomunun hiperince geçişine denk düşüp düşmediğine bakmaktır. Bu geçiş frekansı (Δν_Cs) ise tam tanım gereği 9 192 631 770 Hz’tir; SI saniyesi tam olarak böyle tanımlanmıştır.

Yani saat “kalibre” edilmez. Sayar. Saatin görevi sezyum-133 atomlarını gözlemleyip kaç hiperince geçiş geçtiğini saymaktır. Eğer 9 192 631 770 saymışsa, üzerinden 1 saniye geçmiş demektir. Tanım, fizik ve cihaz aynı şeyi söylüyor.

Tarih boyunca her zaman böyle değildi.

1889’dan 2019’a kadar kilogramın tanımı şöyleydi: “Uluslararası Kilogram Prototipi (IPK), Saint-Cloud’daki Pavillon de Breteuil’de (posta adresi: Sèvres) BIPM kasasında saklanan platin-iridyum silindirin kütlesi.” Yani dünyadaki bir tek gerçek 1 kg vardı; o silindir. Diğer her şey ona göre tanımlanmıştı. IPK günlük çalışma için kullanılmıyordu; yanında BIPM’in kendi yedekleri (témoin) ve bir avuç çalışma standardı vardı. Tarih boyunca yalnızca dört defa kasadan çıkarıldı — 1889 onayı ve üç doğrulama kampanyası (1939-46, 1989-92, 2014). Bu kampanyalarda BIPM yedekleri ve ülkelerin ulusal prototipleri (K20, K54…) IPK ile karşılaştırıldı. IPK’nın kendisinin bir kalibrasyonu yoktu — o, kalibrasyonun referansıydı.

Sorun şuydu: özellikle 1989-92 karşılaştırmasında, IPK ile resmi yedekleri arasında ortalama yaklaşık 50 µg‘lık bir farklılaşma raporlandı (yedeklerin çoğu IPK’ya göre kütle kazandı, ya da IPK kütle kaybetti). Yaklaşık bir asırlık değişim 50 mikrogram. Az gibi duruyor — ama önemli olan miktarı değil, ilkesi: eğer 1 kg’ın tanımı bu silindirse, silindir değişirse 1 kg da değişir. Mantık olarak silindirin yanlış olması mümkün değildi. Yanlış olan, dünyadaki diğer tüm 1 kg ölçümleriydi.

Bu durum, dünyanın en hassas ölçümlerini yapan kuruluşları rahatsız etti. Birim tanımı bir esere bağlıyken, eserin iyi durumda olup olmadığından asla emin olamazdınız.

16 Kasım 2018’de BIPM’in 26. Genel Konferansı (CGPM) çözümü oybirliğiyle kabul etti: SI birimleri artık eserlere değil, doğa sabitlerine bağlanacak. Planck sabiti tam değer atandı, belirsizlik sıfır. IPK emekli edildi. Aynı şey amper, kelvin ve mol için de yapıldı. Yeni tanımlar 20 Mayıs 2019’da — Metre Konvansiyonu’nun 144. yıl dönümünde, yani Dünya Metroloji Günü’nde — yürürlüğe girdi.

Bu, 130 yılın en büyük metroloji reformuydu. Ve şimdi zincirin tepesinde cihaz yok; fizik var.

Akılda kalsın — birincil standart kalibre edilmez: Bir sezyum fıskiyesini “şuna karşı kalibre ettik” diyemezsiniz. Sadece başka bir sezyum fıskiyesiyle karşılaştırırsınız. Anlaşmazlık olursa fizik konuşur, cihaz değil.

2019 Devrimi: Sabitler Tanımlanır, Birimler Türetilir

Reformun mantığı tek satırla şu: önceden birim tanımı belliydi, doğa sabiti ölçülürdü; şimdi doğa sabiti tanımlıdır, birim ölçülür.

Reformun yarım asrı bulan tarihsel dönüm noktaları:

Eski sistemde Planck sabitinin “ölçülmüş değeri” vardı, sürekli daha hassas ölçüm yapmaya çalışıyorduk. Yeni sistemde Planck sabiti tam olarak 6,626 070 15 × 10⁻³⁴ J·s. Belirsizlik sıfır, çünkü tanım böyle. Ölçtüğümüz şey artık Planck sabiti değil — kilogram. Yani Kibble terazisi, kilogramı Planck sabitinden ne kadar iyi gerçekleyebildiğimizi sınar.

Yedi tanımlayıcı sabit (defining constants):

Tablonun anlamı şu: bu yedi sayıyı doğa kanunu olarak kabul ediyoruz. Diğer her şey buradan türüyor. Saniye Δν_Cs’den, metre c × s’den, kilogram h’den, amper e’den, kelvin k’den… Dünyanın her yerinde aynı yedi sayı kullanılıyor; herkes aynı birime sahip.

Pratik bir test: bir Türk laboratuvarındaki 1 kg ile bir Alman laboratuvarındaki 1 kg birbirinden farklı olabilir mi? Eski sistemde evet — Türk silindiri Sèvres’deki orijinalden ne kadar farklılaştığına bağlı. Yeni sistemde hayır — her ikisi de aynı Planck sabitinden türetiliyor; en kötü ihtimalle gerçekleme cihazlarının belirsizliği kadar farklılık olur, sistematik bir kayma yok.

Akılda kalsın — gerçekleme (realization) ile kalibrasyonun farkı: Kalibrasyon, bir cihazın değerini üst seviyedeki başka bir cihaza göre düzeltmektir. Gerçekleme, bir cihazın değerini birim tanımına — yani fiziksel bir olguya — göre üretmektir. Birincil standart kalibre edilmez, birimi gerçekler.

Birincil Standartlar Yakın Plan

Sırayla altı birimin birincil gerçeklenişine bakalım. Her biri için soracağımız sorular: cihaz nedir, hangi sabite dayanır, tipik belirsizlik nedir, dünyada ve Türkiye’de kim çalıştırıyor.

Saniye: Sezyum Fıskiyesi ve Optik Saatler

SI tüm birimleri arasında en hassas tanımlananı saniyedir. Çünkü sezyum-133 atomunun hiperince geçişi, doğanın sunduğu en kararlı periyodik olgu sayılıyor.

İlk pratik sezyum atomik saati 1955’te NPL’de (İngiltere) Louis Essen ve Jack Parry tarafından yapıldı; sıcak bir fırından çıkan atom demetini frekans rezonansından geçiren bir düzendi, doğruluğu 1×10⁻⁹ mertebesindeydi. Sezyum fıskiyesi ise modern tasarım: atomlar lazerle soğutuluyor (mikrokelvin mertebesinde), yukarı doğru fırlatılıyor, yerçekimiyle aşağı düşüyor. Bu “fıskiye” geometrisi atomların rezonans bölgesinden iki kez geçmesini sağlıyor — birincide frekansı işaretliyor, ikincide kontrol ediyor. Daha uzun gözlem süresi, daha keskin rezonans, daha düşük belirsizlik.

Tipik kararlılıklar:

• 1955 NPL sezyum demet saati (Essen-Parry): ~10⁻⁹ (~30 yılda 1 s — yine de mekanik saatlerden bin kat daha iyi)
• Klasik sezyum demet saati (1990’lar): ~10⁻¹³ – 10⁻¹⁴
• Modern sezyum fıskiyesi (NIST-F1 hâlâ aktif, PTB-CSF1/CSF2): ~5×10⁻¹⁶ – 1×10⁻¹⁵
• En iyi optik latis saati (JILA/NIST stronsiyum, 2024): 8,1×10⁻¹⁹

10⁻¹⁶ kararlılık ne demek? Saat ~300 milyon yılda 1 saniye sapar demek. 8×10⁻¹⁹’un anlamı ise evrenin yaşının iki katı boyunca 1 saniyeden az sapma.

Sezyum saatinin doğruluğu yetmiş yılda yaklaşık 10 milyar kat iyileşti — bilim tarihinde belki de en büyük tek kuantitatif ilerleme:

Türkiye tarafında UME’nin Zaman ve Frekans Laboratuvarı 1994’ten beri BIPM’in koordine ettiği Uluslararası Atom Zamanı (TAI) ağına katkı sağlıyor. UME birincil standardı bir sezyum fıskiyesi değil, hidrojen maser (1 adet) + ticari sezyum atom saati ensemble’ı (5 adet) + GPS alıcılarından (2 adet) oluşan bir sistem. UTC(UME) zaman ölçeğinin belirsizliği 2×10⁻¹⁴’ün altında. UME ayrıca stronsiyum tabanlı optik latis saati projesini sürdürüyor; tamamlandığında Türkiye’nin zaman birimi gerçekleme doğruluğu 100 kattan fazla iyileşecek.

Optik saatler bir sonraki SI yeniden tanımının başında. CCTF (Time & Frequency Consultative Committee) yol haritası 2030’a kadar saniye tanımının optik geçişlere kaymasını öngörüyor. O zaman sezyum, kilogramın IPK silindiri gibi tarihe karışacak.

Metre: Saniyeden Türeyen Mesafe

Metre tanımı 1983’ten beri şudur: vakumda ışığın 1/299 792 458 saniyede aldığı yol. Yani metreyi gerçekleme problemi, ışık hızı ile bağlanmış bir frekans/zaman ölçme problemine indirgenir.

Pratikte metre, stabilize edilmiş lazerlerle gerçeklenir:

• 633 nm iyot-stabilize He-Ne lazer (BIPM önerilen liste, ~10⁻¹¹ kararlılık)
• 532 nm iyot-stabilize Nd:YAG lazer
• 1542 nm asetilen-stabilize lazer (telekomünikasyon dalga boyu)

Bu lazerlerin frekansı sezyum saatine karşı sayılır (frekans tarağı/optik kombinasyon teknolojisi); böylece metre dolaylı olarak sezyumdan geliyor. Boy ölçümü ⇒ frekans ölçümü ⇒ saniye standardı ⇒ sezyum.

UME’de uzunluk laboratuvarı 633 nm iyot-stabilize HeNe lazerle çalışıyor; mekanik mihenkleri, blok mihenklerini, koordinat ölçüm cihazlarını bu lazerden türetilen interferometrik ölçümlerle kalibre ediyor.

Kilogram: Kibble Terazisi ve Planck Sabiti

Reformun en dramatik tarafı kilogramda. 130 yıl boyunca kütle birimini Saint-Cloud’daki bir silindir tanımlıyordu. 20 Mayıs 2019’dan itibaren tanım şu: kilogram, Planck sabiti tam değerinden Kibble terazisi (veya eşdeğer yöntem) ile gerçeklenen kütledir.

Kibble terazisi (eskiden “watt terazisi”, Haziran 2016’da mucidi Bryan Kibble [1938-2016] anısına CCU kararıyla yeniden adlandırıldı) iki aşamada çalışır:

İki fazın püf noktası: tek başına B·L (manyetik alan × bobin uzunluğu) çarpımı çok hassas ölçülemez. Ama tartma fazında B·L = m·g/I ve hareket fazında B·L = V/v aynı çarpımdır; iki ifadeyi eşitlediğinizde B·L tamamen sadeleşir. Geriye kalan m·g·v = V·I ilişkisi, kütleyi yerçekimi ivmesi (g, mutlak gravimetrelerle ölçülür), hız (v, lazer interferometre), voltaj (V, Josephson) ve akım (I, kuantum Hall direnciyle ölçülen voltaj farkından) cinsinden verir. Sonuç: m doğrudan Planck sabitine bağlanır.

Kibble terazileri NIST-4 (ABD), NRC (Kanada), BIPM (Fransa), PTB (Almanya), NIM (Çin), KRISS (Güney Kore), LNE (Fransa) tarafından çalıştırılıyor. Tipik bağıl belirsizlikler 10⁻⁸ mertebesinde.

Türkiye tarafı: UME, Kibble terazisi geliştirmesini 2014’te başlattı; ülke için kilogramın salınımlı mıknatıs (oscillating magnet) tipi Kibble terazisiyle gerçeklenmesi yolunu seçti. Bu tasarımda mıknatıs hareketsiz kütleyle birlikte titrer; sinyal frekans alanında okunur. Yayımlanan ön ölçümlerde 1 kg paslanmaz çelik artefakt 54 ppb (yaklaşık ±54 µg) bağıl belirsizlikle ölçüldü; aynı düzenekle Planck sabiti 6 ppm bağıl standart belirsizlikle elde edildi. Günlük kalibrasyon hizmeti hâlâ BIPM kalibrasyonlu transfer kilogram referansı üzerinden veriliyor; Kibble teraziyle gerçekleme tam üretim seviyesine geçildiğinde devreye alınacak.

Alternatif yöntem: Avogadro projesi veya X-ışını kristal yoğunluk (XRCD) yöntemi. Hassas işlenmiş tek kristal silisyum küresinin atom sayısı X-ışını difraksiyonu ile sayılıyor; N_A tam değer olduğundan kütle hesaplanıyor. Almanya’daki PTB bu yöntemin başlıca yürütücüsü; uluslararası IAC (International Avogadro Coordination) konsorsiyumunda LNE, NMIJ, INRIM, NIST de var. 2019’daki ilk uluslararası kg karşılaştırmasında (CCM.M-K8.2019) Kibble terazisi sonuçları XRCD sonuçlarıyla iyi tutarlılık gösterdi.

Volt: Josephson Eklem Dizileri

Süperiletken bir eklemden geçen elektronlar, eklem mikrodalga ile ışınlandığında kuantize voltaj basamakları üretir:

V_n = n · f / K_J
K_J = 2e / h  (Josephson sabiti)

n tam sayı (basamak numarası), f mikrodalga frekansı (sezyum saatten gelir), K_J ise temel sabitlerden türeyen tam bir sayı. Yani V tamamen sayılan bir frekansa bağlı; sıvı helyum sıcaklığında (4 K) eklem doğru çalıştığı sürece, voltaj doğa kanunu kadar kararlı.

Pratik cihaz: Programlanabilir Josephson Voltaj Standardı (PJVS). On binlerce eklemin diziliminde dijital olarak basamak seçilebiliyor; istenen voltaj (0 – 10 V arası) belirleniyor. Tipik belirsizlik 1 part in 10⁹ — yani 10 V’ta ~0,01 µV.

Cihaz kullanışlı ama maliyetli ve karmaşık altyapı gerektiriyor: ya sıvı helyum (geleneksel) ya da kapalı çevrim cryocooler (modern, tercih edilen) ile 4 K civarına soğutma, hassas mikrodalga jeneratörü, manyetik ekranlama, geri besleme elektroniği. Bu nedenle PJVS dünyada büyük ölçüde NMI’lerde ve birkaç askeri/araştırma laboratuvarında bulunuyor; sıvı helyum tedariğinde dünya çapındaki sıkıntılar son yıllarda cryocooler tabanlı sistemlere geçişi hızlandırdı. UME’de DC Voltaj Laboratuvarı Josephson tabanlı sistemiyle hizmet veriyor; Türkiye’deki akredite kalibrasyon laboratuvarları DC voltaj izlenebilirliklerini buradan alıyor.

Dünyada NIST, PTB, NPL, BIPM, NMIJ, KRISS, NMIA başta olmak üzere pek çok NMI PJVS işletiyor. Bunların hepsi BIPM’in koordine ettiği sürekli karşılaştırmalara katılıyor (BIPM.EM-K10 DC voltaj Josephson karşılaştırması; bağlı olarak BIPM.EM-K11 ile 1,018 V ve 10 V Zener referans karşılaştırmaları).

Ohm: Kuantum Hall Etkisi

İki boyutlu elektron gazına sahip bir GaAs/AlGaAs yarı iletkeni 1,5 K sıcaklıkta ve 10 T manyetik alan altında ölçtüğünüzde, Hall direnci sürekli değil kuantize değerler alır:

R_H = R_K / i
R_K = h / e²  (von Klitzing sabiti)
R_K = 25 812,807 45 Ω  (tam değer, h ve e tam olduğundan)

i tam sayı (Landau seviyesi numarası, tipik olarak 1, 2, 3, 4); R_K von Klitzing sabiti, hidrojenden tutun da galaktik bulutlara kadar her yerde aynı.

i=2 platosunda direnç tam olarak 12 906,403 725 Ω — laboratuvarda hiç direnç telini ölçmeden, sadece manyetik alan ve sıcaklık doğru ayarlandığında. Bu plato genişliği yeterince büyükse (manyetik alan birkaç tesla aralığında), direnç değerinin kararlılığı 10⁻⁹ mertebesinde.

UME’de Kuantum Hall laboratuvarı 2010’lardan beri çalışıyor. Türkiye’deki tüm DC direnç ölçümlerinin tepe noktası burası. Direnç laboratuvarları periyodik olarak ESI SR104 veya benzeri 10 kΩ standart dirençlerini UME’ye gönderir; UME bunları kuantum Hall ile karşılaştırır, sertifikayla geri verir.

Josephson + kuantum Hall kombinasyonunun önemli bir yan etkisi var: ikisi birlikte kullanıldığında akım ve güç de doğrudan h ve e cinsinden ölçülebilir. Kibble terazisinin işleyişi tam olarak bu birlikteliğe dayanıyor. Aynı laboratuvar üç temel elektriksel birimi (V, Ω, A) ortak fizikten türetir.

Kelvin: Boltzmann’dan Pratik Sıcaklığa

Sıcaklık biraz farklı bir hikâye. 2019 reformunda kelvin tanımı Boltzmann sabitine bağlandı:

T = E / k  (E enerji, k Boltzmann sabiti)

Termodinamik sıcaklık ilkesel olarak ya akustik gaz termometresi (gaz içindeki ses hızı T’ye bağlı) ya da Johnson gürültüsü termometresi (bir direnç üzerinde termal gürültünün gücü T’ye bağlı) ile ölçülür. Bu yöntemler temel; ama günlük kalibrasyon için pratik değil — saatlerce ölçüm gerektiriyorlar.

Pratik dünyada kelvin ITS-90 (International Temperature Scale 1990) ile gerçeklenir. ITS-90, 0,65 K’den 1357 K’ye kadar sıcaklık aralığını 17 sabit faz geçişi ile etiketler:

Suyun üçlü noktası en kritiği: özel olarak hazırlanmış cam hücrelerde (TPW cell, triple point of water) buz, sıvı ve buhar dengede; sıcaklık tam olarak 273,16 K. Bu hücreler dünyada birkaç laboratuvarda üretilir; UME’nin de kendi TPW hücreleri var.

Sıcaklık piramidi şöyle çalışıyor: SI tanımı (Boltzmann) ile birincil termometreler (akustik gaz/Johnson gürültüsü) ITS-90 sabit noktalarını doğrular; UME bu sabit noktaları muhafaza eder; akredite laboratuvarlar UME’den izlenebilirlik alır; sanayi termometreleri akredite laboratuvarlardan kalibre olur. Sıradan bir PT100 sensörünün kalibrasyon belgesindeki belirsizlik, son tahlilde Boltzmann sabitine ve ITS-90 hücrelerine bağlanır.

Akılda kalsın — birincil ile pratik aynı şey değil: Kelvin SI’da Boltzmann üzerinden tanımlı, ama dünyada hiçbir kalibrasyon laboratuvarı doğrudan akustik gaz termometresi kullanmaz. Pratik referans ITS-90’dır. Tanım fiziksel, gerçekleme tarihsel ve pratik. İkisi arasındaki tutarlılığı NMI’ler üst düzey karşılaştırmalarla kontrol eder.

Birincil Gerçeklemelerin Karşılaştırması

Yedi SI temel biriminin en iyi gerçekleme belirsizlikleri arasında 15 mertebelik bir uçurum var. Saniye en hassas, kandela en kaba. Bu fark hem tarihsel hem de fiziksel: bazı olgular daha kararlı, bazılarını ölçmek daha zor.

Grafiği okumak: saniye gerçeklemesi 10¹⁵ kat daha hassas (8×10⁻¹⁹) iken kandelanın gerçeklemesi 10⁻⁴ mertebesinde. Bu, kandelanın “kötü” tanımlanması demek değil — fiziksel olgu (insan gözünün spektral duyarlılığı) doğası gereği belirsiz. Saniye ise atomik geçişe dayanıyor; daha kararlı bir olgu yok.

Pratik sonuç: bir test mühendisi için frekans ölçümü daima en güvenilir; sıcaklık ve aydınlatma ölçümleri en kaba. Belirsizlik bütçenizde bu mertebe farkı yansır.

Uluslararası Karşılaştırmalar (CIPM MRA)

Diyelim UME’nin Josephson voltaj standardı 10 V’ta 0,01 µV belirsizlik beyan ediyor. Bunun gerçekten doğru olduğunu nasıl biliyoruz? Hiçbir cihaza karşı kalibre etmediğimize göre — peki yanılıyor olabilir mi? Mesela laboratuvarın mikrodalga jeneratörü kalibrasyondan kaymış, ekleme yanlış frekans gönderiyor olabilir mi?

Bu olasılığı sıfırlamanın tek yolu uluslararası karşılaştırma. Aynı 10 V’u dünyanın farklı bir laboratuvarında, bağımsız bir Josephson sisteminde de üretip iki sonucu karşılaştırırsanız, ikisinin tutarlı olması (beyan edilen belirsizliklerin altında) sistemin sağlıklı çalıştığının kanıtıdır.

Bu süreç CIPM MRA (Mutual Recognition Arrangement) çatısı altında yürütülür. 14 Ekim 1999’da Paris’te 38 üye devletin NMI direktörleri ve iki uluslararası kuruluş tarafından imzalanan MRA, üye ülkelerin metroloji enstitülerinin birbirinin sertifikalarını karşılıklı tanımasını sağlar. Türkiye TÜBİTAK UME aracılığıyla 1999 kuruluş imzacılarından biri. Bugün 62 üye devlet, 40 ortak ve 4 uluslararası kuruluşu, toplam 250’yi aşkın enstitüyü kapsıyor. MRA’nın iki ayağı var: Anahtar Karşılaştırmalar (Key Comparisons) ve CMC kayıtları.

Akış şöyle: BIPM bir karşılaştırma planlar, pilot laboratuvar atar. Pilot, bir transfer standardını (örneğin Fluke 7000 zener voltaj referansı, 1 kg paslanmaz çelik kütle, 100 Ω resistör) hazırlar ve katılımcı NMI’lere gönderir. Her NMI standardı kendi birincil sistemine karşı ölçer ve sonucu raporlar. Pilot, sonuçları toplar; ağırlıklı ortalamadan referans değeri (KCRV — Key Comparison Reference Value) hesaplar; her NMI için sapmayı (D_i) yayınlar. Tüm sonuçlar KCDB açık veritabanında saklanır.

Karşılaştırmaların adlandırması: koordinatör kuruluşun kodu + alanı belirten alt komite + sıra numarası. Birkaç tipik örnek:

Her NMI’nin verdiği değerin belirsizlik bütçesini aşacak şekilde sapması, problem işaretidir. Örnek olarak 2021-2022’de yapılan CCT-K7.2021 karşılaştırmasında, 21 katılımcı NMI’nin TPW gerçeklemeleri arasındaki maksimum fark 111 µK, standart sapma 28 µK olarak rapor edildi — yani uluslararası sıcaklık ölçeğinin koordinasyonu sub-mK seviyesinde tutarlı. Eğer bir NMI 1 mK saparsa, hücreleri yeniden değerlendirilir, kapsamı revize edilir, sertifikalardaki belirsizlik artar.

Karşılaştırmaların ikinci ürünü CMC (Calibration and Measurement Capability) beyanları. CMC, bir NMI’nin sunduğu rutin kalibrasyon hizmeti için beyan edilebilir en iyi belirsizliği ifade eder. Akran değerlendirmesinden geçer, KCDB’de yayınlanır. Türk sanayicisi UME’den hangi alanda hangi belirsizlikle hizmet alabileceğini buradan görür; aynı sayfada NIST veya PTB’nin aynı kapsamı görür ve karşılaştırır.

Akılda kalsın — birincil standart kontrolü iki katmanlıdır: İçsel olarak fiziksel sabite bağlanır (gerçekleme), dışsal olarak başka NMI’lerin gerçeklemeleriyle karşılaştırılır (KC). Tek katmandan biri kaymışsa diğer katmandan yakalanır.

TÜBİTAK UME ve Türkiye’nin Birincil Standartları

UME, 11 Ocak 1992’de TÜBİTAK Marmara Araştırma Merkezi bünyesinde, Gebze’de kuruldu. Bugün çok sayıda laboratuvarda zaman/frekans, elektriksel, kütle, uzunluk, sıcaklık, basınç, kuvvet, akustik, fotometri ve iyonlaştırıcı radyasyon alanlarında birincil standart işletiyor.

Yaklaşık başlık başlık birincil yetenekler (kesin değerler için KCDB’ye bakılmalı):

UME’nin KCDB’deki CMC kayıtları herkese açık. Türk akredite kalibrasyon laboratuvarları (TÜRKAK belgesi alanlar) UME’den izlenebilirlik alır; akredite olmayan iç laboratuvarlar (örneğin bir fabrikanın kalite kontrol bölümü) ya doğrudan UME’ye giderler ya da bir akredite labdan hizmet alırlar.

Aviyonik ve savunmada tipik bir akış şöyle olur. TUSAS’ın bir uçak gövdesinde kullandığı PT100 sıcaklık sensörü, üretici dokümanına göre 6 ayda bir kalibre edilmeli. TUSAS bunu TÜRKAK akredite bir kalibrasyon laboratuvarına gönderir; lab kendi referans termometresini (genelde ikinci sınıf Standart Platin Direnç Termometresi, SPRT) kullanarak fırın içinde sensörü doğrular. O lab kendi SPRT’sini her 1-2 yılda UME’ye gönderir; UME ITS-90 sabit noktalarında SPRT’yi karakterize eder. UME’nin sabit nokta hücreleri belirli aralıklarla CCT-K7, CCT-K9 anahtar karşılaştırmalarına katılır — yani başka NMI’lerin TPW hücreleriyle, başka galyum-erime hücreleriyle çapraz kontrol edilir.

Bu zincirin yedi halkası var: Boltzmann sabiti → ITS-90 → UME hücreleri → SPRT → akredite lab → PT100 → uçak. Her halka bir kalibrasyon belgesi, bir izlenebilirlik kanıtı taşır. Ucundaki sayı (uçaktaki PT100’ün okuduğu sıcaklık) ancak zincir baştan sona sağlamsa anlamlı.

Belirsizlik Piramidi: Yukarıdan Aşağıya

Önceki yazıda u_birleşik kavramını tanıttık: birden çok belirsizlik kaynağının karekök kareler toplamı. İzlenebilirlik zincirinin her aktarımı, mevcut belirsizliğin üzerine yeni bir katkı ekler. Tipik bir DC voltaj zincirinde aşağıdaki gibi büyür:

Her seviyede bağıl belirsizlik yaklaşık 10× kötüleşiyor. Bu pratik bir sonuç değil, kalibrasyon sürecinin doğasından geliyor: her aktarımda transfer cihazının kendi katkısı, ortam etkileri (sıcaklık, nem, EMG), operatör katkısı, kabloların direnci eklenir. Üç-dört katkıyı kareli toplamla birleştirdiğinizde sonuç yaklaşık on kat artar.

Grafikten çıkan ders şu: alttaki cihazınızın belirsizliği üstteki halkaların belirsizliklerine bağımlıdır. Multimetreyle 50 ppm okuyabiliyorsanız, kalibratörünüz 5 ppm sunuyor olmalı; kalibratörünüzü kalibre eden lab 0,5 ppm sunmalı; o labın referansı 5 ppb olmalı. Dört halka. Birinde sorun varsa, sayısal değer altta düzgün okunsa bile anlamı yok.

Bunun pratik karşılığı: kalibrasyon sertifikasında “UME izlenebilirliği” yazsa bile zincirde halka eksikse (bir halkadaki cihazın geçerli akreditasyonu yoksa, ya da belge süresi geçmişse) tüm zincir geçersiz. Akreditasyon denetiminde ilk sorulan sorular tam olarak bunu test eder.

Akılda kalsın — TUR’unuz sizinle değil zincirinizle başlar: Multimetrenizle 50 ppm okuyabilmek için zincirin tepesinde 5 ppb belirsizlikli bir Josephson sistemine ihtiyacınız var. Aradaki halkalardan biri kayarsa hepsi etkilenir. Belirsizlik bütçenizdeki “sertifika belirsizliği” tek satırı, aslında tüm üst zincirin damıtılmış halidir.

Kalibrasyon Sertifikasından İzlenebilirlik Çıkarımı

Önceki yazıda akreditasyon denetiminde sorulanlar listesi vermiştik. Bu yazının pratik sonucu olarak listeyi izlenebilirlik tarafına genişletelim. Eline kalibrasyon sertifikası geldiğinde test mühendisinin sorması gereken sorular:

• Sertifikayı veren laboratuvar akredite mi? TÜRKAK numarası (örn. AB-0001-K) veya muadil bir ILAC üyesi akreditasyon kuruluşu numarası olmalı. Akreditasyon kapsam belgesi sorularak doğrulanır; ölçüm büyüklüğünüzün kapsamda olduğundan emin olun.
• Kullanılan üst kademe ekipmanın seri numarası belirtilmiş mi? “Fluke 5720A, S/N 9876543” gibi. Bu olmadan zincir kanıtlanamaz.
• Üst kademe ekipmanın bir önceki kalibrasyonunun belge numarası ve tarihi yazılmış mı? “Reference instrument: UME ID K-2024-…” şeklinde. Sertifika tarihiniz, üst kademe sertifikanın geçerlilik süresi içinde olmalı.
• Beyan edilen belirsizlik U + k + PDF varsayımı içeriyor mu? “U = 28 µV, k=2, normal dağılım” yeterli; sadece “± 28 µV” yetersiz.
• TUR ≥ 4 sağlanıyor mu? Cihazınızın spec’i ile sertifika belirsizliği oranı 4’ün altındaysa, kabul/red kararı için güvenlik payı (guard band) hesaplanmalı.
• Çevre koşulları belgelenmiş mi? Sertifika ölçüm sırasındaki sıcaklık (genelde 23 ± 2 °C) ve nem değerlerini içermeli. Sizin laboratuvarınızda koşullar farklıysa düzeltme veya ek belirsizlik gerekir.
• Süre sonu belirtilmiş mi? “Geçerlilik 1 yıl”, “kalibrasyon aralığı kullanıcı sorumluluğunda” vb. ayrımına dikkat edin.
• Izlenebilirlik beyanı genel mi yoksa NMI numarasıyla mı? “Traceable to SI through UME via … “ spesifikse iyi; sadece “Traceable to NIST/UME” cümlesi tek başına yeterli kanıt değil.

Bu sekiz madde aslında zincirin her halkasını sorgulayan tek bir kontrol listesi. Bir tanesi cevapsız kalıyorsa zincirde kopukluk var demektir; bu durumda kalibrasyon sertifikası işinize yaramaz.

Sonuç

“Saatçinin saatini kim kalibre eder?” sorusunun cevabı — biraz şaşırtıcı bir biçimde — kimse. Zincirin tepesinde bir cihaz değil, bir doğa kanunu var. Sezyum fıskiyesi, Kibble terazisi, Josephson eklem dizisi, kuantum Hall örnekleri başka bir cihaza karşı kalibre edilmez; doğrudan fiziksel sabitleri gerçekler. 2019 SI yeniden tanımı bu fikri tüm temel birimlere taşıdı: artık bir kilogram bile bir parçaya değil, Planck sabitine bağlı.

Birincil standartların kendi içlerindeki tutarlılığı uluslararası karşılaştırmalar garanti ediyor. CIPM MRA çatısı altında BIPM koordinasyonunda yürütülen anahtar karşılaştırmalar (KC), her NMI’nin gerçeklemesini diğerleriyle düzenli olarak çapraz kontrol ediyor; sonuçlar KCDB’de açık. UME bu sürecin aktif bir parçası — Türk sanayisi ve test mühendisi, UME üzerinden dünya birincil standart sistemine bağlı.

Bir test mühendisi için pratik mesaj kalın çizgilerle şu: kalibrasyon sertifikanızı sadece imzalı bir kâğıt olarak değil, bir zincir kanıtı olarak okuyun. Halkaları sayın. Eksik halka varsa “geçti/kaldı” kararınızın altında imzanız var, onun altında da sizin doğruladığınızı varsaydığınız zincir. Zincir kopuksa karar da kopuktur.

Önceki yazıda söz verdiğimiz Monte Carlo simülasyonu yazısı hâlâ yolda. Doğrusal olmayan ölçüm modellerinde GUM’un karekök kareler toplam yaklaşımı yetersiz kalıyor; bilgisayarda 100 000 simülasyon yaparak dağılımı doğrudan üretmek gerekiyor. Bir sonraki yazıda RP-12 Ek B’nin uygulamalı versiyonunu yazacağız — önceki yazıdaki üç örneği Monte Carlo ile yeniden çözeceğiz, sonuçları klasik GUM hesabıyla karşılaştıracağız.

Kaynaklar

• BIPM — SI Brochure (9. baskı, 2019)
• BIPM — Resolution 1 of the 26th CGPM (2018) — SI yeniden tanımı
• BIPM — CIPM MRA ana sayfası
• BIPM — KCDB (Key Comparison Database)
• BIPM — Kibble balance ana sayfası
• NIST — SI Yeniden Tanımı (2019) genel sayfası
• NIST — “How Atomic Clocks Work” (sezyum fıskiyesi açıklaması)
• NIST — NIST-4 Kibble Balance proje sayfası
• NPL — “What is the SI?” eğitim sayfası
• NPL — Bryan Kibble biyografi
• PTB — Atomic Fountain Clock CSF1 ve CSF2
• Stock, M. — “The Watt or Kibble Balance: a Technique for Implementing the New SI Definition of the Unit of Mass”, Metrologia 53 (2016)
• BIPM — ITS-90 Defining Document
• Ahmedov H. ve ark. — “A UME Kibble Balance Displacement Measurement Procedure” (UME Kibble terazisi)
• TÜBİTAK UME — Zaman ve Frekans Laboratuvarı
• TÜBİTAK UME — Ulusal Metroloji Enstitüsü ana sayfası
• TÜRKAK — Akreditasyon Kapsam Sorgulama
• ILAC — Uluslararası Laboratuvar Akreditasyonu Birliği
• JILA — Optik Latis Saat Çalışmaları (Ye Lab)
• Wikipedia — 2019 redefinition of the SI base units (özet)

Test laboratuvarındaki ilk gününüz. Önünüzdeki multimetre 24,98 V gösteriyor. Test belgesi diyor ki: cihazın çıkışı 24 V ± 1 V olmalı. Yan masadaki kıdemli mühendis formun üstüne büyük harflerle “GEÇTİ” yazıyor. Doğru değer 24,98 V. Sınırın çok içinde. Tamam.

Ama dur. O ekrandaki 24,98 sayısı ne kadar gerçeği yansıtıyor? Multimetre dün kalibre edildi. Kabloların kendi direnci var. Oda sıcaklığı sabah 21 °C iken öğleden sonra 25 °C oldu. Bakır konnektörlerde küçük gerilimler oluşuyor. Bunların hepsi, ekrandaki sayının yanına bir hata payı ekliyor. Eğer bu pay 5 mV ise sorun yok. Ama ya 1,5 V ise? O zaman cihaz gerçekte 23,5 V ya da 26,5 V çıkış veriyor olabilir. Sınırın dışında, yani aslında geçmemiş.

İşte bu hata payına ölçüm belirsizliği diyoruz. Bu yazının amacı, belirsizliği nasıl hesapladığınızı sıfırdan anlatmak. İki uluslararası kılavuza dayanacağız. Birincisi GUM (Türkçe açılımıyla “Ölçüm Belirsizliğinin İfadesi Kılavuzu”), uluslararası referans. İkincisi NCSLI RP-12, ABD kalibrasyon mühendislerinin yazdığı pratik el kitabı. Üç gerçek örnek üzerinden hesabı tamamlayacağız: bir voltmetre, bir sıcaklık sensörü, bir basınç sensörü. Sonra aviyonik UUT üreticisi bir şirketin neden farklı bir disiplinle çalışması gerektiğini somut bir VOR/ILS alıcısı örneği üzerinden inceleyeceğiz. Sayılar gerçek, formüller gerçek; dil olabildiğince sade.

Bu Belgeler Nereden Çıktı?

Ölçüm belirsizliği bilimi yaklaşık 50 yıllık. Aşağıdaki zaman çizelgesi ana adımları gösteriyor.

1970’lerde dünyada ölçüm yapan büyük kurumlar — Amerika’da NIST, İngiltere’de NPL, Almanya’da PTB, Fransa’da BIPM — ortak bir derde sahipti. Hepsi aynı miktarı ölçüyordu (1 metrenin uzunluğu, 1 kilogramın ağırlığı), ama her biri farklı şekilde rapor ediyordu. Kimi “± 0,1 mm” yazıyordu, kimi “%95 güvenle 0,15 mm”. Sonuçları karşılaştırmak çok zordu.

1977’de uluslararası ağırlıklar ve ölçümler komitesi CIPM, alt birimi olan BIPM’den bu sorunu çözmesini istedi. BIPM, 1980’de 11 ulusal metroloji laboratuvarından uzmanları bir araya getirdi ve “Belirsizlik Beyanı Çalışma Grubu” toplandı. Çalışma grubunun çıkardığı INC-1 (1980) kararı, bugün hâlâ kullandığımız iki kavramı tanımladı:

• Tip A belirsizlik: Aynı ölçümü defalarca yaparak, çıkan sayıların ne kadar dağıldığına bakarak hesaplanan belirsizlik. Örneğin cihazı 10 kez ölçüp standart sapmayı hesaplamak.
• Tip B belirsizlik: Tekrarlı ölçüm dışındaki her bilgi. Kalibrasyon belgesi, üretici kataloğu, geçmiş deneyim.

13 yıl sonra, 1993’te bu fikirler genişletildi ve uluslararası dört kuruluş (ISO, IEC, OIML, BIPM) ortak bir el kitabı yayımladı: GUM. 2008’de küçük düzeltmelerle yeniden basıldı, bugün JCGM 100:2008 adıyla kullanılıyor. Sonra ek belgeler geldi: JCGM 101 (Monte Carlo simülasyonu ile belirsizlik hesabı, 2008), JCGM 102 (birden fazla sonuç veren ölçümler, 2011), JCGM 106 (uyum kararı, 2012).

Amerika tarafında NCSL International kalibrasyon mühendislerinin oluşturduğu bir dernek. 1995’te ilk RP-12 belgesini yayımladılar, 2013’te tamamen yeniden yazdılar. RP-12, GUM’un akademik dilini günlük kalibrasyon laboratuvarının diline çevirir. Yanına 2006’da yayımlanan ANSI Z540.3 standardı kalibrasyon laboratuvarları için bağlayıcı kurallar getirir.

Türkiye’de TÜBİTAK UME (Ulusal Metroloji Enstitüsü) ulusal ölçüm referanslarını korur. TÜRKAK kalibrasyon laboratuvarlarına akreditasyon verir. Aldığınız kalibrasyon belgesinin doğruluğu, bu zincirden geçerek Paris’in batısındaki Sèvres ilçesinde bulunan BIPM merkezine ve oradan da SI birim tanımlarına bağlanır. Bu bağlantıya izlenebilirlik deniyor.

İzlenebilirlik zinciri görsel olarak şu şekilde:

Her okun başında ve sonunda bir belirsizlik kazanımı olur. SI tanımlarındaki belirsizlik atomik mertebede sıfıra yakındır. UME’nin referansları nano düzeyde belirsizlik taşır. Akredite laboratuvarın belirsizliği biraz daha büyük, sizin cihazınızın daha da. Ürün ölçümünüzün belirsizliği zincirin son halkası — ve eğer zincirde kopukluk varsa (mesela “akredite olmayan bir laboratuvarda kalibre ettirdik”) tüm zincir geçersiz olur.

Belirsizlik Nedir? Birkaç Temel Kavram

Önce küçük bir sözlük. Bu kavramları sık karıştırırız:

Doğruluk ve kesinlik birbirinden bağımsız iki şey. Bir cihaz çok doğru ama az kesin olabilir, ya da çok kesin ama doğru olmayabilir. Bunu anlatmanın en kolay yolu nişan tahtasıdır. Aşağıda dört durum var: her tahtada beş atış var; merkez gerçek değer, atışlar ölçümler.

İdeal durum tabii ki sol üst: hem doğru hem kesin. Sağ üst tehlikeli; cihaz çok kesin ölçüm yapıyor (atışlar bir arada) ama hep yanlış yönde sapıyor. Sapma (bias) dediğimiz durum bu. Sağ alt durumda atışlar merkezi etrafına yığılmış ama dağınık; ortalamasını alırsak doğru cevaba ulaşırız. Kalibrasyon ve belirsizlik analizinin işi, bu dört durumdan hangisinde olduğumuzu bulup uygun şekilde raporlamaktır.

Belirsizliği iki adımda hesaplıyoruz. Önce her bir kaynağı standart belirsizlik denilen bir sayıya dönüştürüyoruz (1 sigmaya, yani normal dağılımın bir standart sapmasına denk düşen değer). Sonra hepsini birleştirip birleşik belirsizlik elde ediyoruz. Birleştirme yöntemi şu: her bileşeni karesel olarak topla, sonra karekökünü al. Buna “karekök kareler toplamı” diyelim, kısaltılmışı KKT (İngilizce literatürde RSS).

u_birleşik² = u_1² + u_2² + u_3² + ...
u_birleşik = √(u_1² + u_2² + u_3² + ...)

Neden böyle topluyoruz? Çünkü farklı kaynaklardan gelen küçük rastlantısal hatalar, doğrudan toplanmaz; istatistik kuralı gereği kareleri toplanır. İki adet ±1 mm hata yan yana geldiğinde sonuç ±2 mm değil, ±1,4 mm olur (√2 ≈ 1,41).

Son olarak, kapsama faktörü denilen bir sayı (genelde k=2) ile çarparak genişletilmiş belirsizliği elde ederiz. k=2, yaklaşık olarak %95 güven düzeyine karşılık gelir. Yani “U=56 µV (k=2)” demek, “gerçek değer büyük olasılıkla ölçtüğümüz sayının 56 µV içinde” demek.

Akılda kalsın — üç temel formül:

• Standart belirsizlik: her bileşeni 1σ’a çevir (Tip A için s/√n; Tip B için aralığı dağılım faktörüne böl).
• Birleşik belirsizlik: u_birleşik = √(u₁² + u₂² + … + uₙ²)
• Genişletilmiş belirsizlik: U = k × u_birleşik (genelde k = 2, ≈ %95 güven)

Tip B belirsizlikleri standart belirsizliğe çevirirken bir varsayım yapmamız gerekir: dağılım nasıl dağılıyor? Üretici “±1 mV” diyorsa o aralığın içinde her değer eşit ihtimalli mi, yoksa orta yoğun mu? Üç tipik durum:

• Düz (üniform) dağılım: Aralık içinde her nokta eşit olası. Standart belirsizliği = a / √3.
• Üçgen dağılım: Orta nokta daha olası, kenarlar düşer. Standart belirsizliği = a / √6.
• Normal dağılım: Genelde sertifikadan gelir. k ile birlikte verilirse, standart belirsizlik = U / k.

Bilgi yoksa, en güvenli tercih düz dağılım varsaymaktır. Aşağıdaki grafik dört dağılım tipini yan yana gösteriyor; hepsinde aralık ±1 birim, ama içerideki olasılık şekli farklı.

U-shape dağılım sıcaklık dalgalanmaları gibi durumlarda görülür: termostatlı bir oda sıcaklığı çoğunlukla alt sınır veya üst sınıra yakın salınır, orta noktada nadir kalır. Klasik üç dağılım dışında ihtiyaç doğdukça başka dağılımlar da kullanılır.

Akılda kalsın — aralığı standart belirsizliğe çevirme:

Elinizde olan	Yapacağınız
Sertifika "U = … (k=2)" der	u = U / 2
Sertifika "U = … (k=3)" der	u = U / 3
Üretici "±a" der, ek bilgi yok	u = a / √3 *(düz/üniform)*
"Merkez yakını daha olası" notu var	u = a / √6 *(üçgen)*
Termostat dalgalanması, ±a sınırlı	u = a / √2 *(U-shape)*

Şüpheliyseniz düz dağılım seçin — en muhafazakâr olanı.

GUM Annex F: Pratik Uyarılar

GUM’un ana metni biraz akademik dilde yazılmış: integraller, kovaryans matrisleri. Yeni başlayan biri için zorlu bir okuma. Ama belgenin F eki (Annex F) bambaşka. Doğrudan ölçüm yapan mühendise sesleniyor, en sık yapılan yanlışları sıralıyor, çözüm öneriyor. Aşağıda en önemli yedi noktayı açıklayalım.

1. Tekrar ölçümleriniz gerçekten “rastgele” mi?

10 ölçüm aldınız, standart sapmasını hesapladınız, “Tip A belirsizlik = 5 mV” dediniz. Ama o 10 ölçüm sırasında oda sıcaklığı 1 °C arttı, kalibratör yavaşça kaymaya başladı, kablonun bağlantı noktasında küçük voltajlar birikti. Bu durumda standart sapma rastgele dalgalanmayı değil, sıralı bir gidişatı ölçer. GUM uyarısı: tekrar ölçümler arasında koşulları gerçekten yenileyin. Cihazı kapatıp açın, sıfırlayın, kabloyu temizleyin, ısıl dengelenmeyi bekleyin.

2. Ortalamanın belirsizliği ile tek ölçümün belirsizliği farklı şeyler.

10 ölçümün ortalamasının standart belirsizliği s/√10 olur. Yani standart sapmayı √10 ile bölersiniz. Ama gelecekte yapılacak tek bir ölçümün belirsizliği s’in kendisidir. Test prosedüründe gelecekte hep 10 kez ölçüp ortalama mı raporlayacaksınız, yoksa tek ölçüm mü? Birinciyse s/√10, ikinciyse s. Pek çok kişi bu ikisini karıştırır.

3. Birden fazla küçük örnek varsa havuzlayın.

Diyelim ki 10 farklı günde, her gün 5 ölçüm yapıyorsunuz. Toplam 50 ölçüm var ama her gün için ayrı bir standart sapma çıkıyor. Hangisini kullanacaksınız? GUM cevabı: hepsini “havuzlayın”. Şu formülle:

        Σ ν_i · s_i²
s² =  ──────────────
          Σ ν_i

Burada her grubun “serbestlik derecesi” ν_i = n_i − 1. Sonuç: tek bir küçük gruba göre çok daha güvenilir bir s. Ölçüm tekrarlanabilirliği çalışmalarının (R&R çalışmaları) matematiksel temeli budur.

4. Üreticinin verdiği değerleri olduğu gibi alın.

Tip B belirsizliği hesaplarken sık yapılan bir hata: “Üretici ±100 µV demiş ama ben yine de 200 µV koyayım, daha güvenli olsun.” Bu yanlış. Elinizdeki kanıt ne ise onu kullanın. Sertifika varsa sertifikadan, üretici belgesi varsa o belgeden, geçmiş ölçüm verisi varsa o veriden. Kendi sezginizle “biraz daha kötümser olalım” demek, sayıları güvenilmez yapar.

5. PDF varsayımı yargı gerektirir.

Üretici “±1%” diyorsa, içindeki dağılım nasıl? Üretici belirtmediyse düz dağılım varsayın. “Çoğunlukla orta yakınında çıkar” diye bir not varsa üçgen dağılım. Ama bu kararı belgenizde yazılı olarak gerekçelendirmelisiniz.

6. Bağımsızlık varsayımı çoğu zaman yanlıştır.

Birleşik belirsizlik formülü (“kareler toplamının karekökü”) sadece birbirinden bağımsız kaynaklar için geçerli. Eğer iki ölçüm aynı kalibratörden besleniyorsa, sertifikalarındaki belirsizlikler ilişkili demektir. Aynı operatör, aynı oda, aynı ortam koşulları… bunlar belirsizlikleri ilişkili kılar. İlişkili kaynakları “bağımsız” kabul edip topladığınızda, sonuç gerçeğin altında ya da üstünde çıkar. GUM bunun için ek bir terim ekler:

u² = Σ u_i² + 2 · Σ u_ij

İkinci terim, ilişkili kaynak çiftleri arasında pozitifse belirsizliği büyütür, negatifse küçültür.

7. Sertifika belirsizliklerinde gizli sıcaklık tuzağı

Bu özellikle test laboratuvarlarında sık görülen bir tuzak. Kalibrasyon belgesi diyor ki: “Cihazın belirsizliği ±28 µV (k=2)”. Sonra ayrıca “ölçümler 23 °C ± 1 °C odada yapıldı” notu var. Şimdi siz cihazı kendi laboratuvarınızda 23 °C ± 3 °C koşullarda kullanıyorsunuz. Cihazın sıcaklık katsayısı bilgisini kataloga bakıp ayrıca ekliyorsunuz.

Burada gizli bir çift sayma var. Cihazın 23 °C ± 1 °C aralığındaki davranışı zaten kalibrasyon belgesindeki ±28 µV içine girmiş. Siz “±3 °C” aralığını eklerken sadece fark olan ±2 °C’lik kısmı hesaba katmalısınız, tüm ±3 °C’yi değil. Aksi halde sıcaklık etkisini iki kez sayarsınız ve belirsizliği gerçeğin üstünde gösterirsiniz.

Bu yedi maddenin ortak fikri: Belirsizlik bir tahmin değil, bir hesap. Her seçiminizi (dağılım varsayımı, bağımsızlık kararı, hangi sertifika değerinin kullanıldığı) belgenizde yazılı tutun. Akreditasyon denetiminde her birinin gerekçesi sorulur.

“k=2 mi, k=3 mü?” Sorusu

Genişletilmiş belirsizliği hesaplarken k değerini seçmemiz gerekiyor. Çoğu uygulamada k=2 (yaklaşık %95 güven) standart. Bazı kritik uygulamalarda k=3 (yaklaşık %99 güven) tercih ediliyor. Ama ikisi arasında dikkat etmemiz gereken bir ayrıntı var.

k=2 yaklaşık %95’lik güven düzeyine sadece ölçüm sayısı yeterince çoksa karşılık geliyor. Eğer Tip A hesaplamasında az sayıda ölçüm yaptıysanız (örneğin sadece 5), istatistiksel dağılım normal değil Student-t dağılımı oluyor. Bu durumda k=2 yerine biraz daha büyük bir değer kullanmak gerekir.

Bu hesabı Welch-Satterthwaite formülü yapar:

                u_birleşik⁴
ν_etkin =  ──────────────────
              Σ (u_i⁴ / ν_i)

Buradaki ν_etkin “etkin serbestlik derecesi”. Tip A bileşeninin serbestlik derecesi n−1, Tip B bileşenleri için (sertifikadan veya katalog değerinden geldikleri için) genelde sonsuz kabul edilir. Etkin serbestlik derecesi yeterince büyükse (genelde 30’dan büyük) k=2 güvenle kullanılabilir. Daha küçükse Student-t tablosundan k değerini bakarsınız.

Pratik tavsiye: ölçümlerinizi en az 30 kere yapıyorsanız k=2 düşünmeyin bile, doğrudan kullanın. Daha az ölçüm yapıyorsanız etkin serbestlik derecesini hesaplayın. Hesabı kolaylaştıran bedava araçlar var; örneğin Amerika’nın NIST kurumunun yayımladığı “NIST Uncertainty Machine” web aracı bu hesabı tek tıkla yapar.

NCSLI RP-12: Pratik Bir El Kitabı

GUM size “ne yapmanız gerektiğini” söyler. NCSLI RP-12 ise “nasıl yaparsınız, hangi tabloları kullanırsınız, hangi şablonu doldurursunuz” sorusunu yanıtlar. 2013 baskısı NCSLI’nin Belirsizlik Analizi Komitesi tarafından yazıldı; komitenin başında belirsizlik analizinin önde gelen isimlerinden Howard Castrup (Integrated Sciences Group kurucusu, NCSLI Wildhack Ödülü 2002 sahibi) vardı.

RP-12’nin yapısı GUM’dan biraz farklı. GUM “Tip A vs Tip B” ayrımıyla giderken, RP-12 hata kaynaklarını günlük dile daha yakın gruplara ayırır:

• Sapma (bias): Cihazın gerçek değerden sürekli aynı yönde sapması.
• Rastgele: Ölçümden ölçüme sebepsiz dalgalanma.
• Kayma (drift): Zamanla yavaş değişme.
• Çevre: Sıcaklık, nem, EMG (elektromanyetik girişim).
• Operatör: Kim ölçtü.
• Yöntem: Hangi adımlarla ölçüldü.

Bu sınıflandırma, kalibrasyon laboratuvarı çalışanlarının kafasındaki gerçeğe daha yakın. Bir sorun bulduklarında “bu hangi kategoriden?” sorusuna kolay cevap verirler.

RP-12’de işine yarayacak özel bölümler:

• Üretici belgesinden belirsizlik çıkarmak: Hangi belge satırı hangi belirsizlik kaynağına karşılık geliyor; hangi durumlarda hangi PDF varsayılmalı.
• Aynı anda birden çok cihazı kalibre etmek: Kalibrasyon prosedürü tek bir referansla 10 cihazı doğruluyorsa, belirsizlik nasıl bölüştürülür.
• Düzeltilmemiş sapmalar için belirsizlik: Sertifika “+0,12 mV sapma” diyor ama prosedürünüz düzeltme uygulamıyor. Bu sapmayı belirsizliğe nasıl yansıtırsınız.
• Monte Carlo simülasyonu: Doğrusal olmayan ölçüm modellerinde klasik GUM yöntemi yetersiz kalır. Bilgisayarda 100.000 simülasyon yapıp dağılımı doğrudan üretirsiniz. RP-12 bu yöntemi pratik bir şekilde anlatır.

ANSI Z540.3 ile bağlantı. Bu standart bir kalibrasyon laboratuvarının uyması gereken kurallardan biri. Ana maddesi şudur: kalibrasyon sonucu yanlış kabul olasılığı %2’den fazla olamaz. Ya da bunu hesaplamak zorsa, TUR ≥ 4:1 olmalıdır. TUR, “test belirsizlik oranı” demek; cihazın toleransının kalibrasyon belirsizliğine oranı. Örnek: cihazın toleransı ±100 µV, kalibrasyon belirsizliği ±25 µV ise TUR = 4. RP-12 bu kuralı sağlamak için gerekli hesap yöntemlerini sunar.

Türkiye uygulaması. TÜRKAK akreditasyonlu kalibrasyon laboratuvarları çoğunlukla Avrupa rehberi EA-4/02’yi takip eder. Ama Türkiye’nin aviyonik (TUSAS, BAYKAR), savunma (ASELSAN, ROKETSAN) ve otomotiv (Togg ve tedarikçileri) firmaları ABD merkezli müşterilere de iş yapıyor. ABD ortağına rapor verdiğinizde NCSLI RP-12 ve Z540.3’e atıf gerekiyor. Yani Türk test mühendisinin masasında giderek artan oranda her iki belge de bulunmalı.

Örnek 1: Voltmetre Kalibrasyonu

Senaryo. Sistem entegrasyon laboratuvarında elinizdeki voltmetre (Keysight 34465A, 6½ haneli) referans bir kalibratörle (Fluke 5720A) doğrulanıyor. Kalibratör tam olarak 10,000 V veriyor. Voltmetrenin bu değeri ne kadar doğru okuduğunu ve okumanın ne kadar belirsizlik içerdiğini hesaplayacağız. Ortam sıcaklığı (23 ± 2) °C.

Adım 1: Tip A — 10 kez ölçüm yapın

Aynı koşullarda 10 ardı ardına ölçüm. Her ölçüm öncesinde voltmetrenin girişini açıp kapayıp kabloyu temizliyoruz (önceki bölümdeki 1. uyarı). Sonuçlar:

• Ortalama: x̄ = 9,999889 V
• Standart sapma: s ≈ 19 µV
• Ortalamanın standart belirsizliği: u_A = s / √10 ≈ 6 µV

Adım 2: Tip B — Diğer kaynakları listeleyin

Her kaynağı düzgün bir tabloya koyarız. Aralığı (üreticinin verdiği değer) ilgili dağılım varsayımıyla bölerek standart belirsizliğe geçeriz.

Adım 3: Birleşik belirsizliği hesaplayın

Her bileşeni karesel olarak topla, karekök al:

u² = 6² + 14² + 0,29² + 23,1² + 1,73² + 2² + 2,89²
u² = 36 + 196 + 0,08 + 533,6 + 3 + 4 + 8,4
u² ≈ 781
u  ≈ 28 µV

Adım 4: Genişletilmiş belirsizlik

Kapsama faktörü k=2 ile çarpın:

U = 2 × 28 = 56 µV

Adım 5: Sonucu ifade edin

Voltmetrenin okuması = (9,999889 ± 0,000056) V, k = 2.

Yani gerçek değer büyük olasılıkla 9,999833 V ile 9,999945 V arasında.

Hangi kaynak en çok katkı veriyor?

Aşağıdaki grafikte, yedi belirsizlik kaynağının her birinin katkısını sıralı görüyorsunuz. Sıcaklık katsayısı toplam belirsizliğin yarısından fazlasını oluşturuyor.

Grafiğin söylediği şey net. Belirsizliği düşürmek isteseniz nereye yatırım yaparsınız? Voltmetreye değil. Daha pahalı bir kalibratöre de değil. Oda sıcaklığını sabitlemeye. Sıcaklık aralığı ±2 °C yerine ±0,5 °C olsa, sıcaklık katkısı 23 µV’den 6 µV’ye düşer; toplam belirsizlik 28 µV’den 16 µV’ye iner. Hiçbir cihaz yatırımı yapmadan, sadece klimayı düzgün ayarlayarak belirsizliği yarıya indirdiniz.

Akılda kalsın — Pareto kuralı: Belirsizlik bütçesindeki bileşenleri varyans katkısına göre sıralayın. İlk iki kaynak çoğu zaman toplamın %80–90’ını oluşturur. İyileştirmeye onlardan başlayın; küçük katkılarla uğraşmak vakit ve para kaybı. Önce en büyük katkıyı yarıya indirmek, geri kalan altıyla uğraşmaktan daha çok kazandırır.

Bu sonucu kabul etmeli miyiz?

Voltmetrenin teknik kataloğu diyor ki cihazın 10 V’ta toleransı ±100 µV. Şimdi TUR hesaplayalım:

TUR = Tolerans / Belirsizlik = 100 / 56 ≈ 1,8

Z540.3’ün 4:1 sınırının çok altında. Ya kabul kararı verirken çok dikkatli olacağız (güvenlik payı uygulayacağız), ya da belirsizliği düşüreceğiz. Üç seçenek var:

1. Sıcaklığı sabitle. Yukarıda anlatıldı. Belirsizlik 16 µV’ye iner, TUR = 6,3 olur. En ucuz çözüm.
2. Daha iyi kalibratör kullan. UME’nin daha düşük belirsizlikle kalibre ettiği bir referans kaynağa geç. Sertifika belirsizliği ±10 µV olabilir. Ama maliyet artar.
3. Müşteriyle konuş. Belki ±100 µV toleransı çok sıkı, gerçek uygulamada ±200 µV bile yeterli olabilir.

Bir test mühendisinin işi sadece sayı üretmek değil, bu üç seçeneği masaya getirip yöneticisiyle tartışmak. Belirsizlik bütçesi olmadan bu konuşmayı yapamazsınız.

Örnek 2: Sıcaklık Sensörü ile Test Fırını Ölçümü

Senaryo. Endüstriyel bir parçanın yüksek sıcaklık dayanım testini yapıyorsunuz. Test gereksinimi: parça 200 °C ± 2 °C ortamda 30 dakika çalışmalı. Fırının içine bir PT100 sensörü koymuşsunuz. (PT100, 0 °C’de tam 100 ohm direnç gösteren platin tel sensörü; sıcaklıkla direnç doğrusal artar; çalışma aralığı tipik olarak −200 °C ile +650 °C arası.) Sensör bir veri toplama kartına (DAQ kartı, NI 9217) bağlı, kart bilgisayara veriyor.

Sıcaklığın gerçek değeri ne olabilir? Belirsizlik bütçesi:

Birleşik belirsizlik:

u² = 0,075² + 0,029² + 0,058² + 0,061² + 0,075² + 0,012² + 0,007²
u² = 0,00563 + 0,00084 + 0,00336 + 0,00372 + 0,00563 + 0,00014 + 0,00005
u² ≈ 0,0194
u  ≈ 0,14 °C

Genişletilmiş belirsizlik (k=2):

U = 2 × 0,14 = 0,28 °C

Sonuç: Fırının iç sıcaklığı = (200,00 ± 0,28) °C, k = 2.

Hangi bileşenler en çok katkı yapıyor? Bakalım:

Test mühendisi olarak ne dersiniz? Gereksinim 200 ± 2 °C, ölçüm belirsizliği 0,28 °C. TUR = 2 / 0,28 ≈ 7,1. Z540.3’ün 4:1 sınırının çok üstünde, sorunsuz.

Ama gereksinim daha sıkı olsaydı (örneğin 200 ± 0,5 °C), TUR = 1,8’e düşerdi. Bu durumda yapılacak iş şu: önce belirsizliği düşürmek lazım. Grafiğe bakın. İlk üç kaynak (PT100 belgesi, DAQ kartı, fırın dağılımı) toplam belirsizliğin %75’ini oluşturuyor. İyileştirme öncelikleri:

1. PT100’ü TÜBİTAK UME’de daha düşük belirsizlikle yeniden kalibre ettirin. ±0,15 yerine ±0,05 °C.
2. Daha yüksek doğruluklu DAQ kartı alın (NI 9226 gibi).
3. Fırın içine ek termal blok koyun, hava sirkülasyonunu artırın.

Bu üç adım belirsizliği yarıya indirir. Hangi kaynağa dokunmadan da ayrı ayrı denenebilir. Mantığı: önce büyüğü azalt, sonra küçükleri düşün.

Örnek 3: Bir Sensörü Kabul mü Edelim, Reddedelim mi?

Senaryo. Bir otomotiv basınç sensörü 0–100 bar arasında ölçüm yapıyor. Kalite kontrolünden geçmesi için toleransı ±0,10 bar. Yani ölçüm cihazı bir referans değer verirken sensör ±0,10 bar içinde okumalı. Kalibrasyon sürecinin belirsizliği: U = 0,025 bar.

TUR hesabı:

TUR = Tolerans / Belirsizlik = 0,10 / 0,025 = 4

Z540.3’ün 4:1 sınırına tam denk geldi. Bu sayı yetiyor mu?

Soruyu şöyle çevirelim: ölçüm cihazı sensörü “geçti” diye işaretlediği halde sensör aslında toleransın dışındaysa, bu yanlış kabul olur. Yanlış kabul olasılığı (PFA = Probability of False Accept) ne kadar?

Önce yanlış kabulun ne demek olduğunu görsel olarak görelim. Aşağıda bir sensörün ölçüm dağılımı çizilmiş. Sensörün gerçek değeri 0,098 bar diyelim — yani toleransın iç sınırına çok yakın. Ölçüm cihazı U = 0,025 bar belirsizlikle bu sensörü ölçüyor. Ölçüm sonucu, gerçek değer civarında bir normal dağılımdan rastgele bir nokta gibi düşünebiliriz. Ölçüm 0,10’un altında çıkarsa “geçti” diyoruz — ama gerçek değer 0,098’de bile, ölçüm dağılımının bir kısmı 0,10’un üstüne taşar. Taşan bu kısım yanlış kabul bölgesidir.

Yeşil alan: ölçüm 0,10’un altında çıkıyor, doğru kabul. Kırmızı alan: ölçüm 0,10’un üstünde çıkıyor (gerçekte sensör tolerans içinde olduğu halde). Burada ölçüm cihazı “reddet” diyecek — ama bu durumda yanlış red. Tam tersi durum, yani sensörün gerçek değeri 0,103 bar olursa (tolerans dışı), ölçüm yine dağılım gösterir, ve dağılımın bir kısmı 0,10’un altına düşer; o zaman ölçüm cihazı “geçti” diyor ama sensör aslında tolerans dışı — yanlış kabul. Bu yazının kalan kısmında yanlış kabul bizi daha çok ilgilendiriyor (üreticinin çıkardığı bozuk ürün).

Aşağıdaki ikinci grafik, TUR’a göre yanlış kabul olasılığının nasıl değiştiğini gösteriyor. Eğri, sensörün gerçek değerinin tolerans içinde uniform dağıldığı varsayımı altında.

TUR = 4’te bile yanlış kabul olasılığı yaklaşık %1,5. 10.000 sensör sevkiyatında 150 hatalı kabul demek. Bu yüzden Z540.3 ek bir önlem öneriyor: kabul aralığını güvenlik payı kadar daraltmak. Buna güvenlik payı (İngilizcesi guard band) deniyor.

Z540.3 6. yöntemde güvenlik payı çarpanı M, TUR’a göre tablodan okunur. PFA’yı %2’nin altında tutmak için tipik değerler:

TUR azaldıkça güvenlik payı büyür; bu mantıklı, çünkü belirsizlik tolerans büyüklüğüne yaklaştıkça yanlış kabul riski artıyor. Bizim örneğimiz için TUR = 4:

Güvenlik payı = 0,053 × 0,025 = 0,00133 bar
Yeni kabul aralığı = ±(0,10 − 0,00133) = ±0,09867 bar

Yani sensörün ölçümü 0,099 bar çıkarsa: tolerans içinde ama güvenlik payı dışında. “Sınırda, manuel inceleme” durumu.

Karşılaştırma için: ILAC G8 (Avrupa) güvenlik payını sade bir şekilde U olarak alır (M = 1). Bu daha muhafazakâr; bizim örneğimizde güvenlik payı 0,025 bar olur, kabul aralığı ±0,075 bar’a kadar daralır. ILAC ve ANSI farkı sahada önemli; müşterinizin hangi standardı şart koştuğuna bakın.

Önemli bir uyarı. “TUR ≥ 4 yeter” varsayımı eski bir kuraldır. Henry Zumbrun adlı uzman 2021’de yazdığı “TUR=4 Neden Yeterli Değil” makalesinde gerçek üretim verisi üzerinden gösterdi: bir ölçüm sınıra çok yakın çıktığında TUR=4 bile %30+ yanlış kabul olasılığı yaratabilir. Bu yüzden modern uygulama, sadece TUR’a bakmak değil, gerçek PFA’yı hesaplamaktır. Z540.3 6. yöntem ya da ILAC G8 (Avrupa eşdeğeri, güvenlik payı = 1×U formülünü kullanır) bu işi yapar.

Akılda kalsın — kabul/red kararı:

• TUR = Tolerans / Genişletilmiş belirsizlik (U)
• Z540.3 (ABD): Yanlış kabul olasılığı (PFA) ≤ %2 olmalı; pratik değilse TUR ≥ 4. Method 6 ile güvenlik payı: TUR=4 için ≈ 0,053×U; TUR=2 için ≈ 0,28×U.
• ILAC G8 (Avrupa): Güvenlik payı = 1×U (kabul aralığı her iki yandan U kadar daraltılır).
• Önemli: TUR ≥ 4 yeter zannetmeyin. Ölçüm sınıra çok yakın çıkarsa TUR=4 bile %30+ yanlış kabul üretebilir. Karar verirken hem TUR’a hem ölçümün sınıra uzaklığına bakın.

Aviyonik UUT Üreticisi İçin Ölçüm Disiplini

Yukarıdaki üç örnek genel bir test laboratuvarı bakışıyla yazıldı. Ama bir aviyonik UUT (Unit Under Test, “test edilen cihaz”) üreten şirketin tablosu farklı. Bir VOR/ILS alıcısı üretiyorsunuz, datasheet’inize “azimuth accuracy ±0,1°” yazdınız, müşteriniz uçak üreticisi (TUSAS, Airbus, Sikorsky) bu beyana güvenerek tip sertifikasyonunu yürütüyor. Sahaya çıkan her cihaz için bu beyanı doğrulamak zorundasınız.

Test ekipmanınız bir RF sinyal üreticisi. Datasheet’inde “azimuth çıkış doğruluğu ±0,001°” yazıyor. Sayılar büyüleyici görünüyor: TUR = 0,1 / 0,001 = 100. Yazının ilk yarısındaki “≥ 10 → sorunsuz” kategorisinin çok ötesinde. Burada bitti, geçtik mi?

Hayır. Bu noktada üç gizli tuzak var ve aviyonik bağlamda her birine düşmek pahalıya patlıyor.

Önce kavram: belirsizlik çıkarılır mı, eklenir mi, yoksa hiç dokunulmaz mı?

Test laboratuvarında kabul/red kararı verirken belirsizlik üç farklı şekilde işlenebilir. Aşağıdaki grafik aynı toleransı (örnek olarak ±0,1) ve aynı ölçüm belirsizliğini (U = 0,025) üç yaklaşımla yan yana gösteriyor; her satırın yeşil bandı kabul aralığını, gri bandı toleransı temsil ediyor.

• 1) Paylaşılan risk: Belirsizliği hesaba katmazsınız. Ölçüm tolerans içindeyse “geçti”. Eski test laboratuvarı uygulaması; ISO/IEC 17025 ile uyumlu beyan üretiyorsanız artık kabul edilmez.
• 2) Korumalı kabul (guarded acceptance): Belirsizlik tolerans sınırından içeri doğru çekilir. Müşteriyi/son kullanıcıyı korur, yanlış kabul olasılığını (PFA) düşürür. UUT üreticisi konumunda doğru yaklaşım.
• 3) Korumalı red (guarded rejection): Belirsizlik tolerans sınırından dışarı doğru itilir. Üreticiyi yanlış red’den korur ama yanlış kabul artar. Aviyonik bağlamda gerekçelendirilmesi zor.

UUT üreticisi olarak ikinci sütundayım — bu yazının kalan kısmı bunu sayısal hale getiriyor.

Risk yönü tartışılır değil

Test laboratuvarında “shared risk” denilen bir uygulama yaygındır: belirsizliği hesaba katmazsın, ölçüm tolerans içindeyse geçer. Bunun temeli müşteri ile laboratuvar arasında risk paylaşımıdır. UUT üreticisi konumunda bu seçeneğiniz yok. Beyan size ait, kabul kararı sizin, sahaya çıkan cihazın sorumluluğu da sizin. İki olası hatanın bedeli aynı değildir:

Bu asimetrik risk profilinde belirsizlik her zaman içeri çekilir, yani kabul aralığı toleranstan daraltılır. Yukarıdaki üç yaklaşımdan tek meşru olanı bu. Ekleme (kabul aralığını genişletme) yönü, DO-178C DAL A bir LRU için sertifikasyon denetiminde gerekçelendirilemez.

Hangi standart: ILAC G8 default

Türkiye’de TÜRKAK akreditasyonu üzerinden çalıştığınız için doğal default ILAC G8 ve onun Avrupa eşdeğeri EA-4/02:

Kabul aralığı = ±(T − U)

Müşteriniz ABD merkezliyse (Lockheed, Raytheon, Boeing tedarik zincirinde değilseniz bile) sözleşme Z540.3 atfı içerebilir. O durumda Method 6 ile TUR’a bağlı M çarpanı kullanırsınız. Pratik fark: ILAC G8 bütün TUR değerleri için 1×U çıkarır; Z540.3 yüksek TUR’da daha az çıkarır. Yani yüksek TUR’da Z540.3 daha gevşek, ILAC G8 daha muhafazakâr. Aviyonik için muhafazakâr olan tarafta kalın.

İki müşteri tipi de varsa rapor şablonunu çift sütun yapın: “ILAC G8 kabul aralığı: ±X” ve “Z540.3 kabul aralığı: ±Y”. Sahada hangisini uygulayacağınızı sözleşme belirler.

Datasheet spec’i son çaredir

Sinyal üreticinizin datasheet’inde “±0,001°” yazıyor. Bu satır, üreticinin geniş bir cihaz popülasyonu için garanti ettiği en kötü durumdur. Sizin elinizdeki tek tek cihaz büyük olasılıkla daha iyidir. Ama bunu nasıl bilirsiniz?

Akredite kalibrasyon belgesi. Sinyal üreticinizi TÜRKAK akredite (veya ulusal eşdeğer) bir laboratuvarda yıllık olarak kalibre ettirdiğinizde belgenizde “ölçülen değer = X, U = ±0,0002° (k=2)” tarzında bir veri olur. Bu sayı genelde datasheet spec’inin 3-10 katı küçüktür. Belirsizlik bütçenizde datasheet spec’i değil bu belgenin U’sunu kullanın.

Datasheet spec ne zaman kullanılır? İki durumda:

1. Sinyal üretici hiç kalibre edilmedi (kötü uygulama, akreditasyon denetimi takılır).
2. Kalibrasyon belgesi var ama ölçüm yaptığınız belirli noktayı kapsamıyor (interpolasyon yapamıyorsunuz).

Spec’i kullanırken yazıdaki kuralı uygulayın: bilgi yoksa düz dağılım, u = a / √3.

u_kaynak (datasheet)                       = 0,001 / √3   ≈ 0,000577°
u_kaynak (akredite belge, U=0,0002, k=2)   = 0,0002 / 2   = 0,0001°

Akredite belgeyle çalışırsanız bu bileşenden gelen katkı yaklaşık 6 kat azalır.

Spec’in geçerlilik kapsamına bakın

Datasheet spec’i her zaman bir koşullar paketinin içinde geçerlidir:

• Sıcaklık aralığı: “23 °C ± 5 °C” tipik. Lab sıcaklığınız bu aralık dışında salınıyorsa spec geçersiz, ek bir tempco (sıcaklık katsayısı) bileşeni ekleyin.
• Takvim: “90 gün spec” ve “1 yıl spec” sayıları farklıdır. Son kalibrasyondan bu yana ne kadar zaman geçti?
• Isınma süresi: “30 dakika ısınma sonrası” yazıyorsa, üretimdeki testlerde bunu uygulayın.
• Ölçüm bandı: Spec belli bir frekans ya da seviye aralığında geçerli olabilir. VOR sinyali için 108–118 MHz, ILS için 108–112 MHz gibi.

Bu kapsam dışında kullanırsanız spec’i kullanmaya hakkınız yok. F Eki 7. uyarısının (gizli sıcaklık tuzağı) tersi: kapsam içindeyken çift saymak, kapsam dışındayken eksik saymak sık yapılan hata.

Bileşen listesi tek satıra düşmez

±0,001° spec’ini tek bileşen olarak kullanmak yetmez. Bir VOR alıcısı azimuth doğruluğu testi için tipik bütçe şöyle görünür:

Birleşik belirsizlik:

u² = 0,0001² + 0,00029² + 0,00017² + 0,00289² + 0,00115²
   + 0,00095² + 0,00058² + 0,00115²
u² ≈ 1,24 × 10⁻⁵
u  ≈ 0,0035°

U  = 2 × 0,0035 ≈ 0,007°  (k=2)

Yani gerçek ölçüm belirsizliğiniz ±0,007° mertebesinde. Datasheet spec’inden gelen ±0,001° ise toplamın yalnızca küçük bir parçası. Çözünürlük (4. satır) ve RF kablolama (5. ve 8. satırlar) çok daha büyük katkı veriyor.

Kabul aralığı ve karar

TUR     = 0,1 / 0,007 ≈ 14,3
Kabul aralığı (ILAC G8) = ±(0,1 − 0,007) = ±0,093°

UUT’nin ölçülen azimuth hatası ±0,093° içindeyse “azimuth accuracy ±0,1° spec’ini karşılıyor” beyanı verebilirsiniz. ±0,093° ile ±0,1° arasındaysa cihaz sınır bölgesinde — yazılı prosedürünüze göre bu cihazları ya tekrar test edersiniz, ya manuel inceleme yaparsınız, ya da reddedersiniz. Fail-safe tarafa düşmek için reddetmek en güvenlisidir.

Üç katmanlı koruma

Bütün bu hesabı yapsanız bile sahaya çıkan her cihazın spec içinde kalması garanti değildir. Aviyonikte standart pratik çift güvence:

Tasarım hedefi   ⊆   Kabul aralığı   ⊆   Beyan toleransı
   (±0,05°)            (±0,093°)            (±0,1°)

• Tasarım hedefi (±0,05°): R&D ekibi devre tasarımını bu hedefe göre yapar; üretim sürecindeki normal varyasyonun beyana taşması engellenir.
• Kabul aralığı (±0,093°): Üretim sonu testte kullanılan eşik. Ölçüm belirsizliği çıkarılmış halidir.
• Beyan toleransı (±0,1°): Datasheet’te yazan, müşteriye verilen söz.

Bu üç sınır arasındaki boşluklar — 0,05° tasarım marjı ve 0,007° ölçüm marjı — emniyet kritik sistemde “ücretsiz öğle yemeği” değildir; üretim verim kaybı (yield loss) olarak para olarak ödenir. Ama VOR/ILS bir LRU’nun sahada ±0,12° ile gelmesinin bedeli, bir avukatın saatlik ücretiyle ölçülür. Yatırım bu açıdan değerlendirilir.

DO-178C, DO-254 ve veri yönetimi

Bütün belirsizlik bütçeniz konfigürasyon yönetimi altında saklanmalı. Pratik kontroller:

• Bütçe dökümanı bir baseline’a (DOORS, SVN vb.) bağlı; revizyon geçmişi var.
• Test prosedürü (TPS) bütçeyi atıf olarak gösteriyor.
• Sinyal üretici kalibrasyon belgeleri (PDF) prosedürün ek dosyaları olarak kayıtlı.
• ATR (Acceptance Test Report) her seri için: ölçüm değeri, U, k, kabul aralığı, karar — dört sütunlu.
• Akreditasyon denetiminde her bütçe satırı için gerekçe belgesi istenir (PDF varsayımı, dağılım seçimi, bağımsızlık kararı).

DO-178C’nin doğrudan ölçüm belirsizliği zorunluluğu yoktur — yazılım standardıdır. Ama DO-254 (donanım), ARP4761 (emniyet değerlendirme) ve müşteriye verilen Hardware Acceptance Data Sheet’ler bütçeyi varsayar. ARP4761 FHA/PSSA aşamalarında “ölçüm doğrulanmamış” bir donanım performansı argüman olarak kullanılamaz.

Aviyonik UUT üreticisi için kontrol listesi

1. Default ILAC G8’i seçin, müşteri Z540.3 isterse iki sütunlu rapor verin. Eklemeyi (genişletmeyi) hiçbir koşulda kullanmayın.
2. Sinyal üreticilerini akredite labda kalibre ettirin, datasheet spec’ini sadece son çare olarak kullanın.
3. Spec geçerlilik kapsamını okuyun: sıcaklık, takvim, ısınma, frekans, seviye. Lab koşullarınız dışındaysa ek bileşen ekleyin.
4. Bütçeyi tek satıra düşürmeyin: çözünürlük, RF kablolama, multipath, UUT tempco — hepsi aviyonikte kayda değer katkı verir.
5. Üç katmanlı koruma: tasarım hedefi < kabul aralığı < beyan toleransı. Tasarım marjı R&D’nin işidir, ölçüm marjı sizin işiniz.
6. TUR yeterli sayılmaz: TUR=14 olsa bile guard band uygulayın. TUR < 4 olursa ya bütçeyi düşürün ya beyanı gevşetin — denetimde “işte böyle çıkıyor” demek geçerli savunma değil.
7. Bütçeyi konfigürasyon yönetimi altına alın: revizyon, gerekçe, ek belgeler. Akreditasyon ve sertifikasyon denetiminde her satır sorulur.

Akılda kalsın — UUT üreticisi için altın kural:

• Risk size ait → belirsizlik çıkarılır, eklenmez.
• Datasheet spec değil, akredite kalibrasyon belgesi.
• Spec geçerlilik kapsamı dışındaysa, ek bileşen.
• Tasarım hedefi, kabul aralığı ve beyan toleransı üç ayrı sayıdır; arada para kaybedersiniz, kaybetmek zorundasınız.
• TUR ≥ 4 yeterli değil; PFA hesaplı guard band uygulayın.

Yedi Pratik Tavsiye

Yazıyı bir el kitabına dönüştürelim. Yarın işe gittiğinizde uygulayabileceğiniz somut yedi madde:

1. Belirsizlik bütçesini test prosedürünün parçası yapın. Test belgesinin içine “belirsizlik bütçesi” başlıklı bir bölüm koyun. Sonradan eklenen bütçe çoğunlukla eksik kalır.

2. Tek ölçüm yapmayın. En az 10 tekrar ölçüm. Mümkünse iki farklı operatör, iki farklı gün. Kıdemli mühendis “bir kez ölçtüm geçti” derse, “tekrar yapalım” deyin.

3. Kalibrasyon belgelerini saklayın. Her cihazın izlenebilirlik zincirinde TÜRKAK akreditasyonlu bir laboratuvarın belgesi olmalı. Belge numaralarını test belgesine yazın. Akreditasyon denetiminde her birinin sorulması olası.

4. İlişkili kaynakları arayın. Aynı kalibratörden iki cihaz besleniyorsa, sertifika belirsizlikleri ilişkili. Aynı oda, aynı kullanıcı, aynı kablolar; bunlar ilişki yaratır. Bağımsızlık varsayımı doğal değildir, doğru olduğunu göstermek size düşer.

5. PDF varsayımlarını yazılı gerekçelendirin. “Düz dağılım kullandım çünkü üretici belirtmedi” gibi bir not her satırın yanında olsun.

6. TUR ≥ 4 yeterli demeyin. Yanlış kabul olasılığını hesaplayın. Z540.3 6. yöntem ya da ILAC G8 ile güvenlik payı ekleyin.

7. Sonucu doğru ifade edin. “Geçti” yerine: “9,999889 V, U = 56 µV (k=2). Tolerans 10,000 V ± 100 µV. Sonuç: tolerans içinde, güvenlik payı içinde.” Sayı + birim + belirsizlik + k dörtlüsü eksik olduğunda rapor da eksik.

Hızlı Referans Kartı

Bu bölümü ayrı bir sayfaya yazdırıp masanızın üstüne koyabilirsiniz. Belirsizlik bütçesi yaparken sürekli geri dönülen şablon.

Adım adım belirsizlik hesabı

1. Ölçtüğünüz büyüklüğün bileşenlerini listeleyin (Tip A + Tip B kaynakları).
2. Her bileşen için standart belirsizliği (u) hesaplayın:
   • Tip A: birden fazla ölçüm → s/√n
   • Tip B: aralığı dağılım faktörüne böl
3. Birleşik belirsizlik: u = √(Σ uᵢ²)
4. Genişletilmiş belirsizlik: U = k × u (genelde k = 2)
5. Sonucu yazın: “X = (değer ± U) birim, k = 2”
6. TUR kontrol edin: TUR = Tolerans / U; gerekirse güvenlik payı uygulayın.

Aralık → standart belirsizlik dönüşüm tablosu

Karar kuralı

Akreditasyon denetiminde sorulanlar

• Her cihazın izlenebilirlik zinciri belge numarası var mı?
• Tip B bileşenleri için PDF varsayımı yazılı gerekçesi var mı?
• Bağımsızlık varsayımı kontrol edildi mi (aynı kalibratör, aynı operatör)?
• Tip A ölçümleri arasında koşullar gerçekten yenilendi mi?
• TUR < 4 ise PFA hesabı belgelenmiş mi?
• Sonuç raporu “değer + birim + U + k” dörtlüsünü içeriyor mu?

Belirsizlik bütçesi şablonu (kopyala-doldur)

Tabloyu doldurduktan sonra “Katkı %” sütunu hangi bileşenin en çok katkıyı verdiğini gösterir; iyileştirmeye en büyük yüzdeden başlayın.

Sonuç

GUM teorik temeli kuruyor, F eki günlük ölçüm yapan mühendise yönelik en pratik bölüm. NCSLI RP-12 GUM’u günlük dile çeviriyor, somut tablo ve şablonlar veriyor. ANSI Z540.3 ile birleşince kalibrasyon laboratuvarlarının uyması gereken kurallar bütünü ortaya çıkıyor.

Türkiye’de uçak elektroniği (TUSAS, BAYKAR), savunma (ASELSAN, ROKETSAN), otomotiv (Togg ve tedarikçileri) ve medikal cihaz alanında bu disiplin yavaş yavaş zorunlu hale geliyor. Akreditasyon denetimleri sertleşiyor, müşteriler belirsizlik bütçesini bir formalite değil mühendislik ürünü olarak istiyor. Aviyonik UUT üreticisi konumunda olanlar için ek bir disiplin var: belirsizlik daima toleranstan çıkarılır, üç katmanlı koruma (tasarım hedefi → kabul aralığı → beyan toleransı) standart pratiktir, ve bütün bütçe konfigürasyon yönetimi altında izlenebilir olmalıdır.

Bir test mühendisinin işi sadece sayı üretmek değil. Sayının yanına eklenecek “± şu kadar” değerini de üretmek. Bu olmadan “geçti” sözünün ölçüsel bir karşılığı yok; sadece bir tahmin.

Bir sonraki yazıda aynı problemleri Monte Carlo simülasyonu ile çözeceğiz. Doğrusal olmayan ölçüm modellerinde (radyo frekans güç ölçümü, dinamik basınç gibi) klasik kareli toplam yaklaşımı yetersiz kalır; bilgisayarda 100.000 simülasyon yaparak dağılımı doğrudan üretmek gerekir.

Kaynaklar

• JCGM 100:2008 — Ölçüm Belirsizliğinin İfadesi Kılavuzu (BIPM PDF)
• JCGM 101:2008 — Monte Carlo ile Belirsizlik Dağılımı (Ek 1)
• JCGM GUM-6:2020 — Ölçüm Modelleri Geliştirme ve Kullanma
• GUM F Eki — Belirsizlik Bileşenlerini Hesaplamak için Pratik Rehber (HTML)
• GUM H Eki — Sayısal Örnekler (HTML)
• NCSLI RP-12: Ölçüm Belirsizliklerini Belirleme ve Raporlama (2013)
• EA-4/02 M:2013 — Avrupa Kalibrasyon Belirsizliği Rehberi
• ILAC G8:09/2019 — Uygunluk Beyanı Kuralları için Rehber
• Henry Zumbrun — TUR=4 Neden Yeterli Değil (Morehouse, 2021)
• Welch-Satterthwaite Formülü Pratik Açıklaması (In Compliance Magazine)
• Etkin Serbestlik Derecesi Hesabı (ISOBudgets)
• Güvenlik Payı (Guard Band) Açıklaması (ISOBudgets)
• Basınç Ölçüm Belirsizliği Rehberi (Fluke Calibration)
• RTCA DO-254 — Aviyonik Donanım Tasarım Güvencesi Rehberi
• SAE ARP4761 — Sivil Hava Sistemleri Güvenlik Değerlendirme Rehberi
• TÜBİTAK UME — Ulusal Metroloji Enstitüsü
• TÜRKAK — Türk Akreditasyon Kurumu

İşte Yöneylem Araştırması (İngilizce Operational Research veya Operations Research, kısaca OR), bu sorunları sistematik biçimde çözmek için geliştirilmiş disiplinin adıdır. Bu yazıda OR’un iki büyük yöntem ailesini — kesin (exact) yöntemler ve metasezgisel (metaheuristic) yöntemler — tanımları ve klasik örnekleriyle inceleyeceğiz. Linear Programming (LP), Integer Programming (IP), Binary Integer Programming (BIP), Mixed-Integer Programming (MIP) ve Dynamic Programming (DP) kesin yöntemleri oluşturur. Genetic Algorithm (GA), Simulated Annealing (SA), Tabu Search (TS) ve Ant Colony Optimization (ACO) ise problem çok büyüdüğünde devreye giren metasezgisel ailenin temsilcileridir. Sonunda iki dünyayı birleştiren matheuristic yaklaşıma ve “hangi problem hangi yöntemi ister?” sorusuna pratik bir çerçeve sunacağız.

Kısa Bir Tarihçe: OR Nasıl Doğdu?

Yöneylem araştırmasının kökleri İkinci Dünya Savaşı’na uzanır. 1940 Ağustos’unda, Britanya Hava Savaşı’nın tam ortasında, fizikçi Patrick Blackett İngiliz ordusunun Anti-Aircraft Command’ı için bir bilim insanları grubu kurdu. Bu grup — tarihe “Blackett’s Circus” (Blackett’ın Sirki) olarak geçti — anti-uçak toplarının düşman bombardımanlarını düşürme oranını iyileştirmek için mekanik hesaplama sistemlerini analiz etti. Sonuç çarpıcıydı: bir düşman uçağını düşürmek için gereken ortalama mermi sayısı, Britanya Hava Savaşı’nın başlangıcındaki 20.000’den 1941’de 4.000’e indirildi.

1941’de Blackett RAF Coastal Command’a geçti ve burada başka bir ekip kurarak Alman U-botlarına karşı kullanılan konvoy taktiklerini, derinlik bombası ayarlarını ve uçak kamuflajını analiz etti. Kaleme aldığı “Scientists at the Operational Level” (Operasyonel Düzeyde Bilim İnsanları) başlıklı dâhili memorandum, modern “operational research” kavramının ilk resmi tanımlarından biri kabul edilir. Savaş bitmeden çok önce OR, stratejik askeri karar vermenin vazgeçilmez parçası olmuştu.

Savaş sonrasında disiplin hızla sanayiye taşındı. 1946’da Amerikan Ordusu için mekanizasyon çalışmaları yürüten genç bir matematikçi olan George Dantzig, 1947 yılının yazında simpleks yöntemini geliştirdi; böylece doğrusal programlama (linear programming) tekniği doğmuş oldu. “Linear programming” terimini kendisi değil, 1948’de Dantzig’in RAND Corporation’a yaptığı ziyarette meslektaşı Tjalling Koopmans önermiştir. 1952’de RAND’e katılan Richard Bellman, çok aşamalı karar problemlerini modellemek için dinamik programlamayı geliştirdi ve 1957’de aynı adı taşıyan klasik kitabı yayımladı.

1960’larda Ailsa Land ve Alison Doig’in dal-sınır (branch-and-bound) algoritması, Ralph Gomory’nin kesme düzlemleri (cutting planes) ve 1970’lerde John Holland’ın genetik algoritmaları ile alan hızla zenginleşti. 1980’lerle birlikte Kirkpatrick ve ekibinin benzetimli tavlaması, Glover’ın tabu araması ve Dorigo’nun karınca kolonisi optimizasyonu metasezgisel devrimi başlattı. Bugün OR, üretimden lojistiğe, sağlıktan finansa, enerjiden telekomünikasyona pek çok sektörün arka planında sessizce çalışan bir bilim dalıdır.

İlginçtir, OR’un bu erken dönem araştırmacılarının birçoğu Nobel ödülü kazandı: Koopmans 1975’te “kaynakların optimal tahsisi” üzerine yaptığı çalışmalarla Ekonomi Nobel’i aldı; 1994’te John Nash, John Harsanyi ve Reinhard Selten oyun teorisi üzerinden ödüle layık görüldü. Dantzig’in adı uzun yıllar Nobel için geçmesine rağmen ödül sadece ekonomi ve barış gibi alanlara verildiğinden matematiğe özgü Fields Madalyası’na da uygun olmadığı için resmi bir büyük ödül alamadı; fakat akademik camiada SIAM tarafından onun adına “Dantzig Prize” oluşturuldu ve her iki yılda bir matematiksel programlamaya katkı yapan bir bilim insanına verilir.

Yöneylem Araştırması Nedir?

Her OR probleminin üç temel bileşeni vardır:

1. Karar değişkenleri (decision variables): Çözümü oluşturan, kontrol edebildiğimiz büyüklükler. Bir işçi sayısı, bir makinenin çalışma süresi, “bu kamyon o depoya gidecek mi?” gibi ikili kararlar.
2. Amaç fonksiyonu (objective function): Maksimize ya da minimize etmek istediğimiz ölçüt. Kâr, maliyet, süre, yakıt tüketimi gibi.
3. Kısıtlar (constraints): Gerçek hayatın çözüme dayattığı sınırlar. Bütçe, kapasite, zaman pencereleri, talep miktarları gibi.

Genel bir optimizasyon problemi matematiksel olarak şöyle yazılır:

min (veya max)    f(x)
s.t.              g_i(x) ≤ 0,   i = 1..m
                  h_j(x) = 0,   j = 1..k
                  x ∈ X

Burada f amaç fonksiyonu, g_i eşitsizlik kısıtları, h_j eşitlik kısıtları ve X karar değişkenlerinin bulunabileceği bölgedir (sürekli sayılar, tam sayılar, ikili değerler vb.).

Bu üçlü formüle edildikten sonra iki temel soru ortaya çıkar: (a) çözüm uzayı ne kadar büyük? ve (b) garantili optimal mi, yoksa makul sürede “yeterince iyi” bir çözüm mü istiyoruz? Bu iki soruya verilen yanıt sizi ya kesin yöntemlere ya da metasezgisellere yöneltir. Bir sonraki bölümlerde bu iki aileyi tek tek ele alacağız.

Kesin (Exact) Yöntemler

Kesin yöntemler, problem boyutu ve yapısı izin verdiğinde matematiksel olarak garantili optimal çözümü üreten tekniklerdir. Simpleks, dal-sınır ve dinamik programlama gibi algoritmalar bu ailenin temel taşlarıdır. Karşılığında ödenen bedel genellikle artan problem boyutlarında üstel mertebede büyüyen çalışma süresidir.

Doğrusal Programlama (Linear Programming — LP)

LP, yöneylem araştırmasının en eski ve en temel aracıdır. Hem amaç fonksiyonunun hem de kısıtların doğrusal olduğu, karar değişkenlerinin ise sürekli (gerçek sayı) olabildiği problemleri çözer. Standart formu şöyle yazılır:

max    z = c₁x₁ + c₂x₂ + ... + cₙxₙ
s.t.   a₁₁x₁ + a₁₂x₂ + ... + a₁ₙxₙ ≤ b₁
       a₂₁x₁ + a₂₂x₂ + ... + a₂ₙxₙ ≤ b₂
       ...
       xᵢ ≥ 0   (∀ i)

Dantzig’in 1947’de geliştirdiği simpleks yöntemi, LP çözmek için hâlâ en yaygın kullanılan algoritmadır. Simpleks’in arkasındaki sezgi saf geometriktir: LP’nin uygulanabilir bölgesi (feasible region) çok boyutlu bir çokyüzlüdür (polyhedron); optimum değer bu çokyüzlünün köşelerinden birinde bulunur. Simpleks tam olarak bunu yapar: bir köşeden komşu köşeye geçerek amaç fonksiyonunu iyileştirir, iyileştirme kalmayınca durur. Pratikte son derece hızlıdır; ama en kötü durumda üstel zamanda çalışabilir. 1979’da Leonid Khachiyan’ın elipsoid yöntemi ile LP’nin polinom zamanda çözülebildiğini kanıtlaması ve 1984’te Narendra Karmarkar’ın projektif iç nokta yöntemlerini (interior point methods) geliştirmesi, alanın iki büyük teorik sıçramasıdır. Modern çözücüler bu iki aileyi birlikte kullanır.

LP’nin bir diğer güzelliği ikilik teoremidir (duality theorem): Her LP’nin bir “eşleniği” (dual) vardır. Primal problem “kârı maksimize et” ise dual “minimum kaynak kullan” gibi yorumlanır. Dualin çözüm değeri, primale ait gölge fiyatları (shadow prices) verir: “Kısıt i‘yi bir birim gevşetirsem amaç fonksiyonu ne kadar değişir?” sorusunun yanıtı. Duyarlılık analizi (sensitivity analysis), kapasite yatırımı ve fiyatlama gibi iş kararlarının temelidir.

Klasik örnek — Üretim karışımı: Bir mobilya atölyesi masa ve sandalye üretiyor. Her masadan 40 TL, her sandalyeden 30 TL kâr ediyor. Elimizde 400 saatlik marangozluk ve 240 saatlik cila kapasitesi var. Bir masa 4 saat marangozluk, 2 saat cila; bir sandalye 2 saat marangozluk, 2 saat cila gerektiriyor. Kârı maksimize etmek için kaç masa ve kaç sandalye üretmeliyiz?

max    z = 40x₁ + 30x₂
s.t.   4x₁ + 2x₂ ≤ 400   (marangozluk)
       2x₁ + 2x₂ ≤ 240   (cila)
       x₁, x₂ ≥ 0

Bu küçük LP’nin optimum noktası uygulanabilir bölgenin köşelerinden birindedir. Grafik yöntemle çözüldüğünde kısıtların kesiştiği nokta (x₁=80, x₂=40) optimal çözüm olur ve kâr 40·80 + 30·40 = 4.400 TL’dir. Simpleks aynı sonucu saniyenin milyonda birinde bulur.

LP’nin en bilinen uygulama kategorileri:

• Diet problem (beslenme): En düşük maliyetle günlük besin gereksinimlerini karşılamak üzere hangi yiyeceklerden ne kadar tüketilmeli? Dantzig’in 1945’te başlayan klasik çalışmalarından biri.
• Transportation problem (ulaşım): m fabrikadan n depoya, her fabrika-depo çifti için farklı taşıma maliyetleri ile en ucuz akış nasıl sağlanır?
• Assignment problem (atama): n işi n kişiye, her eşleşme için farklı yetkinlikle en verimli şekilde nasıl atarız?
• Blending problem (karışım): Rafinerilerde ham petrolün benzin/dizel karışımlarına dağıtımı; en düşük maliyetli kimyasal bileşim.
• Production planning (üretim planlama): Birden çok ürün, birden çok dönem, kapasite ve envanter kısıtları altında toplam kârı maksimize etme.

LP pratikte milyonlarca değişken ve kısıt içeren modelleri modern çözücüler (Gurobi, CPLEX, HiGHS) ile saniyeler–dakikalar mertebesinde çözebilir. Bu olağanüstü ölçeklenebilirlik, LP’yi diğer tüm kesin yöntemlerin “çözüm zemini” hâline getirir: IP, BIP ve MIP’in pek çok algoritması arka planda binlerce LP çözer.

Simpleksin bir takım patolojik durumları da vardır ve bunlar pratikte bilinir: Dejenerasyon (degeneracy), birden fazla kısıtın aynı köşede kesişmesi durumudur; bu durumda amaç fonksiyonu iyileşmeden birkaç iterasyon yapılabilir ve en kötü durumda çevrim (cycling) oluşabilir. Bland’in anti-çevrim kuralı ve sözlükbilimsel kurallar (lexicographic rule) bu sorunu çözer. Gözden geçirilmiş simpleks (revised simplex) ise tüm tabloyu her iterasyonda güncellemek yerine yalnızca bazın tersini çarpanlara ayırarak bellek ve hesap verimini artırır; modern çözücüler bu versiyonu kullanır. Dahası büyük ölçekli ve özel yapılı LP’ler için Dantzig-Wolfe ayrıştırması (decomposition) ve ona dual olan Benders ayrıştırması gibi teknikler, problemi daha küçük alt problemlere bölerek çözer.

Tam Sayı Programlama (Integer Programming — IP)

Karar değişkenleri yalnızca tam sayı değerler alabildiğinde IP’den söz ederiz. “2.4 adet çalışan işe al” gibi anlamsız sonuçlardan kaçınmak için kullanılır:

max    z = cᵀx
s.t.   Ax ≤ b
       xᵢ ∈ ℤ   (∀ i)

IP, LP’den çok daha zordur; genel IP NP-zor sınıfına girer. Teorik çözüm yöntemleri Land ve Doig’in 1960’ta Econometrica dergisinde tanıttığı dal-sınır algoritması ve Gomory’nin 1958’de önerdiği kesme düzlemleridir. Modern çözücüler bu ikisini dal-ve-kesme (branch-and-cut) şemasında birleştirir.

Dal-sınır mekanizması: Önce LP gevşetmesi (tam sayı şartı kaldırılmış hâli) çözülür. Eğer sonuç zaten tam sayıysa bitti. Değilse kesirli bir değişken seçilir (örneğin x₃ = 2.7) ve problem iki alt probleme bölünür: x₃ ≤ 2 ve x₃ ≥ 3. Her alt problem kendi LP gevşetmesiyle çözülür; “sınır” değeri mevcut en iyi tam sayı çözümden daha kötüyse o dal budanır (bound). Algoritma bir ağaç biçiminde gezinerek tüm olası tam sayı çözümleri kapsadığına emin olur.

Kesme düzlemleri aynı zamanda güçlü bir fikirdir: LP gevşetmesine, tüm tam sayı çözümleri dışarıda bırakmayan ama mevcut kesirli LP çözümünü kesip atan yeni eşitsizlikler eklenir. Bu şekilde uygulanabilir bölge sıkılaştırılır, dallanma sayısı azalır. Gomory mixed-integer cuts, MIR, lift-and-project, flow cover gibi onlarca kesi ailesi modern çözücülerde yer alır.

IP için bir özel durum daha önemlidir: tamamen unimodular (totally unimodular) matrisler. Eğer kısıt matrisinin tüm karesel alt determinantları {-1, 0, +1} kümesinde yer alıyorsa, LP gevşetmesinin optimum çözümü zaten tam sayıdır. Bu özellik ağ akış problemleri, bazı çizelgeleme problemleri ve çift yönlü eşleme (bipartite matching) için geçerlidir — bunlar polinom zamanda çözülür.

Klasik örnek — Tesis yerleşimi: Bir kargo şirketi m aday lokasyondan bazılarını depo olarak açmak istiyor. Her depo açma maliyeti ve her müşteriye hizmet maliyeti biliniyor. Her müşterinin hangi depodan hizmet alacağı (tam sayı atama) ve hangi depoların açılacağı (0/1 karar) birlikte modellenir; toplam maliyet minimize edilir. Az sayıda aday varken dakikalarla çözülürken, yüzlerce aday için saatlere çıkabilir. Benzer yapıdaki makine atama ve üniversite ders programı problemleri de IP ile çözülür.

IP için bir diğer önemli klasik teknik Lagrange gevşetmesidir (Lagrangian relaxation): Zor kısıtlar amaç fonksiyonuna ceza (Lagrange çarpanı) olarak eklenir; elde edilen gevşek problem genelde yapısal olarak daha kolaydır (çoğu kez bağımsız alt problemlere ayrışır). Çarpanlar subgradient yöntemiyle iteratif olarak güncellenir. Çıkan Lagrange duali, orijinal IP için bir alt sınır verir ve dal-sınır ağacında güçlü budama sağlar. 1970’lerde Held ve Karp’ın TSP için kullandığı bu yaklaşım, o dönemin en iyi alt sınırlarını vermiştir ve hâlâ özel yapılı büyük IP’lerde tercih edilir.

İkili Tam Sayı Programlama (Binary Integer Programming — BIP)

Karar değişkenlerinin yalnızca {0, 1} değerlerini alabildiği özel bir IP türüdür. “Bir iş yapılacak mı?”, “Bu rota seçilecek mi?”, “Bu eşya çantaya girecek mi?” gibi evet/hayır kararlarında doğal modeldir:

min    z = cᵀx
s.t.   Ax ≤ b
       xᵢ ∈ {0, 1}   (∀ i)

BIP, kombinatoryal optimizasyonun pek çok klasik problemini kapsar:

• Knapsack problem (sırt çantası): Hangi eşyaları seçelim?
• Set covering (küme örtme): Elimizdeki m gereksinimin tamamını karşılayacak en az sayıda araç/hizmet/eleman nasıl seçilir? Hizmet merkezi yerleştirme, elektrik ağı tasarımı, test kümesi seçimi bu sınıftadır.
• Set partitioning (küme bölüntüleme): Elemanları tam olarak tek bir alt kümeye düşecek şekilde nasıl gruplayalım? Havayolu mürettebat eşleme, araç rotalama sorunlarında kullanılır.
• Matching (eşleme): İki grup arasındaki maksimum kâra ulaşan eşleşmeyi bul.
• Graph coloring (çizge renklendirme): Komşu düğümler farklı renklere sahip olmak üzere minimum renk sayısı.

Klasik örnek — Sırt çantası (Knapsack) problemi: n eşya var; her biri için ağırlık wᵢ ve değer vᵢ biliniyor. Taşıyabileceğimiz maksimum toplam ağırlık W. Hangi eşyaları alırız?

max    Σᵢ vᵢ · xᵢ
s.t.   Σᵢ wᵢ · xᵢ ≤ W
       xᵢ ∈ {0, 1}

Somut örnek: 4 eşya (ağırlık-değer): (2-3), (3-4), (4-5), (5-6); kapasite W=5. Hangi eşyaları alırız? Dört eşya var, bu yüzden 2⁴ = 16 olası alt küme var; küçük bir örnekte bile el hesabı uzar. Çözüm: {x₁=1, x₂=1, x₃=0, x₄=0}, toplam ağırlık 5, toplam değer 7.

Knapsack, BIP’nin ders kitabı örneği olmakla kalmaz, aynı zamanda dinamik programlama ile de çözülebilir (aşağıda DP bölümünde göreceğiz) — kesin yöntemlerin birbirine nasıl bağlandığına güzel bir örnektir. Benzer şekilde “hangi işi kabul edelim?”, “hangi reklamı yayımlayalım?”, “hangi yatırım projesine girelim?” gibi pek çok günlük problem BIP olarak modellenebilir.

Karma Tam Sayı Programlama (Mixed-Integer Programming — MIP)

MIP, LP ile IP/BIP’i aynı model içinde birleştirir: bazı değişkenler sürekli (akış, süre, miktar), bazıları ise tam sayı ya da ikilidir (bir tesis açılacak mı, bir rota seçilecek mi). Gerçek dünya problemlerinin büyük çoğunluğu doğal olarak MIP’tir:

min    cᵀx + dᵀy
s.t.   Ax + By ≤ b
       x ≥ 0,   y ∈ ℤⁿ

MIP çözücüleri son 25 yılda milyon kat performans artışı yaşamış bir alandır; bunun büyük kısmı donanımdan değil algoritmik iyileştirmelerden (daha iyi ön işleme, güçlü kesiler, primal sezgisel ve dallanma stratejileri) gelir. Gurobi, CPLEX ve FICO Xpress gibi araçlar pek çok endüstriyel problemi dakikalar içinde çözer.

MIP modelleri sıkça Big-M tekniği kullanır. “Eğer tesis i açıksa, akış olabilir” tipi mantıksal kuralları doğrusallaştırmak için yapılan klasik hile şudur:

x_ij ≤ M · y_i       (y_i = 0 ise x_ij = 0'a zorlanır; y_i = 1 ise x_ij serbest)

Burada M yeterince büyük bir sabittir. M‘nin çok büyük seçilmesi LP gevşetmesini zayıflatır ve çözümü yavaşlatır; çok küçük seçilmesi gerçek çözümleri dışarıda bırakır. Doğru M seçimi iyi MIP modellemenin sanatıdır.

Klasik örnek — Tedarik zinciri ağ tasarımı: Hangi fabrikaların açılacağı (ikili), hangi fabrikadan hangi dağıtım merkezine ne kadar ürün akacağı (sürekli), hangi kamyon rotalarının kullanılacağı (ikili) kararlarının birleşimi saf bir MIP’dir. Çok katmanlı modelde açma/kapama kararları ile akış kararları aynı anda optimize edilir. Toplam maliyet = sabit açılış maliyetleri + değişken üretim ve taşıma maliyetleri. Kısıtlar: müşteri talebini karşılamak, kapasiteyi aşmamak, sadece açık tesisten akış olmak.

Benzer bir yapı unit commitment (birim taahhüt) probleminde de görülür: Hangi elektrik santrali hangi saatte açık olacak (ikili) ve açıkken ne kadar güç üretecek (sürekli)? Bu problem, Türkiye dahil tüm elektrik piyasalarında günlük olarak çözülür ve piyasa fiyatını belirler.

Dinamik Programlama (Dynamic Programming — DP)

Richard Bellman’ın 1957’de yayımladığı Dynamic Programming kitabında formalize ettiği DP, problemi örtüşen alt problemlere ayıran ve her alt problemi yalnızca bir kere çözerek sonucu ezberleyen bir stratejidir. Kalbinde Bellman’ın meşhur optimallik ilkesi (principle of optimality) yatar:

“Bir optimal politika, başlangıç durumu ve kararı ne olursa olsun, kalan kararların ilk karardan ortaya çıkan duruma göre de optimal bir politika oluşturmasını gerektirir.”

Özyinelemeli bir değer fonksiyonu (value function) ile ifade edilir:

V(s) = min   { g(s, a) + V(T(s, a)) }
       a∈A(s)

Burada s durum, a aksiyon, g anlık maliyet, T geçiş fonksiyonu, V optimal maliyet fonksiyonudur. Durum uzayı sonlu ve ayrık olduğunda DP polinom zamanda optimal politika üretir; sürekli ve yüksek boyutlu durumlarda ise boyutun laneti (curse of dimensionality) devreye girer ve yaklaşık DP (Approximate Dynamic Programming) ya da pekiştirmeli öğrenme (reinforcement learning) yaklaşımlarına geçilir. Aslında modern pekiştirmeli öğrenme doğrudan DP matematiğinin üzerine kuruludur.

DP iki farklı biçimde uygulanabilir:

• Top-down (memoization): Özyinelemeli fonksiyon, önceden hesaplanmış değerleri bir cache’de tutar.
• Bottom-up (tabulation): Taban durumundan başlayarak tablo sistematik olarak doldurulur. Pratikte daha hızlıdır çünkü rekürsiyon yığını yoktur.

Klasik örnek — Knapsack (tekrar): Sırt çantası O(nW) DP ile çözülebilir. f(i, w): ilk i eşya ve ağırlık bütçesi w ile elde edilebilecek maksimum değer.

f(i, w) = max{ f(i-1, w),  f(i-1, w - wᵢ) + vᵢ }

4 eşya ve W=5 için (wᵢ = 2,3,4,5, vᵢ = 3,4,5,6) DP tablosu:

i\w   0  1  2  3  4  5
 0    0  0  0  0  0  0
 1    0  0  3  3  3  3
 2    0  0  3  4  4  7
 3    0  0  3  4  5  7
 4    0  0  3  4  5  7

Hücre f(2,5) = 7: ilk iki eşya ve 5 birim kapasiteyle elde edilebilecek en büyük değer. DP tabloyu aşağıdan yukarıya doldurur; O(nW) zaman ve bellek kullanır.

DP, bilgisayar biliminin tamamen olmazsa olmaz aracıdır. Birkaç yaygın uygulama:

• Fibonacci sayıları: F(n) = F(n-1) + F(n-2). Saf rekürsiyon üstel, DP ile doğrusal.
• En kısa yol (Bellman-Ford): Negatif kenar ağırlıklarıyla çalışan tek klasik en kısa yol algoritması DP tabanlıdır.
• Edit distance (Levenshtein mesafesi): İki metin arasında kaç ekleme/silme/değişiklik var? Otomatik yazım denetiminin ve DNA dizi hizalamanın temeli.
• Matrix chain multiplication: A·B·C·D çarpımını hangi sıralama ile yapalım? Sonuç aynı ama ara hesap sayısı çok farklı.
• Seçenek fiyatlaması: Finansta opsiyon fiyatları geri yönde (backward induction) DP ile hesaplanır.
• Viterbi algoritması: Dijital iletişim ve konuşma tanımada gizli Markov modellerinin en olası yolunu bulur.

Metasezgisel Yöntemler

Kesin yöntemler garantili optimal sağlar; fakat problem boyutu bir yerden sonra “makul” sürelerde çözülebilir olmaktan çıkar. Çizelgeleme, rotalama ve yerleşim gibi NP-zor problemlerin endüstriyel ölçekli örneklerinde “kanıtlanmış optimal” lüks bir hedef hâline gelir; kısa sürede üretilen yeterince iyi bir çözüm yeterlidir. Metasezgisel yöntemler bu boşluğu doldurur: doğadan (evrim, fizik, karınca kolonisi) ya da bilişsel süreçlerden (bellek, öğrenme) esinlenen, genel amaçlı ve problem bağımsız çerçeveler sunarlar.

Her metasezgiselin iki temel bileşenini ayırt etmek önemlidir:

• Keşif (exploration, diversification): Çözüm uzayının geniş bir bölgesini taramak.
• Sömürü (exploitation, intensification): Umut verici bölgeleri detaylıca araştırmak.

Bu iki eğilimin dengesi, algoritmanın yerel minimumlarda takılmadan küresel ölçekte iyi çözümler bulmasını sağlar. Ayarlar yanlış olursa algoritma ya hedefsizce dolaşır (çok fazla keşif) ya da ilk bulduğu yerel minimumda donar (çok fazla sömürü).

Genetik Algoritma (Genetic Algorithm — GA)

John Holland’ın 1975’te yayımladığı Adaptation in Natural and Artificial Systems kitabıyla ana hatları çizilen, David Goldberg’in 1989 kitabıyla da pratikte yaygınlaşan GA, evrim kuramından esinlenen bir topluluk (population) tabanlı aramadır. Her çözüm bir kromozom olarak kodlanır; topluluk her iterasyonda seçim (selection), çaprazlama (crossover) ve mutasyon (mutation) operatörleriyle yenilenir.

1. Rastgele başlangıç topluluğu üret
2. her iterasyon için:
     her kromozomun uygunluk (fitness) değerini hesapla
     turnuva / rulet tekerleği ile ebeveynleri seç
     çaprazlama + mutasyon ile yeni kromozomlar üret
     elitizm: en iyi k bireyi koru
3. durdurma kriteri karşılanınca en iyi kromozomu döndür

Holland’ın çalışmasının teorik kalbi şema teoremidir (schema theorem): İyi kısa “şema”lar (belirli bir bit örüntüsüne sahip kromozom parçaları) topluluğa üstel hızla yayılır. Bu, GA’nın neden işe yaradığının teorik bir açıklamasıdır.

GA’nın gücü, kromozom kodlamasının esnekliğinden gelir:

• İkili kodlama: Knapsack için 0/1 diziler. Çaprazlama tek/çok nokta, mutasyon bit ters çevirme.
• Permütasyon kodlama: TSP için şehir sırası. Standart crossover bozuk permütasyonlar üretir, bu yüzden OX (order crossover), PMX (partially mapped crossover) gibi özel operatörler tasarlanmıştır.
• Gerçek sayı kodlama: Sürekli parametreler için. SBX (simulated binary crossover) ve polinom mutasyon yaygındır.
• Ağaç kodlama (Genetic Programming): Program/fonksiyon sentezi için; yapraklar sabitler/değişkenler, düğümler operatörlerdir.

Seçim operatörünün çeşitli varyantları vardır: turnuva (rastgele birkaç bireyin en iyisini seç), rulet tekerleği (fitness oranlı olasılıkla seç), rank-based (sıralama esaslı olasılık), elitizm (en iyi k bireyi değişiklik yapmadan sonraki kuşağa aktar). Çok amaçlı optimizasyonda klasik GA yerine NSGA-II gibi Pareto-cephe koruyan varyantlar kullanılır.

Klasik örnek — Gezgin satıcı problemi (TSP): n şehri birer kez ziyaret ederek başlangıç şehrine dönen en kısa turu bul. Kromozom permütasyon olarak temsil edilir. Çaprazlama iki ebeveynden alt turları birleştirir; mutasyon iki şehrin sırasını değiştirir. Binlerce şehirli örneklerde GA, saniyeler içinde saf rastgeleden çok daha iyi turlar üretir. TSP aynı zamanda GA, SA, TS ve ACO’nun hepsinin karşılaştırma ortak paydasıdır.

Benzetimli Tavlama (Simulated Annealing — SA)

Kirkpatrick, Gelatt ve Vecchi’nin 13 Mayıs 1983’te Science dergisinde yayımladığı seminer makale, SA’yı optimizasyon dünyasına tanıtmıştır. Fiziksel tavlama sürecinden (bir metalin yavaş soğutularak minimum enerji konfigürasyonuna gelmesi) esinlenen SA, tek çözüm üzerinden yerel arama yapar; fakat yerel minimuma sıkışmamak için kontrollü olarak kötü hareketleri kabul eder.

T ← T₀   (başlangıç sıcaklığı)
x ← x₀   (başlangıç çözümü)
her iterasyon için:
    x' ← komşu(x)
    Δ ← f(x') - f(x)
    if Δ < 0:
        x ← x'                         (daha iyiyi daima kabul et)
    else:
        x ← x' olasılıkla exp(-Δ / T)  (kötüyü bazen kabul et)
    T ← α · T   (0 < α < 1, "soğutma")

Kabul kuralının matematiksel kökeni 1953’te Metropolis ve arkadaşlarının istatistiksel mekanik için önerdiği Metropolis-Hastings algoritmasıdır; kuralın arkasındaki Boltzmann dağılımı, termodinamik dengede bir parçacığın enerji durumlarının olasılıklarını verir. Sıcaklık T yüksekken olasılık 1’e yakın, yani kötü hareket neredeyse her zaman kabul edilir (geniş keşif); T 0’a yaklaşırken olasılık 0’a iner ve algoritma saf tepeye-tırmanma’ya (hill climbing) dönüşür.

Pratikteki kritik parametre, soğutma şemasıdır:

• Geometrik soğutma: T ← α·T, tipik α ∈ [0.8, 0.99]. En yaygını.
• Logaritmik soğutma: T = T₀ / ln(1 + k). Teorik olarak küresel optimali garantiler ama çok yavaştır.
• Adaptif soğutma: İlerleme durumuna göre hız ayarlanır; duraklamada yeniden ısıtma (reheating) uygulanır.

Doğru T₀, α ve durdurma kriteri problem bağımlıdır; ama SA’nın pratikteki popülaritesi, kodlamasının basit olması ve çoğu problemde makul parametrelerle iyi iş çıkarmasıdır.

Klasik örnek — Gezgin satıcı problemi (TSP): Kirkpatrick’in orijinal makalesi TSP üzerinde somut sonuçlar gösterir. Bir permütasyonun “komşusu” genelde iki kenarı ters çeviren 2-opt hareketidir; SA, büyük TSP örneklerinde kısa sürede kaliteli turlar bulur. SA ayrıca kombinatoryal yerleşim problemleri, makine çizelgeleme, hiperparametre ayarı ve yapay sinir ağı eğitimi gibi pek çok alanda başarıyla kullanılır.

SA’nın teorik zarafeti, Hajek’in 1988’de ispatladığı bir yakınsama teoreminde yatar: Soğutma yeterince yavaş olursa (logaritmik soğutma ile) SA sonsuz sürede küresel optimali olasılık 1 ile bulur. Pratikte elbette kimse logaritmik soğutma kullanmaz; geometrik soğutma ile “sonlu sürede çok iyi çözüm” tercih edilir. Çağdaş varyantları arasında paralel tavlama (parallel tempering — birden fazla sıcaklıkta paralel zincirler çalıştırılır ve aralarında değişim yapılır), quantum annealing (D-Wave bilgisayarlarının altyapısı) ve threshold accepting (kötü hareketler olasılıkla değil sabit eşikle kabul edilir) sayılabilir.

Tabu Arama (Tabu Search — TS)

Fred Glover’ın 1986’daki çalışmasıyla tanıtılan ve 1989’da ORSA Journal on Computing‘de “Tabu Search — Part I” başlığıyla formalize ettiği TS’in ayırt edici özelliği bellek (memory) kullanmasıdır: daha önce yapılan hareketleri tabu listesinde tutar ve kısa süreliğine tekrarlanmalarını yasaklar. Bu, yerel minimumdan çıkmayı ve döngülere düşmemeyi sağlar.

x ← x₀
tabu_listesi ← ∅
best ← x
her iterasyon için:
    N(x) \ tabu_listesi içindeki en iyi komşu x'ı seç
    x ← x'
    if f(x) < f(best): best ← x
    tabu_listesi.append(x hareketinin tersine çevrilmesi)
    tabu_listesi FIFO ile güncelle

TS’in zarafeti hiyerarşik bellek yapısındadır:

• Kısa dönem bellek (short-term memory): Son yapılan hareketlerin listesi; yasaklıdır. Döngüleri engeller.
• Orta dönem bellek (intermediate-term memory / intensification): İyi çözümlerin ortak özelliklerini hatırlar; bu bölgelere yoğunlaştırma yapar.
• Uzun dönem bellek (long-term memory / diversification): Nadir ziyaret edilen bölgeleri takip eder; zaman zaman oralara atlar.

Aspirasyon kriteri: Bir hareket tabuda olsa bile, o zamana kadar görülen en iyi çözümü iyileştirecekse yasak kaldırılır. Bu basit kural, TS’in yerel minimuma sıkışmadan küresel olarak ilerleyebilmesinin temelidir. Glover’ın tanıttığı stratejik osilasyon (strategic oscillation) ise çözümün uygun bölge ile uygun olmayan bölge arasında kontrollü geçişler yapmasına izin verir; bazen kısıtları kasıtlı olarak ihlal ederek daha iyi aday çözümlere ulaşılır.

Klasik örnek — Araç rotalama problemi (VRP): Bir depodan çıkan k araçla n müşteriye teslimat yapacağız. Her müşterinin talebi, her aracın kapasitesi ve her rotanın toplam mesafe/zaman kısıtı var. Amaç: toplam kat edilen yolu minimize etmek. TS, 1990’larda klasik VRP üzerinde o dönemin en iyi sonuçlarını üreten yöntemlerden biri olmuştur ve bugün de kargo/lojistik uygulamalarında yaygın şekilde kullanılır. TS ayrıca zaman çizelgesi oluşturma, grafik renklendirme ve uyarlanabilir üretim sistemlerinde de etkilidir.

Karınca Kolonisi Optimizasyonu (Ant Colony Optimization — ACO)

Marco Dorigo’nun 1992’de Politecnico di Milano’da savunduğu Optimization, Learning and Natural Algorithms başlıklı (aslında İtalyanca yazılmış) doktora tezinde tanıttığı ACO, gerçek karıncaların yiyecek arama davranışından esinlenir. Karıncalar yiyecek ile yuva arasında feromon izi bırakır; sonraki karıncalar olasılıksal olarak daha yoğun feromonlu yolları tercih eder; kısa yolların feromonu daha hızlı pekişir ve koloni zamanla en kısa yolu keşfeder. Dorigo’nun tezi sırasında Alberto Colorni ve Vittorio Maniezzo ile yakın çalışması, alanın ilk temel algoritmalarını şekillendirmiştir.

Algoritmik olarak:

feromon matrisi τ_ij'yi başlat
her iterasyon için:
    her karınca k için:
        k'yi rastgele bir düğüme yerleştir
        tur tamamlanana kadar:
            komşu j'ye geçme olasılığı:
                p_ij ∝ τ_ij^α · η_ij^β       (η: sezgisel bilgi, örn. 1/d_ij)
    feromonları güncelle:
        τ_ij ← (1 - ρ) · τ_ij + Σ_k Δτ_ij^k   (ρ: buharlaşma oranı)
        Δτ_ij^k = Q / L_k                     (L_k: karınca k'nın tur uzunluğu)

Parametrelerin anlamı:

• α: feromon ağırlığı. Yüksekse kolektif hafızaya güven; düşükse rastgeleye yakın.
• β: sezgisel bilgi ağırlığı. Yüksekse kısa mesafeyi sever; düşükse sadece feromonla ilerler.
• ρ: buharlaşma oranı. Yüksekse hızlı unutur; düşükse eski bilgi uzun kalır.

ACO’nun çok sayıda varyantı geliştirilmiştir: Ant System (orijinal Dorigo), Elitist Ant System (en iyi turun feromonu ek olarak artırılır), Max-Min Ant System (feromon değerleri bir aralıkta sınırlı tutulur, erken yakınsama engellenir), Ant Colony System (Dorigo ve Gambardella’nın 1997’deki güçlendirilmiş versiyonu; lokal feromon güncellemesi eklendi).

Klasik örnek — Gezgin satıcı problemi (TSP): ACO’nun en yaygın gösterildiği problem TSP’dir. Her iterasyonda koloni farklı turlar deneyerek en kısa yol üzerinde feromonu pekiştirir. ACO ayrıca araç rotalama, çizelgeleme, ağ rotalama ve protein katlanması problemlerinde de yaygın olarak kullanılır. Dağıtık doğası, paralel donanımda iyi ölçeklenmesini sağlar.

Kesin vs. Metasezgisel: Karşılaştırma ve Karar Çerçevesi

Hem kesin hem metasezgisel dünyayı dolaştık; şimdi bir karar çerçevesi kuralım. Aşağıdaki tablo iki yaklaşımın temel niteliklerini karşılaştırır:

Bu karşılaştırma arka planında iki önemli teorik çerçeve vardır. Birincisi karmaşıklık sınıflarıdır (P, NP, NP-zor): P sınıfı polinom zamanda çözülen problemleri, NP sınıfı çözümü polinom zamanda doğrulanabilen problemleri, NP-zor sınıfı ise NP’deki her problemin polinom zamanda kendisine indirgenebildiği problemleri kapsar. Saf IP, knapsack, TSP ve VRP hepsi NP-zordur; bu, problem boyutu büyüdükçe kesin yöntemlerle çözüm zamanının katlanarak artacağı anlamına gelir.

İkincisi ise Wolpert ve Macready’nin 1997’de formülize ettiği No Free Lunch teoremidir: Hiçbir optimizasyon algoritması, tüm problem sınıfları üzerinde ortalama olarak diğerinden daha iyi değildir. Bu, “evrensel en iyi metasezgisel” iddialarını çürüten önemli bir teorik sonuçtır. GA, SA, TS, ACO’nun hepsinin farklı problem sınıflarında farklı güçlü yanları vardır.

Peki pratikte hangisini seçeceğiz? Aşağıdaki akış diyagramı basit bir karar çerçevesi sunar:

Özet: önce problem yapısı, sonra ölçek, en sonunda çözüm süresi tercihi. Problem doğrusal ve küçük–orta ölçekliyse LP/IP/BIP/MIP her zaman ilk tercih; büyüdükçe ve doğrusallık bozuldukça metasezgisel yaklaşımlar sahneye çıkar. DP ise aşamalı karar yapısı olan problemler için özel bir arşimet noktasıdır.

Pratikte dikkat edilmesi gereken tuzaklar:

• Yanlış modelleme: Problem doğrusal değilken LP kurmaya çalışmak ya da tersine, kolayca LP kurulabilecek bir problemi metasezgiselle çözmek yaygın hatalardır. “Bu kısıt gerçekten doğrusal mı?” sorusu ilk adımdır.
• Ölçek iluzyonu: Küçük test örneğinde saniyede biten bir MIP, üretim ölçeğinde saatlerce çalışabilir. Dallanma sayısı değişken sayısıyla üstel olarak artar.
• Parametre hassasiyeti: Metasezgisel yöntemler yanlış parametrelerle optimalin çok uzağında çözümler üretebilir. SA’nın soğutma profili, GA’nın popülasyon çeşitliliği, TS’in tabu liste uzunluğu ve ACO’nun buharlaşma oranı klasik ayar parametreleridir.
• Çok amaçlılık: Gerçek hayatta genelde tek amaç yoktur: “en düşük maliyet” ile “en düşük gecikme” çatışabilir. Tek bir ağırlıklı toplam yerine Pareto-optimal cepheyi aramak daha sağlıklı olabilir.
• Çözümün uygulanabilirliği: Matematiksel olarak optimal bir çözüm operasyonel olarak imkansız olabilir; modele girmeyen yumuşak kısıtlar çoğu zaman kullanıcı çözümü ilk gördüğünde ortaya çıkar ve modelin iyileştirilmesini gerektirir.

Matheuristic: İki Dünyanın Birleşimi

Son yıllarda kesin ve metasezgisel yöntemleri aynı çatı altında kullanan hibrit yaklaşımların adı konmuş: matheuristic. Modern endüstriyel optimizasyonun büyük kısmı aslında saf bir kesin ya da saf bir metasezgisel değil, ikisinin akıllıca birleştirildiği matheuristic’ler üzerine kuruludur.

Tipik şemalar:

• Metasezgisel içinde MIP: GA’nın her kromozomunun fitness’ı, küçük bir MIP’in optimal çözümü ile hesaplanır. Kromozom yüksek seviye kararları (hangi tesisler açık?), MIP düşük seviye detayları (ürün akışları) çözer.
• MIP içinde metasezgisel: Büyük bir MIP’in içinde bir metasezgisel “iyi dallanma yönü” önerir; çözücü alt problemleri optimize eder.
• Large Neighborhood Search (LNS): Mevcut çözümün bir kısmı “yıkılır”, kalan kısım sabit tutularak serbest kısım için küçük bir MIP çözülür.
• Benders decomposition: Büyük MIP iki parçaya ayrılır: master problem (karmaşık kararlar) ve alt problem (ürün akışları). Alt problemin duali ile master’a yeni kısıtlar eklenir.
• Column generation: Çok değişkenli problemlerin (örn. VRP) LP gevşetmesine sadece umut vaat eden değişkenler eklenir. Havayolu mürettebat ve uçak çizelgelemede standarttır.

Pratikte basit bir LNS şablonu:

x ← ilk_cozum()            (MIP çözücü ile hızlı başlangıç)
best ← x
for iter = 1..N:
    S ← x'in %k'lık bir alt kümesini seç
    x'in S dışındaki değişkenlerini sabitle
    MIP çözücüye S'yi serbest bırakarak alt problemi çöz
    x' ← yeni çözüm
    if f(x') < f(best):
        best ← x'
        x ← x'

LNS, metasezgisel bir dış çerçeve (hangi değişkenler yıkılacak?) içinde kesin bir iç çözücünün (alt problemi optimalleştir) çalışmasıdır. Gurobi ve CPLEX’in “solution improvement heuristic” modülleri benzer mantıkla çalışır ve kullanıcı matheuristic yazmadan çözücüde hazır gelir.

Matheuristic yaklaşımları; üretim planlama, enerji ağ optimizasyonu, lojistik, havayolu operasyonları ve şehir planlama gibi geniş bir yelpazede yaygın olarak kullanılır.

Belirsizlik Altında Optimizasyon: Stokastik ve Robust

Şu ana kadar tartıştığımız tüm modeller deterministiktir; yani tüm parametrelerin (talep, maliyet, süre) tam olarak bilindiğini varsaydık. Gerçek hayatta ise parametreler çoğu zaman belirsizdir: yarının müşteri talebi rastgele, hava durumu rastgele, makine arızaları rastgele. Belirsizlikle baş etmek için iki ana çerçeve vardır.

Stokastik programlama (stochastic programming): Belirsiz parametreler olasılık dağılımları ile modellenir; amaç fonksiyonu beklenen değeri (expected value) optimize eder. En yaygın formu iki aşamalı stokastik programlamadır: önce belirsizlik çözülmeden “burada ve şimdi” kararları verilir (kaç kamyon kiralayalım?), sonra belirsizlik gerçekleştikten sonra “recourse” (telafi) kararları verilir (yarın hangi rotaları kullanacağız?). Senaryolar yeteri kadar çok olursa problem çok büyür; Benders ayrıştırması ve sample average approximation (SAA) gibi teknikler bu büyüklüğü yönetir.

Robust optimizasyon: Parametreler için bir “belirsizlik kümesi” tanımlanır ve çözüm bu kümedeki en kötü duruma karşı en iyi olur. 2000’lerde Ben-Tal, Nemirovski ve Bertsimas’ın çalışmalarıyla olgunlaşan bu alan, özellikle finans, enerji ve savunma uygulamalarında tercih edilir: olasılık dağılımını tahmin etmek zorsa ya da “çok ender ama çok kötü” senaryolardan korunmak isteniyorsa robust optimizasyon doğal seçimdir.

Son yıllarda makine öğrenmesi ile OR‘un kesişimi de hızla büyüyor. Prediction + optimization çerçevesi, bir ML modelinin tahminlerinin ardından bir MIP/metasezgisel çözücünün kararları aldığı sıralı boru hattı şeklindedir. “Predict-then-optimize” paradigması ile tahmin hatasının optimizasyon kararı üzerindeki etkisi ortak olarak eğitilir. Bu alan son 5 yılda özellikle perakende talep tahmini, enerji fiyat tahmini ve rotalama gibi uygulamalarda iz bırakmıştır.

Gerçek Hayatta OR: Dikkat Çekici Uygulamalar

Yöneylem araştırması akademik bir konu olmanın çok ötesinde; neredeyse her büyük operasyonel sistemin arkasında sessizce çalışan bir bilimdir. Birkaç ikonik örnek:

• Havayolu şirketleri — Uçak ve mürettebat çizelgelemesi: Büyük havayolları her gün on binlerce uçuş yapar. Hangi uçak hangi bacağı uçacak (fleet assignment), pilot ve kabin ekibi nasıl gruplanacak (crew pairing), bireysel ekip çizelgeleri (crew rostering) ve yolcular bağlantı kaçırırsa hangi uçağa bindirilecek sorularının hepsi dev ölçekli MIP’lerdir. Set partitioning formülasyonu ve column generation bu problemlerin standart çözüm aracıdır.
• Kargo ve lojistik — UPS ORION: UPS, 2013’te sahaya tam olarak sürdüğü ORION (On-Road Integrated Optimization and Navigation) sistemi ile her kuryenin günlük rotasını optimize eder. Sistem yılda milyonlarca dolar yakıt tasarrufu sağladığını açıklamış, ayrıca sürücü başına günlük ortalama kat edilen mesafe düşmüştür. Altında klasik VRP çeşitlemelerinin sezgisel versiyonları yatar.
• E-ticaret — Amazon depo robotları: Amazon’un depolarında Kiva (sonra Amazon Robotics) robotları raf getirirken gerçek zamanlı rotalama ve çarpışma önleme problemi çözer. Depo yerleşimi, ürün-raf atama ve sipariş toplama rotaları sürekli yeniden optimize edilir.
• Ulaştırma — Netflix içerik önbellekleme: Netflix, popüler dizi/film bölümlerini hangi ISP sunucusunda hangi saatte önbelleğe alacağını optimize eder. Bu, bir atama + kapasite problemidir ve arka planda büyük bir LP/MIP olarak çözülür.
• Sağlık — Organ transplant ağları: ABD’deki böbrek takas programları (Kidney Paired Donation), uyumsuz bağışçı-alıcı çiftlerini eşleştirerek çok kişili takas zincirleri oluşturur. Bu bir maksimum ağırlıklı döngü eşlemesi problemidir ve IP ile çözülür; binlerce insanın hayatına dokunmuştur.
• Enerji — Elektrik piyasası optimizasyonu: Türkiye dahil hemen her ülkede saatlik elektrik piyasası bir MIP (unit commitment) olarak çözülür. Fiyatlar doğrudan dualin gölge fiyatlarından türer; ekonomi ve mühendislik iç içedir.
• Spor — Takım ligi fikstürü: Büyük futbol ligleri (Premier League, Bundesliga, Süper Lig) takımların deplasman/iç saha dengesini, derbi tarihlerini, yayın haklarını ve stadyum çakışmalarını aynı anda tatmin eden fikstürleri CP/MIP hibrit araçlarıyla oluşturur.
• Afet ve salgın lojistiği — COVID-19 aşı dağıtımı: 2020-2021’de COVID-19 aşılarının soğuk zincir lojistiği, aşıların hangi depolara gideceği, hangi merkezlere sevk edileceği, öncelikli grupların nasıl randevulanacağı devasa OR problemleriydi. Pfizer-BioNTech ve AstraZeneca’nın tedarik zinciri arkasında MIP modelleri vardı.

Bu örnekler OR’un soyut bir matematik egzersizi değil, günlük hayatın temel altyapısını şekillendiren bir mühendislik disiplini olduğunu göstermektedir. Çözülen her problemin ardında hem bir iş paydaşı hem de özel olarak ayarlanmış bir model vardır.

Pratikte Hangi Araçlar Kullanılır?

Bir OR modelini çözmek için hangi aracı seçeceğiniz, problemin türüne, bütçenize ve kullandığınız programlama diline bağlıdır.

Ticari MIP çözücüleri:

• Gurobi: Günümüzün en hızlı ticari MIP çözücülerinden biri. Akademik lisans ücretsizdir.
• IBM CPLEX: Uzun yıllardır sektörün referans noktalarından biri.
• FICO Xpress: Özellikle finans ve enerji sektörlerinde yaygın.

Bu araçlar MIP, LP, quadratic programming ve bazı non-linear programming türlerini çözer; C/C++, Python, Java ve başka diller için API sunar.

Açık kaynak çözücüler:

• HiGHS: Modern, açık kaynak LP/MIP çözücüsü; performansı giderek ticari rakiplerine yaklaşıyor.
• COIN-OR (CBC/CLP): Olgun ve geniş kapsamlı bir koleksiyon.
• Google OR-Tools: LP, MIP, kısıt programlama ve rotalama için birleşik API.
• SCIP: Akademik lisanslı, güçlü bir dal-ve-kesme çözücüsü.
• Pyomo, JuMP: Python ve Julia için modelleme dilleri; arka uçta birçok çözücüye bağlanabilir.

Metasezgisel kütüphaneler:

• DEAP (Python): GA ve evrimsel hesaplama için esnek bir çerçeve.
• simanneal (Python): SA için minimal ve anlaşılır bir kütüphane.
• scikit-opt (Python): GA, SA, PSO, TSP çözümlerini tek paket altında sunar.
• jMetal (Java / Python): Çok amaçlı metasezgisellerin referans koleksiyonu.

Tipik bir tercih akışı şöyledir: Problem küçük-orta ve LP/MIP yapısındaysa, Pyomo ya da JuMP ile modellenip HiGHS veya akademik Gurobi ile çözülür. Problem büyük ve metasezgisel gerekiyorsa DEAP veya simanneal ile hızlı bir prototip yapılır; çalıştıktan sonra ihtiyaca göre optimize edilir ya da matheuristic’e dönüştürülür.

Sonuç

Yöneylem araştırması, üretimden lojistiğe, sağlıktan finansa pek çok gerçek dünya problemini çözen olgun ve kanıtlanmış bir disiplindir. Özetle:

• Kesin yöntemler (LP, IP, BIP, MIP, DP) garantili optimal sağlar ve doğru araçla milyonlarca değişkenli modeller bile rutin olarak çözülebilir. Üretim karışımı, atama, tesis yerleşimi, tedarik zinciri ve aşamalı karar problemlerinde ilk tercih olmalıdır.
• Metasezgisel yöntemler (GA, SA, TS, ACO) optimallik garantisi vermez ama büyük, NP-zor ya da simülasyon tabanlı problemlerde makul sürede yüksek kaliteli çözümler üretir.
• Matheuristic yaklaşımlar ise iki dünyanın en iyilerini birleştirir ve modern endüstriyel optimizasyonun büyük kısmı aslında bu hibritler üzerine kuruludur.

Pratik öneri: Yeni bir optimizasyon problemiyle karşılaştığınızda önce modelleyin. Karar değişkenleri, amaç fonksiyonu ve kısıtları yazın. Model doğrusal/karma-tam sayı yapıya oturuyor ve orta ölçekliyse doğrudan bir MIP çözücü deneyin. Çözücü süre ya da bellek sınırına takılıyorsa matheuristic kurun; hiçbir matematiksel yapı çıkmıyorsa metasezgisel çerçeveyle (GA/SA/TS/ACO) ilerleyin. Her durumda, çözümün iş değeri için “yeterlilik eşiği” (ne kadar yakın optimal yeterli?) en baştan tanımlanmalıdır; bu eşik, yöntem seçimi için amaç fonksiyonundan sonraki en önemli girdidir.

Optimizasyon problemleri gündelik hayatta saklı hâlde karşımıza sürekli çıkar. Formel OR bakış açısı, bu problemleri sezgiyle değil matematikle çözmemizi, çözümlerin kalitesini ölçmemizi ve iş süreçlerinde kanıtlanabilir iyileşmeler yapmamızı sağlar. Bir sonraki “hangi iş önce?”, “hangi rota en iyi?”, “hangi karışımı üretelim?” sorusunu duyduğunuzda, kulağınızın arkasında bu yazıdaki tabloyu hatırlayın.

Daha fazla okuma için: Richard Bellman’ın Dynamic Programming (1957), David Goldberg’in Genetic Algorithms in Search, Optimization and Machine Learning (1989) ve Marco Dorigo ile Thomas Stützle’nin Ant Colony Optimization (2004) kitapları alanın klasikleri arasındadır. Tarihsel arka plan için Patrick Blackett’ın savaş dönemi OR ekipleri ve George Dantzig’in doğrusal programlamayı geliştirdiği Pentagon yıllarına odaklanan INFORMS’un History of O.R. Excellence serisi güzel bir başlangıçtır.

Bu yazıda MISRA C:2012’den (ve 2023 düzeltme paketi olan MISRA C:2023’ten) bu yana nelerin değiştiğini, yeni eklenen kuralları, kaldırılan ve devre dışı bırakılan kuralları, kod örnekleriyle detaylı şekilde inceleyeceğiz.

Kısa Bir Tarihçe

MISRA C:2025, devrimsel bir değişiklik yerine evrimsel bir iyileştirme sunuyor. MISRA C:2023’ün getirdiği çoklu iş parçacığı (multithreading) ve atomik tip desteğinin üzerine, 4 yeni kural, 2 silinen kural, 1 devre dışı bırakılan kural ve 69 diğer düzenleme ile toplam 79 değişiklik içeriyor.

Yeni Kurallar

MISRA C:2025 ile birlikte 4 yeni kural eklendi. Her birini örneklerle inceleyelim.

Kural 8.18 — Başlık Dosyalarında Belirsiz Tanımlara (Tentative Definition) İzin Verilmez

Sınıflandırma: Required (Zorunlu)

C dilinde, bir değişken herhangi bir ilk değer (initializer) olmadan ve extern anahtar kelimesi kullanılmadan tanımlanırsa, bu bir belirsiz tanım (tentative definition) olarak kabul edilir. Eğer bu tanım bir başlık dosyasında yer alırsa ve bu dosya birden fazla derleme biriminde (#include ile) dahil edilirse, bağlayıcı (linker) hataları veya beklenmeyen davranışlar ortaya çıkabilir.

/* config.h - başlık dosyası */

/* Uyumsuz (Non-compliant): Belirsiz tanım */
int32_t global_counter;

/* Uyumlu (Compliant): extern bildirimi */
extern int32_t global_counter;

Neden önemli? Belirsiz tanımlar, hem tanımlama (definition) hem de bildirim (declaration) gibi davranır. Birden fazla .c dosyası aynı başlık dosyasını dahil ettiğinde, aynı değişkenin birden fazla kopyası oluşabilir:

/* modul_a.c */
#include "config.h"   /* global_counter burada tanımlanır */

/* modul_b.c */
#include "config.h"   /* global_counter burada da tanımlanır! */

/* Sonuç: Bağlayıcı hatası veya tanımsız davranış */

Doğru yaklaşım, değişkeni yalnızca bir .c dosyasında tanımlamak ve başlık dosyasında extern ile bildirmektir:

/* config.h */
extern int32_t global_counter;  /* Sadece bildirim */

/* config.c */
#include "config.h"
int32_t global_counter = 0;     /* Gerçek tanım burada */

Kural 8.19 — Kaynak Dosyalarında Harici Bildirim Yapılmamalıdır

Sınıflandırma: Advisory (Tavsiye)

Bu kural, extern bildirimlerinin .c dosyaları içinde değil, yalnızca başlık dosyalarında yapılması gerektiğini belirtir. Kaynak dosya içinde yapılan extern bildirimleri, gizli bağımlılıklar oluşturur ve kodun bakımını zorlaştırır.

/* Uyumsuz (Non-compliant): .c dosyasında extern bildirimi */
void sensor_oku(void) {
    extern int32_t kalibrasyon_degeri;  /* Gizli bağımlılık! */
    int32_t sonuc = ham_deger + kalibrasyon_degeri;
}

/* Uyumlu (Compliant): Başlık dosyasında bildirim */

/* kalibrasyon.h */
extern int32_t kalibrasyon_degeri;

/* sensor.c */
#include "kalibrasyon.h"
void sensor_oku(void) {
    int32_t sonuc = ham_deger + kalibrasyon_degeri;
}

Neden önemli? Bir fonksiyon gövdesi içindeki extern bildirimi, o değişkenin nereden geldiğini gizler. Kod incelemesi sırasında bağımlılıklar kolayca gözden kaçabilir. Başlık dosyası kullanıldığında ise bağımlılık açıkça görülür ve derleyici tip uyumsuzluklarını yakalayabilir.

Kural 11.11 — İşaretçiler Dolaylı Olarak NULL ile Karşılaştırılmamalıdır

Sınıflandırma: Advisory (Tavsiye)

C dilinde bir işaretçi, if koşulunda doğrudan kullanıldığında dolaylı olarak boolean’a dönüştürülür. Bu, işaretçinin NULL olup olmadığını kontrol eder ama niyet belirsiz kalır. MISRA C:2025, işaretçi karşılaştırmalarının açık (explicit) yapılmasını tavsiye eder.

int32_t *ptr = fonksiyon_cagir();

/* Uyumsuz (Non-compliant): Dolaylı karşılaştırma */
if (ptr) {
    /* ... */
}

/* Uyumsuz (Non-compliant): Dolaylı karşılaştırma */
if (!ptr) {
    /* ... */
}

/* Uyumsuz (Non-compliant): Dolaylı tür dönüşümü */
bool gecerli = (bool)ptr;

/* Uyumlu (Compliant): Açık karşılaştırma */
if (ptr != NULL) {
    /* ... */
}

/* Uyumlu (Compliant): Açık karşılaştırma */
if (ptr == NULL) {
    /* ... */
}

Neden önemli? Açık karşılaştırma, kodun niyetini belgeliyor. if (ptr) yazdığınızda okuyucu, bunun bir boolean değer mi yoksa NULL kontrolü mü olduğunu anlamak için bağlamı incelemeye zorlanır. if (ptr != NULL) ise amacı doğrudan ifade eder. Bu kural, MISRA’nın temel tip modeli (essential type model) ile de uyumludur: işaretçiler boolean değildir.

Kural 19.3 — Bir Union Elemanı, Daha Önce Ayarlanmadıysa Okunamaz

Sınıflandırma: Required (Zorunlu)

Union’lar C dilinde bellekte aynı alanı paylaşan farklı türleri temsil eder. Bir eleman üzerinden yazıp farklı bir eleman üzerinden okumak tanımsız davranışa (undefined behavior) yol açabilir, çünkü bellek düzeni platforma bağlıdır.

union veri {
    int32_t tamsayi;
    float   ondalik;
};

union veri d;

/* Uyumlu (Compliant): Yazılan eleman okunuyor */
d.tamsayi = 42;
int32_t x = d.tamsayi;      /* OK: Aynı eleman */

/* Uyumsuz (Non-compliant): Farklı eleman okunuyor */
d.tamsayi = 42;
float y = d.ondalik;         /* Tanımsız davranış! */

Bu tür bir kullanım, özellikle type punning (tür hilesi) olarak bilinen teknikte karşımıza çıkar:

/* Tehlikeli: IEEE 754 bitlerini okuma girişimi */
union {
    float   f;
    uint32_t u;
} pun;

pun.f = 3.14f;
uint32_t bits = pun.u;  /* Uyumsuz: Tanımsız davranış */

/* Güvenli alternatif: memcpy kullanımı */
float f = 3.14f;
uint32_t bits_guvenli;
memcpy(&bits_guvenli, &f, sizeof(bits_guvenli));

Neden önemli? Union üzerinden type punning, platformdan platforma farklı sonuçlar üretebilir (endianness, hizalama, padding). memcpy kullanımı hem taşınabilir hem de derleyici optimizasyonları açısından güvenlidir.

Silinen Kurallar

MISRA C:2025 ile birlikte 2 kural silinmiştir. Silinen kural numaraları gelecekte yeniden kullanılmayacaktır; bu, eski sürümlerle karışıklığı önlemek için alınmış bilinçli bir karardır.

Silinen kurallardan biri Kural 21.2‘dir. Bu kuralın kapsadığı konular artık diğer kurallar tarafından karşılanmaktadır.

Devre Dışı Bırakılan Kural: 15.5 — Tek Çıkış Noktası

MISRA C:2025’in belki de en dikkat çekici değişikliği, uzun süredir tartışmalı olan Kural 15.5‘in (tek çıkış noktası — single point of exit) devre dışı bırakılmasıdır (disapplied).

Bu kural, bir fonksiyonun yalnızca tek bir return ifadesi içermesi gerektiğini zorunlu kılıyordu:

/* Eski yaklaşım: Tek çıkış noktası (Kural 15.5'e uyumlu) */
int32_t bul(const int32_t *dizi, size_t boyut, int32_t hedef) {
    int32_t sonuc = -1;

    for (size_t i = 0u; i < boyut; i++) {
        if (dizi[i] == hedef) {
            sonuc = (int32_t)i;
            break;
        }
    }

    return sonuc;  /* Tek çıkış noktası */
}

/* Yeni yaklaşım: Erken dönüş artık kabul edilebilir */
int32_t bul(const int32_t *dizi, size_t boyut, int32_t hedef) {
    for (size_t i = 0u; i < boyut; i++) {
        if (dizi[i] == hedef) {
            return (int32_t)i;  /* Erken dönüş */
        }
    }

    return -1;
}

Neden devre dışı bırakıldı? Modern yazılım geliştirme pratiğinde, erken dönüşlerin kodun okunabilirliğini ve bakımını kolaylaştırdığı yaygın olarak kabul görmektedir. Tek çıkış noktası kuralı, özellikle hata kontrolü gereken fonksiyonlarda gereksiz iç içe geçmelere ve karmaşık kontrol akışlarına neden oluyordu:

/* Tek çıkış noktası ile karmaşık hata kontrolü */
int32_t dosya_isle(const char *yol) {
    int32_t sonuc = HATA_BILINMEYEN;
    FILE *fp = fopen(yol, "r");

    if (fp != NULL) {
        char *tampon = malloc(TAMPON_BOYUT);
        if (tampon != NULL) {
            if (fread(tampon, 1, TAMPON_BOYUT, fp) > 0u) {
                sonuc = veriyi_isle(tampon);
            } else {
                sonuc = HATA_OKUMA;
            }
            free(tampon);
        } else {
            sonuc = HATA_BELLEK;
        }
        fclose(fp);
    } else {
        sonuc = HATA_DOSYA;
    }

    return sonuc;  /* Derin iç içe geçme! */
}

/* Erken dönüş ile aynı fonksiyon — çok daha okunabilir */
int32_t dosya_isle(const char *yol) {
    FILE *fp = fopen(yol, "r");
    if (fp == NULL) {
        return HATA_DOSYA;
    }

    char *tampon = malloc(TAMPON_BOYUT);
    if (tampon == NULL) {
        fclose(fp);
        return HATA_BELLEK;
    }

    int32_t sonuc;
    if (fread(tampon, 1, TAMPON_BOYUT, fp) > 0u) {
        sonuc = veriyi_isle(tampon);
    } else {
        sonuc = HATA_OKUMA;
    }

    free(tampon);
    fclose(fp);
    return sonuc;
}

Dikkat: IEC 61508 ve ISO 26262 gibi fonksiyonel güvenlik standartları hâlâ tek çıkış noktası yaklaşımını talep edebilir. MISRA C:2025, bu kuralı silmek yerine devre dışı bırakarak, ihtiyaç halinde yeniden etkinleştirilebilir kılmıştır.

Mevcut Kurallardaki Önemli Güncellemeler

İşaretçi Dönüşüm Kuralları: 11.3, 11.4, 11.6

Bu kurallar, intptr_t ve uintptr_t türlerini hesaba alacak şekilde güncellendi. Artık tamsayılar ile adreslerin tamsayı temsili arasında daha fazla dönüşüm imkanı sunuluyor:

#include <stdint.h>

void *ptr = get_address();

/* MISRA C:2012'de sorunlu olabilirdi */
uintptr_t addr = (uintptr_t)ptr;

/* İşlem yap (örn: hizalama kontrolü) */
if ((addr & 0x3u) != 0u) {
    /* Hizalanmamış adres */
}

/* MISRA C:2025'te intptr_t ailesi ile dönüşüm açıkça destekleniyor */
ptr = (void *)addr;

Bu değişiklik özellikle düşük seviyeli sistem programlama, işaretçi etiketleme (pointer tagging) ve donanım kayıt adresleriyle çalışma gibi senaryolarda önemlidir.

Direktif 4.6 — Kayan Nokta Türleri Kapsam Dışı

Direktif 4.6, daha önce uygulama tanımlı (implementation-defined) davranışa sahip temel türlerin yerine boyut belirten türlerin (int32_t, uint16_t vb.) kullanılmasını öneriyordu. MISRA C:2025’te kayan nokta türleri bu direktifin kapsamından çıkarılmıştır. Bunun nedeni, float ve double türlerinin IEEE 754 ile zaten standartlaştırılmış olması ve boyut belirten kayan nokta alternatiflerinin yaygın olmamasıdır.

Switch-Case Yapısında Esneklik

MISRA C:2025’te switch-case yapılarındaki kural güncellemeleriyle, bir case bloğu artık yalnızca break ile değil, return, continue veya abort() gibi ifadelerle de sonlandırılabilir. Bu, daha önce erişilemez kod (unreachable code) uyarılarına neden olan gereksiz break ifadelerini ortadan kaldırır:

/* MISRA C:2012: break zorunlu, return sonrası break gereksiz */
switch (komut) {
    case KOMUT_OKU:
        return veri_oku();
        break;           /* Erişilemez kod uyarısı! */
    case KOMUT_YAZ:
        veri_yaz();
        break;
    default:
        abort();
        break;           /* Erişilemez kod uyarısı! */
}

/* MISRA C:2025: return ve abort() yeterli */
switch (komut) {
    case KOMUT_OKU:
        return veri_oku();   /* break gerekmez */
    case KOMUT_YAZ:
        veri_yaz();
        break;
    default:
        abort();             /* break gerekmez */
}

Temel Tip Modeli (Essential Type Model) Güncellemesi

MISRA C’nin temel tip modeli, C dilinin örtük tür dönüşümlerinden kaynaklanan hataları önlemek için tasarlanmıştır. MISRA C:2025 ile bu modele yeni bir kategori eklendi: “essentially complex floating” (temel olarak karmaşık kayan nokta).

C11 ile birlikte gelen _Complex türleri (örneğin double _Complex) artık temel tip modelinde kendi kategorilerine sahip. Bu, karmaşık sayı işlemlerinde tür dönüşüm kurallarının doğru uygulanmasını sağlıyor.

Ayrıca yukarıda bahsedilen Kural 11.11, temel tip modelini işaretçi-boolean etkileşimlerine genişletiyor. İşaretçiler artık dolaylı olarak boolean gibi değerlendirilemez — bu, modelin kapsamını genişleten önemli bir adım.

MISRA C:2025 ve Rust: Addendum 6

MISRA C:2025 ile birlikte yayınlanan Addendum 6 (ADD6), dikkat çekici bir şekilde MISRA C kurallarının Rust programlama diline uygulanabilirliğini değerlendiriyor. Bu, emniyet kritik sistemlerde Rust’ın artan kullanımına MISRA’nın verdiği ilk resmi yanıttır.

ADD6, MISRA C kurallarından hangilerinin Rust’ta doğal olarak karşılandığını (ownership sistemi, borrow checker sayesinde), hangilerinin alakasız olduğunu ve hangilerinin Rust’ta da dikkat gerektirdiğini haritalıyor. Bu, C’den Rust’a geçiş düşünen emniyet kritik projeler için değerli bir referans belgesi niteliğinde.

Yapısal Değişiklikler

MISRA C:2025, kural organizasyonunda da önemli yenilikler getirdi:

Dikkat çeken yapısal yenilikler:

• “Silindi” ve “Devre dışı” kategorileri ilk kez tanımlandı. Bu, eski kural numaralarının yeniden kullanılmasını engelliyor ve sürümler arası geçişi kolaylaştırıyor.
• Bazı kurallar direktife, bazı direktifler kurala dönüştürüldü — daha doğru sınıflandırma için.
• 3 kural daha uygun bölümlere taşındı.
• Sürekli yayın modeli (rolling release) benimsendi. Artık bağımsız düzeltme paketleri (amendment) yerine, güncellemeler doğrudan yeni sürüm numaralarıyla yayınlanacak.

MISRA C:2025’e Geçiş Stratejisi

Halihazırda MISRA C:2012 veya MISRA C:2023 kullanan projeler için geçiş nispeten kolaydır:

1. Statik analiz araçlarınızı güncelleyin. Perforce QAC, LDRA, Parasoft, Polyspace gibi büyük araç sağlayıcıları MISRA C:2025 desteğini eklemeye başlamıştır.

2. Yeni kuralları değerlendirin. Özellikle Kural 8.18 ve 19.3 (Required) zorunlu olduğundan, mevcut kodunuzda ihlal olup olmadığını kontrol edin.

3. Kural 15.5 politikanızı gözden geçirin. MISRA artık tek çıkış noktası gerektirmese de, projenizin bağlı olduğu fonksiyonel güvenlik standardı (IEC 61508, ISO 26262, DO-178C) bunu gerektiriyor olabilir.

4. intptr_t kullanımınızı gözden geçirin. Kural 11.3, 11.4 ve 11.6’daki değişiklikler, düşük seviyeli donanım erişimi olan kodlarda daha fazla esneklik sağlayabilir.

5. Addendum 6’yı inceleyin. MISRA C:2025 ADD6, kuralların Rust programlama diline uygulanabilirlik eşlemesini içerir — özellikle C’den Rust’a geçiş düşünen projeler için değerlidir.

Sonuç

MISRA C:2025, köklü bir devrim değil ama önemli bir evrim. Yeni kurallar gerçek dünya sorunlarını hedefliyor: başlık dosyalarındaki belirsiz tanımlar, gizli extern bağımlılıkları, dolaylı NULL karşılaştırmaları ve union’ların güvensiz kullanımı.

Belki de en önemlisi, tek çıkış noktası kuralının devre dışı bırakılması, MISRA’nın modern yazılım geliştirme pratiklerine uyum sağlama iradesini gösteriyor.

C dili, emniyet kritik sistemlerde hâlâ baskın konumda ve MISRA C bu dilde güvenli kod yazmak için en kapsamlı kılavuz olmaya devam ediyor. MISRA C:2025 ile birlikte gelen C23/C24 desteği hazırlığı da, bu kılavuzun geleceğe dönük yol haritasının net olduğunu gösteriyor.

Kaynaklar:

• MISRA C:2025, Motor Industry Software Reliability Association, Mart 2025
• Perforce — What Developers Need to Know About MISRA C:2025
• LDRA — MISRA C 2025: The whys and wherefores of what’s new
• Qt — MISRA C:2025: A closer look at some of the changes
• Parasoft — MISRA C 2025: Safer Embedded Code for AI and Rust
• Sanctuary Software — MISRA C:2025 New Guidelines for Critical Systems