Otomobillerdeki ve diğer araçlardaki sınırsız otomasyon olanakları, tasarımcıları elektronik içeriğin artık diğer herhangi bir faktörden daha güçlü bir farklılaşma itici gücü olduğu noktasına kadar büyüledi. Bu araçların herhangi birinde malzeme maliyetinin önemli bir kısmını oluşturur. Ancak otomotiv teknolojisindeki bu devrim bir uyarı ile geliyor. Diğer uygulamalarda, bir elektronik sorunu kapatma veya yeniden başlatma ile düzeltilebilir. Ancak aynı çözünürlük otomobiller için iyi çalışmıyor. Elektronikteki yanlış davranış kazalara, hatta ölümlere neden olabilir.

Bu gerçek endişeyi gidermek için, ISO 26262 standardı, otomobillerde elektronik güvenlik için yönergeler belirlemek üzere hazırlandı. Bu bağlam, otomotiv elektroniği tasarımı sırasında karakterizasyonu ve ölçümü detaylandırır. Standarttaki en önemli analizlerden biri, her bir bileşen için Arıza Modları, Etkileri ve Teşhis Analizidir (FMEDA). Sistemin güvenliği üzerindeki ilgili etkisi ve bu tür arızaları azaltma yöntemleri ile olası arıza modlarını listeler. Bu raporlar, şekil 1'de gösterildiği gibi, IP'lerden otomotiv OEM'lerine kadar değer zinciri aracılığıyla güvenlik karakterizasyonunu iletir.

Şekil 1: FMEDA tedarik zinciri akışına bir örnek.

FMEDA'nın oluşturulması, otomotiv çip üzerinde sistem (SoC) başına önemli ölçüde çaba gerektirir ve bu parçalar yapılandırılabilir olduğunda bu görev birleştirilir. Bu sorumluluk, hangi konfigürasyonların gerekli olduğunu yalnızca tasarımcı bilebileceğinden, tedarikçiden ziyade entegratör üzerindeki yükü arttırır. Başka bir komplikasyon olarak standart, ayrıntılı formatı değil, yalnızca bu analiz raporları için amacı tanımlar. Bu formatlardaki tutarsızlıklar, değer zincirinde güvenlik analizinde üretkenliği engeller. Bu durum ölçeklenebilir değildir ve daha fazla standardizasyon ve zeka gerektirir.

Mevcut süreçteki sorunlar

Güvenlik değerlendirmesi, bir sistemin başarısız olabileceği olası yollar, nedenler ve sonuçlarla ilgili sistem tasarım deneyimine dayalı bir Arıza Modu ve Etkisi Analizi (FMEA) ile başlar. Bu, bir tasarımdaki her bileşen için raporlarda yakalanan sistematik bir FMEDA için başlangıç ​​noktası olur. Her arıza modu için, bu tür arızaları önleme, tespit etme ve düzeltme yöntemleriyle birlikte sistemin güvenliği üzerindeki potansiyel etki listelenir. Belki de kozmik radyasyonla iyonlaşma yoluyla tetiklenen rastgele arızalar özellikle endişe vericidir. Analiz, arızalı davranışların devre boyunca nasıl yayılacağını veya yayılıp yayılmayacağını belirleyen uzun arıza simülasyonlarına dayanır.

Şekil 2: FMEDA'ların yaratılmasındaki çoklu zorluklar.

Belirli bir tasarım düzeyindeki FMEDA, ayrıntılı bir düzeyde arıza modları için planlama ve test etme konusundaki titizliği gösterir. Sistem tasarımında bir sonraki seviyeye geçerken, FMEDA'lar tipik olarak daha yüksek seviyelere toplanmak için soyutlanır. Soyutlama, güvenlik analizi kapsamını korurken arıza modlarını sistem analiziyle ilgili olanlara indirger. Her kullanım durumu performansı yönlendirir ve sistem düzeyinde analiz sırasında farklı soyutlamalar oluşturmayı gerektirebilir.

