Skip to main content

Etiket: MATLAB

MATLAB & Simulink ile Reinforcement Learning İş Akışları

Bir makine öğrenmesi modeline bir görüntü verip içindeki nesneyi tanımasını istediğimizde, problem çoğunlukla tek adımlı bir eşleştirme olarak ele alınabilir: model bir girdi alır ve bir çıktı üretir. Reinforcement learning (RL) problemlerinde ise verilen karar yalnızca o anki sonucu değil, sistemin daha sonra karşılaşacağı durumları da değiştirir. Bu nedenle amaç tek bir doğru çıktıyı tahmin etmek değil, zaman içinde iyi sonuçlar üreten bir karar verme stratejisi öğrenmektir.

Bir robotun uyguladığı tork, otonom bir aracın direksiyon komutu veya bir enerji sistemindeki kaynak tahsisi sistemin bir sonraki durumunu etkiler. Seçilen karar sonraki ölçümleri ve gelecekte kullanılabilecek kararları da değiştirdiği için her adımı birbirinden bağımsız değerlendirmek yeterli olmaz. RL tam olarak bu tür ardışık karar verme problemlerine odaklanır.

Bu yazıda önce RL’nin ne olduğunu ve hangi problemlerde anlamlı bir seçenek haline geldiğini ele alacağız. Ardından MATLAB, Simulink ve Reinforcement Learning Toolbox kullanarak bir RL çözümünün ortam tasarımından ödül tanımına, ajan seçiminden eğitime, testten deployment’a kadar nasıl geliştirilebileceğini adım adım inceleyeceğiz.

Reinforcement Learning Nedir?

Reinforcement learning, bir agent’ın(ajanın) bir ortam ile tekrar tekrar etkileşime girerek bir görevi öğrenmesini sağlayan makine öğrenmesi yaklaşımıdır. Ajan her karar anında ortam hakkında bir gözlem alır, mevcut davranış stratejisi olan politika üzerinden bir eylem seçer ve yaptığı seçimin sonucunda sayısal bir reward(ödül) elde eder. Eğitim algoritması bu deneyimleri kullanarak politikayı zaman içinde geliştirir.

Buradaki amaç yalnızca o anda en yüksek ödülü getiren eylemi seçmek değildir. Ajan, kararların gelecekte oluşturacağı sonuçları da hesaba katarak uzun vadeli toplam ödülü yükseltmeye çalışır. Örneğin bir robotun hedefe çok hızlı ilerlemesi kısa vadede olumlu görülebilir; ancak bu hareket birkaç adım sonra robotun devrilmesine neden oluyorsa uzun vadede iyi bir davranış değildir.

Bu süreci köpek eğitimi üzerinden düşünmek kavramları daha anlaşılır hale getirir. Eğitmen bir komut verir, köpek çevresini gözlemler ve bir davranışta bulunur. Doğru davranış ödüllendirilir; ilgisiz veya istenmeyen davranış ise ödül getirmez. Bu süreç tekrarlandıkça köpek hangi durumda nasıl davranması gerektiğini öğrenir.

Köpek eğitimiReinforcement learning
KöpekAjan
Eğitmen, komutlar ve çevreOrtam
Köpeğin gördüğü ve duyduğu bilgilerGözlem
Köpeğin gerçekleştirebildiği davranışlarEylem
Ödül maması veya övgüÖdül
Köpeğin mevcut davranış stratejisiPolitika

Bir RL sisteminde eğitim ve dağıtım aşamalarını birbirinden ayırmak önemlidir. Eğitim sırasında ajan ortam ile etkileşir, farklı eylemler dener ve politikayı günceller. Eğitim tamamlandığında ise gerçek sistemde çoğunlukla yalnızca eğitilmiş politika kullanılır: politika gözlemi alır ve eylem üretir. Deneme-yanılma, keşif ve öğrenme algoritması eğitim sürecine aittir.

Kontrol sistemleri açısından bakıldığında ortam sisteme, gözlem ölçümlere, eylem manipüle edilmiş değişkene ve politika kontrolcüye benzetilebilir. Ödül ise takip hatası, enerji tüketimi, süre veya kısıt ihlali gibi mühendislik hedeflerini öğrenme problemine taşır. Bu benzerlik RL’yi geleneksel kontrolle aynı yöntem yapmaz; ancak kontrol mühendisleri için güçlü bir zihinsel model sağlar.

Ne Zaman Reinforcement Learning Kullanmalıyız?

RL güçlü bir yaklaşım olsa da her makine öğrenmesi, kontrol veya optimizasyon problemi için doğru başlangıç noktası değildir. Öncelikle problemin gerçekten ardışık kararlar içerip içermediğine bakılmalıdır. Bir eylem sistemin gelecekteki durumunu ve sonraki kararları etkiliyorsa RL anlamlı bir aday olabilir. Robotik, otonom sistemler, süreç kontrolü, çizelgeleme ve kaynak yönetimi bu yapıya sahip problemlerdir.

RL özellikle her durum için doğru eylemi gösteren etiketli verinin bulunmadığı, ancak ortaya çıkan davranışın başarısının ölçülebildiği durumlarda değerlidir. Örneğin bir robot kolunun her sensör ölçümü için doğru motor torkunu etiketlemek zor olabilir. Buna karşılık hedefe uzaklık, hareket süresi, enerji tüketimi ve güvenlik ihlalleri sayısal olarak ölçülebilir. RL bu ölçütleri ödül üzerinden kullanarak uygun davranışı etkileşim yoluyla öğrenebilir.

Kararların etkisi gecikmeli ortaya çıkıyorsa RL’nin uzun vadeli optimizasyon yaklaşımı ayrıca önem kazanır. Bununla birlikte eğitim için yeterli etkileşim üretilebilmesi gerekir. Gerçek sistem üzerinde binlerce deneme yapmak pahalı veya tehlikeli olabileceğinden çoğu mühendislik uygulamasında hızlı ve güvenilir bir simülasyon ortamı kritik rol oynar. Uygun durumlarda daha önce toplanmış deneyimler çevrimdışı eğitim için de kullanılabilir.

Öte yandan problem tek bir girdiden bağımsız bir tahmin üretmekse denetimli öğrenme daha doğal bir seçimdir. Geleneksel PID, LQR, MPC veya matematiksel optimizasyon yöntemi gerekli performansı ve garantileri zaten sağlıyorsa RL ek karmaşıklık yaratabilir. Benzer şekilde güvenli keşif mümkün değilse, ödül gerçek hedefi temsil edemiyorsa veya çözüm kapsamlı biçimde test edilemiyorsa RL ilk tercih olmamalıdır.

RL’nin kullanılması geleneksel kontrolün tamamen kaldırılması anlamına da gelmez. RL yüksek seviyeli planlama, referans üretme veya mode seçimi görevini üstlenirken düşük seviyeli kontrol doğrulanmış bir kontrolcü tarafından yapılabilir. RL eylemleri güvenlik filtresinden geçirilebilir, gerektiğinde yedek kontrolcüye geçilebilir veya ajan yalnızca mevcut kontrolcünün komutuna küçük bir düzeltme ekleyebilir. Pratikte doğru soru çoğu zaman “RL mi, klasik kontrol mü?” değil, “Sistemin hangi karar katmanında RL kullanmak anlamlı?” sorusudur.

Reinforcement Learning İş Akışı

Bir RL projesi yalnızca uygun algoritmayı seçip eğitim başlatmaktan oluşmaz. Ortamın nasıl modellendiği, ajanın hangi bilgileri gördüğü, ödülün neyi teşvik ettiği ve eğitilmiş politikanın nasıl doğrulandığı en az algoritma kadar önemlidir.

Bu yazıda iş akışını altı temel adım üzerinden ele alacağız:

Şekil 1. Reinforcement learning geliştirme iş akışı (MathWorks)

Bu süreç tamamen doğrusal değildir. Test sonuçları yetersiz olduğunda gözlem ve eylem tanımları, ödül, çevre modeli, ajan veya eğitim ayarları değiştirilerek önceki adımlara dönülür. Dağıtım sonrasında gerçek sistemden elde edilen bulgular da aynı tasarım döngüsünü yeniden başlatabilir.

MATLAB ve Simulink ile İş Akışının Adımları

Ortam Tasarlama

Ortam, ajanın eylemlere karşılık sistemin nasıl değiştiğini hesaplar ve her adımda yeni gözlem, ödül ve bölüm sonlandırma bilgisini üretir. Bu nedenle ilk iş, ajan ile ortam arasındaki arayüzü açık biçimde tanımlamaktır.

Gözlem, ajanın karar verirken kullanacağı bilgileri içerir. Kontrol uygulamalarında ölçülen sistem durumları, referans ile ölçüm arasındaki hata, geçmiş değerler, operasyon koşul bilgileri veya önceki eylem gözleme eklenebilir. Eksik gözlem, birbirine benzeyen iki durumda farklı kararlar gerekmesine rağmen ajanın bu farkı görememesine neden olur. Gereksiz gözlem ise network’ü büyütebilir ve eğitimi zorlaştırabilir.

Eylem, ajanın verebileceği karardır. Bu karar doğrudan tork, voltaj veya direksiyon komutu olabileceği gibi geleneksel bir kontrolcü için referans, kontrolcü kazancı, mod seçimi ya da kaynak tahsisi kararı da olabilir. Eylem uzayının ayrık veya sürekli olması, daha sonra kullanılabilecek ajan seçeneklerini doğrudan etkiler.

Ortam gerçek donanım olabilir; ancak deneme-yanılma tabanlı eğitim çoğunlukla doğrudan donanım üzerinde yürütülmez. Sistem dinamiği diferansiyel denklemler veya özel algoritmalarla ifade edilebiliyorsa MATLAB fonksiyonları ve sınıfları ile ortam oluşturulabilir. Fiziksel sistem, sensör, aktüatör, kontrolcü ve mod mantığı içeren daha kapsamlı sistemlerde Simulink daha doğal bir seçenek sunar. Simscape ise mekanik, elektrik, hidrolik ve çok cisimli fiziksel sistemlerin aynı simülasyon içinde modellenmesini kolaylaştırır.

Simülasyon modelinin mümkün olduğunca ayrıntılı olması her zaman daha iyi değildir. Çok basit bir model gerçek davranışı temsil etmeyebilir; gereğinden ayrıntılı bir model ise her bölümü yavaşlatarak eğitim süresini büyütür. Başlangıçta görevi öğrenmek için gerekli dinamikler kullanılmalı, testlerde ortaya çıkan model eksikleri kontrollü biçimde eklenmelidir.

Şekil 2. Reinforcement Learning Designer ile ortam tasarımı

Reinforcement Learning Toolbox bu aşamada MATLAB ve Simulink ortamlarını ortak gözlem-eylem spesifikasyonları üzerinden ajana bağlar. Boyut, limit ve veri tipi gibi arayüz bilgileri açıkça tanımlandığı için ortam ile ajan arasındaki uyumsuzlukların yönetilmesi kolaylaşır. Mevcut Simulink veya Simscape sistem modelinin yeniden yazılmadan eğitim akışına alınabilmesi önemli bir mühendislik avantajıdır.

Ödül Tanımlama

Ödül, mühendislik hedefini ajanın optimize edebileceği sayısal bir geri bildirime dönüştürür. Bir takip probleminde hatanın azalması ödüllendirilebilir; enerji tüketimi, aşırı kontrol çabası, kısıt ihlali veya güvenli olmayan durumlar cezalandırılabilir. Birden fazla hedef varsa ödül bu hedefler arasındaki dengeyi temsil eder.

Örneğin yalnızca hedefe yaklaşmayı ödüllendiren bir ödül, ajanın çok agresif eylemler üretmesine neden olabilir. Yalnızca enerji tüketimini azaltmak ise ajanın hiç hareket etmemeyi öğrenmesiyle sonuçlanabilir. Bu nedenle ödülün yükselmesi ile gerçek mühendislik performansının iyileşmesi aynı şey değildir. Ödül tasarımı sırasında ajanın hedefi beklenmedik bir yoldan optimize edip edemeyeceği de düşünülmelidir.

Ödül her adımda davranışın yönünü gösteren yoğun bir geri bildirim sağlayabilir veya yalnızca görev başarıldığında verilen seyrek bir değer olabilir. Yoğun ödül, eğitimi hızlandırabilir ancak yanlış davranışı teşvik etme riski taşır. Seyrek ödül, hedefi daha doğrudan ifade eder fakat başarılı deneyimler seyrek olduğu için öğrenmeyi zorlaştırabilir. Çoğu uygulamada iki yaklaşım dengeli biçimde birleştirilir.

Şekil 3. Otomatik ödül oluştruma (MathWorks)

Simulink tabanlı uygulamalarda ödül; model sinyalleri, maliyet ifadeleri ve doğrulama koşulları kullanılarak hesaplanabilir. Reinforcement Learning Toolbox standart ödül arayüzünü ve simülasyon sırasında bileşenlerin izlenmesini sağlar. Bazı kontrol problemlerinde Simulink Design Optimization ve Model Predictive Control Toolbox ile tanımlanan kontrol gereksinimlerinden ödül fonksiyonu üretmeye yönelik iş akışları da kullanılabilir. Araç ödülü kendi başına doğru tasarlamaz; fakat ödülün modele bağlanması, değiştirilmesi ve deneyler arasında karşılaştırılması için gereken altyapıyı azaltır.

Politika Temsili ve Ajan Seçimi

Politika, gözlemden eyleme yapılan eşlemedir. Küçük durum ve eylem uzaylarında tablo veya basit fonksiyonlar yeterli olabilir. Gözlem sayısı arttığında, sürekli değerler veya görüntüler kullanıldığında politika ve değer fonksiyonu çoğunlukla sinir ağlarıyla temsil edilir.

RL algoritmaları seçim mantığı açısından üç temel ailede düşünülebilir:

  • Değer tabanlı yöntemler, bir durumun veya durum–eylem çiftinin uzun vadeli değerini öğrenir ve eylemi bu değere göre seçer. Q-Learning ve DQN bu yaklaşımın bilinen örnekleridir. Özellikle ayrık eylem problemleri için doğal bir başlangıç olabilir.
  • Politika tabanlı yöntemler, gözlemden eyleme doğrudan bir haritalama öğrenir. Deterministik veya rassal politika oluşturabilir ve sürekli eylem problemlerine uygulanabilir. Politika Gradyan yaklaşımı bu ailenin temel örneklerindendir.
  • Actor–critic yöntemler, iki yaklaşımı birleştirir. Actor eylem üretirken critic seçilen eylemin ne kadar değerli olduğunu tahmin ederek actor’ın güncellenmesine yardımcı olur. PPO, DDPG, TD3 ve SAC gibi yaygın ajanlar bu çerçevede değerlendirilebilir.

Şekil 4. Actor-Critic politika temsili (MathWorks)

Bu sınıflandırma tek başına algoritma seçmeye yetmez. Eylem uzayının ayrık veya sürekli olması, ortam etkileşiminin maliyeti, keşif ihtiyacı, mevcut deneyimlerin tekrar kullanılıp kullanılamayacağı ve eğitim kararlılığı beklentileri birlikte değerlendirilmelidir. En iyi yaklaşım, problemle uyumlu ve mümkün olduğunca basit bir ajan ile başlayıp sonuçlara göre ilerlemektir.

Şekil 5. Reinforcement Learning Designer ile ajan yaratma

Reinforcement Learning Toolbox hazır ajan implementasyonlarının yanı sıra custom ajan, actor ve critic yapıları geliştirmek için de altyapı sunar Gözlem ve Eylem belirtimlerine göre başlangıç ağları oluşturulabilir; Deep Learning Toolbox katmanlarıyla özel mimariler tasarlanabilir. Reinforcement Learning Designer uygulaması ise ortamı içe aktarma, uyumlu ajan seçeneklerini değerlendirme, actor–critic yapılarını inceleme ve ayarları etkileşimli biçimde değiştirme sürecini hızlandırır. Böylece ekip zamanını algoritmanın temel eğitim döngüsünü yeniden yazmak yerine probleme özgü temsil ve seçimlere ayırabilir.

Ajanı Eğitme

Eğitim sırasında ajan ortam ile tekrar tekrar etkileşir, gözlem-eylem-ödül geçişlerini toplar ve seçilen algoritmaya göre politika veya değer fonksiyonu parametrelerini günceller. Bölüm başlangıç koşulları, maksimum adım sayısı, durdurma ölçütleri, iskonto çarpanı, öğrenme hızı, keşif ayarları ve ajan örnekleme zamanı eğitim davranışını doğrudan etkiler.

Eğitim süreci yalnızca bölüm özül üzerinden değerlendirilmemelidir. Hareketli ortalama ödül, bölüm uzunluğu, başarı oranı, actor ve critic kayıp değerleri, kısıt ihlali sayısı ve gerçek mühendislik temel performans göstergeleri birlikte izlenmelidir. Ödül yükselirken takip hatası veya enerji tüketimi iyileşmiyorsa ödül tanımı istenen görevi temsil etmiyor olabilir.

Tek bir eğitim sonucuna güvenmek de yanıltıcıdır. Ağın başlatılması, keşif ve rastgele başlangıç koşulları nedeniyle aynı ayarlar farklı sonuçlar üretebilir. Birden fazla rastgele bilgi ile eğitim yaparak başarım dağılımını incelemek daha güvenilir bir yaklaşım sağlar.

Şekil 6. Uygulama içerisinde simülasyon ve eğitim ayarlarının yapılması

Eğitimin en pahalı bölümü her zaman sinir ağı hesabı değildir. Darboğaz yavaş çalışan bir Simulink simülasyonuysa farklı işçilerde birden fazla bölüm çalıştırmak deneyim üretimini hızlandırabilir. Büyük bir ağın gradyan hesapları zaman alıyorsa GPU daha fazla fayda sağlar. Reinforcement Learning Toolbox standart eğitim döngüsünü, durdurma ölçütü yönetimini ve eğitim ilerleme görselleştirmesini sağlar; Parallel Computing Toolbox ve GPU desteğiyle uygun hızlandırma seçeneklerine bağlanabilir. Training logger ve Reinforcement Learning Data Viewer ise deneyimlerin, kayıp değerlerinin ve kritik sinyallerin sonradan çözümlenmesini kolaylaştırır.

Eğitilmiş Politikayı Test Etme

Eğitim ortamında yüksek ödül elde etmek, politikanın gerçek sistem için hazır olduğunu göstermez. Eğitim tamamlandıktan sonra politika farklı başlangıç koşulları, model parametreleri, gürültü sensörleri, aktüatör doyumu, gecikme, bozucu etki ve arıza senaryoları altında test edilmelidir

