2026 SDV gündemi · Türkiye
Yazılım Tanımlı Araçlar: Zonal Mimari, OTA ve QNX
TARGET TechNews · Güncellendi
Yazılım tanımlı araç (Software-Defined Vehicle, SDV), işlevlerin yazılım yoluyla geliştirilebildiği ve araç tesliminden sonra güncellenebildiği yaklaşımı ifade eder. Dağıtık ECU'lardan zonal ve merkezi işlem platformlarına geçerken gerçek zamanlı çalışma, emniyet, siber güvenlik ve OTA yaşam döngüsü birlikte planlanmalıdır.
SDV projelerinde entegrasyon ve teslimat baskısı artıyor
QNX'in yayımladığı Under the Hood 2026 araştırması, dünya genelinde 1.100 gömülü otomotiv yazılım geliştiricisinin görüşlerini aktarır. Katılımcıların %80'i, şirketlerinin temel altyapı yerine uygulama katmanındaki yeniliklere daha fazla odaklanması gerektiğini belirtir. Aşağıdaki oranlar katılımcı görüşleridir; pazar büyüklüğü veya ürün performansı ölçümü değildir.
Ankete katılan mühendislikten sorumlu başkan yardımcıları (VPs of Engineering), OEM'lerin uygulama katmanındaki yeniliklere odaklanması gerektiği görüşünde.
UN R155 ile ISO/SAE 21434, siber güvenliği araç yaşam döngüsü boyunca ele alır; UN R156 ise yazılım güncellemeleri ve yönetimine odaklanır. Güvenli OTA; sürüm ve bütünlük kayıtlarını, araç uyumluluğunu, doğrulamayı, kontrollü kurulumu ve hata sonrası kurtarmayı kapsar. ISO 24089 kuruluş ve proje düzeyindeki çerçeveyi tanımlar. SOVD ile AUTOSAR Adaptive, servis tabanlı araç yazılımını destekler.
Anket verileri: QNX Under the Hood 2026. Entegrasyon karmaşıklığı ve platformlar arası ölçeklenebilirlik de iki ayrı yanıt başlığında %36 ile belirtilmiştir. Yazılım güncelleme mühendisliğinin kapsamı için ISO 24089 açıklamasını inceleyin.Dağıtık ECU'lardan zonal ve merkezi mimariye
SDV dönüşümü yalnızca ECU sayısını azaltmaz. QNX Board Support Package (BSP), karta ve işlemciye özgü başlatma kodlarını ve sürücüleri uygulama katmanından ayırarak donanım soyutlama sağlar. Desteklenen işlemci ailesi ya da tedarikçi değiştiğinde taşıma ve yeniden entegrasyon yükünü azaltabilir. Genel amaçlı işletim sistemleri birçok araç içi uygulama için yeterli olabilir. Emniyet açısından kritik işlevler ise deterministik davranış, sertifikasyon desteği ve kontrollü izolasyon gerektirir. Bu nedenle üreticiler, gerçek zamanlı çalışma ve farklı kritiklik seviyelerindeki iş yüklerini yalıtma (mixed-criticality virtualization) gereksinimleri için QNX OS® for Safety ve QNX Hypervisor for Safety 8.0 çözümlerine yönelir.
Fonksiyon başına ECU
Her işlev için ayrı donanım ve yazılım; yüksek entegrasyon yükü ve birbirinden kopuk güncelleme süreçleri.
İş yükü konsolidasyonu
Kokpit, ADAS ve gövde işlevlerinin alan denetleyicilerinde toplanması; kaynakların güvenle paylaşılması.
Merkezi ve güncellenebilir mimari
Merkezi araç bilgisayarları, servis tabanlı veri akışı ve yaşam döngüsü boyunca güncellenebilen işlevler.
QNX, Software-Defined Vehicles için gerçek zamanlı altyapı sağlıyor
QNX'in gerçek zamanlı işletim sistemi ve sanallaştırma çözümleri, ekiplerin temel altyapıyı yeniden geliştirmek yerine araç işlevlerine odaklanmasını kolaylaştırır. Doğru ürün ve varyant; işlemci platformu, emniyet hedefi, siber güvenlik kapsamı ve konsolidasyon planı birlikte değerlendirilerek seçilir.
Merkezi ve zonal işlem platformları için geliştirilmiş, yüksek performanslı ve safety-ready bir mikroçekirdek RTOS platformudur.
TÜV Rheinland tarafından ISO 26262 ASIL D kapsamında sertifikalandırılmış gerçek zamanlı bir işletim sistemi temeli sunar. Ayrıca ISO/SAE 21434 doğrultusunda risk değerlendirmesi, tehdit analizi ve güvenli geliştirme çalışmalarını araç yaşam döngüsü boyunca destekler.
Android tabanlı kokpit, genel amaçlı uygulamalar ve emniyet açısından kritik ADAS iş yüklerinin aynı SoC üzerinde yalıtılmış alanlarda birlikte çalışmasını sağlar. Buradaki emniyet sertifikasyonu standart QNX Hypervisor 8.0'ı kapsamaz. Konuk işletim sistemi ve hedef SoC desteği her proje için ayrıca doğrulanır.
QNX ve Vector'ın birlikte geliştirdiği Alloy Kore, yazılım tanımlı araçlar için önceden entegre edilmiş bir yazılım temeli sunar. Dağıtım, sürüm, lisans ve sertifika kapsamı proje değerlendirmesinde ayrıca doğrulanmalıdır.
SDV projesinde hangi QNX yazılım katmanı gerekir?
Zonal mimari bir işletim sisteminin adı değildir. İşlevlerin nerede çalışacağı, hangi kaynakları paylaşacağı ve nasıl güncelleneceği belirlenmeden ürün seçmek eksik bir değerlendirme oluşturur. Mevcut ürün görsellerini aşağıdaki görev ve kapsam ayrımıyla birlikte okuyun.
| Katman | Değerlendirme amacı | Doğrulanacak kapsam |
|---|---|---|
| QNX SDP 8.0 | Gerçek zamanlı uygulama geliştirme ve işletim sistemi temeli. | Hedef işlemci, BSP, sürücüler ve geliştirme araçları. |
| QNX OS for Safety | Emniyet gereksinimleri bulunan uygulamalar için sertifikalı OS bileşeni. | Ürün sürümü, sertifika ve entegrasyon kılavuzlarındaki koşullar. |
| QNX Hypervisor for Safety | Farklı konuk sistemleri ve kritiklik seviyelerini ayrıştırma. | Konuk desteği, kaynak tahsisi, cihaz paylaşımı ve hata davranışı. |
| Alloy Kore | QNX ve Vector bileşenlerini bir araya getiren temel araç yazılımı. | Dağıtım, sürüm, arayüzler, lisans ve sunulan sertifikasyon kapsamı. |
QNX ve Vector'ın 6 Ocak 2026 duyurusu, Alloy Kore için Early Access erişimini ve 2026 sonuna planlanan sertifikalı sürümü ayrı belirtir. Bu tarihli plan, her dağıtımın bugün sertifikalandırıldığının kanıtı değildir. Güncel paket ile sertifika belgeleri birlikte doğrulanmalıdır.
Donanım gelmeden geliştirmeye nasıl başlanabilir?
QNX Accelerate, desteklenen QNX yazılımlarını bulut hedeflerinde kullanmaya yönelik bir girişimdir; ayrı bir otomotiv sertifikası değildir. Bulut ortamı, uygulama geliştirme ve ekipler arası test paylaşımını fiziksel hedefin temininden ayırmaya yardımcı olabilir. Kullanılan OS sürümü, işlemci mimarisi ve marketplace teklifi eşleştirilmelidir.
- İlk olarak hedef işlevleri ve araç içi arayüzleri tanımlayın; donanıma bağımlı kısımları ayırın.
- Uygun bulut hedefinde uygulama ve arayüz testlerini hazırlayın; sürüm ve yapılandırmayı kaydedin.
- Hedef SoC/BSP üzerinde çevre birimlerini, kaynak paylaşımını ve zamanlama davranışını tekrar değerlendirin.
- Fiziksel sistemde performans, emniyet ve güncelleme doğrulamasını tamamlayın.
Bulutta çalışması, kodun her araç platformunda doğrulandığı anlamına gelmez. Başlangıç kapsamı için QNX Accelerate açıklamasını inceleyin.
Teknik görüşmeye hangi gereksinimler getirilmeli?
- Merkezi veya zonal bilgisayarda çalışacak araç işlevleri ve veri akışları.
- SoC/BSP seçimi, konuk işletim sistemleri ve zamanlama hedefleri.
- Emniyet hedefleri, siber güvenlik sorumlulukları ve tedarikçi sınırları.
- OTA paket uyumluluğu, doğrulama, başarısız güncellemeden kurtarma ve yaşam döngüsü beklentileri.
- Prototip ile üretim sürümü arasında kapatılacak test ve entegrasyon işleri.
Ürün seçeneklerini TARGET QNX portföyünde inceleyebilirsiniz. SAE sürüş seviyeleri ve ASIL D'nin neden farklı kavramlar olduğunu öğrenmek için otonom sürüş ve emniyet yazısına geçin.
SDV mimarinizi proje gereksinimlerinize göre değerlendirelim
Hedef araç işlevlerini, işlemci platformunu, emniyet seviyesini ve konsolidasyon yaklaşımını TARGET ile birlikte netleştirelim. Böylece projeniz için doğru QNX ürününü ve varyantını belirleyebiliriz.
