Zephyrnet Logosu

FMEDA Yeniden Kullanım Zamanı?

Tarih:

Tasarımcılar elektronik sistemlerde güvenliği nasıl ölçüyor? Arıza Modları, Etkileri ve Teşhis Analizi – FMEDA adı verilen bir veya daha fazla tablo aracılığıyla. Aslında bir FMEDA'nın bir tablo olması gerekmez; komut dosyaları veya başka bir biçimde ortaya konabilir, ancak bir tablo bu bilgiyi düşünmenin en kolay yoludur. Konsept kolayca çip üzerinde sisteme (SoC) kadar genişleyebildiğinden, IP için bir FMEDA düşünün. Tabloda, IP uzmanlarının kritik bir güvenlik sorununa yol açabileceğini tahmin edebileceği her arıza modu için bir satır bulunmaktadır. Bu arıza moduna ilişkin tanımlayıcı bilgilerin ardından, etkinin (neden olabileceği güvenlik sorununun) bir açıklaması yer almaktadır. Arıza simülasyonu yoluyla güvenlik mühendisi, bu etkiye yol açan temel sorunun olasılığını belirler. Olasılık önemliyse tasarımcı, sorunu tespit etmek için eşlik kontrolü veya sorunu düzeltmek için hata düzeltme kodu (ECC) kontrolü gibi bir azaltma tekniği önerecektir. Tamamlanmış bir FMEDA daha sonra söz konusu IP için kapsamlı bir güvenlik kalitesi belgesini temsil eder; bu, bir SoC entegratörünün tüm tasarım için FMEDA'yı belirlerken kullanabileceği bir karakterizasyondur.

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

ölçeklenebilirlik

Bu yaklaşımda bir sorun var. Bu örnekte bir FMEDA, tüm IP'lerin zor olması durumunda kabul edilebilecek, IP güvenliğinin düz bir karakterizasyonudur. Tasarımcılar IP'nin diğer yönlerini karakterize ederken FMEDA'yı oluşturabilir, onu IP ile birlikte saklayabilir ve ardından bu tabloyu SoC karakterizasyonunda kullanabilir. Bugünlerde çoğu IP, çip üzerinde ağ (NoC) gibi yapılandırılabilir. Tüm vakaları ele alacak tek bir FMEDA oluşturulamaz. SoC geliştiricisinin kullanılacak konfigürasyon için FMEDA'yı oluşturması gerekir. Fikri mülkiyet tedarikçisi yardım ve ipuçları sağlayabilir ancak entegratörün tüm analizi yapması gerekir. Tasarım sırasında konfigürasyonlar değişirse, bu FMEDA'ların yeniden oluşturulması gerekir.

Sezgisel olarak bu israftır. NoC IP'yi tekrar düşünün. NoC'nin somutlaştırılmış topolojisi muhtemelen tasarım geliştikçe değişecek olsa da, büyük olasılıkla radikal bir şekilde değişmeyecektir. Ve bu değişikliklerin FMEDA üzerindeki etkisi daha da sınırlı olacaktır. Her yeniden yapılandırmada FMEDA'nın sıfırdan yeniden oluşturulması, değiştirilmemiş olanların çoğunu göz ardı eder. Diğer durumlarda, önceki sonuçlara göre öngörülebilir değişiklikler vardır. Her yeniden yapılandırmanın yeniden analiz edilmesi işe yarayacaktır ancak tasarım boyutları büyüdükçe ölçeklenebilirlik sorunu ortaya çıkar. İyi ölçeklenmeyen bir süreçte adımlar atlanabilir ve güvenlik tehlikeye girebilir. Entegratörler için FMEDA'nın yeniden inşa edilmesi, halihazırda dolu bir tasarım programı dahilinde büyük bir iştir. Bu çabayı azaltmak hayatlarını kolaylaştırabilir.

Modelleme yoluyla yeniden kullanma

Arteris, bu sorunun yeniden kullanım yoluyla nasıl çözülebileceğine dair ileriye dönük bir teknik inceleme yazdı. FMEDA'nın önemli yönleri, IP mimarisinin anlaşılmasına ve ayrıntılı karakterizasyona dayalı olarak IP tedarikçisi tarafından geliştirilen güvenlik modellerinde yakalanabilir. Tamamen yapılandırılmış bir IP için bir FMEDA daha sonra bir entegratör tarafından bu modeller ve IP RTL'den yararlanan bir derleyici kullanılarak oluşturulabilir. Entegratörler için bu çok daha kolay bir iş olmalı. SoC güvenlik ekibi, iki kez kontrol olarak imzalanmadan önce hala tam düz FMEDA'yı çalıştırabilir; her yeniden yapılandırmanın bir analize ihtiyacı olmayacak.

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

Derleyici, entegratör için geleneksel bir FMEDA tablosu oluşturabilir veya SoC FMEDA üretiminde kullanılmak üzere bir komut dosyasını komut dosyası odaklı bir araca aktarabilir. Bugün bu düzeyde bir entegrasyon öncelikle büyük otomotiv yarı iletken şirketlerinin içsel olduğu görülüyor. Tipik olarak bu komut dosyası, entegrasyon yapıları, güç ve kontroller için IP düzeyi tablolarını FMEDA'larla birleştirir. Bağlam içi gereksinimleri ve kullanım varsayımlarını soyut hata modlarına uygulayan tasarımcılar ilgi çekici bir kullanım durumu yaratır. FMEDA'ların organizasyonunu standartlaştırma fırsatı vardır; bu, birden fazla fikri mülkiyet tedarikçisinden gelen girdilerin bir araya getirilmesini kolaylaştırabilir. Geliştirilen öneri, IEEE P2851, bu çabayı mümkün kılmalıdır. Aynı zamanda toplama ve soyutlama standartlarının tanımlanmasına da yardımcı olabilir. Bu, IP'ler için FMEDA geliştirmesinden SoC için FMEDA geliştirmeye kadar akışı tamamen otomatikleştirmek için ticari araçların geliştirilmesini teşvik edecektir.

Otomasyonda dikkat edilmesi gereken bir diğer husus izlenebilirliktir. Güvenlik gereksinimleri, otomotiv elektroniği sistem gereksinimlerinde kritik bir bileşendir ve tasarım ve testin yanı sıra izlenebilirlik altyapısına bağlanmalıdır. İzlenebilirlik otomasyonunun eklenmesi, güvenlik karakterizasyonunun geliştirilmesi ve izlenmesi için sağlam bir sistemi tamamlayacaktır.

Tıkla okuyun Bu konuyla ilgili teknik incelemeyi indirmek için. Ayrıca bu konuyla ilgili bir sunum mevcuttur. okuyun.

Stefano Lorenzini

  (tüm gönderiler)

Stefano Lorenzini, Arteris IP'de çalışan ve işlevsel bir güvenlik yöneticisidir. Lorenzini, Arteris IP, Alcatel Microelectronics, Cadence Design Systems, Ericsson, Intel, ST Microelectronics ve Yogitech'i kapsayan 25 yılı aşkın güvenli ve güvenli SoC tasarımı ve mimarisi deneyimine sahiptir. Son 18 yılını IEC 61508 ve ISO 26262 standartları tarafından düzenlenen SoC fonksiyonel güvenlik uygulamalarını yöneterek geçirdi. İtalya Pisa Üniversitesi'nden elektronik mühendisliği alanında yüksek lisans derecesine sahiptir.

spot_img

En Son İstihbarat

spot_img