Değerlendirme yalnızca ödül grafiğine dayanmamalıdır. Kontrol uygulamalarında takip hatası, aşım, yerleşme süresi, kontrol çabası, enerji tüketimi, kısıt ihlali, başarı oranı ve eylem düzgünlüğü gibi gerçek sistem ölçütleri kullanılmalıdır. Başlangıç koşulları ve model parametreleri rastgeleleştirilerek çok sayıda simülasyon çalıştırmak, tek bir başarılı videodan daha güvenilir bilgi verir.

Simulink tabanlı iş akışı, model seviyesindeki testten üretilen kod doğrulamasına geçişi kolaylaştırır. Normal simülasyonda politika ve sistem aynı model içinde çalışır. Software-in-the-loop (SIL) testinde politika için üretilen kod ana bilgisayarda çalıştırılarak model çıktısıyla karşılaştırılır. Processor-in-the-loop (PIL) testinde ise üretilen kod hedef işlemcide çalışır; sayısal denklik, çıkarım süresi ve kaynak kullanımı değerlendirilebilir. Gerektiğinde hardware-in-the-loop testleriyle denetleyici donanımı gerçek zamanlı bitki benetimine bağlanabilir.

Şekil 7. SIL & PIL testlerinin oluşturulması (MathWorks)

Reinforcement Learning Toolbox ile eğitilmiş ajan aynı MATLAB veya Simulink ortamlarında yeniden simule edilebilir. Politikanın Simulink modelinde kalması, RL çözümünü ayrı bir araştırma prototipi olmaktan çıkarıp mevcut Model Tabanlı Tasarım doğrulama zincirine dahil etmeyi kolaylaştırır.

Politikayı Dağıtma

Dağıtım sırasında ihtiyaç duyulan temel bileşen, gözlem alıp eylem üreten eğitilmiş politikadır. Yeniden oynatma belleği, keşif mekanizması ve ağ güncelleme işlemleri eğitime aittir; sahada çalışan sistem çoğunlukla yalnızca çıkarım gerçekleştirir.

Simulink’te eğitilmiş politika bir politika bloğu içine alınarak dağıtıma hazır bir alt sistem oluşturulabilir. Hedef platformun gereksinimlerine göre MATLAB Coder, Simulink Coder, Embedded Coder veya GPU Coder tabanlı iş akışlarıyla C/C++ ya da CUDA kodu üretilebilir. Böylece araştırma ortamındaki politikanın hedef sistem için elle yeniden yazılmasından kaynaklanabilecek farklılıklar azaltılır.

Dağıtım öncesinde gecikme, bellek alanı ve sayısal davranış kontrol edilmelidir. Hedef donanımın kaynakları sınırlıysa budama, yansıtma veya düşük duyarlıklı veri türü gibi ağ sıkıştırma yaklaşımları değerlendirilebilir. Her değişiklikten sonra politika başarımının yeniden test edilmesi gerekir.

Şekil 8. Politikanın gömülmeye hazır hale getirilmesi (MathWorks)

Gerçek sistemde beklenmeyen bir davranış görülürse süreç tamamlanmış sayılmaz. Simülasyon modelindeki eksikler, sürtünme, boşluk, gürültü sensörü, aktüatör dinamiği veya haberleşme gecikmeleri incelenebilir. Model güncellenebilir, eğitim sırasında fiziksel parametreler belirli aralıklarda rasgeleleştirilebilir veya gerçek sistemden toplanan verilerle politika ince ayar yapılabilir. Pekiştirmeli öğrenme geliştirme süreci dağıtımla biten doğrusal bir hat değil, gerçek sistemden tekrar tasarıma dönen kapalı bir mühendislik döngüsüdür.

Uygulama Örneği: Rotational İnverted Pendulum

Quanser QUBE dönel ters sarkaç problemi, iş akışının pratikte nasıl bir araya geldiğini göstermek için iyi bir örnektir. Amaç sarkacı aşağı konumdan yukarı kaldırmak ve üst denge noktasında tutmaktır. Tüm görevi tek bir kara kutu reinforcement kontrolcüsüne vermek yerine pekiştirmeli öğrenme ve geleneksel kontrolün birlikte kullanıldığı hiyerarşik bir mimari kurulabilir.

Bu yapıda bir SAC ajanı sarkacı yukarı kaldıracak referansı üreten sallanarak kaldırma planlayıcısı, bir PPO ajanı ise sallanarak kaldırma ve dengeleme modları arasında geçiş yapan mod seçimi zamanlayıcısı olarak çalışır. Düşük seviyeli iç döngü kontrolcüsü verilen referansı takip ederek kararlılaştırmayı sağlar. Böylece pekiştirmeli öğrenme planlama ve mod seçimi gibi yüksek seviyeli davranışları öğrenirken kritik düşük seviyeli kontrol geleneksel kontrolcüde kalır.

Sarkaç ve motor dinamiği Simulink ve Simscape kullanılarak modellenir. Her ajanın görevi farklı olduğu için gözlem, eylem ve ödül tanımları ayrı hazırlanır. Önce sallanarak kaldırma ajanı eğitilir; bu politika sabitlendikten sonra mod seçimi ajanının eğitimi gerçekleştirilir. Eğitilmiş politikalar önce simülasyon ortamında test edilir, ardından kod üretimi ile SIL ve PIL doğrulamalarından geçirilir. Son aşamada doğrulanan politika hedef donanıma aktarılır ve gerçek Quanser QUBE sistemi üzerinde çalıştırılır.

Şekil 9. Rotational inverted pendulum modeli (MathWorks)

Bu örnekte Reinforcement Learning Toolbox’ın sağladığı değer yalnızca SAC veya PPO algoritmalarının hazır olması değildir. Ortam bağlantısı, ajan oluşturma, eğitim süreci, simülasyon, kod üretimi ve işlemci testleri aynı iş akışı içinde korunur. Bu bütünlük, araştırma sırasında oluşturulan politika ile gerçek sistemde çalışan gerçekleme arasındaki geçişi kolaylaştırır.

Sonuç

Reinforcement learning, her durumda verilmesi gereken doğru eylemleri tek tek tanımlamak yerine, bir ajanın ortam ile etkileşerek uzun vadeli hedeflere uygun bir politika öğrenmesini sağlar. Bu yaklaşım özellikle ardışık kararların, doğrusal olmayan dinamiklerin, gecikmeli sonuçların ve karmaşık gözlem-eylem uzaylarının bulunduğu problemlerde değerlidir.

Başarılı bir RL projesi yalnızca doğru algoritmayı seçmekten oluşmaz. Ortam modeli, gözlem ve eylem arayüzü, ödül tasarımı, eğitim kararlılığı, kapsamlı testler ve dağıtım gereksinimleri birlikte ele alınmalıdır. MATLAB, Simulink ve Reinforcement Learning Toolbox bu parçaları ortak bir mühendislik iş akışında bir araya getirerek tekrar eden altyapı işlerini azaltır.

Toolbox doğru problemi veya ödülü kullanıcı adına belirlemez; yakınsama, kararlılık ya da güvenlik garantisi de vermez. Ancak ortam tasarımından ajan eğitimine, Model Tabanlı Tasarım doğrulamasından kod üretimi ve dağıtıma kadar aynı model tabanlı akışın sürdürülebilmesini sağlar. Pekiştirmeli öğrenmeyi sihirli bir kara kutu yerine simülasyon kontrol tasarımı, doğrulama ve dağıtım araçlarıyla birlikte kullanılan bir karar verme teknolojisi olarak ele almak, gerçek mühendislik uygulamalarında daha güvenilir ve sürdürülebilir sonuçlar üretir.

Uydu Sistemlerinde Model Tabanlı Tasarım: Gereksinimden ECSS-E-ST-40 C Doğrulamasına | MATLAB ile Uçtan Uca Rehber

Bir uydunun yönelim kontrolü sistemini tasarlamak, birbirinden bağımsız görünen onlarca mühendislik kararını tek bir tutarlı zincire dönüştürmek demektir: gereksinim mi tutarsız? Mimari mi eksik? Model mi yanlış? Doğrulama mı yetersiz? Bu yazımıda, Requirements Toolbox ile başlayıp Simulink Design Verifier’da biten uçtan uca bir model tabanlı tasarım sürecini somut bir uydu örneği üzerinden anlatıyoruz.

Giriş

Bir uydu görevinin başarısı, gereksinimden doğrulamaya uzanan zincirin doğru modellenmesine bağlıdır. Uydunun yönelim dinamiği (attitude dynamics), yörünge hareketi ve çevresel bozucu torklar (disturbance torques) birbirine bağlı sistemlerdir. Bu sistemleri ayrı ayrı çözmek kolaydır. Asıl güçlük, hepsini tek bir tutarlı model üzerinde birleştirmek ve bu modeli denetlenebilir bir doğrulama planına bağlamaktır. Model tabanlı tasarım (Model-Based Design) tam bu noktada devreye girer.

Uydunun açısal hareketi, Euler hareket denklemleri ve kuaterniyon kinematiği temel alınarak modellenir. Euler açıları yerine kuaterniyon kullanmanın nedeni, gimbal kilidi (gimbal lock) sorununu taşımamasıdır. Yörünge hareketi ise iki cisim (Kepler) denklemleriyle ya da J2 ve daha yüksek zonal harmonikleri içeren sayısal yayılımla çözülür. Bu denklemler MATLAB ve Simulink ortamında blok diyagramlarla kurulur. Aerospace Blockset, yörünge ve dönme dinamiğini, çevresel modelleri ve işaretleme profillerini hazır bloklarla sağlar. Yönelim belirleme tarafında jiroskop, manyetometre, güneş algılayıcısı ve yıldız izleyici ölçümleri bir Kalman filtresinde (örneğin MEKF) birleştirilir. Kontrol tarafında B-dot detumble ve kuaterniyon geri beslemeli kontrolcü bu döngüyü kapatır.

Bir uydu için bu zincir tek bir araçla değil, bir araç ailesiyle yürütülür. Gereksinimler Requirements Toolbox ile yazılır ve izlenir. Mimari System Composer ile bileşenlere, portlara ve arayüzlere ayrılır. Fonksiyonel model Simulink, Simscape ve Stateflow ile kurulur. Hata senaryoları Simulink Fault Analyzer ile modele dışarıdan eklenir. Doğrulama ise Simulink Test, Simulink Coverage, Simulink Design Verifier ve Simulink Check ile yapılır. Bu yazı, aynı omurgayı MathWorks’ün CubeSat MBSE örneğiyle aynı sırada izler ve her adımda teoriyi ilgili MathWorks çözümüne eşler.

Bir noktayı baştan belirtmek gerekir. Bir gereksinimi mimaride bir bileşene bağlamak, o gereksinimin karşılandığı anlamına gelmez. Bu bağ yalnızca tasarımda bir karşılık olduğunu gösterir. Gereksinimin karşılandığının kanıtı simülasyon, yapısal kapsam ve formal analizdir. Bu ayrım, yazının dördüncü adımının çekirdeğini oluşturur.

Gereksinimler

TEORİHangi toolboxları kullanabilirsiniz?
Misyon hedefinin alt gereksinimlere ayrışması. Yörünge seçimi (irtifa, eğim, yerel güneş saati, güneş eşzamanlılık). Fırlatma aracı zarfı (kütle, hacim, ayrılma açısal hızı, mekanik arayüz). Faydalı yük çözünürlüğü ve tekrar geçiş. İşaretleme doğruluğu ve kararlılığı. Güç ve haberleşme bütçesi.Requirements Toolbox Requirements Editor, ReqIF içe ve dışa aktarma, izlenebilirlik matrisi, bileşene tahsis, değişim etki analizi.

Bir uydu projesi tek bir cümleyle başlar. Örnekteki en üst gereksinim şudur. Sistem, yer hedefinin görüntüsünü günde bir kez 10 metre çözünürlükte sağlar ve saklar. Geri kalan her gereksinim bu hedeften türer. Çözünürlük yörünge irtifasını sınırlar. Tekrar geçiş süresi yörünge eğimini ve düğümün yerel güneş saatini (LTAN) sınırlar. İşaretleme doğruluğu ise ADCS hata bütçesini doğrudan belirler ve aşağı doğru reaksiyon tekeri torkuna, algılayıcı gürültüsüne ve kestirim kovaryansına yansır.

Fırlatma aracı ve yörünge seçimi de birer gereksinimdir, bir varsayım değil. Fırlatma aracı kütle ve hacim zarfını, ayrılma anındaki açısal hız koşulunu ve mekanik arayüzü dayatır. Bunları metin gereksinimi olarak yazarsınız ve mimaride bileşenlere stereotip özelliği olarak (kütle, güç, nominal gerilim) bağlarsınız. Requirements Toolbox bu hiyerarşiyi Requirements Editor içinde kurar ya da ReqIF üzerinden DOORS gibi bir araçtan içe aktarır. Her gereksinim bir kimlik alır. O kimlik mimariye, davranış modeline ve test senaryosuna kadar çift yönlü izlenir. İzlenebilirlik bir biçimsellik değil. Bir gereksinim değiştiğinde hangi bileşenin ve hangi testin etkilendiğini tek bakışta gösterir.

💡 Dikkat.

Güneş eşzamanlı yörünge tam da J2 kaynaklı düğüm gerilemesine dayanır. Yani yörünge gereksinimini fiziksel olarak doğrulamadan sabitlerseniz, üçüncü adımda kullandığınız yörünge yayıcının bu etkiyi içerip içermediğini de denetlemeniz gerekir. Aksi halde kağıt üzerinde doğru, simülasyonda tutmayan bir yörüngeyle çalışırsınız.

Mimari

TEORİHangi toolboxları kullanabilirsiniz?
Sistemin ayrışması. Uzay segmenti, yer segmenti, fırlatma. Alt sistemler: faydalı yük, ADCS/GNC, güç (EPS), uçuş bilgisayarı, haberleşme, yapı, itki. Aynı işlevin farklı tasarım alternatifleri ve ticari analiz.System Composer Bileşen, port, bağlayıcı, arayüz, stereotip, görünüm. Variant Component Tahsis için Requirements Toolbox.

Gereksinimler ne istediğinizi söyler. Mimari sistemi parçalara böler ve her parçaya bir işlev atar. System Composer bunu bileşenler, portlar, bağlayıcılar ve arayüzlerle yapar. Bir port bileşenin çevresiyle etkileşim noktasıdır. Bir arayüz o porttan akan verinin türüdür. Simulink kullanıcıları için doğrudan bir köprü vardır. System Composer arayüzleri Simulink veri yolu (bus) tanımlarıyla aynıdır. Bir veri sözlüğündeki ACSOutBus gibi bir yapı arayüz olarak portlara atanır.

MathWorks örneği mimariyi INCOSE Uzay Sistemleri Çalışma Grubunun CubeSat Referans Modeline (CRM) dayandırır. Bu, sıfırdan başlamak yerine kabul görmüş bir ayrıştırmadan başlamanın örneğidir. Stereotipler her bileşene alana özgü veri ekler. Kütle, güç, maliyet, nominal gerilim. Stereotip paketleri profillerde tutulur ve bir temel stereotipten miras alır. Gereksinim tahsisi bu adımın çekirdeğidir. Requirements Manager içinde bir gereksinimi sürükleyip bileşene bırakırsınız. Implemented sütunu bağlantının kurulduğunu gösterir. Mantıksal ve fiziksel mimariler arasında ise model to model tahsis kurarsınız.

Variant: aynı işlev, farklı tasarım

Bir uydu tasarımı tek bir çözüm değildir. ADCS için üç eksen reaksiyon tekeri mi yoksa yalnızca manyetik tork çubuğu mu? Farklı yörünge ya da fırlatma yapılandırmaları? Variant Component tam bunun içindir. Bir bileşene birden çok tasarım alternatifi koyar ve aktif seçimi etiket ya da ifade kipiyle belirlersiniz. İfade kipinde bir kontrol değişkeni alternatifleri çalışma anında açıp kapatır ve etkinleştirme zamanını seçersiniz. Böylece ticari analizleri modeli yeniden kurmadan yaparsınız. Variant bileşenleri, ayrı gereksinim kümelerini karşılayan tasarım alternatiflerini tek mimaride taşır.

💡 Dikkat

Implemented sütunu yeşil göründü diye gereksinim karşılandı sanmak yaygın bir hatadır. O sütun yalnızca bir bağlantının varlığını söyler. Tasarımın gereksinimi sağladığını üçüncü adımdaki simülasyon ve dördüncü adımdaki test ve formal analiz gösterir.

Fonksiyonel Model

TEORİHangi toolboxları kullanabilirsiniz?
Katı cisim açısal dinamiği ve kuaterniyon kinematiği, yörünge yayılımı, çevresel bozucu torklar, eyleyici ve algılayıcı modelleri, kestirim filtresi, kontrolcü, mod mantığı, hata modeli.Simulink  ·  Aerospace Blockset  ·  Simscape  ·  Stateflow  ·  Simulink Fault Analyzer

Mimari iskelettir. Bu adımda iskelete davranış girer. System Composer Simulink üzerine kurulu olduğu için bir referans bileşeni doğrudan bir Simulink modeline bağlanır. Örnekte GNC alt sistemi üç model referansı içerir ve mimarideki arayüzler model içinde veri yolu sinyallerine eşlenir. İkinci adımda çizdiğiniz mimari burada çalışan modele dönüşür.

Uydu Dinamiği

Katı cismin açısal hareketi gövde çerçevesinde Euler denklemiyle yazılır. Yönelim ise kuaterniyon kinematiğiyle yayılır. Kuaterniyon, Euler açılarındaki tekillik sorununu (gimbal lock) taşımadığı için uçuş yazılımının standardıdır.

💡

I·ω̇ + ω × (I·ω) = T_kontrol + T_bozucu q̇ = ½ · q ⊗ [0, ω] I atalet tensörü, ω gövde açısal hızı, q gövdeden ataleğe kuaterniyon, T torklar.

Yörünge tarafında iki seçim vardır. Hızlı ve yaklaşık için iki cisim (Kepler) yayılımı, gerçekçi için zonal harmonikleri (J2, J3, J4) içeren sayısal yayılım. Aerospace Blockset bunu doğrudan verir. Spacecraft Dynamics bloğu hem yörüngeyi hem de dönme durumlarını birlikte yayar ve yönelim gösterimini seçmenize izin verir. Yalnızca yörünge için Orbit Propagator (Kepler) bloğu vardır. İşaretleme profili için Attitude Profile (Nadir Pointing) gibi hazır bloklar bulunur.

