ISSN: 2147 - Mühendislik | FLUENT| CFD FEA …Derin Öğrenme (Deep Learning), Nesnelerin İnterneti (Internet of Things) gibi alanlarda MATLAB&Simulink kapsamlı çözümler sunmaktadır

ARGE DERGİSİISSN: 2147 - 9550

www.figes.com.tr 2 ARGE Dergisi 3

BAKIŞ AÇISIPoint of View

Dr. Tarık ÖĞÜTYönetim Kurulu BaşkanıFİGES A.Ş.

MATLAB&Simulink yazılım sisteminin çıkış noktası matematikteki “Özdeğer Problemleri” dir. Bir yapının özdeğerlerinin bilinmesi ise, yapının dinamik davranışının bilinmesi anlamına geldiğinden konunun ne derece önemli olduğu açıktır. 1970’li yılların sonlarında daire, dikdörtgen, silindir gibi özel geometrik şekle sahip kabuk yapılar dışındaki yapıların özdeğerlerini analitik olarak hesaplamak mümkün olmadığından bilim insanları uygun sayısal yöntemler arayışı içindeydi. O zamanlar Stanford Üniversitesi’nde matematikçi olan Prof. Cleve Moler tam bu konu üzerinde çalışmaktaydı. Prof. Moler, FORTRAN kullanmadan matris hesapları yapabilen LINPACK ve EISPACK yazılımlarının geliştirilmesine öncülük etmiş, L-şeklinde bir plakanın özdeğerlerini bu yazılımlarla hesaplamayı başarmıştı. Aynı yıllarda genç bir kontrol mühendisi olan Jack Little’ın da bu amaç için bir yazılım geliştirmek ve bunu ticarileştirmek gibi bir hayali vardı. Bu iki insanın yollarının kesişmesi 1984 yılında MathWorks Inc firmasının kuruluşunu beraberinde getirmiştir. Bugün şirketin 4000 çalışanı ve 900 milyon dolar yıllık cirosu vardır. Prof. Cleve Moler MathWorks firmasının yönetim kurulu başkanı ve Jack Little ise CEO’sudur.

MATLAB&Simulink için bir yazılım platformu demek daha doğru olur. Bu yazılım platformu bize kontrol mühendisliği, sinyal ve görüntü işleme, yapay zeka vb. alanlarda kolayca gömülü yazılımlar geliştirmemizi sağlar. Geliştirilen bu gömülü yazılımları çalıştırmak için MATLAB&Simulink lisansına ihtiyaç yoktur. Yani C kodu kullanarak geliştirdiğimiz bir gömülü yazılım gibi kod tamamen bağımsız çalışır ve bize aittir. Bu nedenle MATLAB&Simulink, kütüphanesinde mevcut olan matematik fonksiyonları, algoritmalar, diferansiyel denklem çözücüleri, matris cebiri operasyonları ile fikri hakları tamamen bize ait olan yazılımlar geliştirmemizi sağlar. İşte sağladığı bu avantajlar nedeniyle akademisyenler ve sanayi kuruluşları tarafından büyük destek ve rağbet görmüştür. Günümüzde MATLAB&Simulink bir endüstri standardı haline gelmiştir.

Matematiğin kullanıldığı sektörlere bir göz attığımızda, en yoğun kullanıldığı alanın mühendislik bilimleri olduğunu görürüz. Çünkü mühendisliğin temeli doğa bilimleri, yani fiziktir ve fiziksel olayları betimleyen denklemleri çözmek için matematiğe gereksinim olduğundan, özellikle mühendisler matematiği yoğun kullanmak zorundadır. Doğa bilimleri dışında tıp, ekonomi, finans, hatta sosyal bilimler her geçen gün matematiği daha yoğun kullanır hale gelmiştir. Son yıllarda hızla gelişen Yapay Zeka (Artifical Intelligence), Makine Öğrenmesi (Machine Learning), Derin Öğrenme (Deep Learning), Nesnelerin İnterneti (Internet of Things) gibi alanlarda MATLAB&Simulink kapsamlı çözümler sunmaktadır.

MATLAB&Simulink’in son derece geniş bir uygulama alanınına sahip olması, büyük bir kullanıcı sayısına sahip olmasını da beraberinde getirmektedir. MATLAB kullanıcıları çok farklı sektörlerde çalışıyor olsalar da, hepsi matematiğe hakim insanlardır. Yani, büyük çoğunlukla matematikçiler ve mühendislerdir. Son yıllarda MathWorks firması belirli bir format çerçevesinde bu kullanıcıları MATLAB EXPO şemsiyesi altında bir araya getirerek kendi aralarında bir sinerji oluşmasını hedeflemektedir. Türkiye’de böyle bir etkinlik ilk kez 19 Eylül 2018 tarihinde Congresium Ankara’da gerçekleştirilecektir.

Dergimizin bu sayısında çeşitli sektörlerdeki MATLAB&Simulink uygulamalarına yer verdik. Ancak çok daha fazlasını MATLAB EXPO etkinliğinde bulacağınızı söyleyebilirim.

İyi okumalar...

Sayın ARGE DERGİSİ Okuyucuları,

Saygı ve SevgilerimleDr. Tarık Öğüt


İÇİNDEKİLERİÇİNDEKİLER

İÇİNDEKİLER İÇİNDEKİLER2018 - 3 / Sayı: 19(Temmuz - Ağustos - Eylül) ISSN: 2147-9550

TEKNİK HİZMETLERYayına Hazırlama ve TasarımFİGES A.Ş. Burak ÜNLÜKARA

Basım Yeri:Everest Basım Matbaa Hiz. San.Tic.Ltd.Şti.Sancaktepe Mah. 914. Sk.No:2/1 34200 Bağcılar / İSTANBULTel :+90 212 434 51 34

Yayın Türü:Yerel süreli Türkçe ve İngilizce Bilimsel Yayın

3 ayda bir yayımlanır

FİGES A.Ş. Adına SahibiYönetim Kurulu BaşkanıDr. Tarık ÖĞÜT

Sorumlu Yazı İşleri MüdürüBerrin Kayacan Ö[email protected]

Yayına HazırlayanlarBurak ÜNLÜKARA

Yönetim Yeri:Ulutek Teknoloji Geliştirme Bölgesi, Uludağ Üniversitesi Görükle Kampüsü, 16059 Nilüfer-BursaTelefon : 224 4428585Faks : 224 4428586

www.figes.com.tr

Dergide yayımlanan Yazı, Fotoğraf, Harita, İllüstrasyon ve Konuların Her Hakkı Saklıdır.Kaynak Gösterilmek Şartıyla Alıntı Yapılabilir.Yayınlanan Eserlerin Sorumluluğu Eser Sahiplerine Aittir.

Aksi Gösterilmedikçe Tüm Görseller:ANSYS, MATHWORKS ve FİGES

Para ile satılmaz

FİGES İLERİ MÜHENDİSLİK VE ARGE TEKNOJİLERİ DERGİSİ

06MATLAB SİMuLİNK’TE AKILLI KAMERA VE RADAR SENSÖRÜ İÇİN VERİ BİRLEŞTİRME uYGuLAMASI

HAREKETLİ ARAÇ ÜZERİNDE YAPAY SİNİR AĞI DESTEKLİ NAMLu ATIŞ KONTROLÜ

12

FPGA ÜZERİNDE ODAK MOTORu İÇİN FİLTRE VE PI KONTROLcÜ TASARIMI

18

36cuSTOMIZING THE REAL-TIME cOMPILER OF SIMuLINK cODER FOR SIEMENS SIMATIc S7-1500 SOFTwARE cONTROLLER

45VOLVO cONSTRucTION EquIPMENT STREAMLINES PRODucT DEVELOPMENT wITH A REAL-TIME, HuMAN-IN-THE-LOOP SIMuLATOR

40THREE wAYS TO ESTIMATE REMAINING uSEFuL LIFE FOR PREDIcTIVE MAINTENANcE

47KOREA AEROSPAcE RESEARcH INSTITuTE ADOPTS MODEL-BASED DESIGN TO DEVELOP DO-178c-cOMPLIANT cONTROL LAw SOFTwARE24

KRİTİK ASKERİ SİSTEMLERDE LTE KuLLANIMI VE MATLAB İLE KARIŞTIRIcILARA KARŞI PERFORMANS ANALİZLERİNİN GERÇEKLEŞTİRİLMESİ

30DÖRT ROTORLu İNSANSIZ HAVA ARAcI İÇİN OTOPİLOT VE GÜDÜM SİSTEMİ TASARIMI

43VIRGIN ORBIT SIMuLATES LAuNcHERONE STAGE SEPARATION EVENTS


MAKALE / OTOMOTİV

MATLAB SİMuLİNK’TE AKILLI KAMERA VE RADAR SENSÖRÜ İÇİN VERİ BİRLEŞTİRME uYGuLAMASI

Obje takip ve tespit uygulamaları, başta Savunma Sanayi olmak üzere havacılık ve robotik gibi alanlarda uzun süredir üzerinde yoğun çalışmaların yapıldığı konulardan birisi olmuştur[1]. Bununla birlikte, te-knolojide son yıllarda gerçekleşen baş döndürücü gelişmeler, benzer teknoloji uygulamalarının motorlu taşıtlar gibi günlük hayatımızın bir parçası haline ge-len ve dünya genelinde yılda yüz milyona yakın üretim adedi bulunan[2] bir sektöre girişini de mümkün kılmıştır. Otomotiv sektöründe ilk örneklerine 1990’lı yılların başında yüksek segment araçlarda rastlanan Gelişmiş Sürüş Destek Sistemleri, günümüzde yeni piyasaya çıkan araçlarda neredeyse standart fonk-siyon haline gelmiş ve bir çok büyük firma yakın gelecekteki vizyon hedefini, insanlığı otonom araç

teknolojisi ile tanıştırmak olarak belirlemiştir[3]. Bu sebeple, gelecekte sürücülerin yerini alacak bu te-knolojilerin, günümüzde sürücülerin sorumluluğunda olan çevre algılama, obje ve konum tespiti, karar verme, rota planlama ve aracın planlanan rotada sevki gibi bir çok görevi yerine getirmesi gerekmek-tedir. Bu makalede, öncelikle aracın ön bölgesindeki diğer trafik objelerini algılanmasına ve takibine yöne-lik geliştirilen veri birleştirme mimarisi anlatılacaktır. Daha sonra, tasarlanan bu mimarinin MATLAB/Simulink ortamında geliştirilme sürecine değinilerek, otomotiv standardında bir RADAR sensörü ve akıllı kamera sensörü ile algılanan trafik objelerinin veri birleştirilme uygulaması sonuçları sunulacaktır.

Giriş kısmında bahsedildiği üzere, hem sürüş destek sistemlerinde hem de otonom sürüş teknolojilerinde en önemli alt fonksiyonlardan biri, aracın çevresini ve çevresindeki objeleri algılama görevidir. Aracın çevresindeki objeleri algıladığı ve bir sürücü gibi sınıflandırdığı bu algoritmalar literatürde “Çevre Mod-eli” olarak geçmektedir[4]. Çevre Modeli, temelde aracın üzerindeki sensörlerden gelen bütün veri-lerin işlenmesi ile aşağıdaki verilerin oluşturulmasını amaçlamaktadır

• Bisiklet, taşıt, yaya, trafik işaretleri, trafik ışıkları, bariyerler, refüj gibi tüm varlıkların tespiti, sınıflandırılması, konumlarının hesaplanması ve hareketlerine ilişkin durumların tespiti

• Aracın çevresindeki sürülebilir alanların tespiti• Aracın bulunduğu ortam hakkındaki genel bilgiler

(örneğin; otoban, bölünmüş yol veya otopark)

Bu bilgilerin oluşturulmasında RADAR, kamera, LIDAR, ultrasonik sensörler ve araç üzerindeki diğer aktif sensörler ile birlikte[5], yüksek çözünür-lüklü harita (HD Map) ve V2X haberleşme gibi diğer kaynaklardan da faydalanabilmektedir[6]. Bu kay-naklardan gelen aynı objeye ait olan bilgiler, farklı sayıda ve doğrulukta olabilmekte ve bu durum da sensör birleştirme algoritmalarına olan ihtiyacı doğurmaktadır. Örneğin, tespit edilen bir aracın RA-DAR sensörü ile dikey uzaklığı ve dikey hızı hassas

bir şekilde ölçülebilirken, kamera sensörü ile yanal uzaklığı ve hızı hassas bir şekilde ölçülebiliyorsa, iki sensörden gelen veriler birleştirilerek tespit edilen aracın yatay ve dikey pozisyon ve hız bilgilerini en ha-sas şekilde elde edebilmek mümkün olmaktadır.

