Ann Keffer, Arun Gogineni ve James Kim tarafından

ADAS ve AV özelliklerini kullanan arabalar, kritik gerçek zamanlı uygulamaları gerçekleştirmek için karmaşık dijital ve analog sistemlere dayanır. Bu modern otomotiv tasarımlarında test edilmesi gereken çok sayıda arıza, tek bir teknoloji kullanılarak güvenlik doğrulaması yapılmasını imkansız hale getiriyor.

Ancak simülasyon, emülasyon ve formal için otomatik olarak hedeflenen belirli hata listeleriyle optimize edilmiş bir güvenlik metodolojisi geliştirmek zordur. Diğer bir zorluk ise nihai ölçüm hesaplaması için çeşitli hata enjeksiyon çalıştırmalarından elde edilen hata çözümleme sonuçlarının birleştirilmesidir.

İyi haber şu ki, arıza enjeksiyon motorlarının, optimizasyon tekniklerinin ve otomatik akışın birlikte çalışabilirliği, güvenlik analizinden güvenlik sertifikasyonuna kadar döngüyü hızlı bir şekilde kapatmak için genel yürütme süresini etkili bir şekilde azaltabilir.

Şekil 1'de güvenlik akışındaki optimizasyon tekniklerinden bazıları gösterilmektedir. Optimizasyon ve arıza düzeltme için güvenlik analizi, eşzamanlı arıza simülasyonu, arıza emülasyonu ve resmi bazlı analiz gibi gelişmiş metodolojiler, bir otomotiv SoC'sinin güvenlik gereksinimlerini doğrulamak için kullanılabilir.

Incir 1: Hata liste optimizasyon teknikleri.

Konsept kanıtı: bir otomotiv SoC'si

SoC seviyesinde bir test senaryosu kullanarak, bu otomatikleştirilmiş, çok motorlu akışın, gelişmiş otomotiv tasarımlarında test edilmesi gereken çok sayıda arızayı nasıl ele aldığını göstereceğiz. Bu test senaryosunda kullandığımız SoC tasarımının yaklaşık üç milyon kapısı vardı. İlk olarak, nihai ölçümler için hata kampanyalarını verimli bir şekilde tamamlamak amacıyla hem simülasyon hem de emülasyon hata enjeksiyon motorlarını kullandık. Daha sonra genel hata enjeksiyonunu tamamlamanın bir parçası olarak resmi analiz gerçekleştirdik.

Incir 2: Otomotiv SoC Üst düzey blok diyagramıdır.

Şekil 3, şekil 2'deki güvenlik adası bloğunun bir temsilidir. Renk kodlu alanlar, arıza enjeksiyonu ve arıza sınıflandırması için simülasyon, emülasyon ve resmi motorların nerede kullanıldığını gösterir.

Incir 3: Ayrıntılı güvenlik adası blok diyagramıdır.

Simülasyon kullanarak hata ekleme, CPU çekirdeği ve önbellek blokları için çok zaman ve kaynak tüketiyordu. Bu bloklar, verimlilik amacıyla bir emülasyon motoruyla hata enjeksiyonu için hedeflendi. CPU çekirdeği bir yazılım test kitaplığı (STL) tarafından korunur ve önbellek ECC tarafından korunur. Veri yolu arayüzü, simülasyonla arıza enjeksiyonunun verimli olduğunun belirlendiği uçtan uca koruma gerektirir. Arıza yönetim birimi bu deneyin bir parçası değildi. Arıza yönetim birimi için arıza enjeksiyonu, bir sonraki adım olarak resmi teknoloji kullanılarak tamamlanacak.

Tablo 1 güvenlik adasındaki blokların kayıt sayısını göstermektedir.

Tablo 1: Blok kayıt sayısı.

Bu blokların her biri için oluşturulan hata listeleri, güvenlik mekanizmaları/korumaları olan güvenlik açısından kritik düğümlere odaklanacak şekilde optimize edildi.

