設計師如何量化電子系統(tǒng)的安全性

通過一個或多個表格，稱為故障模式影響和診斷分析 - FMEDA。事實上，F(xiàn)MEDA 不一定是表格；它也可以用腳本或其他形式表現(xiàn)出來，但表格是考慮這些信息的最簡單方法。可以將 FMEDA 視為 IP，因為這個概念很容易擴展到系統(tǒng)級芯片(SoC)中。在FMEDA表格中，將 IP 專家能夠想到的可能導致嚴重安全問題的每一種故障模式都列出來，每種故障模式占一行。

在每種故障模式的辨識信息之后，是對其所產(chǎn)生影響的描述 - 即它可能導致的安全問題。通過故障模擬，安全工程師分析確定產(chǎn)生這種故障的根源問題的可能性。如果這種可能性很大，設計人員將提供一種緩解技術，例如用奇偶校驗來檢測問題，或用糾錯碼 (ECC) 檢查來糾正問題。最后，完整的 FMEDA 就代表該 IP 的綜合安全質(zhì)量文檔，SoC 集成商在確定整個設計的 FMEDA 時可以使用該描述表征。

圖1給出創(chuàng)建FMEDA面臨的多重挑戰(zhàn)。

可擴展性

這種方法存在一個問題。在這種情況下，F(xiàn)MEDA是 IP 安全性的基本表征，如果所有的 IP 都是嚴格定義的，這可能是可以接受的。在表征 IP 的其他方面時，設計人員可以繼續(xù)添加該 FMEDA的內(nèi)容，并將其存儲在 IP中，然后在 SoC 表征中使用該表。

如今，大多數(shù) IP 都是可配置的，例如片上網(wǎng)絡 (NoC)。沒有一個 FMEDA 可以用來處理所有情況。SoC 開發(fā)人員必須為將要使用的配置在 FMEDA中繼續(xù)添加內(nèi)容。雖然 IP 供應商可以提供幫助和提示，但是集成商必須進行所有分析。如果在設計期間配置發(fā)生變化，則必須重新構建FMEDA中相應的內(nèi)容。

直覺上這是一種浪費。我們再來看看 NoC IP的情況。雖然 NoC 的實例化拓撲可能會隨著設計的發(fā)展而改變，但它很可能不會發(fā)生根本性的變化。而這些變化對 FMEDA 的影響將更加有限。在每次重新配置時，從頭開始重新構建 FMEDA 會略過未更改的大部分內(nèi)容。

對于更改的情況，與之前的結果相比，變化是可預測的。重新分析每一次重新配置是可行的，但是隨著設計規(guī)模的增長，這會帶來可擴展性問題。在一個無法很好擴展的過程中，可能會遺漏一些步驟，安全性也會受到影響。對于集成商來說，在已經(jīng)很滿的設計時間表里，重建 FMEDA 是一項巨大的工作。努力減少這個工作量可以讓他們更輕松。

通過建模重復使用

Arteris 撰寫了一份關于如何通過重復使用來解決這個問題的前瞻性白皮書。在 IP 供應商基于對 IP 架構和詳細特征的理解而開發(fā)的安全模型中，F(xiàn)MEDA 的重要方面可以得到體現(xiàn)。然后，基于這些模型和 IP RTL，集成商可以使用編譯器來構建完全配置的 IP 的 FMEDA。

對于集成商來說，這應該是一件容易得多的任務。SoC 安全團隊仍然可以在簽核之前運行完整的 FMEDA 作為雙重檢查；每次重新配置都不需要分析。

圖2 給出建議的FMEDA的生成過程。

編譯器可以為集成商構建傳統(tǒng)的 FMEDA 表格，或者將腳本傳遞給腳本驅(qū)動工具，用于 SoC FMEDA 生成。今天，這種程度的集成似乎主要在大型汽車半導體公司內(nèi)部進行。通常，此腳本將 IP 級別表格與 FMEDA 聚合在一起，用于集成結構、電源和控制。設計人員將上下文需求和使用假設應用到抽象的故障模式中，創(chuàng)建了一個感興趣的用例。

現(xiàn)在是需要將FMEDA的組織結構標準化，這樣可以簡化來自多個 IP 供應商的此類輸入的匯總。正在開發(fā)中的提案 IEEE P2851 應該能夠促成這項工作。它還可以幫助定義聚合和抽象的標準。這將鼓勵商業(yè)工具的開發(fā)，以便使從 IP 的 FMEDA 開發(fā)到 SoC 的 FMEDA 開發(fā)的流程完全自動化。

自動化的另一個考慮因素是可追溯性。安全需求是汽車電子系統(tǒng)需求的關鍵組成部分，應該與設計和測試一起納入可追溯性基礎結構。增加可追溯性自動化將完成開發(fā)和跟蹤安全特性的一個強大系統(tǒng)。

審核編輯：劉清