Otomobil endüstrisi, birçok merkezi olmayan bilgi işlem biriminin bulunduğu bir mimariden, birden fazla işlevi az sayıda merkezi bilgi işlem biriminde birleştiren bir mimariye geçiyor. Bu mimari, kablosuz güncellemeler gibi yeni özellikler sunuyor.
AAOS SDV, çözüm sunmak için mevcut Android sistemini ve altyapısını kullanır. Ayrıca, OEM'ler erken geliştirme sürecini 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ı kullanmaz. Bunun yerine, tüm sistem işlevleri yerel olarak geliştirilir.
SDV Core esas 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 bir dağıtılmış sistem için tasarlanmıştır. Örneğin, SDV Core'un (veya türevlerinin) birden fazla örneğinin aynı çipte ya da 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 örneklerin herhangi birinde barındırılabilen hizmetler olarak uygulanmasıdır.
SDV Core, araç içi işlevler geliştirmek için gereken minimum işlevsellik kümesidir. Normal 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 ve maliyet tasarrufu sağlayabilecek çok çeşitli SoC'leri (çip üzerinde sistem) çalıştırmasına olanak tanıdığı için kasıtlı olarak yapılmıştır.
Ayrıntılı tasarım
Şekil 2. SDV Core'un ayrıntılı mimarisi.
SDV Core, Android'den türetildiği için mimarisi mümkün olduğunca Android ile uyumlu olmaya çalışı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 gerekli 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ında, Virtio cihazlarını destekleyen bir hiper yönetici çalıştırılıyor. Ayrıca hipervizör, Ethernet veya vsock, güç durumları ve blok cihazları uygulamalıdır. Ayrıca, hipervizör Android/Linux'u çalıştırmayı desteklemelidir.
Donanım açısından SDV Core, donanım sanallaştırma desteğine sahip bir CPU ve MMU'nun yanı sıra sistemin Ethernet üzerinden bağlı olduğunu varsayar. Sistemde GPU, IPU, CSI, medya motorları, ekran veya diğer otomotiv iletişim veri yolları (ör. CAN, LIN) bulunması gerekmez.
Android Base
SDV Core, Android'e dayalıdır ancak sistemi temel sistem işlevselliğine indirger ve SDV çalışma zamanı ortamını ekler. Bu nedenle SDV, GKI'yı, yerel sistem hizmetlerini (ör. adbd ve logd) ve sistem işlevlerini de kullanır ancak JVM, JVM tabanlı hizmetler veya sistem uygulamaları ya da JVM için uygulanan özellikler içermez.
Bu, SDV'nin Android'in güncelleme stratejisini ve bölüm düzenini de uyarlayacağı anlamına gelir. Benzer güvenlik şartlarına sahiptir ancak GUI'si yoktur.
GKI, sürücüler ve HAL
SDV Core kullanıcıları, Android 6.1 çekirdeği ile Android'in GKI çekirdeğini kullanır. GKI kullanmanın avantajı, yukarı akışta yapılan değişikliklerin sonunda Android'e yansıtılmasıdır. Ayrıca Android, filoda tek bir çekirdek kullanır. Örneğin, yamalar birden fazla satıcı çekirdeğine değil, merkezi olarak uygulanır.
Bu, SDV'nin kararlı bir çekirdek arayüzüne sahip olmasını da sağlar. Örneğin, güvenlik düzeltmeleri içeren yeni bir çekirdek dağıtıldığında bile GKI ile çalışan modüller olarak sürücüler 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 gerektirmeyen 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 ana depoya gönderilmesi gerekmez ancak GKI arayüzlerine göre derlenmesi gerekir.
SDV Core, Virtio uyumlu bir hipervizörün üzerine kurulduğunu varsaydığı için özellik destekleniyorsa sürücüler Virtio çekirdek modülleri olarak, desteklenmiyorsa 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 kombinasyonu, donanım soyutlamasına yol açar. Bu nedenle, SDV'de HAL'lere ihtiyaç duyulmaz ancak Virtio desteği eksik olduğundan bazıları yine de gereklidir. Örneğin, donanım tabanlı kriptografi için KeyMint HAL ve SDV VM'leri arasında onaylama için yakından ilişkili IRemotelyPrivisionedComponent HAL.
Ağ ve İletişim Yığını
Şekil 3. SDV Core Networking and Communication Stack.
Ağ oluşturma için SDV Core, sanal makineler arasında iletişim kurmak üzere vsock veya Ethernet'in kullanılabildiğini varsayar. Sanal makine içi iletişimde bağlayıcı gibi IPC mekanizmaları da kullanılabilir.
SDV, yalnızca hata ayıklama amacıyla seri iletişimi destekler.
Şekil 4. Hata ayıklama için SDV Core seri desteği.
SDV, tek bir misafir içinde 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. Uygulamanın kopya sayısını optimize etmesine olanak tanımak için sanal makineler 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 sıklıkta ağ trafiği için planlanmamıştır.
Ethernet
Ethernet, birden fazla SoC arasındaki iletişim için (ör. araç içi iletişim) kullanılır. Bu, sanallaştırılmış sistemler olabileceği gibi yerel sistemler veya eski ECU'lar da olabilir.
Araç ağı, mevcut tüm sistemleri tanımlamak için IPv4 adres alanının yeterli olacağı kadar küçüktür. Bununla birlikte, sistemin olası yukarı bağlantılar ve gelecekteki gelişmelerle uyumlu olmasını sağlamak için IPv4 ve IPv6 desteklenmelidir.
VLAN
VLAN, farklı alt ağların yalıtılmasına ve yerel ağların oluşturulmasına olanak tanıyan sanal ağ mimarileri oluşturma mekanizmasıdı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 desteklenir.
Veri Tüneli
Data Tunnel, SDV için yeni geliştirilmiş bir iletişim mekanizmasıdır. Pub/Sub modelini izleyen hızlı bir iletişim kanalı sunar. Örneğin, bir uygulama bir konu yayınlarken bir veya daha fazla uygulama bunu dinleyebilir. Dahili olarak, sanal makine içinde paylaşılan bellek ve FMQ (hızlı mesaj kuyrukları) ya da sanal makineler arasında iletişim kurmak için vsock veya Ethernet kullanılır.
(SDV) TBG'si
SDV RPC, bağlayıcıdan yararlanarak SDV için uzak prosedür çağrılarını 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 veya sanal makineler arası iletişim için vsock ya da Ethernet'i kullanır.
Çerçeveler
SOMEIP
SOMEIP, SDV olmayan sistemlerle iletişim kurmak için kullanılır. TCP ve UDP üzerine kurulmuştur ve özel donanım ya da sürücüler gerektirmez. Google bir referans uygulayacaktır.
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.
Tarafsız bölge
Sistemin daha az güvenilen bir bölümünden (ör. özel olarak yüklenmiş uygulamaların bulunduğu IVI) gelen saldırıları önlemek için sistemin bölümlerini yalıtmak amacıyla ağ, askerden arındırılmış bölgeler de dahil olmak üzere farklı bölgeler oluşturabilir. Uygulamada bu, alt ağların fiziksel veya mantıksal olarak ayrıldığı ve yalnızca izin verilen trafiğin bu sınırları aşabileceği anlamına gelir.
Bağlantı Yöneticisi
Android'de, soket bağlantılarını kendi başlarına açabilen uygulama ve hizmetlerin sayısı genellikle sınırlandırılır. Bunun yerine, bağlantıları açıp yönetmekten 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 temel özelliklerinden biri güncellenebilir olmasıdır. Yeni özellikler, Android sistem güncellemeleri ve APEX paketleri aracılığıyla SDV'nin kullanım ömrü boyunca yüklenebilir.
Android Sistem Güncellemeleri
Android, güncellemeleri yüklemek için zaten bir mekanizma sunar. Son sürümlerde A/B ve sanal A/B güncellemeleri kullanılır. SDV Core da bu mekanizmadan yararlanır. A/B güncellemeleri her bölümü iki kez oluşturur. Bu durum iki avantaj sağlar: Sistem arka planda güncellenebilir ve güncelleme başarısız olursa sistem, çalışmak için bilinen son sürüme geri dönebilir.
APEX Packages
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üklenebilen ve güncellenebilen küçük paketlere yerleştirme mekanizması olan APEX paketlerini de sağlar.
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ını kullanı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önetimiyle ilgili bazı Java kodlarından yararlanır. SDV Core'un, APEX paketlerinin dinamik olarak yüklenmesine olanak tanıyan 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 ile 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, söz konusu sanal makineler arasında koordinasyon gerektirir. Çünkü bu makineler birbirine veri bağımlıdır: Bu bölümleri güncellemek için birincil bir sanal makine olmalı ve diğer sanal makineleri güncellenen bölüm ve senkronizasyon hakkında bilgilendirecek bir mekanizma bulunmalıdır. Böylece, bilinen önceki çalışma durumunun bozulmaması için tüm sanal makineler aynı anda güncellenir.
Başlarken
Başlangıç Kılavuzumuzda kaynak kodu, Cuttlefish ile derleme ve başlatma hakkında ayrıntılı bilgiler verilmektedir.