MODEL TABANLI SİSTEM MÜHENDİSLİĞİ YAKLAŞIMIYLA OTOMOTİV GÜVENLİK STANDARTLARININ ENTEGRASYONU
04/05/26 13:01
Otomotiv sektöründe yazılım miktarının hızla artması, güvenlik, siber güvenlik, bilgi güvenliği ve yazılım güncellemelerinin birbirinden bağımsız ele alınamayacağını göstermektedir. Önümüzdeki on yıl içinde araçlarda kullanılan yazılım satır sayısının bir milyar satırı aşacağı öngörülmektedir. Bu gelişme, ISO 26262 (fonksiyonel güvenlik), ISO/SAE 21434 (siber güvenlik), ISO/IEC 24089 (yazılım güncellemeleri) ve ISO/IEC 27001 (bilgi güvenliği yönetim sistemi) standartlarının bütünleşik bir yaklaşımla uygulanmasını zorunlu hale getirmektedir.
Bu çalışmada, ISO/IEC/IEEE 15288 yaşam döngüsü çerçevesi esas alınarak söz konusu standartların model tabanlı sistem mühendisliği (MBSE) yaklaşımıyla nasıl entegre edilebileceği incelenmiştir. Sistem mimarisi, gereksinim izlenebilirliği, varyant yönetimi, fonksiyonel testler (HIL, SIL, VIL) ve canlı testler MBSE kapsamında ele alınmış, entegrasyon matrisi ile süreçler arası ilişkiler gösterilmiştir. Ayrıca, dijital ikiz yaklaşımının güvenli güncelleme ve operasyonel izleme süreçlerine katkısı vurgulanmıştır.
Sonuç olarak MBSE, artan yazılım karmaşıklığını yönetmede yalnızca teknik değil, stratejik bir çözüm sunmaktadır. Bu entegrasyon, OEM’lerin güvenli, güncellenebilir ve sürdürülebilir otomotiv sistemleri geliştirmesine olanak sağlamaktadır.
1. GİRİŞ
Bağlantılı ve otonom araç teknolojilerinin yükselişi, otomotiv sektörünü yalnızca işlevsel güvenlik değil, aynı zamanda siber güvenlik, güncellenebilirlik ve bilgi güvenliği alanlarında da standartlara dayalı çözümler geliştirmeye zorlamaktadır.
Karayolu araçlarında kullanılan kod miktarı sürekli olarak artış göstermektedir. İçten yanmalı motorlu araçlarda görece daha düşük olan kod miktarı hibrit ve elektrikli araçlarda çok daha büyük miktarlara çıkmaktadır. Kod satırı olarak incelendiğinde günümüzde ortalama 10 – 50 – 100 milyon satır olarak kod miktarının 2035 yılında 30 – 100 – 150 milyon satıra yükselmesi ön görülmektedir.
2035 ötesi için ise milyar satırlar ifade edilmektedir.
Büyümenin Başlıca Nedenleri
- ADAS ve otonom sürüş sistemlerinin yaygınlaşması
- SDV (Software Defined Vehicle) mimarisine geçiş
- OTA (Over-the-Air) güncellemelerin standartlaşması
- Bulut bağlantısı, V2X iletişimi, mobil uygulamalar
- ISO/SAE 21434, ISO 24089 gibi standartların zorunlu hale gelmesi
Sonuç ve Etkiler
- Yazılım miktarındaki artış, saldırı yüzeyini genişletir.
- Siber güvenlik ve yazılım güncelleme yönetimi kritik hale gelir.
- Kod güvenliği, yaşam döngüsü yönetimi, test ve sertifikasyon süreçleri daha karmaşık hale gelir.
- OEM’ler için teknoloji ortaklarıyla (Nvidia, Bosch, Qualcomm, TI vb.) daha entegre bir çalışma gerektirir.
Şekil 1 Araç Türlerine Göre Tahmini Kod Satırı (milyon)
Bu durum da birbirleriyle etkileşen ve tüm sistem olarak aracın ve çevre birimlerinin doğru olarak çalışması ve görevini yerine getirmesini sağlamaya çalışan tüm bu yazılımların planlama, geliştirme, test, güncelleme dahil tüm yaşam döngüsünün sistemli olarak ele alınmasını zorunlu hale getirmektedir.
2. TANIMLAR VE KISALTMALAR
Bu bölümde bildiride geçen başlıca standartlar, kavramlar ve kısaltmalar açıklanmaktadır.
MBSE: Model Tabanlı Sistem Mühendisliği – sistemlerin dijital modeller aracılığıyla geliştirilmesi, izlenmesi ve doğrulanması yaklaşımı.
ISO/IEC/IEEE 15288: Sistem yaşam döngüsü süreçlerini tanımlayan uluslararası standart.
ISO 26262: Otomotiv fonksiyonel güvenlik standardı.
ISO/SAE 21434: Otomotiv siber güvenlik standardı.
ISO/IEC 24089: Araçlarda yazılım güncellemelerinin yönetimi için uluslararası standart.
ISO/IEC 27001: Bilgi güvenliği yönetim sistemi standardı.
OTA (Over-the-Air): Araç yazılımlarının kablosuz olarak güncellenmesini sağlayan yöntem.
HIL (Hardware-in-the-Loop): Gerçek donanımların simülasyon ortamında test edilmesini sağlayan yöntem.
SIL (Software-in-the-Loop): Yazılım bileşenlerinin sanal ortamda test edilmesini sağlayan yöntem.
VIL (Vehicle-in-the-Loop): Gerçek araç ile sanal trafik senaryolarının birlikte test edilmesini sağlayan yöntem.
Dijital İkiz: Gerçek sistemin sanal bir kopyası olup test, doğrulama ve güncelleme süreçlerinde kullanılır.
PSIRT (Product Safety Incident Response Team): Bir kuruluşun ürünlerinde veya hizmetlerinde ortaya çıkan güvenlik açıklarını ve siber olayları yönetmekle sorumlu uzman ekip.
2.1. İLGİLİ STANDARTLAR VE TEMEL ROLLERİ
- ISO/SAE 21434: otomotiv siber güvenliği - ISO 26262: fonksiyonel güvenlik - ISO/IEC 24089: yazılım güncellemeleri - ISO/IEC 27001: bilgi güvenliği
ISO 26262 12 standarttan oluşmaktadır. Bunların 2’si son revizyon ile 2018’de eklenmiştir.
ISO 26262:2018 – Road Vehicles — Functional Safety
1. Part 1: Vocabulary
Standardın genelinde kullanılan terimlerin ve tanımların açıklaması.
2. Part 2: Management of Functional Safety
Fonksiyonel güvenliğin yönetimi; organizasyonel yapı, sorumluluklar ve süreç yönetimi.
3. Part 3: Concept Phase
Konsept aşaması; tehlike analizi, risk değerlendirmesi (HARA), güvenlik hedefleri.
4. Part 4: Product Development at the System Level
Sistem düzeyinde ürün geliştirme; güvenlik gereksinimleri, sistem mimarisi.
5. Part 5: Product Development at the Hardware Level
Donanım geliştirme; hata toleransı, arıza oranı hesapları, güvenlik analizleri.
6. Part 6: Product Development at the Software Level
Yazılım geliştirme; güvenlik gereksinimleri, yazılım mimarisi, kodlama ve test.
7. Part 7: Production, Operation, Service and Decommissioning
Üretimden kullanıma, bakım ve servisten kullanım ömrü sonuna kadar güvenlik gereklilikleri.
8. Part 8: Supporting Processes
Konfigürasyon yönetimi, değişiklik yönetimi, doğrulama, kütüphaneler ve araçların güvenliği.
9. Part 9: Automotive Safety Integrity Level (ASIL)-oriented and Safety-oriented Analyses
ASIL tayini, güvenlik analizleri (FTA, FMEA, FMEDA).
10. Part 10: Guideline on ISO 26262
Standardın uygulanmasına yönelik rehberlik ve yorumlayıcı açıklamalar.
11. Part 11: Guidelines on Application of ISO 26262 to Semiconductors
Yarı iletkenler (mikrodenetleyiciler, ASIC’ler vb.) için özel uygulama rehberi.
12. Part 12: Adaptation of ISO 26262 for Motorcycles
Motosikletlere uyarlama; özel riskler, güvenlik hedefleri ve uygulama yöntemleri.
3. ENTEGRASYON STRATEJİSİ
Her bir standardın ISO 15288’deki yaşam döngüsü süreç gruplarına nasıl eşlendiği gösterilmiştir.
Bunun yanında tüm bu standartlar zaten bir arada çalışmak için tasarlanmış ve birbirlerine metin içinde ilişkilendirilmiştir.
ISO 24089 içinde normatif referans olarak; ISO 26262-6, ISO 26262-8 ve ISO/SAE 21434 verilmektedir.
Aynı şekilde ISO/SAE 21434’ün normatif referansı da ISO 26262-3’dür.
Yine aynı standardın Organizasyonel Siber Güvenlik Yönetimi bölümü (Madde 5) ISO/IEC 27001’e uygun bir yapılanmayı ön görmektedir.
Şekil 2 ISO/SAE 21434 Organizasyonu
Bu noktada bir olası yanlış anlamanın da önüne geçmekte fayda var: ISO 24089 sadece uzaktan (OTA, Over The Air) güncellemeleri değil tüm yazılım güncellemelerinin güvenliğini ilgilendiren bir standarttır. Madde 7.3.4’de kablolu (USB, Flash Drive, vb.,), kablosuz (GSM, Wi-Fi) veya donanım değişikliği ile yapılan tüm yazılım güncellemeleri kapsama dahil edilmektedir.
Şekil 3 Otonom Araç İçin Yazılım Güncelleme Senaryosu
4. SİSTEM MİMARİSİ VE GELİŞTİRME SÜRECİNDEKI ROLÜ
Sistem mimarisi, yalnızca bir teknik tasarım çıktısı değil, aynı zamanda bütün geliştirme sürecinin omurgasını oluşturan kritik bir entegrasyon noktasıdır. Otomotiv sektöründe güvenlik, siber güvenlik, güncellenebilirlik ve bilgi güvenliği gereksinimlerinin artması, sistem mimarisinin bu alanları birlikte ele alacak şekilde yeniden tanımlanmasını zorunlu kılmaktadır. ISO/IEC/IEEE 15288 yaşam döngüsü süreçleri dikkate alındığında, sistem mimarisi; kavramsal tasarımdan servisten çekmeye kadar tüm aşamaların sürekliliğini güvence altına alır.
Şekil 4 ISO/IEC/IEEE 15288 Sistem Yaşam Döngüsü Süreçleri
Modern araçlarda donanım, yazılım, haberleşme altyapısı ve bulut tabanlı servisler arasında karmaşık ilişkiler bulunmaktadır. Bu nedenle mimari, katmanlı bir yapı üzerinden ele alınmalı; donanım katmanı, işletim sistemi ve middleware, uygulama yazılımı ve kullanıcı etkileşim katmanı net biçimde ayrıştırılmalıdır. Bu katmanlar arasındaki etkileşimlerin modellenmesi, hem fonksiyonel güvenlik hem de siber güvenlik açısından kritik rol oynar.
Grady Booch’un da dediği gibi “Her sistem bir mimariye sahiptir. Bilinçli olarak veya kazayla”. Bu noktada önemli olan mimarinin ihtiyaç analizlerini, kısıtları, ilişkileri doğru değerlendirerek oluşturulmasıdır.
Örneğin, ISO 26262 kapsamındaki hata toleransı mekanizmaları, ISO/SAE 21434’te öngörülen tehdit modelleri ile birlikte mimari seviyede değerlendirildiğinde, çok daha bütünsel bir risk yönetimi elde edilebilir.
Şekil 5 MBSE Süreci - Otomotiv Güvenlik Entegrasyonu
Ayrıca sistem mimarisi, gereksinimlerin izlenebilirliği açısından da merkezî bir rol
üstlenmektedir. Bir güvenlik gereksinimi veya güncelleme politikası, mimari modelde ilgili bileşenle ilişkilendirildiğinde, değişikliklerin etkisi kolaylıkla takip edilebilir. Varyantların yönetimi de bu noktada önem kazanır; farklı araç modellerinde aynı mimarinin türevlerinin kullanımı, konfigürasyon tabanlı modelleme sayesinde mümkün olur. Bu sayede hem fonksiyonel güvenlik hedefleri hem de siber güvenlik önlemleri varyantlar arasında tutarlı biçimde korunur.
Şekil 6 Otomotiv Sistem Mimarisi Katmanları
Son olarak, mimari aşamada yapılan çalışmalar yalnızca geliştirme sürecini değil, fonksiyonel ve canlı testlerin etkinliğini de doğrudan etkiler. İyi tanımlanmış bir mimari, HIL, SIL ve VIL test senaryolarının daha erken aşamalarda hazırlanmasına olanak sağlar. Böylelikle MBSE yaklaşımı, sistem mimarisini geliştirme sürecinin merkezine yerleştirerek, standartların entegrasyonunu ve izlenebilirliği en üst düzeye çıkarmaktadır.
5. MODEL TABANLI SİSTEM MÜHENDİSLİĞİ (MBSE)
MBSE, mimariyi yalnızca görselleştirmekle kalmaz; aynı zamanda doğrulama, test ve güncelleme döngülerini de tek bir dijital ikiz üzerinden yönetir.
5.1 MBSE ADIMLARI VE STANDARTLARLA EŞLEŞTİRME
Sistemlere bütüncül bakışta gerek yazılım güvenliği, gerek bileşen güvenliği, gerek araç güvenliği veya sistem altyapısının baştan sona sistematik tasarımı ve yönetimi şarttır.
MBSE Adımlarına doğrudan atıflar, ilgili standartlarda aşağıdaki gibi yer almaktadır.
- Gereksinim Analizi: ISO/SAE 21434, ISO 26262 - Sistem Tanımı: ISO 24089, ISO/SAE 21434 - Doğrulama: ISO 26262, ISO/IEC 27001 - Güncelleme: ISO/IEC 24089
Bu doğrudan atıflar MBSE ile standartların yollarının kesiştiği yegane adımlar olarak değerlendirilmemelidir. Aşağıdaki eşleştirme tablosunda her standardın kendi içindeki adım ve metotların yaşam döngüsü sürecinde sistem mühendisliği ile örtüştüğü adımları göstermektedir.
Aşağıdaki tablo, ISO/SAE 21434, ISO 26262, ISO/IEC 24089 ve ISO/IEC 27001 standartlarının ISO/IEC/IEEE 15288 yaşam döngüsü süreçleri ile entegrasyonunu göstermektedir.
5.2 GEREKÇELENDİRME
MBSE yaklaşımı, farklı güvenlik standartlarının aynı platformda ele alınmasını sağlayarak bütüncül bir bakış açısı sunar. Geleneksel yöntemlerde fonksiyonel güvenlik, siber güvenlik veya yazılım güncellemeleri genellikle ayrı ayrı yönetilirken, MBSE sayesinde bu disiplinler arasındaki ilişkiler tek bir model üzerinde görselleştirilir ve izlenebilir hale gelir. Bu durum, gereksinimlerin çakışmasını azaltır ve güvenlik hedefleriyle siber güvenlik önlemlerinin tutarlı biçimde uygulanmasını mümkün kılar. Ayrıca dijital ikiz yaklaşımı, yazılım güncellemeleri ve güvenlik testlerinin sahaya çıkmadan önce sanal ortamda doğrulanmasına imkân tanır. Bu sayede hem zaman hem de maliyet açısından önemli avantajlar elde edilir. MBSE, yalnızca standartlara uyum sağlamakla kalmaz, aynı zamanda gelecekteki regülasyon değişikliklerine adaptasyonu da kolaylaştırır. Dolayısıyla, otomotiv yazılımındaki artan karmaşıklığın yönetilmesi için MBSE’nin gerekçesi, yalnızca teknik değil, aynı zamanda stratejik bir zorunluluk olarak ortaya çıkmaktadır.
Şekil 7 TARA Süreci
6. SİSTEM GELİŞTİRMEDE TESTLERİN ROLÜ
Geliştirilen sistemlerin, donanım ve yazılımların gerekli görevleri yerine getirip getirmediğinin kontrolü ancak sistematik doğrulama ile mümkündür.
Doğrulama Hedefleri:
– Maliyet, zamanlama ve performans gereksinimlerinin kabul edilebilir risk seviyeleriyle karşılandığından emin olmak için, en düşük seviyeden sistemin tamamına kadar fiziksel mimarinin doğrulanmasını sağlamak amacıyla belirlenmiş kriterleri kullanmak.
– Sistem tasarım çözümlerinde kullanılacak verileri üretmek ve teknolojileri doğrulamaktır.
Bu doğrulamayı sağlamanın en temel yöntemi ise testtir.
Test, sistemin belirtilen hedefleri (teknik performans, operasyonel etkinlik, operasyonel uygunluk) ne ölçüde karşıladığı, aştığı veya karşılayamadığı konusunda nesnel yargıların yapıldığı araçtır.
Değerlendirmenin amacı, sistematik kararlar almaya yardımcı olmak için testlerden ve diğer araçlardan elde edilen verileri incelemek, analiz etmek ve değerlendirmektir.
6.1. FONKSİYONEL TESTLER
Fonksiyonel testler, sistemin tasarım amaçlarına uygun şekilde çalışıp çalışmadığını ortaya koyar: - HIL (Hardware-in-the-Loop) - SIL (Software-in-the-Loop) - VIL (Vehicle-in-the-Loop) - Test Senaryosu Örnekleri: Acil frenleme, şerit takip, yazılım güncelleme sonrası fonksiyon kaybı kontrolü
6.2. CANLI TESTLER VE OPERASYONEL İZLEME
Fonksiyonel doğrulamanın ardından sistemlerin gerçek kullanım koşullarında güvenli çalışması için canlı testler kritik öneme sahiptir: - OTA Güncellemelerinin Testi - Siber Güvenlik Penetrasyon Testleri - Operasyonel İzleme - Saha Geri Bildirimi
7. SİSTEM YAKLAŞIMI
7.1. YAKLAŞIM VE MİMARİ: MBSE + V‑MODEL
Önerilen yaklaşım, SysML tabanlı bir MBSE modelinde gereksinimler, mimari, davranış ve doğrulama unsurlarını tek yerde toplayarak V‑Model boyunca uçtan uca izlenebilirliği kurar. V‑Model’in sol tarafında HARA, TARA, ISMS ve OTA risk etkinlikleri; sağ tarafında ise birim/entegrasyon/sistem testleri ve entegre assurance case yer alır. Temel prensip, riskten doğan her kararın bir gereksinime ve bir test kanıtına bağlanmasıdır.
Şekil 8 V‑Model’de standartların eşlemesi ve izlenebilirlik köprüleri.
7.2. ORTAK RİSK DİLİ VE BİRLEŞİK GEREKSİNİMLER KATMANI
ISO 26262 kapsamında HARA çıktıları güvenlik hedeflerine (Safety Goals) ve fonksiyonel/teknik güvenlik gereksinimlerine (FSC/TSC) dönüşür. ISO/SAE 21434’te TARA, siber güvenlik hedefleri ve konseptini oluşturur; bunlar siber güvenlik gereksinimlerine (CSR) ayrışır. ISO 27001’de ISMS riskleri, geliştirme ve operasyon bağlamında kontrol hedefleri ve Uygulanabilirlik Beyanı (SoA) ile yönetilir. ISO 24089’da OTA riskleri; paket güvenliği, bütünlük/doğrulama, dağıtım kampanyası güvenliği ve rollback kabiliyeti üzerinden ele alınır. Bu dört risk hattı birleşik gereksinimler katmanında birleştirilerek mimari bloklara allocate edilir ve test kapsamı ile ilişkilendirilir.
Şekil 9 HARA–TARA–ISMS–OTA iplikçiklerinin birleşik gereksinimlere akması
7.3. İZLENEBİLİRLİK VE ENTEGRE DOĞRULAMA ÖRNEĞİ
Modelde gereksinim ↔ risk ↔ mimari öğe ↔ test ↔ kanıt zinciri kurulur. Güvenlik (safety) ve siber güvenlik argümanları, hedef–strateji–kanıt (GSN) yapısı ile entegre bir assurance case altında derlenir. Denetim kanıtları ve regülasyon uyum çıktıları modelden otomatik veya yarı otomatik olarak üretilerek dokümantasyon maliyeti düşürülür ve tutarlılık artırılır.
Şekil 10 İzlenebilirlik matrisi ve sadeleştirilmiş GSN örneği
7.4. SÜREÇ ENTEGRASYONU: DEĞİŞİKLİK, TEDARİKÇİ, OLAY YÖNETİMİ
Değişiklik ve yapılandırma yönetiminde tekil CMDB/BOM/SBOM görünümü korunur; her değişiklikte ASIL, siber ve OTA etkileri birlikte değerlendirilir. Tedarikçi yönetimi; 26262 yetkinlik ve safety case girdileri, 21434 tedarikçi siber gereksinimleri, 24089 OTA uyumluluğu ve 27001 sözleşmesel kontroller ile bütünleştirilir. Ürün odaklı PSIRT süreçleri ile kurumsal ISMS olay yönetimi köprülenerek, sahadan gelen bulgular risk modeline geri beslenir.
7.5. KARAR KAPILARI VE ÇATIŞMA ÇÖZÜMÜ
Günlükleme ile gizlilik arasında denge, 27001’e uygun sınıflandırma ve en az gerekli veri ilkesiyle kurulur. Fail‑safe/fail‑operational tasarım kararlarında emniyet önceliklendirilirken, siber güvenlik kontrollerinin sistem davranışına etkisi analiz edilir. OTA kampanyalarında rollback kanıtı ve safety/siber risk onayı olmadan dağıtıma çıkılmaz; homologasyon gereklilikleri karar kapılarında doğrulanır.
8. GELECEK PERSPEKTİFİ VE STANDARTLARIN ENTEGRASYONU
Önümüzdeki on yıl içinde otomobillerde kullanılan yazılım satır sayısının 2025’te 100 milyon iken 2035 sonrası 1 milyar satırı aşacağı öngörülmektedir. Bu dramatik artış, yalnızca kodun miktarını değil, aynı zamanda yazılımın güvenlik yüzeyini de büyütmektedir. Dolayısıyla, fonksiyonel güvenlik (ISO 26262), siber güvenlik (ISO/SAE 21434), yazılım güncellemeleri (ISO/IEC 24089) ve bilgi güvenliği (ISO/IEC 27001) standartlarının entegrasyonu kaçınılmaz hale gelmiştir.
Şekil 11 Sektörel Uyum Haritası
Volkswagen Group, Technical Development bölümü tüm araç genelinde geliştirmenin sistematik yürütülebilmesi için bir MBSE konusunda çok ciddi yatırımlar yapmaktadır.
Teknik Geliştirmeden Sorumlu Yönetim Kurulu Üyesi Thomas Ulbrich bu durumu"Araba giderek elektrikle çalışan bir yazılım ürünü haline geliyorsa, gelişiminin de tüm boyutlarıyla gelişmesi gerekiyor. Süreçlerimizi ve organizasyonumuzu bileşenler yerine sistemlere ve işlevlere odaklayarak TD'yi daha bağlantılı ve daha verimli hale getiriyoruz. Önce donanım yerine yazılım. Bu, geliştirme sürelerimizi yüzde 25 oranında kısaltmamızı sağlayacak - gelecekte araç projeleri, temel yazılım mimarisinin yerleştiği noktadan itibaren 54 ay yerine 40 ayda tamamlanacak, Bu yıl, dönüşüm Wolfsburg'da planlanan Campus Sandkamp geliştirme merkeziyle Grup dışında da görünür hale gelecek. Campus Sandkamp'ı dünyanın en ileri teknolojiye sahip araç geliştirme merkezi yapmak için 800 milyon avro harcayacağız. Bu şekilde, TD'nin Volkswagen'i bir teknoloji şirketine dönüştürme hızını artırdığını vurguluyoruz," diye açıklamaktadır.
Hazırlanan entegrasyon matrisi, bu standartların ISO/IEC/IEEE 15288 yaşam döngüsü süreçleriyle nasıl kesiştiğini ve birbirini nasıl tamamladığını göstermektedir. MBSE, artan yazılım karmaşıklığını tek bir dijital ikiz ortamında yönetmenin anahtarıdır. Fonksiyonel testler ve canlı testler MBSE’nin içinde standartlara bağlanarak izlenebilir hale gelir. Sonuç olarak, otomotiv yazılımındaki büyüme, standartların entegrasyonu olmadan yönetilemeyecek bir karmaşıklığa doğru ilerlemektedir.
MBSE’nin bu standartlara uyumu çok hızlandıracak, ve uyumluluğun hızlı bir şekilde denetlenebilmesi mümkün olacaktır. Modelleme pratiğinin önemli olduğu otomotiv yazılımcılarının bu konuda gelişmesi gerektiğini, kullanabilecekleri tool’lar olduğunu yani bu işlerin soyut şeyler olmadığını, hemen eyleme geçebileceklerini de belirtmek isteriz.
9. SONUÇ
Bu bölümde, çalışmanın sonuçları kısa bir girişle özetlenmekte ve otomotiv sektöründe MBSE yaklaşımıyla standart entegrasyonunun geleceğe yönelik etkilerini vurgulayan ana fikirler madde madde sunulmaktadır.
- MBSE yaklaşımı, güvenlik, siber güvenlik ve yazılım güncellemeleri arasında köprü kurar.
- Otomotiv yazılımındaki artış, standart entegrasyonunu kaçınılmaz hale getirmektedir.
- Sistem mimarisi, gereksinim izlenebilirliği ve varyant yönetiminde kritik rol oynar.
- Fonksiyonel testlerin erken aşamada mimariyle ilişkilendirilmesi kaliteyi artırır.
- Canlı testler, güvenli OTA güncellemeleri ve operasyonel izleme ile desteklenmelidir.
- Entegrasyon matrisi, standartların süreçlerle ilişkisini net biçimde göstermektedir.
- OEM’ler için teknoloji ortaklarıyla entegre çalışma zorunlu hale gelmektedir.
- Dijital ikizler, güvenlik ve güncelleme doğrulamalarını hızlandırır.
- Standartlar arası çakışmalar MBSE ile en aza indirilebilir.
- Gelecekte güvenli yazılım geliştirme, entegrasyon odaklı MBSE yaklaşımıyla sürdürülebilir olacaktır.
Bağlantılı ve otonom araç teknolojilerinin yükselişi, otomotiv sektörünü yalnızca işlevsel güvenlik değil, aynı zamanda siber güvenlik, güncellenebilirlik ve bilgi güvenliği alanlarında da standartlara dayalı çözümler geliştirmeye zorlamaktadır.
Karayolu araçlarında kullanılan kod miktarı sürekli olarak artış göstermektedir. İçten yanmalı motorlu araçlarda görece daha düşük olan kod miktarı hibrit ve elektrikli araçlarda çok daha büyük miktarlara çıkmaktadır. Kod satırı olarak incelendiğinde günümüzde ortalama 10 – 50 – 100 milyon satır olarak kod miktarının 2035 yılında 30 – 100 – 150 milyon satıra yükselmesi ön görülmektedir.
2035 ötesi için ise milyar satırlar ifade edilmektedir.
Büyümenin Başlıca Nedenleri
- ADAS ve otonom sürüş sistemlerinin yaygınlaşması
- SDV (Software Defined Vehicle) mimarisine geçiş
- OTA (Over-the-Air) güncellemelerin standartlaşması
- Bulut bağlantısı, V2X iletişimi, mobil uygulamalar
- ISO/SAE 21434, ISO 24089 gibi standartların zorunlu hale gelmesi
Sonuç ve Etkiler
- Yazılım miktarındaki artış, saldırı yüzeyini genişletir.
- Siber güvenlik ve yazılım güncelleme yönetimi kritik hale gelir.
- Kod güvenliği, yaşam döngüsü yönetimi, test ve sertifikasyon süreçleri daha karmaşık hale gelir.
- OEM’ler için teknoloji ortaklarıyla (Nvidia, Bosch, Qualcomm, TI vb.) daha entegre bir çalışma gerektirir.
Şekil 1 Araç Türlerine Göre Tahmini Kod Satırı (milyon)
Bu durum da birbirleriyle etkileşen ve tüm sistem olarak aracın ve çevre birimlerinin doğru olarak çalışması ve görevini yerine getirmesini sağlamaya çalışan tüm bu yazılımların planlama, geliştirme, test, güncelleme dahil tüm yaşam döngüsünün sistemli olarak ele alınmasını zorunlu hale getirmektedir.
2. TANIMLAR VE KISALTMALAR
Bu bölümde bildiride geçen başlıca standartlar, kavramlar ve kısaltmalar açıklanmaktadır.
MBSE: Model Tabanlı Sistem Mühendisliği – sistemlerin dijital modeller aracılığıyla geliştirilmesi, izlenmesi ve doğrulanması yaklaşımı.
ISO/IEC/IEEE 15288: Sistem yaşam döngüsü süreçlerini tanımlayan uluslararası standart.
ISO 26262: Otomotiv fonksiyonel güvenlik standardı.
ISO/SAE 21434: Otomotiv siber güvenlik standardı.
ISO/IEC 24089: Araçlarda yazılım güncellemelerinin yönetimi için uluslararası standart.
ISO/IEC 27001: Bilgi güvenliği yönetim sistemi standardı.
OTA (Over-the-Air): Araç yazılımlarının kablosuz olarak güncellenmesini sağlayan yöntem.
HIL (Hardware-in-the-Loop): Gerçek donanımların simülasyon ortamında test edilmesini sağlayan yöntem.
SIL (Software-in-the-Loop): Yazılım bileşenlerinin sanal ortamda test edilmesini sağlayan yöntem.
VIL (Vehicle-in-the-Loop): Gerçek araç ile sanal trafik senaryolarının birlikte test edilmesini sağlayan yöntem.
Dijital İkiz: Gerçek sistemin sanal bir kopyası olup test, doğrulama ve güncelleme süreçlerinde kullanılır.
PSIRT (Product Safety Incident Response Team): Bir kuruluşun ürünlerinde veya hizmetlerinde ortaya çıkan güvenlik açıklarını ve siber olayları yönetmekle sorumlu uzman ekip.
2.1. İLGİLİ STANDARTLAR VE TEMEL ROLLERİ
- ISO/SAE 21434: otomotiv siber güvenliği - ISO 26262: fonksiyonel güvenlik - ISO/IEC 24089: yazılım güncellemeleri - ISO/IEC 27001: bilgi güvenliği
ISO 26262 12 standarttan oluşmaktadır. Bunların 2’si son revizyon ile 2018’de eklenmiştir.
ISO 26262:2018 – Road Vehicles — Functional Safety
1. Part 1: Vocabulary
Standardın genelinde kullanılan terimlerin ve tanımların açıklaması.
2. Part 2: Management of Functional Safety
Fonksiyonel güvenliğin yönetimi; organizasyonel yapı, sorumluluklar ve süreç yönetimi.
3. Part 3: Concept Phase
Konsept aşaması; tehlike analizi, risk değerlendirmesi (HARA), güvenlik hedefleri.
4. Part 4: Product Development at the System Level
Sistem düzeyinde ürün geliştirme; güvenlik gereksinimleri, sistem mimarisi.
5. Part 5: Product Development at the Hardware Level
Donanım geliştirme; hata toleransı, arıza oranı hesapları, güvenlik analizleri.
6. Part 6: Product Development at the Software Level
Yazılım geliştirme; güvenlik gereksinimleri, yazılım mimarisi, kodlama ve test.
7. Part 7: Production, Operation, Service and Decommissioning
Üretimden kullanıma, bakım ve servisten kullanım ömrü sonuna kadar güvenlik gereklilikleri.
8. Part 8: Supporting Processes
Konfigürasyon yönetimi, değişiklik yönetimi, doğrulama, kütüphaneler ve araçların güvenliği.
9. Part 9: Automotive Safety Integrity Level (ASIL)-oriented and Safety-oriented Analyses
ASIL tayini, güvenlik analizleri (FTA, FMEA, FMEDA).
10. Part 10: Guideline on ISO 26262
Standardın uygulanmasına yönelik rehberlik ve yorumlayıcı açıklamalar.
11. Part 11: Guidelines on Application of ISO 26262 to Semiconductors
Yarı iletkenler (mikrodenetleyiciler, ASIC’ler vb.) için özel uygulama rehberi.
12. Part 12: Adaptation of ISO 26262 for Motorcycles
Motosikletlere uyarlama; özel riskler, güvenlik hedefleri ve uygulama yöntemleri.
3. ENTEGRASYON STRATEJİSİ
Her bir standardın ISO 15288’deki yaşam döngüsü süreç gruplarına nasıl eşlendiği gösterilmiştir.
Bunun yanında tüm bu standartlar zaten bir arada çalışmak için tasarlanmış ve birbirlerine metin içinde ilişkilendirilmiştir.
ISO 24089 içinde normatif referans olarak; ISO 26262-6, ISO 26262-8 ve ISO/SAE 21434 verilmektedir.
Aynı şekilde ISO/SAE 21434’ün normatif referansı da ISO 26262-3’dür.
Yine aynı standardın Organizasyonel Siber Güvenlik Yönetimi bölümü (Madde 5) ISO/IEC 27001’e uygun bir yapılanmayı ön görmektedir.
Şekil 2 ISO/SAE 21434 Organizasyonu
Bu noktada bir olası yanlış anlamanın da önüne geçmekte fayda var: ISO 24089 sadece uzaktan (OTA, Over The Air) güncellemeleri değil tüm yazılım güncellemelerinin güvenliğini ilgilendiren bir standarttır. Madde 7.3.4’de kablolu (USB, Flash Drive, vb.,), kablosuz (GSM, Wi-Fi) veya donanım değişikliği ile yapılan tüm yazılım güncellemeleri kapsama dahil edilmektedir.
Şekil 3 Otonom Araç İçin Yazılım Güncelleme Senaryosu
4. SİSTEM MİMARİSİ VE GELİŞTİRME SÜRECİNDEKI ROLÜ
Sistem mimarisi, yalnızca bir teknik tasarım çıktısı değil, aynı zamanda bütün geliştirme sürecinin omurgasını oluşturan kritik bir entegrasyon noktasıdır. Otomotiv sektöründe güvenlik, siber güvenlik, güncellenebilirlik ve bilgi güvenliği gereksinimlerinin artması, sistem mimarisinin bu alanları birlikte ele alacak şekilde yeniden tanımlanmasını zorunlu kılmaktadır. ISO/IEC/IEEE 15288 yaşam döngüsü süreçleri dikkate alındığında, sistem mimarisi; kavramsal tasarımdan servisten çekmeye kadar tüm aşamaların sürekliliğini güvence altına alır.
Şekil 4 ISO/IEC/IEEE 15288 Sistem Yaşam Döngüsü Süreçleri
Modern araçlarda donanım, yazılım, haberleşme altyapısı ve bulut tabanlı servisler arasında karmaşık ilişkiler bulunmaktadır. Bu nedenle mimari, katmanlı bir yapı üzerinden ele alınmalı; donanım katmanı, işletim sistemi ve middleware, uygulama yazılımı ve kullanıcı etkileşim katmanı net biçimde ayrıştırılmalıdır. Bu katmanlar arasındaki etkileşimlerin modellenmesi, hem fonksiyonel güvenlik hem de siber güvenlik açısından kritik rol oynar.
Grady Booch’un da dediği gibi “Her sistem bir mimariye sahiptir. Bilinçli olarak veya kazayla”. Bu noktada önemli olan mimarinin ihtiyaç analizlerini, kısıtları, ilişkileri doğru değerlendirerek oluşturulmasıdır.
Örneğin, ISO 26262 kapsamındaki hata toleransı mekanizmaları, ISO/SAE 21434’te öngörülen tehdit modelleri ile birlikte mimari seviyede değerlendirildiğinde, çok daha bütünsel bir risk yönetimi elde edilebilir.
Şekil 5 MBSE Süreci - Otomotiv Güvenlik Entegrasyonu
Ayrıca sistem mimarisi, gereksinimlerin izlenebilirliği açısından da merkezî bir rol
üstlenmektedir. Bir güvenlik gereksinimi veya güncelleme politikası, mimari modelde ilgili bileşenle ilişkilendirildiğinde, değişikliklerin etkisi kolaylıkla takip edilebilir. Varyantların yönetimi de bu noktada önem kazanır; farklı araç modellerinde aynı mimarinin türevlerinin kullanımı, konfigürasyon tabanlı modelleme sayesinde mümkün olur. Bu sayede hem fonksiyonel güvenlik hedefleri hem de siber güvenlik önlemleri varyantlar arasında tutarlı biçimde korunur.
Şekil 6 Otomotiv Sistem Mimarisi Katmanları
Son olarak, mimari aşamada yapılan çalışmalar yalnızca geliştirme sürecini değil, fonksiyonel ve canlı testlerin etkinliğini de doğrudan etkiler. İyi tanımlanmış bir mimari, HIL, SIL ve VIL test senaryolarının daha erken aşamalarda hazırlanmasına olanak sağlar. Böylelikle MBSE yaklaşımı, sistem mimarisini geliştirme sürecinin merkezine yerleştirerek, standartların entegrasyonunu ve izlenebilirliği en üst düzeye çıkarmaktadır.
5. MODEL TABANLI SİSTEM MÜHENDİSLİĞİ (MBSE)
MBSE, mimariyi yalnızca görselleştirmekle kalmaz; aynı zamanda doğrulama, test ve güncelleme döngülerini de tek bir dijital ikiz üzerinden yönetir.
5.1 MBSE ADIMLARI VE STANDARTLARLA EŞLEŞTİRME
Sistemlere bütüncül bakışta gerek yazılım güvenliği, gerek bileşen güvenliği, gerek araç güvenliği veya sistem altyapısının baştan sona sistematik tasarımı ve yönetimi şarttır.
MBSE Adımlarına doğrudan atıflar, ilgili standartlarda aşağıdaki gibi yer almaktadır.
| Yaşam Döngüsü Aşaması | ISO/SAE 21434 | ISO 26262 | ISO/IEC 24089 | ISO/IEC 27001 |
| Kavram & Planlama | TARA analizi | HARA, ASIL tayini | Güncelleme gereksinimi | Varlık ve risk değerlendirmesi |
| Sistem Tanımı | Güvenli mimari | Sistem mimarisi ve arayüzleri | OTA uyumluluğu | Erişim kontrolleri |
| Tasarım & Geliştirme | Kriptografi, kimlik doğrulama | Güvenlik mekanizmaları | Versiyon yönetimi | Değişiklik yönetimi |
| Entegrasyon & Test | Penetrasyon testleri | Fonksiyonel testler | Güncelleme doğrulama | Test verisi güvenliği |
| Kullanım & Operasyon | Olay izleme, güncelleme sonrası izleme | Operasyonel güvenlik | OTA uygulama ve takibi | Loglama, izleme |
| Bakım & Güncelleme | Sürekli tehdit yönetimi | Güvenli bakım | Rollback, güncelleme döngüsü | İzleme ve gözden geçirme |
| Servisten Çekme | Veri silme, güvenli kapatma | Fonksiyonel sonlandırma | Güncellemenin durdurulması | Varlık emekliliği |
- Gereksinim Analizi: ISO/SAE 21434, ISO 26262 - Sistem Tanımı: ISO 24089, ISO/SAE 21434 - Doğrulama: ISO 26262, ISO/IEC 27001 - Güncelleme: ISO/IEC 24089
Bu doğrudan atıflar MBSE ile standartların yollarının kesiştiği yegane adımlar olarak değerlendirilmemelidir. Aşağıdaki eşleştirme tablosunda her standardın kendi içindeki adım ve metotların yaşam döngüsü sürecinde sistem mühendisliği ile örtüştüğü adımları göstermektedir.
Aşağıdaki tablo, ISO/SAE 21434, ISO 26262, ISO/IEC 24089 ve ISO/IEC 27001 standartlarının ISO/IEC/IEEE 15288 yaşam döngüsü süreçleri ile entegrasyonunu göstermektedir.
5.2 GEREKÇELENDİRME
MBSE yaklaşımı, farklı güvenlik standartlarının aynı platformda ele alınmasını sağlayarak bütüncül bir bakış açısı sunar. Geleneksel yöntemlerde fonksiyonel güvenlik, siber güvenlik veya yazılım güncellemeleri genellikle ayrı ayrı yönetilirken, MBSE sayesinde bu disiplinler arasındaki ilişkiler tek bir model üzerinde görselleştirilir ve izlenebilir hale gelir. Bu durum, gereksinimlerin çakışmasını azaltır ve güvenlik hedefleriyle siber güvenlik önlemlerinin tutarlı biçimde uygulanmasını mümkün kılar. Ayrıca dijital ikiz yaklaşımı, yazılım güncellemeleri ve güvenlik testlerinin sahaya çıkmadan önce sanal ortamda doğrulanmasına imkân tanır. Bu sayede hem zaman hem de maliyet açısından önemli avantajlar elde edilir. MBSE, yalnızca standartlara uyum sağlamakla kalmaz, aynı zamanda gelecekteki regülasyon değişikliklerine adaptasyonu da kolaylaştırır. Dolayısıyla, otomotiv yazılımındaki artan karmaşıklığın yönetilmesi için MBSE’nin gerekçesi, yalnızca teknik değil, aynı zamanda stratejik bir zorunluluk olarak ortaya çıkmaktadır.
Şekil 7 TARA Süreci
6. SİSTEM GELİŞTİRMEDE TESTLERİN ROLÜ
Geliştirilen sistemlerin, donanım ve yazılımların gerekli görevleri yerine getirip getirmediğinin kontrolü ancak sistematik doğrulama ile mümkündür.
Doğrulama Hedefleri:
– Maliyet, zamanlama ve performans gereksinimlerinin kabul edilebilir risk seviyeleriyle karşılandığından emin olmak için, en düşük seviyeden sistemin tamamına kadar fiziksel mimarinin doğrulanmasını sağlamak amacıyla belirlenmiş kriterleri kullanmak.
– Sistem tasarım çözümlerinde kullanılacak verileri üretmek ve teknolojileri doğrulamaktır.
Bu doğrulamayı sağlamanın en temel yöntemi ise testtir.
Test, sistemin belirtilen hedefleri (teknik performans, operasyonel etkinlik, operasyonel uygunluk) ne ölçüde karşıladığı, aştığı veya karşılayamadığı konusunda nesnel yargıların yapıldığı araçtır.
Değerlendirmenin amacı, sistematik kararlar almaya yardımcı olmak için testlerden ve diğer araçlardan elde edilen verileri incelemek, analiz etmek ve değerlendirmektir.
6.1. FONKSİYONEL TESTLER
Fonksiyonel testler, sistemin tasarım amaçlarına uygun şekilde çalışıp çalışmadığını ortaya koyar: - HIL (Hardware-in-the-Loop) - SIL (Software-in-the-Loop) - VIL (Vehicle-in-the-Loop) - Test Senaryosu Örnekleri: Acil frenleme, şerit takip, yazılım güncelleme sonrası fonksiyon kaybı kontrolü
6.2. CANLI TESTLER VE OPERASYONEL İZLEME
Fonksiyonel doğrulamanın ardından sistemlerin gerçek kullanım koşullarında güvenli çalışması için canlı testler kritik öneme sahiptir: - OTA Güncellemelerinin Testi - Siber Güvenlik Penetrasyon Testleri - Operasyonel İzleme - Saha Geri Bildirimi
7. SİSTEM YAKLAŞIMI
7.1. YAKLAŞIM VE MİMARİ: MBSE + V‑MODEL
Önerilen yaklaşım, SysML tabanlı bir MBSE modelinde gereksinimler, mimari, davranış ve doğrulama unsurlarını tek yerde toplayarak V‑Model boyunca uçtan uca izlenebilirliği kurar. V‑Model’in sol tarafında HARA, TARA, ISMS ve OTA risk etkinlikleri; sağ tarafında ise birim/entegrasyon/sistem testleri ve entegre assurance case yer alır. Temel prensip, riskten doğan her kararın bir gereksinime ve bir test kanıtına bağlanmasıdır.
Şekil 8 V‑Model’de standartların eşlemesi ve izlenebilirlik köprüleri.
7.2. ORTAK RİSK DİLİ VE BİRLEŞİK GEREKSİNİMLER KATMANI
ISO 26262 kapsamında HARA çıktıları güvenlik hedeflerine (Safety Goals) ve fonksiyonel/teknik güvenlik gereksinimlerine (FSC/TSC) dönüşür. ISO/SAE 21434’te TARA, siber güvenlik hedefleri ve konseptini oluşturur; bunlar siber güvenlik gereksinimlerine (CSR) ayrışır. ISO 27001’de ISMS riskleri, geliştirme ve operasyon bağlamında kontrol hedefleri ve Uygulanabilirlik Beyanı (SoA) ile yönetilir. ISO 24089’da OTA riskleri; paket güvenliği, bütünlük/doğrulama, dağıtım kampanyası güvenliği ve rollback kabiliyeti üzerinden ele alınır. Bu dört risk hattı birleşik gereksinimler katmanında birleştirilerek mimari bloklara allocate edilir ve test kapsamı ile ilişkilendirilir.
Şekil 9 HARA–TARA–ISMS–OTA iplikçiklerinin birleşik gereksinimlere akması
7.3. İZLENEBİLİRLİK VE ENTEGRE DOĞRULAMA ÖRNEĞİ
Modelde gereksinim ↔ risk ↔ mimari öğe ↔ test ↔ kanıt zinciri kurulur. Güvenlik (safety) ve siber güvenlik argümanları, hedef–strateji–kanıt (GSN) yapısı ile entegre bir assurance case altında derlenir. Denetim kanıtları ve regülasyon uyum çıktıları modelden otomatik veya yarı otomatik olarak üretilerek dokümantasyon maliyeti düşürülür ve tutarlılık artırılır.
Şekil 10 İzlenebilirlik matrisi ve sadeleştirilmiş GSN örneği
7.4. SÜREÇ ENTEGRASYONU: DEĞİŞİKLİK, TEDARİKÇİ, OLAY YÖNETİMİ
Değişiklik ve yapılandırma yönetiminde tekil CMDB/BOM/SBOM görünümü korunur; her değişiklikte ASIL, siber ve OTA etkileri birlikte değerlendirilir. Tedarikçi yönetimi; 26262 yetkinlik ve safety case girdileri, 21434 tedarikçi siber gereksinimleri, 24089 OTA uyumluluğu ve 27001 sözleşmesel kontroller ile bütünleştirilir. Ürün odaklı PSIRT süreçleri ile kurumsal ISMS olay yönetimi köprülenerek, sahadan gelen bulgular risk modeline geri beslenir.
7.5. KARAR KAPILARI VE ÇATIŞMA ÇÖZÜMÜ
Günlükleme ile gizlilik arasında denge, 27001’e uygun sınıflandırma ve en az gerekli veri ilkesiyle kurulur. Fail‑safe/fail‑operational tasarım kararlarında emniyet önceliklendirilirken, siber güvenlik kontrollerinin sistem davranışına etkisi analiz edilir. OTA kampanyalarında rollback kanıtı ve safety/siber risk onayı olmadan dağıtıma çıkılmaz; homologasyon gereklilikleri karar kapılarında doğrulanır.
8. GELECEK PERSPEKTİFİ VE STANDARTLARIN ENTEGRASYONU
Önümüzdeki on yıl içinde otomobillerde kullanılan yazılım satır sayısının 2025’te 100 milyon iken 2035 sonrası 1 milyar satırı aşacağı öngörülmektedir. Bu dramatik artış, yalnızca kodun miktarını değil, aynı zamanda yazılımın güvenlik yüzeyini de büyütmektedir. Dolayısıyla, fonksiyonel güvenlik (ISO 26262), siber güvenlik (ISO/SAE 21434), yazılım güncellemeleri (ISO/IEC 24089) ve bilgi güvenliği (ISO/IEC 27001) standartlarının entegrasyonu kaçınılmaz hale gelmiştir.
Şekil 11 Sektörel Uyum Haritası
Volkswagen Group, Technical Development bölümü tüm araç genelinde geliştirmenin sistematik yürütülebilmesi için bir MBSE konusunda çok ciddi yatırımlar yapmaktadır.
Teknik Geliştirmeden Sorumlu Yönetim Kurulu Üyesi Thomas Ulbrich bu durumu"Araba giderek elektrikle çalışan bir yazılım ürünü haline geliyorsa, gelişiminin de tüm boyutlarıyla gelişmesi gerekiyor. Süreçlerimizi ve organizasyonumuzu bileşenler yerine sistemlere ve işlevlere odaklayarak TD'yi daha bağlantılı ve daha verimli hale getiriyoruz. Önce donanım yerine yazılım. Bu, geliştirme sürelerimizi yüzde 25 oranında kısaltmamızı sağlayacak - gelecekte araç projeleri, temel yazılım mimarisinin yerleştiği noktadan itibaren 54 ay yerine 40 ayda tamamlanacak, Bu yıl, dönüşüm Wolfsburg'da planlanan Campus Sandkamp geliştirme merkeziyle Grup dışında da görünür hale gelecek. Campus Sandkamp'ı dünyanın en ileri teknolojiye sahip araç geliştirme merkezi yapmak için 800 milyon avro harcayacağız. Bu şekilde, TD'nin Volkswagen'i bir teknoloji şirketine dönüştürme hızını artırdığını vurguluyoruz," diye açıklamaktadır.
Hazırlanan entegrasyon matrisi, bu standartların ISO/IEC/IEEE 15288 yaşam döngüsü süreçleriyle nasıl kesiştiğini ve birbirini nasıl tamamladığını göstermektedir. MBSE, artan yazılım karmaşıklığını tek bir dijital ikiz ortamında yönetmenin anahtarıdır. Fonksiyonel testler ve canlı testler MBSE’nin içinde standartlara bağlanarak izlenebilir hale gelir. Sonuç olarak, otomotiv yazılımındaki büyüme, standartların entegrasyonu olmadan yönetilemeyecek bir karmaşıklığa doğru ilerlemektedir.
MBSE’nin bu standartlara uyumu çok hızlandıracak, ve uyumluluğun hızlı bir şekilde denetlenebilmesi mümkün olacaktır. Modelleme pratiğinin önemli olduğu otomotiv yazılımcılarının bu konuda gelişmesi gerektiğini, kullanabilecekleri tool’lar olduğunu yani bu işlerin soyut şeyler olmadığını, hemen eyleme geçebileceklerini de belirtmek isteriz.
9. SONUÇ
Bu bölümde, çalışmanın sonuçları kısa bir girişle özetlenmekte ve otomotiv sektöründe MBSE yaklaşımıyla standart entegrasyonunun geleceğe yönelik etkilerini vurgulayan ana fikirler madde madde sunulmaktadır.
- MBSE yaklaşımı, güvenlik, siber güvenlik ve yazılım güncellemeleri arasında köprü kurar.
- Otomotiv yazılımındaki artış, standart entegrasyonunu kaçınılmaz hale getirmektedir.
- Sistem mimarisi, gereksinim izlenebilirliği ve varyant yönetiminde kritik rol oynar.
- Fonksiyonel testlerin erken aşamada mimariyle ilişkilendirilmesi kaliteyi artırır.
- Canlı testler, güvenli OTA güncellemeleri ve operasyonel izleme ile desteklenmelidir.
- Entegrasyon matrisi, standartların süreçlerle ilişkisini net biçimde göstermektedir.
- OEM’ler için teknoloji ortaklarıyla entegre çalışma zorunlu hale gelmektedir.
- Dijital ikizler, güvenlik ve güncelleme doğrulamalarını hızlandırır.
- Standartlar arası çakışmalar MBSE ile en aza indirilebilir.
- Gelecekte güvenli yazılım geliştirme, entegrasyon odaklı MBSE yaklaşımıyla sürdürülebilir olacaktır.