Bununla birlikte, farklı kaynaklardan gelen bilgi-lerin birleştirilmesinde çeşitli zorluklarla da karşılaşılabilmektedir. Çoğunlukla bu veriler sen-sörlerden asenkron yapıda gelmekte ve farklı za-manlarda örneklenmiş olmaktadır. Ek olarak, farklı sensörlerden gelen hangi ölçümün hangi objeye ait olabileceğine karar vermek de başlı başına bir prob-lemdir ve bu problemin çözümüne yönelik literatürde bir çok veri eşleştirme algoritması geliştirilmiştir. Sen-sörlerin menzil farkları, farklı ortamlarda ve ölçüm değerlerinde farklı hassasiyette olmaları, farklı tipte ölçüm sağlamaları (örneğin RADAR dikey hızı ölçerk-en, kamera ölçemeyebilir) da başlı başına çözülmesi gereken problemlerdir.

Mobil eye akıllı kamera ve Continental Uzun men-zil RADAR sensörleri (Şekil 1) için geliştirdiğimiz veri birleştirme algoritmasında öncelikle sensörler ve araç dinamikleri MATLAB/Simulink ortamında modellenmiştir. Bu modele, sensörlerin asenkron yapıları, menzil farklılıkları, ölçüm tipleri ve hassasi-yetleri ile veri formatları da dahil edilerek olabildiğince gerçekçi bir benzetim ortamı oluşturulmuştur.

GİRİŞ

Umut [email protected] Sürüş ve Araç Kontrol Sistemleri Takım LideriAVL Türkiye

Şekil 1-Referans Uygulama Sensör Yerleşimi


Mobileye kamera ve Continental ARS408 Uzun Menzil RADAR kullanılan bu uygulamada (Şekil 2), kamera ve radar tarafından tespit edilen objeler, sensor seviyesinde kalman temelli bir algoritma ile filtrelenerek veri birleştirme seviyesinde takip edilen

objeler ile eşleştirilip veri birleştirme işlemi yapılmıştır. Veri birleştirme işlemi sonucunda tespit edilen objelerin bilgisi ise görselleştirilmek üzere bir arayüze aktarılmıştır.

Veri birleştirme seviyesinde (Şekil 3), bütün sensörlerden gelen veriler öncelikle zamansal ve uzaysal olarak hizalanmış, daha sonra takip edilen

objeler ile eşleştirilmiştir. Eşleştirilen ölçümler içerisindeki sayısal ve anlamsal veriler takip edilen objelerin verileri ile birleştirilmiştir.

Geliştirilen algoritma, oluşturulan yapay ölçümler ile benzetim ortamında test edilmiş ve doğrulanmıştır. Örneğin, Şekil 4’te görülen 3 araçlı senaryo için, araçlara ait sensör ölçümleri ve veri birleştirme algoritması çıktıları Şekil 5’te sunulmuştur. 1 numaralı durumda 2. araç sadece RADAR, 2 numaralı durumda ise 3. araç sadece kamera sensörü ile

algılanabilmesine rağmen veri birleştirme sonucu elde edilen araçların sürekli bir şekilde takip edilebildiği görülmektedir. 3 numaralı durumda ise 2 numaralı araca ait hiçbir ölçüm olmamasına rağmen, veri birleştirme algoritmasının aracın konumunu bir süre tahmin ettiği ve eşleşen ilk ölçüm verisi ile konumu doğrultup takibe devam ettiği görülebilmektedir.

Benzetim ortamında oluşturulmuş veriler ile MATLAB/Simulink ortamında doğrulanan algoritma, gerçek sensörler ile kaydedilmiş verilerin benzetim ortamında yeniden oluşturulmasıyla da test edilmiştir. Şekil 6’da sunulan sonuçlarda, 1 numaralı durum yalnızca

kamera tarafından algılanabilen, 2 numaralı durum hem kamera hem de RADAR tarafından algılanabilen, 3 numaralı durum ise yalnızca RADAR tarafından algılanabilen araçlar için veri birleştirme algoritması sonucudur.

Bu örnektekine benzer algoritma geliştirme uygulamalarında hata ayıklama/düzeltme işlemleri ve performans ölçümü oldukça zor olabilmektedir. Özellikle algoritma doğrulama ve performans ölçümü aşamasında yapılan gerçek ölçümlerin kesin değerleri bilinemediğinden, algoritmanın öncelikle yapay

olarak yaratılmış simulasyon verisi ile test edilmesi ve dogrulanması gerekmektedir. Bu amaçla, kullanılan sensörler MATLAB’ın Otonom Sürüş Sistemleri Araç Kutusu[7] (Automated Driving System Toolbox)’nda modellenerek, çeşitli senaryolarda yapay ölçümler oluşturulmuştur. (Şekil 4)

Şekil 2 – Uygulama Genel Mimarisi

Şekil 4 – Otonom Sürüş Sistemleri Araç Kutusu Kullanılarak Oluşturulan 3 Araçlı Senaryo

Şekil 5 – Benzetim Senaryo Verisi ile Uygulama Sonuçları

Şekil 3 – Veri Birleştirme Mimarisi


Hem benzetim ortamında oluşturulan sensör verileri, hem de kaydedilmiş sensör verileri ile doğrulanan Simulink kodu, daha sonra MATLAB’ın kod çevrim imkanlarından faydalanılarak C koduna çevrilmiştir. Otomatik olarak oluşturulan C başlık ve kaynak dosyaları, daha önce C++ ortamında geliştirilen bir sensör arayuz ve GUI programına entegre edilerek algoritmanın gerçek zamanlı olarak da çalışması/görselleştirilmesi sağlanmıştır. Otomotiv sınıfı akıllı kamera ve RADAR sensörlerinin veri birleştirmesi için oluşturulan bu algoritmanın geliştirme sürecinde MATLAB ve Simulink ortamının gelişmiş imkanlarından faydalanılmıştır. Algoritmada özellikle veri eşleştirme fonksiyonları, karmaşık matris operasyonları ve olasılık

teorisi ile alakalı fonksiyonların bulunması sebebiyle, MATLAB’ın sunduğu C koduna çevrilebilir hazır çözümler, geliştirme sürecini oldukça hızlandırmıştır. Bununla birlikte, hata ayıklama süreçlerinde işlem takibi ve bütün verilerin figurler ile görsel olarak ifade edilebilir olması, hataların giderilmesini ve iyileştirme süreçlerini oldukça kolaylaştırmıştır. Simulink ortamında geliştirilen kodun, kolaylıkla C koduna çevrilebilir olması hem insan hatalarından kaynaklanabilecek hataların önüne geçmiş hem de algoritmanın geliştirildikten sonra gerçek zamanlı çalışmaya uygun hale getirilmesi sürecini çok büyük ölçüde kolaylaştırmıştır.

Şekil 6 – Sensör Verileri ile Uygulama Sonuçları

1. G. W. Pulford, “Taxonomy of multiple target tracking methods,” IEE Proceedings - Radar Sonar and Navigation, vol. 152, pp. 291-304, 2005.

2. The International Organization of Motor Vehicle Manufacturers(Organisation Internationale des Constructeurs d’Automobiles), 2016 Production Statistics

3. Self-driving Car Timeline for 11 Top Automakers, https://venturebeat.com/2017/06/04/self-driving-car-timeline-for-11-top-automakers/

4. Berger, C., & Rumpe, B. (2014). Autonomous driving-5 years after the urban challenge: The anticipatory vehicle as a cyber-physical system. arXiv preprint arXiv:1409.0413.

5. Meng, X., Wang, H., & Liu, B. (2017). A Robust Vehicle Localization Approach Based on GNSS/IMU/DMI/LiDAR Sensor Fusion for Autonomous Vehicles. Sensors, 17(9), 2140.

6. Seif, H. G., & Hu, X. (2016). Autonomous driving in the iCity—HD maps as a key challenge of the automotive industry. Engineering, 2(2), 159-162.

7. Automated Driving System Toolbox, https://www.mathworks.com/products/automated-driving.html

REFERANSLAR


Namlu atış kontrol sisteminin belirlenen her hedefi vurabilmesi için gerekli namlu yükselme açısının (elevation angle - ) hesaplanmasında ve silah atış kontrol sistemindeki hedefi yakalama probleminin çözümlenmesinde bir yapay sinir ağı (YSA) yapısından faydalanılmıştır [3]. YSA yapısında kullanılan ağırlık ve bias katsayılarının optimize edilmesinde genetik algoritma yöntemi tercih edilmiştir. Burada oluşturulan YSA’nın eğitiminde kullanmak üzere bir eğitim data kümesi hazırlanmıştır. Eğitim için ele alınan 25 farklı hedefin koordinatları belirli bir aralıkta rastgele seçilmiş, araç ve hedef noktanın hareketsiz olduğu kabul edilmiştir. Belirlenen hedeflere gerçekleştirilen atışların isabet başarı oranları, belirlenecek namlu yükselme açısına bağlı olarak değişmektedir. Bu şekilde oluşturulan eğitim data kümeleri ile YSA’nın eğitimi tamamlandıktan sonra, eğitimde kullanılan hedeflerden farklı olarak rastgele seçilmiş koordinatlar hedef alınarak atış testleri için simülasyonlar tekrarlanmıştır. Ayrıca bu çalışmada bölgesel minimuma takılmamak ve bütünsel minimumu bulabilmek açısından avantajlı olan Genetik algoritmalar yöntemi tercih edilmiştir.Bilinen sistemlerde namlu yükselme açısının tespitinde klasik analitik hesaplamalar yer almaktadır. Yapay zekâ tekniklerinin kullanılması ile bir sistemde modellenemeyen parametrelerin modeldeki etkisinin hesap edilebilmesi bir avantaj olarak karşımıza çıkmaktadır. Ayrıca sistem öğrenebilme özelliği kazanabilmektedir.

Simülasyonlarda aracın hareket halinde olması ve arazi yüzeyinin engebeli olmasına bağlı olarak araca etkiyen dış bozucu etkiler altında atış kontrol sisteminin başarısı da incelenmiştir.

Sistemin fiziksel parametrelerinden θ; gövdenin zemine göre olan açısal konumunu, α; namlunun gövdeye göre bağıl açısal konumunu, temsil etmektedir

Ele alınan sistemin dinamik modeli oluşturulmuş, eksenlere ait tahrik kuvvetlerini belirten matematiksel ifadeler Lagrange-Euler yöntemiyle hesaplanmıştır.

2. NAMLUNUN PID KONTROLÜ

Namlu açısının belirlenen referans açısal konuma getirilmesi için klasik bir PID kontrolör tasarlanmıştır. Hata değerinin anlık artış veya azalış eğilimine bakarak PID kontrol bir çıkış sinyali üretmektedir.PID kontrolörün başarısını ortaya koyabilmek için araç 5 m/s hızla ilerletilirken zeminden rastgele bozucu etkilere maruz bırakılmıştır. Başlangıç şartlarının sıfır olduğu andan itibaren namlu yükselme açısının ayrı ayrı ve referans konumlarına gitmesi için uygulanan PID kontrol neticesinde araç dinamiklerine ait sistem ve kontrol cevapları Şekil 2,3,4,5’te verilmiştir. Tasarlanan PID kontrol katsayıları deneme yanılma tekniği ile belirlenerek

, olarak bulunmuştur.

Şekil 1. Namlu Atış Kontrol Sistemli Yarım

Taşıt Modeli

Şekil 2. için PID Kontrol Neticesinde Araç Dinamiklerine Ait Cevaplar

Şekil 3. için PID Kontrol Neticesinde Araç Dinamiklerine Ait Cevaplar

Ahmet Burak [email protected] Yüksek MühendisiFIRAT ÜNİVERSİTESİMekatronik Müh. Bölümü

Doç. Dr. Oğuz [email protected] ÜNİVERSİTESİ Mekatronik Müh. Bölümü

Muhammet Aydı[email protected]. Makina MühendisiFIRAT ÜNİVERSİTESİ Mekatronik Müh. Bölümü

HAREKETLİ ARAÇ ÜZERİNDE YAPAY SİNİR AĞI DESTEKLİ NAMLu ATIŞ KONTROLÜ