SoC tasarımında süreç, şekil 2'de vurgulandığı gibi, ölçeklenebilirlik problemlerinden üç önemli şekilde muzdariptir. Çip üzerinde ağ (NoC) açık bir örnek sağlar. Her NoC yapılandırması, bağlandığı uç nokta IP'lerinde ve hizmet kalitesi ve güç hedeflerinde belirlenen SoC'ye özeldir. Bant çıkışından önce tasarım değiştikçe, NoC'nin de değişmesi gerekir. Her örnekleme, gerekli NoC konfigürasyonunu bilen SoC entegratörü tarafından gerçekleştirilen bağımsız bir analiz gerektirir.

Doğal bir soru, bu analizin en azından bir kısmının farklı konfigürasyonlar arasında yeniden kullanılıp kullanılamayacağıdır. Yeniden kullanım, SoC tasarımını hızlandırmada zaten başarılıdır ve işlevsel doğrulamada önemli bir rol oynar. Buna karşılık, FMEDA, tasarım gereksinimlerine nispeten yeni bir ektir ve henüz bir yeniden kullanım stratejisi geliştirmemiştir. Belirli bir düzeydeki her analiz sıfırdan yapılmalı ve önemli ölçüde zaman ve kaynak tüketmelidir. Yeniden kullanım stratejisi, tasarım çizelgelerinde çok büyük bir fark yaratabilir ve bir çözüm mevcutsa hataları önleyebilir.

FMEDA için standart bir formatın olmaması da bir verimlilik kaybıdır. Birden çok tedarikçinin IP'lerini kullanan SoC entegratörleri, kullanım senaryosu uyumluluğu konusunda farklı biçimler, gereksinimler ve varsayımlarla ve dolayısıyla soyutlamalar elde etmenin başka yollarıyla mücadele etmelidir. Bugün, bu kopukluklar entegratörler ve tedarikçiler arasında manuel olarak çözülüyor, ancak süreç ölçeklenebilir değil. Hataların olabileceği çok fazla nokta var.

FMEDA'yı yeniden kullanımla hizalama

Yeniden kullanım merkezli bir metodoloji, her aşamada düz analize dayanamaz. Yapılandırılabilir bir IP'nin temel hata modları, yapılandırmalar arasında farklılık göstermez. Bunlar, belirli bir düzen için bir FMEDA'nın oluşturulmasına izin vererek, RTL'nin parametrik örneklemelerinde yorumlanabilir olmalıdır. Bu akışta, hata modları ve güvenlik azaltma, rapor odaklı olmaktan ziyade model odaklı olacaktır. Model tabanlı bir yaklaşım, bir IP için bir FMEDA modelinin oluşturulmasına ve sunulmasına izin verir. Önemli kazanç, SoC entegratörünün artık tasarım geliştirme sırasında her konfigürasyon değişikliği için tam bir düz analiz yürütmesine gerek olmamasıdır.

Şekil 3: Önerilen FMEDA oluşturma süreci.

Bir sonraki mantıklı ilerleme, bu yeteneği SoC FMEDA derlemesine genişletmek olacaktır. SoC düzeyinde analiz için bir oluşturucu, IP'ler için geleneksel FMEDA raporlarını okuyabilir ve bağlam içi gereksinimleri ve kullanım varsayımlarını uygulayabilir. Bu, bu ayrıntıyı IP başına bu amaca uygun birkaç temel arıza moduna kadar optimize eder. Jeneratör daha sonra bu girdiden bu kullanım modeli için uygun SoC FMEDA'yı oluşturabilir. Farklı varsayımlar kümesi için yeni bir analiz oluşturmak, bu yeni parametreleri aramak ve oluşturucuyu yeniden çalıştırmaktan daha fazla çaba gerektirmez. Kullanılan araç ISO 26262 sertifikalı olduğundan, uyumluluk zaten yerleşik olduğundan bant çıkışından önce ek analiz gereksizdir. Şekil 3, IP düzeyinde FMEDA oluşumundan SoC düzeyinde FMEDA üretimine kadar önerilen tam akışı göstermektedir.

