Data Distribution Unit (DDU) Mission Computer (Görev Bilgisayarı) ile diğer cihazlar (peripherals) arasındaki haberleşmeyi sağlayan kısımdır. Şeklen şöyle
Böylece şu işlevler sağlanır
1. Yalıtım
Görev Bilgisayarı, çevre birimlerinden yalıtılır
2. Farklı Cihazlar
Görev Bilgisayarına farklı cinste ve tipte çevre birimleri takılabilir
3. Yedeklilik (Redundancy)
Çevre birimlerinin yedekli olması sağlanabilir. DDU bir "windowing" kuralı uygulayarak (örneğin sinyal gücü, cihazın kalitesi, kullanıcı tercihi vs) aynı bilgileri veren farklı cihazlar arasında birisini tercih eder ve Görev Bilgisayarına bu cihaza ait bilgiyi gönderir. Eğer cihaz bozulursa, DDU otomatik olarak yedek cihaza geçer. Böylece Görev Bilgisayarında bir bozulma olmaz.
Mimari
Aslında DDU ile yazılım mimarilerinden birisi olan Hexagonal Architecture veya diğer ismiyle "Ports and Adapters" birbirlerine bayağı benziyorlar. Aslında Hexagonal Architecture ise çok daha genel bir mimaridir. Herhangi bir yerde kullanılabilir.
Fakat DDU genellikle kapalı sistemlerde kullanılır. Bu kapalı sistem gemi, uçak, araba gibi yazılım ağırlıklı bir sistemdir.
Çevre Birimleri
DDU terminolojisinden içinde çevre birimlerle haberleşmeyi sağlayan kısma
gibi bir isim verilir.-Peripheral Interface Unit (PIU),- System Interface Unit (SIU)
Data Distribution Unit Donanımı
DDU tercihen tek bir kutu şeklindedir. Çevre birimlerine çok farklı protokol ve kablolama ile bağlanırken, çekirdek tarafına çıkış veren arayüz standart ve çokça kullanılan bir şeydir.Veri Yapısı
Veri yapısı 3 başlık altında toplanabilir. Eğer Domain Driven Design kullanıyorsak şöyle gruplarız
Application Entities
1. PIU Entities
Bir PIU'dan gelen mesaj olduğu gibi, başka PIU'lara dağıtılır.
2. Mission Computer Entities
Mission Computer'a gönderilecek kayıtlardır
Domain Entities
1. System Entities
Failover, SubsystemState, Simulation Message Generation gibi logic içeren bilgilerin tutulduğu kayıtlar
2. Summary Entities. Bazı sistemlerde buna Data Reduction deniliyor.
PIU'lardan bir sürü veri akar. Bazı önemli alanları birleştirerek ekranda göstermek veya log'lamak isteyebilirim.
Tasarım Kuralı
Bence bu tür yazılımlarda Command Pattern bayağı kullanışlı.
1. Çevresel cihazdan gelen veri bir Command içinde işlenir.
2. Command entity'lere sadece yazma işlemi yapar. Command hangi entity tipini güncelleyeceğini bilir.
Örneğin bir Command sadece PIU kayıdını güncellerken, bir başka Command PIU, Summary Entity, Mission Computer kayıtlarının hepsini güncelleyebilir.
3. Entity'lere Listener takılır. Güncellenen entity bilgisi ile ne yapılacağı Listener'ın bileceği şeydir.
Command yazma işleminde şu entity'lerden bir veya bir kaç tanesini günceller.
1. PIU Entity Güncelleme
PIU Entity değerini güncelleyebilir. Yeni veri Listener aracılığıyla diğer PIU'lara yayınlanır. Eğer gerekiyorsa Failover kayıtlarına bakılarak, cihaz seçili veya etkinse, Mission Computer kayıları da güncellenir.
2. System Entity Güncelleme
System Entity aynı işi yapan bir veya daha fazla alıcıdan kuvvetli olanın tercih edildiği değerleri içerir. Bazen cihazlar yedeklidir, bazen de farklı cihazların kesişen işlevleri vardır. Örneğin hız hem GPS hem de Hız Ölçer ile ölçülebilir. Bu cihazlar arasında bir önceliklendirme koymak isteyebilirim. Böylece eğer çalışıyorsa hızı önce GPS ile ölçerim, eğer çalışmıyorsa Hız Ölçeri ile ölçmek isteyebilirim.
Tercih etme işi aslında bence DDS'teki Ownership Qos kullanımına benziyor.
3. Mission Computer Entity Güncelleme
Bazı bilgiler de görev bilgisayarına gönderilir. Gönderilen bilgi muhtemelen birden fazla cihazın bilgisinin bileşimini içeren bir mesaj şeklinde olacaktır.
4. Summary Entity Güncelleme
PIU'dan gelen bir sürü mesajı özet şeklinde ekranda gösterme veya loglama amacıyla kullanılır. Bu entity'ye takılan Listener gerekli işlemi gerçekleştirir.
Sınıf ve Mesaj İsimlendirme
DDU boru şeklinde olmasına rağmen çok katmanlı olabilir. Bu durumda sınıf isimlendirmesi önem kazanıyor.
Mesaj İsimleri
Mesaj isimleri XFromSensor, YToSensor şeklinde olabilir.
Konfigürasyon
Aynı tipte alıcılardan birden fazla varsa, her XFromSensor mesajına sourceDevice diye bir alan eklenebilir
DDU Int Bileşeni - Receive
network -> XFromSensorTopic -> XFromSensorTopicCommand -> XFromSensorTopicDTO
Yani : XFromSensorTopic okuyorsa ve DTO gönderiyorsa, command olarak XFromSensorTopicCommand çalıştırır. Burada DTO'ya dönüşüm olmasına rağmen önemsiz olduğu için command isminde belirtilmiyor.
DDU Core Bileşeni
XFromSensorTopicDTO -> XFromSensorCommand -> XRecordListener -> XRecordToSensorDTO
Yani : XFromSensorTopicDTO okuyorsa, command olarak XFromSensorCommand çalıştırır. Burada command ismi artık Topic, gibi şeyleri içermez, çünkü core işlemi yapmaktadır.
DDU Int Bileşeni - Send
XRecordToSensorDTO -> XRecordToSensorTopicCommand -> network
Yani : XRecordToSensorDTO okuyorsa ve topic gönderiyorsa, command olarak XRecordToSensorTopicCommand çalıştırır. Burada DTO'dan tekrar Topic'e dönüşüm olduğu için command isminde belirtiliyor.
Hiç yorum yok:
Yorum Gönder