Ülkelerin tehditlere karşı caydırıcılığı artırmak ve birbirlerine karşı üstünlük sağlamak amacıyla daha güçlü ve etkili silah sistemlerine sahip olma isteği ve ülkelerin bu alandaki çalışmaları günümüzde de artan bir hızla devam etmektedir [1]. Günümüz savunma sanayi teknolojisi ile geliştirilen yeni nesil silah sistemlerinin temel amacı, her türlü bozucu etki karşısında belirlenen hedefin başarılı bir şekilde vurulmasını sağlamaktır. Aynı zamanda, yaşadığımız dönem içerisindeki harp koşullarında, daha hareketli ve daha hızlı tepki verebilen silah sistemleri tercih edilmektedir. Bu silah sistemleri içerisinde, hareketli araç üzerinden yapılan atışın başarılı olması, namlu stabilizasyonu ile mümkündür. Namlu stabilizasyon sistemi, sadece bir hedef takip sistemi değil aynı zamanda namlunun hedef bölgesinde kalmasını sağlayan, arazi şartlarından en az etkilenen yüksek vuruş yüzdesi atışlar yapılmasına yardımcı olan bir sistemdir [2]. Namlu stabilizasyonunun başarılı bir

şekilde gerçekleştirilebilmesi için hareketli aracın süspansiyon özellikleri, arazi yüzeyinin fiziki özellikleri, atış yapılacak namlu sisteminin tepme kuvveti, havanın atmosferik şartları vb. tasarlanan sisteme tesir eden bozucu etkiler karşısında doğru tepkilerin elde edilmesi gerekmektedir.

Bu çalışmada, üzerine hareketli bir namlu atış kontrol sisteminin yerleştirildiği düzlemsel yarım taşıt modeli kullanılmıştır. Sistem toplamda 4 serbestlik dereceli olarak modellenmiştir. Aracın sabit ve hareketli durumlarında gerçekleştirilen simülasyonlarla atışların hedefe olan isabet başarısı incelenmiştir. Simülasyonlar MATLAB paket programında gerçekleştirilmiştir. Namlunun araç gövdesine göre yaptığı bağıl açısal hareketinde, hedeflenen referans açıyı yakalayabilmesi için klasik PID kontrol yöntemi kullanılmıştır.

1. GİRİŞ

MAKALE / SAVuNMA


eklenmesi gerekmektedir. Buna göre namlu yükselme açısı γ=φ+∅ olarak hesap edilmelidir.

Bu çalışmada YSA yardımıyla ∅ düzeltme açısının tespit edilebilirliği araştırılmıştır. Bunun için Şekil 7’de görülen 3 katmanlı ileri beslemeli bir YSA yapısı kullanılmıştır. Giriş katmanında 7 hücre, gizli katmanda 3 hücre ve çıkış katmanında tek hücre kullanılmıştır. Giriş ve gizli katmandaki hücrelerde aktivasyon fonksiyonu olarak tansig fonksiyonu, çıkış katmanında ise purelin fonksiyonu kullanılmıştır. Bu parametrelerin seçimi deneme yanılma tekniği ile belirlenmiştir. Atış yapılacak hedef noktanın x ve y koordinatları ile hipotenüs açısı YSA’ya verilecek giriş verileri olarak, ∅ düzeltme açısı ise YSA’ya öğrenmesi gereken çıkış verisi olarak belirlenmiştir. YSA’nın eğitimi için Tablo 1’de verilen eğitim data kümesi kullanılmıştır.

Yatay ve düşey koordinatları belli olan her bir hedefin isabet ettirilebilmesi için girişte verilmesi gereken ∅ düzeltme açıları tespit edilmiştir. Bu tespitte kullanılan genetik algoritma için, MATLAB genetik algoritmalar araç kutusundan faydalanılmış, popülasyon sayısı 40, iterasyon sayısı ise 120 olarak seçilmiştir.

Tablo 1. YSA için Hazırlanan Eğitim Data Kümesi

4. SİMÜLASYONLARLA HEDEF İSABET TESTLERİ

Şekil 8’de araç üzerindeki namludan yapılmış bir atışın hedefe isabet ettiği simülasyonlardan alınmış bir görüntü yer almaktadır.

Aracın hareketli ve hareketsiz olduğu farklı durumların her biri için gerçekleştirilen, 5 farklı hedefe yönelik atışlardan elde edilen test sonuçları Tablo 2’de verilmiştir. Aracın ilerleme hızları 0-4 m/s değerleri arasında seçilmiştir. Araç hareket halindeyken zeminden bozucu etki girişi uygulanmıştır. Bu bozucu etki araç ilerleme hızına da bağlı olarak 0.05 m genliğinde ve 0-5 Hz frekans aralığında zamanla rastgele değişen bir fonksiyon ile tanımlanmıştır.

Şekil 7. Namlu Düzeltme Açısı için Kullanılan YSA Yapısı

Tablo 2. Simülasyonlardan Elde Edilen Test Sonuçları

Şekil 8. Simülasyonlarla Gerçekleştirilen Atışın Hedefe İsabet Ettiği Anın Görüntüsü

0 0.5 1 1.5 20

5

10

15)ecere