Bunun gibi bir metodoloji, model tabanlı yeteneği yalnızca bir IP tedarikçisi onaylamış olsa bile, bir SoC geliştirme ekibi için güvenlik analizini büyük ölçüde basitleştirebilir. Her bir IP tedarikçisi, şu anda geliştirilmekte olan IEEE P2851 standardı gibi bir güvenlik verisi alışverişi standardını destekleseydi, SoC güvenlik analizi ekibinin değeri daha da artacaktı. SoC için IP modellerini toplamak ve soyutlamak için araçları teşvik etmek, daha çok IEEE P2851'in tamamlanmasına ve benimsenmesine bağlı olabilir. Ancak, bazı otomotiv SoC tedarikçilerinde zaten bu nitelikte çözümler olduğu göz önüne alındığında, bu hedef çok ulaşılabilir görünüyor.

İzlenebilirlik ve FMEDA

Entegratörler ve tedarikçiler arasında gereksinimlerin değiş tokuş edilmesi gerektiğinde, izlenebilirlik zorunlu hale gelir. Otomotiv uygulamaları için tasarımda en önemli gereksinim, FMEDA'da belgelendiği gibi güvenliktir. Gereksinimler, uygulama, test etme ve FMEDA'lar birbiriyle yakından bağlantılıdır. Aşağıdaki şekil 4'te gösterildiği gibi, tüm sürecin bütünlüğü korunacaksa, bunlardan herhangi birinde meydana gelen değişiklikler diğerlerinde doğru bir şekilde izlenmelidir.

Şekil 4: Gereksinimler, uygulama, test ve FMEDA arasındaki izlenebilirlik yakından ilişkilidir.

Burada izlenebilirliği dikkate almak için başka bir zorlayıcı neden daha var. Her entegrasyon seviyesinde, FMEDA'lar ayrıntılı yapısal seviye arıza modlarından çok daha az sayıda sistem arıza moduna soyutlanır. Bu soyutlama, kullanım durumları ve sistem tasarımı deneyimine dayalı olarak gerçekleştirilir. Hatalar mümkündür ancak sistem arıza modlarından bileşen arızası soyutlamalarına ve daha ayrıntılı bileşen analizlerine kadar dikkatli izlenebilirlik yoluyla azaltılabilir.

İzlenebilirlik, farklı kullanım durumlarına karşı sorun teşhisi ve soyutlama desteği için değerlidir. Bir entegratör, bir kullanım durumu için belirli arıza modlarının diğerlerinden daha önemli olduğuna karar verebilir. Oysa başka bir durumda bu karar değişebilir. Tüm hata modlarını inceleme yeteneği göz önüne alındığında, bir entegratör neye öncelik vereceğini ve neyi görmezden geleceğini seçebilir. Bir jeneratörün desteğiyle, önceki bölümde açıklandığı gibi, bir entegratör seçenekleri keşfetmek için daha fazla esnekliğe sahip olacaktır.

Eylem çağrısı

FMEDA için uygulamaları yeniden kullanma hamlesi hem mantıklı hem de kaçınılmaz görünüyor. Yeniden kullanım uygulamaları, tasarım ve doğrulamada zaten fazlasıyla kanıtlanmıştır. Şimdi güvenlik analizlerinin bu seviyeye çıkma zamanı. Ortaya çıkmaya başladığında bu arayüzleri planlanan IEEE P2851 standardı ile uyumlu hale getirmek de doğal olacaktır. Bu arada, yüksek düzeyde yapılandırılabilir IP tedarikçileri, entegratör müşterilere daha iyi hizmet vermek için çözümler üretmelidir. Toplama ve soyutlama için otomotiv yarı iletken çözümleri, SoC düzeyinde daha eksiksiz bir çözüm tanımlamaya yardımcı olabilir. Bu yaklaşım, FMEDA aracılığıyla izlenebilirlik ihtiyacını kabul etmelidir.

Güvenlik analizi ölçeklenebilirliğinde başgösteren sorunu aşmak ancak bu nitelikteki gelişmelerle mümkündür.

FMEDA hakkında daha fazla bilgi için tıklayın okuyun.