💡 Dikkat

Güneş eşzamanlı yörünge J2 kaynaklı düğüm gerilemesine dayanır. Pertürbasyonsuz Kepler yayıcı bu etkiyi yok sayar. SSO tasarımını doğrularken pertürbasyonsuz bloğu kullanmak, yörüngeyi güneş eşzamanlı yapan etkiyi gizler. Bu adımda doğru blok zonal harmonikli sayısal yayıcıdır.

Çevresel Model

Bozucu torklar dört ana kaynaktan gelir. Yerçekimi gradyanı atalet asimetrisinden doğar. Atmosferik sürükleme alçak yörüngede baskındır ve irtifa düştükçe büyür. Güneş radyasyon basıncı yüzey alanına ve basınç merkezi ile kütle merkezi arasındaki kaymaya bağlıdır. Artık manyetik dipol Dünya alanıyla etkileşir.

💡

T_gg = (3μ / R³) · (R̂ × I·R̂) T_m = m × B μ yerçekimi sabiti, R yörünge yarıçapı, R̂ nadir birim vektörü, m artık dipol, B manyetik alan vektörü.

Bu modeller için Aerospace Blockset yerçekimi, manyetik alan (IGRF ve WMM) ve atmosfer yoğunluğu bloklarını sağlar. Manyetik alan vektörü B yalnızca bir bozucu kaynağı değildir. Hem manyetometre ölçümünün hem de tork çubuğu kontrolünün temelidir.

Eyleyici Modeli

Reaksiyon tekeri açısal momentum depolar ve tork üretir. Gerçek tekerde tork sınırı, momentum doyması, kalkış sürtünmesi (stiction) ve nicemleme vardır. Tekerler doyduğunda momentumu boşaltmak gerekir ve bu boşaltma manyetik tork çubuğu ya da iticiyle yapılır. Tork çubuğu yalnızca B vektörüne dik yönde tork üretir, B boyunca tork üretemez. İtici kesiklidir ve bir en küçük itki darbesi (minimum impulse bit) vardır. Kontrol düzeyinde bu modeller Simulink içinde kurulur. Elektriksel ve mekanik sadakat gerektiğinde, örneğin motor sargısı, baranın gerilimi ve EPS’e binen güç çekişi modellenecekse, Simscape devreye girer. Simscape fiziksel ağ yaklaşımıyla çalışır ve denklemleri sizin yerinize kurar.

💡 Dikkat

Tekeri ideal bir tork kaynağı olarak modellemek doymayı ve sürtünmeyi gizler. Oysa işaretlemeyi bozan iki şey tam da bunlardır. Erken aşamada ideal model hız kazandırır. İşaretleme bütçesini doğrularken tork sınırı ve momentum boşaltma döngüsü modelde olmalıdır.

Dört tipik algılayıcının zayıf noktası farklıdır. Yıldız izleyici en doğru ölçümü verir ama yavaştır ve Güneş ya da Dünya albedosu körleştirebilir. Güneş algılayıcısı kaba ölçüm verir ve gölgede çalışmaz. Manyetometre ucuzdur ama gürültülüdür ve tork çubuğu çalışırken kirlenir. Jiroskop yüksek hızda ölçer ama kayma (bias) ve açısal yürüme biriktirir. Modelde gürültü, bias, açısal yürüme, hizalama hatası, nicemleme, gecikme ve güncelleme hızı bulunmalıdır.

Algılayıcı Modeli

💡 Dikkat

Tork çubuğu çalışırken alınan manyetometre ölçümü kirlidir. Algılama ve eyleme aynı anda yapılırsa kestirim bozulur. Bunu mod mantığında zamanlamayla çözersiniz. Önce ölç, sonra tork uygula.

Filtre Modeli (kestirim)

Yönelim belirleme iki aileye ayrılır. Belirleyici yöntemler (TRIAD, QUEST) iki ya da daha çok vektör gözleminden anlık yönelim çıkarır. Özyineli yöntemler jiroskopla durumu yayar ve vektör algılayıcılarla düzeltir. Tipik bir çarpımsal genişletilmiş Kalman filtresi (MEKF) çarpımsal hata kuaterniyonunu ve jiroskop bias’ını birlikte kestirir.

💡

x = [ δθ , b_g ]ᵀ δθ küçük açı hata vektörü, b_g jiroskop bias. Süreç gürültüsü açısal yürüme σ_v ve bias yürümesi σ_u ile ayarlanır. Düzeltme adımından sonra kovaryans sıfırlanır (reset).

Yakınsama keyfi değildir. İyi bir başlangıç yönelimi, ayarlanmış Q ve R kovaryansları ve gözlenebilirlik gerektirir. Gözlenebilirlik için eşdoğrusal olmayan en az iki vektör gözlemi gerekir. UKF, kuvvetli doğrusal olmayan rejimlerde alternatiftir.

💡 Dikkat

Gölge döneminde güneş algılayıcısı düşer ve geriye tek vektör (manyetometre) kalır. Tek vektör tam yönelimi gözleyemez. EKF bu pencerede sapabilir. Senaryolarınızda gölge geçişini mutlaka koşturun.

Kontrolcü

İki temel mod vardır. Ayrılma sonrası yüksek açısal hızı söndürmek için B-dot detumble kullanılır ve yalnızca manyetometre ile tork çubuğu ister. İşaretleme moduna geçince kuaterniyon geri beslemeli PD kontrolcü hedef yönelimi tutar. Bir momentum saturasyon döngüsü ise tekerdeki momentumu çapraz çarpım yasasıyla tork çubuğuna aktarır.

💡

m = −k · ḃ T = −K_p · sgn(q₀)·q_v − K_d · ω m_saturasyon = (1/‖B‖²) · (B × T_istenen) ḃ gövde çerçevesindeki manyetik alanın türevi, q_v hata kuaterniyonunun vektör kısmı, sgn(q₀) en kısa dönüşü seçer.

Mod Mantığı (Stateflow)

Yukarıdaki blokları kim yönetir? Bir denetleyici durum makinesi. Stateflow sonlu durum makineleriyle bu denetimi kurar. Tipik akış şudur. Detumble, ardından Güvenli ve Güneşe işaretleme, ardından İnce işaretleme ve Görüntüleme, ardından Momentum boşaltma. Geçişler koşullara bağlıdır. Açısal hız eşiği, gölge bayrağı, hedef görünürlüğü, teker momentum eşiği ve hata bayrakları. Stateflow burada hem zamanlayıcı hem de arıza tespit ve kurtarma (FDIR) mantığının yaşadığı yerdir.

Hata Modeli (Simulink Fault Analyzer)

Simulink Fault Analyzer hataları tasarımı değiştirmeden enjekte eder. Algılayıcı takılması (stuck at), bias kayması, eklenen gürültü, sinyal gecikmesi, veri kaybı ya da teker arızası gibi davranışları modele dışarıdan ekler. Tetikleme zamanlı, koşullu ya da elle olur. Hataları Simulink, Simscape ve System Composer genelinde yönetir. Etkileri Simulation Data Inspector ile incelersiniz. Multiple Simulations paneliyle hata duyarlılığı analizi yaparsınız. Safety Analysis Manager ile FMEA ve FHA gibi güvenlik analizlerini yürütür, hataları tehlikelere, tespit ve azaltma mantığına ve gereksinimlere bağlarsınız. Ürün R2023b ile geldi. Bu, döngüyü kapatan adımdır. Burada enjekte ettiğiniz bir hata, bir sonraki adımda FDIR mantığınızın o hatayı yakaladığını kanıtlayan bir test senaryosuna dönüşür.

Doğrulama ve V&V

TEORİHangi toolboxları kullanabilirsiniz?
Gereksinim temelli test. Birim, regresyon, sırt sırta (back to back) test. Yapısal kapsam (karar, koşul, MCDC, ilişkisel sınır). Formal analiz: tasarım hatası tespiti ve özellik ispatı. Modelleme standardı uyumu ve metrikler. Misyon düzeyinde geçerleme.Simulink Test  ·  Simulink Coverage  ·  Simulink Design Verifier  ·  Simulink Check

Modeli kurdunuz. Şimdi gereksinimleri karşıladığını göstermeniz gerekir. Simulink Test bunu sistematik ve tekrarlanabilir biçimde yapar. Test Manager testleri yönetir ve koşar. Test Sequence bloğu karmaşık senaryolar ve değerlendirme ölçütleri kurar. Koşum kabini (test harness) test edilen bileşeni yalıtır ve modele müdahale etmez. Değerlendirmeleri metin tabanlı bir dille yazar, beklenen çıktıları ve toleransları belirlersiniz. Testleri birinci adımdaki gereksinim kimliklerine bağlarsınız. Sağlamlık için parsim ile yüzlerce koşumu paralel çalıştırır, başlangıç hızı, atalet belirsizliği ve algılayıcı gürültü tohumları üzerinde Monte Carlo dağılım taraması yaparsınız. Aynı testler SIL, PIL ve donanım döngüde (HIL) kiplerde de koşar. Modelinizi Speedgoat gibi gerçek zamanlı bir hedefe taşıdığınızda test takımınız sizinle gelir.

Yapısal Kapsam (Simulink Coverage)

Test geçti demek yeterli test yaptınız demek değildir. Simulink Coverage testin ne kadarını gerçekten çalıştırdığınızı ölçer. Endüstri standardı metrikleri uygular. Karar, koşul, değiştirilmiş koşul ve karar (MCDC), ilişkisel sınır, sinyal aralığı ve arama tablosu kapsamı. Birden çok koşumun kapsamını biriktirir (cumulative coverage) ve birim testlerden gelen kapsamı sistem testi düzeyinde toplar. Kapsamı bağlı gereksinimlere göre kapsayarak istenmeyen kapsamı dışarıda tutarsınız. Eksik kapsam yalnızca test boşluğunu değil, eksik gereksinimi ya da istenmeyen işlevi de açığa çıkarır. Embedded Coder ile üretilen kod için SIL ve PIL kipinde kod kapsamı da ölçülür. MCDC, DO-178C ve DO-331 tanımına göre raporlanır.

💡 Dikkat

. Yapısal kapsam gerekli koşuldur, yeterli koşul değildir. Yüzde yüz MCDC her zaman ulaşılabilir olmayabilir. Savunmacı modelleme kalıpları erişilemez dallar üretir. Bunları kapsam filtresiyle ayırır ve gerekçesini kayıt altına alırsınız.

Formal Analiz (Simulink Design Verifier)

Simulink Design Verifier formal yöntemler (SAT ve SMT çözücüleri) kullanır ve simülasyonun gözden kaçırdığı hataları açığa çıkarır. Üç işi vardır. Birincisi tasarım hatası tespiti. Tamsayı taşması, sıfıra bölme, ölü mantık (dead logic) ve dizi sınırı ihlali gibi hataları modelde arar. İkincisi özellik ispatı. Bir güvenlik ya da gereksinim özelliğini biçimsel olarak ispatlar ya da onu ihlal eden bir karşı örnek üretir. Üçüncüsü otomatik test üretimi. Karar, koşul, MCDC ve özel hedefleri karşılayan test senaryolarını otomatik üretir. Böylece elle yazılmış testlerin kapatamadığı kapsam boşluklarını kapatır. Her ihlal ve her hedef için hata ayıklamaya yarayan bir simülasyon test senaryosu üretir. Falsifikasyon ile ispat arasındaki fark önemlidir. Bir test bir hatayı gösterebilir. Formal ispat ise bir özelliğin tüm girdi uzayında tuttuğunu söyler.

Standart Uyumu ve Metrikler (Simulink Check)

Simulink Check modeli, gereksinimleri ve testleri standartlara karşı denetler. MathWorks Advisory Board (MAB) stil kılavuzunu ve yüksek bütünlüklü yazılım standartlarını (DO-178C, DO-254, ISO 26262, IEC 61508) uygular. Denetimler düzenleme anında (edit time) çalışır, böylece ihlali tasarım sırasında yakalarsınız. Boyut ve karmaşıklık gibi metrikleri (siklomatik karmaşıklık) raporlar. Model Testing Dashboard ise gereksinim temelli test durumunu tek panoda toplar. Bağlı gereksinimler, test sonuçları ve kapsam birlikte görünür. İzlenebilirliğin tamlığını ve doğrulama kanıtını burada izlersiniz. Kendi kurum standartlarınız için özel denetimler de yazarsınız.

Dört araç birlikte bir döngü kurar. Check modelleme sırasında standardı dayatır. Test gereksinim temelli senaryoları koşar. Coverage tamlığı ölçer. Design Verifier özellikleri ispatlar ve boşluklar için test üretir. Model Testing Dashboard kanıtı toplar. Sertifikasyon kapsamında bu araçları kullandığınızda DO Qualification Kit ile araç niteliğini (tool qualification, TQL) sağlarsınız. Üçüncü adımda enjekte ettiğiniz hata senaryoları ise burada FDIR doğrulama testlerine dönüşür.

💡 Dikkat

Misyon testinin geçmesi tek başına geçerleme değildir. MathWorks örneği bunu açıkça söyler. Bu test erken aşamada yörünge seçiminin makul olduğunu teyit eder, kapsamlı bir doğrulama değildir. Geçen bir test yalnızca o senaryonun o simülasyon penceresinde tuttuğunu gösterir.

Sınırlar ve Sonraki Adım

Buraya kadar kurulan zincir kâğıt üzerinde tutarlıdır. Pratikteki asıl gerilim, sadakat ile koşum süresi arasındaki dengede (fidelity-runtime tradeoff) ortaya çıkar. Motor elektriksel dinamiğini, bara gerilimini ve sürtünmeyi içeren tam bir Simscape eyleyici modeli, çözücüye katılık (stiffness) getirir ve değişken adımlı çözücünün adım maliyetini artırır. Buna pertürbasyonlu çevre (J2 ve daha yüksek zonal harmonikler, yoğunluk modeline bağlı sürükleme, güneş radyasyon basıncı) ile atalet belirsizliği, algılayıcı gürültü tohumları ve başlangıç açısal hızı üzerinde binlerce Monte Carlo koşumu eklendiğinde, hesap yükü tek bir masaüstü oturumunda taşınamaz hâle gelir. Bu yükü paralel koşum (parsim) ve hızlandırılmış kip (accelerator) bir ölçüde azaltır.

Bazı etkiler bu döngünün doğal olarak dışında kalır. Esnek gövde modları (flexible body modes), güneş paneli ve antenler gibi eklentilerin yapısal titreşimini kontrolcü bant genişliğiyle kuplajlar ve katı cisim varsayımını geçersiz kılar. Termal kuplaj (thermal coupling), yapısal eğilme ve algılayıcı hizası üzerinde yavaş ama ölçülebilir bir kayma yaratır. Yıldız izleyicinin ayrıntılı optik ve radyometrik modeli (saçılan ışık, gürültü eşdeğeri açı) ise ayrı bir simülasyon alanıdır. Bu etkiler tek bir Simulink modeline sığmaz ve ortak simülasyon (co-simulation) ya da donanım döngüde test (hardware-in-the-loop, HIL) gerektirir.

Nerede durup sadakat eklemeyi kesmek gerektiği bir araç ayarı değil, doğrulanan gereksinime bağlı bir mühendislik kararıdır. İşaretleme doğruluğu bütçesini doğrulamak için eyleyici doyması ve algılayıcı gürültüsü modelde bulunmalıdır. Termal sürüklenmeyi doğrulamak için ise ayrı bir analiz alanı gerekir.

Model gerçek donanıma HIL aşamasında bağlanır. Speedgoat gerçek zamanlı hedef üzerinde uçuş yazılımı döngüde koşar, gerçek giriş çıkış (RS-485, algılayıcı öykünmesi) bağlanır ve model sabit bir örnekleme periyoduna (sample time) zorlanır. Masaüstünde gizli kalan zamanlama varsayımları burada açığa çıkar. Gerçek zamanlı aşım (real-time overrun), giriş çıkış gecikmesi ve çözücü bütçesi ancak gerçek bir saat altında ölçülür. Sonraki adım budur ve varsayımların gerçek zamana karşı sınandığı yer de orasıdır.

Sonuç

Gereksinimden doğrulamaya uzanan bu zincir, bir uydu sisteminin mühendislik karmaşıklığını tek bir model çatısı altında yönetmenin mümkün olduğunu gösteriyor. Requirements Toolbox’tan Simulink Design Verifier’a kadar kullandığımız her araç, bir önceki adımın çıktısını girdi olarak alıyor, bu da hata yayılımını minimuma indiriyor ve ECSS-E-ST-40 Cgibi standartların gerektirdiği iz sürülebilirliği otomatik olarak sağlıyor. Esnek gövde modları, termal kuplaj ve gerçek zamanlı HIL doğrulaması bu makalenin kapsamı dışında kaldı; bunları ilerleyen yazılarda ele alacağız. Bu aşamada anlatılan zinciri kendi projenize uyarlamak veya araçlar hakkında teknik destek almak istiyorsanız bizimle iletişime geçin.

MATLAB ile Ücretsiz Yerel LLM Kullanarak Uçtan Uca RAG Nasıl Kurulur?

Büyük dil modelleri eğitim verisinde olmayan teknik dokümanları, proje raporlarını veya şirket içi kılavuzları bilemez ve bu bilmediği yerde genellikle istenen cevabı veremeyebilir. Retrieval-Augmented Generation (RAG) bu sorunu yapısal olarak çözer: model yanıt üretmeden önce belge koleksiyonunuzdan ilgili parçaları bulur, bu bağlamı prompt içine ekler ve kaynaklarınıza dayalı yanıt üretir.

Bu yazıda MATLAB’ın Text Analytics Toolbox ve LLMs with MATLAB Add-On araçlarını kullanarak — BM25, document embedding, hybrid search ve Ollama üzerinden ücretsiz yerel LLM entegrasyonu dahil — uçtan uca bir RAG iş akışını nasıl kurabileceğinizi adım adım ele alıyoruz.

RAG Nedir ve LLM’ler Neden RAG’e İhtiyaç Duyar?

Retrieval-Augmented Generation (RAG), büyük dil modellerinin yanıt üretmeden önce ilgili bilgi parçalarını güvenilir kaynaklardan bulmasını ve ardından bu bağlamı kullanarak cevap üretmesini sağlayan bir yaklaşımdır. Temel fikir oldukça basittir: önce ara, sonra cevap üret.