D( afla + atet

0 0.5 1 1.5 2-50

0

50

Kon

trol

Tor

ku (

Nm

)

0 0.5 1 1.5 2-0.05

0

0.05

)m( ucuzob 1

Y

0 0.5 1 1.5 2-0.04

-0.02

0

0.02

0.04

0.06

Y2

bozu

cu (

m)

0 0.5 1 1.5 20

5

10

15

20

25

30

35

)ecereD( afla + atet

0 0.5 1 1.5 2-50

0

50

Kon

trol

Tor

ku (

Nm

)

0 0.5 1 1.5 2-0.05

0

0.05

)m( ucuzob 1

Y

0 0.5 1 1.5 2-0.06

-0.04

-0.02

0

0.02

0.04

Y2

bozu

cu (

m)

Ülkelerin tehditlere karşı caydırıcılığı artırmak ve birbirlerine karşı üstünlük sağlamak amacıyla daha güçlü ve etkili silah sistemlerine sahip olma isteği ve ülkelerin bu alandaki çalışmaları günümüzde de artan bir hızla devam etmektedir [1]. Günümüz savunma sanayi teknolojisi ile geliştirilen yeni nesil silah sistemlerinin temel amacı, her türlü bozucu etki karşısında belirlenen hedefin başarılı bir şekilde vurulmasını sağlamaktır. Aynı zamanda, yaşadığımız dönem içerisindeki harp koşullarında, daha hareketli ve daha hızlı tepki verebilen silah sistemleri tercih edilmektedir. Bu silah sistemleri içerisinde, hareketli araç üzerinden yapılan atışın başarılı olması, namlu stabilizasyonu ile mümkündür. Namlu stabilizasyon

sistemi, sadece bir hedef takip sistemi değil aynı zamanda namlunun hedef bölgesinde kalmasını sağlayan, arazi şartlarından en az etkilenen yüksek vuruş yüzdesi atışlar yapılmasına yardımcı olan bir sistemdir [2]. Namlu stabilizasyonunun başarılı bir şekilde gerçekleştirilebilmesi için hareketli aracın süspansiyon özellikleri, arazi yüzeyinin fiziki özellikleri, atış yapılacak namlu sisteminin tepme kuvveti, havanın atmosferik şartları vb. tasarlanan sisteme tesir eden bozucu etkiler karşısında doğru tepkilerin elde edilmesi gerekmektedir.

Bu çalışmada, üzerine hareketli bir namlu atış kontrol sisteminin yerleştirildiği düzlemsel yarım taşıt modeli kullanılmıştır. Sistem toplamda 4 serbestlik dereceli olarak modellenmiştir. Aracın sabit ve hareketli durumlarında gerçekleştirilen simülasyonlarla atışların hedefe olan isabet başarısı incelenmiştir. Simülasyonlar MATLAB paket programında gerçekleştirilmiştir. Namlunun araç gövdesine göre yaptığı bağıl açısal hareketinde, hedeflenen referans açıyı yakalayabilmesi için klasik PID kontrol yöntemi kullanılmıştır.

3. NAMLU YÜKSELME AÇISININ TESPİTİ

Konumu bilinen bir hedefe başarılı bir atış yapabilmek için namlunun, uygun yükselme açısına sahip olması gerekir. Şekil 6’da, hedef noktasını vurabilmek için araç gövde açısı ile α namlu bağıl açısının toplamı olan = +α namlu yükselme açısıyla basit bir eğik atış hareketi görülmektedir. Pratik uygulamalarda bu açı hesap edilirken mühimmatın izlediği yörünge güzergâhındaki hava sıcaklığı, basıncı, rüzgâr şiddeti ve yönü, havanın yağışlı olma durumu gibi atmosferik şartlar göz önünde bulundurulurken bu çalışmada bu parametreler ihmal edilmiştir.

Sürtünmesiz ve yerçekimsiz ortamda belirlenen bir hedefin başarıyla isabet ettirilebilmesi için Şekil 6’da görülen d_hip doğrultusunda bir yolun izlenmesi yeterli olacaktır. Bu doğrunun eğimi olan φ hipotenüs açısı hedefin x ve y koordinatlarına bağlı olarak (1)’deki gibi değişim gösterecektir. Ortama sürtünme etkisi ile birlikte düşey y ekseninde yerçekimi etkisinin dâhil edilmesi halinde, hedefin isabet ettirilebilmesi için φ hipotenüs açısına bir miktar ∅ düzeltme açısının

Şekil 6. Eğik Atışta Hipotenüs Açısı


5. SONUÇLAR VE ÖNERİLER

Dinamik bir sistemde olabilecek belirsizliklerden kaynaklanan problemlerin YSA ile aşılabileceği düşüncesinden yola çıkılarak bu çalışmada YSA’nın atış kontrol sistemindeki kullanılabilirliği incelenmiştir. Gerekli olan namlu yükselme açısının doğru hesap edilebilmesi hedef isabetinde büyük önem taşımaktadır. Ayrıca hesap edilen bu açının bir kontrolör tarafından sağlanması da gerekmektedir. Bu çalışmada katsayıları deneme yanılma yöntemi ile elde edilmiş klasik PID kontrol yöntemi kullanılarak namlunun açısal konum kontrolü belirli bir başarıyla sağlanmaya çalışılmıştır.

Tablo 2’de test simülasyonlarından elde edilen isabet hatalarına bakıldığında en büyük değerin hedeften 4.1319 m kadar, en küçük değerin ise 0.0782 m kadar saptığı anlaşılmaktadır. Bu aralıklardaki hassasiyete sahip uygulamalar için testlerin başarılı olduğu söylenebilir. İsabet hatasındaki bu değişkenliğe, araç hareketliyken zeminden etki eden bozucu girişlerin ve sistem dinamiğinde oluşabilecek belirsizliklerin neden olduğu düşünülmektedir. Namlu yükselme açı değerinin on binde bir hassasiyete kadar etkili olduğu görülmektedir. İsabet hata değeri kullanılan kontrolörün başarısını doğrudan ortaya koymaktadır. Sonuçlar incelendiğinde, bir atış kontrol sisteminde namlu yükselme açısının tespitinde YSA’nın kullanılabilir bir yapıda olduğu açıkça görülmektedir.

6. KAYNAKLAR

[1]Isık, H., 2016. Namlu İçerisindeki Balistik Parametrelerin Modellenmesi. The Journal of Defense Sciences Vol.15. pp. 159.

[2]Songul, S., 2014. Tank Namlusu Stabilizasyon Sisteminin Arduino İle Uygulanması ve Deneysel Düzeneğinin Hazırlanması. Master Tezi, Trakya Üniversitesi, Makine Mühendisliği Bölümü. pp. 20.

[3]Lee, Y, W., 2007 Neural solution to the target intercept problems in a gun fire control system. Neurocomputing-70. pp. 689.

Şekil 1. Genel kontrolcü mimarisi

FPGA ÜZERİNDE ODAK MOTORu İÇİN FİLTRE VE PI KONTROLcÜ TASARIMI

MAKALE / YAZILIM

Yapılan bu çalışmada FPGA üzerinde, odak motoru olarak kullanılan DC motorun konum kontrolü gerçeklenmistir. Çalışmada öncelikle kontrolcü MATLAB Simulink ortamında tasarlanmıştır. Sonrasında, tasarlanan bloklar HDL Coder yazılım aracı ile VHDL koduna dönüştürülmüştür. Eş zamanlı

benzetim çalışması sonrasında, üretilen VHDL kodları ile birlikte el ile yazılan kodlar birleştirilerek FPGA kodu oluşturulmuştur. Oluşturulan bu kod sistem üzerinde test edilmiştir. Son olarak da çevre koşulları testleri yapılarak sistemin güvenilir olduğu görülmüştür.

Tasarlanan yapıda öncelikle hedef konum girdisi ani değişimleri yumuşatmak için filtrelenmekte ve sonrasında da PI kontrolcü yardımıyla da oldukça

düşük hata seviyesinde hedeflenen konuma ulaşılmaktadır.

GİRİŞ

KONTROLCÜ TASARIMI

Low Pass Filter PI ControllerPWM signal

+-

Encoder

Target Positon

Position Error

Can Uğur [email protected] A.Ş. / MGEO

Murat [email protected] A.Ş. / MGEO


Şekil 2. Alçak geçirgen filtrenin basamak tepkisi

PI kontrolcü tasarımı Simulink üzerinde yapılmış ve VHDL kodları da yine buradan üretilmiştir. Şekil 3’te FPGA içerisinde bulunan blokların bir şema gösterimi bulunmaktadır. Bu şemada filtre ve PI kontrolcü blokları Matlab’ın HDL kodlayıcı özelliği ile üretilmiştir. PWM üretici ve motor konumu okuyucu blokları el ile yazılmıştır.

Şekil 3. Odak motoru kontrolcüsü için kurulan sistem

Eş Zamanlı Benzetim



Şekil 4. Tasarlanan PI kontrolcü ve üretilen VHDL kodunun eş zamanlı benzetim modeli

Filtre tasarımı MATLAB’ın “Filter Design & Analysis Tool” uygulaması üzerinden yapılmış ve sonrasında bu uygulama üzerinden filtrenin Simulink modeli ve VHDL kodu üretilmiştir. Her ne kadar filtre tasarımının sonucunda bize gerekli olan sadece VHDL dosyaları

ise de benzetim sırasında bize yardımcı olması açısından filtrenin bir Simulink modelinin üretilmesi gerekmektedir. Tasarlanan filtrenin basamak tepkisi Şekil 2’de görülmektedir.

EŞ ZAMANLI BENZETİM


PI kontrolcü tasarımı Simulink üzerinde yapılmış ve VHDL kodları da yine buradan üretilmiştir. Şekil 3’te FPGA içerisinde bulunan blokların bir şema gösterimi bulunmaktadır. Bu şemada filtre ve PI kontrolcü blokları Matlab’ın HDL kodlayıcı özelliği ile üretilmiştir. PWM üretici ve motor konumu okuyucu blokları el ile yazılmıştır.


Eş Zamanlı Benzetim

PI kontrolcü tasarımı Simulink üzerinde yapılmış ve VHDL kodları da yine buradan üretilmiştir. Şekil 3’te FPGA içerisinde bulunan blokların bir şema gösterimi bulunmaktadır. Bu şemada filtre ve PI

kontrolcü blokları MATLAB’ın HDL kodlayıcı özelliği ile üretilmiştir. PWM üretici ve motor konumu okuyucu blokları el ile yazılmıştır.

Filtre ve PI kontrolcü tasarımları sonrasında VHDL kodları üretilir. Ancak yapılan tasarımlar ile bu tasarımlardan üretilen VHDL kodlarının aynı başarıma sahip olma durumu kontrol edilmelidir. Bu amaçla

Simulink üzerinde eş zamanlı benzetim yöntemi kullanılmaktadır. Burada Simulink ile Modelsim RTL benzetim programı birlikte çalışmaktadır.

Şekil 5. Tasarlanan PI kontrolcünün eş zamanlı benzetim sonucu

Şekil 6. Odak motoru kontrol sisteminin Simulink üzerinde doğrulama modeli

Şekil 3’te tasarlanan PI kontrolcü için oluşturulan eş zamanlı benzetim modeli görülmektedir. Bu modelin girişine her iki kontrolcüye de verilecek olan bir giriş örüntüsü bağlanmıştır. Sonuç olarak da Şekil 4’te görüldüğü üzere her iki kontrolcünün çıkışı birbiri ile karşılaştırılmıştır ve her ikisinin de aynı sonucu verdiği görülmüştür

Benzer biçimde fitre tasarımı için de eş zamanlı benzetim çalışması yapılmış ve yine hatasız sonuçlar elde edilmiştir. Yapılan eş zamanlı benzetim çalışmaları sonucunda FPGA koduna eklenecek olan VHDL kodları hazır hale getirilmiştir.

Tasarımı tamamlanan FPGA kodu hazırlanan sistem üzerinde koşturulmuş ve sitemden doğrulama amaçlı olarak hedef konumu, merceğin anlık konumu, filtre çıkışı ve PI kontrolcü verileri toplanmıştır. Bu verilerin

ışığında Şekil 6’da görüldüğü üzere Simulink’te tasarlanan model üzerinden doğrulama işlemi yapılmıştır.

DENEYSEL SONUÇLAR


Şekil 7. Simulinkte oluşturulan filtre ile tasarlanan sistem üzerindeki filtrenin doğrulama sonucu

Şekil 8. Simulinkte oluşturulan PI kontrolcü ile tasarlanan sistem üzerindeki PI kontrolcünün doğrulama sonucu

Şekil 9. Tasarlanan sistemin kontrolcü başarımı

Filtre, PI kontrolcü ve sistemin başarımı, sırasıyla Şekil 7, Şekil 8 ve Şekil 9’da görülmektedir.

Görüldüğü üzere sistemin başarımı ile eş zamanlı benzetim sonuçları birbirlerine oldukça yakın sonuçlar vermektedir.

Öncelikle, üretilecek olan VHDL kodlarının veri genişliklerinin başka bir deyişle çözünürlüklerinin uygun şekilde belirlenmesi büyük önem arz etmektedir. Çözünürlüğün düşük olması durumunda sistemden istenilen verim alınamayacaktır. Çözünürlüğün gerekenden yüksek olması durumunda ise FPGA üzerinde gereksiz yere işlem yükü artacağı için kaynak kullanım miktarı ve güç tüketimi artacaktır. O yüzden bu değerlerin gereken hassasiyete ve benzetim sonuçlarından elde edilen sonuçlara göre belirlenmesi önem arz etmektedir.

MATLAB’ın kod üretme yeteneği bize daha hızlı kod geliştirme süreci, güvenilirlik, esneklik ve hızlı ilkörnek çıkarımı gibi konularda yarar sağlayabilmektedir. Gereksinimlerin hızlıca işlenerek yapının tasarlanması, tasarlanan bu yapının da MATLAB Simulink üzerinde hızlıca benzetiminin yapılabilmesi

sayesinde kod geliştirme süreci hızlı bir şekilde tamamlanabilmektedir. Bunun yanında örneğin PID değişkenlerinin değiştirilmesi ya da filtrenin kesim sıklığının veya derecesinin tekrardan belirlenmesi durumunda istenilen kodlar hızlıca yeni değişkenlerle tekrardan üretilebilmektedir. Kodun el ile yazılması durumunda ise gereksinimdeki bir değişim ile birlikte kodun neredeyse tamamının tekrardan yazılması gerekebilmektedir. Ayrıca gecikmeler ve kaynak kullanımı ile ilgili istenilen şekilde en iyileme yöntemleri seçilebilmektedir.

Sonuç olarak FPGA içerisinde tasarlanan sayısal kontrolcü donanım üzerinde test edilmiş ve veri kaydı alınarak doğrulama işlemi yapılmıştır. Son olarak tasarlanan sistem çevre koşulları testlerinden geçirilerek sistemin güvenilir bir yapıda olduğu görülmüştür.

SONUÇLAR


KRİTİK ASKERİ SİSTEMLERDE LTE KuLLANIMI VE MATLAB İLE KARIŞTIRIcILARA KARŞI PERFORMANS

ANALİZLERİNİN GERÇEKLEŞTİRİLMESİ

MAKALE / HABERLEŞME

Kablosuz haberleşme teknolojisinin bant genişliği, bağlantı hızı, veri kapasitesi, kapsama alanı ve güvenliği gibi bir çok özelliği, yıllar içinde gelişerek günümüzde yaygın olarak kullandığımız LTE-A seviyesine ulaşmıştır. 4.5G olarak da bilinen bu teknoloji ile akıllı cihazlarımız aracılığıyla yüksek boyuttaki verileri saniyeler içerisinde paylaşabilir, görüntülü konuşabilir, video izlerken internette arama yapabilir, konuma dayalı hizmetler ve daha pek çok özelliği kullanabiliriz.

Ancak kamu güvenliği, askeri ortamlar gibi kritik alanlarda kullanılan haberleşme sistemleri dar bantlı haberleşme sistemleri olarak geliştirildiği için sadece ses ve düşük veri iletimine olanak sağlamaktadır. Bu sebeple birçok ülke LTE-A protokolünün kritik uygulama haberleşme sistemlerinde kullanılmasını desteklemektedir.LTE-A’nın kritik haberleşme sistemlerinde de kullanılması, teknik olarak sağlayacağı avantajların yanı sıra maliyet olarak da avantaj sağlayacaktır. Avustralya hükümeti tarafından hazırlanmış olan Kamu Güvenliği Mobil Geniş Bant

(PSMB-Public Safety Mobile Broadband) araştırma raporuna göre, Avustralya’da sadece kritik alanlarda kullanılmak üzere kurulacak özel bir haberleşme ağının, ticari ağların kullanımını uyarlamaktan yaklaşık 2,8 kat fazla maliyetli olduğu belirtilmiştir [1]. İngiltere LTE-A standardını kritik alanlarda kullanmaya başlayan ilk ülkelerden biridir. Başlattığı yeni Acil Servis Ağı (ESN-Emergency Service Network) ile 2020 yılına kadar polis, itfaiye, arama kurtarma, ambulans ve diğer kamu güvenliği kullanıcılarını LTE tabanlı sistemlere geçirmeyi hedeflemektedir [2]. Kore hükümeti ise 2014 yılında PS (Public Safety) LTE adında bir proje başlatmıştır. Bant 28 (APT700) üzerinden özel LTE ağı kurmayı ve ülke çapında kritik önem taşıyan iletişimi sağlamayı hedeflemektedir. ABD, Belçika, Meksika, Fransa, Avustralya, Belarus gibi ülkeler de yakın zamanda LTE ağı üzerinde ulusal kamu güvenliği ağı da kurmayı planlamaktadır [2].

LTE-A’nın yaygın olarak kullanılması hedeflenen bir diğer alanı ise askeri amaçlıdır. ABD ordusu muharebe ortamındaki iletişimi sağlamak, video, ses ve veri de

Gizay KISA AraştırmacıTÜBİTAK UZAY

Fatih GENÇUzman Uygulama Müh.FİGES AŞ

LTE AŞAĞI-HAT FİZİKSEL KATMANI

dâhil olmak üzere gerekli görev parametrelerini anlık olarak aktarmak, uçak gemileriyle uçaklar arasındaki haberleşmeyi sağlamak için LTE kullanmaktadır [3]. Böylece mevcut durumun daha iyi anlaşılabilmesi ve değerlendirilmesi sağlanarak daha hızlı ve daha doğru tepkiler verebilmesi planlanmaktadır.

Bu çalışmada askeri sistemlerde sıklıkla görülen iletişim sistemlerine karşı geliştirilen karıştırıcıların tasarımı gerçekleşrilmiş, ticari kullanımlar için geliştirilen mevcut LTE-A’nın muhtemel kritik alanlarda, şu anki haliyle kullanılması durumunda ne gibi bir performans sergileyeceği gözlemlenmiştir.

Bu amaçla, LTE-A aşağı hat fiziksel kanalına baraj, kısmi bant, tek tonlu ve çok tonlu sinyal karıştırıcıların etkileri incelenerek, LTE-A sisteminin sinyal karıştırıcılar altında Bit Hata Oranı (BER-Bit Error Rate)- Sinyal Gürültü Oranı (SNR-Signal Noise Ratio) enerji verimliği hesaplanacaktır. Böylelikle ileride bir çanta boyutundaki sinyal karıştırıcılar ile acil durum müdahile ekiplerinin, askeri personelin veya doğal afet durumunda o bölgede bulunan vatandaşların iletişiminin kesilmemesinin ve daha büyük kaos ortamlarının oluşmasının önüne geçilebilir.

LTE aşağı hat fiziksel katmanı Aşağı-hat Bağlantı Paylaşımlı Kanal (DLSCH-Downlink Shared Channel) ve Fiziksel Aşağı hat Paylaşılmış Kanal (PDSCH-Physical Downlink Shared Channel) olarak iki

kısımdan oluşmaktadır. Bu işlem basamaklarından olan çoklayıcı ve kanal kodlama işlemleri, fiziksel kanalları ve modülasyon 3GPP standartlarında açıklanmıştır [4,5].

Şekil 1’de aşağı hat bağlantı için gerekli alıcı ve verici işlem basamaklarını göstermektedir. Buna göre her bir işlem basamağı MAC katmanında gönderilen verinin OFDM sinyali olarak antenlere aktırılıncaya kadar fiziksel katmanda gerçekleşen sinyal işlemlerini tanımlamaktadır. İlk aşama olan DLSCH aşamasında, veri çoklanır ve kodlanır. Hata tespiti için Döngüsel Artıklık Denetimi (CRC-Cyclic Redundancy Check) kodu üretilerek eklenir. Veriler, alt bloklar olarak bilinen daha küçük parçalara bölünür. Kullanıcı verileri turbo kanal kodlama yöntemiyle kodlanır. Oran eşleştirme ile de istenilen kodlama oranını yansıtmak

için çıkış bitlerinin sayısı belirlenir. Son olarak kod blokları kod sözcüklerine yeniden dönüştürülür. Buraya kadar gerçekleştirilen işlemler ikili sisteme göre gerçekleştirilmektedir. Daha sonraki aşamalar ise PDSCH olarak tanımlanır. Kod sözcükleri önce bir şifreleme işlemine tabi tutulur ve daha sonra modüle edilmiş bir sembol akışı ile sonuçlanan bir modülasyon ile haritalanır. Alıcıda verici işlemlerinin tersi gerçekleştirilir. Bu kısımda verici blok yapılarına ilaveten senkronizasyon ve kanal kestirimi aşamaları yer almaktadır.

Şekil 1. LTE aşağı-hat fiziksel katmandaki alıcı ve verici yapısı


Baseband to passband:

SİNYAL KARIŞTIRICILAR

Temel Bandtan Bandgeçiren bir iletişim ortamına geçiş işlemleri karıştırıcıların etkisini gözlemlemek için gerçekleştirilmiştir. MATLAB ortamında gerçekleştirilen kaynak kodlama, kanal kodlama, modülasyon ve kanal yapıları temel band olarak adlandırılan taşıyıcı frekansın sıfır kabul edildiği durum için üretilmiştir. Temel band haberleşmenin amacı taşıyıcı frekansının oluşturulması için gerekli olan yüksek örneklemelerden kurtulmak ve yüksek depolama gerektirmeyecek simülasyonları gerçekleştirebilmektir. Bu çalışmada Baraj Sinyal Karıştırıcı, Kısmi Bant Karıştırıcıların tasarımı temel band sinyalleri olarak tanımlanmıştır. Son olarak temelbandta tasarlanan verici sinyallerine kanalın ve AWGN gürültünün etkisi tanımlandıktan sonra karıştırıcın etkisi toplamalı olarak eklenmiştir.Bunun yanında Tek tonlu ve Çok Tonlu kanal karıştırıcılarını tasarlayabilmek için Bandgeçiren bir

yapı oluşturmak gerekmektedir çünkü bu karıştırıcıların yapısı gereği sürekli bir biçimde üretilmesi gereken bir ton olmaktadır. Bu tonların her bir alt banda etkisi ancak bandgeçiren haberleşme şeklinde gerçekleştirilebilmektedir. Bunun için Temel bandta tanımlanan vericisi sinyalleri ejwct taşıyıcı sinyali ile çarpılarak tanımlanmıştır. Benzer bir şekilde Tek ve Çok tonlu kanal karıştırıcılar üretilmiş ve verici sinyalin kanal çıktısına toplamalı olarak eklenmiştir. Bu sayede tüm karıştırıcıların etkileri analiz edilebilmiştir. Şekil 2 ‘de görüldüğü üzere verici ve alıcıya kanal, kanal karıştırıcının etkisi gösterilmektedir. Görüldüğü üzere verici sinyali kanal ve gürültüden geçtikten sonra alıcı tarafında karıştırıcıdan etkilenmektedir. Bu çalışmada Şekil2’de belirtilen genel yapı ile karıştırıcıların etkisi incelenmektedir

Yıllar içinde gelişen kablosuz ağların belki de en büyük ortak noktası hepsinin sinyal karıştırıcılar tarafından zayıf ya da şiddetli olarak etkileniyor olmasıdır. Baraj

sinyal karıştırıcı, kısmi bant sinyal karıştırıcı, tek tonlu sinyal karıştırıcı ve çok tonlu sinyal karıştırıcılar şekil 3’de gösterilmektedir.

Şekil 2. Alıcı, Verici ve Kanal Karıştırıcı şematiği

Şekil 3 Kanal Karıştırıcıları ve frekans eksenindeki etkileri

SİMÜLASYON PARAMETRELERİ

Baraj sinyal karıştırıcı (BSK), hedef sinyal hakkında ek bilgi gerektirmez. Tüm banda Toplanır Beyaz Gauss Gürültü (AWGN) bindirilerek gürültü seviyesi arttırılır. Böylece hedefin aldığı Sinyal-Gürültü Oranı (SNR) düşer. Baraj sinyal karıştırıcı çok etkili bir yöntem olmasına karşın çok fazla güç gerektirmektedir [6]. Kısmi bant sinyal karıştırıcı (KBSK), baraj sinyal karıştırıcıdan farklı olarak LTE-A sisteminde bant genişliğinin sadece belirli bir bölümü hedeflenir. Hedeflenen bant genişliğine yine sabit bir AWGN bindirilerek gürültü seviyesi artırılır. Özelikle LTE’de senkronizasyon sinyallerini karıştırmak için kısmi bant sinyal karıştırıcı kullanılabilmektedir [7]. Tek tonlu sinyal karıştırıcı (TTSK), kısmi bant karıştırıcısının bir çeşidi olarak sınıflandırılabilir. Her tek ton, LTE standardındaki

tek bir alt taşıyıcıyı karıştırmak için kullanılır. Tek tonlu sinyal karıştırıcı’da tek bir alt taşıyıcıyı karıştırabilmek için tek bir tonu yüksek güçte iletir. Çok tonlu sinyal karıştırıcı (ÇTSK), tek tonlu sinyal karıştırıcıdan farklı olarak birden çok alt-taşıyıcıyı karıştırmak için eşit güçte ve çok sayıda ton üretir. Özellikle iletilen sinyal karıştırıcının gücü sınırlı olduğunda, iletilen tonların sayısı arttırılarak sinyal karıştırıcının gücü düşürülür.

LTE-A aşağı hat fiziksel katmanına ayrı ayrı eklenerek bant genişliği ve modülasyon seviyelerine göre BER (Bit Hata oranı)- SJNR (İletişim sinyalinin hattaki gürültü artı karıştırıcı oranı) performansı karşılaştırmalı olarak incelenmiştir.

Kanal yapısı olarak düşük hareketli frekans seçici kanal tercih edilmiştir. Simülasyon parametreleri sırasıyla: Alıcı anten sayısı 1, verici anten sayısı 1, kanal bant genişliği 1,4 MHz ve 20 MHz, modülasyon tipi 16 QAM ve 64 QAM, OFDM için 1,4 MHz ve 20 MHz bant genişliği sırasında FFT genişliği 128 ve 2048, kodlama oranı 1/3, Turbo şifre çözme döngü sayısı 6, taşıyıcı frekans 2,5x109 olarak seçilmiştir.

Tüm simülasyonlarda Monte Carlo simülasyon metodu kullanılmıştır. Monte Carlo simülasyonu maksimum hata sayısı ve maksimum bit sayısı değerlerine göre gerçekleştirilmiştir. BER analizleri bu iki kritik değere ulaştığında sonuçlanmakta ve bir sonraki iterasyona geçilmektedir. BER performansları çıkartılırken maksimum hata sayısı ve maksimum bit sayısı bir milyondur.

Tablo 1. Aşağı-hat fiziksel katman simülasyon parametreleri

Simülasyon Bant Genişliğinin Performansa Etkisi

Simülasyon Modülasyonun Tipinin Performansa Etkisi

Kanal Tipi Düşük Hareketli Frekans Seçici Kanal Düşük Hareketli Frekans Seçici Kanal

AWGN Kanal 10 dB 10 dB

Kullanılan Bant Genişlikleri 1,4 MHz, 20 MHz 1,4 MHz

Kullanılan Modülasyon Çeşidi 16 QAM 16 QAM, 64 QAM

Alıcı Anten Sayısı 1 1

Verici Anten Sayısı 1 1

Kodlama Oranı 1/3 1/3

Maksimum turbo şifre çözme sayısı 6 6

Taşıyıcı Frekans (Hz) 2,5x109 2,5x109


SİMÜLASYON SONUÇLARI VE ANALİZLER

Tablo 1 ‘de iki farklı senorya için belirlenen parametreler gösterilmektedir. Bu parametreler ile Şekil 3’de BSK, KBSK, TTSK ve ÇTSK’nin LTE-A 1,4 MHz ve 20 MHz bant genişliklerinde ve 16 QAM modülasyon tekniği altında bozucu etkileri bir arada gösterilmiştir. Grafiğe göre, her iki bant genişliğinde de ÇTSK’nin bozucu etkisinin en fazla olduğu sırasıyla TTSK, BSK ve KBSK’nin geldiği gözlemlenmektedir. Aynı zamanda 10-3 bit hata oranında 1,4 MHz ve 20 MHz bant genişlikleri arasında BSK’nin 1,1 dB, KBSK’nin ise 0,8 dB’lik bir enerji farkının olduğu gözlemlenmiştir. Bu verilerden yola çıkarak 20 MHz’lik bant genişliğinde daha az enerjiyle 1,4 MHz’lik bir sistemdeki bit hata oranına sahip olunabildiği görülmektedir.

Şekil 4’de 1,4 MHz bant genişliğinde 16 QAM ve 64 QAM modülasyon uygulandığında BSK, KBSK, TTSK ve ÇTSK’nin bozucu etkilerini göstermektedir. Buna göre 10 dB SJNR değerinde 16 ve 64 modülasyon teknikleri karşılaştırıldığında, 16 QAM modülasyonunda BSK 1,072x10-3, KBSK 2,63x10-3, TTSK 0,4907 ve ÇTSK ise 0,4287 BER değerlerine sahip iken, 64 QAM modülasyonda BSK 3,162x10-2, KBSK 1,13x10-1, TTSK 0,47 ve ÇTSK 0,49 BER değerlerine sahiptir. Yani 16 QAM modülasyon tekniğinde tüm kanal bozucuların etkisinin en az olduğu görülmüştür.

Bunun nedeni ise 16 QAM modülasyon tekniğinde yıldız kümesi diyagramında her bir sembolleri arası mesafenin 64 QAM modülasyona göre daha geniş olmasıdır. Ayrıca 15 dB SJNR ve 20 dB SJNR değerinden sonra BSK ve KBSK uygulandığında 64 ve 16 QAM modülasyon BER performansları yakınsamaktadır. Yani bu değerlerden sonra sinyal

gücü arttırılsa bile verimlilik değişmediği ve doyum noktasına ulaştığı görülmektedir. TTSK ve ÇTSK kanal bozucu teknikleri arasında ise 21 dB SJNR değerinden sonra 16 QAM ve 64 QAM modülasyon teknikleri için 10-1 BER değerinde yaklaşık 1 dB’lik enerji farkı oluşmaktadır.

Şekil 3 Sinyal karıştırıcılar altında LTE-A’nın 1,4 MHz ve 20 MHz bant genişlikleri için BER-SJNR performansı

SONUÇ

REFERANSLAR

LTE-A ticari kullanım amacıyla geliştirilmiş bir standart olmasına karşın kritik alanlardaki haberleşme sistemlerinde de kullanılması planlanmaktadır. Bu çalışmada temel amaç, LTE-A’nın sinyal karıştırıcılar altında performanslarını inceleyerek, ticari olarak geliştirilmiş olan bu standardın güvenilirliğine dikkat çekmektir. Bu amaçla yapılan analizler neticesinde LTE-A’nın fiziksel kanalında ÇTSK ve TTSK düşük bant genişliği ve yüksek modülasyon katsayılarında benzer özellikler göstermesine karşın ÇTSK’nin

diğer durumlarda sırası ile TTSK, BSK ve KBSK karıştırıcılarından daha fazla sinyal karıştırıcı etkiye sahip olduğu gözlemlenmiştir. Sonuç olarak LTE-A sahip olduğu birçok teknik avantajına rağmen, sinyal karıştırıcılardan etkilenebilmektedir. Bu sebeple kullanım amacının giderek çeşitlendiğini göz önünde bulundurularak gelecekteki sürümlerinde sinyal karıştırıcılara karşı bağışıklığının daha da artırılması gerektiği gözlemlenmiştir.

1. İnternet: Avustralya hükümeti verimlilik komisyonu raporu. (2015). Public safety mobile broadband research report. URL: http://

www.webcitation.org/query?url=https%3A%2F%2Fwww.pc.gov.au%2Finquiries%2Fcompleted%2Fpublic-safety-mobile-

broadband%2Freport%2Fpublic-safety-mobile-broadband.pdf&date=2018-04-01. Son Erişim Tarihi: 28.03.2018.

2. İnternet: Mission critical application enabled by LTE network. (2016). Huawei Technologies Co., LTD. URL: http://www.webcitation.

org/query?url=http%3A%2F%2Fwww-file.huawei.com%2F-%2Fmedia%2FCORPORATE%2FPDF%2Fmbb%2Fmission_critical_

application_enabled_by_lte_network.pdf%3Fla%3Den&date=2018-03-28. Son Erişim Tarihi: 28.03.2018.

3. Mshvidobadze, T. (2012, October). Evolution mobile wireless communication and LTE networks. 2012 6th International Conference

on Application of Information and Communication Technologies (AICT), Tbilisi, Georgia.

4. İnternet: Evolved universal terrestrial radio access (E-UTRA), multiplexing and channel coding. (2017). URL: http://www.webcitation.

org/query?url=http%3A%2F%2Fwww.etsi.org%2Fdeliver%2Fetsi_ts%2F136200_136299%2F136212%2F14.02.00_60%2Fts_13621

2v140200p.pdf&date=2018-03-28. Son Erişim Tarihi: 28.03.2018.

5. İnternet: Evolved universal terrestrial radio access (E-UTRA), Physical Channels and Modulation Version. (2011). URL: http://www.

webcitation.org/query?url=http%3A%2F%2Fwww.etsi.org%2Fdeliver%2Fetsi_ts%2F136200_136299%2F136211%2F10.00.00_60%

2Fts_136211v100000p.pdf&date=2018-03-28. Son Erişim Tarihi: 28.03.2018.

6. Jun, L., Andrian, J. H., and Zhou, C. (2007, April). Bit error rate analysis of jamming for OFDM systems. 2007 Wireless

Telecommunications Symposium, Pomona.

7. Shahriar, C., Sodagari, S., Mcgwier, R., and Clancy, T. C. (2013, June). Performance impact of asynchronous off-tone jamming

attacks against OFDM. 2013 IEEE International Conference on Communications (ICC), Budapest.

Şekil 4 Sinyal karıştırıcılar altında LTE-A’nın 16 QAM ve 64 QAM modülasyonlarında BER-SJNR performansı


DÖRT ROTORLu İNSANSIZ HAVA ARAcI İÇİN OTOPİLOT VE GÜDÜM SİSTEMİ TASARIMI

MAKALE / HAVAcILIK

İnsansız hava araçları (İHA) pilot içermemeleri ve insan hayatı için tehlike arz eden ortamlarda etkin görev üstlenmeleri nedeniyle akademik, sivil ve askeri çalışmalarda önemli bir araştırma konusu haline gelmiştir. İnsansız hava araçları sabit ve döner kanatlı olmak üzere iki grup halinde kategorize edilmektedir. Sabit kanatlı hava araçları faydalı yük kapasitesinin

fazla olması ve daha uzun uçuş süresi imkanı tanıması nedeniyle tercih edilirken; döner kanatlı hava araçları yüksek manevra kabiliyeti, havada asılı kalma yeteneği ve dikey iniş-kalkış imkanı sağlamasıyla öne çıkmaktadır. Bu çalışmada dört rotorlu bir insansız hava aracının Newton-Euler denklemleri ile modellenmesi ve uçuş yönetim sistemi anlatılmaktadır.

Dört rotorlu bir hava aracı için temel olarak ‘+’ ve ‘x’ olmak üzere iki ayrı konfigürasyon seçeneği bulunmaktadır. Her iki konfigürasyonda da itme (thrust) ve sapma (yaw) dinamikleri benzerken, yuvarlanma (roll) ve yunuslama (pitch) dinamikleri farklılık göstermektedir. ‘+’ konfigürasyonuna sahip hava araçlarında yuvarlanma ve yunuslama dinamiklerinden yalnızca iki motor sorumluyken, ‘x’ konfigürasyonunda tilt moment üretimi için araç

üzerindeki 4 motorun hepsi kullanılmaktadır. ‘x’ konfigürasyona sahip hava araçları, görüş alanı ön pervane ile kapanmayacağından kamera yerleştirip görüntü almak için daha uygundur. Keşif ve gözlem görevlerine elverişli olması sebebiyle çalışmada hava aracının ‘x’ konfigürasyonu tercih edilmiştir. Hava aracına etki eden kuvvet ve torklar Şekil 1’de şematik olarak verilmiştir.

GİRİŞ

SİSTEM DİNAMİKLERİ

Şekil 1: Hava Aracına Etki Eden Kuvvet ve Torklar

Çalışmada uçuş denetimi için PID yöntemi tercih edilmiştir. PID denetleyiciler sisteme verilen referans giriş sinyali ile gerçek çıktı arasındaki hataya dayalı olarak çıkış sinyali üretmektedir. PID denetleyicideki P (proportional) teriminin artması sistemin yükselme süresini azaltırken, I (integral) teriminin artması kararlı durum hatasını düşürmektedir. Türevsel denetleyici D teriminin ise sistem kararlılığının artmasında ve üst aşımın azalmasında etkisi vardır.

Tek denetim sistemi döngüsünün aksine, iç içe geçmiş denetim sistemi döngüleri sistemin daha hassas

kontrol edilmesine imkan tanır. Ardışık döngüler sayesinde elde edilen kontrol sinyallerine kolaylıkla sınırlama koyulabilir. Ardışık döngülerin sağladığı esneklik ve hassasiyet avantajından dolayı, çalışmada Şekil 3’te verilen algoritma tercih edilmiştir. Oluşturulan yapıda u,v,w, ψ ifadeleri referans olarak seçilirken, P/PI/PID denetimciler ile sistemin kararlılığını artması ve istenilen spesifikasyonların sağlaması amaçlanmıştır. Kullanılan denetim döngüleri içten dışa doğru: açısal hız kontrolü (q,p,r), yönelim kontrolü (θ, ψ, ϕ) ve hız kontrolü (w, u, v) olarak sıralanmaktadır.

Sistem modeli oluşturulurken itki grubunu temsil etmek için matematiksel eşitlikler yerine test verilerinin kullanılması tercih edilmiştir. Kurulan test düzeneğinde motorlara farklı PWM değerleri gönderilmiş; itme, tork, devir, voltaj ve akım bilgileri kayıt altına alınmıştır. Düzenekten toplanan PWM-itme kuvveti ilişkisi MATLAB’ in polinomiyal eğri uydurma

fonksiyonları kullanılarak simülasyon modeline entegre edilmiştir. Ayrıca sürüklenme ve itme katsayılarının hesaplanması için yine test verilerinden yararlanılmıştır. Son olarak X ve Y eksenlerindeki jiroskopik momentler de hesaplanarak hava aracının matematiksel modeli tamamlanmıştır.

Konfigürasyon seçiminin ardından hava aracının matematiksel modeli aşağıda yer alan kabüller çerçevesinde Newton-Euler metodundan yararlanılarak çıkarılmış, sistem MATLAB/Simulink ortamında simüle edilmiştir.

• Sistem rijit ve simetriktir.

• Pervaneler rijittir.

• Sistemin ağırlık merkezi ile gövdeye sabitlenmişeksen takımı (body fixed frame) çakışıktır. Quadrotor 6 serbestlik dereceli bir sistem olup 12 adet durum (state) kullanılarak açıklanmaktadır. İlk 6 durum yönelim açılarını

(ϕ, θ, ψ ) ve bu açılardaki değişimi (p, q, r) ifade etmektedir. Diğer 6 durum ise dünya eksen takımına göre pozisyon (x,y,z) ve gövde eksen takımına göre hızları (u,v,w) ifade etmektedir. Quadrotor üzerindeki rotorlar gövdeye sabit olduğundan hava aracının eğim açısı, aracın yatay hareketi ile değiştirilmektedir. Bu nedenle, yuvarlanma (roll) ve yunuslama (pitch) momentlerinin oluşturulması için pervanelerdeki hız farkından yararlanılmaktadır. Hava aracının Y ekseni etrafındaki dönüşünün sağlanması için 1 ve 3. pervanelerin hızları artarken 2 ve 4. pervanelerin hızları azalmaktadır. Aracın Y ekseni etrafındaki yunuslama momenti Şekil 2’de şematik olarak gösterilmiştir.

OTOPİLOT TASARIMI

Şekil 2: Yunuslama (Pitch) Momentinin Üretimi

Burcu HatipoğluMekatronik Sistem Mühendisi / Mechatronic System EngineerLapis Havacılık Teknolojileri A.Ş. / Lapis Aerospace


Şekil 3: Denetim Döngüsü Şematiği

Şekil 4: Otopilot Simülasyon Modeli

Şekil 5: Güdüm Algoritması

Hava aracının yatay hızları (u,v) iç içe 3 kontrol döngüsü ile, sapma açısı (ψ) ise iç içe 2 kontrol döngüsü ile kontrol edilmektedir. Aracın dikey hız (w) kontrolü içinse tek bir denetim döngüsü kullanılmıştır.

Yukarıda verilen denetim sistemi şematiğine ek olarak, yükseklik kontrolü de oluşturularak otopilot algoritması tamamlanmıştır. Otopilot algortimasının simülasyon modeli Şekil 4’te verilmiştir.

Güdüm sistemi hava aracının üç boyutlu ortamdaki konumundan ayrılarak varması planlanan başka bir konuma mümkün olan en az hatayla ulaşmasını sağlamak için kullanılmaktadır. Güdüm algortiması sayesinde otopilot sistemine girdi oluşturacak kafa açısı, iki nokta arasındaki en kısa mesafe, uçuş süresi ve hız bilgisi gibi veriler elde edilmektedir.

Oluşturulan algortimada İHA’nın anlık konumu ile hedef nokta arasındaki en kısa mesafeyi bulmak amacıyla Haversine formülünden yararlanılmıştır. Ek olarak, kullanıcı tarafından sisteme verilen maksimum hız, hava aracı hedefe yaklaştıkça azaltılarak aracın hedef koordinatları ıskalaması engellenmiştir. Güdüm algoritmasının simülasyon modeli Şekil 5’te ki gibidir.

GÜDÜM SİSTEMİ TASARIMI

Şekil 6: Hava Aracı Simülasyon Modeli

Şekil 7: Hedef Takip Çıktısı

Oluşturulan model farklı koordinat, yükseklik ve hız girdileri altında sınanmıştır. Şekil 7’de 39° kuzey, 39° batı koordinatından yola çıkan hava aracının 3 farklı hedefe uğrayıp başlangıç noktasına geri dönerken

izlediği rota görülmektedir. Alınan sonuçlara göre hava aracı hedef koordinatlara maksimum 7 cm hata payı ile ulaşabilmektedir.

Hava aracından Şekil 7’de verilen hedef koordinatlara ulaşırken yüksekliğini 1020 metrede sabit tutması istenmiştir. Şekil 8’de hava aracının 1000 metre

yükseklikte bulunan ilk konumundan ayrılarak 1020 metre yüksekliğe tırmanışı görülmektedir.

Güdüm algoritması tasarımının ardından uçuş yönetim sistemi ile hava aracının matematiksel

modeli birleştirilerek Şekil 6’daki simülasyon modeli elde edilmiştir.

SONUÇLAR


Şekil 8: Yükseklik Çıktısı

Simülasyon ortamında elde edilen sonuçlar, hava aracının verilen referans girdileri başarılı bir şekilde takip ettiğini göstermektedir. İleriki çalışmalarda simülasyon modeline kullanılacak bataryanın

dinamikleri de eklenerek, uçuş testleri ile simülasyon çıktıları karşılaştırılacak ve kontrolcü katsayıları üzerinde ayarlama işlemi yapılacaktır.

1. S. Bouabdallah, “Design and control of quadrotors with application to autonomous flying,” Lausanne Polytechnic University, 2007.

2. D. Mellinger, M. Shomin, and V. Kumar, “Control of quadrotors for robust perching and landing,” in International Powered Lift

Conference, October 5-7, 2010, 2010.

3. M.S.Büyüksarıkulak, ”Autopilot design for a quadrotor”, METU, 2014.

KAYNAKLAR

1. INTRODUCTIONSimulink® Coder™ (formerly Real-Time Workshop™) is a toolbox used to generate and execute C and C++ code from Simulink models, MATLAB® func-tions and Stateflow® charts. The generated code can be used for real-time and non-real-time applications such as rapid prototyping, simulation acceleration and HIL (hardware-in-the-loop) testing. It is possible to tune and monitor the generated code running outside MATLAB and Simulink [1].

In this paper, we show how we utilize this technology to generate source code customized to the Siemens

SIMATIC S7-1500 Software Controller environment. At the end of such work, the SIMATIC Target 1500S™ has been brought into the use of industry.

2. CODE CUSTOMIZATION TECHNOLOGYThe Target Language Compiler (TLC) is an integral part of MathWorks® code generation technology used to produce C or C++ code and executables from MATLAB algorithms and Simulink diagrams. It enables you to achieve platform-specific code or to incorporate your own algorithmic changes for several purposes [3].

Halil Aydoğuş[email protected] Development Engineer Siemens

MAKALE / ENDÜSTRİ OTOMASYON

cuSTOMIZING THE REAL-TIME cOMPILER OF SIMuLINK cODER FOR SIEMENS SIMATIc

S7-1500 SOFTwARE cONTROLLER

www.figes.com.tr 30


Figure 1 shows how the target language compiler takes role within the whole code generation process. It is designed to transform the model description file (i.e. model.rtw) into target-specific code. This file is an intermediate form of a Simulink model containing a compiled representation of it. Real-Time Workshop also requires a template make-file specifying the appropriate compiler options in order to create a target-specific application [3]. However, we cut the process right at this step and instead use the SIMATIC ODK 1500S which is a specific tool for developing real-time library functions for S7-1500S software controllers. It is based on an Eclipse SDK and uses GCC cross compiler [4]. Details of using ODK 1500S are described in Chapter 4.

3. CUSTOMIZING BUILD PROCESSThe build process lets you control the flow and supply additional custom code in hook methods executed at specific points in the code generation and build process. Hook methods can be used to add customized actions to the generic build process. They can be modified in a function prototype referred to as STF_make_rtw_hook.m, where STF is the name of the customized TLC (i.e. the customized system target file).

Figure 2 lists the order in which the build process calls STF_make_rtw_hook with different arguments [2]. We customize the process at almost every step depending on requirements. For example, the after_make step is completely customized by including the ODK process. In order to register the interface for this customized process to MATLAB, the system target file is added to the Simulink customization file (i.e. sl_customization.m) so that the MATLAB can recognize it and let it to be used as a separate process.

4. GENERATING CUSTOMIZED CODE FOR THE S7-1500 SW CONTROLLERThe main motivation for the customization of the build process is the fact that the real-time side of an S7-1500S controller requires a specific shared object which can dynamically be loaded by a Step7 program during runtime. In order to obtain such an object, an ODK 1500S project is constructed by generating the following files:

•The body for the generated C++ source code (model.cpp)•Header files (model.h)•Header file defining parameters and data structures private to the generated code (model private.h)•An interface file defining necessary functions to build an ODK project (model_ODK.odk)•The body for the ODK functions defined in the interface file (model_ODK.cpp)•Source files required for external mode communication or any additional feature (see Chapters 6&7)

The first three items in this list are generated by the Simulink Coder itself while the other ones are generated by the customized TLC. After creating the project, the TLC process then triggers a build using an internal interface provided by ODK. At the end of this build, the following files necessary to run the simulation algorithm on an S7-1500S controller are obtained:

•Shared object file (model_ODK.so)•Program source file (model_ODK.scl)

Figure 1. Real-Time Workshop code generation process with target language compiler included

Figure 2. Templated build process provided by predefined hook methods

31ARGE Dergisi

Figure 3. General workflow for code generation using SIMATIC Target 1500S™

Figure 4. a. An example model in Simulink

www.figes.com.tr 32


Figure 4. b. The use of corresponding function block generated from this model in TIA Portal environment

Basic workflow for this process is shown in Figure 3. The shared object file contains the executable function which corresponds to the exact algorithm designed in the Simulink model and it must be stored in a S7-1500S controller. On the other hand, the external program source (i.e. the SCL file) definesinterface for a function block which has the same inputs and outputs as the Simulink model and it has to be called by a Step7 program [5]. Figure 4 shows an example Simulink model and its corresponding function block used in a Step7 program.

5. CONFIGURATION SET FOR THE TARGET ENVIRONMENTIn order to generate code compatible to the target environment, some configuration options are set to appropriate values by the customized TLC. The following table includes the values for major ones of these options:

In addition to these, we also offer a set of customized options about ODK runtime environment and options for enabling/disabling additional features provided. ODK-specific options are not the subject of this paper while additional features are discussed in Chapter 7.

6. TUNE PARAMETERS AND MONITOR SIGNALS DURING ExECUTION: ExTERNAL MODEExternal mode allows a host and a target to communicate over a specified protocol, where the host is the environment the MATLAB andSimulink execute and the target is the environment in which the executable created by the code generation and build process runs (i.e.S7-1500S SW controller in our case). The Simulink requests by transmitting messages to the target to execute parameters changes or to upload simulation data. The target responds by executing the host’s request. Figure 5 illustrates the client/server architecture this communication is based on [2].

We implemented a TCP/IP-based client/server communication for external mode. In order to use Simulink external mode over TCP/IP, we created an external in terface MEX-file for our target’s TCP/IP transport and implemented an information queue which is specific to the S7-1500S environment. As shown in Figure 6, the MEX-file (i.e. ext_comm) sends the requests to the target environment while the exe-cutable on the target side sends back an appropriate response or the simulation data requested.

Language

Solver type

Tasking mode of the real-time system

Device vendor

Device type

Byte ordering

Single output/update function

Code interface packaging

Classic call interface

MAT-file logging

External Mode transport layer

Static memory allocationforExternal Mode

C++

Fixed-stepSingle tasking

Intel

x86-32 (Windows32)

Little Endian

Enabled

Nonreusable function

Disabled

Disabledtcpip

Enabled

An innovative aspect of the implemented queue on the target is that we designed it to be thread-safe despite the default implementation provided by Simulink does not support a thread-safe mechanism. In this way, the simulation and the task sending data to Simulink can run on different threads, allowing the simulation thread to have a very fast cycle-time. Such a thread-safe mechanism is achieved by storing and accessing to simulation data in a non-blocking concurrent queue, which is a specialized version of the one proposed by Michael and Scott [6]. It has thus been possible to design it in a way that allows the Simulink engine to always get the latest simulation data from the target, preventing a possible lag between the actual signal state and its state observed on Simulink.

7. ADDITIONAL FEATURESIn TLC environment, the compiled model which corresponds to the description file mentioned in

Chapter 2 is accessed via a record named as Compiled Model. Through this object, the required information for additional features presented below is obtained and processed.

7.1 Complex Data TypesMultidimensional signals and structured data types (e.g. structures, arrays and bus objects) in a model require special care during code generation. A bus object, for example, can be considered as the Simulink representation for C++ structs. If a block is defined in a structured data type, a corresponding struct in ODK interface file is created for this so that a user can use it in a Step7 program with the same structural hierarchy. Moreover, we also support ‘complex numbers’ defined for bus objects or input/output parameters, having real and imaginary parts.

7.2 Access to Block Parameters and Internal SignalsParameters for model blocks can be accessed and modified over Simulink during external mode communication. However, we also provide an interface block to the user to read/write these parameters over Step7 program during model execution on an ODK-capable S7-1500S SW controller.

Users can also define measurement points in a model by naming the internal lines connecting the model blocks, for mainly debug purposes. We also provide an option to the user to include these signals in the generated model function block so that they become accessible on Step7 environment.

7.3. Referenced ModelsFor referenced models, the rtw hook steps in Figure 2 iterate recursively in dependency order for each referenced model. The generated code for referenced models is considered as an additional source. Therefore after_make step for a referenced model is omitted and the source code generated for all referenced models is incorporated within the ODK 1500S project generated at after_make step for the parent model.

8. SUMMARYSimulink® Coder™ provides an essential technology to industry because the large number of real customer systems works on specific hardware environments and requires the need for accelerated simulation, rapid prototyping and HIL testing. By adapt ing th is techno logy to S7-1500S SW controllers, we enable Siemens customers to easily and quickly implement their closed-loop control algorithms they design on Simulink environment.

www.figes.com.tr 34

Figure 6. TCP/IP-based client/server implementation for external mode

Figure 5. Host/Target communication channel for external mode


9. REFERENCES[1] The MathWorks, Inc. (2017). Simulink® Coder™ Getting Started Guide. Retrieved from https://www.mathworks.com/help/pdf_doc/rtw/rtw_gs.pdf.

[2] The MathWorks, Inc. (2017). Simulink® Coder™ User ’s Guide. Retr ieved f rom ht tps:/ /www.mathworks.com/help/pdf_doc/rtw/rtw_ug.pdf.

[3] The MathWorks, Inc. (2017). Target Language Compiler™ For Use with Real-Time Workshop® Reference Guide. Retrieved from https://www.mathworks.com/help/pdf_doc/rtw/rtw_tlc.pdf.

[4] Siemens AG. (2016). SIMATIC STEP 7 (TIA Portal) Options Open Deve lopment K i t 1500S V2 .0 Programming and Operating Manual. Retrieved from https://support.industry.siemens.com/cs/ww/en/view/109741218.

[5] Siemens AG. (2017). SIMATIC STEP 7 (TIA Portal) Options Target 1500S™ for Simulink® V1.0 Update 1 Programming Manual. Retrieved from https://support.industry.siemens.com/cs/ww/en/view/109741754.

[6] Michael, M. M., & Scott M. L. (1996). Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms. Retrieved from http://www.cs.rochester.edu/~scott/papers/1996_PODC_queues.pdf.

Remaining useful life (RUL) is the length of time a machine is likely to operate before it requires repair or replacement. By taking RUL into account, engineers can schedule maintenance, optimize operating efficiency, and avoid unplanned downtime. For this reason, estimating RUL is a top priority in predictive maintenance programs.

An RUL estimation model not only predicts RUL but also provides a confidence bound on the prediction. The model inputs are condition indicators, features extracted from sensor data or log data whose behavior changes in a predictable way as the system degrades or operates in different modes.

The method used to calculate RUL depends on the kind of data available:

• Lifetime data indicating how long it took for similar machines to reach failure

• Run-to-failure histories of machines similar to the

one you want to diagnose• A known threshold value of a condition indicator

that detects failure

Predictive Maintenance Toolbox™ provides models for estimating RUL from each type of data.

LIFETIME DATAProportional hazard models and probability distributions of component failure times are used to estimate RUL from lifetime data. A simple example is estimating the discharge time of a battery based on past discharge times and covariates, variables such as the environment in which the battery operated (such as temperature) and the load placed on it.The survival function plot in Figure 1 shows the probability that a battery will fail based on how long it has been in operation. The plot shows, for example, that if the battery is in operation for 75 cycles, it has a 90% chance of being at the end of its life time.

By Aditya Baru, MathWorks

MAKALE / ALTYAPI

THREE wAYS TO ESTIMATE REMAINING uSEFuL LIFE FOR PREDIcTIVE MAINTENANcE


RUN-TO-FAILURE DATAIf you have a database of run-to-failure data from similar components or different components showing similar behavior, you can estimate RUL using similarity methods. These methods capture degradation profiles and compare them with new data coming in from the machine to determine which profile the data matches most closely.

In Figure 2, the degradation profiles of historical run-to-failure data sets from an engine are shown in blue and the current data from the engine is shown in red. Based on the profile the engine most closely matches, the RUL is estimated to be around 65 cycles.

THRESHOLD DATAIn many cases, run-to-failure data or lifetime data was not recorded but you do have information on prescribed threshold values—for example, the temperature of a liquid in a pump cannot exceed 160oF (71oC) and the pressure must be under 2200 psi (155 bar). With this kind of information, you can fit time series models to condition indicators extracted from sensor data such as temperature and pressure, which rise or fall over time.

These degradation models estimate RUL by predicting when the condition indicator will cross

the threshold. They can also be used with a fused condition indicator that incorporates information from more than one condition indicator using techniques such as principal component analysis.

Figure 3 shows an exponential degradation model that tracks failure in a high-speed bearing used in a wind turbine. The condition indicator is shown in blue. The degradation model predicts that the bearing will cross the threshold value in approximately 9.5 days. The region shaded in red represents the confidence bounds for this prediction.

Figure 1. Survival function plot. At the end of 75 cycles, the probability of a battery’s continuing to operate is 0.1, or 10%.

Figure 2. Degradation profiles (blue) based on run-to-failure data. The distribution of the stars (or endpoints) of the nearest blue curves gives an RUL of 65 cycles

Figure 3. Degradation model for a high-speed bearing. The bearing has an estimated RUL of 9.5 days based on its current condition data (blue) and the exponential degradation model (red) fit to this data.

Once you have reliable estimates for RUL, you can integrate them into dashboards used by operators or incorporate them into alarm systems monitored

by maintenance teams. Teams can then respond to changes in equipment health as quickly as possible, and without affecting operations.


LauncherOne is Virgin Orbit’s two-stage launch vehicle for delivering small satellites into low earth orbit. To reduce costs and increase launch location flexibility, LauncherOne is designed to be air-dropped from a 747-400 carrier aircraft in flight. Each mission will entail several crucial separation events, including the separation of LauncherOne from its carrier aircraft, the first stage from the second, the fairing from the second, and the satellite payload from the second.

To ensure adequate clearance between separating

structures, engineers at Virgin Orbit used Simulink® and Simscape Multibody™ to model and simulate LauncherOne separation events. In addition to minimizing the risk of collisions, the simulation results are used to inform design decisions for the spacecraft structural components and separation mechanisms.

“We considered several modeling and simulation options, including open-source libraries and costly commercial software packages,” says Patrick Harvey, associate engineer at Virgin Orbit. “Simulink

“MATLAB and Simulink saved us about 90% on costs compared with the alternative we considered while giving us the coding flexibility to develop our own modules and fully understand the assumptions being made, which is essential when reporting results to other teams.”

Patrick Harvey, Virgin Orbit

MAKALE / KuLLANIcI HİKAYESİ

VIRGIN ORBIT SIMuLATES LAuNcHERONE STAGE SEPARATION EVENTS

Virgin Orbit’s LauncherOne vehicle assembled (top), with exploded view showing the fairing, payload, and first and second stages (bottom).

and Simscape Multibody provide the best of both options: the flexibility of open source—without the steep learning curve—and the confidence and time-savings advantages of commercial solutions—without the high cost.”

CHALLENGEWhen the structural design for LauncherOne was still in development, Harvey and his team had to account for a number of unknowns in the analysis of separation events, including the mass properties of each component as well as the forces and timing characteristics of the pneumatic and spring pushers used to initiate separations. The team needed to run thousands of Monte Carlo simulations while varying the values of these uncertain parameters to determine whether a specific parameter combination would cause a collision.

With so many simulations needed, the team wanted to automate the simulation process and to run simulations concurrently on multiple computing cores. With its existing simulation system incapable of automation or parallel processing, the team began looking for an alternative. Open-source solutions would take too long to verify and customize, while bespoke multibody dynamics simulation software packages were too costly and difficult to customize.

SOLUTIONVirgin Orbit engineers modeled and simulated LauncherOne stage and payload separation events with Simulink and Simscape Multibody, using Parallel Computing Toolbox™ to run simulations in parallel on multicore processors.

Working in Simulink with Simscape Multibody, the team constructed a preliminary model consisting of basic 3D shapes, including spheres, cones, and cylinders.

During these early simulations, they used 2D cross-sections and a 2D distance equation to measure clearances. They then implemented a Gilbert-Johnson-Keerthi (GJK) collision detection algorithm in MATLAB® to calculate the distance between 3D objects. The team based their implementation on an algorithm downloaded from MathWorks File Exchange.

Next, the group exported point clouds for the structural components from their CAD software. They created a MATLAB app that used the exported data for each component to create an equivalent 3D convex hull in Simscape Multibody.

After verifying the model via manually initiated simulations, the team created a second MATLAB app

that automates Monte Carlo simulations on multiple processing cores using Parallel Computing Toolbox.

This app reads 50 to 100 simulation parameters, along with their value distributions and limits, from a Microsoft® Excel® spreadsheet. It then runs up to 1000 simulations while varying parameter values, and saves the results—typically, several gigabytes of data—for postprocessing in MATLAB.

During postprocessing, the team examines any simulation scenarios in which components collided or passed within a threshold distance of one another, using the Mechanics Explorer tool in Simscape Multibody to visualize the physical movement of the components.

Simulation results are provided to Virgin Orbit hardware design engineers as well as to guidance, navigation, and control (GNC) engineers, who use Simulink to develop and simulate control algorithms.

The team is currently working on simulating the air-drop separation event, which will incorporate a model of aerodynamic forces and effects. The team is also refining the model based on results from floor tests of flight hardware in preparation for the spacecraft’s maiden launch.

RESULTS• Simulationscompleted10timesfaster. “With

Simulink and Simscape Multibody, we can employ simplifying assumptions and parallel processing to reduce simulation times from days to hours,” says Harvey. “Just as important, we can automate the simulations so they run in the background or overnight, and have the results waiting for us in the morning.”

• Simulation setup times cut by up to 90%. “Each simulation run involves setting up anywhere from 50 to 100 variables,” Harvey says. “We use MATLAB and Simulink to read these variables from a spreadsheet, which makes it easy to prepare the simulations and cuts setup times by a factor of 5 to 10.”

• Hardware designs informed by simulationresults. “We used results from Simulink simulations to inform decisions on bracket sizing and geometry changes,” says Harvey. “The results also help us understand which tolerances can be loosened to simplify manufacturing and which have to be tightened to ensure adequate separation clearances.”


When designing excavators, wheel loaders, haulers, and other construction equipment, engineers develop prototype versions of the machinery to evaluate performance, responsiveness, and operability. Building physical prototypes costs manufacturers millions of dollars and months of development time. Until recently, however, this was the only way to effectively understand the experience of operating a new machine.

Volvo Construction Equipment (Volvo CE) can now

evaluate new machine designs before a prototype is built. Volvo CE engineers built a real-time, human-in-the-loop simulator for construction machines using Simulink®, Simscape™, and Simulink Real-Time™. The Virtual Machine Simulator (VMS) gives operators realistic visual, auditory, and motion feedback during simulation.

“With Simscape and Simulink Real-Time we can simulate not only fuel economy and performance but also the feel of operating the machine—all before

“It was technically impossible for us to build a full-scale hydraulic system model to run in real time without Simulink, Simscape, and Simulink Real-Time. Our simulator enables us to test new concepts for construction equipment, tune parameters, reduce lead times, and minimize issues in the field.”

Jae Yong Lee, Volvo Construction Equipment

VOLVO cONSTRucTION EquIPMENT STREAMLINES PRODucT DEVELOPMENT wITH A REAL-TIME,

HuMAN-IN-THE-LOOP SIMuLATOR

Volvo Construction Equipment’s real-time, human-in-the-loop simulator.

MAKALE / KuLLANIcI HİKAYESİwe build a physical prototype,” says Jae Yong Lee, Chief Engineer at Volvo CE. “Evaluating operator experience through simulation is vital to making trade off decisions in the early stages of product development.”

CHALLENGEVolvo construction machines rely on sophisticated hydraulic systems comprising numerous valves, pumps, and pipes, as well as a control system and various sensors. These hydraulic systems must be matched with an appropriately sized engine and then optimized for performance and fuel economy by tuning controller parameters.

Volvo engineers knew that this complex task would be too costly to perform on physical prototypes, but they lacked a way to accurately simulate hydraulics in real time. Further, domain-specific simulation tools would enable them to simulate only individual subsystems, making it impossible to develop a full-scale simulator of a complete machine incorporating hydraulic, mechanical, electrical, and electronic subsystems.

The team needed tools that would enable them to model all subsystems in a single environment and perform real-time simulations of the complete system. This approach would let them make informed design trade off decisions that took into account not only performance and efficiency but also feedback from the operator driving the machine. A modeling and simulation environment that supported multiple domains was also essential to the company’s concurrent engineering approach, in which teams develop various subsystems of the final product in parallel and then converge on an optimal solution.

SOLUTIONVolvo CE engineers selected Simulink, Simscape, and Simulink Real-Time for the development of the VMS platform.The team modeled the main control valve, relief valves, swing motor, and hydraulic circuits of the first machine to be simulated—an excavator—with Simscape Fluids™ and Simscape. They then modeled the mechanical components, including the boom, arm, and bucket, with Simscape Multibody™.

Working in Simulink, the team created an engine model and then integrated it with the hydraulic, mechanical, and other subsystem models to create a model of the complete machine.

Using Simulink and Simulink Control Design™, they developed a controller model and performed closed-loop simulations with the machine model. They used MATLAB® to postprocess simulation results. They then refined the controller design based on their

analysis of system behavior in simulation, and verified the machine model with test data from an actual machine.

They generated C code from their models using Simulink Coder™, and used Simulink Real-Time to run the code concurrently on three target PCs from Speedgoat.

The real-time simulation platform is currently in use for excavator product development, and the company plans to use it to develop wheel loaders and articulated haulers, as well. The team recently added controller-in-the-loop and rapid control prototyping capabilities to the simulator to support software development and testing.

RESULTS• Number of prototypes reduced. “The

simulations that we run with Simulink and Simscape let us evaluate various design concepts and parameter values, reducing the risk of redesign later in the development cycle,” says Lee. “Once we identify an optimal design via simulation, we can build it. We anticipate a 30–50% reduction in prototype builds as a result.”

• Issuesinthefieldresolvedfaster. “Using the simulator, we can replicate any issue that arises in the field, troubleshoot the problem, and quickly find a solution,” says Lee.

• Controller tuned in simulation. “We refined the controller design by simulating the controller model with the machine model and analyzing system behavior,” says Lee. “Using this approach we reduced lead time for product development and increased product quality by covering a wide range of test scenarios.”


“MathWorks Consulting Services provided an automated environment that enabled our designers to verify control law software in accordance with DO-178C. They also showed us how to configure test harnesses for our models and taught us in detail how to modify the model to resolve problems.”

Youngshin Kang, Korea Aerospace Research Institute

KOREA AEROSPAcE RESEARcH INSTITuTE ADOPTS MODEL-BASED DESIGN TO DEVELOP DO-178c-

cOMPLIANT cONTROL LAw SOFTwARE

Development process for control law software based on DO-178C.

MAKALE / KuLLANIcI HİKAYESİThe Korea Aerospace Research Institute (KARI) recently adopted Model-Based Design with MATLAB® and Simulink® to develop and test DO-178C-compliant software for an automatic flight control system (AFCS) used in manned helicopters. Having no prior experience with Model-Based Design or DO-178C procedures, KARI engaged MathWorks Consulting Services to provide training and to set up an environment for DO-178C Level A development and verification.

“Carrying out control law design and software development in accordance with DO-178C without MATLAB and Simulink would have required a larger staff with considerable technical know-how and experience,” says Dr. Youngshin Kang, principal researcher on the flight control research team at KARI. “MATLAB and Simulink enabled us to complete this project on schedule even though we had never done one like it before.”

CHALLENGEOn similar projects in the past, the engineers who developed the control laws would pass their designs to operational flight program software developers for hand-coding and manual testing. Subtle misunderstandings between the control law designer and the software developer led to errors in the software, some of which went undetected until flight tests. KARI wanted to eliminate these kinds of errors by generating software directly from their design.

The helicopter AFCS project that KARI launched was the first of its kind in Korea. Recognizing the challenge that their limited experience posed, the team wanted expert assistance in setting up a development environment that supported code generation as well as automated verification and validation of their control law software in compliance with DO-178C guidelines.

SOLUTIONKARI engineers developed and verified the AFCS control law software using Model-Based Design with MATLAB and Simulink.

Before beginning development, the team received training on Model-Based Design from MathWorks Consulting Services. In addition to coaching and instruction, the consultants provided hands-on deployment support for a new development environment that enabled the team to automate code generation, verification, and validation.

Working in Simulink, KARI engineers developed a control law model that included submodels for basic stabilization control, external loop control, and mode authorization condition switching. This model

processed input from the helicopter’s pilot stick and sensors and then generated actuator displacement commands and mode change authorization signals.

The team combined the control law model with a nonlinear motion model of the aircraft and ran closed-loop simulations that included fault conditions for both actuators and sensors.

The engineers used MATLAB scripts to postprocess simulation results and produce detailed reports that included pilot inputs as well as the corresponding fuselage velocity, attitude, and actuator displacement.

Using the environment set up by the MathWorks consultants, the KARI engineers followed an automated verification and validation process. In this process, Simulink tools for verification and validation were used to perform model coverage analysis, detect design errors and dead logic, and check the model’s compliance with safety standards and high-integrity modeling guidelines, including DO-178C guidelines.

Simulink Test™ was used to manage and run requirements-based tests and create test harnesses that enabled the team to achieve 100% test coverage for each submodel in the control law model. The team then generated code from the validated control law model with Embedded Coder® and performed unit testing on the generated code.

The team is now preparing for hardware-in-the-loop simulations, a DO-178C audit, and flight tests of the control law software.

RESULTS• Softwaremodificationsquicklyimplemented.

“During the project, we often received urgent modification requests,” says Kang. “Thanks to the automated processes we put in place with Model-Based Design, we were able to reduce the time it takes for software modification by almost 50%.”

• Software defects reduced. “Because we generated code directly from the Simulink control law model with Embedded Coder, we eliminated the occurrence of software bugs caused by the misunderstandings that can arise between the control law designer and software developer,” Kang says.

• DO-178C verification automated. “DO-178C procedures are automatically reflected in our Simulink development and verification environment,” Kang says. “As a result, even developers who have no experience with DO-178C are able to meet the guidelines.”

www.figes.com.tr 48

Documents

ISSN: 2147 - Mühendislik | FLUENT| CFD FEA …Derin Öğrenme (Deep Learning), Nesnelerin İnterneti (Internet of Things) gibi alanlarda MATLAB&Simulink kapsamlı çözümler sunmaktadır