Bir güvenlik analiz aracı olan SafetyScope, hem Veloce Arıza Uygulaması (hata emülatörü) hem de arıza simülatörü için FM'lere yönelik arıza listeleri oluşturmak üzere çalıştırıldı ve arıza listelerini fonksiyonel güvenlik (FuSa) veritabanına yazdı.

CPU ve önbellek blokları için emülatör, sentezlenmiş blokları ve hata ekleme/hata tespit ağlarını (FIN/FDN) girer. Daha sonra uyarıyı yürüttü ve tüm FDN'lerin durumlarını yakaladı. Durumlar kaydedildi ve arıza enjeksiyon çalıştırmalarıyla karşılaştırma için "altın" referans olarak kullanıldı. Optimize edilmiş arıza listesinde listelenen her arıza için hatalı davranış taklit edildi ve FDN'ler, altın çalıştırma sırasında oluşturulan referans değerleriyle karşılaştırıldı ve sonuçlar, arıza veritabanında niteliklerle birlikte sınıflandırıldı ve güncellendi.

Şekil 4: CPU kümesi. (Kaynak itibaren https://developer.arm.com/Processors/Cortex-R52)

Blok diyagramda gösterilen alt parçaların her biri için analiz motorunu kullanarak optimize edilmiş bir hata listesi oluşturduk. Arıza listeleri FuSa veritabanındaki bireysel oturumlara kaydedilir. FuSa veritabanından rastgele örnek oluşturmak için genel faylar üzerinde istatistiksel rastgele örneklemeyi kullandık.

Şimdi emülasyon kullanarak hata enjeksiyonu boyunca rastgele bir örnek aldığımızda ne olacağına bakalım. Ancak bunun hata enjeksiyonunu tamamen kapatması için N numuneyi işledik.

tablo 2: algılandı faylar by güvenlik mekanizmaları.

Tablo 3, toplam arızalar için genel arıza dağılımının, rastgele örneklenmiş arızaların arıza dağılımı ile aynı doğrultuda olduğunu göstermektedir. Tablo ayrıca 3125 toplam arızadan 4782'inin tespit edilen toplam arızasını da göstermektedir. Ayrıca alt parça başına tespit edilen hataları modelleyebildik ve genel olarak %65.35'lik bir tespit edilen hata oranı sağladık. Rastgele örneklemdeki hatalara ve %90 kapsama hedefimize dayanarak hata marjının (MOE) ±%1.19 olduğunu hesapladık.

tablo 3: CPU ve önbellekte hata eklemenin sonuçları.

Toplam tespit edilen (gözlenen + gözlemlenmeyen) 3125 arıza, net bir arıza sınıflandırması sağlar. Tespit edilemeyen gözlemlenenler aynı zamanda Artık arızalar için de net bir sınıflandırma sağlar. Tespit edilmemiş gözlemlenmemiş ve eklenmemiş hataların daha fazla analizini yaptık.

tablo 4: Hata sınıflandırma sonra arıza enjeksiyonu.

616 Tespit Edilmemiş Gözlemlenemeyen arızayı analiz etmek için birçok hata ayıklama tekniği kullandık. İlk olarak, bu UU hatalarının etki konisini (COI) kontrol etmek için resmi analiz kullandık. COI dışındaki hatalar güvenli kabul edildi ve analizden çıkarılan beş hata vardı. COI içindeki arızalar için, ECC, zamanlayıcı, flaş bellekle ilgili vb. gibi çeşitli konfigürasyonların gerekçelendirilmesiyle birlikte mühendislik değerlendirmesini kullandık. Son olarak, resmi ve mühendislik değerlendirmesini kullanarak 616 UU arızalarını güvenli arızalar ve geri kalanlar olarak daha ayrıntılı olarak sınıflandırabildik. UU arızaları muhafazakar artık arızalara dönüşür. Ayrıca 79 kalan hatayı da inceledik ve 10 hatayı güvenli hatalar olarak sınıflandırabildik. Eklenmeyen hatalar ayrıca başka bir uyaranın bu hataları oluşturup oluşturamayacağını kontrol etmek için simülasyon modeline göre test edildi. Hiçbir uyarı bu hataları enjekte edemediğinden, bu hataları değerlendirmemizden ve buna göre hata marjına aykırı olarak çıkarmaya karar verdik. Bu değişiklikle birlikte yeni MOE'miz ±%1.293 oldu.

Buna paralel olarak arıza simülatörü, veri yolu bloğunun arıza modları için optimize edilmiş arıza listelerini çıkardı ve işlevsel doğrulamadan gelen uyarıyı kullanarak arıza simülasyonlarını çalıştırdı. Başlangıçtaki uyaran seti yeterli kapsama sağlamadığından daha yüksek kalitede uyaranlar (test vektörleri) hazırlandı ve yeni uyaranlar üzerinde ek hata kampanyaları yürütüldü. Tüm arıza sınıflandırmaları FuSa veri tabanına yazıldı. Genel verimlilik ve yüksek performans için tüm çalışmalar paralel ve eş zamanlı gerçekleştirildi.

SafetyScope kullanılarak yapılan güvenlik analizi, daha fazla doğruluk sağlanmasına ve arıza simülasyonunun yinelemesinin azaltılmasına yardımcı oldu. Çeşitli testlerdeki emülasyondan sonra CPU ve önbellek, Tablo 90'te gösterildiği gibi %5'ın üzerinde genel bir SPFM ile sonuçlandı.

tablo 5: Genel Sonuçlar.

Şu anda, arıza simülasyonunu gerçekleştiren BUS bloğu (uçtan uca koruma) için yapılan testlerin tümü tamamlanmamıştı. Tablo 6, ilk başlangıç ​​testinin %9.8'lik hataları çok hızlı bir şekilde çözebildiğini göstermektedir.

tablo 6: BUS bloğu için E2E SM tarafından algılanan hataların yüzdesi.

SoC'nin çalışma zamanı çalışma durumunu taklit etmek için BUS üzerinde yüksek trafiğe sahip daha fazla test entegre ediyoruz. Bu bağımsız hata enjeksiyonlarının sonuçları (simülasyon ve emülasyon), yukarıdaki bloklardaki son ölçümlerin hesaplanması için Tablo 7'de gösterilen sonuçlarla birleştirildi.

tablo 7: Analiz sonrası son arıza sınıflandırması.

Sonuç

Bu makalede, SoC düzeyindeki bir otomotiv test senaryosunda kullanılan yeni bir fonksiyonel güvenlik metodolojisinin ayrıntılarını paylaştık ve metodolojimizin, resmi, simülasyon ve emülasyon doğrulama motorlarını kullanarak hata eklemeye yönelik optimizasyon tekniklerini kullanarak nasıl ölçeklenebilir, verimli bir güvenlik iş akışı ürettiğini gösterdik. . Arıza eklemeyi çalıştırmadan önce güvenlik analizi yapmak çok kritikti ve zaman tasarrufu sağlıyordu. Bu nedenle, bu ölçekte bir proje için birden fazla motorun kullanılması ve sonuçların ortak bir FuSa veri tabanından okunması için birlikte çalışabilirlik gereklidir.

ADAS ve AV otomotiv tasarımlarına yönelik bu son derece etkili işlevsel güvenlik akışı hakkında daha fazla bilgi için lütfen Siemens EDA teknik incelemesini indirin. Karmaşık güvenlik mekanizmaları, doğrulama ve metrik kapatma için birlikte çalışabilirlik ve otomasyon gerektirir.

Arun Gogineni, Siemens EDA'da IC fonksiyonel güvenliğinde mühendislik yöneticisi ve mimardır.

James Kim, Siemens EDA'da teknik liderdir.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://semiengineering.com/interoperability-and-automation-yield-a-scalable-and-efficient-safety-workflow/