Bu yaklaşım özellikle teknik dokümanlar, ürün notları, şirket içi veriler ve güncel raporlar gibi modelin eğitim verisinde doğrudan yer almayan içerikler için önemlidir. LLM tek başına güçlü bir dil üreticisi olsa da, güncel veya kuruma özel içeriklerde hatalı ve dayanağı zayıf cevaplar verebilir. RAG, bu sorunu retrieval katmanı ile azaltır.

Kısa Terimler Sözlüğü

TerimAçıklama
LLMLarge Language Model. Büyük metin veri kümeleri üzerinde eğitilmiş ve doğal dil üretimi yapabilen model ailesi.
RAGRetrieval-Augmented Generation. Yanıt üretmeden önce ilgili içeriği bulup modele bağlam olarak veren yaklaşım.
BM25Anahtar kelime tabanlı retrieval yöntemi. Kelime sıklığı ve belge uzunluğuna göre skor üretir.
EmbeddingMetni sabit boyutlu yoğun vektörler hâline dönüştüren temsil yöntemi. Semantik benzerlik için kullanılır.
Hybrid SearchBM25 ve embedding tabanlı aramanın birlikte kullanılması.
RRFReciprocal Rank Fusion. Farklı retrieval sıralamalarını tek listede birleştiren yöntem.
t-SNEYüksek boyutlu vektörleri iki boyuta indirerek benzerlik yapısını görselleştirmeye yarayan yöntem.

MATLAB & Simulink Tarafında Kullanılan Toolbox ve Add-On’lar

Bu blog yazısındaki ana akış doğrudan MATLAB kodu üzerinden ilerler. Simulink tarafı burada zorunlu değildir, kullanılabilir.

  • MATLAB: Temel betik akışı, dosya yönetimi, veri hazırlama ve LLM çağrıları için kullanılır.
  • Text Analytics Toolbox: tokenizedDocument, splitParagraphs, bm25Similarity, documentEmbedding, embed ve cosineSimilarity gibi metin analizi ve retrieval fonksiyonlarını sağlar.
  • Large Language Models (LLMs) with MATLAB Add-On: ollamaChat ve generate gibi fonksiyonlarla Ollama, OpenAI ve Azure OpenAI bağlantılarını mümkün kılar.
  • Text Analytics Toolbox Model Support Package: all-MiniLM-L6-v2 veya all-MiniLM-L12-v2 gibi embedding modellerinin kullanılmasına yardımcı olur.
  • Database Toolbox (opsiyonel): PostgreSQL + pgvector gibi sistemlerle embedding vektörlerini veritabanında saklamak ve sorgulamak için kullanılabilir.
  • Simulink: Bu dokümandaki RAG akışının temel parçası değildir; istenirse sonraki aşamalarda uygulama genişletmesi olarak ele alınabilir.

Uçtan Uca RAG İş Akışı

Aşağıdaki akış, blog yazısında anlatacağımız uçtan uca RAG yapısını sade bir şekilde özetler. Önce belge toplama ve ön işleme yapılır; ardından retrieval katmanı ile ilgili parçalar bulunur, bu parçalar prompt içine yerleştirilir ve yerel LLM üzerinden yanıt üretilir.

Şekil 1 – MATLAB ile RAG iş akışı (NotebookLM)

Belgeleri İçeri Alma ve Ön İşleme

RAG sürecinin ilk adımı, çalışılacak belgeleri içeri almaktır. Bu belgeler web üzerinden indirilebilir veya doğrudan yerel bir klasörden okunabilir. Amaç, retrieval aşamasında kullanılabilecek temiz ve aranabilir bir doküman koleksiyonu oluşturmaktır.

Aşağıdaki örnek, belgeleri belirli bir klasöre indirir. Böylece aynı veri seti üzerinde tekrar tekrar çalışmak kolaylaşır.

