=Paper=
{{Paper
|id=Vol-1483/46_Deneyim
|storemode=property
|title=ED Model Yapıtaşı Haberleşme Altyapısı
|pdfUrl=https://ceur-ws.org/Vol-1483/46_Deneyim.pdf
|volume=Vol-1483
|dblpUrl=https://dblp.org/rec/conf/uyms/YilmazCK15
}}
==ED Model Yapıtaşı Haberleşme Altyapısı==
https://ceur-ws.org/Vol-1483/46_Deneyim.pdf
ED Model Yapıtaşı Haberleşme Altyapısı
Aysun Sancar Yılmaz, Betül Baydemir Çankaya, Hande Doğan Köseoğlu
REHİS-EHGYM, Aselsan A.Ş. , Ankara
{asancar,baydemir,hdogan}@aselsan.com.tr
Özet. Elektronik Destek (ED) Model Yapıtaşı, Radar Elektronik Harp
projelerinde ihtiyaç olan veri yapısı ortaklığı, kontrol işlemci haberleşme ve
eğitim simülasyonu ihtiyaçlarını karşılamak için geliştirilen bir yapıtaşıdır.
Yapıtaşı, sistemde bulunan diğer yazılımlarla konfigüre edilebilir olarak OSGI,
ATA ve CORBA teknolojileri kullanarak haberleşebilmektedir. Bu çalışmada
ED Model Yapıtaşı haberleşme mimarisi aktarılacaktır.
Anahtar Kelimeler: Radar Elektronik Destek, OSGİ, Yazılım Mimarisi,
CORBA, ATA, Tasarım Kalıpları, Kullanıcı Arayüzü
1 Giriş
ED Model Yapıtaşı, radar elektronik destek kullanıcı arayüzü yazılımlarının temel
işlevleri olan yayınların tespiti, yayın parametrelerinin bulunması için yapılan detaylı
tespit, tespit edilen parametrelerin kaydı, yayın parametrelerine göre yayının kimlik
bilgisini belirlemek için kullanılacak veri dosyalarının yönetimi, yayınlar üzerinde
parametre bazlı filtreleme, yayınlara alarm üretme, sistem kalibrasyon işlemleri ve
eğitim simülasyon ihtiyaçlarını kontrol işlemci yazılımı ile haberleşerek karşılayan bir
yapıtaşıdır.
Benzer ED projelerinde Kİ birimiyle haberleşme ve senaryo yönetimlerinin
ortaklanmasını sağlama, ortak bileşenlerle daha hızlı ürün çıkarma çalışmaları
kapsamında alan analizi çalışmaları yapılmış, bu kapsamda ED Model Yapıtaşı ortak
bir katman olarak ED projelerinde kullanılmak üzere geliştirilmeye başlanmıştır.
Yapıtaşı servis tabanlı mimariye (Service Oriented Architecture) uygun olarak
geliştirilmiştir. Yapıtaşı birbirleri ile haberleşen servislerden oluşmaktadır. Bu
servislerin aranmasını, bulunmasını ve kullanılmasını sağlayan servis platformu
olarak OSGİ (Open Services Gateway Initiative)[1] kullanılmıştır. OSGİ platformu
çeşitli hazır yönetim servisleri sunmaktadır. Her bir servis bu yönetim servislerini
kullanarak servis kütüğüne kendi sunduğu servisleri kaydeder. Bu servisleri
kullanacak diğer servisler yine yönetim servislerini kullanarak istedikleri servisleri
servis kütüğünden sorgular, bağlanır ve kullanır. Servis kullanımı nesnelerin
metotlarını çağırmak şeklinde olur.
Yapıtaşı içinde geliştirilen bileşenlerin birbiri ile OSGİ altyapısı üzerinden
haberleşmesi yanı sıra veri akışını gerçeklediği kontrol işlemci yazılımı ile
haberleşme ihtiyacı bulunmaktadır. ED Model Yapıtaşı bu haberleşmeyi OSGİ, ATA
(Arayüz Tanımlama Aracı) [3] ya da CORBA (Common Object Request Broker
439
Architecture) [2] aracılığı ile gerçekleştirir. Bu makalede ED Model Yapıtaşının
haberleşme mimarisi aktarılacaktır.
2 ED Model Yapıtaşının Kapsamı
ED Model Yapıtaşı, OSGİ ortamında kendini ortama kaydeden java ‘plugin’
lerinden oluşmaktadır. Bu yapıtaşını kullanacak uygulamalar OSGİ ortamından
servisleri çekerek kullanıma alır. Yapıtaşının temel görevleri radar elektronik harp
destek projelerinde yer alan tespit, teşhis, kalibrasyon, kayıt, kimliklendirme kaynağı,
alarmlama, filtreleme ve ortak çalışma mesajlaşması (ED sisteminin diğer sistemlerle
haberleşmesi) gibi genel ed işlemlerini gerçeklemek (görev modu), bu yeteneklere ek
olarak da ortam simülasyonu yapmaktır. (eğitim modu)
Şekil 1'de ED Model servislerinin yer aldığı projenin çalışma ortamı
gösterilmektedir. OSGİ çerçevesinde bulunan kullanıcı arayüzü servisleri ED model
servislerini ortamdan alarak kullanırlar. Radeh Yönetim Servisi mod geçişlerini
yöneten servis olarak bir üst katmanda konuşlandırılmıştır. Bütün servis dış arayüzü
“RadehModelCekirdek” servisi üstünden sunulmaktadır. Bu sayede bağımlılıklar tek
bir elden yönetilir.
OSGi Çerçevesi
CESMO Haberleşme Servisi Kullanıcı Arayüzü Servisi
Seyrusefer Radeh Yönetim Servisi Log Servisi
yayın listesi
RADEH Servisleri
RadehModelCekirdek
Filtre Model Servisi Alarm Model Servisi
Tespit Model Detaylı Tespit Taktik Kayıt Model Kim. Kaynağı Model Kalibrasyon Model
Servisi Model Servisi Servisi Servisi Servisi
OrtakÇalışma Model Servisi
Kİ Servisleri
Tespit Model Kİ Detaylı Tespit Kİ Taktik Kayıt Kİ Kim. Kaynağı Kİ Kalibrasyon Kİ
OrtakÇalışma Model Kİ
Servisi Servisi Servisi Servisi Servisi
Şekil 1. ED Model Yapıtaşı Çalışma Ortamı Genel Görünümü
Kİ servisleri diye gösterilen kısım ise ED Model Yapıtaşının haberleştiği kontrol
işlemci arayüzünü belirtmektedir. Her bir kontrol işlemci arayüzü için bir bağlantı
kurulmaktadır. Şekil 2'de ED Model Yapıtaşının hem kendini kullanan Kullanıcı
Arayüzü hem de kontrol işlemci yazılımı ile kurduğu genel haberleşme yapısı
gösterilmektedir.
440
Kullanıcı Arayüzü Bileşen-
leri
OSGİ
ED MODEL
OSGİ,
CORBA,
ATA
Kontrol İşlemci Arayüzü
Şekil 2. ED Model Yapıtaşı Genel Haberleşme Yapısı
3 ED Model Yapıtaşında Kullanılan İlk Haberleşme Altyapısı
(FAZ 1)
ED Model Yapıtaşı elektronik harp projelerinde yer alan ortak kontrol işlemci (Kİ)
haberleşme ve senaryo ihtiyaçlarının ortaklanması amacıyla gerçeklenmeye
başlamıştır. Proje ilk defa hayata geçirildiğinde Kİ haberleşmesi CORBA altyapısı ile
yapılacağı için ilk sürüm olarak CORBA altyapısı kullanılmıştır. Makalede Faz 1
olarak bahsedilen altyapı ED Modelin CORBA kullanılarak yapılan tasarımıdır.
3.1 CORBA
CORBA , Object Management Group (OMG) tarafından oluşturulan farklı
platformlardaki sistemlerin haberleşmesi için geliştirilmiş ortak bir dildir. İşletim
sisteminden, dilden ve donanımdan bağımsız bir şekilde iletişimi sağlar. Bu
özellikleri sayesinde farklı ortamlarda koşabilen ve farklı dillerde geliştirilmiş
olabilen projeye özel kontrol işlemci yazılımlarının dış arayüz ile haberleşme
senaryolarında CORBA kullanılmıştır. CORBA, ‘IDL’[4] (interface definition
language) adı verilen mesajların yazılı olduğu dosyaları kullanır. Bu dosyalar ‘idl’
derleyicileri tarafından derlenip kodlamada kullanılacak kaynak kodlar oluşturulur.
ED Model Yapıtaşı java ortamında geliştirildiği için ‘idl’ derlemesi sonucu oluşan
java dosyaları ilk aşamada kullanıma alınmıştır.
441
Bu ‘idl’ dosyalarının diğer bir özelliği de Faz 2'de gerçeklenen ATA ve OSGİ
altyapısı için ortak kullanım dili sağlayacak olmasıdır.
3.2 İlk Tasarım
Bu mimaride, her bir Kİ bağlantısı CORBA üzerinden bağlantı kurup yönetir.
Yapıtaşının haberleşme seçeneği mevcut kontrol işlemci yazılımlarının CORBA
bağlantısını destekleyecek şekilde tasarlanmıştır.
Bir ED Model servisinin Kİ yazılımı ile haberleşmek için kullandığı tasarım kalıbı
Şekil 3’te gösterilmektedir.
Şekil 3. ED Model Yapıtaşı Faz 1 Haberleşme Tasarım Kalıbı
Bu tasarım kalıbına göre Kİ yazılımından mesaj alan sınıf “ModelSunucu” sınıfıdır
ve servis sınıfı olan “ModelSınıfı” sınıfını “IModelIcArayuz” arayüz sınıfı üzerinden
bilmektedir, doğrudan bir bağlantı kurulmamıştır. Benzer şekilde “ModelSınıfı” sınıfı
Kİ yazılımına mesaj göndermek amacıyla “IGomuluAdaptor” arayüzünü
kullanmakta, bu arayüzü gerçekleyen “GomuluAdaptor” sınıfına doğrudan bir erişimi
bulunmaktadır.
4 ED Model Haberleşme Altyapısı (FAZ 2)
ED Model Yapıtaşı bileşeninin farklı elektronik harp projelerinde farklı Kİ
bileşenleri ile haberleşme ihtiyacı doğmuştur. Makalede Faz 2 olarak bahsedilen ED
Model Yapıtaşı , OSGİ ve ATA arayüzleri ile Kİ haberleşmesini de gerçekleyecek
şekilde genişletilmiştir.
442
4.1 OSGİ
OSGİ, yeniden kullanılabilirliği destekleyen modüler yapıda bir mimari ile java
uygulamaları geliştirmeyi sağlayan bir çerçevedir.
Ed Model Yapıtaşı, OSGİ çerçevesi kullanılarak geliştirilmiştir. ED projelerinde,
zamanla değişen istekler ve ortamlar sonucunda kontrol işlemci yazılımları gömülü
kartlardan Windows ortamına alınmış, yazılım geliştirici ekibin de tecrübelerine
dayanarak OSGİ kullanılarak geliştirilmeye başlanmıştır. Kİ yazılımının OSGİ'de
geliştirilmesi sonucu, bu yazılımla haberleşecek ED Model Yapıtaşı yazılımının da
OSGİ arayüzü olması istenmiştir.
4.2 ATA
Arayüz Tanımlama Aracı (ATA), dağıtık birimler üzerinde çalışan yazılım
bileşenlerinin arayüzlerini bir arayüz modeli ile tanımlayan, tanımlanan arayüz
modeli üzerinden, ara katman kaynak kodu, arayüz dokümanı ve arayüzü test etmek
için çalıştırılabilir bir test aracı üreten Eclipse tabanlı bir araçtır. ATA, tanımlanmış
bir ATA arayüz modeli üzerinden ara katman kodu, çalıştırılabilir bir test aracı ve
yazılım arayüz tasarım tanımı dokümanı üretebilmektedir. Oluşturulan ara katman
kodu RPC[5] (Remote Procedure Call) mantığı ile çalışan bir katmandır. Oluşturulan
kod haberleşme protokolünden bağımsızdır. Üretilen ara katmanın kullanım yöntemi
Şekil 4’te verilmiştir.
443
Şekil 4. ATA Kullanım Yöntemi
Üretilen ara katmanın kullanılması için kullanıcının tek yapması gereken dış
arayüzden gelen mesajları ve senaryoları gerçeklemesidir.
444
4.3 Haberleşme Tasarımı
class tespit
IEDModel_Tespit
-instance
ATA_ModelSunucu
Thread
haberlesme::GomuluAdaptor::
BaglantiThread
ModelSunucu
-KIBaglantiThread «interface»
#ModelSunucu IGomulu
-Model
«interface» haberlesme::GomuluAdaptor
IModelIcArayuz
haberlesme::
haberlesme::ATA_GomuluAdaptor haberlesme:: OSGI_GomuluAdaptor
CORBA_GomuluAdaptor
Şekil 5. ED Model Yapıtaşı Faz 2 Haberleşme Tasarım Kalıbı
Kİ yazılımı ile haberleşen ED Model servislerinde kullanılan ortak bir haberleşme
tasarım kalıbı bulunmaktadır. Bu tasarım kalıbı Şekil 5’te verilmektedir. Bu tasarım
kalıbında “GomuluAdaptor” sınıfı sunucu nesnesine mesaj göndermek amacıyla
kullanılacak olan sınıftır. “GomuluAdaptor” sınıfı, gönderilecek mesajları içeren
“IGomuluAdaptor” arayüz sınıfı üzerinden model sınıfı tarafından kullanılacaktır.
Sunucu nesnesinden gelen mesajları alacak sınıf ise “ModelSunucu” sınıfıdır.
“ModelSunucu” sınıfı “IModelIcArayüz” arayüz sınıfı üzerinden model sınıfına
mesajları aktarır.
GomuluAdaptor sınıfından türeyen 3 adet sınıf bulunmaktadır. Bu sınıflarda ATA,
CORBA ve OSGI haberleşmesi için özelleşmiş kodlar bulunmaktadır. ED Model
servisleri konfigürasyondan ayarlanan haberleşme tipine göre ilgili “GomuluAdaptor”
nesnesi yaratılır. OSGI ve CORBA haberleşmesi için aynı nesne türleri
kullanılmıştır. CORBA tarafından kullanılan sınıflar ortaklık sağlaması açısından
OSGI haberleşmesinde de tercih edilmiştir. ATA haberleşmesi için gelen ve giden
mesajlar ayrı bir sınıf kümesi için tanımlanmış, bu sebeple sunucu tarafı ATA için
yeniden yazılmıştır. “ATA_ModelSunucu” sınıfına gelen mesajlar CORBA sınıf
tiplerine çevrilerek bundan sonra olan akış aynı olacak şekilde tasarım yapılmıştır.
ATA haberleşmesi için yapılan bu değişikliğin ana sebebi, haberleşme sağlanan Kİ
bileşenin ATA sınıf tiplerini kullanmasıdır. OSGI haberleşmesi için OSGI’de
geliştirilen Kİ yazılımı da ‘idl’den üretilen CORBA sınıflarını kullanmaktadır.
445
5 Sonuç
ED Model Yapıtaşı, 2008 yılından beri değişen ekiplerle beraber farklı ED
projelerinde kullanıma alınmıştır. Projelerdeki ihtiyaçlar ve talepler doğrultusunda
kendini son teknolojilere uygun olarak güncellemiş, şu an aktif olarak 5 projede
kullanıma alınmıştır. Bu projelerden biri ATA arayüzünü, 3 tanesi de OSGİ
arayüzünü kullanmaktadır. Bir projede de CORBA ile idamesi devam etmektedir. Kİ
ile haberleşmeler ‘idl’ arayüzü kullanılarak ortaklanmaktadır. Kullandığımız tasarım
kalıbı sayesinde yeni bir mesaj eklendiğinde ‘idl’ değişikliği yapılır, bu ‘idl’
değişikliği ATA için ayrıca derlenir, ‘idl’ için üretilen kodlar ve ATA için üretilmiş
yine ‘idl’den derlenen ‘jar’ projeye eklenerek haberleşmede değişen kısım hızlıca
eklenebilmektedir. Bütün türetilmeler ‘idl’ üzerinden olduğu için yapılacak hatalar
minimum düzeye indirgenmiştir.
Kullandığımız mimari ED Model Yapıtaşı için yeni bir altyapı ile Kİ
haberleşmesini destekleyecek durumdadır. “GömülüAdaptor” sınıfından türeyen yeni
bir sınıf yazmak hem mevcut yapıyı bozmayacak, hem de yeni bir haberleşme
entegrasyonunu sağlayacaktır.
Kaynaklar
1. www.osgi.org, OSGI Web Sayfası
2. www.corba.org, CORBA Web Sayfası
3. B. Kekeç,O. Karadeniz, “Arayüz Tanımlama Aracı”, UYMS,2013.
4. www.omg.org, Object Management Group Web Sayfası
5. A.D. Birrell, B.J. Nelson, ”Implementing remote procedure calls”, ACM Transactions on
Computer Systems 2, 1984.
446