Otomobil sektörü, birçok merkezi olmayan işlem biriminden oluşan bir mimariden, birden fazla işlevi birkaç merkezi işlem biriminde birleştiren ve kablosuz güncellemeler gibi yeni özellikler sağlayan bir mimariye geçiyor.
AAOS SDV, çözüm sunmak için mevcut Android sistemini ve altyapısını kullanır. Ayrıca OEM'ler, erken geliştirmeyi kolaylaştırdığı ve yeni test olanakları sağladığı için bulutta da çalışabilen çözümler arıyor.
Tasarım
Şekil 1. SDV Core mimarisi.
SDV Core için AAOS (SDV Core), Android tabanlı bir işletim sistemidir. Gömülü yapısı nedeniyle Android'in JVM yığınını uygulamaz, bunun yerine tüm sistem işlevleri yerel olarak geliştirilir.
SDV Core, öncelikli olarak sanallaştırılmış bir ortam için geliştirilmiştir ve bazı tasarım kararları bu entegrasyonu varsayar. Bununla birlikte, SDV Core'u yerel olarak çalıştırmak mümkündür ancak bu, diğer Android sürümlerine kıyasla daha fazla entegrasyon çalışması gerektirir.
SDV Core, yerel olarak dağıtılmış bir sistem için tasarlanmıştır. Örneğin, SDV Core'un (veya türevlerinin) birden fazla örneğinin aynı çipte veya birden fazla sistemde yan yana çalıştığını ve bir ağ bağlantısı üzerinden iletişim kurabildiğini varsayar. Bu nedenle, sistem mimarisinin temel bir yönü, işlevlerin örneklerden herhangi birinde barındırılabilecek hizmetler olarak uygulanmasıdır.
SDV Core, araç içi işlevler geliştirmek için gereken minimum işlev grubudur. Tipik bir hizmet birkaç sinyal alır, bunları işler ve sonucu diğer hizmetlerle paylaşır. Bu kapsam sınırlaması, SDV Core'un gelişmiş motorlar içermeyebilecek çok çeşitli SoC'leri (çip üzerinde sistem) çalıştırmasını ve maliyetleri düşürmesini sağladığı için bilinçli olarak yapılmıştır.
Ayrıntılı tasarım
Şekil 2. SDV Core'un ayrıntılı mimarisi.
SDV Core, Android'den türetilmiştir. Bu nedenle, mimarisi Android ile mümkün olduğunca uyumlu olacak şekilde tasarlanmıştır. Bu, SDV Core'un Android'deki GKI, sürücüler, HAL'ler ve temel kitaplıkları da kullandığı ve hizmet mimarisi için gereken bileşenleri eklediği anlamına gelir.
Aşağıdaki bölümlerde sistem bileşenleri ayrıntılı olarak ele alınacaktır.
Ana makine ortamı ve sanallaştırma
SDV Core, sanal bir ortamda çalışacağı varsayılarak geliştirilmiştir. Bu nedenle, ana makine ortamıyla ilgili bazı varsayımlarda bulunuruz:
Ana makine ortamı, Virtio cihazlarını destekleyen bir hipervizör çalıştırır. Ayrıca hipervizör; Ethernet veya vsock, güç durumları ve blok cihazları uygulamalıdır. Ayrıca hipervizör, Android/Linux çalıştırmayı desteklemelidir.
Donanım açısından SDV Core, donanım sanallaştırma desteğine sahip bir CPU ve MMU olduğunu ve sistemin Ethernet üzerinden bağlandığını varsayar. Sistemde GPU, IPU, CSI, medya motorları, ekran veya diğer otomotiv iletişim veri yollarının (ör. CAN, LIN) bulunması gerekmez.
Android Base
SDV Core, Android'i temel alır ancak sistemi temel sistem işlevlerine indirger ve SDV çalışma zamanı ortamını ekler. Bu, SDV'nin GKI, yerel sistem hizmetleri (ör. adbd ve logd) ve sistem işlevlerini de kullandığı ancak JVM, JVM tabanlı hizmetler veya sistem uygulamaları ya da JVM için uygulanan özellikleri içermediği anlamına gelir.
Bu, SDV'nin Android'in güncelleme stratejisini ve bölüm düzenini de uyarlayacağı anlamına gelir. Benzer güvenlik gereksinimleri vardır ancak GUI'si yoktur.
GKI, Sürücüler ve HAL
SDV Core, Android 6.1 çekirdeği ile Android'in GKI çekirdeğini kullanır. GKI kullanmanın avantajı, upstream'e eklenen değişikliklerin Android'e de eklenmesidir. Ayrıca Android, tüm cihazlarda tek bir çekirdek kullanır. Örneğin, yamalar birden fazla tedarikçi çekirdeği yerine merkezi olarak uygulanır.
Bu sayede SDV, kararlı bir çekirdek arayüzüne de sahip olur. Örneğin, sürücüleri, güvenlik düzeltmeleri içeren yeni bir çekirdek dağıtıldığında bile GKI ile çalışan modüller olarak derleyebilirsiniz.
GKI çekirdeğinin sabit bir zaman çizelgesi vardır. Bir sonraki GKI çekirdeğinin parçası olması gereken tedarikçi değişiklikleri, yıl sonuna kadar Linux çekirdeğine aktarılmalıdır.
GKI ile cihaz sürücüleri ve başlatma için gerekli olmayan modüller çekirdek modülleri olarak derlenir ve erken başlatma sırasında yüklenen bir ramdisk'te yer alır.Çekirdek modülü arayüzünü bekleyemeyen çok erken cihaz yapılandırmaları (ör. rastgele başlatma) cihaz ağacında yapılmalıdır. Çekirdek modüllerinin yukarı akışa dahil edilmesi gerekmez ancak GKI arayüzlerine göre derlenmesi gerekir.
SDV Core, Virtio uyumlu bir hipervizör üzerine inşa edildiğini varsaydığından sürücüler, özellik destekleniyorsa Virtio çekirdek modülleri olarak veya başka bir açık standart (ör. DICE için Open Profile ve güven için open-dice çekirdek sürücüsü) olarak sunulur.
Virtio (ve açık standartlar) ile hipervizörün bu kombinasyonu, donanım soyutlamasına yol açar. Bu nedenle, SDV'de HAL'lere çok az ihtiyaç duyulur ancak eksik Virtio desteği nedeniyle bazı HAL'ler hâlâ gereklidir. Örneğin, donanım tabanlı kriptografi için KeyMint HAL ve SDV sanal makineleri arasında onay için yakından ilişkili IRemotelyPrivisionedComponent HAL.
Ağ ve İletişim Yığını
Şekil 3. SDV Temel Ağ ve İletişim Yığını.
Ağ iletişimi için SDV Core, sanal makineler arasında iletişim kurmak için vsock veya Ethernet'in kullanılabildiğini varsayar. Sanal makine içi iletişimde bağlayıcı gibi IPC mekanizmaları da kullanılabilir.
SDV, seri iletişimi yalnızca hata ayıklama amacıyla destekler.
Şekil 4. Hata ayıklama için SDV Core seri desteği.
SDV, tek bir konukta iletişim modeline ve performans gereksinimlerine bağlı olarak birden fazla seçenek sunar.
Vsock
Vsock, birden fazla sanal makine veya ana makine ile sanal makine arasındaki yerel iletişim için tercih edilen kanaldır. Sanal makineler, uygulamanın kopya sayısını optimize etmesine olanak tanımak için birbirleriyle doğrudan vsock iletişimi kullanmalıdır.
Paylaşılan Bellek
Paylaşılan bellek yalnızca IPC (işlemler arası iletişim) için bir sanal makineyle iletişim kurmak amacıyla kullanılır ancak birden fazla sanal makine arasında iletişim kurmak için normal bir kanal olarak sunulmaz. Ana makine, konukla bilgi paylaşmak için paylaşılan belleği kullanabilir ancak bu, yüksek frekanslı ağ trafiği için planlanmamıştır.
Ethernet
Ethernet, birden fazla SoC arasındaki iletişim, yani araç içi iletişim için kullanılır. Bu sistemler sanallaştırılmış sistemler, yerel sistemler veya eski ECU'lar olabilir.
Araç ağı, IPv4 adres alanının mevcut tüm sistemleri tanımlayabileceği kadar küçüktür. Bununla birlikte, sistemin olası uydu bağlantıları ve gelecekteki gelişmelerle uyumlu olmasını sağlamak için IPv4 ve IPv6 desteklenmelidir.
VLAN
VLAN, farklı alt ağları izole etmeye ve yerel ağlar oluşturmaya olanak tanıyan sanal ağ mimarileri oluşturmak için kullanılan bir mekanizmadır. Bu, farklı güvenlik bölgeleri oluşturmak için kullanılabilir ve arabalarda bu amaçla kullanılır. VLAN desteği gereklidir.
Protokoller
TCP ve UDP
Kullanım alanına bağlı olarak sistem, güvenilir veya güvenilir olmayan ancak hızlı bir iletişim protokolü gerektirir. Bu nedenle TCP ve UDP desteklenecektir.
Veri Tüneli
Data Tunnel, SDV için yeni geliştirilen bir iletişim mekanizmasıdır. Pubsub modelini izleyen hızlı bir iletişim kanalı sunar. Örneğin, bir uygulama bir konu yayınlarken bir veya daha fazla uygulama bu konuyu dinleyebilir. Dahili olarak, sanal makine içinde paylaşılan bellek ve FMQ (hızlı mesaj sıraları) kullanır veya sanal makineler arasında iletişim kurmak için vsock ya da Ethernet kullanır.
(SDV) RPC
SDV RPC, bağlayıcıdan yararlanan SDV için uzak prosedür çağrıları uygular. Uzak bir prosedürü çağırmak için önceden tanımlanmış bir API kullanır. Veri Tüneli'ne benzer şekilde, sanal makine içindeki iletişim için paylaşılan belleği, sanal makineler arası iletişim için ise vsock veya Ethernet'i kullanır.
Çerçeveler
SOMEIP
SOMEIP, SDV olmayan sistemlerle iletişim kurmak için kullanılır. TCP ve UDP üzerine kuruludur ve özel donanım veya sürücü gerektirmez. Google, referansı uygular.
Hizmet Keşfi Aracısı (SD Aracısı)
SDV'ye hizmet keşfi, kimlik doğrulama ve yetkilendirme sağlar. İletişim için daha önce bahsedilen yöntemlerden herhangi birini kullanabilir. Kimlik doğrulama ve yetkilendirme için SD aracısının güvenlik donanımına ve çalışan bir güven zincirine erişmesi gerekir.
Ara katman yazılımı
SDV, tüm bu farklı protokollerin kullanımını basitleştirmek için ara katman yazılımı adı verilen bir çerçeve geliştirir. Ayrıca, yeni bir dil olan VSIDL ile tüm araç sinyalleri için bir doğruluk kaynağı uygular.
Nötr bölge
Sistemin daha az güvenilir bir bölümünden (ör. özel yüklü uygulamalara sahip IVI) gelebilecek saldırıları önlemek için sistemin bölümlerini izole etmek amacıyla ağ, silahsızlandırılmış bölgeler de dahil olmak üzere farklı bölgeler sunabilir. Uygulamada bu, alt ağların fiziksel veya mantıksal olarak ayrıldığı ve yalnızca izin verilenler listesindeki trafiğin bu sınırları geçebileceği anlamına gelir.
Bağlantı Yöneticisi
Android'de, soket bağlantılarını kendileri açabilen uygulama ve hizmetlerin sayısını sınırlamak yaygın bir uygulamadır. Bunun yerine, bağlantıları açma ve yönetme işlemlerinden merkezi bir örnek sorumludur. Android bu işlevi bir Java hizmetinde uyguladığından SDV kendi bağlantı yöneticisini oluşturur.
Güncellenebilme durumu
SDV'nin en önemli özelliklerinden biri güncellenebilme durumudur. SDV'nin kullanım ömrü boyunca Android sistem güncellemeleri ve APEX paketleri aracılığıyla yeni özellikler yüklenebilir.
Android Sistem Güncellemeleri
Android'de güncellemeleri yüklemek için bir mekanizma zaten mevcuttur. Son sürümlerde A/B ve sanal A/B güncellemelerini kullanır. SDV Core da bu mekanizmadan yararlanır. A/B güncellemeleri her bölümü iki kez oluşturur. Bu sayede iki avantaj elde edilir: Sistem arka planda güncellenebilir ve güncelleme başarısız olursa sistem, bilinen son çalışan sürüme geri dönebilir.
APEX paketleri
Android, sistemi birden fazla bölüme ayırıp güncellenebilir hale getirmenin yanı sıra uygulamaları ve kitaplıkları sistem güncellemelerinden bağımsız olarak yüklenip güncellenebilen küçük paketlere yerleştiren bir mekanizma olan APEX paketleri de sunar.
SDV Core, hizmetleri bir SDV örneğine dinamik olarak yüklemek için APEX kapsayıcılarını kullanır. Ayrıca, birden fazla hizmetin tek bir işleme dağıtımını yönetmek için de APEX kapsayıcılarından yararlanır: Güvenlik risklerini azaltmak için yalnızca aynı APEX'te paketlenmiş ve aynı sertifikayı kullanan hizmetler aynı ikili dosyaya dağıtılabilir.
Android'in APEX paketlerini yükleme mekanizması, paketleri doğrulamak için APK yönetimine yönelik bazı Java kodlarından yararlanır. SDV Core'un, APEX paketlerinin dinamik olarak yüklenmesine olanak tanımak için yerel bir alternatif uygulaması gerekir.
Güncelleme Yönetimi
SDV örnekleri, araçta tamamen bağımsız birimler değildir ve diğer SDV örnekleri ve araç hizmetleriyle koordinasyon gerektirir. Örneğin, hizmet bağımlılıklarını yüklemek veya güncellemelerin yalnızca güvenli bir sistem durumunda yüklenmesini sağlamak için.
SDV, birden fazla sanal makinede bölüm kullanmayı değerlendirir. Bu işlem, sanal makineler arasında koordinasyon gerektirir çünkü sanal makineler arasında veri bağımlılığı vardır. Bu bölümleri güncelleyecek bir birincil sanal makine ve diğer sanal makineleri güncellenen bölüm hakkında bilgilendirecek bir mekanizma olmalıdır. Ayrıca, bilinen önceki çalışma durumunun bozulmaması için tüm sanal makinelerin aynı anda güncellenmesini sağlayacak bir senkronizasyon mekanizması da gereklidir.
Başlarken
Başlangıç Kılavuzumuzda, kaynak kodu ve Cuttlefish ile derleme ve başlatma hakkında ayrıntılı bilgi verilmektedir.