url = [“https://openknowledge.worldbank.org/bitstreams/0c18c872-91f0-51a4-ba91-c36b98893b4a/download”
“https://openknowledge.worldbank.org/bitstreams/476f037b-a17e-484f-9cc2-282a2e5a929f/download”
“https://openknowledge.worldbank.org/bitstreams/0c18c872-91f0-51a4-ba91-c36b98893b4a/download”];
 
localpath = “./data/”;
if ~exist(localpath, “dir”)
    mkdir(localpath);
end
numFiles = numel(url);
for i = 1:numFiles
    filename = “WBD_” + i + “.pdf”;
    localFileName = fullfile(localpath, filename);
    if ~exist(localFileName,”file”)
        websave(localFileName, url{i}, weboptions(Timeout=30));
    end
end
 

Belgeler indirildikten sonra, farklı dosya tipleri tek bir akışta okunabilir. extractFileText fonksiyonu, PDF veya DOCX gibi formatlardan metin çıkarmayı sağlar. Ardından preprocessDocuments yardımcı fonksiyonu ile metin, paragraf tabanlı daha küçük birimlere ayrılır.

readFcn = @extractFileText;
filePattern = [“.txt”,”.pdf”,”.docx”,”.html”,”.htm”];
fds = fileDatastore(localpath,’FileExtensions’,filePattern,’ReadFcn’,readFcn);
 
str = readall(fds);
str = [str{:}];
 
documents = preprocessDocuments(str);

Aşağıdaki yardımcı fonksiyon, belgeleri tokenize eder ve retrieval için uygun paragraf parçalarına dönüştürür.

function allDocs = preprocessDocuments(str)
    tokenized = tokenizedDocument(join(str,[newline newline]));
    allDocs = splitParagraphs(tokenized);
end
 
function wrappedText = wrapText(text)
    s = textwrap(text,80);
    wrappedText = string(join(s,newline));
end

BM25 ile Anahtar Kelime Tabanlı Retrieval

Şekil 2 – BM25  tabanlı Retrieval (ChatGPT)

BM25, klasik ve güçlü bir sparse retrieval yöntemidir. Kullanıcı sorgusundaki kelimeleri belge parçalarıyla karşılaştırır; kelime sıklığı ve belge uzunluğu gibi ölçütlere göre en ilgili parçaları öne çıkarır. Özellikle belirli ürün adları, fonksiyon isimleri veya teknik terimler gibi açık anahtar kelimelerde oldukça etkilidir.

İlk örnek, BM25 skorlarını hesaplar ve dokümanları en yüksek skordan en düşüğe doğru sıralar.

scores = bm25Similarity(documents,query);
[~,idx] = sort(scores,”descend”);
 
rankSparse = 1:length(documents);
rankSparse(idx) = rankSparse;

Pratikte retrieval sonuçlarının tamamı prompt içine gönderilmez. Bunun yerine, en alakalı parçalar seçilir ve toplam kelime sayısı belirli bir sınırda tutulur. Aşağıdaki örnek bu seçimi göstermektedir.

query = “What technical criteria can be used to streamline new approvals for grid-friendly DPV?”;
 
embQuery = bm25Similarity(documents, tokenizedDocument(query));
 
[~, idx] = sort(embQuery, “descend”);
limitWords = 1000;
selectedDocs = [];
totalWords = 0;
 
i = 1;
while totalWords <= limitWords && i <= length(idx)
    totalWords = totalWords + doclength(documents(idx(i)));
    selectedDocs = [selectedDocs; joinWords(documents(idx(i)))];
    i = i + 1;
end

Document Embedding ile Semantik Retrieval

Şekil 3 – Semantik Retrieval (ChatGPT)

BM25 aynı kelimeleri yakalamakta güçlüdür; ancak sorgu ile doküman benzer anlam taşısa bile aynı terimleri kullanmıyorsa bazı ilgili parçalar gözden kaçabilir. Bu nedenle embedding tabanlı retrieval, metinlerin semantik olarak birbirine ne kadar yakın olduğunu ölçmek için kullanılır.

Aşağıdaki örnekte all-MiniLM-L12-v2 modeli ile hem dokümanlar hem de kullanıcı sorgusu vektör uzayında temsil edilir. Daha sonra cosineSimilarity ile benzerlik hesaplanır.

emb = documentEmbedding(Model=”all-MiniLM-L12-v2″);
embeddedDocuments = embed(emb,documents);
embeddedQuery = embed(emb,query);
 
scores = cosineSimilarity(embeddedDocuments,embeddedQuery);
[~,idx] = sort(scores,”descend”);
 
rankDense = 1:length(documents);
rankDense(idx) = rankDense;

Hybrid Search ve Reciprocal Rank Fusion (RRF)

Şekil 4 – Hybrid yaklaşım (BM25 + Embedding) (ChatGPT) 

Birçok gerçek senaryoda en iyi sonuç, yalnızca BM25 veya yalnızca embedding kullanmak yerine bu iki yaklaşımı birleştirmekle elde edilir. BM25 açık terimleri yakalarken, embedding semantik yakınlığı yakalar. Hybrid search bu iki güçlü tarafı bir araya getirir.

Reciprocal Rank Fusion (RRF), sparse ve dense retrieval sıralamalarını tek bir listede birleştirmek için kullanılan pratik bir yöntemdir. Aşağıdaki örnek, iki sıralamayı bir RRF skoru ile birleştirmektedir.

k = 60;
rrfScores = 1./(k*rankSparse) + 1./(k*rankDense);

💡 Neden Hybrid Search?

BM25, sorguda geçen açık terimleri güçlü şekilde yakalar. Embedding retrieval ise farklı kelimeler kullanılsa bile anlamca yakın içerikleri öne çıkarabilir. Hybrid yaklaşım, her iki yöntemin güçlü yanlarını aynı akışta birleştirir.

Örneğin “Büyük kurbağa küçük gölette” ve “Küçük kurbağa büyük gölette” cümleleri aynı kelimeleri içerir; ancak kelimelerin cümle içindeki rolleri değiştiği için anlamları farklıdır. Embedding tabanlı yöntemler, kelime sırasını, bağlamı ve anlamsal ilişkiyi dikkate alarak bu tür farkları yakalamada daha başarılıdır.

Vektörleri Veritabanında Saklama

Küçük örneklerde embedding vektörlerini doğrudan MATLAB değişkenlerinde tutmak yeterli olabilir. Ancak doküman sayısı büyüdüğünde, vektörleri bir veritabanında saklamak ve sorgulamak daha sürdürülebilir bir yapıdır. PostgreSQL + pgvector bu amaçla sık kullanılan bir seçenektir.

Aşağıdaki örnek, embedding modelinin hazırlanmasını ve sorgu vektörünün SQL tarafında benzerlik araması için kullanılmasını göstermektedir.

modelName = “all-MiniLM-L12-v2”;
embeddingModel = documentEmbedding(Model = modelName);
 
query = “Will Federal Fund rate decrease after FOMC meeting in the following 3 months?”
embeddedQuery = embed(embeddingModel,query)
sqlEmbeddedQuery = “‘[” + join(string(embeddedQuery),”,”) + “]'”;
sqlCosineSimilarity = “SELECT text FROM embeddings_FOMC ORDER BY 1 – (embedding <=> ” + sqlEmbeddedQuery + “) DESC LIMIT 30”;
selectedDocs = fetch(conn,sqlCosineSimilarity);
head(selectedDocs,10)

Ollama ile Ücretsiz Yerel LLM’i MATLAB’e Dahil Etme

Retrieval adımı hazır olduğunda sıra, yerel LLM’i sürece dahil etmeye gelir. Ollama, açık kaynak ve ücretsiz modelleri yerel ortamda çalıştırmayı kolaylaştırır. MATLAB tarafında ise LLMs with MATLAB Add-On içindeki ollamaChat fonksiyonu kullanılarak bu modele bağlanılabilir.

Önce kullanılacak model Ollama üzerinden indirilir. Ardından MATLAB içinde bir chat nesnesi oluşturulur.

>> !ollama pull mistral
 
chat = ollamaChat(“mistral-nemo”, …
    “You are a helpful assistant. You will get a ” + …
    “context for each question, but only use the information ” + …
    “in the context if that makes sense to answer the question. ” + …
    “Lets think step-by-step, explaining how you reached the answer.”, …
    TimeOut=600);

Prompt İçine Context Yerleştirme ve Yanıt Üretimi

Bu aşamada retrieval katmanından gelen selectedDocs içeriği, prompt içindeki Context bölümüne eklenir. Böylece model, yalnızca genel bilgisine göre değil, retrieval ile seçilen spesifik bilgi parçalarına dayanarak yanıt üretir.

Aşağıdaki örnek, promptun nasıl kurulduğunu ve generate ile son yanıtın nasıl üretildiğini göstermektedir.

prompt = “Context:” + join(selectedDocs, ” “) + newline + …
    “Answer the following question: ” + query;
response = generate(chat, prompt);
 
wrapText(response)

t-SNE ile Retrieval Sonuçlarını Değerlendirme

Şekil 4 – t-SNE ile sonuçların değerlendirilmesi (Medium- Retheesh Ravi)

Retrieval kalitesini sadece “yanıt iyi görünüyor” şeklinde değerlendirmek yerine, kullanılan vektör temsilini daha analitik biçimde incelemek de mümkündür. Amaç, sorgu ile dönen dokümanların vektör uzayında birbirine ne kadar yakın olduğunu görsel olarak yorumlamaktır.

Sonuç

Bu yazıda, MATLAB kullanarak ücretsiz yerel LLM’lerle uçtan uca bir Retrieval-Augmented Generation (RAG) iş akışının nasıl kurulabileceğini ele aldık. Temel akış; belgelerin içeri alınması, ön işlenmesi, ilgili parçaların retrieval yöntemleriyle seçilmesi, bu parçaların prompt içine context olarak eklenmesi ve yerel LLM üzerinden yanıt üretilmesi adımlarından oluşur.

RAG yaklaşımı, LLM’lerin yalnızca genel bilgisine dayanmak yerine güvenilir dokümanlardan getirilen içerikle yanıt üretmesini sağlar. Bu sayede özellikle teknik dokümanlar, ürün notları, raporlar ve kuruma özel bilgi tabanları üzerinde daha kontrollü ve açıklanabilir cevaplar üretilebilir.

MATLAB tarafında Text Analytics Toolbox ile BM25, document embedding ve hybrid search gibi retrieval yaklaşımları uygulanabilirken, LLMs with MATLAB Add-On ile Ollama üzerinden çalışan yerel modeller sürece dahil edilebilir. Küçük veri setlerinde doküman parçaları ve embedding vektörleri MATLAB değişkenleri içinde yönetilebilir; daha büyük koleksiyonlarda ise PostgreSQL + pgvector gibi veritabanı çözümleri kullanılabilir.

Sonuç olarak, MATLAB ile RAG yalnızca bir LLM çağrısından ibaret değildir. Veri hazırlama, retrieval, context oluşturma, yerel model entegrasyonu ve sonuç değerlendirme adımlarını tek bir teknik iş akışında birleştiren uygulanabilir bir yaklaşımdır.

Mühendislikte Dijital Dönüşüm: MathWorks Ekosisteminde Agentic AI Kullanımı

Mühendislik yazılımlarında son yılların en büyük değişimi yalnızca modelleme ve simülasyon tarafında değil, aynı zamanda geliştirme süreçlerinin nasıl hızlandırıldığı tarafında yaşanıyor. Artık mühendisler sadece sistem tasarlamıyor; yapay zeka destekli araçlarla model kuruyor, test süreçlerini otomatikleştiriyor ve kod üretiyor.

Öne çıkan yeni kullanım senaryolarından biri de Claude Code gibi büyük dil modellerinin mühendislik iş akışına entegrasyonudur.

Bu yazıda, MathWorks ekosisteminde Model Tabanlı Tasarım yaklaşımının, Claude Code tabanlı bir agent ile nasıl uçtan uca otonom bir mühendislik akışına dönüştürüldüğü ele alınmaktadır. Amaç, tek tek araç kullanımını göstermek değil; tüm mühendislik yaşam döngüsünün nasıl orkestre edilebildiğini ortaya koymaktır.

Sistem yaklaşımı: Araçlardan Akışa Geçiş

Geleneksel mühendislik süreçlerinde gereksinim yönetimi, sistem mimarisi, test, doğrulama, kaynak kodu ve CI/CD adımları genellikle farklı araçlar ve farklı sorumluluk alanları üzerinden yürütülür. Bu durum güçlü bir ekosistemin parçalı bir iş akışına dönüşmesine neden olabilir.

Bu çalışmada ise yaklaşım tersine çevrilmiştir:

Odak, araçları ayrı ayrı kullanmak değil; tüm mühendislik akışını tek bir sistem davranışı olarak orkestre etmektir.

Bu amaçla Claude Code tabanlı bir agent, MATLAB ortamına entegre edilerek mühendislik sürecinin aktif bir bileşeni haline getirilmiştir.

Mühendislik Ajanı

Claude Code tabanlı agent, MATLAB ve Simulink ortamına entegre edilerek yalnızca komut çalıştıran bir yapıdan çıkarılıp, sistemi anlayan bir mühendislik orkestratörüne dönüştürülmüştür.

Bu agent şu döngü ile çalışmaktadır:

  • Sistem modelini analiz eder
  • Eksiklikleri ve tutarsızlıkları tespit eder
  • Bir sonraki mühendislik adımını önerir
  • Kritik değişiklikler için mühendis onayı ister
  • Aksiyonları uygular
  • Sonuçları doğrular
  • Süreci versiyon kontrolüne işler

Bu yapı sayesinde mühendis, her adımı manuel olarak gerçekleştiren bir operatör değil; sistemin karar mekanizmasını yöneten bir denetleyici haline gelir.

Mühendislik Akışı

Sistem Entegrasyonu ve Başlangıç Analizi

Çalışmanın ilk aşamasında farklı kaynaklardan gelen model ve sistem bileşenleri bir araya getirilmiştir.

İlk analizde sistemde şu problemler tespit edilmiştir:

  • Eksik veya tutarsız model referansları
  • Çakışan veri tanımları
  • Uyumsuz sistem arayüzleri
  • Yapılandırma eksiklikleri

Agent bu problemleri analiz ederek sistemin çalışabilir bir başlangıç durumuna getirilmesini sağlamıştır.

Gereksinim–Tasarım İzlenebilirliği

Sistemdeki en kritik sorunlardan biri, gereksinimler ile tasarım bileşenleri arasındaki bağlantıların eksik olmasıdır.

Bu aşamada Agent:

  • Tüm gereksinimleri analiz eder.
  • Gereksinimlerden üretilen sistem bileşenleri arasındaki ilişkileri kurar.
  • Uçtan uca izlenebilirlik yapısını yeniden oluşturur.

Doğrulama ve Test Akışı

Sistem davranışını doğrulamak için senaryo tabanlı test yapısı oluşturulmuştur.

Bu aşamada:

  • Sistem davranış senaryoları tanımlanmış
  • Model giriş/çıkış tutarlılığı kontrol edilmiş
  • Veri akışındaki hatalar giderilmiştir

Bu sayede sistem farklı operasyon senaryoları altında doğrulanabilir hale gelmiştir.

Üretim Kodu Oluşturma

Model tabanlı tasarım yaklaşımı kullanılarak sistemden doğrudan üretim seviyesinde kod oluşturulmuştur.

Bu süreç:

  • Modelden otomatik kod üretimi
  • Derlenebilirlik kontrolü
  • İzlenebilirlik bağlantılarının korunması

adımlarını içermektedir.

Sistem Dayanıklılığı ve Hata Senaryoları

Farklı arıza senaryoları sistem davranışını test etmek için simüle edilmiştir:

  • Sensör kaybı
  • Veri bozulması
  • Aktüatör hataları

Sisteme ayrıca gerçek zamanlı bir sağlık izleme yaklaşımı entegre edilmiştir.

Formal Doğrulama

Kritik sistem davranışları yalnızca test edilmemiş, aynı zamanda matematiksel olarak doğrulanmıştır.

Bu aşamada:

  • Bazı davranışlar formal olarak ispatlanmış
  • Ulaşılmayan kod yolları tespit edilmiş
  • Test senaryoları otomatik türetilmiştir

Kod Kalitesi ve Sistem Olgunlaştırma

Sistem iteratif olarak daha güvenilir hale getirilmiştir:

  • Test kapsamı artırılmış
  • Statik analiz hataları giderilmiş
  • Sistem davranışı deterministik hale getirilmiştir

Süreç Otomasyonu ve Ekip Yapısı

Gerçek mühendislik süreçlerine uyumlu olacak şekilde:

  • Branch koruma yapısı oluşturulmuş
  • Kod inceleme süreçleri standartlaştırılmış
  • Rol bazlı sorumluluk modeli tanımlanmıştır

Operasyonel Senaryo Yönetimi

Sistem farklı çalışma modlarına ayrılmıştır:

  • Nominal operasyon modu
  • Riskli operasyon modu
  • Özel konfigürasyon senaryoları

Otomatik Dokümantasyon

Sistemden doğrudan:

  • Tasarım dokümanı
  • Test raporu

üretilecek şekilde bir yapı kurulmuştur. Tüm dokümanlar sistem verisinden türetilmiştir.

Dayanıklılık Analizi

Çok sayıda simülasyon çalıştırılarak sistem davranışı analiz edilmiştir.

Sonuçlar:

  • Yüksek stabilite
  • Düşük hata oranı
  • Parametre değişimlerine karşı güçlü tolerans

Gerçek Zamanlı Sistem Davranışı

Sistem 3D ortamda çalıştırılarak gerçek zamanlı şekilde gözlemlenmiştir. Bu aşamada sistemin davranışı simülasyon ortamında canlı olarak takip edilebilir hale gelmiştir.

Sonuç

Bu çalışma bir araç gösterimi değil, uçtan uca bir mühendislik akışı demonstrasyonudur.

MathWorks ekosistemi, model tabanlı tasarım yaklaşımı ile gereksinimden doğrulamaya, simülasyondan üretim koda kadar tüm mühendislik yaşam döngüsünü kapsayan güçlü bir altyapı sunmaktadır.

Ancak bu çalışmada görülen temel fark, araçların kendisi değil, bu araçların nasıl birlikte orkestre edildiğidir.

Claude Code tabanlı agent yaklaşımı ile:

  • Mühendislik süreci tek bir akış olarak yönetilebilmekte
  • Sistem kendi durumunu analiz edebilmekte
  • Bir sonraki adımı önerip uygulayabilmektedir.

Bu yaklaşımda mühendis, araçları tek tek kullanan bir operatör değil; sistemin davranışını yöneten karar verici konumundadır.

Mühendislik Yolculuğunuzda Yanınızdayız

MATLAB & Simulink çözümleri, teknik danışmanlık, eğitimler veya projeleriniz hakkında sorularınız mı var? Sorularınızı yanıtlamaktan ve projelerinize değer katacak çözümler sunmaktan memnuniyet duyarız.

MATLAB’den CUDA Kodu Üretimi: Gömülü Görüntü İşleme ve Derin Öğrenme Algoritmalarının GPU’lar Üzerinde Hızlandırılması

MATLAB ile GPU Kod Oluşturmayı Tanıtıyoruz

GPU hesaplama, verilerin devasa ölçekte paralel hesaplanmasına olanak tanıdığı için derin öğrenme uygulamalarının büyümesine katkıda bulunmaktadır. GPU hesaplama, algoritmalarınızdaki veri paralelliğinden (data parallelism) yararlanarak uygulamalarınızı hızlandırır. Bu durum; derin öğrenmenin yanı sıra gömülü görüntü işleme ve radar gibi alanlardaki hesaplama açısından yoğun algoritmalar için performans hedeflerine ulaşılmasında kilit rol oynar.

GPU ile hızlandırılmış hesaplama, heterojen bir programlama modelini takip eder; uygulamanızın paralelleştirilebilen kısımları, GPU üzerindeki yüzlerce veya binlerce paralel çekirdekte eşzamanlı olarak yürütülen çekirdeklere (kernels) atanırken, kodun ardışık (sıralı) kısımları CPU üzerinde çalışır.

GPU Coder™, NVIDIA® GPU’larda yürütülmek üzere MATLAB® kodundan otomatik olarak CUDA® kodu üreterek mevcut MATLAB algoritmalarınızı GPU’lar üzerinde hızlandırır. Üretilen CUDA kodu, CPU ve GPU arasındaki veri transferi yükünü (overhead) en aza indirirken, paralellik için optimize edilir. Kod üretimi sırasında GPU Coder, CPU ve GPU bölümleri (partitions) arasındaki veri bağımlılığını (data dependency) analiz eder. Bu analiz, verilerin CPU ve GPU arasında kopyalanması gereken minimum konum setini belirler.

CPU ve GPU arasındaki bellek bant genişliği darboğazı (memory bandwidth bottleneck), algoritmaların GPU’larda performans kaybı yaşamasının temel nedenidir; veri transferini en aza indirme yeteneği, önemli performans kazanımları sağlar. Otomatik bir iş akışı, CUDA’da elle kod yazmaktan kaynaklanabilecek zorlukların ve artan hataların önüne geçer.

GPU Coder; masaüstü, bulut veya NVIDIA Jetson® ve NVIDIA Drive® platformlarını içeren gömülü cihazlar üzerinde çalışan GPU’larda algoritmalarınızı hızlandırır. Şekil 1 ve 2 bu performans iyileştirmelerini vurgulamaktadır.

Uygulamalar; SURF öznitelik çıkarımı (feature extraction), stereo uyumsuzluk (stereo disparity) ve sis giderme (fog removal) gibi yaygın görüntü işleme operasyonlarının yanı sıra FFT (Hızlı Fourier Dönüşümü) gibi yaygın sinyal işleme operasyonlarında iki kata kadar (100 kata kadar/iki büyüklük mertebesi) performans artışı sağlayabilir.

Testing PlatformMATLAB 2018a
CPUIntel Xeon CPU E5-1650 v3 @ 3.50 GHz
GPUNVIDIA Pascal TITAN V (Volta architecture)
CUDAVersion 9.0

Şekil 1. GPU’larda çalışan GPU Coder tarafından oluşturulan CUDA kodu ile CPU’larda çalışan C kodu arasında yaygın görüntü işleme ve sinyal işleme performans karşılaştırmaları.

Şekil 2, GPU Coder ile üretilen CUDA kodunun çıkarım (inference) performansını diğer popüler derin öğrenme çerçeveleriyle (frameworks) kıyaslamaktadır. GPU Coder tarafından üretilen kod, TensorFlow™‘dan beş kat, Apache MXNet‘ten ise iki kat daha hızlı çalışmaktadır.

CPUIntel Xeon CPU E5-1650 v4 @ 3.60 GHz
GPUNVIDIA Pascal TITAN Xp
cuDNNv7

Şekil 2. Derin öğrenme performans karşılaştırmaları: NVIDIA Titan® Xp üzerinde çalışan GPU Coder, TensorFlow ve MXNet’in AlexNet çıkarım performansı karşılaştırması.

Tipik bir derin öğrenme algoritmasının; çıkarım (inference) için bir veya daha fazla eğitilmiş ağı çağıran bir kullanıcı mantığından (user logic) oluştuğunu unutmayın. GPU Coder ile, herhangi bir manuel kodlamaya gerek duymadan tüm uygulamanın kodunu otomatik olarak üretebilirsiniz.

Örneğin, çok basit bir görüntü sınıflandırma görevinde kullanıcı mantığı; görüntünün yeniden boyutlandırılması ve renk uzayının değiştirilmesi gibi ön işleme (pre-processing) adımlarını ve sınırlayıcı kutu (bounding box) çizilmesi gibi son işleme (post-processing) adımlarını içerebilir. GPU Coder, uygulamanın tamamından kod üretir (Şekil 3).

Şekil 3. GPU Coder kullanarak uçtan uca uygulamanın tamamı için kod oluşturma.

Üst Düzey İş Akışı

Şekil 4, algoritma tasarımından kod üretimine ve ardından dağıtıma kadar uzanan tipik iş akışını göstermektedir. Sürece, MATLAB kodunu kod üretimi için hazırlayarak başlarsınız; ardından üretilen kodun orijinal MATLAB koduyla işlevsel olarak aynı şekilde çalıştığından emin olmak için test aşamasına geçersiniz.

Üçüncü adımda kodu; ya bir MEX dosyası olarak (hızlandırma amacıyla orijinal MATLAB algoritmasının yerine geçmesi için) ya da daha büyük bir CUDA projesine entegre edilebilecek bir statik/dinamik kütüphane veya kaynak kod biçimindeki CUDA kodu olarak üretebilirsiniz. İsteğe bağlı olan dördüncü adım ise, üretilen kodun performansını artırmak için MATLAB kodunu daha fazla optimize etmektir.

Şekil 4. MATLAB kodundan CUDA kodu oluşturmak için iş akışı.

Trafik İşareti Algılama Uygulaması

Bu bölüm; derin öğrenme tabanlı bir trafik işareti tespiti örneğini kullanarak, kod üretimi iş akışını daha ayrıntılı bir şekilde incelemektedir. Trafik işareti tespiti ve tanıma işlemini gerçekleştirmek için gereken üç temel adım; tespit (detection), maksimum olmayan bastırma (non-maximal suppression- NMS) ve tanımadır (recognition). Aşağıdaki işlemleri yapan bir MATLAB algoritması ile başlayabilirsiniz:

  • Bir test görüntüsünü okumak ve ön işlemeden geçirmek,
  • Trafik işaretini tespit etmek için nesne tespit ağının (object detection network) tahmin (prediction) yöntemini çağırmak,
  • NMS algoritmasını kullanarak üst üste binen tespitleri bastırmak,
  • İşareti tanımlamak için tanıma ağının (recognition network) tahmin yöntemini çağırmak,
  • Sınırlayıcı kutular (bounding boxes) ve bunlara karşılık gelen tespit etiketlerini içeren bir çıktı görüntüsü görüntülemek.

Bu algoritma için CUDA kodu üretmek amacıyla, işe bu MATLAB betiğini (script) kod üretimine hazırlayarak başlayabilirsiniz.

GPU Kod Oluşturma için MATLAB Kodunu Hazırlama

Bir MATLAB algoritmasını kod üretimine hazırlamak için şu adımları izlersiniz:

  1. Algoritmayı test düzeneğinden (test bench) ayırın. İşe algoritmayı test düzeneğinden ayırarak ve algoritma kodunu bir fonksiyon haline getirerek başlayın. Ayrıca algoritmanızı; derin öğrenme ağı çıkarım fonksiyonu ile ön işleme ve son işleme fonksiyonları olarak kısımlara ayırmak iyi bir uygulamadır.
  2. Algoritmanın hesaplama açısından yoğun kısımlarını belirleyin. Algoritmadaki darboğazları (hotspots) belirlemek ve profillemek için MATLAB Profiler’ı kullanın. Bir sonraki adımda kolaylık sağlaması için bu kritik noktaları ayrı fonksiyonlar haline getirin.
  3. GPU Coder’ı, darboğazları otomatik olarak CUDA çekirdeklerine (kernels) eşlemesi için yönlendirin. Darboğaz fonksiyonlarının başına coder.gpu.kernelfun pragmalarını (komutlarını) yerleştirin. Bu, GPU Coder’ın bu hesaplama açısından maliyetli fonksiyonları analiz etmesini ve onlardan en verimli CUDA çekirdeklerini oluşturmasını sağlar.
  4. Algoritmanın kod üretimi ile uyumlu olduğundan emin olun. Bu süreci yürütmek için GPU Coder arayüzünü kullanın. GPU Coder, desteklenmeyen fonksiyonlar ve yapılar dahil olmak üzere kod üretimi uyumluluk sorunlarını tespit etmek için bir “kod üretimi hazırlık aracı” çalıştırarak başlar:
    1. Sınırlandırılmamış değişken boyutlu veriler: GPU Coder, sınırları belirlenmiş (bounded) değişkenlerden kod üretir. Eğer kod üreticisi bir dizinin boyutunu belirleyemezse veya boyutun değiştiğini saptarsa, o boyut “değişken boyutlu” (variable-size) olarak kabul edilir. GPU Coder, sınırlandırılmamış değişkenler veya diziler için uyarı verir. Bu durumda, kod üreticisinin belleği statik olarak ayırabilmesi için bir üst sınır (upper bound) belirtmeniz gerekir:
      1. Giriş değişkenleri için üst sınır belirtme: Değişken boyutlu girişlerin üst sınırlarını belirtmek için coder.typeof yapısını kullanın.
      1. Yerel değişkenler için üst sınır belirtme: Değişken boyutlu dizilerin boyutlarını belirleyen değişkenlerin değerlerini kısıtlamak için ilişkisel operatörlerle birlikte assert fonksiyonunu kullanın veya bir fonksiyondaki yerel değişkenin tüm örnekleri için üst sınırları belirtmek üzere coder.varsize fonksiyonunu kullanın.
  5. Potansiyel çalışma zamanı (run-time) hatalarını kontrol edin. Kod üretimi uyumluluğunu kontrol ettikten sonra, çalışma zamanı hatalarını tespit edip düzeltmek için çalışma zamanı kontrolleri yapmanızı öneririz. Bellek bütünlüğünü doğrulamak, dizi sınırlarını kontrol etmek ve boyut kontrolü yapmak için CPU çalışma zamanı kontrollerini çalıştırın. Kayıtçı taşmalarını (register spills) belirlemek ve yığın boyutu (stack size) uyumluluğunu doğrulamak için GPU çalışma zamanı kontrollerini çalıştırın.

Trafik İşareti Algılama MATLAB Komut Dosyasını Kod Oluşturma için Hazırlama

Yukarıdaki adımları izleyerek; ilk aşamada tsdr adını verdiğimiz algoritmik kod, tsdr_test.m adlı test düzeneği betiğinden ayrılır. Fonksiyonu MATLAB üzerinde profillediğinizde (profiling), fonksiyon içinde izole edilecek özel bir darboğaz (hotspot) olmadığını görürsünüz. Bu durum, coder.gpu.kernelfun pragmasını tsdr fonksiyonuna yerleştirerek fonksiyonun tamamını GPU’ya eşleyebileceğiniz anlamına gelir.

Üretilen MEX Dosyasının Test Edilmesi

Kod artık kod üretimi için hazır olduğuna göre, ilk yapmanız gereken şey; üretilen MEX dosyasını MATLAB içerisinde test ederek orijinal kodla işlevsel olarak aynı şekilde çalıştığından emin olmaktır. Bunun için bir MEX fonksiyonu oluşturursunuz. MEX; derlenmiş ikili dosyayı (compiled binary) MATLAB içinde çağırmanıza ve orijinal fonksiyonun yerine kullanmanıza olanak tanıyan bir “sarmalayıcı” (wrapper) arayüzüdür.

GPU Coder uygulamasında, CUDA kodu üretmek için derleme türü (build type) olarak MEX‘i seçin ve bunu NVIDIA’nın nvcc derleyicisini kullanarak bir MEX fonksiyonuna dönüştürün. Kod doğrulama adımında, test düzeneğinizden (test bench) bu MEX fonksiyonunu çağırarak, üretilen kodun orijinal MATLAB fonksiyonuyla aynı işlevselliği sağladığını teyit edebilirsiniz.

Bu örnek uygulamada; üretilen kodun davranışını doğrulamak için MEX hedefi üretir ve doğrulama adımında testi MEX versiyonu ile çalıştırırsınız.

GPU Coder’ı Embedded Coder® ile birlikte kullanarak; üretilen bağımsız (standalone) C++ kodunun nümerik davranışını, gömülü GPU’nuza dağıtıldığı haliyle doğrulamak için Yazılım Döngüde (SIL – Software-in-the-Loop) yürütme yöntemini kullanabilir ve böylece kodu daha ileri düzeyde test edebilirsiniz. Bu yöntem, MEX dosyası ile seri üretim kalitesindeki bağımsız (standalone) kod arasındaki her türlü farkı tespit etmenize olanak tanır.

MEX veya Kaynak Kod Olarak Kod Üretimi: Masaüstü, Bulut veya Gömülü GPU’larda Dağıtım

Üretilen MEX fonksiyonunun beklendiği gibi çalıştığını doğruladıktan sonra, sadece “derleme türü” (build type) seçeneğini değiştirerek bağımsız (standalone) C++ kodu veya bir statik kütüphane üretebilirsiniz. Ardından, üretilen kütüphaneyi geliştirme ortamınızdaki daha büyük bir uygulamaya entegre edebilir ve algoritmanızı masaüstüne veya buluta dağıtabilirsiniz.

Amacınız NVIDIA Jetson veya Drive gibi gömülü platformlara dağıtım yapmaksa, CUDA kaynak kodunu hedef cihaza aktarabilir ve derleme işlemini doğrudan cihaz üzerinde yapabilirsiniz. Jetson TX2, TX1 veya TK1 gibi NVIDIA Tegra® geliştirme kartları için bir diğer seçenek ise; üretilen kodu ana bilgisayarınızda (host machine) çapraz derlemek (cross-compile) ve ardından çalıştırılabilir dosyayı (executable) hedef cihaza kopyalayarak dağıtmaktır.

MEX derleme türü ile kod üretmenin önemli bir kullanım alanı da; yorumlanması gereken yerel MATLAB fonksiyonu yerine, GPU üzerinde çalışan derlenmiş ikili dosyayı (binary) çağırarak MATLAB içindeki hesaplama hızını artırmaktır.

Kod Üretimi ve Trafik İşareti Tespit Uygulamasının Dağıtımı

Trafik işareti tespiti örnek uygulamasında hedef, algoritmayı masaüstüne dağıtmaktır. Bu durumda, derleme türünü (build type) kaynak kod (source code) olarak seçer ve bir ana dosyaya (main file) entegre edilip çalıştırılabilir (executable) bir dosyaya dönüştürülebilen bağımsız C++ kodu üretirsiniz. Hatta bir adım daha ileri giderek, çapraz derlenebilen (cross-compiled) ve bir Jetson kartına dağıtılabilen bir statik kütüphane üretebilirsiniz.

Kodunuzu Daha Fazla Optimize Etmek İçin İpuçları

Eğer üretilen kod performans gereksinimlerinizi karşılamıyorsa, kodun performansını artırmak için ek adımlar ve optimizasyonlar uygulayabilirsiniz:

  • MEX Profil Oluşturma (Profile MEX) Kullanımı: Üretilen kodun performansındaki darboğazları belirlemek için MATLAB Profiler’ı kullanarak üretilen MEX fonksiyonunun yürütme sürelerini analiz edebilirsiniz. Üretilen kodun profili, ilgili MATLAB fonksiyonunun her bir satırı için çağrı sayısını ve harcanan süreyi gösterir. Belirli darboğazlar, MATLAB algoritmanızda birkaç küçük değişiklik yaparak veya kod üretimi seçeneklerini ayarlayarak giderilebilir; aşağıda birkaç teknik listelenmiştir.
  • coder.gpu.kernel Pragmasını Kullanma: Algoritmanızdaki bazı paralel döngüler üretilen kodun bazı kısımlarında paralelleştirilmemişse, GPU Coder’ı o döngü için bir “kernel” (çekirdek) üretmeye zorlamak amacıyla döngünün hemen önüne coder.gpu.kernel pragmasını yerleştirebilirsiniz. Bunun ileri düzey bir işlem olduğunu ve dikkatli kullanılması gerektiğini unutmayın.
  • Tasarım Şablonlarını (Design Patterns) Kullanma: Belirli bir giriş elemanının, birden fazla komşu çıktı elemanını hesaplamak için tekrar tekrar erişildiği algoritmalar için; hesaplama verimliliğini artırmak amacıyla şablon işlemleri (gpucoder.stencilKernel) veya matris-matris işlemleri (gpucoder.matrixMatrixKernel) gibi tasarım şablonlarını kullanabilirsiniz. Bu tasarım şablonları, performansı artırmak için GPU’nun paylaşımlı belleğinden (shared memory) yararlanır. Detaylar için tasarım şablonu dokümantasyonuna bakınız.
  • Özel CUDA Kodu Ekleme: Üretilen kodunuza dahil etmek istediğiniz, belirli alt fonksiyonlar için halihazırda elinizde bulunan yüksek derecede optimize edilmiş CUDA kodlarınız varsa; GPU Coder, bu özel kodları üretilen kodla entegre etmenize yardımcı olmak için coder.ceval işlevselliğini genişletir. Ayrıntılar için eski kod entegrasyonu (legacy code integration) dokümantasyonuna bakınız.
  • Kod Üretimi Seçeneklerini Özelleştirme: Kod üretimini aşağıdaki gibi seçeneklerle özel gereksinimlerinize göre daha fazla ayarlamak için kod üretimi yapılandırmasını (configuration) özelleştirebilirsiniz:
    • Bellek Atama Modu Ayarı: Ayrık (discrete) ve birleşik (unified) bellek atama modları arasında seçim yapma.
    • CUDA Kütüphaneleri Desteği: cuBLAS ve cuSOLVER gibi optimize edilmiş CUDA kütüphaneleri için desteği etkinleştirme.
    • Hedefin Hesaplama Kapasitesini (Compute Capability) Belirtme.
    • GPU Derleyicisine Ek Bayraklar (Flags) Gönderme.

Sonraki Adımlar

Simülasyon Sürelerini Nasıl Kısaltırsınız? Reduced Order Modeling Rehberi

Mühendislikte yüksek doğruluklu fizik tabanlı modeller çok değerlidir. Özellikle FEA, CFD veya PDE tabanlı modeller; sistem davranışını ayrıntılı biçimde temsil eder, tasarım kararlarını destekler ve fiziksel içgörü sağlar. Ancak aynı modelleri sistem seviyesi simülasyonlarda, kontrol tasarımında veya Hardware-in-the-Loop testlerinde kullanmak istediğimizde ciddi bir problem olan hesaplama maliyeti ile karşılaşırız.

Reduced Order Modeling (ROM), tam da bu noktada devreye girer. En basit haliyle ROM; bir modelin hesaplama karmaşıklığını azaltırken sistemin baskın davranışlarını korumayı amaçlayan yöntemler bütünüdür. Hedef, tam modeli birebir kopyalamak değil; kabul edilebilir doğrulukta ama çok daha hızlı çalışan bir temsil elde etmektir.

Bu yaklaşım sayesinde yüksek doğruluklu modeller, sistem seviyesinde yeniden kullanılabilir hale gelir. Böylece aynı fiziksel sistemi daha hafif, daha hızlı ve daha geniş test akışlarına uygun biçimde kullanmak mümkün olur.

Neden Reduced Order Modeling’e İhtiyaç Duyarız?

Yüksek doğruluklu mühendislik modellerinin en büyük avantajı ayrıntıdır; en büyük dezavantajı ise bu ayrıntının maliyetidir. Özellikle üçüncü parti FEA veya CFD araçlarından gelen modeller ya da PDE tabanlı çözümler, tek bir zaman adımında bile oldukça uzun çözüm sürelerine sahip olabilir.

Sistem seviyesi simülasyon, uzun süreli senaryo taraması, kontrol tasarımı ve HIL testleri gibi görevlerde bu maliyet çoğu zaman kabul edilemez hale gelir. Buradaki asıl mühendislik problemi, hızı artırırken doğruluk, güvenilirlik ve yorumlanabilirlik dengesini nasıl koruyacağımızdır.

İyi kurulmuş bir reduced-order model, yüksek doğruluklu modelin yerini tamamen almak zorunda değildir. Asıl değer, onu daha büyük mühendislik akışlarında kullanılabilir hale getirmesidir. ROM sayesinde simülasyon süreleri ciddi ölçüde düşürülebilir, daha fazla senaryo taranabilir ve fizik tabanlı modeller gerçek zamana yakın test ortamlarına taşınabilir.

ROM Yaklaşımı ve MATLAB&Simulink Ekosistemi

Reduced Order Modeling tek bir yöntem değildir. Farklı problem tipleri için farklı yaklaşımlar bulunur. Genel çerçevede ROM’u üç grupta düşünebiliriz: AI-based data-driven, linearization tabanlı ve model-based yöntemler.

Bu blog yazısının odağı özellikle AI-based data-driven ROM tarafıdır. Çünkü burada fiziksel sistemi her adımda tekrar çözmek yerine, yüksek doğruluklu modelden veya sistemden elde edilen giriş-çıkış verileriyle daha hafif bir model eğitilir. Başka bir deyişle, pahalı çözücüyü sürekli çalıştırmak yerine onun baskın davranışını öğrenen bir vekil model oluşturulur.

Bu yaklaşım özellikle elinizde güvenilir bir high-fidelity model varsa, o modeli farklı çalışma koşullarında koşturup veri üretebiliyorsanız ve hız kazanımı fiziksel ayrıntının tamamından daha kritik hale geldiyse oldukça güçlü bir seçenektir.

MathWorks ekosisteminin güçlü olduğu noktalardan birkaçı, veri hazırlama, model eğitimi, doğrulama, entegrasyon ve deploy adımlarını aynı ortamda bağlayabilmesidir. Bu açıdan ROM, tek başına duran bir kavram değil; daha geniş bir Model-Based Design ve AI mühendisliği hattının parçasıdır.

AI-based ROM akışında öne çıkan araçlar arasında Simulink, System Identification Toolbox, Statistics and Machine Learning Toolbox ve Deep Learning Toolbox yer alır. Bu akışta ROM geliştirme tarafında ise Reduced Order Modeler app kullanılır; uygulamanın kurulumu Reduced Order Modeler for MATLAB Support Package üzerinden yapılır. Doğrulama tarafında Deep Learning Toolbox Verification Library, deployment tarafında ise Code Generation ve hedef platform entegrasyonları önemli rol oynar.

Bu bütünlük sayesinde şu zincir kurulabilir: yüksek doğruluklu modelden veri üretmek veya mevcut veriyi içe almak, giriş ve çıkış sinyallerini seçmek, farklı ROM adaylarını eğitmek, modelleri karşılaştırmak, seçilen modeli Simulink’e entegre etmek ve sonrasında sistem seviyesinde doğrulayıp geliştirmek.

Örnek Problem: Jet Engine Turbine Blade Modelinin Hızlandırılması

ROM kavramı, somut bir kullanım senaryosu olmadan soyut kalabilir. Bu nedenle jet engine turbine blade örneği, yaklaşımı göstermek için oldukça açıklayıcıdır. Bu örnekte yüksek doğruluklu bir türbin kanadı modeli, yapay zeka tabanlı bir reduced-order model ile değiştirilir.

Sistemde girişler olarak ortam sıcaklığı, ortam basıncı ve soğutma sıcaklığı kullanılır. Çıktı ise maksimum yer değiştirmedir. Orijinal modelde türbin kanadının deformasyonu önce ısıl dağılımın hesaplanması, ardından yapısal denklemlerin çözülmesi ile elde edilir. Bu fiziksel olarak anlamlıdır; ancak simülasyon süresi yüksektir.

AI-based ROM burada aynı girişlerden benzer çıkışı çok daha hızlı tahmin etmeyi amaçlar. Böylece yüksek doğruluklu modelin fiziksel bilgisinden yararlanılırken, hesaplama yükü ciddi ölçüde azaltılır. Bu tür senaryolarda ROM’un değeri, yalnızca yaklaşık sonuç üretmesi değil; bu sonucu mühendislik kararlarını destekleyecek hızda üretebilmesidir.

Veri Hazırlama ve Model Seçimi

Veri Hazırlama

AI tabanlı bir reduced-order modelin başarısı büyük ölçüde veriye bağlıdır. Bu nedenle ROM sürecinin en kritik aşamalarından biri, eğitim verisinin nasıl üretildiğidir. MathWorks tarafında bu iş için iki temel yol vardır: yüksek doğruluklu modelden sentetik veri üretmek veya daha önce toplanmış veriyi uygulamaya almak.

Burada Design of Experiments yaklaşımı kritik hale gelir. Çünkü reduced-order modelin öğreneceği dünya, aslında deney tasarımı ile tanımlanır. Hangi giriş aralıklarının gezileceği, sinyallerin ne kadar çeşitleneceği ve hangi çalışma bölgesinin kapsanacağı; modelin genelleme kabiliyetini doğrudan etkiler.

Bu noktada simulation inputs ile ROM inputs ayrımını doğru kurmak da önemlidir. Sistemi dışarıdan sürmek için kullandığınız üst seviye girdiler ile, ROM’un yerine geçeceği pahalı alt sistem bloğunun gerçek girdileri aynı olmak zorunda değildir. Bu ayrım doğru tanımlanırsa veri, daha fiziksel anlamlı ve daha hedefe yönelik hale gelir.

Hangi Tür Data-Driven ROM Kullanılabilir?

Data-driven ROM yaklaşımı genel olarak iki grupta düşünülebilir: time-independent modeller ve dynamic modeller. Time-independent modellerde çıktı yalnızca mevcut girişe bağlı kabul edilir. Başka bir deyişle sistemin hafızası yoktur. Bu tarafta look-up table, surface fitting veya basit MLP yapıları kullanılabilir.

Dynamic modellerde ise sistemin hafızası vardır. Çıktı yalnızca mevcut girdiye değil, geçmiş girdilere ve zaman içindeki evrime de bağlıdır. Isıl gecikmeler, atalet etkileri veya iç durum dinamikleri söz konusuysa bu tür modeller daha uygun hale gelir.

Bu yazıda öne çıkan üç dinamik model ailesi; LSTM, Nonlinear ARX ve Neural State Space yaklaşımıdır.

LSTM ile AI-Based ROM

LSTM, zaman bağımlılıklarını öğrenmek için güçlü bir yapıdır. Sequence input katmanı veriyi sekans olarak modele taşır; LSTM katmanı ise geçmiş bilgiyi state üzerinden taşır. Böylece model, önceki adımları unutmadan zamansal bağımlılıkları öğrenebilir.

Bu yapı özellikle geçmiş girdilerin ve önceki davranışların bugünkü çıktıyı etkilediği sistemlerde anlamlıdır. Bununla birlikte yorumlanabilirlik bazı klasik yöntemlere göre daha sınırlı olabilir ve bazı deployment senaryolarında inference maliyeti farklı modellere göre daha yüksek kalabilir.

Neural State Space ile Fiziksel Davranışa Daha Yakın Bir Öğrenme

Neural State Space yaklaşımında sistem, state denklemleri üzerinden öğrenilir. Bir ağ state’in zaman içinde nasıl evrildiğini; diğer ağ ise bu state’ten çıktının nasıl üretildiğini temsil eder. Ardından bir integratör yardımıyla sistem zaman içinde ilerletilir.

Bu yaklaşım özellikle iç dinamikleri belirgin olan sistemlerde güçlüdür. State-space yapısı sayesinde salt black-box bir modele kıyasla, bazı mühendislik ekipleri için daha doğal bir soyutlama sunabilir. NumberInputLags, NumberOutputLags, NumberLayers, NumberUnits ve SampleRate gibi hiperparametreler de modelin kapasitesi ile zaman çözünürlüğünü belirler.

NLARX: Pratik ve Güçlü Bir Alternatif

Nonlinear ARX modeli, sistemi açık state değişkenleriyle değil; mevcut ve geçmiş girişler ile geçmiş çıkışların oluşturduğu regresörler üzerinden temsil eder. Yani model her zaman adımında geçmiş bilgileri kullanarak yeni çıktıyı üretir.

Bu yaklaşım çoğu mühendislik problemi için güzel bir başlangıç noktası olabilir. Çünkü kurulumu görece pratiktir, dinamik davranışı öğrenebilir ve tamamen derin ağ tabanlı yapılara göre bazı durumlarda daha hızlı eğitim sunabilir.

Model Seçiminde Doğruluk Yeterli mi?

ROM tarafında sık yapılan hatalardan biri yalnızca RMSE gibi bir metriğe odaklanmaktır. Oysa sistem seviyesinde kullanılacak bir model seçerken tek soru, en düşük hatayı kimin verdiği değildir.

Gerçek mühendislik kararında eğitim hızı, inference hızı, model boyutu, yorumlanabilirlik, Simulink entegrasyon kolaylığı ve hedef platform uygunluğu gibi eksenler de en az doğruluk kadar önemlidir. Bu nedenle en iyi model, mutlak olarak değil; bağlama göre belirlenir.

Kontrol tasarımı için seçilecek model ile deployment için seçilecek model her zaman aynı olmayabilir. Asıl mesele, ilgili kullanım senaryosunda doğru hız-doğruluk dengesini kurmaktır.

Model Eğitimi ve Optimizasyon

Dynamic reduced-order model adayları oluşturulduktan sonra bir sonraki kritik adım, bu modellerin yalnızca eğitilmesi değil, aynı zamanda sistematik biçimde iyileştirilmesidir. Bu noktada Experiment Manager app, farklı hiperparametre kombinasyonlarını kontrollü şekilde deneyip sonuçlarını karşılaştırmak için güçlü bir çerçeve sunar.

Örneğin LSTM, NLARX veya Neural State-Space gibi dinamik modeller için katman sayısı, birim sayısı, input-output lag değerleri, öğrenme oranı, mini-batch boyutu ya da eğitim seçenekleri gibi parametreler belirli aralıklarda taranabilir. Experiment Manager, bu kombinasyonları tek tek çalıştırarak her denemenin sonuçlarını kaydeder; böylece hangi ayarların doğruluk, eğitim süresi veya genel performans açısından daha başarılı olduğu sistematik biçimde görülebilir.

Ayrıca uygulama; klasik parameter sweep yaklaşımına ek olarak rastgele örnekleme ve Bayesian optimization stratejilerini de destekler. Hesaplama maliyeti yüksek olduğunda, Parallel Computing Toolbox ile bu süreç daha da hızlandırılabilir. Experiment Manager birden fazla denemeyi aynı anda paralel çalıştırabilir; özellikle dynamic ROM eğitimlerinde, model sayısı ve deneme alanı büyüdükçe bu paralel yürütme desteği ciddi zaman kazancı sağlar.

Simulink Entegrasyonu ve Karşılaştırma

ROM’un gerçek değeri eğitimden sonra başlar. Eğitilen modelin Simulink’e alınması ve daha büyük sistem modeli içinde kullanılabilmesi gerekir. Bu aşamada amaç yalnızca tekil tahmin başarısını görmek değil; modelin gerçek sistem bağlamındaki davranışını değerlendirmektir.

Standalone testte iyi görünen bir model, kapalı çevrim veya daha büyük bir sistem içinde beklenmedik davranışlar gösterebilir. Bu nedenle Simulink entegrasyonu, reduced-order modelin gerçekten mühendislik akışına girdiği adımdır.

High-Fidelity Model ile ROM Nasıl Karşılaştırılır?

Bir reduced-order modelin başarısı iki eksende değerlendirilmelidir: doğruluk ve hız. Yalnızca tahmin eğrilerinin benzemesi yeterli değildir; bu benzerliğin anlamlı bir simülasyon hız kazanımı ile gelmesi gerekir.

Bu nedenle profiling oldukça önemlidir. Simulink Profiler gibi araçlar, yüksek doğruluklu model ile reduced-order model arasındaki zaman farkını görünür hale getirir. ROM’un değeri de burada netleşir: yaklaşık olarak aynı davranışı çok daha kısa sürede üretmek. Neural state-space modelinin 16 kat daha hızlı olduğunu gözlemleyebiliyoruz.

Verification Neden Gerekli?

AI tabanlı reduced-order model ne kadar hızlı ve doğru görünürse görünsün, özellikle kritik sistemlerde doğrulama olmadan güvenle kullanılamaz. Küçük giriş perturbasyonlarında model kararlı mı, tahmin bandı ne kadar değişiyor ve model dağılım dışı verilerle karşılaştığında nasıl davranıyor gibi sorular önemlidir.

Deep Learning Toolbox Verification Library bu noktada değerli bir katman sunar. Robustness analizi, output bounds değerlendirmesi ve runtime monitoring gibi yaklaşımlar; reduced-order modelin saha kullanımında daha güvenli biçimde değerlendirilmesine yardımcı olur.

Deployment

MathWorks ekosisteminin güçlü olduğu diğer alan, eğitilen AI modellerinin deploy edilebilir hale getirilmesidir. Library-free C code generation ve farklı hedef platform seçenekleri, reduced-order modelin masaüstü prototipi olmaktan çıkıp gerçek zamanlı test veya gömülü çalıştırma senaryolarına taşınmasını mümkün kılar.

Özellikle HIL akışlarında yüksek doğruluklu plant modelin tamamını gerçek zamanda çalıştırmak çoğu zaman mümkün olmaz. Reduced-order model burada kritik bir çözüm sunar. Eğitilen model hedef platforma aktarılabilir, parametreler ayarlanabilir ve sistem seviyesi entegrasyon gerçek zamanlı test ortamında sürdürülebilir

Kullanıcı Hikayeleri

Endüstriyel kullanım hikâyeleri, ROM’un yalnızca akademik veya demo amaçlı bir konu olmadığını gösterir. Örneğin otomotiv ve güç sistemleri tarafında surrogate modeller ile ciddi hız kazanımları elde edilmiş, performans tahmin akışları daha uygulanabilir hale getirilmiştir. Subaru ve Cummins gibi firmaların çalışamlarına MathWorks sayfasından ulaşabilirsiniz.

Bu tür örnekler, reduced-order modeling yaklaşımının yalnızca teori seviyesinde kalmadığını; mühendislik ekiplerinin günlük geliştirme akışlarında da gerçek karşılığı olduğunu gösterir.

Sonuç

Reduced Order Modeling, yüksek doğruluklu modelleri terk etmek için değil; onları daha geniş mühendislik akışlarında kullanılabilir hale getirmek için vardır. Özellikle AI tabanlı data-driven ROM yaklaşımları, high-fidelity modellerden elde edilen bilgiyi koruyup hesaplama maliyetini ciddi ölçüde azaltabilir.

MATLAB ve Simulink ekosistemi ise bu süreci veri üretiminden model eğitimine, sistem entegrasyonundan verification ve code generation’a kadar tek bir mühendislik hattı içinde ele almayı mümkün kılar.

Bugün birçok ekip için asıl soru artık yüksek doğruluklu modelimizin olup olmadığı değil; bu modeli sistem seviyesinde etkili biçimde nasıl kullanabileceğimizdir. Reduced Order Modeling, bu sorunun en güçlü cevaplarından biridir.

MATLAB Copilot: MATLAB Kullanıcıları İçin Yapay Zekâ Destekli Yeni Dönem

MATLAB Kullanıcıları için Yapay Zeka Destekli Geliştirme Deneyimi

Yapay zekâ destekli araçların yükselişiyle birlikte mühendisler, araştırmacılar ve öğrenciler için kod geliştirme süreci daha hızlı, daha verimli ve daha sezgisel hâle geliyor. MATLAB’in yeni Copilot entegrasyonu, kullanıcıların doğal dil komutlarıyla kod yazmasını, kodlarını iyileştirmesini ve çalışma akışlarını otomatikleştirmesini sağlayan güçlü bir yardımcı olarak öne çıkıyor.

Bu yazıda MATLAB Copilot’ın sunduğu avantajlar, en iyi kullanım ipuçları, MATLAB ekosistemiyle entegrasyon yetenekleri ve ideal bir Copilot çalışma akışı gibi başlıkları detaylıca ele alıyoruz.

MATLAB Copilot Nedir?

MATLAB Copilot, doğal dil komutlarını kullanarak MATLAB komutları, fonksiyonları ve script’leri hızlıca üretmeye yardımcı olan bir yapay zekâ destekli asistandır. Hem yeni başlayanlar hem de ileri seviye kullanıcılar için:

  • Kod oluşturma,
  • Hata ayıklama,
  • Optimizasyon önerileri,
  • Veri işleme ve görselleştirme adımlarında otomasyon sağlar.

MATLAB Copilot’u teknikler öğrenmek, fikir geliştirmek ve verimliliği artırmak için kullanabilirsiniz.

MATLAB Copilot’ın Sağladığı Avantajlar

MATLAB Copilot, MATLAB için optimize edilmiştir.

  • Kod geliştirme süresini hızlandırabilir.
  • Daha temiz, yeniden kullanılabilir kod üretmeye yardımcı olur.
  • Yeni kullanıcılar için öğrenme sürecini kolaylaştırır.
  • Deneyimli kullanıcılar için tekrar eden işlemleri otomatikleştirir.

MATLAB Copilot ve ChatGPT Arasındaki Temel Farklar

Yapay zekâ destekli araçlar kod geliştirmeyi hızlandırsa da, her aracın odaklandığı alan ve çalışma şekli farklıdır. MATLAB Copilot ile ChatGPT arasında öne çıkan farklar şunlardır:

Alan Uzmanlığı

  • MATLAB Copilot: MATLAB diline, fonksiyonlarına, toolbox yapılarına ve Simulink modellerine özel optimize edilmiştir.
  • ChatGPT: Çok geniş bir konu yelpazesinde genel amaçlı bir yardımcıdır.

Çalışma Ortamı Entegrasyonu

  • MATLAB Copilot: Doğrudan MATLAB Editor, Workspace, Live Script ile entegre çalışır. Kodun bağlamını, değişkenleri ve aktif projeyi algılar.
  • ChatGPT: Kod editöründen bağımsızdır; MATLAB kodu üretebilir ama çalışma ortamını gerçek zamanlı olarak göremez.

Bağlama Duyarlılık (Context Awareness)

  • MATLAB Copilot: Workspace değişkenlerini, açık script’leri, model bileşenlerini tanır. “Elimdeki data değişkenini filtrele” dediğinizde bağlamı bilir.
  • ChatGPT: Kullanıcının verdiği bilgilere dayanır; çalışma dosyalarına veya modellere erişimi yoktur.

MATLAB Ekosistemi İçin Optimize Edilmiş Çözümler

  • MATLAB Copilot: Toolbox fonksiyonlarını doğru ve güncel sözdizimiyle kullanır. Örneğin Control System Toolbox veya Image Processing Toolbox komutlarını bağlama göre önerebilir.
  • ChatGPT: Toolbox fonksiyonlarını bilir ancak versiyon farklılıklarını veya kullanıcı workspace’ini bilemez.

Kod Testi ve Anında Geri Bildirim

  • MATLAB Copilot: Kodun çalıştığı ortama entegre olduğundan anlık olarak değişiklik yapma ve test etme döngüsü daha hızlıdır.
  • ChatGPT: Kod üretir ama MATLAB içinde otomatik test veya bağlam takibi yapmaz.

Güvenlik ve Kurumsal Uyumluluk

  • MATLAB Copilot: MATLAB ortamına özgü güvenlik politikalarına ve lisanslı toolbox ekosistemine entegredir.
  • ChatGPT: Genel amaçlı bir modeldir; belirli bir yazılım ekosistemine özel güvenlik bağlamı yoktur.

MATLAB Copilot İngilizce Dışındaki Dilleri Kullanabilir Mi?

MATLAB Copilot, istenilen dile göre uygun gördüğü dilde yanıt verir. Sohbet gibi bazı özelliklerde soruyu hangi dilde sorduysanız genellikle o dilde yanıt verir. Diğer durumlarda varsayılan dil olan İngilizceye dönebilir. Şu anda MATLAB Copilot’un hangi dili kullanacağını manuel olarak ayarlamak mümkün değildir.

MATLAB Copilot Kullanım İpuçları

✓ İsteğinizi net bir şekilde tanımlayın.

✓  Optimize edilmemiş kod bloklarını revize ettirin.

✓ Uzun scriptleri parçalara ayırmasını isteyin.

✓ Otomasyon için prompt şablonları oluşturun.

Sonuç

MATLAB Copilot, mühendislik, veri analizi ve modelleme süreçlerinde güçlü bir üretkenlik aracı olarak öne çıkıyor. Doğru ipuçlarıyla kullanıldığında hem kod kalitesini artırıyor hem de geliştirme sürecini büyük ölçüde hızlandırıyor.
İster öğrenci olun, ister Ar-Ge mühendisi: Copilot, MATLAB projelerinizi bir üst seviyeye taşımanız için mükemmel bir yardımcı.

MATLAB Copilot Ürün Sayfamıza Göz Atın

Keşfet

Türkiye’nin 5G Dönüşümünde Yeni Bir Paradigma

Türkiye’de gerçekleştirilen 5G spektrum ihalesi, iletişim teknolojilerinde yeni bir dönemin resmi başlangıcı olarak görülmekte ve ülkenin dijital dönüşüm vizyonu açısından kritik bir eşik teşkil etmektedir. Bu dönüşüm yalnızca daha yüksek mobil veri hızları anlamına gelmemektedir; aksine, iletişim altyapısının sosyal, ekonomik ve teknolojik katmanlarının yeniden tanımlandığı bütünsel bir değişimi ifade eder. Şehirlerin dijitalizasyonu, endüstriyel otomasyonun gelişimi, savunma uygulamalarındaki iletişim–algılama birleşimi (ISAC), sağlık teknolojilerindeki yenilikler ve yapay zekâ tabanlı gerçek zamanlı sistemler gibi pek çok alan, 5G’nin sunduğu düşük gecikme, yüksek kapasite ve güvenilirlik temelinde şekillenmektedir.

Bu dönüşümün başarısı, yalnızca sahada kurulan baz istasyonlarına ya da operatörlerin sunduğu hizmetlere bağlı değildir. 5G’nin fiziksel katman yapısı, modülasyon teknikleri, anten dizileri, çoklu erişim yapıları, kanal modelleri ve protokol katmanları son derece karmaşık matematiksel süreçlere dayanır. Dolayısıyla bu teknolojinin hayata geçmeden önce akademik ve mühendislik düzeyinde kapsamlı biçimde modellenmesi, simüle edilmesi, test edilmesi ve donanımsal olarak doğrulanması zorunluluk haline gelmiştir. İşte bu noktada MATLAB’in 5G Toolbox, HDL Coder, SoC Blockset ve ilgili FPGA destek paketleri kritik rol oynar; simülasyondan prototiplemeye, prototiplemeden gerçek zamanlı donanım testine uzanan uçtan uca bir mühendislik hattı sunar.

Türkiye’de 5G’nin Sosyo-Teknik Arka Planı

Türkiye’nin 5G’ye geçiş kararı, yalnızca bilgi iletişim sektöründe değil, toplumun hemen her alanında etkili olacak bir değişim anlamına gelmektedir. Akıllı şehirlerden sağlığa, endüstriyel üretimden savunma teknolojilerine kadar geniş bir yelpazede kritik yeniliklerin önünü açan bütünsel bir ekosistemi beraberinde getirmektedir.

  • Akıllı şehir altyapılarının olgunlaşması, trafik yönetiminden enerji dağıtımına, güvenlik kameralarının gerçek zamanlı analizinden afet yönetim sistemlerine kadar pek çok kritik uygulamanın 5G’nin sunduğu yüksek bant genişliği ve düşük gecikme olmadan etkin şekilde işleyemeyeceğini gösteriyor.
  • Endüstri 4.0’ın gerçek anlamda uygulanması, 5G’nin deterministik zamanlama özelliklerinin otomasyon robotları, AGV/AMR sistemleri ve fabrika içi özel ağlarda kritik görev üstlenmesi sayesinde Türkiye’nin üretim sektörü için küresel rekabet gücü açısından bir zorunluluk haline geliyor.
  • Savunma sanayiinde iletişim ve algılamanın birleşimi, dünyada 6G hazırlıklarında en çok konuşulan kavramlardan biri olan Integrated Sensing and Communication (ISAC)’ın Türkiye’nin radar, SİHA ve elektronik harp kabiliyetleriyle birleştiğinde çok daha güçlü sistemlerin ortaya çıkmasını sağlayacağı anlamına geliyor.

Akademik ve Endüstriyel Tasarımın Temel Taşı: MATLAB 5G Toolbox

5G Toolbox, 3GPP NR (Yeni Radyo) fiziksel katmanının matematiksel olarak modellenmesi için son derece kapsamlı bir ortamdır. Akademik çalışmalarda teorik doğruluğun, endüstride ise standarda uygunluğun temel şart olduğu düşünülürse, bu toolbox hem simülasyon doğruluğu hem de esneklik açısından kritik bir rol oynar.

5G Toolbox; OFDM tabanlı dalga şekillerinin üretiminden LDPC/Polar kodlamaya, masif MIMO beamforming mimarilerinden FR1/FR2 kanal modellerine kadar tüm fiziksel katman bileşenlerini modelleyebilir. Üstelik PHY katmanının uçtan uca işleyişi, yani kodlamadan modülasyona, kanaldan eşitleyiciye ve hata oranı analizine kadar tüm aşamalar tek platformda bir araya gelir. Bu durum, tasarım sürecinin disiplinli ve tutarlı bir biçimde ilerlemesini sağlar.

Örneğin, Türkiye’de bir Ar-Ge ekibi yerli 5G modem ya da baz istasyonu tasarlamak istediğinde, ilk aşamada MATLAB 5G Toolbox içinde waveform üretir, kanal etkilerini test eder, beamforming tekniklerini dener ve elde edilen BER/BLER (Bit Error Rate/Block Error Rate) sonuçlarını analiz eder. Bu aşamada alınan sonuçlar, daha sonra FPGA üzerinde gerçekleştirilecek donanım uygulamalarının temel parametrelerini belirler.

Ray-Tracing Channel Görüntüsü

Gerçek Zamanlı 5G Sistemlerinin Vazgeçilmez Bileşeni: FPGA Ekosistemi

5G’nin gerektirdiği performans değerleri — örneğin 100 MHz üzeri bant genişlikleri, masif paralel anten dizileri, yüksek boyutlu FFT işlemleri — klasik işlemcilerin kapasitesini aşan yapıda olduğundan donanım hızlandırıcılar şarttır. FPGA’ler, paralel işlem yapısı ve deterministik çalışma prensibi sayesinde 5G fiziksel katmanının büyük kısmını gerçek zamanlı olarak çalıştırabilir.

FPGA’ler özellikle:

  • OFDM modülasyon/demodülasyon zinciri
  • Beamforming matris işlemleri
  • Kanal kodlama ve kod çözme
  • Zaman ve frekans senkronizasyon
  • Yüksek hızlı I/Q işleme hatları

gibi yoğun hesaplama gerektiren bloklarda kritik rol oynar.

Türkiye’de özellikle savunma ve telekom alanındaki firmalar Xilinx Zynq UltraScale+, RFSoC ve Intel Stratix gibi FPGA platformlarını yoğun biçimde kullanmaktadır. Bu nedenle MATLAB ile FPGA arasında kusursuz bir geliştirme akışı sağlayan araçların önemi büyüktür.

Simülasyondan Donanıma: HDL Coder ve SoC Blockset’in Birleştirici Rolü

5G Toolbox içinde doğrulanan bir algoritmanın FPGA üzerinde çalıştırılabilmesi için HDL Coder devreye girer. Bu araç MATLAB & Simulink modellerini doğrudan sentezlenebilir HDL koduna dönüştürür. Böylece tasarımcıların karmaşık algoritmaları sıfırdan HDL olarak yazmasına gerek kalmaz; kaynak kullanımı, zamanlama analizi ve donanım optimizasyonları otomatik biçimde oluşturulur.

Bu süreç:

  1. MATLAB’da tasarım
  2. Simülasyon ve doğrulama
  3. HDL Coder ile Verilog/VHDL üretimi
  4. FPGA üzerinde test (FIL-FPGA in the Loop)
  5. Geri bildirim ile tasarım iyileştirme

şeklinde döngüsel bir mimari oluşturur.

SoC Blockset ise FPGA + ARM gibi heterojen mimarilerin birlikte nasıl çalışacağını akademik ve endüstriyel düzeyde simüle eder. 5G sistemlerinde kontrol katmanı (MAC/RLC) genellikle ARM üzerinde çalışırken, fiziksel katman (PHY) FPGA üzerinde yürütülür. Bu birleşik yapı, 5G’nin gerçek zamanlı doğasına en uygun mimaridir.

RFSoC ile Gerçek Zamanlı Test Ortamlarının Oluşturulması

Simülasyon ve FPGA doğrulaması önemli adımlardır; fakat 5G’nin gerçek kablosuz ortamda nasıl performans göstereceğini anlamak için RF donanımı gereklidir. RFSoC platformları, entegre ADC/DAC birimleri sayesinde MATLAB–FPGA–RF akışını tamamlayan ideal bir prototipleme ortamı sunar.

Bu tür platformlar, Türkiye’de özellikle:

  • 5G modem prototipleri
  • Pasif bistatik radar çalışmaları
  • mmWave iletişim araştırmaları
  • ISAC projeleri
  • Endüstriyel kablosuz otomasyon sistemleri için sıkça kullanılmaktadır. Çünkü RFSoC ile gerçek antenler üzerinden — MATLAB tarafından üretilen dalga şekilleri kullanılarak —laboratuvar ortamında sahaya yakın testler yapılabilir.

Verify System RF Performance with Streaming Data Akış Görüntüsü

Sonuç

Türkiye’nin 5G’ye geçiş süreci yalnızca bir teknoloji adaptasyonu değil, aynı zamanda ülkenin dijital egemenliği, rekabet gücü ve yenilik kapasitesi açısından stratejik bir adımdır. Bu adımın sağlıklı şekilde ilerleyebilmesi, mühendislik tasarım süreçlerinin simülasyondan donanıma kadar tüm aşamalarda bilimsel doğrulukla yürütülmesine bağlıdır.

MATLAB 5G Toolbox, HDL Coder, SoC Blockset ve FPGA ekosisteminin beraber sunduğu uçtan uca geliştirme zinciri, Türkiye’nin 5G altyapısını:

  • daha güvenilir,
  • daha hızlı geliştirilebilir,
  • daha düşük maliyetli,
  • daha yüksek doğruluklu,
  • daha rekabetçi

hale getirecektir.

Bu bütünleşik yaklaşım, ülkenin yalnızca 5G teknolojisini kullanan değil, aynı zamanda bu teknolojiyi geliştiren, üreten ve ihraç eden bir aktör olmasını mümkün kılar. Özellikle 6G ve ISAC gibi bir sonraki nesil teknolojilere giden yolda Türkiye için bu mühendislik altyapısı vazgeçilmezdir.

MATLAB ile Kestirimci Bakım: İşletme Maliyetlerini Düşürün

Endüstriyel ekipmanların plansız arızalar sebebi ile duraklaması ciddi üretim kayıplarına yol açmaktadır. Kestirimci bakım (predictive maintenance), sensör verileri ve matematiksel modeller kullanarak bir makinenin ne zaman arıza vereceğini öngörmeye çalışır. Doğru uygulandığında bu yaklaşım, gereksiz bakım işlemlerini azaltır, üretim verimliliğini artırır ve işletme maliyetlerini düşürür. Fiziksel modeller ve makine öğrenimi algoritmaları ile birlikte bu süreç, Predictive Maintenance Toolbox ile hızlandırılabilir. Toolbox, motorlar, dişli kutuları, rulmanlar ve piller gibi uygulamalara yönelik durum izleme ve tahmine dayalı bakım algoritmalarını tasarlamaya yardımcı olur.

Bu yazıda, kestirimci bakım için genel iş akışını özetleyecek ve MATLAB ekosistemindeki toolboxları kullanarak uygulanabilir bir senaryo sunacağız. Senaryoda bir pompanın sensör verileri ile oluşturulan dijital ikizden (digital twin) ve rulman arızası örneğinden yararlanacağız. Anlatılan adımlar, gerçek MathWorks örneklerine dayanmaktadır. Aynı yaklaşımları projelerinizde uygulayabilirsiniz.

Predictive Maintenance Toolbox ile Neler Yapabilirsiniz?

MathWorks’ün Predictive Maintenance Toolbox’ı, durum izleme ve kestirimci bakım algoritmalarını tasarlamak için kapsamlı yetenekler sağlar. Toolbox;

  • Koşul göstergeleri ve anomali tespiti tasarlamaya yardımcı olur. Diğer pek çok uygulama gibi rulman, motor ve batarya izleme için özel örnekler sunar. Teşhissel özellik tasarımı (Diagnostic Feature Designer) uygulaması ile zaman, frekans ve zaman-frekans alanlarındaki özellikleri interaktif olarak çıkartıp sıralamanızı sağlar. Kullanıcılar özellikleri görselleştirebilir, nominal ve arızalı veriler arasında en ayırt edici olanları belirleyebilir ve bu özellikleri daha sonra makine öğrenmesi modellerine aktarabilir.
  • Arıza tespiti ve teşhisi için istatistiksel, makine öğrenmesi ve derin öğrenme modellerini eğitmeyi destekler. Koşul göstergeleri kullanılarak sağlıklı ve arızalı durumları ayırt eden karar modelleri geliştirilebilir. Derin öğrenme kullanarak rulman arızalarının teşhisi gibi sorunlar için scalogram (süreç içerisinde sinyalin sürekli dalgacık dönüşümü sonucu oluşan zaman‑frekans temsili) üzerinden transfer öğrenimi yapılabilir.
  • Kalan kullanım ömrü (RUL) tahmini için özel modeller içerir. RUL, bir sistemin tamir ya da değişim gerektirmeden önceki beklenen kullanım süresidir. Toolbox hem trend‑tabanlı degradasyon modelleri (lineer veya üssel) hem de benzerlik tabanlı ve gözetimli hayatta kalma modelleri gibi yaklaşımları barındırır. Bu modeller, zaman içinde değişen koşul göstergelerinin istatistiksel özelliklerini kullanarak bir test makinesinin kalan ömrünü olasılıksal olarak tahmin eder.
  • Veri yönetimi, simülasyon ve dağıtım olanakları sunar. Ölçülen verileri yerel dosyalardan veya bulut depolarından içe aktarabilir, Simulink/Simscape modelleri ile arıza verisi üretebilir ve algoritmaları C/C++ koduna çevirerek uç cihazlara dağıtabilirsiniz.

Predictive Maintenance Toolbox İş Akışı

Aşağıdaki adımlar Predictive Maintenance Toolbox’ın sunduğu yetenekler kullanılarak gerçekleştirilen bir kestirimci bakım iş akışını özetler.

Veri Toplama ve Organize Etme

Bakım algoritmalarının temelini sensör verisi oluşturur. Vibrasyon, sıcaklık, basınç, akım veya voltaj sensörlerinden elde edilen ölçümler; yerel dosyalarda, veri tabanlarında veya bulut ortamlarında toplanır. Toolbox, bu verileri ensemble formatında organize etmeyi kolaylaştırır ve Simulink/Simscape modelleri ile simülasyon yoluyla arıza verisi üretebilmenizi sağlar. Böylece gerçek arıza verisi az olduğunda dijital ikiz kullanarak eğitim verisi oluşturabilirsiniz.

Özellik Tasarımı ve Sıralama

Bir makinenin sağlıklı veya arızalı olduğunu belirleyen koşul göstergeleri tanımlanmalıdır. Diagnostic Feature Designer uygulaması; zaman alanı istatistikleri (rms, pik faktörü vb.), frekans alanı ölçümleri (spektral kurtosis, zarf spektrumu), zaman‑frekans temsilleri ve döner makine metriklerini interaktif olarak üretir. Bu özellikleri görselleştirip hangi göstergelerin nominal ve arızalı verileri en iyi ayırdığını görebilir ve denetimli/denetimsiz ya da prognostik sıralama yöntemleri ile en etkili özellikleri seçebilirsiniz.

Arıza Tespiti ve Teşhisi

Seçilen koşul göstergeleri, makine öğrenmesi modellerini eğitmek için kullanılır. Toolbox, destek vektör makineleri (SVM), karışık ağaçlar, k‑en yakın komşu (kNN), rastgele ormanlar ve derin sinir ağları gibi pek çok algoritma sağlar. Örneğin derin öğrenme ile rulman arızalarının teşhisi için titreşim sinyalleri scalogram’lara dönüştürülerek transfer öğrenimi uygulanabilir; bu yöntem küçük veri kümelerinde bile yüksek doğruluk sunar. Arıza tespiti işlemi iteratiftir; farklı özellik ve model kombinasyonları denenerek en iyi sonuç veren yapı seçilir.

Kalan Ömür Tahmini (RUL)

Arıza tespitinden sonra, makinenin ne kadar daha çalışabileceğini tahmin etmek gerekir. RUL, koşul göstergelerinin zaman içindeki eğilimine dayalı olarak istatistiksel bir dağılım şeklinde hesaplanır. Predictive Maintenance Toolbox; üssel veya lineer degradasyon modelleri, benzerlik tabanlı modeller ve hayatta kalma modelleri gibi çeşitli yöntemleri destekler. Benzerlik tabanlı bir RUL tahmininde, run‑to‑failure verileri içeren bir ensemble kümesi hazırlanır, trendlenebilir özellikler seçilir, sensör birleşimi ile bir sağlık göstergesi oluşturulur ve eğitim verisi ile benzerlik ölçümleri kullanılarak tahminci eğitilir.

Uygulama ve Dağıtım

Algoritmalar eğitildikten sonra, kod üretimi ile uç cihazlara veya bulut sistemlerine dağıtılabilir. Simscape tabanlı dijital ikizler, geliştirilen algoritmanın farklı arıza senaryolarında nasıl çalıştığını test etmek için kullanılır. MATLAB Coder ve Simulink Coder, modelleri C/C++ koduna çevirerek PLC’lere, mikrodenetleyicilere veya IoT ağ geçitlerine gömülebilir.

Pompa İstasyonunda Kestirimci Bakım

Bir kimya tesisinde dört kademeli santrifüj pompalar prosesi beslemektedir. Geçmişte pompa arızaları, üretimi durdurmuş ve yüksek maliyetlere yol açmıştır. Bu nedenle, bir kestirimci bakım sistemi kurarak pompaların durumunu izlemek ve arızaları önceden tespit etmek istiyoruz. Senaryoda Predictive Maintenance Toolbox, Simscape ve çeşitli MATLAB toolbox’ları birlikte kullanılacak.

Dijital İkiz ile Eğitim Verisi Oluşturma

Gerçek arıza verisi sınırlı olduğundan, Simscape tabanlı bir triplex pompa modeli kullanıyoruz. MathWorks’ün File Exchange’te sunduğu Predictive Maintenance in a Hydraulic Pump örneği, Simscape ile modellenen bir triplex pompa ve bu pompanın çıkış basıncını izleyerek hangi bileşenin arızalandığını tespit eden bir algoritma içerir. Model;

  • Sızdırmazlık kaçakları, tıkanmış girişler, rulman aşınması ve kırık motor sargıları gibi bozulmaları ayrı ayrı simüle edebilir.
  • Simülasyon sonuçlarını tekrar kullanarak eğitim süresini kısaltmaya yönelik kod örnekleri sağlar.
  • Gerçek sensör verileri ile birleştirilebilir; böylece gerçek dünyaya uygun bir eğitim seti elde edilir.

Simulink modelini kullanarak her arıza durumunda pompanın çıkış basıncı, vibrasyon ve akım sinyalleri oluşturulur. Bu veriler ensemble formatında düzenlenir ve her koşul için etiketlenir. Daha sonra veriler Diagnostic Feature Designer uygulamasına aktarılır.

Özellik Çıkarma ve Model Eğitimi

Pompa verileri üzerinde; ortalama, RMS, spektral kurtosis, zarf spektrumu ve harmonik bileşenler gibi özellikler çıkarılır. Diagnostic Feature Designer’ın denetimli sıralama modunu kullanarak arıza durumlarını en iyi ayırt eden özellikler seçilir. Seçilen özellikler bir tabloya aktarılır ve şu adımlar uygulanır:

  1. Arıza sınıflandırma: Seçilen özellikler ile bir makine öğrenmesi sınıflandırıcısı (örneğin, rastgele orman veya SVM) eğitilir. Veri seti, her bir arıza türü için eğitim ve test kümelerine ayrılır. K‑katlı çapraz doğrulama ile modelin doğruluk ve F1 skorları değerlendirilir.
  2. Gerçek zamanlı izleme: Eğitilen model, gerçek pompa verileri üzerinde çalıştırılır. Model çıkışı “sağlıklı”, “rulman aşınması” gibi sınıflar döndürür ve işletme sistemi operatörleri anında bilgilendirilir.
  3. RUL tahmini: Sızdırmazlık kaçakları ve rulman aşınması için koşul göstergelerinin zaman içindeki eğilimi izlenir. Üssel degradasyon modeli ve benzerlik tabanlı model gibi RUL tahmincileri eğitilir. Örneğin, rulman aşınması göstergesi her simülasyonun sonuna kadar kaydedilir; “trendability” ve “prognosability” metrikleri hesaplanarak en güvenilir gösterge seçilir ve fit ile degradasyon modeli parametreleri tahmin edilir. Ardından predictRUL fonksiyonu, her pompa için kalan ömür dağılımını verir.

Deneme Yapabileceğiniz Hazır Örnekler

Kullanıma hazır bazı örnekler aşağıdadır.

Derin Öğrenme ile Rulman Arızası Tanıma

Pompalar haricinde, döner makinelerde en sık görülen arızalardan biri rulman hasarıdır. MathWorks’ün Rolling Element Bearing Fault Diagnosis Using Deep Learning örneği, Wavelet Toolbox, Predictive Maintenance Toolbox ve Deep Learning Toolbox’ı bir araya getirerek 1‑boyutlu titreşim sinyallerini 2‑boyutlu scalogram görüntülerine dönüştürür ve önceden eğitilmiş bir evrişimli sinir ağı ile arıza sınıflandırması yapar. Bu yöntem, geleneksel yaklaşımlarda gereken manuel özellik çıkarımı süresini azaltır ve küçük veri kümelerinde bile yüksek doğruluk sağlar.

Örnekte kullanılan Machinery Failure Prevention Technology (MFPT) verisi, farklı yük ve hız koşullarında sağlıklı, dış bilezik hatalı ve iç bilezik hatalı rulmanlardan oluşan 20 veri seti içerir. Titreşim sinyalleri sürekli dalgacık dönüşümü (CWT) ile zaman‑frekans düzleminde temsil edilerek scalogram’lar elde edilir ve bu görüntüler transfer öğrenimi için bir resim sınıflandırma ağının girişine beslenir. Uygulama adımları şunlardır:

  1. Veri Hazırlama: MFPT veri seti indirildikten sonra her ölçüm için titreşim sinyali (gs) ve örnekleme hızı (sr) alınır. İç ve dış bilezik hatalarının kritik frekansları hesaplanır.
  2. Scalogram Oluşturma: cwt fonksiyonu veya plotBearingSignalAndScalogram yardımcı fonksiyonu kullanılarak titreşim sinyali scalogram’a dönüştürülür. Scalogram’ın iki boyutu zaman ve frekansı temsil eder.
  3. Model Eğitimi: Hazır bir derin sinir ağı (örneğin SqueezeNet) yüklenir, son katmanları MFPT verisindeki sınıf sayısına göre yeniden yapılandırılır ve ağırlıkları dondurarak transfer öğrenimi yapılır. Eğitim sırasında augmentedImageDatastore kullanılarak veri artırımı yapılabilir.
  4. Test ve Değerlendirme: Ayrılmış test verileri ile model doğruluğu hesaplanır. Confusion matrix ve ROC eğrileri değerlendirme için kullanılabilir. Eğitim tamamlandığında, kod MATLAB Coder ile gerçek zamanlı uygulamalara gömülebilir.

Bu yöntem, pompa senaryosunda da kullanılabilir: pompa vibrasyon verileri scalogram’lara dönüştürülüp rulman arızaları bir derin ağla sınıflandırılabilir. Transfer öğreniminin sağladığı hız ve doğruluk avantajları, veri kümesinin küçük olduğu durumlarda özellikle önemlidir.

Kalan Ömür Tahmini ve Bakım Planlaması

Arıza türü tespit edildikten sonra, bakım planlaması için kalan ömrün tahmin edilmesi gerekir. RUL tahmini modelleri, koşul göstergelerinin zaman serilerindeki eğilimleri analiz ederek arızanın ne kadar süre sonra gerçekleşeceğine ilişkin olasılık dağılımları üretir. Predictive Maintenance Toolbox; üssel ve lineer degradasyon modelleri, benzerlik tabanlı modeller ve hayatta kalma modelleri gibi seçenekler sunar. Benzerlik tabanlı bir tahmin için tipik adımlar şöyledir:

  1. Veri hazırlığı: Run‑to‑failure (arızaya kadar çalışma) verilerini içeren bir ensemble oluşturulur. PHM 2008 turbofan motoru veri seti gibi açık veri setleri bu amaçla kullanılabilir. Her makine için zaman, çalışma koşulları ve çoklu sensör ölçümleri tablo halinde saklanır.
  2. Çalışma rejimi kümeleme ve normalizasyon: Farklı çalışma koşullarındaki veriler birbiriyle karşılaştırılabilmesi için kümeleme ve normalizasyon yapılır. Bu adım, hız ve yük gibi değişkenlerin etkisini azaltır.
  3. Trendability analizi ve sağlık göstergesi oluşturma: Tek tek özelliklerin eğilimleri incelenir, en trendlenebilir ve prognostik özellikler seçilir ve sensör füzyonu ile tek bir sağlık göstergesi elde edilir.
  4. Model eğitimi ve tahmin: Sağlık göstergesi kullanılarak bir benzerlik tabanlı RUL modeli (residualSimilarityModel veya pairwiseSimilarityModel) eğitilir. predictRUL fonksiyonu, her yeni ölçüm geldiğinde kalan ömür tahminini günceller.

RUL tahmini sonucunda, bakım müdahalelerinin ne zaman yapılacağı planlanabilir. Örneğin bir pompanın rulman aşınmasının 200 saat içinde arızaya yol açacağı tahmin ediliyorsa, planlı duruş buna göre ayarlanır. Tahminler belirsizlik içerdiğinden, güven aralıkları veya risk tabanlı karar yöntemleri ile desteklenmelidir.

Sonuç

MATLAB ve Predictive Maintenance Toolbox, kestirimci bakım algoritmaları geliştirmek için uçtan uca bir çözüm sunar. Diagnostic Feature Designer ile özellik çıkarmadan makine öğrenmesine, Simscape ile dijital ikiz oluşturup arıza verisi üretmeye ve RUL tahmini ile bakım planlamasına kadar tüm aşamalar tek bir ortamda gerçekleştirilebilir. Bu yazıdaki pompa senaryosu ve rulman örneği, MathWorks’ün gerçek örneklerinden uyarlanmış olup, pratikte uygulanabilir adımlar içerir. Sensör verisini toplayıp koşul göstergeleri tasarlamak, arıza tespit ve teşhisi için uygun modeller seçmek ve kalan ömrü tahmin etmek, modern endüstriyel tesislerde arıza riskini azaltmak için kritik öneme sahiptir.

Kestirimci bakım projelerine başlarken, mevcut verinin kalitesi ve miktarı ile başlayın. Yeterli arıza verisi yoksa, Simscape tabanlı modeller ve benzetimlerle veri üretin ve makine öğrenmesi algoritmalarınızı bu verilerle eğitin. Küçük veri kümeleri için transfer öğrenimi ve otomatik özellik çıkarımı büyük avantaj sağlar. Son olarak, RUL tahminlerinin belirsizlik içerdiğini ve bakım kararlarının mühendislik yargısı ile desteklenmesi gerektiğini unutmayın. İyi planlanmış bir kestirimci bakım stratejisi, ekipman ömrünü uzatır ve üretim hatlarınızın kesintisiz çalışmasını sağlar.

Kurumsal
MATLAB & Simulink
İletişim
Kurumsal e-bültenimize abone olarak FİGES hakkındaki güncel gelişmelerden haberdar olabilirsiniz.
E-Bültene Kayıt Ol
Sosyal Medya'da FİGES

© FİGES A.Ş. Tüm hakları saklıdır.